Как настроить процессы документирования в продуктовой разработке
О процессах в продуктовой разработке написано достаточно много статей и книг. Меньше информации о том, как в эти процессы встраивать специалистов, которые участвуют в создании контента для продукта, в частности, интерфейсных текстов и продуктовой документации. На определенном этапе развития компании инстинктивно понимают, что есть потребность в отдельных технических писателях/копирайтерах/DocOps-инженерах, но не всегда могут уверенно сказать, как и на каких этапах разработки они должны взаимодействовать с продуктовыми командами и должен ли существовать выделенный отдел документирования.
В этой статье я расскажу, как построить процессы документирования с продуктовыми командами, которые работают по гибким методологиям (Scrum, Kanban). От чего отталкиваться, какие процессные модели можно использовать, если у вас небольшой отдел документирования из 2–3 человек или большая команда, которая включает в себя не только технических писателей, но и других специалистов, например, переводчиков-копирайтеров и DocOps-инженеров. Надеюсь, что наш опыт будет полезен тимлидам/техлидам, Scrum-мастерам, техническим писателям, разработчикам и всем, кто так или иначе сталкивается в работе с техническим документированием.
Minimal but sufficient
Один из принципов Agile-манифеста — “работающий продукт важнее исчерпывающей документации”. Неверная трактовка этого принципа приводит к тому, что ценность продуктовой документации воспринимается ниже, чем ценность доставки фичей, поэтому задачи по документации часто имеют низкий приоритет. Создается разрыв между текущим состоянием продукта и его описанием. Потенциально это может привести к упущенной выгоде, так как клиенты не знают о новых фичах или важных изменениях в продукте, которые могут повлиять на интеграцию. Или к увеличению операционных издержек — поток однотипных вопросов создает дополнительную нагрузку на техническую поддержку и другие отделы, работающие с потенциальными и текущими клиентами.
Как адаптировать процессы документирования к особенностям гибких методологий, чтобы сократить разрыв между фокусом на быстрое получение обратной связи и покрытием фичей документацией? Достаточно подробно этот вопрос раскрывается в статье Agile/Lean Documentation: Strategies for Agile Software Development, но мы можем выделить основные моменты, которые стоит учитывать:
- Разрабатывайте только ту документацию, которой будут пользоваться. Не тратьте время на создание документации “в стол”.
- Работайте с документацией так же, как с продуктом — создавайте минимальную, но необходимую документацию, получайте обратную связь и итеративно дорабатывайте. Или включите разработку документации в Definition of Done, чтобы она стала частью доставляемой ценности.
- Используйте Agile-практики, чтобы сделать процессы документирования более гибкими.
Посмотрим, как эти подходы проявляются в различных процессных моделях, которые можно использовать при построении взаимодействия между участниками процесса документирования.
Процессные модели документирования
Процессные модели документирования основаны на способе взаимодействия специалистов-носителей компетенций документирования с продуктовой командой. При выборе модели стоит учитывать следующие критерии:
- сколько технических писателей в компании;
- сколько продуктовых команд приходится на одного технического писателя;
- есть ли выделенный отдел документирования (функциональная команда);
- как публикуется документация по продукту или продуктам, если их несколько — на единой платформе или независимо, но, например, с соблюдением общего корпоративного стиля.
В зависимости от критериев, можно выделить следующие модели:
- Doc as a Service — компетенции документирования в отдельной функциональной команде
- Doc as a Part of Development Team — компетенции документирования в команде разработки
- Hybrid — модель, которая сочетает в себе особенности первых двух
С развитием процессов документирования и разработки в компании, модели могут сменять друг друга. В конкретный период времени может использоваться та модель, которая лучше всего адаптируется к текущему уровню развития процессов разработки.
Doc as a Service
Модель Doc as a Service предполагает наличие отдельной функциональной команды, в которой есть компетенции документирования. Кроме технических писателей, в такую команду также могут входить переводчики, копирайтеры, менеджеры по локализации, DocOps-инженеры. Модель хорошо работает:
- при небольшом количестве продуктовых команд и небольшом размере самой функциональной команды (например, на начальном этапе развития процессов документирования, когда в компании есть только один технический писатель и 2–3 продуктовые команды);
- если у продуктовых команд есть потребность в документации или интерфейсных текстах, но нет достаточного объема задач, чтобы загрузить специалистов на full-time.
Сама команда документирования может работать и по Scrum, и по Kanban. Прозрачность процесса для продуктовых команд обеспечивается за счет визуализации текущей работы в таск-трекере (например, на доске Jira) и дополнительной коммуникации (например, периодические встречи или чат).
Плюсы модели:
- Есть общие правила и договоренности, например, стайлгайд или внутрикомандные и межкомандные процессы
- Члены функциональной команды более тесно взаимодействуют друг с другом, более активно обмениваются знаниями и практиками
- Есть возможность уделять время развитию инструментов и процессов документирования — часть рабочего времени, например, 30%, выделяется на задачи, которые направлены на автоматизацию рутинных процессов, повышение качества и скорости выполнения задач
- Члены функциональной команды более универсальны, могут работать на несколько команд и при необходимости заменять друг друга, например, на время отпуска или больничного
Минусы модели:
- Слабая погруженность членов функциональной команды в продукт
- Недостаточная прозрачность работы по задачам документирования для команды разработки
- Документация не воспринимается как важная часть продукта
Doc as a Part of Development Team
При использовании модели Doc as a Part of Development Team компетенции документирования находятся внутри продуктовой команды. В зависимости от потребностей команды и объема работ, в нее могут входить технические писатели, переводчики-копирайтеры, менеджеры по локализации, переводчики, DocOps-инженеры. Модель хорошо работает:
- если у продуктовой команды есть потребность в документации или вычитке/локализации интерфейсных текстов и достаточный объем задач, чтобы загрузить специалистов на full-time;
- для зрелых Scrum-команд, которые стремятся к максимальной автономности и кросс-функциональности.
Специалисты документирования, работающие только с одной командой, могут работать внутри спринтов команды или в отдельном спринте/на отдельной Kanban-доске. Прозрачность процесса обеспечивается за счет визуализации текущей работы в таск-трекере в виде отдельных задач, подзадач или статусов и участия во всех Scrum-ритуалах команды.
Плюсы модели:
- Работа специалиста документирования прозрачна для команды разработки, так как он участвует во всех ритуалах
- Специалист документирования — равноправный член команды, он глубже погружен в продукт, знает его лучше и может предлагать идеи для улучшения
- Роль документации воспринимается командой разработки как более важная
Минусы модели:
- Сложнее соблюдать общие правила и договоренности между специалистами документирования разных команд, что может привести к неконсистентности документации, особенно если она публикуется на единой платформе
- Специалисты документирования не могут друг друга заменять на время отпуска или больничного, что может влиять на bus factor
- Сложнее находить возможность уделять время развитию платформы и процессов документирования
- Сложнее считать метрики документирования
Отдельные минусы модели можно нивелировать за счет создания гильдии или передачи части компетенций другим членам продуктовой команды для увеличения bus factor. В книге M. Nispel. Creating Documentation in an Agile Scrum Environment также приводится несколько методик, которые позволяют построить процессы документирования параллельно с разработкой — Sprint behind with a related story, Same sprint with a related story, Same sprint and story.
Hybrid Model
Гибридная модель сочетает в себе особенности первых двух моделей:
- В компании есть отдельная функциональная команда с компетенциями документирования
- Специалисты документирования работают только с закрепленными за ними командами
Модель хорошо работает в смешанных средах:
- при большом количестве продуктовых команд и большом размере самой функциональной команды;
- если у отдельных продуктовых команд есть потребность в документации или вычитке/локализации интерфейсных текстов и есть достаточный объем задач, чтобы загрузить специалистов на full-time.
При гибридной модели возможны разные варианты настройки процессов, так как, с одной стороны, учитываются специфика работы и потребности отдельных продуктовых команд, с другой стороны, уделяется время развитию функциональной команды. Это позволяет держать качество и скорость выполнения задач на необходимом уровне, а также периодически пересматривать распределение ресурсов и адаптироваться к масштабированию продуктовых команд.
Плюсы модели:
- Есть общие правила и договоренности, например, стайлгайд или внутрикомандные и межкомандные процессы
- Члены функциональной команды более тесно взаимодействуют друг с другом, более активно обмениваются знаниями и практиками
- Есть возможность уделять время развитию платформы и процессов документирования — часть рабочего времени, например, 30%, выделяется на задачи, которые направлены на автоматизацию рутинных процессов, повышение качества и скорости выполнения задач
- Работа специалиста документирования прозрачна для команды разработки
- Специалист документирования глубже погружен в продукт, знает его лучше и может предлагать идеи для улучшения
Минусы модели:
- Для активного обмена знаниями и практиками требуется участие функциональной команды в дополнительных ритуалах, например, встречи гильдии
- Возрастает сложность процессов межкомандного взаимодействия
- Специалисты документирования не могут друг друга заменять на время отпуска или больничного, что может влиять на bus factor
- Риск перегруза при работе с несколькими командами
На текущем этапе развития процессов в компании мы пришли к использованию гибридной модели. Отдел документирования состоит из семи технических писателей, трех копирайтеров-переводчиков и одного DocOps-инженера. Один технический писатель работает с 1–3 командами, один переводчик-копирайтер — с 2–6 командами, DocOps-инженер работает как с отдельными запросами продуктовых команд, так и с запросами специалистов документирования.
Команда документирования работает по Kanban. Прозрачность процесса для продуктовых команд обеспечивается за счет визуализации текущей работы на доске Jira и дополнительной коммуникации (периодические встречи или чат). Каждый технический писатель и переводчик-копирайтер поддерживает процессы в команде самостоятельно, но есть общие правила и договоренности, которые являются базой для построения этих процессов и дополняются или видоизменяются с учетом специфики команд.
Мы также используем несколько дополнительных ритуалов:
- DOC Sync в начале спринтов продуктовых команд, чтобы обменяться новостями, подсветить зависимости и верхнеуровнево спланировать релизы, так как мы используем одну платформу для публикации документации
- DOC гильдия раз в две недели для обмена знаниями и практиками
- DOC Demo раз в две недели, в конце спринтов продуктовых команд, чтобы обменяться новостями, которые касаются внутренних изменений в процессах и инструментах
- DOC Retro раз в две недели, в конце спринтов продуктовых команд, чтобы обсудить, что было хорошо, а что можно улучшить в процессах
Выводы
Процессные модели помогают построить прозрачные процессы документирования в гибкой разработке с учетом различных условий. Вы можете использовать их как основу и адаптировать под специфику своей компании. Важным моментом в успешном построении процессов также является следование принципам Agile не только в продуктовой команде, но и в функциональной команде документирования. Ниже приведены основные моменты, которые стоит учитывать специалистам документирования при работе в Agile-среде.
