Почему команда работает плохо? Очень много о регламентах и процессах

Hola, Amigos! 

Я Артём Салеев, руководитель backend-направления в компании Amiga. Мы занимаемся заказной разработкой мобильных приложений на Flutter, созданием веб-сайтов и корпоративных порталов. 

Большинство советов, которые мы рассмотрим дальше, справедливы для заказной веб-разработки или проектной деятельности. Но если вы работаете в продукте, тоже сможете почерпнуть полезные рекомендации и применить на практике. 

Эта статья вышла на основе моего выступления на конференции Merge 2022.

Все плохо, что делать?

Ситуация: задача не выполнена вовремя, потратили на нее больше часов, чем планировалось, а по итогу появляется куча багов. Знакомо? А когда мы получаем такой результат, к кому все идут в первую очередь? Конечно, к разработчикам. 

Но почему команда косячит и что-то идет не так? Мы задались этим вопросом и ретроспективно посмотрели на последний год. Основные причины можно разбить на 3 категории: проблемы с документацией, регламенты процессов, регламенты разработки. Поехали разбираться.

Проектная документация

Чтобы избежать ошибок выше, у вас должна быть собрана вся информацию по проекту в одном месте. Мы храним данные в Confluence. 

Я разделил блоки документации на 3 отдельные области в зависимости от ролей и их зоны ответственности (у вас разбивка может отличаться): общая информация, менеджерские документы, документы разработчика.

Общая информация

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

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

Ответственность менеджера

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

• окументация проекта: акты, счета, договора с подрядчиками и т.п.
• Гант и сроки. Менеджер фиксирует, на каком этапе проекта команда находится, кто и что делает в ближайшее время, какие результаты. Необходимо постоянно поддерживать этот документ в актуальном состоянии. Мы также используем его на еженедельных встречах с клиентом, чтобы показывать сроки, результаты работы и подсвечивать какие-то контрольные точки. 
• Спринты. Если работаете по Scrum, можете фиксировать пулы задач спринтов и отслеживать их. 
• Бэклог. Используем это как копилку для желаний клиента. Периодически возвращаемся и мониторим, что можем реализовать. 
• Ретро. Итожим с командой результаты, обсуждаем цели, задачи и что нужно исправить/улучшить. После встречи менеджер составляет отчет, который мы анализируем на следующем ретро (сверяемся, удалось ли нам исправить ошибки). 
• Репорты. PM описывает договоренности на встречах с клиентом в репорт встречи, чтобы в процессе работы посмотреть, когда и о чем договорились. 

Ответственность тимлида

То, что влияет на процессы разработки, фиксирует тимлид и ведет следующую документацию:

• Архитектура проекта. Включает в себя описание серверного окружения, архитектурные решения, используемые сервисы и механизмы взаимодействия между ними; 
•  Принципы и регламенты разработки. Раздел содержит в себе стандарты разработки и правила написания кода, которым необходимо придерживаться на проекте (PSR, SOLID и т.п). По большей части они общие, но бывают и исключения; 
• Доступы. Важно контролировать уровни доступов всех участников проекта, особенно когда команда быстро растет;
• Тест-планы и баг-репорты. Раздел посвящен тестированию проекта и всему, что с ним связано. Хранение такой информации позволяет анализировать накопленные данные и делать последующие выводы; 
•  Технический долг — тут можно фиксировать временные решения и компромиссы, которые нужно исправить в перспективе, чтобы проект не скатился, куда не нужно. 

Регламент процессов

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

• Четко формулировать задачи и составлять понятные требования. Делать это так, чтобы исполнитель, зайдя в задачу, понимал, что от него хотят. Справедливости ради — бьемся с этой проблемой по сей день. Постановка задачи в духе «cделать фильтр — вот макет» не прокатит.
• Оценивать трудозатраты. Думаю, что большинство читающих — умнички, и оценивают задачи прежде, чем брать их в работу. Это неотъемлемая часть контроля процесса и сроков, только так, и никак иначе :) 
• Делать декомпозицию на задачи по 6 часов. Выработали для себя это правило, потому что набили много шишек. Задачи гораздо проще контролировать, и при таком подходе можно своевременно реагировать на возникающие проблемы. 
• Ставить ответственных и сроки на любом этапе задачи, иначе вы рискуете потерять ее из виду или бесконечно переносить. 
• Фиксировать любую другую информацию, которая поможет упростить процесс разработки/менеджмента. 

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

• Трекинг времени — сколько потратил на выполнение задачи. Так мы можем смотреть аналитику, прогнозировать и корректировать последующие оценки. 
• Комментарии по итогу выполненных работ: что сделано, что осталось. 
• Инструкции при необходимости (как запустить выгрузку, где лежит скрипт и т.д). 
• Если задача не завершена или нужно больше времени — описание проблемы. В идеале получать от исполнителей сразу возможные варианты решения этой проблемы. 

Регламенты разработки

Этот раздел напрямую влияет на качество проекта в техническом плане и кодовой базы. 

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

Code Style. Написание кода должно быть в едином стандарте, для этого придумали соответствующие правила, которые необходимо соблюдать.

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

• Например, мы именуем коммиты по следующему правилу: task_XXX, где XXX — номер задачи из трекера. Это позволяет связать историю коммитов с задачей и в последующем легко и быстро отслеживать нужные правки 
• Хуки, линтеры и пайплайны — вещи, с помощью которых можно упростить или автоматизировать процесс Code Review, Deploy и сократить трудозатраты. 
• Прочая автоматизация — нет предела совершенству. На прошлом шаге можно не останавливаться, под свои нужды допиливать и автоматизировать процессы. 

Итог

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

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

Спасибо, что дочитали статью до конца, буду рад ответить на все ваши вопросы и подискутировать в комментариях!