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