Читать книгу: «Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности», страница 4

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

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

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

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

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

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

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

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

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

Глава 2
Как устроена индустрия создания цифровых продуктов

Содержание главы:

• Зачем нужно знать устройство IT-индустрии

• Типы проектов

• Форматы работы

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

• Экосистема IT-индустрии и продюсирование проектов

Зачем нужно знать устройство IT-индустрии

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

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

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

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

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

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

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

Типы проектов

По мнению Дэвида Майстера, существует три обобщенных типа проектов – «Мозги», «Седина» и «Процедуры» (Brains, Grey Hair, Procedures).

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

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

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

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

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

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

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

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

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

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

Форматы работы

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

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

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

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

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

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

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

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

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

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

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

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

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

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