Ошибки при организации тендеров на разработку ПО

#Тезисы

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

Январь, 2017

Разницу между покупкой готового костюма и пошивом на заказ понимает каждый. Закупка в офис мебели и создание мобильного приложения отличаются еще больше. Но почему-то конкурсная процедура одинаковая.

"Мозги" — нужен совершенно новый инновационный продукт, который не имеет аналогов

"Седина" — вы внедряете существующее решение, например, запускаете внутри компании сервис bitrix24

"Процедуры" — задачи по поддержке существующего сайта, когда нужно регулярно обновлять промо-страницы под новые маркетинговые кампании

Даже те компании, в которых делают различие, могут не учитывать тип проекта. Когда вы заказываете проект, нужно понимать, какой именно у вас тип проекта. В зависимости от типа, сам подход к поиску подрядчика, а потом и к самому проекту будут сильно отличаться.

Для проектов "Мозги" либо "Седина" недостаточно в запросе указать формальные требования к квалификации разработчиков, описать требования к продукту и дальше выбирать по стоимости, срокам и репутации подрядчика. Отличается сам процесс закупки.

Проект разделяется на два равноправных этапа – поиск решения (проектирование) и создание (разработка) продукта. Для проектирования заключается один договор, на разработку – другой. До того, как закончится проектирование, сказать сколько будет стоить разработка можно только ориентировочно.

Прочтите первые несколько глав книги Дэвида Майстера, там отлично показана разница между типами проектов

Дальше классика. Прошли январские праздники, начали искать подрядчиков, организовали конкурс. Старт разработки планировали на 1 февраля, но смогли к этому сроку подготовить только конкурсную документацию. Время вроде бы еще есть, нагоним.

Прошёл конкурс, выбрали подрядчика. Уже март, еще минус месяц. Ребята, ваш бюджет мы подтверждаем, но вам нужно успеть к 1 мая. Вы планировали в июне? Придётся поторопиться, иначе контракт не подпишем. Подрядчик соглашается на зажатые сроки.

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

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

Чтобы так делать, внутри компании у всех участников проекта должна быть установка на действительную цель проекта, а не на то, чтобы каждый отдельный сотрудник выполнил свой личный KPI.

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

Кажется странным, но проектирование нужно прежде всего клиенту, а не подрядчику. Оно заставляет команду подрядчика разобраться как следует со всеми деталями в начале проекта. Это ведь не только клиенту хочется быстрее уже начать просто делать, а не заниматься этой скучной работой по анализу требований и проработке архитектуры. Особенно если контракт подписан по модели Time&Material, когда оплачивается все фактически потраченное на проект время.

За внешним видом скрывается внутреннее устройство

Кажется странным, но проектирование нужно прежде всего клиенту, а не подрядчику. Оно заставляет команду подрядчика разобраться как следует со всеми деталями в начале проекта.

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

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

Умный клиент понимает, что продукт требует полного проектирования и настаивает на нем. В результате проект получается быстрее и качество выше.

По ходу проекта часто происходит подмена понятий и уже проект по разработке превращается в бизнес-проект. Т.е. большой внутренний проект внутри клиента сокращается до размеров проекта по разработке продукта. И получается, что разработка продукта приравнивается к созданию нового направления.

Руководство банка помнит первоначальная цель — открытие направления по продаже страховок. Когда приходит момент сдачи приложения, то все ждут, что его запуск автоматически запустит новое направление в бизнесе. Но операционной команды нет и внутренние процессы не готовы, что дальше происходит, можно догадаться.

Я сам часто оказывался в подобной ситуации и пока вижу только один способ с ней бороться – все время напоминать клиенту, чтобы он не забывал про свою часть.