Процесс будет описан так, как это принято в Авито. В других компаниях он может отличаться, так как компании выстраивают внутренние процессы под себя, исходя из практического опыта. Полное описание процесса-TDR читайте в плейбуке компании.

Модель зрелости проектных решений

Рассмотрим упрощенную модель “зрелости” по реализации проектных решений разбитую на 5 уровней:

Уровень 1

  • Пишем код

Уровень 2

  • Пишем код -> Согласовываем

Уровень 3

  • Согласовываем -> Пишем код

Уровень 4

  • Согласовываем -> Пишем код -> Документируем решение

Уровень 5

  • Документируем решение -> Согласовываем -> Пишем код

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

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

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

В погоне за низким TTM часто 5-ый уровень может быть не достижим, так как требует доп. ресурса, и хорошие разработчики вынуждены лавировать между 3 и 4 в зависимости от капасити спринта.

Дизайн ревью

“Документирование решений” и “Согласования” в совокупности образуют процесс под названием “Дизайн ревью” (Design Review), который стал стандартом для разработки любых решений в Биг Техе.

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

Авито тоже не стоит на месте и постоянно оптимизирует свои процессы. Так в компании на смену дорогих архитектурных комитетов пришел Tech Design Review или просто TDR.

Про такой процесс проще всего думать в формате пул-реквеста (или мердж-реквеста) в сервис. Представьте, что вы сделали такой по завершению работы над своей задачей, но вместо кода с новой фичей или багфиксом у вас документ, где описано решение какой-либо технической проблемы, которое затрагивает сразу несколько доменов и потенциально влияет на весь продукт и другие команды. Ревьюеры смотрят код, оставляют комментарии…

Этапы Tech Design Review

В TDR механика абсолютно такая же, а весь процесс состоит из следующих этапов:

1. Обозначаем проблему

TDR не возникает на пустом месте: существует проблема, которую важно решить. Формируем ее. Важно уделить данному этапу должное внимание, чтобы будущие ревьюеры документа поняли необходимость вашего решения.

2. Находим решение

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

3. Собираем вместе

Настало время собрать все воедино. Удобно, когда есть специальный инструмент для этого, предоставляющий шаблон с основными полями. Но, если инструмента нет, то просто собираем по секциям то, что делали раньше:

  • проблема
  • описание решения
  • схема зависимостей
  • компромиссы
  • альтернативы
  • нагрузка и расчеты
  • ресурсы
  • структура баз данных
  • метрики
  • сроки реализации
  • FAQ (вопросы, возникающие по ходу и ответы на них)

Структура выше хорошо ложится на создание нового сервиса. Для прочих решений могут подойти другие шаблоны.

Фактически общая формула такая: проблема -> решение -> обоснование

4. Отдаем в ревью

На этом этапе у нас есть оформленная версия документа (v1.0). Выбираем экспертов, в домене которых будет происходить новая разработка. Чтобы найти экспертов можно задать 2 вопроса:

  • “Кто владелец сервиса, на которое будет оказано влияние?”
  • “Кому потенциально наше решение облегчит или затруднит жизнь?”.

Эксперты выбраны. Отправляем на согласование и ждем.

5. Ревью

Собирается обратная связь от экспертов, автор документа отвечает на вопросы. На этом этапе эксперты должны поставить свою оценку (флаг):

🟢 - вопросов нет

🟡 - есть неблокирующие вопросы, можно начинать разработку

🔴 - такое решение нельзя запускать в прод

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

6. Завершение

В зависимости от статуса на предыдущем шаге возможны варианты, но, если все хорошо, то можно постепенно планировать будущую разработку и приступать к реализации.

Асинхронный формат

Важно отметить, что согласование TDR проводится полностью в асинхронном формате. Это быстро и удобно для всех. Конечно, при необходимости можно организовать встречу, чтобы решить спорные моменты, но это скорее исключение. С таким форматом согласен и Microsoft загляните к ним в плейбук, чтобы узнать подробнее.

Если будете углубляться в тему, то можете столкнуться с ADR (Architecture decision record) - это тоже важный документ, но представляет собой другой процесс - более локальный и применительный к отдельно взятому решению.

Читайте оригинальный пост и присоединяйтесь к обсуждению в Телеграм: @time2code