Ускоряем процесс разработки сложных проектов. Без хаоса и нервов

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

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

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

Часто самый простой и очевидный вариант увеличения скорости разработки — подключить новых специалистов или команду. Руководителю проекта кажется, что так можно ускорить скорость доставки business-value до конечных пользователей. На практике такое получается не всегда, особенно когда процессы в проекте требуют переработки. Приведем один пример из нашей практики.

Необходимо было подключить две команды к существующему развивающемуся проекту. Проект разрабатывался более 4-х лет и содержит большое количество подсистем (более 20) со своими общими механизмами и сервисами. Полный регресс требовал участия 5-7 QA инженеров и около 4-6 рабочий дней. При вхождении в проект и выхода команд на необходимый уровень решения задач столкнулись со следующими сложностями:

• Одна часть исходных кодов системы находилась под управлением системы управления версиями svn, другая git. SVN ранее был очень популярен, однако для больших командных проектов и частых параллельных изменений плохо подходит. Поэтому до перехода на git часть времени терялась на мерджи, правку конфликтов и прочие операции, связанные с ветвлением в svn.
• Для разворачивания окружения была устаревшая инструкция, поэтому команды собрали всевозможные подводные камни этой системы, а к первым задачам смогли приступить только через 3-4 дня.
• Ключевые аналитики, технические специалисты были заняты подготовкой релиза, поэтому невозможно было оперативно получать уточняющую информацию по новым задачам. Постановка задач была очень верхнеуровневой. Это существенно замедляло реализацию задач.
• Workflow задач был сложным, вначале команды “спотыкались” как поступать с задачей на протяжении ее жизненного цикла.
• Вначале клиент хотел обойтись только силами своих QA-инженеров, но у них не получалось полноценно и в нужные сроки проверить новый функционал, подключенных команд разработки, из-за большой загрузки. Поэтому приходилось работать с овертаймами.
• Code review проводился согласно устоявшимся на проекте принципам и критериям. Критерии не были задокументированы. Поэтому тратилось дополнительное время на исправление замечаний.

Результатом вышеописанных нюансов являются:

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

Рассмотрим как можно избежать подобной ситуации.

Анализ процессов

Прежде чем подключать новых специалистов, стоит разобраться, как устроена работа команды — необходимо найти и устранить «узкие» места. Обычно этим вопросом занимается PM, так как он отвечает за проект, и именно ему хочется тратить меньше сил на отслеживание процессов.

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

Анализ «узких мест» возможен с двух сторон: со стороны топ-менеджмента/эксперта и со стороны команды. Разберем каждый вариант отдельно.



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

Важное условие — поддержка руководства проекта и готовность к изменениям.

Соответственно, эксперт погружается в проект и подробно анализирует документацию, исходный код, структуру БД, производственный процесс (от проведения аналитики до релиза). Поэтапно работа выглядит так:

1. Рассматривается вся цепочка работ на проекте от начала и до конца. Замеряется время каждого процесса.
2. Строится диаграмма ганта. Эксперт смотрит какие процессы идут параллельно, какие друг за другом.
3. Эксперт думает как сделать каждый процесс более продуктивным и менее затратным. Как правило, эксперт интуитивно понимает в каких местах возникают самые большие сложности и начинает их раскручивать на предмет возможной модернизации.

Плюсы данного подхода:

• Работу анализирует человек, который не участвует в проекте. У него незамыленный взгляд на процессы, следовательно, он может найти, те проблемы, которые не видны членам команды.
• Эксперт, как авторитет, способен убедить команду принять изменения в процессах. Команды, которые долго работают над проектом не стремятся к нововведениям. Для них это большой стресс, так как придется заново переучиваться. Причем такая реакция идет даже на те изменения, которые помогут работать эффективнее.
• Быстрое внедрения решений — от 2-15 дней. Все зависит от глобальности изменений и бюрократичности внутри организации.
• Команда проекта перенимает опыт сторонних экспертов. В дальнейшем это поможет самостоятельно настраивать процессы.

Минусы:

• Экспертам нужно потратить много времени, чтобы разобраться в тонкостях. Команда может изучить историю проекта за день, в то время как эксперту нужно минимум полторы недели.
  Что с этим делать: ставить цели анализа вместе с руководителем проекта/тимлидом. Дать эксперту все «вводные» проекта, не утаивать детали.
  
  Если клиент настолько лоялен, что готов итерационно анализировать проект, нужно пользоваться случаем и соглашаться на такие условия. Впоследствии можно будет корректировать направление анализа после каждой итерации, фокусируясь только на нужном.
• Некоторые члены команды могут быть не согласны с решением. Впоследствии, они могут саботировать проект, плохо выполнять договоренности, а это плохо сказывается на общем настрое команды.
  
  Что с этим делать: обсуждать каждое решение вместе с командой, а не ставить их просто перед фактом.
  
  Идеальный вариант: эксперт анализирует процессы самостоятельно, а затем обсуждает их с ключевыми людьми на проекте. Если есть противоречия — они обсуждают их. Так накопится масса лояльных к изменениям людей, которые будут влиять на других членов команды. Можно будет убедить самых ярых скептиков.

Со стороны команды. Этот подход можно назвать ретроспективой, которая является неотъемлемой частью в scrum. Процесс выглядит так:

• Собирается вся команда проекта
• Один из участников берет на себя роль фасилитатора (scrum-master). Он следит за тем, чтобы беседа шла в конструктивном ключе.
• Команда обсуждает их подходы к работе. Рассматриваются все аспекты: процессы, написание кода, постановка задач и т.д. Затем выделяются плюсы и минусы.
• На общем голосовании договариваются об изменениях: плюсы нужно закрепить, минусы устранить.
• Через 3-4 недели процесс повторяется. Команда смотрит на результаты, и если всех всё устраивает, то работа продолжается.

Важные условия:

1. Поддержка руководством любых изменений и нововведений.
2. Сплоченность команды и нацеленность на улучшения.

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

Плюсы подхода:

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

Минусы:

• Есть риск, что будут решены лишь незначительные проблемы, а все ключевые так и останутся нетронутыми.
  Что с этим делать: PM, тимлид и фасилитатор должны через авторитет влиять своим мнением на команду. Их задача — привлечь внимание к важным проблемам еще на этапе обсуждения.
• Для серьезных изменений, которые требуют больших трудозатрат требуется дополнительное время на согласование с руководством. При этом не факт, что руководство согласится с нововведениями.
  Что с этим делать: отстаивать свою точку зрения перед руководством — это единственное решение.
• Если в команде нет постоянного обучения (конференции, обмен опытом, тренинги), то скорее всего достигнутые решения будут устаревшими и не столь эффективными.
  Что с этим делать: постоянно обмениваться опытом. Участвовать на профильных конференциях, митапах, внутренних тренингах. Если речь идет о крупной компании, то хорошим вариантом будут демо-дни. На таких мероприятиях команды показывают каких результатов они достигли в работе.

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

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

Подготовка инфраструктуры для новых команд

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

1. Задачи для новой команды должны быть подробно детализированы. К каждой из них можно приступить без ожидания — нет зависимости от текущих или будущих задач. Очерчены зоны ответственности каждой команды.
   Если этого не будет, то большая часть новой команды будет простаивать или заниматься второстепенными задачами, которые оказывают наименьшее влияние на ценность продукта.
2. Архитектура проекта «правильная», т.е. разбита на модули, подсистемы, общие компоненты.
   
   Если этого не будет, то подключить новую команду не получится. Разработчики будут работать под управлением текущего тимлида, но человек может эффективно управлять не более чем 7-9 людьми. Тимлид будет разрываться, а некоторые участники команды будут без дела ждать пока им дадут задачи.
   
   Если нет возможности выделить обособленные участки кода проекта, но двигаться вперед надо, то можно попробовать обойти это ограничение. Следует разделить проект на несколько частей через рефакторинг.
   
   Другой вариант — после погружения в проект двух-трёх человек отдавать на разработку новой команде все более крупные бизнес-функции. Так команды будут разрабатывать проект изолированно друг от друга, а за счет нового тимлида (человека, который погрузился в тонкости) сократит нагрузку на основного тимлида.
3. Процессы работы в проекте подробно описаны. Например, есть workflow задачи, показывается выполнение задачи в системе управления версиями (практика показывает, что не у всех стандартный GitFlow), описано взаимодействие между участниками проекта.
   Если этого не будет, то на проекте будет творится хаос. При этом руководитель проекта будет заниматься только «ручным», экстренным управлением.
4. У общих компонентов и модулей есть актуальная, понятная документация. Есть unit и интеграционные тесты основных частей. Существует понятное описание архитектуры всего проекта, общих механизмов, а также инструкция как их следует применять. Если вышеперечисленного пока не существует, то необходимо добавить подобные задачи в пул технического долга для исправления ситуации.
   
   Если этого не будет, то повышается риск выполнения двойной работы. Будет написан некачественный или дублированный исходный код. В дальнейшем это приведет к более дорогостоящей поддержке проекта. Как правило, подключение новой команды, подразумевает возможное подключение еще нескольких команд. Соответственно временные затраты будут масштабироваться на величину кратную количеству команд.
5. Зафиксированы правила написания кода — код конвенции, скриптов обновления структуры БД — миграции, общие принципы обязательного code review. Несмотря на сильную схожесть, наверняка у каждого проекта есть свои особенности.
   Если этого не будет, то сложность и стоимость дальнейшей поддержки проекта многократно возрастет.

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

Как мы подключали дополнительную команду на проект

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

1. Нет единой точной информации о том, каким образом должны быть реализованы фичи. Список задач, багов, улучшений устарел.
2. Нет continuous Integration, а разработка ведется в двух ветках.
3. Процесс тестирования продукта не отлажен. Например, QA-инженеры могут находить баги, которые уже были ранее исправлены, что приводит к дополнительным трудозатратам.
4. База тест-кейсов была в зачаточном состоянии. Отдельные QA-инженеры начинали писать кейсы для себя. Из-за этого никто не мог дать определенную оценку качеству продукта и возможным рискам при выпуске новой версии.
5. Процесс работы, от постановки до одобрения заказчиком, не документирован. Невозможно было спрогнозировать точный состав функций релиза, как и другие менее значимые пункты.

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

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

В результате внедрили\оптимизировали следующие процессы:

1. Выстроили коммуникации между всеми членами команды продукта — разработчики, аналитики, специалисты по тестированию.
2. Задокументировали критичные и сложные функции для более прозрачного тестирования, устранения дефектов, разрешения спорных ситуаций, последующего планирования работ.
3. Оптимизировали процессы по разработке. Принят WorkFlow и GitFlow проекта. Помогли настроить Continuous Integration и запуск автотестов в автоматическом режиме.
4. Увеличили скорость сборки тестовых стендов в два раза.
5. Организовали процесс правильного тестирования. Внедрили регрессионное тестирование по завершению каждой итерации.
6. Внедрили процесс планирования итераций.
7. Провели нагрузочное тестирование.

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

• Ввод в промышленную эксплуатацию спустя 3 месяца.
• Исправлено 70% багов
• Реализованы четыре серьезные фичи
• Оптимизирована и увеличена в 8 раза скорость загрузки некоторых страниц
• Получена точная информация о качестве всего продукта
• Построен RoadMap итераций

Считаю, что одно из самых важных достижений этого проекта — радость клиента. Он прозрачно представлял состояние проекта в любой момент времени, а обязательства перед бизнесом были выполнены в полном объеме и в оговоренные сроки.

Заключение

Основных способов увеличения скорости разработки проектов два: устранить «узкие» места и увеличить производственные мощности. В первом случае можно получить 30-40% прироста скорости разработки, во втором 70-80%. Дополнительные команды не дают двойного прироста производительности, поскольку больше времени тратится на взаимодействие между несколькими командами.

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

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

Над проектом, который мы описывали ранее, сейчас работает 3 команды ( одна старая и две новых). Количество выполняемых задач увеличилось в 1,9 раз.

Спасибо за внимание!
Авторские материалы для разработчиков мы также публикуем в наших соцсетях – ВКонтакте и Telegram.