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

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

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

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

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

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