Недавно посмотрел лекцию Яндекса для продактов (скидывать не буду — для аналитиков там пользы мало и идёт еще 2ч). Но были хорошие тейки в защиту документации, и я понял, что пост "Как выглядит хорошая документация?" можно раскрыть еще больше.

Что дает хорошая документация?👍 👆 Ускоряет тайм-ту-маркет Разработчики сразу понимают, что и как делать, а не пишут тебе с «Блииииин, а давай созвонимся, я не поняль».

👆Бизнес🤝разработка Бэклог приоритизируется легче: понятно, сколько стоит фича и какую пользу приносит.

👆**Гарантирует согласованность на всех платформах Никаких «на iOS работает так, на Android эдак, а на Web вообще по-другому».

👆Экономит время** Избавляет от повторяющихся вопросов и 100500 переписок с разработчиками и стейкхолдерами — вся нужная информация уже собрана в одном месте.

Что будет, если документации нет или она плохая?😭 🤯Исправление косяков после релиза Фичи выходят с багами, потому что изначально требования были неясными. Приходится дорабатывать и выкатывать повторно.

🤯**Бесконечные переписки Разработчики и стейкхолдеры задают одни и те же вопросы, а информацию приходится вылавливать по чатам и задачам.

🤯Размытые цели** Аналитику приходится по сто раз объяснять одни и те же вещи разным людям.

🤯**Низкий приоритет важных задач Бизнес не видит ценности — важная задача пылится в бэклоге, а потом её и вовсе срезают.

Когда нужно начинать писать документацию? Сразу. Как только пришла задача, даже если это всего два-три предложения. Лучше создать страницу и зафиксировать мысли, чем потом по крупицам вспоминать, что вообще обсуждали.

Как часто нужно обновлять документацию? Краткий ответ — всегда.

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

А как у вас с этим? Всё чётко, или тоже бывает, что бизнес говорит одно, разработка делает другое, а в итоге выходит третье?**🔥

IT АНАЛитика