2022 год научил нас быстро менять приоритеты для оперативного реагирования на внешние факторы. В наших целях была зафиксирована ключевая задача по отказу от софта вендора в пользу собственных решений, разработанных на основе микросервисной архитектуры. Стоял вполне комфортный срок: полностью завершить переход до конца года, и команды планомерно шли к этой цели, наряду с разработкой менее масштабных, но тоже важных фич. Но в связи со вполне реальными рисками преждевременного ухода вендора из РФ сроки доработок сократились с полугода до одного месяца (почти как в известной шутке про невозможность родить ребёнка ранее, чем через 9 месяцев, сколько людей для этого процесса не привлекай). Ниже я опишу наш опыт мобилизации и решения поставленных задач в нереалистичные сроки.
Что имеем на старте
Задачу по переходу на собственные системы совместно решало несколько подразделений компании. В отличие от ситуации, описанной в другой статье на Хабре, у нас уже была большая команда, которая неоднократно показывала хороший результат в сжатые сроки в различных проектах. Но если в «обычных» проектах мы внутри команды формировали минигруппу разработки (с учётом календарных сроков и предварительной оценки в человеко-днях, об этом можно почитать тут), то этот проект обладал рядом особенностей:
Отсутствие времени на нормальную аналитику (тут можно вставить шутку про «без нормального ТЗ получается ХЗ», но она становится несмешной, когда дедлайн реально «завтра», а проект ещё не начат). Приходилось класть рельсы во время движения поезда.
Огромная сложность в синхронизации и поддержке мастер-данных во всех интегрируемых системах, вводимых в эксплуатацию вместо софта вендора.
Слишком много внешних контрагентов. Это сильно затрудняло сбор первоначальных требований и подготовку условий для тестирования, удлиняло коммуникации.
Масштаб доработки зашкаливал. Обычно речь шла о кусочке бизнес-процесса, который можно было пропилотировать изолированно, а потом растиражировать на всю страну. В нашем же случае весь бизнес-процесс переходил со стадий, которые диктовались софтом вендора, на наш новый, лучше адаптированный под текущую реальность процесс.
Срок был слишком маленький, чтобы можно было добрать недостающих разработчиков, обучить их и получить планируемый результат.
Всего в проекте было задействовано около восемнадцати команд. Нашу часть разработки мы решили вести параллельными миникомандами (инженеров и экспертов взяли из текущих команд) с как можно более коротким релизным циклом, чтобы сразу видеть ошибки и иметь время на их корректировку. Сам процесс в ходе мозгового штурма был разбит на множество более маленьких подпроцессов, по каждому из которых завели эпик и назначили ответственного бизнес-специалиста.
Наш проект архитектурно представляет из себя набор сервисов и микросервисов, что облегчает внедрение изменений несколькими группами разработки.
Как синхронизируем доработки
Для решения задач в сжатые сроки важна эффективность, а значит, мы должны были максимально исключить ошибки вида «две группы разработки делают одно и то же» (но, к сожалению, полностью их предотвратить невозможно). Чтобы синхронизировать доработки, мы каждое утро на стендапе узнавали результат работы каждого разработчика, а после проводили небольшое совещание между бизнесом, техлидами и техническими руководителями (управляющими несколькими командами). На этом мероприятии мы оценивали текущий глобальный прогресс и старались расположить будущие доработки таким образом, чтобы миникоманды как можно меньше пересекались, и результат работы одной миникоманды становился основой для доработок второй. Для подобного анализа техлиды и технические руководители должны быть максимально погружёнными в код проекта и процессы разработки, чтобы правильно учесть все нюансы и увидеть все риски.
Все команды вели разработку параллельно, и могли проводить независимое тестирование на моках. Таким образом мы убирали взаимозависимость разрабатываемой функциональности. Фичи прорабатывали «методом набегающей волны»: пока разработчики писали код одной фичи, бизнес-эксперт параллельно уже прорабатывал следующую. Но до конца общий объём трудозатрат в начале всего проекта был неочевиден.
Как выстраиваем релизный цикл
Даже в самых экстремальных ситуациях нельзя забывать о пользователях вашего продукта. Поэтому мы использовали следующую систему:
Все доработки в production льются сначала на узкую группу пользователей. В случае успеха и положительной обратной связи — тиражируются на страну.
В течение недели можно лить только мелкие и средние доработки функциональности. В связи с высокими рисками поломки процессов крупные доработки лились только в выходные дни, когда пользователей системы значительно меньше. Для этого компания выводила команду разработки за двойную оплату.
Исправление найденных в production ошибок имеет приоритет над разработкой фич. Лучше успеть сделать меньше функциональности, чем застопорить работу крупнейшего ипотечного процесса в России.
Поддержка и исправление багов
Для обнаружения большинства типов ошибок в проектах есть технические и продуктовые метрики. Команда инженеров должна приложить все силы для того, чтобы узнавать о неисправностях раньше конечных пользователей. Но даже в системах с оперативными мониторингами могут проявляться технические неисправности, и чаще всего они возникают на стыке нескольких систем.
Чтобы получать оперативную и объективную обратную связь о работе нашего программного обеспечения, мы создали чаты для общения с пользователями, отранжированные по степени критичности функциональности. Однако количество пользователей, задействованных в процессе, превышало 30 000+, поэтому потребовалось выстроить иерархию «ключевых пользователей», которые на своём уровне агрегировали проблемы и уже напрямую доносили их до разработчиков в чате. Почему это был чат? Потому что решение проблемы зачастую требовалось здесь и сейчас (особенность процесса), а не через час и не через день.
Важно, чтобы общением с пользователями были заняты максимально вовлечённые в разработку люди, так как в ином случае до команды информация может доходить в искажённом виде.
С какими сложностями мы столкнулись
Постоянно ломающиеся тестовые стенды. Для того, чтобы проверить интеграционную доработку, надо было прогнать тестовый сценарий через огромное количество этапов, тестовые стенды для которых были в зоне ответственности разных команд. Тестирование с заглушками на своей стороне не помогало сильно повысить качество конечного продукта: процесс построен таким образом, что каждый предыдущий шаг зависит от данных, полученных на предыдущем шаге, поэтому важно было видеть реальные интеграционные ответы и проверять каждого участника цепочки, в противном случае ошибки накапливались. Поэтому сквозь боль и слёзы раз за разом приходилось просить помощи в починке чужого тестового стенда у всех контрагентов, предоставив фактуру по ошибке и сообщая об ожидаемом результате.
Никто не знает весь процесс целиком, только по частям. К сожалению, реальность такова, что никто не знает, как работают крупные системы. Можно найти специалиста по конкретному кусочку бизнес-процесса, либо же может повезти познакомиться с аналитиком, который поверхностно знает процесс целиком (но опускаясь на самый низкий уровень, в частные случаи, можно поймать множество сюрпризов). В такой ситуации нужно набираться терпения и стараться получить информацию изо всех источников.
Выгорание и постоянная работа на выходных. Мощное напряжение сил в течение длительного времени не может не повлиять на здоровье и психику. Регулярная работа на выходных ускоряла разработку и снижала влияние на клиента, но недостаток отдыха постепенно накапливался. От полного выгорания спасала только дружелюбная (несмотря на всю сложность ситуации) атмосфера в команде, понимающее отношение руководства и сосредоточенность на конечной масштабной цели.
Незаинтересованность части участников. В момент крупных изменений крайне сложно побудить всех участников процесса действовать синхронно, в одном темпе. Кто-то не может быстро включиться в новый процесс из-за непонимания, а для кого-то одна мысль о значительных изменениях кажется угрожающей. В таких ситуациях помогает выявление проблемных узлов и эскалация проблемы на более высокий уровень.
Какие положительные моменты мы смогли найти
Положительные моменты напрямую вытекают из недостатков процесса:
Совместное «горение в танке» сблизило команды. Появились новые горизонтальные связи, произошёл интенсивный обмен опытом, совместная работа над тяжёлым проектом углубила взаимопонимание.
Целеустремлённость руководства и выделение большого числа ресурсов и команд. Опытное руководство трезво оценило ситуацию и выделило все доступные ресурсы на выполнение задач. Были урегулированы все вопросы со старыми приоритетами команд, что позволило разработке не отвлекаться на другие задачи. Все переработки оплачивались в двойном размере.
Карт-бланш на приоритизацию. Приоритизацией доработок занимались сами команды разработки, исходя из низкоуровнего понимания процесса. Никому не приходилось доказывать, что сначала надо реализовать и внедрить именно этот модуль, а не альтернативный (пусть доля бизнеса у него и больше).
Быстрая обратная связь. Благодаря целеустремлённости и возможности пилотировать новые процессы на очень маленьком количестве пользователей удавалось получить честную обратную связь в кратчайшие сроки, поправить неучтённые моменты и «раскатить» на большую долю пользователей более стабильный процесс.
Появление понимания процесса у всех (даже у новичков-разработчиков). Постоянное сквозное тестирование процесса с прохождением всех нюансов и доработкой всех граничных случаев помогло вовлечь и на практике показать всю сложность банковского ипотечного процесса каждому члену команды.
Используемые лайфхаки
Попробую в единый список выписать практики, которые, по моему мнению, в значительной степени помогли при разработке и позволили добиться ожидаемого результата:
Разбиение большой команды на независимые миникоманды (фронтенд + бекенд или фулстек + бекенд) снижает усилия на погружение в контекст.
Инкапсуляция всех статусов, презентаций, планов и контрольных мероприятий в одну еженедельную встречу с минимальным отвлечением от производственного процесса «создаёт прозрачность» для руководства без дополнительного отвлечения.
Короткий релизный цикл.
Пилотирование всех доработок на малом числе пользователей в production (канареечные релизы).
Приоритет исправления багов над реализацией фич.
Чаты с ключевыми пользователями для быстрой обратной связи.
Прямая коммуникация разработчиков разных команд минуя бизнес-эксперта.
Гибкое изменение административных и HR-процедур для сохранения максимальной эффективности производственного процесса.
Выводы
Самый главный вывод — старайтесь не попасть в такой «смертельный» проект. Это был тяжелейший месяц в моей карьере. Возьмите отпуск, заболейте, уезжайте в командировку, но лучше откосите.
Если не выгорело и вы в «команде смертников», то сделайте всё возможное, чтобы достичь поставленной цели. Вероятно, придётся жертвовать личным временем, вниманием к семье и друзьям. Но такие проекты приносят очень неплохие материальные и нематериальные дивиденды в будущем (если всё-таки оказываются успешными).
Надеюсь, мой опыт окажется полезным вам, если вы попадёте в такую же ситуацию.
P.S. Мы смогли.