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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 3
Оценка проектов, планирование и неопределенность

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

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

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

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

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

• Бизнес и цели проекта

• Живое воплощение неопределенности, или выбор специалистов для работы над проектом

• Ограничения традиционных подходов к управлению проектами

• Проектирование и неопределенность

• Итог

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

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

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

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

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

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

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

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