Как запустить продуктовый подход в in-house разработке: цели, метрики, перцентили …

Хочу поговорить про продуктовый подход в инхаус-разработке.

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

А инхаус-разработка – это вот такой уставший программист, бесконечный 1С, долго, неизмеримо, и, как говорится, «делай, что говорят, и будь что будет».

Говорят, что эти два подхода очень плохо друг с другом уживаются. Но я расскажу о том, как мы их подружили.

Расскажу путь нашей компании, постараюсь дать какие-то практические советы – рассказать, как мы решали возникающие проблемы. И в конце постараюсь все это обобщить, чтобы было интересно.

Компания, в которой я работаю, называется «Петрович-ТЕХ». Мы создаем и развиваем ИТ-продукты для крупного строительного ритейла.

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

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

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

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

Технологии с предыдущего слайда позволяют нам:

• отправлять 93% доставок без участия логистов – у нас доставки автоматизированы;

• SMS о времени прибытия доставки у нас – это не абстрактное «ждите нас весь день», а конкретное «ждите нас 18.44» – точно к назначенному времени успевают 98% машин.

Это было пара слов о компании, теперь пара слов обо мне.

 

 

Меня зовут Дмитрий Макаров, я ИТ бизнес-партнер компании «Петрович-ТЕХ».

В ИТ я уже 15 лет. Прошел путь от системного администратора до разработчика, а потом от аналитика до ИТ бизнес-партнера.

 

Я расскажу о том, как мы запускали почти что Scrum-подход с элементами Kanban – или, может, это был Kanban-подход с элементами Scrum:

• Как мы разбивали 1С:УТ на продукты и сервисы и, самое главное, зачем.

• Как мы учились отвечать бизнесу на вопрос: «Когда будет готово хотя бы примерно?»

• Как мы вообще все это измеряли.

• Как мы через метрики пытались договариваться.

• Как за счет введения продуктового подхода нам удалось сократить время поставки на продуктив в два раза.

 

 

Давайте синхронизируемся по терминам.

Что такое продуктовый подход? Больше всего мне нравится определение коллег из ScrumTreck, что это:

• проектирование решений «от клиента»;

• развитие через эксперименты, тестирование гипотез и расчет юнит-экономики;

• и наличие продуктовой команды.

А когда я полез в интернет искать, что такое инхаус-разработка:

• Самое классное определение, которое я нашел – это обычная офисная работа.

• Еще мне понравилось, что это ИТ-компания внутри другой структуры – в нашем случае это ИТ-компания внутри другой компании.

• Причем наши продукты не замыкаются внутри компании – мы создаем сервисы для внутренних специалистов компании, а они через эти сервисы взаимодействуют с внешними клиентами.

 

Петрович-ТЕХ тогда

 

 

2020 год. В тот период обстановка в Петрович-ТЕХ была похожа на этот мем – разработка «в мыле» обрабатывала бесконечный поток задач, а бизнес все время от нас чего-то ждал.

• Задачи валились в «общий котел».

• Бизнес боролся за ресурс ИТ по принципу «чье важнее».

• Команды разработки выбирались по принципу: «Кто делал что-то похожее? Давайте, подключайтесь!»

• Оценки давались по знаменитому методу «три П»: пол, палец, потолок.

 

Компания росла, поток задач увеличивался, клиенты стали более требовательны. Мы поняли, что продуктовый и проектный подход надо разделять.

• Мы хотели настроить нормальный диалог бизнеса и ИТ – вовлечь бизнес в совместную работу с ИТ.

• Хотели понять нашу возможную пропускную способность и оптимизировать затраты на разработку.

• Хотели собирать статистику и метрики, чтобы стать прозрачнее.

• Одна из идей была – это составлять требования не только в терминах объектов 1С, но и в терминах бизнес-процессов.

Я сразу извиняюсь за фразу, которая уже набила всем оскомину, но у нас началась цифровая трансформация. На старте мы опирались на принципы STATIK и правила из Kanban, которые говорят о том, что:

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

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

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

Дальше расскажу, как мы это делали.

 

 

Наши первые цели были такие – мы хотели:

• разделить весь входящий поток от бизнеса на направления;

• закрепить за каждым из этих направлений свою команду;

• создать для каждой инициативы понятный и прозрачный жизненный цикл;

• визуализировать нашу работу;

• использовать метрики;

• и через эти метрики более явно предоставлять бизнесу точку принятия обязательств.

 

Наш путь. Первые шаги

 

В Kanban есть такое понятие как сервисы. Kanban Guide говорит о том, что любая компания – это экосистема взаимосвязанных сервисов.

Определение сервиса на слайде. Если в двух словах, сервис – это поток ценности, который создается для создания продукта или решения задач клиента.

Первое, что мы сделали, это идентифицировали сервисы и заказчиков для этих сервисов.

 

Разделение на сервисы произошло по направлениям деятельности – мы вынесли в отдельные сервисы обслуживание некоторых подсистем 1С, а также продукты, работающие не только на 1С:

• 7 направлений, которые выделены рамочкой, были связаны с УТ: маркетинг, склад и так далее.

• Финансы тоже связаны с 1С, но идут отдельным блоком, потому что они не из УТ.

• И отдельным треком у нас пошли E-com, интеграция и BI & ML.

Я лидирую направление «Розница», которое отвечает за процессы контакт-центра и строительных торговых центров. В общем, мы за Розницу.

Первые итоги:

• Как я уже сказал, мы идентифицировали сервисы и нашли заказчиков для этих сервисов (дальше расскажу, кто это).

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

• Далее определили эти команды поставки.

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

 

Команда

У каждого направления появилась своя «капсульная» команда

Часть команды от ИТ такая:

• Архитектор, он же тимлид.

• Два аналитика – либо бизнес, либо системных, в зависимости от требований бизнеса.

• Два разработчика.

• Quality Assurance.

• Два специалиста от техподдержки – один из них ближе к разработке, а второй ближе к бизнес-анализу.

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

Часть команды от бизнеса получилась такая:.

• Директора направлений стали бизнес-владельцами новых стримов. Они принимали последние power-решения и делали финальную визу.

• С ними мы согласовали закрепленных за стримами методологов. Методологи – это такие специалисты от бизнеса, power-юзеры, которые хорошо понимают, как работает система в зоне их ответственности, хорошо знают бизнес-домен и могут сформулировать свои ожидания.

 

Как ИТ и бизнес обсуждают идеи

 

Мы сформировали единое информационное пространство для обсуждения идей с бизнесом:

• Организовали регулярные встречи с бизнесом или каденции – петли обратной связи, которые мы еще назвали «Комитеты методологов». Я вообще считаю, что главный козырь во всей нашей цифровой трансформации – это был открытый диалог бизнеса и ИТ.

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

• Когда мы берем инициативу в работу, бизнес-аналитик дает для нее прогнозные даты завершения – это и есть точка принятия обязательств для ИТ.

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

Мы утвердили методологию и разработали понятные для нас регламенты.

На слайде схематично изображен процесс производства идеи от головы методолога (человека, который это придумал) до конкретного кода и реальных объектов в системе.

И в конце, когда процесс производства идеи уже завершен, мы с командой собираемся и анализируем метрики на ретроспективе.

 

 

Мы визуализировали жизненный цикл инициативы на доске в Miro.

Здесь показан пошаговый процесс работы, который разбит на тематические блоки, и для каждого блока расписано:

• кто что делает;

• какие триггеры к каким результатам приводят;

• и какие артефакты после этого остаются.

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

• как человека из бизнеса – например, нашего нового методолога или партнера;

• так и человека от команды – например, разработчика. «Смотри, мы делаем так, наша команда живет по таким правилам».

 

Документацию мы ведем в системе Confluence и один из артефактов от бизнеса – это «Концепция инициативы».

 

 

«Концепция инициативы» заполняется по шаблону.

• Сначала ее заполняет методолог от бизнеса – он описывает, зачем ему нужна эта инициатива. Какая у него боль, какие цели преследует эта инициатива, просчитывает выгоды и формирует метрики измерения результата.

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

• Затем ИТ-бизнес-партнер создает эту инициативу в системе Jira.

• Инициативе присваивается вес – мы измеряем инициативы в размерах футболок (T-shirt size) от XS до XXL. Задача размера XXL – это обычно заявка на проект, уже что-то мастодонтное.

 

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

Каждую маленькую задачку мы оцениваем в стори поинтах. Причем здесь мы не пошли по пути чисел Фибоначчи, мы взяли один стори поинт = один день. Мерить очень просто, и все, в принципе, понятно.

 

 

Мы стали работать по Scrum – запустили спринты в Jira, развернули kanban-доски.

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

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

 

 

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

• Утренние стендапы мы перенесли в мессенджер.

• В начале и конце спринта встречаемся в Zoom: в начале недели – чтобы пополнить бэелог и запустить спринт, а в конце недели – чтобы провести ретроспективу.

• И раз в квартал встречаемся для ревью сервиса поставки – смотрим на метрики, ищем проблемы и пытаемся сформировать пути решения этих проблем.

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

Особенно полезными оказались встречи для ревью сервиса поставки. На одной из таких встреч мы увидели, что прожигаем тестирование. Начали обсуждать и поняли, что нам не хватает еще одного quality assurance-тестировщика в спринт. Сейчас решается пополнение. Я дальше расскажу, как мы это заметили.

 

Метрики

 

 

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

Самая главная метрика, которую мы мерили – Lead-Time, время от того, как мы взяли инициативу в работу, до того, как мы по ней успешно завершили пользовательское тестирование.

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

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

Допустим, если вы когда-то сделали задачку, оцененную в размерах футболок на M, за 100 дней, то с 85% вероятностью вы ее снова сделаете за 100 дней. За эти сроки можно перед бизнесом коммититься.

Когда все закончено, мы собираемся с командой и обсуждаем метрики – смотрим отчеты, которые приняты в подходах Scrum и Kanban.

 

Отчеты, которые мы используем, это:

• кумулятивная диаграмма – Cycle Time;

• диаграмма сгорания работ спринта – Sprint Report;

• диаграмма производительности команды – Velocity Chart и так далее.

На слайде – скриншот плагина Jira Flow Companion. Это абсолютно бесплатный плагин для Chrome, который показывает 85 перцентиль для Lead Time и кумулятивные диаграммы.

Это реальная диаграмма сгорания работ моей команды за последние 6 недель – видно, где были какие зависания, как мы съедали задачки и так далее.

 

WIP лимиты: ограничения на количество задач в работе

 

 

WIP-лимиты.

Когда мы договорились о том, что мы оцениваем задачи в размерах футболок, нужно было договориться о количестве задач в работе по каждому из размеров.

Сначала мы с тимлидом долго различными подходами пытались просчитывать возможные комбинации: сколько задач каждого размера может «переварить» команда. Придумали формулу в Excel, хотели даже обработку в 1С написать, чтобы можно было двигать, сколько M взять, сколько L в зависимости от производительности команды.

Заручившись этими математическими выкладками пришли на «Комитет методологов» и говорим директорам, что мы посчитали. И когда я начал озвучивать свои идеи, один из директоров сказал: «Давайте пока что примерно на глаз прикинем так: 3 задачи L/XL, 3 задачи M и 4 задачи S/XS. Нормально?» И это правда было нормально.

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

Итого мы ввели WIP-лимиты и договорились об ограничениях в спринте по:

• количеству инициатив от бизнеса в стрим;

• количеству одновременных задач в спринте – сколько story, багов, тасков и спайков может попадать;

• и договорились об объемах сторипоинтов в спринте – решили, что у нас в спринте будет 16 сторипоинтов с запасом на тех. долг.

Почему 16 – дальше покажу, вы сможете это быстро для своей команды в будущем померить.

 

Сигналы потенциальных проблем

 

Сигнал потенциальных проблем. Когда мы установили ограничения и стали смотреть пропускную способность в динамике, мы стали искать «горящие» работы и варианты увеличения производительности.

Например, мы увидели, что на Kanban-доске есть «горящая» колонка Testing – явный сигнал потенциальной проблемы, о котором я ранее упоминал. Там было сначала 6 задач, 7 задач, потом 8 задач.

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

 

Точки роста

Безусловно, на сегодняшний день у нас есть точки роста.

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

• Мы можем иногда промахиваться с оценками.

• А запросы на изменения могут иногда приезжать под конец разработки, из-за чего страдают сроки.

• Одна из самых главных болей сейчас – это то, что из-за обилия XL-задач S и XS-задачи часто откладываются и их приходится делать «между делом». Либо в перерывах между большими, либо когда большие задачи ставятся на паузу – тогда начинаем пилить кнопку в обработке или править отчет.

 

Кейс: достижения открытого диалога

Могу рассказать про одно из достижений, полученных в результате открытого диалога.

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

Встретились, пообщались, решили, что это не запрос на изменение, а реально новое требование к системе – отпочковали это требование в новую инициативу и поставили на поток, а задачку отправили в деплой.

Я считаю, что такие достижения открытого диалога между бизнесом и ИТ как раз рождаются на стыке открытого и честного разговора.

 

Петрович-ТЕХ сейчас

 

 

Я хотел бы, конечно, в конце вот такую картинку показать, где теперь бизнес копает, а разработка чего-то ждет. Но, конечно, это не так.

Теперь копает и бизнес, и разработка:

• Бизнес копает в поисках лучших идей и каких-то полезных историй.

• Мы копаем в поисках оптимизации производительности и так далее.

• Главное, что сейчас улучшилось взаимодействие и возросла вовлеченность бизнеса.

• Мы вместе считаем затраты на разработку и финансовые выгоды на выходе.

• Для нас важно, что работа теперь разделена на стримы, а поток задач стал более предсказуемым.

 

 

На слайде – реальные цифры из нашего плагина к Jira. Здесь видно, как мы сократили Lead Time по компании:

• теперь задачку M мы делаем на 156 дней быстрее;

• а задачку L – на 203 дня быстрее.

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

 

 

По стриму «Розница», который я лидирую, мы реально сократили выполнение задачи размера M в два раза – от 100 до 54 дней.

А кумулятивная диаграмма справа показывает Lead Time о том, что 85% вообще любых задач команда решит за 115 дней.

 

 

Я обещал рассказать про экспериментально установленное ограничение в 16 Story points, которые мы успеваем закрыть за спринт.

В Jira есть диаграмма Velocity Chart. Она ретроспективно собирает производительность вашей команды и может изобразить среднюю линию, которая показывает, сколько в среднем в Story points ваша команда реально на самом деле съедает за спринты.

Вот так экспериментально можно подобрать ограничения для вашей команды.

 

 

В диалоге с бизнесом мы теперь умеем:

• отвечать на вопрос: «Когда примерно будет готово» и обсуждать состав работ с бизнесом;

• планировать дедлайны;

• работать с рисками;

• отказываться от невыгодных задач;

• разбирать техдолг;

• самое главное – мы умеем описывать то, что разрабатываем и в терминах 1С, и в терминах бизнес-процессов.

 

 

Кроме этого, в диалоге с бизнесом мы продолжаем:

• наращивать экспертизу;

• наблюдать динамику метрик;

• делать ретроспективные обзоры работ, чтобы корректировать оценки и сроки;

• считать затраты и выгоды.

 

 

Поскольку у нас помимо продуктовой есть и проектная разработка, я хотел еще рассказать, каким образом уживаются проекты и продукты. Но так как эта тема потянет на отдельное выступление, затрону только один момент:

• Когда в компании стартует проект, он, во-первых, имеет руководителя проекта от ИТ и от бизнеса.

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

 

Планы

 

 

Планы наши, наверное, такие:

• Мы планируем сократить Lead time на 15%.

• Хотим оптимизировать время с момента появления идеи у бизнеса до запуска в продуктив. Возможно, для этого придется залезть на поляну бизнеса, провести исследование процессов – построить канбан не только для ИТ, но и на поляне бизнеса.

• Планируем привлечь в нашу команду коллег с продуктовым майндсетом, которые горят темами Agile, Scrum, Kanban и так далее.

 

Рекомендации

 

 

Если аккумулировать наш роадмап на одном слайде, он будет выглядеть примерно так.

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

 

 

Практические рекомендации:

1. Визуализируйте свою работу, создайте доски. Для этого есть много бесплатных редакторов – Notion, Trello и другие. Даже если нет онлайн-доски, клейте стикеры на стены.

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

3. Разделите задачи на этапы, разлинуйте на доске несколько колонок «В очереди», «В работе», «Готово» и т.д.

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

5. Посчитайте, сколько дней живет ваша задача в системе.

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

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

 

Заключение

 

 

Я постарался рассказать, как мы подружили инхаус-разработку с продуктовым подходом. Теперь вот тут видно, что у дядьки появилась борода и смузи, поэтому у нас в инхаус-команде гибко, современно, интересно и со смузи.

 

Вопросы и ответы

 

Что делать, когда приходит задача по проекту, которая точно затронет не одну команду? Какие глобальные подводные камни здесь можно встроить?

У нас есть каденции, когда маленькие местечковые команды встречаются с бизнесом. А есть каденции, когда встречается крупный бизнес и туда приходит генеральный директор. Это называется проектный день – туда люди приходят с проектами и говорят: «Внимание, у нас вот такая работа. Мы затронем вот это, это и это».

Наверное, один из самых ярких примеров, с которым все сталкивались – это маркировка. Пришли ребята, говорят: «Ребята, у нас маркировка. Если не запустимся, мы не будем работать».

Поскольку маркировка нас коснулась в первую очередь с точки зрения направления «Розницы», она стала нашей болью – наш руководитель отдела сам за нее взялся, сам начал ее тащить.

Ребята пришли на проектный день и говорят генеральному: «Мы сейчас запускаем маркировку, поэтому тормозим финансы, розницу, склад и логистику. Но мы без этого реально жить не можем».

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

И здесь ищем уже баланс на стыке РП от бизнеса, РП от ИТ и бизнес-партнера. Собираемся и очень больно, кропотливо что-то достаем и двигаем.

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

Как вы продаете бизнесу техдолг?

Мне кажется, это про открытый диалог бизнеса и ИТ. Я когда прихожу и говорю: «Если мы сейчас вот это не сделаем, здесь приляжет» Мне говорят: «Дима, ты опять пугаешь!»

Но мне кажется, что эти истории про «пугать» очень честные и с бизнесом об этом нужно открыто говорить.

У нас есть давний техдолг, и хотя его не видно, он довольно критичный. И не так давно была история, когда тимлид сел, подключил софт, который собирает эти ошибки, нарисовал график и отправил на весь бизнес со словами: «Ребят, у нас проблемы». И бизнес согласился: «Давайте тогда лечить, наверное».

Мы иногда вынуждаем бизнес. Не сами просим у них возможности это полечить, а говорим бизнесу: «Ребята, смотрите, у вас болит». И бизнес говорит: «Да, давайте лечить».

Кто у вас отвечает за поддержку? И как часто к вам прилетают задачи, связанные с исправлением ошибок? Как вы их решаете?

У нас есть отдел, который занимается поддержкой вообще всех разработок в компании. И в самом стриме, в капсульной команде, есть еще два человека от саппорта, один ближе к бизнес-процессам, второй ближе к коду. Вход в команду, в наш стрим «Розница» происходит через этих людей.

• Если бизнес имеет какую-то проблему, он звонит на первую линию поддержки.

• Если первая линия поддержки не решает, проблема переходит на этих двух сотрудников – они пытаются решить.

• Если они не могут решить, то мы обсуждаем эту проблему и берем в работу

• Если это не что-то критичное, мы это разбираем на ретроспективе – в конце ретро у нас выступает саппортер. У него своя kanban-доска, там проблемы. Он говорит: «Вот это, это, это, это». Если бизнес-аналитик или разработчик сходу знает, как это полечить, его туда отправляют. Если нет, мы из этого формируем задачи на реверс-инжениринг. Задача встает в очередь так же, как техдолг, мы ее обсуждаем и берем в работу.

А если нужно починить срочно, быстро, на проде косяк?

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

Как определяется приоритет задач? Это решает продукт-оунер? Что делать, если таких продукт-оунеров несколько?

Продукт-оунер со стороны ИТ, который отвечает за бэклог спринта, он один. Мы его еще называем ИТ-бизнес-партнер. А от бизнеса продукт-оунеров несколько – это методологи.

Каким образом они бьются? Они выходят на проектный день и говорят: «Моя задача 200 миллионов», «А моя 20 миллионов». И есть бизнес-методолог, самый верхний человек от стрима, который говорит: «Это не делаем, а это делаем». Все.

У вас в составе ИТ-команды есть аналитики, один из которых ИТ-бизнес-партнер. А от бизнеса есть методологи. Как между ними провести границу? Не должен ли бизнес-аналитик знать то, что знает методолог?

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

Как мотивировать методологов заниматься этой работой при том, что у них есть своя задача от бизнеса зарабатывать деньги? И как мотивировать их руководителей выделять этих людей и давать с ними работать?

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

У нас внутри компании есть люди, которые сами хотят расти в ИТ, и мы с ними согласовываем.

У нас большая компания – 8 тысяч человек, и там несложно найти человека, который реально хочет.

Мы говорим: «Хотите быть ответственными за что-то?» Один говорит, что ему неинтересно, второму неинтересно, а третьему интересно.

Этот человек будет методологом сам, его не нужно заставлять и учить.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.