Как продуктовая документация сокращает Time-to-Market?

Проблематика

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

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

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

В конечном итоге страдали ключевые метрики производительности:

• Velocity (непосредственно производительность команд).
  
• Predictability (предсказуемость работы команд).
  
• Time to Market (время до выхода на рынок).

Time to Market является одним из ключевых показателей в работе продакт-менеджера. Он оказывает влияние на ту ценность, которую продакт приносит компании: чем скорее новая функциональность окажется в production, тем раньше компания начнет получать дополнительные деньги.

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

Роль продуктовой документации

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

Основные задачи, которые было важно выполнить с помощью продуктовой документации, следующие:

• Зафиксировать формат описания функциональных требований и ожиданий от продукта. Стремились к тому, чтобы спецификации требований четко описывали, что продукт должен выполнять, какие проблемы решать и каким критериям качества отвечать. Это обеспечивало бы основу для всех этапов разработки и тестирования.
  
• Обеспечить четкое техническое понимание продукта коллегами. Цель была в том, чтобы документация служила для детального описания архитектуры, кода, API и процессов эксплуатации продукта, что является критически важным для внутренней координации между разработчиками, тестировщиками и системными архитекторами.
  
• Облегчить обслуживание и поддержку продукта. Хотели, чтобы руководства по обслуживанию, документация по устранению неполадок и процедуры обновления продукта направлялись на обеспечение его долгосрочной стабильности и надежности, а также на снижение времени и ресурсов, необходимых для поддержки.

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

1. Повышение эффективности использования продукта пользователями. Руководства и FAQ предназначены для облегчения установки, настройки и эксплуатации продукта конечными пользователями, минимизируя необходимость в обращениях к службе поддержки. 
2. Поддержка маркетинговых и продажных усилий. Документы, ориентированные на маркетинг и продажи, предоставляют информацию о преимуществах продукта, его функциях и конкурентных преимуществах, помогая формировать эффективные стратегии продвижения и коммуникации с потенциальными клиентами.

Важно, чтобы все эти задачи выполнял один единый документ.

Процесс разработки и поддержки продуктовой документации из моего опыта

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

Потребовалось учесть несколько этапов: Discovery, Delivery и Support:

• Discovery — это этап продуктовой работы, включающий в себя исследования, создание продуктовых артефактов, таких как User Story Map и Road Map, и подготовку документации для определения целей и задач продукта. 

• Delivery — это этап разработки продукта, включающий в себя технический аудит, подготовку архитектуры и кода, процессы развертывания и поддержки. Здесь создается техническая документация, объясняющая, как работает продукт. 

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

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

В конце концов был создан единый формат PRD (Product Requirements Document, или документ, описывающий требования к продукту).

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

Мои критерии выбора к wiki-системе для ведения документации

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

Хорошая wiki-система должна отвечать следующим требованиям:

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

В нашем случае для документации используются Confluence и Notion. Но также есть и другие варианты — подбирайте те, что подходят под необходимые вам критерии.

Интеграция процессов документирования в жизненный цикл продукта

Далее необходимо приложить значительные усилия, чтобы написание и поддержка документации стали неотъемлемой частью производственного процесса. Было принято решение использовать DOR (Definition of Ready – критерии готовности) и DOD (Definition of Done – критерии приемки) для каждого этапа жизненного цикла продукта. Эти инструменты помогают гарантировать, что документация станет неотъемлемой частью разработки.

• DOR определяет условия, которые должны быть выполнены перед началом работы над новой задачей или функцией. DOR подразумевает, что команда полностью понимает задачу и имеет все необходимые для ее выполнения ресурсы.
• DOD является набором критериев, которые должны быть выполнены, чтобы задача или функция считалась завершенной. DOD гарантирует, что все работы по этапу выполнены на должном уровне, прежде чем перейти к следующему этапу. 

Для успешной интеграции документации в жизненный цикл продукта, необходимо установить четкие DOR и DOD для каждого этапа — Discovery, Delivery, и Support:

• На этапе Discovery DOD обеспечивает, что вся необходимая предварительная документация создана и одобрена. Это включает в себя исследование рынка, аудиты, пользовательские истории и требования к продукту.
• На этапе Delivery DOR гарантирует, что перед началом разработки доступна вся необходимая техническая спецификация и документация. DOD на этом этапе удостоверяет, что документация актуализирована в соответствии с разработанным продуктом, включая архитектурные решения и технические спецификации.
• На этапе Support DOR подразумевает готовность документации для поддержки и обслуживания продукта, в то время как DOD подтверждает, что все руководства пользователя, процедуры обновления и списки известных проблем обновлены и доступны пользователям и команде поддержки.

Принятие DOR и DOD на каждом из этих этапов делает документацию обязательной частью разработки и поддержки продукта. Эти критерии должны быть четко описаны и включены в описание производственных процессов, которые предоставляются новым сотрудникам в рамках процедуры онбординга. Такой подход гарантирует, что каждый член команды с самого начала осведомлен о требованиях к документированию на всех этапах разработки и поддержки продукта. Это создает общее понимание стандартов качества и обязательных условий для выполнения работ.

Зачастую DOD для одного этапа работы – это DOR для следующего за ним этапа работы. В нашем случае DOD для передачи задачи из Discovery в Delivery в основном требует наличия следующих артефактов:

• краткое описание задачи, включая цели и виденье;
  
• User Story Map, описывающий функциональные требования к продукту или функциональности;
  
• готовые к принятию в работу дизайн-макеты и прототипы в Figma;
  
• гипотезы и дизайн эксперимента, включающий подробное описание, каким образом новый функционал будет влиять на пользовательский опыт;
  
• результаты проведенных исследований, демонстрирующие сигналы жизнеспособности гипотез;
  
• подробный расчет потенциального бизнес-эффекта, получаемого благодаря реализации задачи;
  
• описание отслеживаемых метрик: ключевой, дополнительных и контрольных; - образ результата в формате AS IS и TO BE.

Конечным этапом необходимо обеспечить неизменное выполнение DOR и DOD участниками команд. Для этого DOR и DOD были интегрированы в Jira (система управления задачами, которая используется в компании) таким образом, чтобы задачи, требующие выполнения DOD, не могли быть завершены до выполнения указанного DOD. А задачи, для которых установлен DOR, не могли быть взять в работу до выполнения указанного DOR. Такая интеграция обеспечила автоматизированный контроль за соблюдением процессов документирования.

Таким образом, удалось решить все проблемы, которые негативно влияли на Time to Market. Некоторые рутинные задачи, которые раньше требовали продолжительного времени на повторное погружение, стали выполняться в два раза быстрее. А также на основе существующей документации был создан единый чек-лист, который позволил увеличить эффективность онбординга новых специалистов и сократить необходимое на онбординг время с трех месяцев до одного.

Заключение

В заключение статьи о роли продуктовой документации можно сказать следующее. Продуктовая документация играет важную роль в успехе любого продукта, обеспечивая четкость и эффективность коммуникации между всеми участниками процесса – от разработчиков до конечных пользователей. Она не только способствует более гладкой и предсказуемой разработке, но и улучшает поддержку, обслуживание продукта и пользовательский опыт, тем самым увеличивая удовлетворенность клиентов и лояльность к бренду. Следование лучшим практикам и избегание распространенных ошибок позволит вашей документации оставаться актуальной и эффективной, гарантируя, что ваш продукт будет развиваться и удовлетворять потребности пользователей на протяжении всего времени его существования.