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

Автор книги: Вадим Митякин

сообщить о нарушении

Текущая страница: 4 (всего у книги 7 страниц)

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

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

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

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

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

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

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

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

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

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

Что не так?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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