Организация рабочего процесса в команде на IT-проекте

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

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

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

В свое время я как раз и попал на такой проект, где были все эти прелести.

Никто не хотел брать на себя ответственность за проект (большой сервисный маркетплейс), текучка была страшная, заказчик просто рвал и метал. СЕО как-то подошел ко мне и сказал, что ты имеешь нужный опыт так вот тебе и карты в руки. Забирай проект себе. Облажаешься, проект закроем и всех выгоним. Получится, будет круто, тогда веди его и развивай, как считаешь нужным. В итоге я стал тимлидом на проекте и все легло на мои плечи.

Первое, что я сделал — это разработал рабочий процесс с нуля, который соответствовал на тот момент моему видению, и написал должностную инструкцию для команды. Внедрять его было непросто. Но где-то в течении месяца все устаканилось, разработчики и клиент привыкли, и все пошло уже тихо и комфортно. Для того чтобы показать команде, что это не просто «буря в стакане», а реальный выход из ситуации, я взял на себя максимальный объем обязанностей, сняв неприятную рутину с команды.

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

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

Поскольку на моем проекте это работает, то может быть кому-то это также сможет помочь. Итак, сам процесс, который помог нам спасти проект:

Процесс работы команды на проекте «Мой любимый проект»

a) Внутри командный процесс (между разработчиками)

• Все задачи создаются в системе Jira
• Каждая задача должна быть максимально описана, и выполнять строго одно действие
• Любая фича, если она достаточно сложная, разбивается на много мелких тасок
• Команда работает над фичами, как единой таской. Вначале делаем все вместе одну фичу, отдаем ее на тестирование, затем берем следующую.
• Каждая задача маркируется, для бэкенда или фронтенда она
• Есть типы тасок и багов. Нужно верно их указывать.
• После выполнения задачи она переводится в статус ревью кода (при этом создается пулл реквест на своего коллегу)
• Тот кто выполнял задачу сразу же трекает свое время для этой задачи
• После проверки кода, ПР апрувится и после этого, тот, кто выполнял эту задачу, самостоятельно мержит ее в мастер ветку, после чего изменяет ее статус в готова для деплоя на дев сервер.
• Все задачи, готовые к деплою на дев сервер, деплоятся тимлидом (его зона ответственности), иногда членом команды, если что-то срочное. После деплоя все таски с готова к деплою на дев переводятся в статус — готова к тестированию на деве
• Все задачи тестирует заказчик
• Когда заказчик протестировал задачу на деве, он переводит ее в статус готова для деплоя на прод
• Для деплоя на прод мы имеем отдельную ветку, куда мержим мастер только перед деплоем
• Если во время тестирования заказчик находит баги, то он возвращает задачу на доработку, устанавливая ей статус возвращена на доработку. Таким образом мы отделяем новые задачи от тех, которые не прошли тестирование
• В итоге все задачи проходят путь от создания до завершения: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
• Каждый разработчик тестирует свой код самостоятельно, в том числе и как пользователь сайта. Не допускается слитие ветки с основной, если доподлинно не известно, что код работает.
• У каждой задачи есть приоритеты. Приоритеты расставляет либо заказчик, либо тимлид.
• Разработчики в первую очередь выполняют приоритетные задачи.
• Разработчики могут назначать задачи друг на друга, если были найдены разные баги в системе или одна задача состоит из работы нескольких специалистов.
• Все задачи, которые создает заказчик, попадают к тимлиду, который их оценивает, и либо просит заказчика доработать либо назначает на одного из членов команды.
• Все задачи, которые готовы к деплою на дев или прод, попадают также к тимлиду, который самостоятельно определяет, когда и как проводить деплой. После каждого деплоя тимлид (или член команды) должен уведомить заказчика об этом. А также сменить статусы для задач, на готово к тестированию на дев/прод.
• Каждый день в одно и то же время (у нас это в 12.00) мы проводим митинг между всеми членами команды
• Каждый на митинге отчитывается, включая тимлида, что он сделал вчера, что планирует делать сегодня. Что не получается и почему. Таким образом вся команда в курсе того, кто чем занимается и на каком этапе находится проект. Это дает нам возможность спрогнозировать и откорректировать, если нужно, наши эстимейты и дедлайны.
• На митинге тимлид также озвучивает об всех изменениях в проекте и об уровне текущих багов, которые были найдены не заказчиком. Все баги разбираются и назначаются на каждого члена команды для их решения.
• На митинге тимлид назначает на каждого задачи, учитывая текущую загруженность разработчиков, уровень их профессиональной подготовки, а также с учетом близости той или иной задачи к тому, чем занимается разработчик в данный момент.
• На митинге тимлид вырабатывает общую стратегию по архитектуре и бизнес логике. После чего вся команда это обсуждает и принимает решение о внесении коррективов или принятии данной стратегии.
• Каждый разработчик пишет код и строит алгоритмы самостоятельно в рамках единой архитектуры и бизнес логики. Каждый может выразить свое видение реализации, но насильно никто никого не заставляет делать только так, а не иначе. Каждое решение аргументируется. Если есть лучшее решение, но сейчас нет на него времени, то создается таска в жире, на будущий рефакторинг определенной части кода.
• Когда разработчик взял в работу задачу, он переводит ее в статус разработки. Вся коммуникация по поводу уточнения задачи у заказчика ложится на плечи разработчика. Вопросы технического плана можно задавать тимлиду или коллегам.
• Если разработчику не понятна суть задачи, а заказчик не смог толково ее разъяснить, то он приступает к следующей задаче. А текущую забирает тимлид и сам обсуждает ее с заказчиком.
• Каждый день разработчик должен в чате клиента писать о том, над какими задачами он работал вчера и над какими задачами будет работать сегодня
• Рабочий процесс происходит по скраму. Все разбито на спринты. Каждый спринт длится две недели.
• Спринты создает, наполняет и закрывает тимлид.
• Если проект имеет строгие дедлайны, то стараемся примерно заэстимейтить все таски. И собираем из них спринт. Если заказчик пытается в спринт добавить еще задачи, то мы тогда выставляем приоритеты, и какие-то другие задачи переносим на следующий спринт.

б) Процесс работы с заказчиком

• Каждый разработчик может и должен коммуницировать с заказчиком
• Нельзя заказчику позволять навязывать свои правила игры. Нужно в вежливой и дружелюбной манере дать понять заказчику, что мы специалисты в своем деле, и только мы должны выстраивать процессы работы и вовлекать в них заказчика
• Необходимо, в идеале, прежде чем приступать к реализации какого-либо функционала, создать блок-схему всего логического процесса для фичи (воркфлоу). И отправить ее на подтверждение заказчику. Это касается только сложного и не очевидного функционала, например, платежная система, система уведомлений и т.д. Это позволит более точно понять, что именно нужно заказчику, сохранить документацию к фиче, а также застраховать себя от того, что заказчик может в будущем сказать, что мы сделали не то, что он просил.
• Все диаграммы/блок-схемы/логику и т.д. мы сохраняем в Конфлюенсе/Жире, где просим заказчика в комментариях подтвердить правильность будущей реализации.
• Мы стараемся не грузить заказчика техническими подробностями. Если нам нужно понимание того, как заказчик хочет, то рисуем примитивные алгоритмы в виде блок-схемы, которые заказчик может понять и сам все исправить/доработать.
• Если заказчик находит баг в проекте, то мы просим очень подробно расписать его в Жире. При каких обстоятельствах он произошел, когда, какую последовательность действий осуществлял заказчик при тестировании. Просим прикреплять скриншоты.
• Мы стараемся каждый день, максимум через день делать деплой на дев сервер. Заказчик тогда начинает тестировать функционал и проект не простаивает. При этом это является маркером для заказчика, что проект находится в полной разработке и никто не рассказывает ему сказки.
• Очень часто бывает так, что заказчик не до конца понимает, что ему вообще нужно. Так как создает новый для себя бизнес, с еще не отлаженными процессами. Поэтому очень частым случаем бывает ситуация, когда мы выбрасываем в мусорник целые куски кода и перекраиваем логику приложения. Из этого вытекает, что не стоит абсолютно все покрывать тестами. Есть смысл покрывать тестами только критически важный функционал и то с оговорками.
• Бывают ситуации, когда команда понимает, что мы не вписываемся в дедлайны. Тогда мы проводим быстрый аудит по задачам, и тут же сообщаем об этом заказчику. В качестве выхода из ситуации мы предлагаем запускать в срок важный и критический функционал, а остальное оставить на пострелиз.
• Если заказчик начинает придумывать разные задачи из головы, начинает фантазировать и объяснять на пальцах, то мы просим его предоставить нам макет страницы и флоу с логикой, которая должна полностью описать поведение всего макета и его элементов.
• Перед тем, как взять в работу любую задачу, мы должны удостоверится, что эта фича входила в условия нашего договора/контракта. Если это новая фича, которая выходит за пределы наших первоначальных договоренностей, то мы обязательно должны заэстимейтить эту фичу ((примерное время выполнения + 30%) х 2) и указать заказчику, что у нас уйдет столько-то времени на нее, плюс дедлайн смещается на время эстимейта помноженное на два. Сделаем задачу быстрее — замечательно, все от этого только выиграют. Если нет, то мы подстраховались.

в) Что мы не приемлем в команде:

• Необязательность, несобранность, забывчивость
• „Кормление завтраками“. Если не можешь выполнить задачу, не знаешь как, то об этом нужно тут же уведомлять тимлида, а не ждать до последнего.
• Бровады и похвальбы от человека, который не доказал еще делом свои возможности и профессионализм. Если доказал, то можно, в рамках приличия :)
• Обман в любых его проявлениях. Если задача не выполнена, то не стоит менять ее статус на выполненную и писать в чате клиента, что она готова. Сломался компьютер, слетела система, собака погрызла ноутбук — все это недопустимо. Если происходит реальный форс-мажор, то тимлид тут же должен быть уведомлен.
• Когда специалист все время в офлайне и к нему сложно достучаться в рабочее время.
• Токсичность в команде не допускается! Если кто-то с чем-то не согласен, то все вместе собираются на митинг и это обсуждают и решают.

---

И еще ряд вопросов/тезисов, которые я иногда задаю своему заказчику, чтобы снять все недопонимания:

1. Какие у вас критерии качества?
2. Как вы определяете есть ли в проекте проблемы или нет?
3. Нарушая все наши рекомендации и советы по изменению/улучшению системы, все риски несете только вы
4. Любые мажорные изменения проекта (например, всевозможные экста флоу) будут приводить к возможному появлению багов (которые мы будем, естественно, фиксить)
5. Невозможно в течении пары минут понять, что за проблема произошла на проекте, а тем более тут же ее пофиксить
6. Мы работаем по конкретному продукт флоу (Таски в Жира — Разработка — Тестирование — Деплой ). А значит мы не может реагировать на весь поток просьб и жалоб в чате
7. Программисты являются именно программистами, а не профессиональными тестировщиками, и не могут обеспечить надлежащее качество тестирования проекта
8. Ответственность за конечное тестирование и прием задач на проде лежит полностью на вас
9. Если мы уже взяли в работу задачу, то не можем сразу же переключаться на другие, пока не доделаем текущую (иначе это приводит к еще большим багам и увеличению времени разработки)
10. Людей в команде стало меньше (по причине отпусков или болезней), а работы стало больше и мы физически не успеем реагировать на все, что вы хотите
11. Просьба с вашей стороны сделать деплой на прод без протестированных задач на деве — это только ваши риски, а не разработчиков
12. Когда вы ставите нечеткие задачи, без корректного флоу, без макетов дизайна, то это требуюет от нас намного больших усилий и сроков реализации, так как нам вместо вас приходиться делать дополнительный объем работы
13. Любые таски по багам, без детального описания их возникновения и скриншотов, не дают нам возможности понять, что пошло не так, и как нам сэмитировать этот баг
14. Проект требует постоянной доработки и улучшений для повышения производительности и безопасности. Поэтому команда тратит часть своего времени на эти улучшения
15. По причине того, что у нас бывают переработки по часам (срочные фиксы), то мы должны их компенсировать в другие дни

Как правило, заказчик сразу понимает, что не так все просто в разработке софта, и одного желания тут явно недостаточно.

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

P. S. Хочу уточнить, что на нашей стороне проджект менеджера нет. Он есть на стороне заказчика. Совсем не технарь. Проект европейский. Вся коммуникация только на английском.

Всем удачи на проектах. Не выгорайте и постарайтесь улучшать свои процессы.

Исходник в моем блоге.