Основные задачи из этой области – технологические. Например, разработка новой платформы для колл-центра с технологией генерации и распознавания голоса или создание комплексной системы автоматизации выборов в крупной стране. В обоих примерах компании-подрядчику потребуется выполнить большой объем работы внутри после получения требований к проекту. Так работают системные интеграторы и технологические R&D-центры. Кстати, они также прибегают к услугам компаний из других квадрантов, например, передают разработку на аутсорсинг «Фармацевтам», оставляя на своей стороне задачи проектирования и координации работы над проектом.
Последний в модели квадрант расположен справа сверху. Это означает высокую сложность решаемых задач с индивидуализированным подходом и необходимость в постоянных коммуникациях между клиентом и исполнителем. Учитывая характер задач и степень ответственности, тут уже сложно говорить в таких терминах. Стороны взаимодействуют скорее как равноправные партнёры, занимающиеся общим проектом. Каждый из них эксперт в своём деле. Клиент определяет общее направление деятельности, обозначает либо проблемы в бизнесе, либо возможные точки развития, а исполнитель помогает подобрать наиболее удачный способ решения. Этот квадрант называется «Психотерапевт» (Psychotherapist).
В отличие от «Нейрохирургов», где задачи тоже сложные, но преимущественно носят технологический характер, задачи «Психотерапевтов» связаны с разработкой концепций продуктов и их проектированием, поиском принципиальных схем решения бизнес-задач и исследованием технологий, открывающих новые форматы работы бизнеса. В случае если проект требует этого, в ответственность «Психотерапевта» входит подбор необходимых исполнителей из других областей для решения конкретных задач при реализации общего проекта. Сформулированная в «Методе параноика» модель продюсирования ИТ-проектов как раз описывает формат работы в этом квадранте.
Экономика проектов
Экономика проектов также бывает разная в зависимости от типов проектов и формата работы над ними. Существует множество способов оценки и управления бюджетом проекта, но я хочу рассказать об одном аспекте, который как мне кажется, лежит в основе всех моделей и определяет саму возможность выжить подрядчику, а клиенту получить проект. Речь идёт о диаграмме приходов и расходов.
При всей банальности этой мысли, прибыль компании, выполняющей проекты на заказ, в конечном счёте складывается из приходов и расходов. Параметром, который объединяет приходы и расходы, является время. Если за фиксированный отрезок времени компания получит денег больше, чем потратит, то по итогу этого отрезка её деятельность является прибыльной. Но это, как ни странно, вовсе не значит, что если последний квартал был прибыльный, то с компанией все в порядке. Дальше я расскажу, как обстоят дела на самом деле.
Нужно помнить, что способ, каким вы оцениваете свою деятельность, влияет на то, как вы эту деятельность организуете. Именно поэтому сначала я хочу обратить внимание на параметр времени. Большинство считает по календарным периодам. Так сложилось, и причина – бухгалтерский учёт. Но не только. Кроме того, что бухгалтерам так удобно считать (это конечно не их прихоть, а реальность в виде законодательства), есть бизнес-модель компании.
Бизнес-модели
Самая распространённая модель – ресурсная. Это когда у вас как у компании есть ресурсы, и вы ими торгуете. В случае с заказной разработкой ресурсы – это специалисты и их рабочие часы. При этом как вы упаковываете эти часы для клиента – сдаёте каждого разработчика в аренду на почасовой основе («Time & Material» или «T&M») или продаёте целиком команду на проект, не имеет значения. Важно то, что чем больше у вас ресурсов, тем потенциально больше вы можете на них заработать. А вот то, как реализуется этот потенциал, определяет отношение количества проданных часов к календарному периоду времени.
Именно такая модель приводит к тому, что деятельность оценивается календарным способом, т.к. в конечном счёте привязана к графику выплаты зарплаты сотрудникам, рабочие часы которых компания продаёт клиентам. Чем больше часов за календарный период продано, тем лучше. Это кажется настолько привычным и само собой разумеющимся, что практически вся бизнес-литература и большинство проектных методологий ориентированы на повышение эффективности использования проектных ресурсов.
Если ваша задача продать как можно большее количество часов как можно большего количества специалистов, то это неизбежно приводит компанию к типу проектов «Процедуры» и формату работы «Фармацевт» или «Сиделка». Даже те компании, которые изначально позиционировали себя как работающие над уникальными проектами, при значительном расширении штата, как правило, переходят на более общий формат, потому что, как уже сказано выше, такова неизбежная экономическая логика. Любая крупная аутсорсинговая компания часто в начале специализируется на создании продуктов для клиентов, но в рано или поздно превращается в «Body Shop», переходя к модели аутстаффинга.
Характерная черта ресурсной модели – это возможность клиента заменить ресурсы одного подрядчика на ресурсы другого или даже перейти на свои, наняв в штат специалистов требуемой квалификации. Это ограничивает возможности роста часовой ставки и вводит понятие рынка услуг. Если компании продают часы специалистов схожей квалификации, то они неизбежно конкурируют друг с другом. Способов конкуренции немного – цена, уровень опытности специалистов и управленческое качество предоставления услуг (качество коммуникаций, возможность оперативного расширения команды, координация работы специалистов на стороне подрядчика).
Существует другая бизнес-модель, в которой «товаром» служит нечто отличное от ресурсов, а именно знания. Можно, конечно, поспорить и сказать, что специалисты, часы которых покупает клиент, тоже обладают знаниями, например, в программировании или дизайне. Но эти знания не уникальны, а самое главное, клиент покупает работу как таковую, и чем больше работы будет выполнено, тем лучше для клиента. Разберём на примере.
Банк ищет способ уменьшить стоимость обслуживания своих клиентов, а заодно увеличить их количество. Из анализа конкурентов делается вывод, что в этом может помочь новое мобильное приложение, которое будет достаточно удобным и функциональным, чтобы клиенты самостоятельно решали свои задачи, а не приходили в отделения банка, тратя время операционистов. В итоге объявляется конкурс для выбора подрядчика. Цель простая – найти компанию, которая за меньшую стоимость предоставит специалистов достаточной квалификации для этой задачи, т.е. создания мобильного приложения. Пока мы видим обычную ресурсную модель. Но банк может поступить по-другому.
Например, найти компанию, которая уже имеет опыт и наработки в создании подобных приложений. Адаптация под задачи банка, конечно, потребуется, но в сравнении с разработкой с нуля будет сэкономлено время, которое банк потратил бы на самостоятельный поиск решения, и не факт, что удачный. Или банк мог бы привлечь специалистов в управлении проектами, которые более эффективно организовали работу над проектом, лучше, чем это могут сделать сотрудники банка или менеджеры подрядчика, специализирующегося на разработке и в результате также сократить издержки на создание приложения. В ряде случаев ещё более полезным для банка мог бы быть специалист, который качественно по-другому подошёл бы к первоначальной задаче и предложил способы уменьшения стоимости обслуживания клиентов не за счёт мобильного приложения, а другой технической и организационной технологии.
Ценность услуги в такой модели формируется не себестоимостью, от которой дальше рассчитывается стоимость для клиента путём добавления приемлемой для рынка наценки, а ценностью, которой услуга обладает в масштабах бизнеса клиента. Если, например, новая технология позволяет клиенту зарабатывать дополнительные 10% или, наоборот, экономить те же 10%, то при обороте компании в 100 млн рублей ценность услуги составит 10 млн рублей. Именно о таком порядке стоимости услуг и в таком ключе необходимо вести разговор, а вовсе не о часовой ставке. Часто одного часового общения с клиентом достаточно, чтобы повлиять на его бизнес. Вы же не будете говорить о стоимости часа в несколько миллионов рублей? Конечно, эта модель имеет и обратную сторону, когда одно и то же решение или технология даст пропорционально меньший результат в абсолютных значениях в бизнесе меньшего масштаба.
Если вы попытаетесь мерить бизнес, работающий по такой модели, обычным календарным способом и смотреть на то, сколько часов ваших специалистов было продано клиентам за последний квартал, то долго такой бизнес не протянет. Вспоминается анекдот, когда на вопрос директора, входящего в офис филиала компании, почему один из сотрудников в рабочее время развалился в кресле и ничего не делает, ему отвечают «последний раз, так же сидя в этом кресле, он предложил идею, которая принесла нам миллион долларов, поэтому пускай сидит дальше!»
Приходы и расходы
Теперь посмотрим на то, из чего складываются приходы и расходы у компаний, выполняющих проекты на заказ. И как разные типы проектов и форматы работы над ними влияют на периодичность движения денег. И в конечном счёте на прибыльность.
Поступления от клиентов могут быть регулярными и нерегулярными. Это зависит от того, что именно покупает клиент. Если речь идёт о покупке часов специалистов (чаще всего это аутстаффинг отдельных специалистов или целых команд), то в большинстве случаев поступления регулярные. Клиент оплачивает согласованное количество часов, отработанных сотрудниками подрядчика за фиксированный отрезок времени, например, месяц.
Если клиент покупает не просто часы специалистов, а конкретные результаты работы, например дизайн-макеты сайта или в целом спроектированное и разработанное мобильное приложение, то это проектная работа. Для такой работы характерны нерегулярные поступления, т.е. оплата клиента, привязанная к этапам проекта, а не к календарным отрезкам. Более того, каждый этап может иметь разную стоимость, т.к. от этапа к этапу может быть задействован разный состав проектной команды. Стоимость может рассчитываться как по фактически отработанным командой часам («работа по T&M»), так и быть фиксированной («fixed price»). В случае с ресурсной бизнес-моделью, а большинство проектов так или иначе выполняются в этой модели, способ расчёта стоимости («работа по T&M» или «fixed price») просто вопрос того, кто несёт риски, клиент или подрядчик.
Аналогично поступлениям от клиентов, расходы тоже могут быть регулярными и нерегулярными. Я говорю сейчас только о проектных расходах, т.е. оплате труда специалистов. В ИТ-отрасли это основные затраты в отличие от производственной сферы, где имеют значение стоимость исходных материалов и оборудования, оплата аренды и другие инфраструктурные расходы. Когда вы создаёте цифровые продукты, самое главное – это люди. Люди же любят стабильность. По крайней мере, большинство из них, и в первую очередь это касается денег. Поэтому компании, работающие в ресурсной бизнес-модели, практически всегда имеют штат сотрудников. Ведь чтобы продавать ресурсы, у вас они должны быть. Это означает регулярные расходы, причём независимо от того, есть ли поступления от клиентов или нет.
Работать в ресурсной бизнес-модели можно и с нерегулярными расходами. Часто компании привлекают в качестве дополнительных ресурсов внешних фрилансеров средней квалификации или отдельных классных специалистов, работающих по-проектно. Тем не менее, это не является существенной долей такого бизнеса. Есть ещё небольшое количество компаний, работающих другим способом. Как правило, это небольшие компании, часто даже просто самостоятельные проектные команды. В них оплата специалистов напрямую связана с объёмом проданных часов клиентам.
Совсем отдельно стоят высокопрофессиональные объединения специалистов, работающих под общим брендом, но при этом каждый из них является не сотрудником, а равноправным участником и претендует на свою долю от поступлений от клиентов. Такой формат, как правило, связан с бизнес-моделью знаний, а не ресурсной моделью. Поступления связаны с отдельными проектами, и они нерегулярные, расходы также нерегулярные.
Из всех этих объяснений про регулярность поступлений и расходов я хочу подвести вас к следующей проблеме. Если за время работы над проектом сумма приходов меньше, чем сумма расходов, то в итоге компания несёт убытки. Эти убытки часто незаметны на общем фоне, т.к. могут компенсироваться прибылью с других проектов. В итоге компания формально прибыльная, но работает не так эффективно, как это можно было бы ожидать. Чем-то похоже на внутреннее кровотечение внешне вроде бы здорового человека. Это связано с самой природой этого бизнеса и тем, как накладываются друг на друга графики поступления денег и графики расходов. На схеме ниже показана ситуация, когда расходы на штат сотрудников срезают все всплески приходов от клиента по проекту и дают в итоге практически нулевую прибыль. Хотя в процессе может захватывать дух от оборотов.
Любая компания, имеющая регулярные расходы, пытается добиться как можно более регулярного поступления оплат от клиентов. А регулярные поступления возможны в случае, когда команда специалистов как можно дольше работает над одним и тем же проектом и её состав не меняется. Именно с этим связана любовь компаний-разработчиков к Скраму, т.к. у проекта нет разных по стоимости этапов, а команда максимально однородна и специалисты взаимозаменяемы. Работа над проектом разбита на равные отрезки времени – спринты, за которые удобно выставлять регулярные счета. Дело, как обычно, в деньгах, а вовсе не в каком-то волшебном качестве этой популярной методологии. Другим вариантом является то, что компания специализируется на одинаковых проектах, либо старается работать по модели аутстаффинга, передавая своих сотрудников на как можно больший срок в проекты клиентам. И то и другое характерно для проектов типа «Процедуры» и «Седина».
Иначе обстоят дела у компаний, которые в силу формата работы не могут переложить риски на клиента. В случае если бизнес-модель компании ресурсная, то основная задача управления – балансировка загрузки ресурсов. Клиенты приходят и уходят, состав сотрудников не так быстро меняется, как стартуют новые проекты и завершаются старые. Сбалансировать загрузку ресурсов сложно. Если от проекта к проекту меняются потребности в специалистах разных компетенций, то выдерживать баланс становится ещё труднее. Только сверхприбыль по нескольким крупным проектам позволяет таким компаниям жить достаточно долго. В основном действительно успешные компании, работающие по такой модели, делают проекты типа «Мозги» просто потому, что там есть возможность выставлять очень высокую стоимость работ.
Экосистема и продюсирование проектов
Разные типы проектов требуют разных специалистов. Когда сходятся звезды и на проекте собирается нужная команда, все получается. Причём я говорю не просто про потребность в высококлассных разработчиках или талантливых дизайнерах. Для проектов часто нужны специалисты со средней компетенцией, но важно, чтобы их было много и их стоимость укладывалась в бюджет. Например, если проект типа «Процедуры» попытаться сделать командой, которая обычно делает проекты типа «Мозги», то в минусе будут все – клиент, который сильно переплатит, специалисты, т.к. для них это будет неинтересная работа, компания-подрядчик, из которой эти специалисты уволятся, если такая ситуация будет регулярной.
Схема наглядно показывает, как выглядит расхождение потребностей в специалистах требуемого уровня для проектов, которыми занимается компания и её фактический состав. Как видно, дело может быть и в уровне компетенции, и в требуемом количестве специалистов нужной компетенции. Среди ИТ-предпринимателей есть иллюзия, что в рамках большой компании можно собрать нужную команду для любого проекта. Им кажется, что проблема только в том, чтобы найти подходящих людей. На практике это не происходит, и дело вот в чем. Есть мотивы, по которым люди приходят в компании работать, и есть объективные причины, по которым эти люди являются профессионалами в определённой области. Есть мотивы, по которым клиенты выбирают эти компании, и есть объективные причины, по которым у этих компаний либо получается сделать проект, либо не получается.
Сильные специалисты ищут компании, в которых они смогут развиваться и реализовывать себя. Деньги играют только функцию социального подтверждения их профессионального статуса, но не являются основным мотивом. Для профессионального роста специалиста нужна соответствующая среда. Так же, как и для роста растений – не будет достаточно воды и солнца, и ваш фикус загнётся. То же самое и в работе, если не будет сложных задач, не будет сильных наставников и в результате не будет сильного специалиста. Одного желания человека здесь недостаточно. И даже если вы собрали уже сильную команду, но не загружаете её интересными задачами, то команда не сохранит своего уровня. В отличие от растений у людей есть ноги, и в конечном счёте вся команда разойдётся. Это, кстати, часто не понимают руководители не из ИТ-среды, которые пытаются давить авторитетом, а не заинтересовывать людей. Характерна ситуация, когда вместе с уходом кого-то из крутых специалистов вслед за ним уходит целая команда, потому что они работали не «на фирму», а «чтобы учиться у него».
Отдельно нужно сказать про проекты типа «Седина». Для них характерна отраслевая специализация, т.к. наработки и технологии, которые ожидают получить клиенты, не являются просто «программерскими» решениями, речь идёт про способы решения отраслевых задач с помощью ИТ-технологий. Нельзя в компании держать специалистов по всем отраслям во Вселенной. Именно поэтому ИТ-компании, выполняющие проекты типа «Седина», всегда имеют отраслевую специализацию. Таких специализаций может быть несколько, их ещё называют практиками, например, «практика по нефтянке» или «по налогам». Чтобы наработать подобную специализацию, компании нужно много инвестировать и выполнить существенное количество проектов для клиентов в целевой отрасли.
Клиенты, в отличие от ИТ-специалистов, обычно хуже разбираются в этой среде, хотя постоянная ротация людей между корпоративным бизнесом, который чаще всего выступает в роли заказчиков проектов, и ИТ-компаниями, реализующими эти проекты, приводит к постепенному росту компетенции у клиентов. Как я уже писал в одной из своих статей, наверно, одной из ключевых проблем во взаимоотношениях между клиентами и подрядчиками является непонимание иной природы ИТ-проектов в отличие от обычных закупок оборудования или услуг из более традиционных сфер. Создание цифровых продуктов всегда сопряжено с высокой степенью неопределённости во всех аспектах – в оценке, сроках и, собственно, в самих проектных решениях. Игнорирование этой неопределённости в конечном счёте дорого обходится всем, причём в прямом смысле этого слова.
Давно пора понять, и я это говорю не только в адрес специалистов, что успешный проект начинается с ясного понимания целей. Это не такой простой вопрос, как кажется. Часто истинная цель создания какого-то цифрового сервиса или приложения вовсе не какие-то бизнес-задачи, а амбиции конкретного топ-менеджера. Если вовремя, ещё в начале проекта честно ответить себе на этот вопрос, можно подойти к выбору средств более разумно. Вместо того, чтобы нанимать дорогих специалистов, можно купить готовое решение, либо обойтись маркетинговыми средствами, совсем избежав такого проекта. Вот почему я считаю, что определение типа проекта, пускай даже такое условное, нужно не только подрядчикам, но и клиентам. В конце концов, речь идёт про потерянные деньги и время, которое часто имеет решающее значение.
Например, компания открывает новое направление в своём бизнесе и планирует создать для него инновационный инструмент, требующий исследований и глубокой технической экспертизы, бессмысленно искать подрядчика среди тех, кто делает проекты типа «Процедуры». У такой компании могут быть хорошо поставлены процессы для создания типовых продуктов и низкая часовая ставка, но у них нет специалистов, обладающих достаточным опытом и самое главное методикой поиска сложных решений. Здесь помогут только «Мозги».
Другая ситуация, когда клиенту нужно сделать аналогичное решение, как у конкурентов. В этом случае лучший выбор – это подрядчик, уже обладающий отраслевым опытом и выполнивший несколько подобных проектов. Когда компания занимается похожими проектами, в результате формируется сложившаяся структура команды. Например, когда мы в «ГАЛС СОФТ» создавали приложения для СМИ, у нас на проекте всегда был руководитель проекта, интерфейсный дизайнер, технический архитектор, он же лидер группы разработки, пара разработчиков для каждой из мобильных платформ и тестировщик. Работа команды укладывалась в один и тот же проектный цикл, состоящий из одних и тех же этапов. Более того, если разрабатываемые продукты имеют схожую функциональность, то и состав, и объем задач у каждого из участников был похож от проекта к проекту. Таким образом обычно строится работа над проектами типа «Седина».
То же самое происходит, когда компания-подрядчик внедряет разработанную им технологию в бизнес клиента. Как правило, есть типовые шаги проекта, начинающиеся с анализа ключевых параметров, влияющих на ход внедрения. Но влияющих в строго заданных границах, т.к. внедряемая технология, например, внутренний корпоративный портал, имеет свои ограничения. Дальнейший ход проекта также идёт в рамках типового процесса с учётом полученных параметров на этапе предпроектного анализа. Кажущаяся гибкость на самом деле является просто большим количеством возможных вариантов. Это обычный проект типа «Седина».
Совсем по-другому обстоят дела на проекте, в котором требуется создать уникальный продукт. В момент, когда клиент формулирует бизнес-цели, неизвестен ни будущий облик продукта, ни его функциональные возможности, часто даже непонятно, каким именно образом будет решена клиентская задача. А значит, неизвестен состав проектной команды и этапы проекта. Все это определяется по мере того, как видение будущего продукта становится все более ясным. А становится оно ясным в процессе проектирования будущего продукта. Все это типичные признаки проекта типа «Мозги», а работают над такими проектами «Нейрохирурги» или «Психотерапевты».
Конечно же, «Нейрохирурги» или «Психотерапевты» не работают в одиночку. Я в начале сказал, что индустрия создания цифровых продуктов – это экосистема. Для работы над уникальными проектами требуются специалисты с уникальными компетенциями. Но это вовсе не значит, что для работы над следующим проектом потребуются те же самые компетенции. В результате складывается ситуация, когда под каждый новый проект должна быть собрана новая команда. Некоторые из её участников будут работать в ней в течение всего проекта, другие присоединятся только на время, пока не сделают свою часть. Для такого формата нужна особая роль ключевого участника проектной команды, своеобразная точка отсчёта. Тот, кто проведёт проект по пути от формулирования концепции продукта до его запуска. Попутно рассчитает экономику проекта и сформирует команду.
Ближе всего к такой схеме работы находится продюсирование фильмов. Инвестор приглашает продюсера, который в свою очередь подбирает режиссёра, сценариста, помогает провести кастинг, обеспечивает производство фильма на всех стадиях. При этом следит за бюджетом и если выясняется, что для требуемого результата нужно кого-то сменить в команде, то продюсер имеет на это полномочия. Безусловно ещё существует и режиссёрский формат работы над фильмами, но меня в данном случае интересует коммерческое кино как способ ведения проектов.
Суть такого подхода состоит в том, чтобы выбрать для проекта только одного человека – продюсера. Все остальное он сделает сам. Для того чтобы у него все получилось, он должен обладать большим спектром компетенций, эдакий человек-оркестр. Такой профессионал – большая редкость, но мы ведь говорим про уникальные проекты. В нем должен сочетаться и проектировщик, и управленец, и предприниматель. Он должен уметь ладить с людьми и налаживать рабочие процессы. Если продюсер работает в формате «психотерапевта», то он постоянно взаимодействует с клиентом, вырабатывая с ним концепцию продукта и выступая в качестве проводника в процессе поиска наилучшего решения бизнес-задач. Если продюсер работает как «нейрохирург», то он выступает в роли генерального конструктора, продумывая принципиальную схему решения задачи клиента, и интегрирует работу других специалистов на проекте. Если такой подход вам кажется интересным, то восьмая глава даст его подробное описание.
Глава 3. Оценка проектов, планирование и неопределённость
Кто прав, бизнес или специалисты?
Цель любого проекта – создание инструментов, используемых бизнесом. Это может быть онлайн-магазин, через который компания продаёт товары, или банковский сервис для взаимодействия с клиентами, или мобильные приложения, используемые на складе сотрудниками логистической компании. В большинстве случаев для поддержания всех процессов требуется одновременно несколько инструментов. Часть из них создаётся на заказ непосредственно для бизнеса, часть подбирается из готовых продуктов либо внешних сервисов. Если бизнес развивается, то вместе с ним развиваются и цифровые инструменты. Т.к. внешняя среда любой компании все время меняется, то и сама компания должна непрерывно адаптироваться. А значит, любой действующий бизнес находится в постоянном процессе обновления своей инфраструктуры, в том числе и цифровой.
Чаще всего это обновление заключается в совершенствовании уже существующих инструментов. Компания может менять ассортимент продаваемых товаров или расширять свои услуги, но основная схема работы остаётся без изменений. В таких случаях достаточно небольших доработок. То же самое можно сказать про обновление дизайна или изменения в интерфейсе. К примеру, если речь идёт про онлайн-сервис, то более простое взаимодействие с клиентами может увеличить продажи, при этом бизнес-модель компании сохраняется. Но бывают случаи, когда требуется что-то более радикальное, нечто, что меняет правила игры, давая бизнесу возможность построить свою работу способом, отличным от конкурентов, или создав принципиально новую бизнес-модель. Это типичный сценарий для успешных стартапов, хотя традиционные компании тоже периодически делают подобные попытки, которые, как ни странно, иногда заканчиваются успехом.
Конечно же, бизнес не решает такие задачи самостоятельно, а привлекает специалистов из ИТ-индустрии. В предыдущей главе я как раз описал внутреннюю кухню этой отрасли, дал описание типов проектов, форматов работы, объяснил, как устроена экономическая модель проектных команд и компаний, создающих цифровые продукты и сервисы. Независимо от того, работают ли ИТ-специалисты внутри или бизнес заказывает проект у сторонних технологических компаний, взаимодействие бизнеса и профессионалов – не самая простая задача. Многие проекты завершаются, либо значительно превышая ожидаемые сроки и стоимость, либо без требуемого результата. Но чаще всего происходит и то, и другое. Только в отдельных случаях бизнес получает то, на что изначально рассчитывал.
Вы, наверно, уже догадались, что эта глава посвящена проектной работе, т.е. процессу превращения бизнес-задач в действующие цифровые инструменты. Но в то же время эта глава о неочевидных причинах того, почему не удаётся реализовать такие проекты. Почему неочевидных? Потому что с точки зрения бизнеса причины кажутся простыми и понятными: к проекту привлекли специалистов, которые не смогли уложиться в сроки или реализовали продукт плохого качества. С точки зрения профессионалов, создающих цифровые продукты, причина тоже не вызывает сомнений: бизнес не смог чётко поставить задачи, а на реализацию выделил слишком мало времени и сократил бюджет. Ключевым моментом для понимания является то, что речь может идти об одном и том же проекте. Точка, с которой вы смотрите на реальность, влияет на ваше представление о ней и открывает иную перспективу. Или её отсутствие.
Для пешехода, который погибает, переходя дорогу на зелёный свет, но не глядя по сторонам, единственной радостью остаётся то, что он был прав. Так и бизнес часто настаивает на своей формальной правоте, говоря, что раз уж продукт был заказан, то он непременно должен быть получен в требуемом виде. Не понимая природы проектной работы над цифровыми продуктами, бизнес часто теряет время и деньги, а иногда рискует собственным существованием. Цена вопроса, как мне кажется, слишком высока, чтобы продолжать настаивать на своём и не пытаться разобраться в действительных причинах проблем.
То же самое можно сказать и про профессионалов. Немногим людям, имеющим отношение к цифровым продуктам, посчастливилось поработать с обеих сторон проектных баррикад. Знание того, что происходит на противоположной стороне, даёт более глубокое понимание возникающих проблем. Как следствие, проекты, выполняемые такими людьми, с большей вероятностью достигают успеха. Ильяху Голдратт называл попытку поиска компромисса между разными точками зрения способом создания иллюзии. Эти же люди лишены подобных иллюзий, и в таком ясном взгляде и заключена их ценность. Многие проекты получили бы шанс, если при их ведении это можно было бы учесть.
К сожалению, большинство из нас склонны к простым решениям, это в нашей природе. Именно поэтому так популярна идея, что использование определённой методологии или подхода к ведению проектов может решить все возникающие в них проблемы. Многие из моих коллег наверняка помнят огромные буквы AGILE на входе в центральный офис Сбербанка. Но следование нескольким простым правилам никогда не являлось панацеей, ни в том, чтобы за месяц стать стройным и красивым, ни в том, чтобы реализовать сложный проект в рамках запланированного бюджета и с нужным качеством.
