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