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

Вадим Митякин, 2019

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

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

Что не так?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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