проект Вадима Митякина

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

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

Короче не благодарите, я решил сделать эту работу за вас. Описал типичные шаги, которые ведут ваш тендер в бездну. Вот четыре ошибки, которые приводят к проблемам с проектами:
Заказ проекта рассматривается как очередная закупка, сегодня столы, завтра мобильное приложение
Сроки проекта назначаются еще до начала проекта и далее не обновляются
Проектирование продукта ограничивается дизайном
Клиент ожидает вместе с продуктом еще и бизнес

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

Разницу между покупкой готового костюма и пошивом на заказ понимает каждый. Закупка в офис мебели и создание мобильного приложения отличаются еще больше. Но почему-то конкурсная процедура одинаковая.
"Мозги" — нужен совершенно новый инновационный продукт, который не имеет аналогов
"Седина" — вы внедряете существующее решение, например, запускаете внутри компании сервис bitrix24
"Процедуры" — задачи по поддержке существующего сайта, когда нужно регулярно обновлять промо-страницы под новые маркетинговые кампании
Даже те компании, в которых делают различие, могут не учитывать тип проекта. Когда вы заказываете проект, нужно понимать, какой именно у вас тип проекта. В зависимости от типа, сам подход к поиску подрядчика, а потом и к самому проекту будут сильно отличаться.
Для проектов "Мозги" либо "Седина" недостаточно в запросе указать формальные требования к квалификации разработчиков, описать требования к продукту и дальше выбирать по стоимости, срокам и репутации подрядчика. Отличается сам процесс закупки.

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

Сроки проекта назначаются исходя из ранних планов и далее не обновляются

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

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

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

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

Проектирование продукта ограничивается дизайном

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

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

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

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

Клиент ожидает вместе с продуктом еще  бизнес

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

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

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

Подведем итоги:

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

На сладкое интервью про тендер Почты России на разработку мобильных приложений, которое мы записали с Гоблином (Дмитрием Пучковым).