Документация проекта: на страже порядка

Документация проекта: на страже порядка

Когда речь заходит о документации проекта, все сходятся во мнении, что она крайне важна, нужна и вообще «да-да, мы её ведём». Но, как показывает практика, далеко не все компании (и это касается не только маленьких операторов, но и довольно крупных брендов, названия которых часто на слуху) не уделяют документации достаточное количество времени.

В этом посте поделимся субъективным взглядом на важность документации для iGaming-бренда.

Централизованность

Над проектом работает большое количество команд, и у каждой есть свои отдельные спейсы, таблицы, доски и т.д. Это абсолютно нормально. Но при этом должен существовать один главный документ (условно — «мастер-документ»), который будет сердцем всей системы.

В нём должна храниться основная информация по проекту, а к нему уже могут быть привязаны расчёты и дополнительные материалы других команд. Если iPM хочет узнать базовую информацию по колесу фортуны — он заходит в соответствующий раздел документа и видит всё необходимое. Если нужно понять, с какой вероятностью выпадает топ-3 по стоимости подарок в колесе — он может перейти по ссылке и углубиться в расчёты.

Отсутствие мастер-документа приводит к тому, что информация по проекту разбросана в разных местах. Чтобы её найти, приходится проходить «миллион» чатов в Slack с вопросом: «А ты не в курсе, где лежит вот эта инфа?»

Онбординг

Онбординг — сам по себе стрессовый процесс. А если проект большой и в нём нет внятной продуктовой документации, знакомство с продуктом превращается во фрустрирующий квест.

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

Минимум догадок — максимум фактов

Отсутствие документации приводит к тому, что любая информация о продукте начинает строиться на догадках:

• «Я не знаю, но, скорее всего, знает вот он»
• «Я уже точно не помню, но вроде мы приняли такое решение, потому что…»

В итоге управление продуктом усложняется, решения принимаются дольше, чем нужно, доходы не растут (или даже падают — потому что что-то сломалось, а никто не знает, как это изначально должно было работать).

Документация — это фундамент сильной операционной составляющей. Да, вы всё равно завязаны на конкретных исполнителях и их опыте. Но если такой исполнитель уйдёт, при наличии сильной документации будет гораздо легче перехватить его зону ответственности и постепенно ввести нового человека.

Снежный ком

Большинство понимает важность документации, но во многих компаниях она всё равно страдает. Основная причина — эффект снежного кома.

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

Наш подход

Далее — о том, как мы стараемся выстраивать работу с мастер-документом.

Целевой пользователь документа — любой представитель команды проекта. Главная цель — сделать проект понятным и управляемым.

1. Читабельность. Каждый раздел мастер-документа должен быть понятным и легко читаемым. Мы стараемся тезисно описывать ключевые моменты и прикреплять дополнительные таблицы, если может возникнуть необходимость углубиться в детали.
2. Зоны ответственности. Мастер-документ разделён между командами. У каждой есть свой блок, который она обязана вести. В каждом блоке всегда указан ответственный за модуль.
3. Системность. Как описано выше, ведение документа — обязательная часть работы, а не опциональная активность «по остаточному принципу».
4. Обратная связь. Раз в квартал мы проводим кросс-командный митинг, посвящённый исключительно мастер-документу. Его цель — «причесать» документ, обсудить улучшения подхода к его ведению и при необходимости добавить новые разделы.

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