Про продуктовые команды 🤝
(Часть 6 - Тесное взаимодействие vs Документация)

Бонусом от тесного взаимодействия продакта с командой является отсутствие необходимости в излишней детализации требований. Как детализация является излишней - ситуативно.

Я не верю в идеально проработанные требования. Достаточно детальная и избегающая двусмысленных формулировок документация требует неоправданно много ресурсов на написание и согласование. И чаще она требовалась, чтобы прикрыть зад во времена работы с аутсорсингом по fix price.

При этом (имея опыт работы с 7+ подрядчиками по fix price) я ни разу не встречал такого документа с требованиями, к которому бы не возникало вопросов в процессе разработки. А возникающие вопросы в старой модели взаимотношений "заказчика” и "исполнителя” это приводит к одному из двух сценариев:
✦ "ну тогда сделаю на своё усмотрение" - и будет плохо, потому что, кроме чтения этого документа, я вообще хз что мы делаем
✦ "ваши документы плохие, не могу работать" - постоянные простои в работе и пинг-понг по статусам

А в ситуации, когда команда разработки погружена в контекст, “на своё усмотрение" внезапно оказывается отличной стратегией. Чем больше нейронки команды обучаются принимать правильные решения самостоятельно по обратной связи от продакта, тем меньше потребность в детализации документов. И тем больше продакт мозг продакта освобождается для принятия судьбоносных для продукта решений, вместо расписывания логики работы каждой кнопки.

Казалось бы, проблему можно решить введением роли бизнес-аналитика - продакт описывает требований верхнеуровнево, а аналитик детализирует. Но на практике этот механизм ломается об:
✦ разработчики спихивают принятие даже мелких решений на БА - он становится bottleneck’ом
✦ даже сильно вовлечённый в контекст БА будет отчасти сломанным телефоном - продакту приходится вычитывать все подробности и убеждаться, что его поняли верно
✦ если решать прошлую проблему обсуждениями "всем вместе”, то БА превращается в "писаря" - всё обсудили, все поняли, а Коля зафиксирует

В Сбере и Яндексе требования к подробности документации сильно варьиюруются от команды к команде. Но даже самая подробные из встреченных мной там документов не идут ни в какое сравнение с BRD от бизнес-аналитиков в Ренессанс Кредите, где один только процесс их согласования мог занимать месяцы. (Угадаете, какой в РК был T2M?)

Ещё один бонус от не_слишком детальных требований - их не так обидно отбрасывать, когда выяснится, что задуманное слишком трудоёмко в реализации. А на стадии формирования MVP фичи/продукта стадия потрошения неизбежна.

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

На мой субъективный взгляд, тесное взаимодействие при, всех его недостатках, бьёт детальную документацию, если для бизнеса критична скорость доставки функционала. (А это почти все компании в текущих реалиях.) Естественно, сильно зарегулированные (банки, здравоохранение…) или высоко-рисковые индустрияи (авиация, энергетика…) накладывают свои ограничения - там всё немного иначе.

Делитесь информацией с разработкой, не считайте их просто "руками" - это окупится ростом самостоятельности. 🤓

#product_teams #product_management #documentation