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