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