На написание этой короткой заметки меня подтолкнула энтропия - усиливающийся хаос в структуре проектных артефактов. Бессвязное, непоследовательное изложение проектной документации всё чаще становится барьером на пути создания сложных IT-проектов.
Дизайнеры, проектировщики, аналитики, архитекторы и все те, кто участвует в создании цифровых продуктов, зачастую просто переносят результаты своих исследований и измышлений в доки - надеясь при этом, что все остальные мыслят точно так же, как они. Это ощущение, конечно, ошибочно - и даже не стоит объяснять, почему.
Давайте попробуем разобраться, как это можно победить. И начну я, пожалуй, с собственной цитаты:
Помните, что у проектной документации тоже есть пользователи. Рассматривайте её как отдельный внутренний продукт.
Завязка
Пару лет назад у меня вышла интереснейшая дискуссия с одним очень умным человеком. Он заявлял, что проектная документация должна создаваться как книга: там должна быть завязка, основная линия, финал. Что последовательность изложения крайне важна, и без этого не получится заинтересовать читателя, а именно заинтересованность - ключ к верному пониманию сути проекта и отдельных его нюансов.
Если рассмотреть такое заявление поверхностно, то всё сходится: последовательно изложенная документация сама "ведёт" пользователя. Сперва следует плавное погружение в проект, что-то вроде концепции будущего продукта. Затем - описание отдельных компонентов, бизнес-логики. Потом - результаты высокоуровневого технического и UX-проектирования. И уже под конец, развязкой - артефакты итерационного детального проектирования.
Чтобы учесть контекст использования документации, мы даже можем разбить её на несколько ключевых направлений: пользовательское, техническое и бизнес. Таким образом, дизайнеры получат свой нарратив, а разработчики - свой. Представители бизнеса тоже не уйдут обделёнными: для них мы сперва подсветим цели и задачи проекта в бизнес-срезе, потом развернём их в конкретные метрики и способы достижения.
Кажется, что всё верно. Мы не даём программистам и всем остальным пользователям нашей документации сорокастраничных сбивчивых техзаданий, не заставляем их продираться сквозь заросли непонятных терминов.
Если следовать нарративному подходу, то даже пользовательские сценарии нашего продукта мы должны предоставлять в той же последовательности, в которой они выполняются:
Разумеется, такой подход подразумевает некоторую структуру проектной документации. Запихнуть всё в один или даже десять документов не получится. Нужны разделы для разных направлений, чёткие оглавления каждого документа, последовательное и логичное именование.
В этом случае, нарратив упрощает процесс погружения, делает понятными причинно-следственные связи внутри вашего продукта и каждого его компонента.
Так-то оно так, но не совсем. Теория хорошая и складная, но когда дело доходит до практики на проектах сложнее лендинга, нарратив перестаёт работать.
Конфликт
Уже при первом приближении становится ясно, что пользователи не изучают документацию последовательно. Однако мне, разумеется, понадобилось реальное подтверждение. Я как раз начинал новый проект и решил последовать стратегии моего собеседника: начал писать документацию в виде нарратива (разумеется, насколько это было возможно). До старта эксперимента я сделал концепцию и высокоуровневое проектирование продукта. В детальное не заходил, на то были свои проектные причины.
Итак, на каждую страницу документации была повешена аналитика (благо Confluence позволяет делать это довольно просто - достаточно обладать некоторыми техническими навыками). Я собирал только время на странице и переходы между документами. Выставил цели на последовательный переход более чем по 4 документам подряд при длительности сессии более 5-ти минут (чтобы не учитывать тех, кто просто зашёл что-то уточнить). Результат визуализировал в Google Analytics.
Так как проект был довольно большой, то и пользователей документации, и самой документации было приличное количество:
- 22 пользователя: 2 технических тимлида, 8 программистов, 3 тестировщика, UX-дизайнер, UX-исследователь, 2 бизнес-аналитика, маркетолог, сеошник, 2 владельца продукта и их технический консультант.
- 64 документа, разделённых на 7 разделов: roadmap, текущее состояние, словарь терминов, концепция, пользовательский слой, бизнес-слой, техническая документация.
Эксперимент имел смысл только в начале проекта, когда команда ещё не была погружена в нюансы, и можно было зафиксировать реальный путь изучения документации. Итого, у меня получилась выборка по пяти рабочим дням: от понедельника до пятницы. Двадцать два самых разных пользователя, 64 страницы в семи разделах.
Результат, как и ожидалось, оказался негативным. За рабочую неделю менее 12% сессий достигали цели в 4 последовательных документа подряд. Средний показатель - 2 документа (2.3, если быть точным). При этом большая часть конверсии пришлась на понедельник и вторник. К пятнице уже почти никто не изучал даже две последовательных доки подряд. Средняя продолжительность активной сессия была в районе 47-ти минут в начале эксперимента (пн) и 21-ой в его конце (пт).
Развитие
Это объективные цифры, с которыми трудно спорить: нарратив в проектной документации не работает. По крайней мере, в своём чистом виде.
Однако если оценивать субъективно, то нарратив оказался крайне полезен. Глубина погружения в проект у практически всех его участников выросла в разы. Если раньше, на других проектах, приходилось повторно проговаривать какие-то моменты, уже отражённые в доках, то теперь митинги стали куда более эффективными. Было видно, что команда действительно находится в едином информационном поле. Это не выразишь метрически, поэтому тут вам придётся просто поверить мне на слово.
Но почему же так происходит? Нарратив не работает, но всё равно приносит ощутимую пользу?
После эксперимента я поговорил почти с каждым его участником. Меня интересовало, что именно позволило так глубоко погрузиться в проект всего за несколько дней. Не сказать, чтобы результат оказался сильно неожиданным, но всё же.
Если обобщить, то главная польза от последовательного и логичного изложения документации в том, что так её проще укладывать в память. Не изучать последовательно, а именно раскладывать по полочкам в голове. Пользователи могли скакать по разделам, переходить по перекрёстным ссылкам, тыкать в интерактивные диаграммы - но из-за понятной и последовательно изложенной структуры всей документации, они чётко знали, где находится их внимание в данный момент и на какую полку нужно положить это знание.
Развязка
Тот проект запустился весьма успешно и даже быстрее, чем ожидалось. И с тех пор я уже три года стараюсь придерживаться именно этого подхода: понятная документация, чёткая структура, последовательное изложение.
Нарратив не работает сам по себе. Но вот вкупе с остальными хорошими практиками он становится тем самым "цементом", который связывает все "кирпичики" проектной документации, все разрозненные части и артефакты - в единое представление о продукте.
Ещё больше букв и картинок про дизайн и проектирование можно увидеть на моем сайте и здесь, в дзен-канале (подписывайтесь).