Бизнес-кухня, или Как заказчик выбирает digital-агентство. #2

Выбор подрядчика для реализации IT-проекта – сложный процесс, требующий вовлечения всех заинтересованных лиц со стороны заказчика. Независимо от внедряемого решения (облачные сервисы, разработка веб-решений или мобильных приложений, внедрение готовых продуктов CRM, ERP или BI) и способа проведения закупки (тендер, запрос КП, прямая закупка и т.п.), процедура выбора IT-компаний предполагает, как правило, одни и те же этапы. В предыдущей статье мы подробно рассмотрели, как проходит подготовка к новому проекту и каким образом формируется список потенциальных исполнителей. Сегодня подробно остановимся на основных подходах к анализу полученных КП и критериях выбора победителя.

• Стоимость проекта, т. е. капитальные затраты (CAPEX). Оценивается как бюджет конкретного контракта, так и стоимость его внедрения, которая может включать дополнительные расходы на лицензии, дополнительные сервисы, услуги или материалы.
• Последующие операционные затраты (OPEX). Мало провести имплементацию проекта, нужно понимать, сколько будет стоить его поддержка в будущем. Сюда входят и расходы на оборудование, и поддержка в широком смысле этого слова — обеспечение работы инфраструктуры и программного обеспечения, поддержка пользователей, внесение небольших изменений и доработок в проект.
• Ценообразование (Time & Material или Fix Price). Обычно российский заказчик не готов идти по модели T&M и хочет точно знать стоимость проекта до его начала. Тем не менее варианты T&M широко распространены за границей и все чаще встречаются и в отечественной практике.
• Сроки внедрения проекта. Нередко заказчик не может оценить степень своей вовлеченности в проект и ожидает, что он будет реализован максимально оперативно. При этом часто именно на согласование уходит больше времени, чем на разработку.
• Методология внедрения или разработки (Waterfall, Agile).Отечественные компании до сих пор предпочитают классический «водопадный» подход, но все чаще, понимая, что сложные проекты практически невозможно описать в одном ТЗ, рассматривают и альтернативные варианты. Один из таких подходов — итеративный waterfall — предполагает, что все работы разбиваются на этапы, а техническое задание составляется последовательно на каждый из них. Таким образом, к моменту написания ТЗ на последнюю часть первые оказываются уже реализованными.
• Применяемые инструменты (язык программирования, IDE или Framework). Иногда заказчики сами диктуют их использование, например для оптимизации расходов на поддержку в будущем (однотипность позволяет поддерживать продукты с меньшими затратами).
• Опыт подрядчика. Это очень важный параметр: получить крупный контракт компании, которая не реализовала ни одного серьезного проекта, просто нереально. Но иногда даже внушительное портфолио не гарантирует победу. Часто заказчик ожидает увидеть у подрядчика опыт успешной реализации проектов в его, заказчика, отрасли. Это обусловлено тем, что каждая сфера бизнеса имеет свою специфику, и заказчик справедливо полагает, что наличие у подрядчика аналогичного опыта работы упростит взаимопонимание и коммуникации и ему не нужно будет расшифровывать названия и термины, объяснять нюансы.
• Наличие у подрядчика собственных программистов. Не секрет, что на digital-рынке есть компании, которые не имеют своих разработчиков в штате, а используют труд фрилансеров. По возможности заказчики стараются избегать таких контрагентов, т. к. это чаще всего (хотя очевидно, что не всегда) говорит об отсутствии у подрядчика культуры разработки, а значит, не гарантирует качество проекта и повышает риск невозможности его дальнейшего развития.
• Выстроенный процесс разработки. Это еще один момент, который в целом охватывает принятые у разработчика процессы и методологии ведения проектов и разработки ПО. Здесь заказчики обращают внимание на наличие таких процедур, как код-ревью и Q&A (тестирование), а также на инструменты ведения проекта и его документации (Kanban, JIRA и др.).