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