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