Договоренности команды перед разработкой

Зачем это фиксировать

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

Хорошая договоренность делает работу проще. Плохая договоренность превращается в отдельный процесс, который никто не хочет поддерживать.

Когда это продолжает roadmap тимлида

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

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

Так roadmap перестает быть списком долгов тимлида и становится инструментом изменения системы работы.

Минимальный набор

Для команды разработки полезно явно договориться о пяти вещах:

• как задача попадает в работу;
• что должно быть понятно до старта;
• где фиксируются решения и изменения;
• как поднимаются риски;
• что считается готовым результатом.

Этого достаточно для первого устойчивого контура. Остальное стоит добавлять только после того, как появляется реальная боль.

1. Вход в разработку

Перед стартом задачи команда должна понимать:

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

Если вход в разработку не определен, тимлид часто становится единственным маршрутизатором всех вопросов. Это плохо масштабируется и создает лишние задержки.

2. Готовность задачи

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

Минимум:

• цель;
• основной сценарий;
• ограничения;
• данные и владельцы;
• критерии приемки;
• известные риски;
• открытые вопросы.

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

3. Фиксация решений

Устное решение удобно сегодня и дорого через месяц. Команде нужна легкая форма записи:

• что решили;
• почему выбрали именно так;
• какие варианты отклонили;
• какие последствия приняли;
• когда решение нужно пересмотреть.

Для небольшого решения достаточно комментария в задаче. Для решения, которое влияет на архитектуру, процесс, API или несколько команд, лучше сделать отдельную короткую запись.

4. Риски и эскалация

Риск нужно поднимать до того, как он стал пожаром. Для этого команда должна договориться:

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

Хороший сигнал: разработчик или аналитик может сказать “здесь нужна проверка гипотезы” без ощущения, что он тормозит работу.

5. Изменения в процессе

Процесс не должен быть неподвижным. Но изменение процесса тоже должно быть явным:

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

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

Формат на одну карточку

Для начала достаточно короткой карточки в командной базе знаний:

1. Контекст: почему договоренность нужна.
2. Правило: что делаем теперь.
3. Граница: к каким задачам это относится.
4. Исключения: когда можно действовать иначе.
5. Ответственный: кто поддерживает договоренность.
6. Проверка: когда смотрим, работает ли это.

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

Рабочий шаблон договоренности

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

Название.

Как команда называет договоренность.

Пример: “Задача не уходит в разработку без критерия готовности”.

Контекст.

Какая повторяющаяся проблема появилась и почему ее нельзя больше оставлять в устной договоренности.

Правило.

Что команда теперь делает одинаково.

Формулировка должна отвечать на вопрос: “Как поступаем в следующий раз?”

Граница применения.

К каким задачам договоренность относится:

• все задачи;
• только интеграции;
• задачи с несколькими командами;
• задачи с чувствительными данными;
• задачи с жестким сроком;
• только крупные изменения.

Сигнал тревоги.

По каким признакам команда понимает, что договоренность нужно применить.

Пример: “В задаче есть внешний сервис, но не названы статусы ошибок и правила повторного запроса”.

Ответственный.

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

Проверка.

Когда команда вернется к договоренности и решит, помогает она или только создает лишнюю работу.

Минимальный формат:

• что стало понятнее;
• где договоренность сработала;
• где она мешала;
• что меняем в следующей итерации.

Связанные артефакты.

Что нужно открыть рядом:

• чеклист готовности задачи;
• risk-review;
• запись решения;
• критерии приемки;
• API-контракт или схема данных.

Антипаттерны

Стоит насторожиться, если:

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

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