2022 год научил нас быстро менять приоритеты для оперативного реагирования на внешние факторы. В наших целях была зафиксирована ключевая задача по отказу от софта вендора в пользу собственных решений, разработанных на основе микросервисной архитектуры. Стоял вполне комфортный срок: полностью завершить переход до конца года, и команды планомерно шли к этой цели, наряду с разработкой менее масштабных, но тоже важных фич. Но в связи со вполне реальными рисками преждевременного ухода вендора из РФ сроки доработок сократились с полугода до одного месяца (почти как в известной шутке про невозможность родить ребёнка ранее, чем через 9 месяцев, сколько людей для этого процесса не привлекай). Ниже я опишу наш опыт мобилизации и решения поставленных задач в нереалистичные сроки.

Что имеем на старте

Задачу по переходу на собственные системы совместно решало несколько подразделений компании. В отличие от ситуации, описанной в другой статье на Хабре, у нас уже была большая команда, которая неоднократно показывала хороший результат в сжатые сроки в различных проектах. Но если в «обычных» проектах мы внутри команды формировали минигруппу разработки (с учётом календарных сроков и предварительной оценки в человеко-днях, об этом можно почитать тут), то этот проект обладал рядом особенностей:

• Отсутствие времени на нормальную аналитику (тут можно вставить шутку про «без нормального ТЗ получается ХЗ», но она становиться несмешной, когда дедлайн реально «завтра», а проект ещё не начат). Приходилось класть рельсы во время движения поезда.

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

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

• Масштаб доработки зашкаливал. Обычно речь шла о кусочке бизнес-процесса, который можно было пропилотировать изолированно, а потом растиражировать на всю страну. В нашем же случае весь бизнес-процесс переходил со стадий, которые диктовались софтом вендора, на наш новый, лучше адаптированный под текущую реальность процесс.

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

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

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

Как синхронизируем доработки

Для решения задач в сжатые сроки важна эффективность, а значит, мы должны были максимально исключить ошибки вида «две группы разработки делают одно и то же» (но, к сожалению, полностью их предотвратить невозможно). Чтобы синхронизировать доработки, мы каждое утро на стендапе узнавали результат работы каждого разработчика, а после проводили небольшое совещание между бизнесом, техлидами и техническими руководителями (управляющими несколькими командами). На этом мероприятии мы оценивали текущий глобальный прогресс и старались расположить будущие доработки таким образом, чтобы миникоманды как можно меньше пересекались, и результат работы одной миникоманды становился основой для доработок второй. Для подобного анализа техлиды и технические руководители должны быть максимально погружёнными в код проекта и процессы разработки, чтобы правильно учесть все нюансы и увидеть все риски.

Все команды вели разработку параллельно, и могли проводить независимое тестирование на моках. Таким образом мы убирали взаимозависимость разрабатываемой функциональности. Фичи прорабатывали «методом набегающей волны»: пока разработчики писали код одной фичи, бизнес-эксперт параллельно уже прорабатывал следующую. Но до конца общий объём трудозатрат в начале всего проекта был неочевиден.

Как выстраиваем релизный цикл

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

1. Все доработки в production льются сначала на узкую группу пользователей. В случае успеха и положительной обратной связи — тиражируются на страну.

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

3. Исправление найденных в production ошибок имеет приоритет над разработкой фич. Лучше успеть сделать меньше функциональности, чем застопорить работу крупнейшего ипотечного процесса в России.

Поддержка и исправление багов

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

Чтобы получать оперативную и объективную обратную связь о работе нашего программного обеспечения, мы создали чаты для общения с пользователями, отранжированные по степени критичности функциональности. Однако количество пользователей, задействованных в процессе, превышало 30 000+, поэтому потребовалось выстроить иерархию «ключевых пользователей», которые на своём уровне агрегировали проблемы и уже напрямую доносили их до разработчиков в чате. Почему это был чат? Потому что решение проблемы зачастую требовалось здесь и сейчас (особенность процесса), а не через час и не через день.

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

С какими сложностями мы столкнулись

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

• Никто не знает весь процесс целиком, только по частям. К сожалению, реальность такова, что никто не знает, как работают крупные системы. Можно найти специалиста по конкретному кусочку бизнес-процесса, либо же может повезти познакомиться с аналитиком, который поверхностно знает процесс целиком (но опускаясь на самый низкий уровень, в частные случаи, можно поймать множество сюрпризов). В такой ситуации нужно набираться терпения и стараться получить информацию изо всех источников.

• Выгорание и постоянная работа на выходных. Мощное напряжение сил в течение длительного времени не может не повлиять на здоровье и психику. Регулярная работа на выходных ускоряла разработку и снижала влияние на клиента, но недостаток отдыха постепенно накапливался. От полного выгорания спасала только дружелюбная (несмотря на всю сложность ситуации) атмосфера в команде, понимающее отношение руководства и сосредоточенность на конечной масштабной цели.

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

Какие положительные моменты мы смогли найти

Положительные моменты напрямую вытекают из недостатков процесса:

• Совместное «горение в танке» сблизило команды. Появились новые горизонтальные связи, произошёл интенсивный обмен опытом, совместная работа над тяжёлым проектом углубила взаимопонимание.

• Целеустремлённость руководства и выделение большого числа ресурсов и команд. Опытное руководство трезво оценило ситуацию и выделило все доступные ресурсы на выполнение задач. Были урегулированы все вопросы со старыми приоритетами команд, что позволило разработке не отвлекаться на другие задачи. Все переработки оплачивались в двойном размере.

• Карт-бланш на приоритизацию. Приоритизацией доработок занимались сами команды разработки, исходя из низкоуровнего понимания процесса. Никому не приходилось доказывать, что сначала надо реализовать и внедрить именно этот модуль, а не альтернативный (пусть доля бизнеса у него и больше).

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

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

Используемые лайфхаки

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

• Разбиение большой команды на независимые миникоманды (фронтенд + бекенд или фулстек + бекенд) снижает усилия на погружение в контекст.

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

• Короткий релизный цикл.

• Пилотирование всех доработок на малом числе пользователей в production (канареечные релизы).

• Приоритет исправления багов над реализацией фич.

• Чаты с ключевыми пользователями для быстрой обратной связи.

• Прямая коммуникация разработчиков разных команд минуя бизнес-эксперта.

• Гибкое изменение административных и HR-процедур для сохранения максимальной эффективности производственного процесса.

Выводы

Самый главный вывод — старайтесь не попасть в такой «смертельный» проект. Это был тяжелейший месяц в моей карьере. Возьмите отпуск, заболейте, уезжайте в командировку, но лучше откосите.

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

Надеюсь, мой опыт окажется полезным вам, если вы попадёте в такую же ситуацию.

P.S. Мы смогли.