Это касается не только бюджета. Гибкие методологии не дают карт-бланш на работу над продуктом в режиме «здесь и сейчас», потому что проект – это всегда способ для бизнеса попасть из точки А в точку Б. У него есть допустимая цена и время, за которое необходимо пройти путь. Если за выбором следующего шага в проекте не стоит понимание конечной цели, то это похоже на езду в автомобиле, когда водитель произвольно крутит руль влево-вправо и не следит за дорогой. Гибкие методологии прежде всего должны давать тактическую свободу, но стратегически необходимо понимать, куда двигаться.
В таком акценте на целостность проявляется особенность принципа. Согласно ему, все версии продукта, подобно эпизодам сериала, рассматриваются не как несвязанные между собой истории, а как части общей картины. В начале задаются правила игры, своеобразные законы вселенной проекта или общее сценарное пространство, в котором действуют герои, и дальше, от эпизода к эпизоду, события разворачиваются, следуя общей логике. И точно так же, подобно сериалу, продукт выстраивается внутри общего архитектурного пространства на всех уровнях: бизнес-уровне, функциональном, интерфейсном, техническом и организационном.
На организационном уровне целостность выражается в том, что интересы и ответственность проектной команды не ограничиваются только одной версией, а охватывают весь цифровой продукт. Участники принимают решения, которые дают преимущества не в рамках локальной задачи, а учитывают общие цели проекта. Похожим образом этот эффект проявляется при формировании самих команд. Часто выгоднее привлечь к проектированию или разработке архитектурных компонентов более опытных, но дорогих специалистов, и за счет этого сэкономить в масштабах всего проекта.
На функциональном, интерфейсном и техническом уровнях целостность проявляется в создании архитектуры и общих правил, унифицирующих добавление новых функций в продукт. Свойством хорошо спроектированной архитектуры, технической или интерфейсной, является достаточная гибкость, при которой не нужно перерабатывать систему целиком, чтобы внести очередные изменения. Это частая проблема, когда доработки делаются в отрыве друг от друга и в проекте накапливается технический долг. Здесь же удается этого избежать, потому что истинная гибкость, о которой так много говорят, опирается, прежде всего, на гибкость конструкции в основе цифрового сервиса.
На уровне бизнеса целостность проекта дает владельцам уверенность, что создаваемый продукт комплексно решает задачи компании, а не просто закрывает отдельные фрагменты бизнес-модели. Это позволяет отказаться от ручного управления, что в проектах типа «Мозги» и невозможно, поскольку они состоят в основном из поиска решений. Стиль управления в таких проектах заключается не в директивном назначении задач, а в создании пространства возможностей, соответствующего образу будущего продукта. Участники проектной команды сами наполнят это пространство найденными решениями в заданных границах.
Если суммировать сказанное, то принцип сериала отвечает на вопрос: «Как подойти к оценке нетиповых проектов и организовать работу в условиях высокой внешней неопределенности со стороны бизнеса?» Следующие части главы описывают, как структурировать работу, сделать первые исследовательские шаги, сформировать пространство, в котором будет развиваться продукт, и как затем перейти к воплощению замысла. Также дается понимание, как проджект-раннер должен подойти к организации проектной команды и прогнозированию работ на каждой стадии.
Напомню, что в отличие от типов «Седина» и «Процедуры», в проектах типа «Мозги» цель не в реализации уже апробированных подходов и технологий, а в нахождении решений для новых нестандартных задач. Это может относиться и к техническим вопросам, и к вопросам бизнеса, но чаще всего и к тем, и к другим. Все потому, что интересные решения обычно рождаются на пересечении разных дисциплин. Примеров много: от бизнес-моделей, построенных на новых технологических инструментах, до экспериментов с новыми сочетаниями сценариев поведения пользователей и цифровых продуктов. Такие проекты отличаются высоким уровнем неопределенности, и в них не работают стандартные методы управления.
Давайте посмотрим, какие инструменты предлагает «Метод параноика» для организации проектов типа «Мозги». Во-первых, контрольные точки, которые позволяют структурировать процесс и внести фактор предсказуемости. Во-вторых, гибкие проектные команды и продюсерский подход к их управлению. Для нетиповых задач нужно собирать уникальную группу специалистов и обновлять ее по мере развития проекта. В-третьих, модель продукта как совокупность всех принятых командой решений. Она позволяет «видеть» цифровой продукт во всей его полноте и одновременно является средой коммуникаций между участниками. Дальше я покажу работу каждого инструмента и их сочетание.