Метод параноика. Как взять под контроль неопределённость в проектах при создании цифровых продуктов для бизнеса бесплатное чтение

Что такое «Метод параноика»

Вряд ли можно себе представить съёмку разных фильмов с одним и тем же актёрским составом. Участников необходимо подбирать каждый раз под новые роли. Создание цифровых продуктов тоже требует уникального состава специалистов, а значит нужен тот, кто сможет объединить их в действующую команду. «Метод параноика» заимствует идею из киноиндустрии и вводит роль продюсера, а вместе с ней и продюсерский подход работы над ИТ-проектами.

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

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

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

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

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

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

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

Как устроена книга

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

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

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

«Красная», «чёрная» и «белая»

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

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

1) 

инструментальный

– приёмы и навыки, которые вам необходимы в моменте для выполнения текущих задач;

2) 

интерпретационный

– внешнее объяснение и прогнозирование на основе фактов и способов оценки, которые вам недоступны, но вместе дают общую картину;

3) 

системный

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

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

По моей статистике, самые читаемые – это статьи с описанием инструментов и рабочих приёмов, например, «5 шагов для разработки мобильного приложения». Поэтому такой популярностью пользуются интернет-ресурсы, каналы и учебные курсы, на которых даётся ясное и простое объяснение базовых вещей, которые позволят сразу начать работу.

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

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

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

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

Теперь, после такого развёрнутого объяснения думаю мне будет проще показать планируемую структуру материалов по «Методу параноика». Если коротко, то:

1) 

«Красная» книга описывает

системный

уровень и через множество примеров даёт

интерпретацию

того, как можно смотреть на проектную работу.

2) 

«Чёрная» книга должна служить

инструментальным

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

интерпретационного

уровня в ней тоже не обойтись.

3) 

Ну и «Белая» книга – это парафраз от термина «

White

Paper

», обозначающего набор материалов, в сжатой форме дающих информацию о методе и его приёмах, т.е. чисто

инструментальный

уровень, в нашем случае комплект примеров проектной документации и артефактов.

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

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

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

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

История вопроса

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

Компания «ГАЛС СОФТ», которую я создал в 2002 году, тоже не была исключением. За 15 лет существования компании, вплоть до момента, когда я придумал новый формат – продюсирование ИТ-проектов, мы выполнили больше тысячи проектов и для большинства из них привлекали внешних участников. Очень быстро мы поняли, что недостаточно передать подрядчику простую постановку задачи в виде требований к продукту. Количество возможных интерпретаций и способов реализации могло быть каким угодно, но самое главное, что результат работы мог быть непредсказуемым. Постепенно все больше ключевых проектных решений мы начали принимать на своей стороне и уделять проектированию много внимания. Нашим языком общения с другими членами команд стала проектная документация. Это был единственный способ локализовать неопределённость, от которой зависела успешность проектов, которые мы выполняли для наших клиентов.

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

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

Чтобы мои слова не показались необоснованными, я приведу в качестве примера проекты, над которыми нам повезло поработать. История «ГАЛС СОФТ» началась с того, что я в возрасте 23 лет, будучи начинающим разработчиком с 5-летним стажем, при этом начитавшимся книг про проекты создания операционных систем, задумал сделать систему управления предприятием. На тот момент я уже участвовал в похожем проекте, и мои старшие коллеги показали, как системный взгляд на задачи позволяет находить нетривиальные решения. Например, мы спроектировали распределённую модель хранения данных о движениях товаров для нескольких офисов, не имеющих постоянного сетевого соединения. Все это было сделано ещё до появления чего-то похожего на блокчейн.

В работе над своим продуктом я хотел пойти дальше. Вместе с командой «ГАЛС СОФТ» мы разработали систему, имевшую встроенный редактор бизнес-процессов с внутренним скриптовым языком, распределённую сетевую архитектуру, базу данных с динамической структурой, возможность интеграции с внешними системами. На создание продукта ушло два года. Первым клиентом стал крупнейший на тот момент в России системный интегратор КРОК, в 2004 году внедривший нашу систему на полторы сотни рабочих мест. Мы сделали интеграцию с внутренним порталом для ведения документооборота по регламенту и со складской системой для отслеживания движений оборудования при поставках клиентам.

В дальнейшем мы много работали над созданием корпоративных систем и порталов, например, мы развивали корпоративные порталы Майкрософта и ТНК-BP, разрабатывали системы для анализа продаж в Хонде и Логитеке, делали внутренний сервис для Лаборатории Касперского. С каждым следующим проектом появлялся новый опыт, мы многому научились в том числе и у своих клиентов. При этом попытки создания сложных систем без предварительной глубокой проработки и проектирования всегда приводили к серьёзным проблемам в проектах.

Самые интересные проекты начались, когда мы занялись мобильными приложениями. Нашим первым проектом было создание мобильного приложения для livejournal.com. В тот момент в 2009 году «Живой Журнал» был жив как никогда и нам повезло создать приложения для Android и Windows Phone. Безусловно, это были непростые проекты, не в последнюю очередь по нашей вине. Тогда мы только искали оптимальный процесс, который бы объединял работу проектировщиков, дизайнеров и разработчиков. В дальнейшем мы создали приложения для Ведомостей и Афиши. А спроектированное и разработанное нами мобильное приложение издательского дома Коммерсантъ стало одним из лучших приложений в мире для СМИ по версии Google в 2014 году. На тот момент мы ещё не до конца отладили проектный процесс, но важность предварительного проектирования поняли в полной степени, и это давало свои результаты.

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

В определённом смысле, благодаря такому подходу, мы достигли потолка в развитии компании. Дальнейший рост компании потребовал бы, как это ни странно, упрощения проектов, над которыми мы могли бы работать. Мне же хотелось двигаться дальше и пробовать свои силы в чем-то ещё более интересном и сложном, кроме того, мне нравится непосредственно процесс проектирования и работать исключительно в административной роли мне не хотелось. Так, в результате я договорился об объединении «ГАЛС СОФТ» с одной из дружественных компаний и в 2016 году появился новый бренд на рынке заказной разработки мобильных приложений. Я же, после некоторого перерыва, запустил Цифровую артель Eleven, в которой выступаю как управляющий партнёр и продюсер ИТ-проектов.

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

Doom нового времени

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

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

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

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

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

Уже тогда я интуитивно начал понимать, в чем дело. У успеха продукта две стороны: одна – это решение задач пользователей, другая – быть первым, оказаться в нужное время в нужном месте и связать представление пользователей о задаче именно с ним, когда его название становится синонимом самой задачи. На мой взгляд, лучше всего об этом написал один из создателей Quake, Майкл Абраш в статье «Valve: как я здесь оказался, на что это похоже и чем я здесь занимаюсь»:

«Гэйб рассказывает об этом так. Когда он работал в Microsoft в начале 90-х, он провёл опрос на тему того, какое ПО установлено на компьютерах работников. На втором месте по популярности оказалась Windows.

На первом был Doom.

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

Успех Doom'а наглядно показал, что этот подход больше не работал. Не было особого смысла в том, чтобы делать одну и ту же вещь даже дважды; практически вся ценность сосредотачивалась в воплощении творческого порыва в самый первый раз. После того как Doom был выпущен, тысячи программистов и художников могли сделать что-то подобное (и многие делали), но никто из них и близко не подошёл к такому же эффекту. Проще говоря, если ты программист, возможно, ты вполне способен написать Facebook, или поисковый механизм как у Google, или Twitter, или браузер, и ты определённо можешь штамповать Tetris, или Angry Birds, или Words with Friends, или Farmville, или любую из сотен других чрезвычайно успешных программ. Однако прибыль от такой деятельности будет крайне мала, и в этом вся фишка – в эпоху Интернета софт имеет практически нулевую стоимость копирования и массивные сетевые эффекты, которые приводят к так называемой «спирали положительного фидбэка», а следовательно именно тот, кто первым сделает ход, будет доминировать».

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

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

Чем являются цифровые технологии в бизнесе

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

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

В такой бизнес-модели имеют значение следующие параметры:

– цена аренды (желательно ниже)

– сумма зарплат всех сотрудников (желательно ниже)

– среднее время присутствия гостей (желательно короче)

– средняя стоимость заказа (желательно выше)

– количество посетителей в день (желательно больше, чтобы не было пауз между периодами использования столиков и соответственно получения заказов)

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

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

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

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

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

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

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

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

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

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

Давайте я повторю ещё раз для ясности. Технологии являются инструментом, с помощью которого ведётся бизнес. При этом инструменты без бизнеса – просто инструменты. Как говорит мой диетолог, «самое важное слово в термине «биологически активные добавки к пище» это слово «пища». Одни инструменты ограничивают возможности, другие, наоборот, их создают. Ключевая задача состоит в выборе нужных инструментов, понимании возможностей, которые с их помощью можно получить, и умении применить выбранные инструменты. Точка.

«Проблема Газели» и терминология

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

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

«Проблема Газели» называется по названию грузового автомобиля марки «ГАЗ». Суть её в понимании разницы между транспортной компанией, использующей «Газели», и непосредственно автомобилем. Думаю, никто не сомневается, что отдельный автомобиль и даже целый автопарк не являются бизнесом. Автомобили используются как инструмент в бизнесе, с помощью которого предоставляется услуга. Но бизнес бизнесом становится за счёт всей остальной инфраструктуры: отдела продаж, штата водителей, бухгалтера, наличия клиентов, желающих что-то перевезти, и, конечно же, денег, используемых для взаиморасчётов. Более того, если автомобиль – это что-то статичное (хоть он и ездит), а вот бизнес – это процесс. Самое главное, что, убрав автомобиль и заменив его каким-либо другим инструментом, например носильщиками или самолётами, бизнес останется бизнесом. А вот убрав бизнес-инфраструктуру, автомобиль перестанет быть даже инструментом. Пропадает всякий смысл его существования.

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

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

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

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

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

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

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

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

Что такое успешный продукт

Я уже много раз использовал слово «успешный» по отношению и к продуктам, и к проектам. Теперь мне хотелось бы остановиться на этом подробнее. Что это в принципе такое – успешный продукт? А проект? Как это проявляется и каковы критерии, чтобы можно было говорить об успешности? Вопрос не праздный, потому что кроме чувства гордости за свою работу, в проектной работе часто возникают конфликты между бизнесом и ИТ-профессионалами по поводу результатов их работы. И важно быть уверенным, что все разговаривают на одном языке. Начнём с проектов по проектированию, разработке, внедрению, запуску, сопровождению и т.д. цифровых продуктов и сервисов. Пока будем использовать интуитивно понятное значение слова проект, но в следующей главе я подробно расскажу, какие бывают у них типы.

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

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

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

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

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

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

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

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

Что же делает продукт успешным кроме удачи и того факта, что вы оказались первым, кто «сделал первый ход», как говорил выше Майкл Абраш из Valve? Это — неоспоримая ценность для пользователей. Если думать только об интересах бизнеса, то легко сделать продукт, который будет не нужен пользователям. Но это не проблема цифровых продуктов, это общая проблема. Точно в такую же ситуацию можно попасть и с любым другим инструментом, и в целом бизнес-процессом. В качестве иллюстрации мне нравится пример про вендинговый аппарат, который я нашёл в одной из книг по проектированию.

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

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

Приёмы поиска технологических решений для бизнеса

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

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

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

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

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

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

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

Точка отсчёта

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

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

Мобильные приложения

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

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

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

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

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

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

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

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

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

Голосовые интерфейсы

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

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

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

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

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

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

Помимо сценариев использования голосовых интерфейсов через «умные» устройства, например колонки и телефонные звонки, есть уже ставшие традиционными мобильные приложения голосовых ассистентов. Вкратце их концепция такова: обращаясь к ассистенту в приложении, вы запускаете определённый сервис, реализованный в виде отдельного сценария голосового взаимодействия. Такие сервисы чем-то похожи на приложения и называются «навыками». Используя «навыки», вы можете, к примеру, заказать такси, поиграть в игру, узнать статус заказа и т.п. Любая компания или разработчик может создать свой «навык», чтобы он был доступен всем пользователям одного из голосовых ассистентов, таких как Алиса от Яндекса или Amazon Alexa. Но у подобного подхода есть один серьёзный изъян – сложность и неочевидность способа использования.

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

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

Отраслевые концепты

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

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

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

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

Дилемма бизнеса и ИТ-специалистов

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

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

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

Что не так?

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

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

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

Помню, как первый раз прочитал книгу Дэвида Майстера «Управление фирмой, оказывающей профессиональные услуги». На тот момент компании «ГАЛС СОФТ» было уже 10 лет, и к своему удивлению и восторгу в этой книге я нашёл ответы на большинство накопившихся вопросов. Читая некоторые абзацы, я просто кричал в голос, как все просто складывалось. Майстер писал книгу про юридические и консалтинговые компании, я же адаптировал описанную им модель под реалии нашей индустрии. В итоге, после анализа нашей деятельности мы кардинально поменяли формат работы с клиентами, а с некоторыми из них даже завершили проекты, т.к. стало понятно, что нам нужно сфокусироваться на чем-то одном. Любому, кто занимается проектной деятельностью, я настоятельно рекомендую прочесть как минимум две его книги – «Управление фирмой, оказывающей профессиональные услуги» и «Истинный профессионализм».

Какие бывают проекты

По мнению Дэвида Майстера, существует три обобщённых типа проектов – «Мозги», «Седина» и «Процедуры» (Brains, Grey hair, Procedures). Первый тип – решение ранее неизвестных задач, например, создание сервиса для новой банковской бизнес-модели. Такой проект в большой степени похож на исследовательскую работу, и специалисты, работающие над ним, должны быть опытными профессионалами, имеющими сложившийся подход к поиску нестандартных решений.

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

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

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

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

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

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

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

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

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

Кто и как делает проекты

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

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

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

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

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

Теперь посмотрим на другую область – левый верхний квадрант. Задачи здесь также простые либо неиндивидуализированные, но требуют регулярных коммуникаций. Важно понимать, что интенсивность общения клиента с исполнителем связана с самой сутью решаемых задач. Примером может служить продвижение бренда компании в диджитал-пространстве. Такую задачу невозможно выполнить раз и навсегда, требуется постоянная работа, учитывающая текущий контекст на рынке и меняющиеся бизнес-цели клиента. Квадрант называется «Сиделка» (Nurse).

Если в случае с «Фармацевтом» проекты так или иначе имеют срок, в течение которого нужно получить результат, то в случае с «Сиделкой» работа выстраивается вокруг долговременных целей клиента. Это характерная черта бизнес-модели представителей этой области – диджитал-агентств. На ум приходят термины «экаунт-менеджер», «медиа-план», «kpi» на календарный период, рекламные акции и т. п.

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

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

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

Теперь, когда мы разобрались с вопросом сложности, можно рассказать про два оставшихся квадранта. Начнём с правого нижнего, где уровень коммуникаций между клиентом и исполнителем низкий. Так же, как и «Фармацевты», компании из этого квадранта получают от клиента описание задачи, после этого выполняют проект и возвращаются обратно с готовым результатом. Ключевое отличие от «Фармацевтов» в том, что часто сутью задачи является выяснение, а в чем именно заключается проблема клиента и поиск её решения. Это похоже на то, как пациент приходит с проблемой к врачу, требующей сложной операции. После того как диагноз поставлен и ясно, что требуется сделать, пациент засыпает на операционном столе и просыпается уже после её завершения. Поэтому квадрант называется «Нейрохирург» (Brain Surgeon).

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

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

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

Экономика проектов

Экономика проектов также бывает разная в зависимости от типов проектов и формата работы над ними. Существует множество способов оценки и управления бюджетом проекта, но я хочу рассказать об одном аспекте, который как мне кажется, лежит в основе всех моделей и определяет саму возможность выжить подрядчику, а клиенту получить проект. Речь идёт о диаграмме приходов и расходов.

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

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

Бизнес-модели

Самая распространённая модель – ресурсная. Это когда у вас как у компании есть ресурсы, и вы ими торгуете. В случае с заказной разработкой ресурсы – это специалисты и их рабочие часы. При этом как вы упаковываете эти часы для клиента – сдаёте каждого разработчика в аренду на почасовой основе («Time & Material» или «T&M») или продаёте целиком команду на проект, не имеет значения. Важно то, что чем больше у вас ресурсов, тем потенциально больше вы можете на них заработать. А вот то, как реализуется этот потенциал, определяет отношение количества проданных часов к календарному периоду времени.

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

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

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

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

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

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

Ценность услуги в такой модели формируется не себестоимостью, от которой дальше рассчитывается стоимость для клиента путём добавления приемлемой для рынка наценки, а ценностью, которой услуга обладает в масштабах бизнеса клиента. Если, например, новая технология позволяет клиенту зарабатывать дополнительные 10% или, наоборот, экономить те же 10%, то при обороте компании в 100 млн рублей ценность услуги составит 10 млн рублей. Именно о таком порядке стоимости услуг и в таком ключе необходимо вести разговор, а вовсе не о часовой ставке. Часто одного часового общения с клиентом достаточно, чтобы повлиять на его бизнес. Вы же не будете говорить о стоимости часа в несколько миллионов рублей? Конечно, эта модель имеет и обратную сторону, когда одно и то же решение или технология даст пропорционально меньший результат в абсолютных значениях в бизнесе меньшего масштаба.

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

Приходы и расходы

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

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

Если клиент покупает не просто часы специалистов, а конкретные результаты работы, например дизайн-макеты сайта или в целом спроектированное и разработанное мобильное приложение, то это проектная работа. Для такой работы характерны нерегулярные поступления, т.е. оплата клиента, привязанная к этапам проекта, а не к календарным отрезкам. Более того, каждый этап может иметь разную стоимость, т.к. от этапа к этапу может быть задействован разный состав проектной команды. Стоимость может рассчитываться как по фактически отработанным командой часам («работа по T&M»), так и быть фиксированной («fixed price»). В случае с ресурсной бизнес-моделью, а большинство проектов так или иначе выполняются в этой модели, способ расчёта стоимости («работа по T&M» или «fixed price») просто вопрос того, кто несёт риски, клиент или подрядчик.

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

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

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

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

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

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

Экосистема и продюсирование проектов

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

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

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

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

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

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

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

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

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

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

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

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

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

Кто прав, бизнес или специалисты?

Цель любого проекта – создание инструментов, используемых бизнесом. Это может быть онлайн-магазин, через который компания продаёт товары, или банковский сервис для взаимодействия с клиентами, или мобильные приложения, используемые на складе сотрудниками логистической компании. В большинстве случаев для поддержания всех процессов требуется одновременно несколько инструментов. Часть из них создаётся на заказ непосредственно для бизнеса, часть подбирается из готовых продуктов либо внешних сервисов. Если бизнес развивается, то вместе с ним развиваются и цифровые инструменты. Т.к. внешняя среда любой компании все время меняется, то и сама компания должна непрерывно адаптироваться. А значит, любой действующий бизнес находится в постоянном процессе обновления своей инфраструктуры, в том числе и цифровой.

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

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

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

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

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

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

Почему невозможно точно оценить проект

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

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

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

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

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

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

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

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

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

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

Не обманывайтесь. Этой истории уже несколько десятков лет. Борьба идёт с переменным успехом, и периодически верх берет то одна, то другая сторона. Благодаря ей на свет регулярно появляются новые методологии и подходы. Дизайн-мышление, проектирование на основе персонажей, Jobs-to-be-done, Agile, Scrum, RUP, экстремальное программирование и т.д. Каждая новая модель предполагает радикальное улучшение процесса и возможность наконец-таки получать по итогу проекта именно то, что требуется. Но, как говорил Брукс в своей знаменитой книге «Мифический человеко-месяц», серебряной пули как не было, так и нет. И вряд ли она когда-нибудь появится. Методологии в основном служат не снижению неопределённости, а только лишь обосновывают перенос рисков со специалистов на бизнес.

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

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

Что делать с неопределённостью в проектах

Вы уже догадываетесь, к чему я веду? Если неопределённость является корневой причиной невозможности точного планирования, вероятно, есть смысл сконцентрироваться на поиске способов её уменьшения. Конечно, в силу описанных выше особенностей проектной работы устранить её полностью невозможно. Но это и не нужно. Большое значение имеет само знание о наличии неопределённости и её локализация в отдельных частях проектах. Как писал Нассим Талеб уже после выхода «Чёрного лебедя», объясняя ключевую идею книги, причиной неожиданности события может быть как сама природа такого события (например, метеорит), так и слепота наблюдателя (как экономический кризис 2008 года). И если с первой категорией мы ничего поделать не можем, то со второй такая возможность есть.

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

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

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

Как видите, мы все равно неизбежно приходим к тому, что поиск способов снижения или локализации неопределённости – необходимый путь к снижению проектных рисков и в конечном счёте к получению бизнесом именно того результата, на который он изначально рассчитывает. Это один из базовых принципов «Метода параноика».

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

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

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

Тип проекта как индикатор уровня неопределённости

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

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

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

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

Неопределённость растёт от «Седины» к «Процедурам» и достигает своего максимума в «Мозгах». Коротко это можно объяснить следующим образом. Цель проектов «Седина» как раз и состоит в том, чтобы избежать неопределённости. Используемые решения уже многократно проверены, специалисты участвовали в аналогичных проектах. План работ, сроки и бюджет рассчитываются исходя из прошлого опыта. Все это тем не менее не даёт 100% гарантии, т.к. существуют и другие причины неопределённости, о которых я дальше рассказываю в этой главе.

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

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

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

Бизнес на пороге кардинальных изменений

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

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

По какому пути может пойти компания в подобной ситуации? Вариант «Оставить все как есть» или сразу закрыть бизнес мы рассматривать не будем, он всегда с нами и его несложно реализовать. Есть ещё несколько вариантов, и каждому из них соответствует свой тип проекта, и в каждом из них своя степень неопределённости. Рассмотрим их по отдельности.

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

Никто не может сказать, что получится в результате проекта. Будет ли это онлайн-сервис, исключающий агентов и дающий возможность клиентам самим искать объекты недвижимости, или интеллектуальная система, наоборот, помогающая агентам проводить сделки, или мобильные приложения для 3D сканирования помещений с возможностью виртуальных экскурсий, заранее понять нельзя. Возможно, будет и то, и другое. Такой проект представляет собой серию исследований и экспериментов. От результатов одного шага зависит то, каким будет следующий. В какой-то момент может стать понятно, что решение не может быть найдено либо его поиск займёт непрогнозируемое время. Границы проекта в большей степени определяются возможностями бизнеса и пониманием того, где, по мнению владельцев бизнеса, лежит граница разумного риска ради получения новых возможностей.

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

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

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

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

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

Новое направление в бизнесе или стартап

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

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

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

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

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

Работающий бизнес, развивающий свои цифровые сервисы

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

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

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

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

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

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

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