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

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

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

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

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

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

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

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

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