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

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

Hola, Amigos!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

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

6969
1 комментарий

Или просто мало платят...

Ответить