Hola, Amigos!
Я Артём Салеев, руководитель backend-направления в компании Amiga. Мы занимаемся заказной разработкой мобильных приложений на Flutter, созданием веб-сайтов и корпоративных порталов.
Большинство советов, которые мы рассмотрим дальше, справедливы для заказной веб-разработки или проектной деятельности. Но если вы работаете в продукте, тоже сможете почерпнуть полезные рекомендации и применить на практике.
Эта статья вышла на основе моего выступления на конференции Merge 2022.
Все плохо, что делать?
Ситуация: задача не выполнена вовремя, потратили на нее больше часов, чем планировалось, а по итогу появляется куча багов. Знакомо? А когда мы получаем такой результат, к кому все идут в первую очередь? Конечно, к разработчикам.
Но почему команда косячит и что-то идет не так? Мы задались этим вопросом и ретроспективно посмотрели на последний год. Основные причины можно разбить на 3 категории: проблемы с документацией, регламенты процессов, регламенты разработки. Поехали разбираться.
Проектная документация
Чтобы избежать ошибок выше, у вас должна быть собрана вся информацию по проекту в одном месте. Мы храним данные в Confluence.
Я разделил блоки документации на 3 отдельные области в зависимости от ролей и их зоны ответственности (у вас разбивка может отличаться): общая информация, менеджерские документы, документы разработчика.
Общая информация
- Требования, ТЗ и спецификации. Зафиксированные требования — важнейшая часть любого проекта. Все, в том числе и клиент, должны понимать, какой продукт по итогу получится. К тому же, это гарант безопасности команды и компании с юридической точки зрения.
Оригинал: meme-arsenal.ru
- Материалы от клиента. Мы скидываем сюда все входящие материалы, которые прилетают со стороны заказчика — брифы, референсы, макеты и так далее. Всегда понятно, где искать потерявшуюся ссылку месячной давности, не в общем чате же.
- Список команды. Здесь хранятся следующие данные — ФИО, контакты, за что отвечает на проекте. Такой перечень поможет команде понять, кто и чем занимается, к кому обращаться в случае проблемы, как найти человека.
- Онбординг. Краткая «экскурсия» по проекту, которая поможет быстрее подключить новых сотрудников. Это дополнительный пункт — зависит от частоты сменяемости участников проекта. Всегда нужно смотреть целесообразность онбординга, не во всех проектах понадобится.
Ответственность менеджера
В нашей команде за наполнение этого блока документации отвечает менеджер проекта, у кого-то может быть по-другому. Какое наполнение входит в зону его ответственности?
- окументация проекта: акты, счета, договора с подрядчиками и т.п.
- Гант и сроки. Менеджер фиксирует, на каком этапе проекта команда находится, кто и что делает в ближайшее время, какие результаты. Необходимо постоянно поддерживать этот документ в актуальном состоянии. Мы также используем его на еженедельных встречах с клиентом, чтобы показывать сроки, результаты работы и подсвечивать какие-то контрольные точки.
- Спринты. Если работаете по Scrum, можете фиксировать пулы задач спринтов и отслеживать их.
- Бэклог. Используем это как копилку для желаний клиента. Периодически возвращаемся и мониторим, что можем реализовать.
- Ретро. Итожим с командой результаты, обсуждаем цели, задачи и что нужно исправить/улучшить. После встречи менеджер составляет отчет, который мы анализируем на следующем ретро (сверяемся, удалось ли нам исправить ошибки).
- Репорты. PM описывает договоренности на встречах с клиентом в репорт встречи, чтобы в процессе работы посмотреть, когда и о чем договорились.
Ответственность тимлида
То, что влияет на процессы разработки, фиксирует тимлид и ведет следующую документацию:
- Архитектура проекта. Включает в себя описание серверного окружения, архитектурные решения, используемые сервисы и механизмы взаимодействия между ними;
- Принципы и регламенты разработки. Раздел содержит в себе стандарты разработки и правила написания кода, которым необходимо придерживаться на проекте (PSR, SOLID и т.п). По большей части они общие, но бывают и исключения;
- Доступы. Важно контролировать уровни доступов всех участников проекта, особенно когда команда быстро растет;
- Тест-планы и баг-репорты. Раздел посвящен тестированию проекта и всему, что с ним связано. Хранение такой информации позволяет анализировать накопленные данные и делать последующие выводы;
- Технический долг — тут можно фиксировать временные решения и компромиссы, которые нужно исправить в перспективе, чтобы проект не скатился, куда не нужно.
Пример отображения информации по проекту в Confluence
Регламент процессов
Как я писал ранее, мы занимаемся заказной разработкой, и большая часть нашей работы сводится к выполнению различных задач. Поэтому рассмотрим, пожалуй, наиболее важный для нас — это регламент постановки задач. Мы на своем опыте пришли к следующим правилам:
- Четко формулировать задачи и составлять понятные требования. Делать это так, чтобы исполнитель, зайдя в задачу, понимал, что от него хотят. Справедливости ради — бьемся с этой проблемой по сей день. Постановка задачи в духе «cделать фильтр — вот макет» не прокатит.
- Оценивать трудозатраты. Думаю, что большинство читающих — умнички, и оценивают задачи прежде, чем брать их в работу. Это неотъемлемая часть контроля процесса и сроков, только так, и никак иначе :)
- Делать декомпозицию на задачи по 6 часов. Выработали для себя это правило, потому что набили много шишек. Задачи гораздо проще контролировать, и при таком подходе можно своевременно реагировать на возникающие проблемы.
- Ставить ответственных и сроки на любом этапе задачи, иначе вы рискуете потерять ее из виду или бесконечно переносить.
- Фиксировать любую другую информацию, которая поможет упростить процесс разработки/менеджмента.
Пример отображения дополнительных полей для упрощения менеджмента
Не менее важная часть задач — отчетность. Она необходима, чтобы на любом этапе задачи участники понимали, какая работа уже проделана, а что осталось реализовать. Также это способствует снижению количества узких горлышек в команде, когда при смене исполнителя или менеджера весь процесс встает. Что включает в себя такая отчетность:
- Трекинг времени — сколько потратил на выполнение задачи. Так мы можем смотреть аналитику, прогнозировать и корректировать последующие оценки.
- Комментарии по итогу выполненных работ: что сделано, что осталось.
- Инструкции при необходимости (как запустить выгрузку, где лежит скрипт и т.д).
- Если задача не завершена или нужно больше времени — описание проблемы. В идеале получать от исполнителей сразу возможные варианты решения этой проблемы.
Регламенты разработки
Этот раздел напрямую влияет на качество проекта в техническом плане и кодовой базы.
Первое, с чего необходимо начать, это организация тестовых зон. Можно описать, какие площадки вы создаете, где вы их создаете. Следующее, это Readme проекта — информация, которая поможет понять, как развернуть проект у себя, где взять актуальный бэкап базы и т.д. Так при подключении новых разработчиков не будет необходимости проходить эти круги ада с каждым.
Code Style. Написание кода должно быть в едином стандарте, для этого придумали соответствующие правила, которые необходимо соблюдать.
Работа с Git. Изначально мы полагались на классическое Git Flow, но этого оказалось недостаточно. Поэтому выделили ряд необходимых правил:
- Например, мы именуем коммиты по следующему правилу: task_XXX, где XXX — номер задачи из трекера. Это позволяет связать историю коммитов с задачей и в последующем легко и быстро отслеживать нужные правки
- Хуки, линтеры и пайплайны — вещи, с помощью которых можно упростить или автоматизировать процесс Code Review, Deploy и сократить трудозатраты.
- Прочая автоматизация — нет предела совершенству. На прошлом шаге можно не останавливаться, под свои нужды допиливать и автоматизировать процессы.
Итог
Проанализировав опыт сотрудников, мы выделили 3 основные причины, почему команда работает не так эффективно, как хотелось бы: отсутствие или неполная информация по проекту, нет четко регламентированных процессов взаимодействия в команде, а также процессов разработки, которые нуждались в оптимизации и доработке.
Мы разобрали несколько советов из различных категорий, которые напрямую влияют на эффективность разработки. Они не помогут избежать всех ошибок и трудностей, но существенно минимизируют их количество.
Спасибо, что дочитали статью до конца, буду рад ответить на все ваши вопросы и подискутировать в комментариях!
компании напрямую?
