Привет, меня зовут Дима, я ведущий ИТ-бизнес-партнёр в "Петрович-Тех". Сегодня расскажу вам историю о том, как мы запускали продуктовый подход к инхаус-разработке. 

В 2020 году задачи бизнеса сыпались в «общий котел», коллеги из бизнеса буквально бились за ИТ-ресурсы по принципу «чьё важнее». Команды разработки формировались по принципу «кто делал что-то похожее», оценки делались примерные с умножением на «пи» или на «е».

Эта статья – о том, как мы разбирали 1С УТ на продукты и сервисы, запускали “почти что Scrum-подход с элементами Kanban”, учились отвечать на вопросы “сколько ждать хотя бы примерно?” и “когда уже будет готово?” через метрики и перцентили – и как в конечном итоге благодаря продуктовому подходу нам удалось удвоить пропускную способность команд.

Драйвер изменений

Причина, по которой случились описываемые в статье изменения – классическая. Бизнес рос, задач стало больше, планка требований поднималась. Стали требоваться всё более точные сроки, появилась потребность организовать тесную совместную работу бизнеса и ИТ.

Нам хотелось сделать лучше сразу и для себя, и для бизнеса, стать прозрачнее “внутри и снаружи”: понять нашу пропускную способность, иметь общую и детальную статистику по командам, давать более точные прогнозные оценки. 

Целевое решение мы сформулировали так: разделить входящий поток идей бизнеса на направления, закрепить за направлениями команды, формализовать понятный жизненный цикл задач, визуализировать работу, использовать метрики и явно обозначать точку принятия обязательств.

Продуктовый подход vs инхаус-разработка

Чтобы реализовать целевое решение, мы сделали ставку на запуск продуктового подхода. Часто под продуктовым подходом подразумевается тестирование гипотез и расчёт юнит-экономики. Скорость, гибкость, измеримость, а там уже и до бирюзовых смузи рукой подать. Но как всё это применить к инхаус-разработке? 

Вопрос про инхаус (внутреннюю) разработку возник у нас неспроста: в "Петрович-Тех" мы создаём ИТ-решения для строительного ретейла, и большое число наших продуктов – то, с чем конечные клиенты не взаимодействуют напрямую, системы автоматизации разных промежуточных этапов цепочки создания ценности (логистика, сдача-приёмка товаров и другое).

Долго и не гибко, бесплатно и непрогнозируемо, “делай, что должен и будь что будет” – стереотипы об инхаус-разработке могут звучать как-то так. Увы, стереотипы эти бывают не всегда неверны.

Наша идея была в том, что продуктовый подход и инхаус-разработка не обязаны противоречить друг другу, могут сосуществовать. Давайте посмотрим, как реализация этой идеи выглядела на практике.

Пересобираем стримы и команды

Первым делом мы перепроверили, что не будем изобретать велосипед – договорились про матчасть, на которую будем опираться.

В основу заложили правила Kanban и принципы STATIK:

1. Выясните потребности и ожидания заказчика и сосредоточьтесь на них.

2. Управляйте работой, дайте людям возможность организоваться вокруг неё.

3. Развивайте правила для улучшения бизнес-показателей и увеличения пользовательской удовлетворенности.

Первое, что мы сделали – идентифицировали сервисы, проанализировали нагрузку, разделили поток входящих задач на стримы. В случае ИТ для строительного ритейла получился такой набор стримов:

• маркетинг

• розница

• склад

• логистика

• электронный документооборот

• партнёрская сеть

• опт

• e-commerce 

• финансы 

• интеграции

• BI & ML

Для каждого направления собрали свою команду. Состав типовой команды такой: архитектор решений (он же тимлид), два аналитика (бизнес или системных, в зависимости от потребностей), два разработчика, тестировщик и два специалиста поддержки (один ближе к бизнес-процессам, второй «ближе к коду»). 

Объединяют и курируют команды по каждому направлению ИТ бизнес-партнеры. Человек в этой роли больше всего похож на Product Owner, но также он выполняет ряд обязанностей бизнес-аналитика, Scrum-мастера и Delivery-менеджера. 

Безусловно, такие изменения не проходят без поддержки руководителей со стороны бизнеса: директора направлений стали бизнес-владельцами новых стримов. С ними мы согласовали закрепленных за стримами методологов от бизнеса, которые понимали, как работают процессы в зоне их ответственности и могли рассказать свои ожидания от системы.

Крупные задачи от бизнеса, которые в Scrum обычно называются «Epic», у нас получили название «Инициатива». Для их приоритизации и предоставления обратной связи, мы начали проводить регулярные встречи, которые назвали «комитеты методологов». На комитетах бизнес и ИТ обсуждают бенефиты от реализации, сроки и стоимость работ.

Логика распределения работ по стримам такая: кто выгодоприобретатель – тот и владелец. Инициативы, которые в ближайшее время будут взяты в работу, получают прогнозные даты завершения. Это точка принятия обязательств ИТ-команды.

Прозрачность и визуализация

Важный шаг в описываемом процессе изменений – описание методологии и регламенты. Эти артефакты с одной стороны фиксируют, как именно мы работаем, с другой стороны – эволюционируют со временем, вбирают в себя новый опыт.

Пример артефакта – “Концепция инициативы”. Это шаблон для методологов, где они описывают проблемы, бизнес-требования, просчитывают бенефиты, формируют метрики измерения результата. После этого ИТ бизнес-партнер помогает сформировать пользовательские требования, оценить риски и какие смежные информационные системы могут быть задействованы.

Документацию мы ведем в Confluence, она связана с задачами в Jira прозрачным треком от бизнес-требований до пользовательских историй и сценариев использования с тест-кейсами.

Инициативы мы измеряем «в рубашках» от XXL до XS, а остальные типы задач получают оценку в «story point». Мы не стали подходить к story point «академически», по принципу чисел Фибоначчи, а просто решили, что 1 SP = 1 день.

Визуализация жизненного цикла задач (от Инициативы до Story) выглядит примерно так:

Запустили в Jira типичные для Scrum спринты, начали проводить ретроспективы и встречи по пополнению бэклога, развернули Scrum и Kanban-доски.

В моём стриме мы используем 2-недельные спринты для бизнеса и недельные внутри команды разработки. Утренние «стендапы» мы перенесли в мессенджер, при этом в Zoom встречаемся два раза в неделю: чтобы запустить спринт и провести его ретроспективу. Раз в квартал встречаемся для ревью сервиса поставки: подсвечиваем проблемы, ищем причины их возникновения и придумываем план по их устранению.

Мы в шутку называем такой подход «Петрджайл» – как бы он не назывался, для нас главное, что работает.

Что там по цифрам

Можно было пойти разными путями, чтобы получить статистику для прогнозных оценок: например, использовать метод Монте-Карло. Мы решили пойти по эмпирическому пути: проработали три месяца и взяли полученную статистику за основу расчёта метрик, понимая, что к ним нужно будет возвращаться и актуализировать.

Мы считали показатели Lead Time и смотрели за его динамикой. Ещё для ряда продуктов считали Cycle Time некоторых блоков работ: например, время от взятия задачи в разработку до передачи в пользовательское тестирование.

Lead Time мы считали не средний или общий, а по 85-му перцентилю для каждого размера задачи. Этот подход позволяет брать время, за которое было завершено 85% прошедших через стрим задач. Таким образом, мы можем предположить, что с 85% вероятностью мы сделаем инициативу похожего размера за аналогичное время. Этот показатель мы рассчитываем через формулу в плагине “Structure” в Jira.

После сбора метрик, мы начали работать следующим образом: встречаемся на комитете методологов, присваиваем инициативе размер, берем Lead Time с 85-м перцентилем по такому размеру и обозначаем длительность. Прогнозные сроки сдачи инициатива получает после того, как ей начинает заниматься бизнес-аналитик.

Для сбора метрик используются графики Kanban и Scrum: кумулятивная диаграмма, диаграммы сгорания работ спринта (Sprint Report), диаграмма производительности команды (Velocity Chart) и другие.

Ограничиваем Work-In-Progress и измеряем динамику Lead Time

Важный этап изменений: ограничить поток инициатив на вход. Я довольно долго различными способами просчитывал возможные комбинации: сколько задач каждого размера может “переварить” команда? Сколько должно быть одновременной работы? Заручившись математическими выкладками я пошёл на встречу с бизнес-владельцами стрима.

Когда я начал озвучивать свои идеи, один из директоров сказал: “Давай пока что примерно, на глаз сделаем так: три задачи L, три задачи М и четыре задачи S/XS. Устраивает?”.

И это действительно всех устраивало! Такие быстрые решения от “сурового” бизнеса я считаю стоящими, такое может родиться только в открытом диалоге.

В итоге мы ввели ограничения одновременных задач в работе (WIP-лимиты) для следующих величин:

1. Количество инициатив от бизнеса в стрим.

2. Количество задач типа Story, Bug, Task, Spike для команды.

3. Объём Story Point в спринте.

А потом стали смотреть «горящие» работы и искать варианты увеличения производительности.

Ниже представлены реальные цифры сокращения Lead Time за год работы в таком формате. 

Конечно, на улучшение метрики повлияло ещё и то, что за год компания увеличила штат сотрудников. Однако, сбор такой статистики позволил нам и в этом вопросе сделать оптимизацию – уйти от негибкого подхода “в любой непонятной ситуации нужны разработчики” к найму с учётом актуального контекста и различных потребностей. Например, бизнес-аналитиков в итоге за год в команду пришло больше, чем программистов.

Точки роста

Не обошлось без проблем. Во всём описываемом участвуют люди, которые устают, ходят в отпуск, болеют, решают житейские проблемы – человеческий фактор никто не отменял.

Маленькие инициативы всё ещё иногда делаются долго, так как часто берутся в работу в перерывах между большими; бывает, что откладываются. 

Несмотря на достаточно высокий уровень экспертизы в домене нашего стрима, даже со всей собранной статистикой – иногда мы ошибаемся с оценками. Бывает, что запросы на изменения или требования прилетают в последний момент, внезапно. 

Однажды мы передали в пользовательское тестирование доработку по реализации в 1С УТ, но заказчик решил протестировать вообще всё оформление сделки. Ответом на тестирование стал приложенный файл с проблемой при оформлении заказа покупателя, в который команда конечно же изменений не вносила. 

На встрече с заказчиком выяснилось, что проблема вовсе не свежая и есть желание, чтобы функциональность работала по-другому. В процессе общения мы договорились вынести идею в новую инициативу. 

Не всегда всё идёт по плану, но быстрая реакция на изменения – то, что выручает.

До и после изменений

До запуска продуктового подхода мы сталкивались с отношением, когда коллеги считали, что “зачем что-то менять, и так работает”, но в то же самое время “надо бы что-то поменять, а то бизнес вечно недоволен сроками”. 

Сегодня мы умеем давать ответы на вопросы “когда будет готово?”, планировать ресурсы и работать с дедлайнами, открыто обсуждать сроки и состав работ с бизнесом, отказываться от невыгодных задач, принимать риски и разбирать техдолг. Продолжаем наращивать экспертизу в нашем бизнес-домене, смотрим динамику метрик и делаем ретроспективные обзоры работ, чтобы скорректировать оценки, сроки и другие показатели.

Обратная связь от бизнеса стала лучше, увеличилась вовлеченность – мы вместе считаем затраты на разработку и финансовые выгоды на выходе.

Наладили скорость поставки и сократили Lead Time вдвое за год: средняя задача стала уходить в продуктив за 54 дня, вместо 100, а вообще любую с 85% вероятностью мы сделаем за 115 дней:

До конца года мы планируем снизить Lead Time на 15%, настроить процесс обменами лучшими практиками между командами. С коллегами из моей команды держим уровень “не меньше 15 Story Points”:

В дальнейших планах – систематизировать работу с OKR, сделать заход на поиск дополнительных вариантов оптимизации Time-To-Market, усилить Discovery-процессы.

Роадмап: год

Если вы идёте по пути разворачивания продуктового подхода прямо сейчас или планируете заняться этим в будущем, вот на всякий случай список тех шагов, которые прошли мы на дистанции в год – свериться.

1. Найдите и разграничьте зоны влияния и ответственности, выясните потребности и ожидания бизнеса, задавайте вопросы и обсуждайте ответы.

2. Составьте список работ, проанализируйте нагрузку и соберите продуктовые команды.

3. Расставьте приоритеты и уточните размеры задач через Story Points, рубашки или любым другим удобным для вас способом.

4. Создайте правила и регламенты, визуализируйте работу через доски, дашборды и документы.

5. Ограничьте поток работ на вход в бэклог команды.

6. Поработайте три месяца, вовлекайте бизнес, показывайте результаты.

7. Отслеживайте метрики своих команд: Lead Time, диаграмму сгорания работа, Cycle time отдельных работ и другие важные для вас метрики.

Роадмап: месяц

На случай если планируете запускать у себя продуктовый подход уже вот-вот – как выглядел наш роадмап на старте, в пределах первого месяца. 

1. Визуализируйте работу – сделайте доски в любом удобном для вас месте: Trello, Notion, Jira, Kaiten или просто повесьте бумажные стикеры на стену в офисе.

2. Дайте своим задачам размеры и разделите задачи на этапы.

3. Двигайте задачи по статусам на вашей доске – смотрите, где возникают застои и пытайтесь понять почему.

4. Посчитайте, сколько дней живет задача в вашей системе и попытайтесь найти закономерности, обсудите с коллегами.

5. Начните работать итерациями от недели до месяца и берите тот объём работы, который вы реально можете сделать, исходя из скорости по результатам из пункта 4.

И в каком бы масштабе ни смотреть (месяца, года или любого другого интервала), в основании всех будущих изменений лежит необходимое и достаточное условие успеха: начните говорить с бизнесом. Расскажите, какую проблему хотите решить, какие есть идеи решения, почему такие, узнайте их мнение. Вероятность услышать в ответ “зачем что-то менять” – ненулевая. Но есть шансы и на “давайте делать, вместе” –  так что попытаться стоит!