Привет! Меня зовут Максим Павлов, я управляющий партнёр KTS и отвечаю за направление системной и бизнес-аналитики.
Подготовка документации — дело затратное. Прежде чем приступать к ней, нужно подумать, действительно ли она нужна, или это делается, потому что «так принято».
Сегодня я подробно остановлюсь на ситуациях, когда написать ее необходимо. Если в одной из них вы узнаете свой проект, документация сильно поможет в его реализации.
Обратите внимание, что речь пойдет не о документировании кода и не пользовательской документации, а обо всех остальных ее видах.
Содержание:
Когда пора писать документацию
Бурный найм или ротация специалистов
Большая команда
Завершение работы над большим блоком и пауза по проекту
Когда писать документацию рано
Проект или модуль проекта часто переделывается
Когда определенная фича или большой раздел находится на этапе проверки гипотезы
Когда продукт еще не запущен
В сухом остатке
Когда пора писать документацию
Бурный найм или ротация специалистов
Ротация может быть между разными проектами компании, либо между блоками одного большого проекта.
Как правило, подключение новых специалистов необходимо при активном росте продукта, когда текущей скорости команды не хватает. Документация по проектам, над которыми работает команда, позволяет быстро провести онбординг новых специалистов, которые присоединяются к разработке продуктов.
Если документации нет, новые ребята начинают приходить с вопросами к более опытным. Получается парадокс: человек, которого брали в команду, чтобы ускорить работу, наоборот, замедляет ее. И чем больше таких новичков, тем больше вопросов. С документацией новые специалисты быстрее начнут приносить пользу.
Большая команда
Если над проектом работает, допустим, от 3-4 человек на каждой платформе, например на фронтенде, может получиться так, что кто-то из них вообще не прикоснется к коду определенного модуля.
Если одному разработчику придется что-то исправлять или дорабатывать в незнакомом разделе, с актуальной документацией его шансы успешно сделать это самостоятельно резко возрастают. В противном случае может получиться так, что вся команда будет ждать специалиста, который как бы отвечает за эту часть проекта, либо отвлекать его от текущих задач.
Завершение работы над большим блоком и пауза по проекту
Это могут быть цикличные проекты, над которыми команда работает с определенной периодичностью, или просто некий проект, поставленный на холд.
Здесь у команды KTS есть живой пример — личный кабинет для сотрудников Х5 Retail Group, в котором есть модуль ежегодного планирования отпусков. Этот процесс каждый год начинается в октябре и кончается в декабре, и каждый год наши ребята его оптимизируют на основе фидбэка пользователей и HR-специалистов заказчика.
Мы понимаем, что заниматься этим проектом зимой-весной мы не будем – работа по нему начнется в августе-сентябре. В таких случаях важно после каждого завершения работ по проекту описать актуальную документацию по доработанному блоку, чтобы максимально упростить процесс возвращения к этой задаче.
Когда писать документацию рано
Вот мини-чеклист кейсов, когда она точно не нужна:
Проект или модуль проекта часто переделывается
Точно не нужно писать документацию, когда проект находится на этапе постоянных корректировок и изменений. Речь идет не о дополнениях функционала, а о серьезном изменении частей проекта.
В таких случаях уже готовую документацию придется постоянно менять, и бизнес-эффекта на этой стадии от нее будет меньше, чем оверхеда от ее ведения и оформления.
Когда определенная фича или большой раздел находится на этапе проверки гипотезы
Любая фича может как выстрелить, так и показать отрицательный результат после тестирования на пользователях. Если мы изначально понимаем, что можем ее выкинуть, если она не взлетит, то до подтверждения ее жизнеспособности документация не нужна.
Когда продукт еще не запущен
«Работающий продукт важнее исчерпывающей документации», — гласит один из пунктов Agile-манифеста.
Запустить продукт и не иметь документации лучше, чем не запустить продукт, но иметь исчерпывающую документацию.
Это утверждение не касается проектов, связанных с жизнью и здоровьем людей, где риск ошибки очень велик. Но для остальных кейсов это справедливо.
В сухом остатке
Проектная документация — это всегда компромисс. Даже с учетом описанных выше критериев, нужно принимать решение не исходя из каких-то постулатов, а оценив, насколько эффект от написания документации нужного уровня детализации сопоставим с объемом вложений в этот процесс.
В следующей статье я остановлюсь на более глобальном вопросе: стоит ли писать документацию вообще?
Другие статьи по менеджменту и аналитике:
Инструкция для менеджеров и руководителей по реанимации запущенного проекта
Как менеджеру понять, что на проекте нужен аналитик
6 ошибок, из-за которых менеджеры-джуны остаются джунами
