Менеджмент цифрового продукта. От идеи до идеала

2. Техническая – создается в процессе разработки для осуществления и повышения ее эффективности. Используется разработчиками продукта и другими разработчиками и участниками. Можно выделить нормативную техническую документацию, которая создается для получения сертификатов соответствия, аудита и прочего.

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

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

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

Далее приведены различные способы сокращения разных типов документации.

1. Сокращение горизонта планирования, покрытого документацией. Как уже говорилось ранее, чем больше срок планирования, тем больше вероятность, что часть планов будет не реализована. От 20 до 40 % годичных стратегических планов теряют актуальность, например, в связи с изменением технологического, бизнес- или регулярного ландшафта. Еще 20–30 % не реализуется по причине ошибок прогнозирования и культа амбициозности. Следовательно, чем меньше горизонт планирования, тем меньше вероятности сделать лишнюю работу.

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

3. Использование формата пользовательских историй при описании функциональных требований. Формат пользовательских историй (можно услышать юзерстори) позволяет описывать функциональность системы от лица пользователя. Это дает возможность бизнес-заказчику фокусироваться на финальном артефакте и оставлять промежуточные на усмотрение команды разработки. Формат отвечает на вопрос «что нужно сделать» и позволяет ответить на вопрос «как это сделать» разработчикам, выбирая при этом оптимальные способы и инструменты. (Подробнее о формате пользовательской истории см. в п. 3.2.4.1.)

Сокращение объема технической документации

1. Автоматически генерируемая документация. Нужно отдавать предпочтение решениям, которые позволяют генерировать документацию автоматически на основе структур кода. Например, фреймворк разработки[28] типа FastAPI позволяет из коробки автоматически генерировать документацию для интеграции потребителями сервиса. С появлением больших языковых моделей[29] набирает популярность генерация документации на основе ИИ. Например, GitHub Copilot экономит время разработчиков на описание кода, отправляемого в репозиторий.

2. Pull-документация. Тут применяется принцип втягивания вместо вталкивания. Часто бывает, что документация пишется про запас, и, если сделать замеры, можно увидеть, что часть документов генерируется впустую. Принцип вытягивания подразумевает, что документация генерируется по запросу. При этом современная документация – это не обязательно текст. Более эффективно и наглядно по времени может быть записать скринкаст[30] с объяснением голосом. Потом такое видео добавляется в базу знаний и отправляется по запросу. Подход втягивания имеет еще и культурно-оздоравлива-ющий эффект – разработчики начинают больше общаться и помогать новичкам вливаться, что отличается от культуры выталкивания, в которой новичка могут отправить штудировать обширную базу документов о продукте. Разумеется, принцип pull-документации нельзя использовать повсеместно, например для нормативной документации, создаваемой по требованиям стандартов. Но само движение в сторону перевода генерации артефактов от выталкивания к втягиванию позволит значительно оптимизировать процесс и сделать деятельность сотрудников более содержательной и осмысленной.

3.1.1.3. Реагирование на изменения важнее следования плану