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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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).

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

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

Страницы: 12 » »»