Текст книги "Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности"

Теперь рассмотрим, как неопределенность проявляется в разных типах проектов на примере запуска стартапа или создания нового направления в существующем бизнесе. В качестве примера возьмем производственную компанию, открывающую направление онлайн-продаж под заказ с индивидуальными параметрами. Действующую производственную часть компании можно рассматривать как внешнего поставщика для нового направления, и в таком случае искомая бизнес-модель подойдет и для отдельной компании.

Такой бизнес невозможно запустить без цифрового сервиса. Это должна быть онлайн-витрина с конфигуратором продукта, системой формирования заказа и оплаты, а также отслеживанием статуса поставки, связанным с транспортной службой. Все это должно быть интегрировано с производственной частью: от учета текущей загрузки для расчета сроков готовности до передачи и отслеживания всех параметров заказов. Помимо этого, система также должна предоставлять финансовую и производственную аналитику для всех сотрудников, участвующих в управлении. Как видите, если вначале создание такого цифрового инструмента могло показаться относительно простой задачей, то после детализации требований все становится сложнее.

Здесь, в отличие от предыдущего примера, возможных вариантов меньше. Исключается тип «Процедуры», когда специалисты работают по четко сформулированным заданиям. Проработка таких заданий сама по себе превращается в самостоятельный проект. Если бизнес делает ставку на инновационную модель работы, которой нет у возможных конкурентов, то суть такого проекта заключается в поиске возможного решения (тип «Мозги»). Как и в первом примере, уровень неопределенности здесь очень высок. Итоговая схема работы компании определяет требования к будущему цифровому сервису и рождается как уравнение между технологическими возможностями и визионерским видением предпринимателей.

Важно понимать, что, даже если технологический продукт будет качественно реализован и сможет выполнять все необходимые функции, это не гарантия успеха для бизнеса. Ошибка может оказаться не на уровне системы, а в предположениях о мотивах покупателей или возможностях производства.

Второй путь – это заимствовать бизнес-модель у аналогичных компаний и использовать проверенные технологические системы и решения (тип «Седина»). В этом случае необходимо привлекать специалистов с опытом создания подобных цифровых сервисов. Если используются существующие продукты, степень неопределенности низкая и можно точно оценить стоимость и сроки проекта. В то же время неопределенность возрастает, если бизнес-модель готова, но для ее реализации требуется создание нового технологического продукта, хотя и аналогичного тем, что работают у конкурентов. Если за такой проект возьмутся специалисты без опыта в этой области, то для них задача будет иметь тип «Мозги», что не позволит им спрогнозировать объем и сложность работ.

Выбор способа запуска нового направления определяется амбициями и стратегией развития бизнеса. Если речь идет о венчурных компаниях и стартапах, которые делают ставку на инновации и отрыв от конкурентов, то проект типа «Мозги» оправдан. Для бизнеса с другими способами привлечения заказов предпочтительнее вариант с использованием уже проверенных цифровых инструментов и решений, конечно если они существуют в данной отрасли.

Давайте рассмотрим уровень неопределенности в проектах для стабильно работающего бизнеса, который расширяет способы взаимодействия с клиентами, сохраняя текущую бизнес-модель. Примером может быть банк с онлайн-сервисами, добавляющий мобильные приложения и голосовых ассистентов.

Для лучшего понимания важно учитывать наличие актуальной документации, описывающей цифровые инструменты, используемые в банке, и внутреннюю экспертизу по проектированию и разработке. Все это работает в пользу проектов, предполагающих создание новых сервисов на базе существующих, причем, как правило, основными участниками проектов становятся собственные специалисты банка.

Первым и наиболее частым вариантом является проект типа «Процедуры», что означает создание новых цифровых сервисов с сохранением существующих сценариев взаимодействия с клиентами. Мобильные приложения и голосовые интерфейсы рассматриваются как дополнительные каналы коммуникаций без принципиальных изменений. Такой подход снижает уровень неопределенности, а наличие документации создает устойчивую среду для проектирования и разработки. Даже если в проект привлекаются внешние специалисты, сотрудники IT-департамента банка могут четко поставить задачи.

В таких проектах, при соблюдении всех условий, можно точно спрогнозировать объем работ. Большая часть неопределенности устраняется на стадии постановки задачи, и лишь расширение функционала первой версии продукта может осложнить планирование. Проблемы при таком подходе начинаются на этапе опытной эксплуатации, когда стандартные пользовательские сценарии для всех каналов коммуникаций сталкиваются с реальностью. Низкая оценка удобства работы со стороны клиентов требует изменений. Если те же специалисты займутся решением этой задачи в рамках того же проекта, проблему они не устранят.

Более предпочтительный вариант для банка – воспользоваться существующими наработками и запустить проект типа «Седина». Для этого нужно пригласить специалистов, которые уже создавали банковские мобильные приложения и голосовых ассистентов, либо использовать готовые цифровые продукты. В отличие от внутренних специалистов, приглашенные профессионалы уже прошли путь проб и ошибок и выработали типовую, но работающую модель взаимодействия с пользователями. Банк не должно смущать, что подобные инструменты и подходы могут использовать другие банки, поскольку для клиентов это уже привычные и удобные сервисы.

Уровень неопределенности в таких проектах ниже, чем в первом варианте. Основной риск связан с возможными проблемами совместимости предлагаемого продукта с существующей цифровой банковской инфраструктурой. Если внешние и внутренние специалисты смогут выстроить хорошие рабочие отношения, это позволит им на начальном этапе выяснить все необходимые параметры рабочей среды для интеграции. Как я уже неоднократно подчеркивал, не стоит выходить за границы заложенных пользовательских сценариев и наработанного опыта, так как в таком случае теряются все преимущества проектов типа «Седина».

Теперь перейдем к третьему варианту (тип «Мозги») – самостоятельному поиску моделей коммуникаций с клиентами через новые технологические каналы. Это исследовательская работа с высоким уровнем неопределенности. Руководители должны четко представлять цели проекта и активно участвовать в нем, взаимодействовать с командой специалистов, работающих над новым продуктом. В конечном счете только они полностью понимают бизнес-модель и ключевые особенности банка. Есть две возможные причины выбора такого варианта развития.

Одна из них – завышенные амбиции руководства банка или менеджеров, отвечающих за проект. По опыту большинство подобных проектов заканчиваются неудачно и с серьезными репутационными потерями, поскольку уровень амбиций не соответствует уровню компетенций. От проекта приходится отказываться либо в процессе разработки, либо, что еще болезненнее, после публичного анонса и запуска в эксплуатацию. Из-за непонимания причин неопределенности в таких проектах вину за неудачу и финансовые издержки часто перекладывают на специалистов.

Другая причина, – тут я хотел бы отдать должное таким руководителям, – заключается в стратегии постоянного поиска новых точек роста и ниш для развития. Для стабильного и успешного бизнеса нужны регулярные эксперименты по типу «Мозги», чтобы иметь наготове набор возможных решений. Лучше не доводить до ситуации, когда становится слишком поздно для вдумчивой подготовки. При таком подходе банк может запустить исследовательский проект задолго до того, как мобильное приложение или голосовой ассистент станут де-факто обязательным требованием со стороны клиентов. Возможные неудачи в этом случае будут рассматриваться не как провал всего проекта, а как неподтвержденные гипотезы.

После завершения инновационного проекта и получения нового работающего цифрового сервиса есть смысл продолжать его развитие в формате проектов типа «Процедуры». Последовательно улучшать и адаптировать систему под текущие потребности, не меняя найденную модель коммуникаций с клиентами.

Приведенные примеры нужны, чтобы вы наглядно увидели, как разные типы проектов ограничивают возможности прогнозирования из-за разного уровня неопределенности. Бывают ситуации, когда на вопрос «сколько это будет стоить» невозможно ответить, и дело не в низкой компетенции специалистов, а в самой природе процесса создания сложных систем. В то же время, если бизнес-модель допускает использование готовых продуктов или типовых решений, можно достичь результата в известные сроки и бюджет. Главное не смешивать разные подходы.

На концептуальном уровне это выглядит следующим образом. Любой бизнес работает в рамках установленной бизнес-модели, которая опирается на определенный набор инструментов, включая цифровые. Когда создается новый бизнес, требуется либо придумать комбинацию модели и инструментов с нуля, либо заимствовать ее. Когда бизнес создан и работает, он требует постоянного обновления из-за изменений внешней среды. Такие обновления могут быть эволюционными, когда постепенно развиваются инструменты и бизнес-процессы без изменения модели работы. Если для продолжения деятельности недостаточно простой адаптации, могут потребоваться революционные изменения в бизнес-модели и в поддерживающих ее инструментах. Тогда снова встает выбор: заимствовать известное или создавать новое.

Задачи создания и развития бизнес-моделей и инструментов можно разделить на три типа проектов: «Мозги» – это когда вы меняете бизнес уникальным образом, «Седина» – когда копируете чужой опыт, «Процедуры» – когда проводите регулярное обновление существующих инструментов без изменения бизнес-моделей.

Как видно на схеме жизненного цикла бизнеса, стадии перерождения и развития имеют определенную логику. Невозможно поддерживать работу компании, все время находясь в состоянии смены модели работы и радикального обновления используемых инструментов. Любой проект типа «Мозги» или «Седина» должен быть завершен, за ними последуют проекты по развитию типа «Процедуры». Но и у них есть предел, когда возможности адаптации существующей бизнес-модели и инструментов исчерпываются, и требуется новое радикальное обновление.

Думаю, теперь понятно, что далеко не всегда можно спрогнозировать параметры будущего проекта, а иногда невозможно даже предсказать результат. Бюджет и сроки – это производные от работ, которые предстоит выполнить, а они, в свою очередь, зависят от изначальной цели.

В этой главе я начал с типов проектов, хотя настоящим источником неопределенности в работе над цифровыми инструментами является отсутствие четких целей. Но это не вина бизнеса, как бы специалисты ни настаивали на этом. Конечно, они страдают от этого и часто жалуются: «Клиент не знает, чего хочет». Действительно, это так. Но поставить цель не так просто.

Для этого нужно пройти определенный путь. И бизнес находится в той же ситуации, что и специалисты, работающие над проектом. Часто проблема в бизнесе не ощущается явно, и требуется время и внимание, чтобы выявить истинные потребности, которые могут маскироваться под ложные цели. Они приводят к выбору неподходящего типа проекта. В ситуации, где достаточно доработки существующих цифровых сервисов, запускается сложный «прорывной» проект. И наоборот, когда требуется новое уникальное решение, пытаются остаться в рамках текущих инструментов.

Например, сейчас всех захватила концепция перевода деятельности компаний в онлайн. Кажется естественным организовать продажи через веб-сайт или мобильные приложения, освободить офис и перевести сотрудников на удаленную работу. Ожидается, что это сократит операционные расходы и привлечет больше покупателей. Взяв такую идею за основу, бизнес ставит целью проекта создание сервиса для онлайн-продаж и инструментария для удаленной работы. И терпит неудачу. Вместо роста продаж происходит спад, работа внутри компании сбоит, и качество работы, до того казавшееся удовлетворительным, ухудшается.

Как впоследствии становится понятно, расчет строился на предположении, что схема продаж и взаимоотношения между сотрудниками останутся прежними, только переместятся в онлайн. При этом было упущено то, что двигало продажи в традиционном формате и что заставляло крутиться колесо работы внутри компании. Игнорировался факт, что существующая бизнес-модель, которая хорошо работала в прошлом, не подходит под меняющуюся внешнюю среду и новый инструментарий. Думаю, это не самое приятное открытие, особенно после того, как израсходован бюджет и потеряно время, которое можно было использовать с большим смыслом.

Как видите, путь к пониманию истинной цели может быть долгим и дорогим. Чтобы обозначить цель как поиск новой бизнес-модели и поддерживающего ее цифрового инструментария, нужно разобраться с базовыми вещами, которые кажутся очевидными. Например, возьмем традиционную схему продаж и ее отличия в онлайне.

Есть старое правило трех факторов успешного магазина: расположение, расположение и расположение. Владельцы магазинов могут не подозревать, что успех зависит не от репутации, оформления, вежливости продавцов или ассортимента. Поэтому, запуская онлайн-продажи, они рассчитывают, что их клиентами останутся те же люди, что обычно заходили в их магазин. Что, конечно же, не так: поведение одних и тех же людей в магазине и в онлайне сильно отличается.

Прежде всего отличается причина посещения. В случае с обычным магазином это может быть немотивированный поступок («увидел и просто зашел посмотреть»), а для посещения сайта нужно явное желание и усилия для его поиска. Это не те же люди, что проходили мимо знакомых витрин каждый день и решили зайти. Более того, посетители могут быть из другого города или страны. В магазине человека встречает продавец, который может направить, предложить что-то подходящее, проконсультировать, и, главное, показать товар. В онлайне покупатель предоставлен сам себе, и на его поведение влияют другие факторы, на которые сайт повлиять не может. И это только пара отличий, на которые стоит обратить внимание.

Для запуска онлайн-продаж нужно пересмотреть почти все части существующей бизнес-модели: кто покупатели, параметры типовой покупки, ассортимент, ценообразование, способы продвижения, доставки, оплаты, возврата, гарантийного и сервисного обслуживания, места и объемы хранения товара, а также состав и роли сотрудников. Если вам кажется, что подобные вопросы способны решить разработчики веб-сайта, вы явно не на том пути. С ложной целью – разработать и запустить интернет-магазин, компания оказывается в тупике, специалисты неспособны ответить на вопросы бизнеса, а бизнес не может полноценно воспользоваться технологическим продуктом.

Может показаться, что привлечь бизнес-консультантов – хорошая идея. Часто компании так и поступают. И снова терпят неудачу. Причина в том, что, так же как IT-специалисты не разбираются в финансах или вопросах построения продаж, бизнес-консультанты не сильны в технологиях. Их знания поверхностны и часто уже неактуальны. Новую бизнес-модель невозможно разработать в отрыве от цифровых инструментов, и наоборот. В процесс преобразования должны быть вовлечены все стороны одновременно.

Живое воплощение неопределенности, или выбор специалистов для работы над проектом

Ни точное определение целей, ни правильный выбор типа проекта не устранят фундаментальный источник неопределенности – человеческий фактор. Все зависит от решений людей, участвующих в проекте и создающих цифровые продукты. Как я уже писал, природа технологических проектов кардинально отличается от классических отраслей. На производстве корректно запрограммированное оборудование или настроенный процесс гарантированно приводят к ожидаемому результату, а в проектной работе все зависит от способностей людей. Результаты проекта – плод их творческой фантазии. Специалисты, занимающиеся проектированием, дизайном, разработкой, работают с чистой мыслью, а их инструменты, такие как среды разработки или графические редакторы, – лишь способ выразить свои идеи. В любой задаче есть вариативность, и по большому счету не существует алгоритма для поиска «правильных» решений. Способность принимать решения, которые дадут нужный результат, определяется качествами конкретного специалиста, его опытом, знаниями, профессиональным подходом и способом мышления.

Однако бизнес при запуске проектов и выборе специалистов ориентируется на количественные параметры: сроки, бюджет, количество людей с определенными компетенциями. При этом упускаются не менее важные, просто не столь понятные, качественные характеристики кандидатов для реализации их проектов. Имея в виду кандидатов, я говорю не только о конкретных людях, но и о командах в целом как о единых проектных организмах. И люди, и команды обладают уникальными личными и профессиональными качествами, которые тоже нужно учитывать, а после запуска проекта уметь использовать эти качества для достижения результата. Такое умение – это тоже компетенция. Ее отсутствие со стороны бизнеса делает процесс работы над проектом непредсказуемым.

Даже один специалист способен сорвать работу всей команды, если от его результатов зависят остальные участники. Достаточно затянуть выполнение задачи или принять решения, которые в дальнейшем скажутся на всех частях будущего продукта. Например, неверный выбор технологии хранения данных может привести к тому, что сайт интернет-магазина не выдержит большой нагрузки. Это повлечет за собой серьезную переработку всех частей сервиса, потребует дополнительного времени и денег, и могут образоваться новые проблемы. Если ошибку допустит архитектор системы, ее цена может стать еще выше, а выяснится это, возможно, когда уже будет поздно что-то менять.

Удивительно, как часто компании игнорируют здравый смысл и выбирают исполнителей исключительно по формальным признакам. При выборе не проводится личных встреч, пока не определится победитель конкурса. В ряде случаев личный контакт и создание хороших дружеских отношений между сторонами проекта считается вредным, ведь может негативно повлиять на установленные в компании процедуры. Сказать, что это глупость, означало бы не придать проблеме большого значения. Такой подход наносит будущему проекту урон в его основании, потому что игнорирует суть проектной работы.

Иногда ситуацию спасает наличие необходимой компетенции со стороны компании, которая предоставляет услуги по созданию цифровых продуктов. Но чтобы проект не был лотереей, бизнес должен понимать критерии и подходы для выбора подходящих специалистов. В противном случае он становится заложником целей компании-поставщика. В зависимости от бизнес-модели такая компания склонна предлагать выгодные для нее условия. Например, постарается продать как можно больше часов своих специалистов или предложит продукт или технологию, формируя проектную команду в соответствии с типовой схемой внедрения. Все это может принести нужный результат, но только если соответствует изначальным целям бизнеса.

Идеально, когда на стороне бизнеса есть люди, которые понимают задачи проекта и разбираются в IT-индустрии. Конечно, такие навыки и опыт – большая редкость, поэтому бизнес идет более простым путем и делегирует поиск тех, кто сможет реализовать проект, в отдел закупок или тендерный комитет.

Тендерные процедуры

Несколько лет назад мы с Дмитрием «Goblin» Пучковым записали ролик о тендере Почты России на разработку мобильных приложений. Мы подробно разобрали не только конкретную историю, но и общую ситуацию с процедурой заказа программного обеспечения в коммерческих и государственных компаниях. Прошло много времени, но ситуация не изменилась. Это было бы простительно 20–30 лет назад, когда создание цифровых продуктов для бизнеса только начиналось. Теперь, когда слово «цифровизация» уже неприлично произносить, это выглядит странно.

Оставим в стороне вопросы коррупции, при которой бессмысленно искать здравый смысл в происходящем. В подобных ситуациях цели организаторов тендеров отличаются от целей бизнеса и часто им противоположны. Но даже если взять вариант с добросовестными намерениями, то, по сути, правила выбора поставщика для работы над проектом все еще не сильно отличаются от закупки мебели или поставки оборудования, что совершенно точно не идет на пользу ни бизнесу, ни проектной команде.

Как и в случае обычного заказа, бизнес формулирует требования к будущему продукту или сервису. Потенциальные исполнители готовят свои предложения на основе этих требований. Выбор делается с учетом предложенных сроков, стоимости и уровня доверия к поставщику. То, что на данном этапе подобные оценки носят условный характер, остается за скобками. Этот подход напоминает спиритический сеанс или гадание, несмотря на внешнюю солидность.

Бизнес таким образом стремится уменьшить неопределенность, считая, что контракт с заранее согласованными условиями служит гарантией получения нужного результата. Такой метод вступает в противоречие с природой проектной работы и фактически еще больше увеличивает неопределенность, и, кроме того, создает непомерные трудности на пути к цели проекта. Дело в том, что цифровой продукт, как я описал в первой главе, работает в симбиозе с бизнесом. Без знания технологических возможностей компания не сможет сформулировать требования к продукту. Это уравнение с несколькими переменными, где с одной стороны бизнес-модель, с другой – технологические инструменты. Делать одно в отрыве от другого бессмысленно. Поэтому когда бизнес не вовлекает IT-специалистов в процесс формулирования требований в формате отдельного проекта, то рискует получить результат, которым не сможет воспользоваться.

Такой подход ограничивает не только бизнес, но и компании, претендующие на заказ. У них мало исходных данных для подготовки предложения и короткие сроки для принятия проектных решений, на основе которых можно было бы оценить будущий проект. На качество этой работы влияет и факт, что она не оплачивается, а на вход в компанию поступает поток запросов на проекты, и нет ясности, какой из них будет выбран. В результате самые важные для проекта решения принимаются в наименее подходящий для этого момент, и, очевидно, они будут не самыми удачными.

Даже если по ходу проекта появятся новые вводные и более удачные способы реализации продукта или решения бизнес-задач, пересмотреть первоначальные решения не получится. Дело в том, что на них построена оценка, которой поставщик должен придерживаться в рамках изначальных договоренностей. Так, пытаясь устранить неопределенность и гарантировать выполнение проекта, бизнес, наоборот, лишает команду возможности сделать его лучше.

Теперь вернемся к основной теме – людям, которые работают над проектом. Выбор специалистов должен определяться объективными потребностями, вытекающими из целей и типа проекта, а также технологическими особенностями создаваемого продукта. На практике это становится ясно далеко не сразу. Формат процедуры выбора подрядчика требует определиться с требованиями к составу проектной команды в самом начале, когда происходит оценка. От количества специалистов, компетенций и профессионального уровня зависит стоимость работ и принципиальная возможность подобрать подходящих кандидатов к началу проекта. В результате судьбу проекта определяют не только преждевременные технические решения, но и люди, выбранные на ранней стадии. Каждый из них может быть отличным профессионалом, но не подходить для решения задач конкретного проекта. Универсальных специалистов не существует.