Как стать автором
Обновить
142.99
Домклик
Место силы

Как девять женщин могут родить ребёнка за месяц

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров14K

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

Теги:
Хабы:
Всего голосов 28: ↑26 и ↓2+29
Комментарии34

Публикации

Информация

Сайт
domclick.ru
Дата регистрации
Дата основания
Численность
501–1 000 человек
Местоположение
Россия
Представитель
Евгения Макарова