Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Привет, меня зовут Дима, я ведущий ИТ бизнес-партнёр в Петрович-Тех. Сегодня расскажу вам историю о том, как мы запускали продуктовый подход к инхаус-разработке.
В 2020 году задачи бизнеса сыпались в «общий котел», коллеги из бизнеса буквально бились за ИТ-ресурсы по принципу «чьё важнее». Команды разработки формировались по принципу «кто делал что-то похожее», оценки делались примерные, с умножением на «пи» или на «е».
Эта статья – о том, как мы разбирали 1С УТ на продукты и сервисы, запускали “почти что Scrum-подход с элементами Kanban”, учились отвечать на вопросы “сколько ждать хотя бы примерно?” и “когда уже будет готово?” через метрики и перцентили – и как в конечном итоге благодаря продуктовому подходу нам удалось удвоить пропускную способность команд.
Драйвер изменений
Причина, по которой случились описываемые в статье изменения – классическая. Бизнес рос, задач стало больше, планка требований от бизнеса поднималась. Стали требоваться всё более точные сроки, появилась потребность организовать тесную совместную работу бизнеса и ИТ.
Нам хотелось сделать лучше сразу и для себя, и для бизнеса, стать прозрачнее “внутри и снаружи”: понять нашу пропускную способность, иметь общую и детальную статистику по командам, давать более точные прогнозные оценки.
Целевое решение мы сформулировали так: разделить входящий поток идей бизнеса на направления, закрепить за направлениями команды, формализовать понятный жизненный цикл задач, визуализировать работу, использовать метрики и явно обозначать точку принятия обязательств.
Продуктовый подход vs инхаус-разработка
Чтобы реализовать целевое решение, мы сделали ставку на запуск продуктового подхода. Часто под продуктовым подходом подразумевается тестирование гипотез и расчёт юнит-экономики. Скорость, гибкость, измеримость, а там уже и до бирюзовых смузи рукой подать. Но как всё это применить к инхаус-разработке?
Вопрос про инхаус (внутреннюю) разработку возник у нас неспроста: в Петрович-Тех мы создаём ИТ-решения для строительного ритейла, и большое число наших продуктов – то, с чем конечные клиенты не взаимодействуют напрямую, системы автоматизации разных промежуточных этапов цепочки создания ценности (логистика, сдача-приёмка товаров и другое).
Долго и не гибко, бесплатно и не прогнозируемо, “делай, что должен и будь что будет” – стереотипы об инхаус-разработке могут звучать как-то так. Увы, стереотипы эти бывают не всегда неверны.
Наша идея была в том, что продуктовый подход и инхаус-разработка не обязаны противоречить друг другу, могут сосуществовать. Давайте посмотрим, как реализация этой идеи выглядела на практике.
Пересобираем стримы и команды
Первым делом мы перепроверили, что не будем изобретать велосипед – договорились про матчасть, на которую будем опираться.
В основу заложили правила Kanban и принципы STATIK:
Выясните потребности и ожидания заказчика и сосредоточьтесь на них.
Управляйте работой, дайте людям возможность организоваться вокруг неё.
Развивайте правила для улучшения бизнес-показателей и увеличения пользовательской удовлетворенности.
Первое, что мы сделали – идентифицировали сервисы, проанализировали нагрузку, разделили поток входящих задач на стримы. В случае ИТ для строительного ритейла получился такой набор стримов:
маркетинг
розница
склад
логистика
электронный документооборот
партнёрская сеть
опт
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-лимиты) для следующих величин:
Количество инициатив от бизнеса в стрим.
Количество задач типа Story, Bug, Task, Spike для команды.
Объём Story Point в спринте.
А потом стали смотреть «горящие» работы и искать варианты увеличения производительности.
Ниже представлены реальные цифры сокращения Lead Time за год работы в таком формате.
Конечно, на улучшение метрики повлияло ещё и то, что за год компания увеличила штат сотрудников. Однако, сбор такой статистики позволил нам и в этом вопросе сделать оптимизацию – уйти от негибкого подхода “в любой непонятной ситуации нужны разработчики” к найму с учётом актуального контекста и различных потребностей. Например, бизнес-аналитиков в итоге за год в команду пришло больше, чем программистов.
Точки роста
Не обошлось без проблем. Во всём описываемом участвуют люди, которые устают, ходят в отпуск, болеют, решают житейские проблемы – человеческий фактор никто не отменял.
Маленькие инициативы всё ещё иногда делаются долго, так как часто берутся в работу в перерывах между большими; бывает, что откладываются.
Несмотря на достаточно высокий уровень экспертизы в домене нашего стрима, даже со всей собранной статистикой – иногда мы ошибаемся с оценками. Бывает, что запросы на изменения или требования прилетают в последний момент, внезапно.
Однажды мы передали в пользовательское тестирование доработку по реализации в 1С УТ, но заказчик решил протестировать вообще всё оформление сделки. Ответом на тестирование стал приложенный файл с проблемой при оформлении заказа покупателя, в который команда конечно же изменений не вносила.
На встрече с заказчиком выяснилось, что проблема вовсе не свежая и есть желание, чтобы функциональность работала по-другому. В процессе общения мы договорились вынести идею в новую инициативу.
Не всегда всё идёт по плану, но быстрая реакция на изменения – то, что выручает.
До и после изменений
До запуска продуктового подхода мы сталкивались с отношением, когда коллеги считали, что “зачем что-то менять, и так работает”, но в то же самое время “надо бы что-то поменять, а то бизнес вечно недоволен сроками”.
Сегодня мы умеем давать ответы на вопросы “когда будет готово?”, планировать ресурсы и работать с дедлайнами, открыто обсуждать сроки и состав работ с бизнесом, отказываться от невыгодных задач, принимать риски и разбирать техдолг. Продолжаем наращивать экспертизу в нашем бизнес-домене, смотрим динамику метрик и делаем ретроспективные обзоры работ, чтобы скорректировать оценки, сроки и другие показатели.
Обратная связь от бизнеса стала лучше, увеличилась их вовлеченность – мы вместе считаем затраты на разработку и финансовые выгоды на выходе.
Наладили скорость поставки и сократили Lead Time вдвое за год: средняя задача стала уходить в продуктив за 54 дня, вместо 100, а вообще любую с 85% вероятностью мы сделаем за 115 дней:
До конца года мы планируем снизить Lead Time на 15%, настроить процесс обменами лучшими практиками между командами. С коллегами из моей команды держим уровень “не меньше 15 Story Points”:
В дальнейших планах – систематизировать работу с OKR, сделать заход на поиск дополнительных вариантов оптимизации Time-To-Market, усилить Discovery-процессы.
Роадмап: год
Если вы идёте по пути разворачивания продуктового подхода прямо сейчас или планируете заняться этим в будущем, вот на всякий случай список тех шагов, которые прошли мы на дистанции в год – свериться.
Найдите и разграничьте зоны влияния и ответственности, выясните потребности и ожидания бизнеса, задавайте вопросы и обсуждайте ответы.
Составьте список работ, проанализируйте нагрузку и соберите продуктовые команды.
Расставьте приоритеты и уточните размеры задач через Story Points, рубашки или любым другим удобным для вас способом.
Создайте правила и регламенты, визуализируйте работу через доски, дашборды и документы.
Ограничьте поток работ на вход в бэклог команды.
Поработайте три месяца, вовлекайте бизнес, показывайте результаты.
Отслеживайте метрики своих команд: Lead Time, диаграмму сгорания работа, Cycle time отдельных работ и другие важные для вас метрики.
Роадмап: месяц
На случай если планируете запускать у себя продуктовый подход уже вот-вот – как выглядел наш роадмап на старте, в пределах первого месяца.
Визуализируйте работу – сделайте доски в любом удобном для вас месте: Trello, Notion, Jira, Kaiten или просто повесьте бумажные стикеры на стену в офисе.
Дайте своим задачам размеры и разделите задачи на этапы.
Двигайте задачи по статусам на вашей доске – смотрите, где возникают застои и пытайтесь понять почему.
Посчитайте, сколько дней живет задача в вашей системе и попытайтесь найти закономерности, обсудите с коллегами.
Начните работать итерациями от недели до месяца и берите тот объём работы, который вы реально можете сделать, исходя из скорости по результатам из пункта 4.
И в каком бы масштабе ни смотреть (месяца, года или любого другого интервала), в основании всех будущих изменений лежит необходимое и достаточное условие успеха: начните говорить с бизнесом. Расскажите, какую проблему хотите решить, какие есть идеи решения, почему такие, узнайте их мнение. Вероятность услышать в ответ “зачем что-то менять” – ненулевая. Но есть шансы и на “давайте делать, вместе” – так что попытаться стоит!
