Управление распределенными командами разработки

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

3 обязательных условия при работе с распределенными командами

• Выделенный менеджер

У каждой команды должно быть ответственное лицо, которое будет курировать свою часть работ. Обычно это либо Project manager, либо тимлид со стороны подрядчика.

• График взаимодействия

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

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

• Лид проекта

Обязательно должен быть человек, который видит всю картину целиком: либо собственник продукта, либо IT-менеджмент заказчика, который согласует действия всех команд. Также должен быть техлид, который соберет результаты работы нескольких групп разработки воедино. Это либо менеджер проекта, либо ведущий программист.

Как распределить специалистов в командах?

Когда продукт монолитный и пока не интегрируется с сервисами, то удобно привлекать одного подрядчика на все направления: front, back, QA и аналитика. Если подрядчик не может закрыть потребность полностью, то делить лучше, например, в формате front+back, QA+аналитика.

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

Как избежать проблем и организовать управление

Мы заметили, что проблемы на проектах с распределенными командами повторяются и выделили 4 самые популярные из них, а также описали, что поможет их устранить.

• Проблема 1: К задачам долго не приступают.

Часто причина в неправильном описании задачи. Эту ошибку обычно допускает бизнес с небольшим опытом во взаимодействии с компанией-разработчиком и ставит задачи в формате "надо добавить фичу" и все. Но такая постановка задачи тратит ресурс.

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

Чтобы этого избежать, лучше описать, как задачу можно воспроизвести в будущем и как ее протестировать, а также сразу дать все ресурсы для ее выполнения. Идеально описанная задача - когда тимлид делегирует ее разработчику, он сразу приступает к выполнению и сдает. И никто больше в процессе не участвует.

Признаки хорошо описанной задачи:

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

• Проблема 2: Задачи простаивают

Обычно команда не может приступить к работе из-за задержек другой, поэтому нужно заранее спланировать очередность работ и составить план на разработку.

Как происходит на практике: после обсуждения или анализа рынка было принято решение разработать фичу для сайта или дополнительную функциональность в приложении. Для описания задач потребовалась аналитика.

Когда аналитика готова, то она передается backend и frontend разработчикам на оценку. В то время, когда backend готовится к работам, можно сделать независимые задачи для фронтовой части.

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

• Проблема 3: На реализацию изменений уходит много времени.

Советуем руководствоваться простым правилом: не вносить изменений, пока спринт не закончен. Кажется, что внести изменение в ходе работы быстрее, но по факту это сильно вредит качеству продукта в перспективе.

Лучше планировать работу небольшими спринтами. По опыту: две недели - оптимальный срок. Команда успеет спланировать, как выполнить задачи, провести тестирование и внести правки. Следите, чтобы в этот период DevOps поддерживал высокую скорость и надежность CI/CD. Также прогнозируйте увеличение нагрузки на систему и ее расширение, чтобы подготовить сервера и ресурсы.

• Проблема 4: Происходят ошибки при загрузке обновлений.

Чаще всего ошибка в синхронизации front и back версий, нужно наладить коммуникацию об изменениях между менеджерами команд.

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

Чек-лист, который поможет держать проект под контролем:

• Созвоны по выбранному графику (Zoom, Skype, Google Meet)
• Подробный RoadMap для фиксации очередности действий команд (GoogleDocs, Jira)
• Единый "центр управления" общим процессом разработки (Jira, Trello)
• Отслеживание проблемных мест раз в неделю

Прозрачная и открытая коммуникация - основа всего. Иногда один факт, не рассказанный на митинге может стоить недельных переделок. Обязательно организуйте регулярный обмен информацией по проекту.

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