Хабр, привет! Это Виталий Колесников из МТС Диджитал. Недавно я поделился кейсом, как моя команда создала и внедрила стандартный производственный процесс с нуля. Но внедрить процесс — это полдела, дальше нужно его развивать. Как и хороший продукт, он меняется в зависимости от потребностей рынка и бизнеса. К тому же у пользователей есть свои запросы, а у производства продукта — свой жизненный цикл. Сегодня поделюсь опытом, как нам удается поддерживать единообразие процесса и при этом учитывать тенденции рынка, потребности команд и ЖЦ продуктов.

Изменения СПП. План действий

Для начала немного базы. Можно сказать, стандартный производственный процесс (СПП) — это набор объектов:

• эпик — крупная фича;

• история — более мелкая атомарная фича.

А они, в свою очередь, состоят из:

• статусов жизненного цикла;

• обязательных и необязательных атрибутов — ниже расскажу, что к ним относится;

• автоматизаций между объектами;

• автоматизации со смежными системами производства: разработка, тестирование и так далее.

Что такое обязательные и необязательные атрибуты? Первые — это те, без которых нельзя создать и идентифицировать задачу: тема, имя эпика или истории, автор и так далее. Необязательные — это дополнительные атрибуты: связь с другими задачами, период или квартал, сроки исполнения.

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

• минорные: добавление новых необязательных атрибутов и статусов, переходов между статусами;

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

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

Перед созданием сущности обязательно проводим исследования и опросы в других производственных командах. Так мы понимаем, востребованы ли изменения у широкой аудитории. А потом уже с учетом комплексной обратной связи разрабатываем новый процесс — то есть объект со своим жизненным циклом и атрибутами. 

Внося любые изменения, мы сохраняем единую стилистику наименований статусов, переходов и опорную функциональность для удобства работы с новой сущностью в стандартном workflow. Соблюдаем ролевую, статусную, приоритетную модель и схему переходов.

Есть еще один важный момент — SLA (Service Level Agreement). Это то, как быстро мы реагируем на запросы команд. В среднем минорные изменения мы вводим в пределах 2 дней. На крупные уходит от 7 до 14 дней. Так работают scrum-команды, это стандартный двухнедельный спринт, и он комфортен для всех сторон. Если запрос от команды поступает к нам в середине или конце текущего спринта, анализируем его мы уже в следующем.

Кто описывает изменения

За ключевые процессы по направлениям технологических практик (Agile, архитектура, разработка, тестирование, DevOps и другие) в нашей компании отвечают Владельцы процессов. Каждый Владелец может вносить изменения в действующие процессы, за которые он отвечает внутри СПП. Например, запланировать автоматизации, добавить или изменить статусы, добавить метрики. При этом он придерживается принципов построения СПП. 

Если изменение мажорное (по сути это создание нового процесса), мы запускаем пилотную версию, тестируем, собираем ОС и дорабатываем его. Минорные изменения касаются уже существующего процесса: с ними мы действуем по SLA.

Тонкости внедрения СПП

В предыдущем посте я рассказывал, что мы перевели на СПП сначала 5, 15, 80 продуктов, потом 300 и так далее. Конечно, сделать это непросто: сперва нужно проанализировать процесс, который уже есть в конкретной команде, подсветить слабые места, потом предложить решение. И, главное, привести сильные аргументы, чтобы ребята поняли, зачем им вообще нужно входить в эту историю. Будем честны, к изменениям многие из нас поначалу настроены скептически. Дальше опишу, как именно мы анализируем процесс в команде. 

Начинаем с продуктовой составляющей. На первой встрече просим озвучить цели, ценности и позиционирование продукта. Смотрим на структурированность бэклога, то есть нарезку на глобальные фичи (эпики) и атомарные ценности и фичи (истории). Если в команде продукта есть такая иерархическая структура, смотрим на названия сущностей — у любого эпика или истории они должны быть понятны. Ведь то, что команда запланировала в разработку, должно иметь прозрачную ценность и пользу для клиента, соответствовать условиям оценки и приема в работу (DoR, Definition of Ready), критериям приемки фичи и ее метрикам. Мы должны суметь это измерить и протестировать. Часто команды не задумываются об этом, тогда как переосмысление названия может привести к корректировке входных требований на разработку, DoD и AC по задаче — о них ниже.

Если названия фичей понятны и укладываются в цели и ценность продукта, смотрим на критерии: 

• DoD (Definition of Done) — показывает, что нужно сделать команде и после чего можно считать историю завершенной;

• AC (Acceptance Criteria) — показывает, что нужно сделать, чтобы удовлетворить потребности пользователя. 

Если с критериями все хорошо, анализируем процессную составляющую — как организовано производство, Agile и коммуникация. Здесь нас интересует, насколько часто продукт релизится, работает команда по Scrum или Kanban, сколько длятся спринты. Если частота поставки релиза максимум раз в две недели, идем дальше. Если реже, например, раз в три недели, в один или три месяца — начинаем разбираться. 

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

Чтобы сократить срок поставки, начинать все-таки с чего-то нужно. Вот несколько советов:

• не пытайтесь объять необъятное, не планируйте большой объем работ внутри истории. Иначе высок риск не уложиться в спринт;

• максимально распараллельте работу и распределите ее по разным спринтам;

• выделите часть Discovery из истории. Discovery — это большой кусок, связанный с CustDev. Может получиться, что гипотеза не подтвердится и в итоге вы не будете выпускать эту фичу, а какая-то часть работы по ней уже будет начата. Поэтому рекомендую запланировать Discovery на более ранние периоды;

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

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

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

Почему я акцентирую на этом внимание? Предлагаемый нами workflow заточен под инкрементальную разработку: на реализацию эпика может уйти три месяца, истории — не более двух недель. Чтобы все получилось, мы стараемся детально по маленьким кусочкам разбирать процессы: проектирование, аналитика, груминг (англ. PBR, Product Backlog Refinement, уточнение бэклога продукта по Agile), разработка, тестирование и развертывание.

Бывают ситуации, когда предлагаемый флоу командам не подходит — об этом мы узнаем, когда анализируем цели, критерии и частоту поставки релиза. Причина в разной зрелости производственных процессов разных продуктов. Поэтому перед тем, как переводить команду на стандартный workflow, мы дополнительно перестраиваем ее внутренние процессы. Обычно оптимизация и реинжиниринг происходят небыстро, вдобавок нужно найти общий язык с самой командой и заручиться ее поддержкой. Как уже говорил выше, в этом помогают сильные аргументы. Сотрудники должны увидеть, что изменения действительно полезны и, даже если сейчас придется дополнительно над чем-то поработать, в долгосрочной перспективе процесс станет удобнее и прозрачнее для всей компании.

Жизненный цикл производства — почему это важно?

Преднастроенный workflow эпиков и историй включает все этапы производства, которые я перечислил выше. Каждому из них соответствует отдельный статус или их группа. Для каждого объекта настроены проверки, обязательность и переходы. Проскочить или проигнорировать важный для производства этап не получится. 

Командам, в которых есть все необходимые роли, будет легко организовать работу внутри стандартного workflow. Для них все уже готово: автоматизации Jira связаны с ролями и этапами — значит, работать с объектами получится быстро и без влияния человеческого фактора. Можно строить статистику по этапам, выявлять слабые места — например, где и на каком шаге застряла история или как долго она проходила аналитику, разработку, код-ревью, тестирование. 

Но если один сотрудник совмещает несколько ролей, работа со всеми статусами флоу становится избыточной. Давайте на примере. Представьте, что разработчик — это еще и архитектор, и аналитик. Конечно, он не сможет выполнить всю это работу на 100% качественно. Для полного инкремента ему нужно проархитектурить, проаналитить задачу и разработать код. Лучше он выполнит именно свою часть — разработку. В итоге в прод можно выпустить фичу, которая снизит производительность продукта.

Такие проблемы как раз и позволяет выявить наш СПП. Метрики настроены на каждом процессе СПП, так что можно легко понять, как с каждым из этапов ЖЦ производства работает команда. А значит, CTO смогут вовремя реагировать и принимать меры.

В планах реализовать процессы для малых инженерных команд (с ограниченным составом ролей), которые позволят разрабатывать и выпускать релизы с более простым флоу. Еще мы развиваем процесс внутри СПП для автоматизированного управления релизами — в следующий раз расскажу об этом подробнее.