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

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

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

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

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

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

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

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

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

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

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

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

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