Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности

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

«Метод параноика» меняет порядок и рассматривает документацию как описание не того, что уже сделано, а того, что только предстоит сделать. При таком подходе артефакты проектирования превращаются в модель будущего продукта и средство коммуникации между участниками проекта. При переводе описания решений из формальной процедуры в инструмент ежедневного использования петля работы с документацией получает положительное подтверждение. Как следствие, документация становится еще и местом накопления актуальной информации, которой доверяют.

Неважно, какие технологии для описания модели продукта вы будете использовать – классические UML-диаграммы, смесь текстовых спецификаций, алгоритмических схем и графических макетов интерфейса. Важно, какой у них жизненный цикл, и как они структурированы. Об этом будет подробнее рассказано в «Черной книге» метода. Сейчас я остановлюсь на принципиальных аспектах подхода.

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

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

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

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

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