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