Заказная разработка. Ищем баланс между добром и злом
Привет, Хабр!
Меня зовут Кристина Спирина, я руководитель проектов в ИТ.
Знаю, что выбор подрядчика для заказной ИТ-разработки может быть таким же коварным, как путь на Темную сторону Силы. Кажется, что все под контролем, но один неверный шаг — и проект рискует оказаться в хаосе. В этой статье мы разберем, с какими «имперскими» трудностями сталкиваются заказчики в ходе проектов, и как выбрать надежного «джедая» для успешной разработки.
Зачем нужен руководитель проекта на стороне заказчика
Заказная разработка — эффективный метод реализации своих идей. Не нужно содержать свою ИТ‑команду, все сделают под ключ, риски на стороне подрядчика и минимальное участие заказчика в проекте.
Именно так думает заказчик, когда выбирает вариант реализации ИТ-продукта с привлечением подрядчика. Но на практике возникают сложности.
Нужно как-то выбрать подрядчика, нужно взаимодействовать с командой подрядчика и контролировать сроки по проектным задачам. И тут на помощь заказчику приходит руководитель проекта:
представляет интересы заказчика в проекте и знает бизнес-процессы;
проверяет оценку работ подрядчика на адекватность;
взаимодействует с подрядчиком и контролирует сроки по проектным задачам;
выявляет и снижает риски провала проекта;
при необходимости решает конфликтные ситуации.
А что ожидать от проекта, если такого специалиста не будет?
Во-первых, команда подрядчика постоянно будет обращаться непосредственно к заказчику по любым вопросам. А таких вопросов будет много: от предоставления контактов сотрудников до решения конфликтных ситуаций.
Во-вторых, никто не застрахован от недобросовестного подрядчика, который без контроля будет срывать сроки проекта и, в итоге, не достигнет целей проекта.
В-третьих, единой картины по проекту нет, и не понятно, что происходит.
Наличие руководителя проекта со стороны заказчика существенно снижает риски провала проекта. Он знает, на каком этапе находится проект, какие проблемы есть на проекте, как их решить или минимизировать, чтобы не навредить проекту. А заказчик спокоен за то, что результаты проекта будут соответствовать заявленным.
Выбираем подрядчика
Выбор правильного подрядчика является половиной успеха проекта.
В моей практике сформировалось для этого несколько шагов. В начале мы:
Четко формируем цель проекта, бизнес-задачу, которую должны решить. Обычно в своих проектах я составляю карту функциональности — это перечень функционала нового/изменяемого ПО с приоритезацией обязательности. Дальше мы его будем использовать уже при сравнении подрядчиков, и это поможет нам сделать правильный выбор.
Карта функциональности ПО
Формируем стандартные требования к поддержке продукта (если мы не планируем сопровождать его в дальнейшем самостоятельно), к стеку технологий и архитектуре решения. В основном это стандартные требования, определенные в компании.
Определяем формат работы с подрядчиком: Time Material, где вы платите за фактически отработанное время каждого сотрудника или Fix, где вы платите за итоговый результат. Мои проекты — преимущественно Fix договоры.
И только после этого приступаем к анализу рынка и поиску исполнителей, которые могут выполнить нашу задачу.
В основном мы запрашиваем у подрядчиков стандартные документы: предварительное КП, проведение демо продукта (если уже что-то есть), предполагаемый план-график проекта, как они это видят, состав команды. Но еще мы просим заполнить анкету, которая даст нам больше информации о подрядчике и поможет сформировать правильное мнение о нем.
Шаблон-анкета подрядчика
Анкета подрядчика
Получив информацию от подрядчиков, формируем сравнительную таблицу и по бальной шкале проводим оценку.
Если у подрядчика уже есть аналог продукта, который мы хотим — вспоминаем про карту функциональности и проводим анализ на соответствие.
Чтобы определить, кто наилучшим образом соответствует требованиям и бюджету, оцениваем:
опыт — документарное подтверждение опыта работы с данной предметной областью;
компетенции — проводим собеседование с участниками команды (аналитик, разработчик, архитектор и руководитель проекта подрядчика), чтобы понять самим уровень и экспертизу заявленных сотрудников;
репутацию подрядчика — референсы других клиентов подрядчика;
стоимость работ — не стоит ориентироваться на низкую стоимость и не учитывать качество и опыт подрядчика. Соблюдайте баланс между ценой и качеством.
И вот с помощью сравнения многих факторов нам удалось выбрать «лучшего» подрядчика для нашего проекта. А какой он в деле, уже покажет реализация проекта.
Методы борьбы с недобросовестным подрядчиком
На практике мы можем столкнуться с тем, что подрядчик не такой уж «хороший», каким показался при выборе.
Рассмотрим, с какими проблемы сталкивалась я в своих проектах, и что делать, чтобы их избежать, ведь, лучше учиться на чужих ошибках.
С нами работают по остаточному принципу
Во время тендера подрядчик направляет все свое внимание на вас и демонстрирует большую заинтересованность и высокую скорость ответа. Но как только договор подписан, подрядчик начинает терять интерес к вам и все дольше отвечает в чатах, появились более приоритетные заказчики, и вы не в их числе.
Что делать:
Еще этапе тендера согласуйте с подрядчиком выделенную команду, которая будет фул-тайм работать над вашем проектом. Хорошо если это будет обязательным требованием вхождения в проект.
На старте проекта установите регулярные отчетные встречи с подрядчиком, на которых будут обсуждаться статус и прогресс их работ, возможные проблемы. Регулярность 1—2 раза в неделю.
Срыв срока, нет результата работы
Еще одна частая проблема — подрядчик не может презентовать то, что сделано, переносит демо, показывает не то, чего мы ожидаем.
Кажется, что разработка либо вообще не двигается, либо движется значительно медленнее утвержденного графика.
Что делать:
Установите план-график демо заранее, не старте проекта.
Определите, какой именно артефакт должен стать результатом проделанной работы за определенный период.
Узнайте причину данной ситуации. Могут быть проблемы с ресурсами: заболели или уволились. Нужно выстроить с подрядчиком доверительные отношения, чтобы он не боялся говорить о возможных рисках еще до того, как случится проблема. Возможно, даже совместно искать варианты решения.
Совместные дейли. На проекте со стороны подрядчика есть руководитель проекта, но в случае, если вы видите, что прогресса нет — начните ходить на дейли подрядчика, чтобы больше разобраться в причинах срыва сроков. Если на проекте совместно работает и команда подрядчика и команда заказчика, можно устраивать совместные встречи.
Низкое качество релизов
На первом релизе функционала выявляется качество передаваемого продукта. Передают практически не рабочий функционал. При доработке ломают то, что работало раньше.
Что делать:
Включить в артефакты проекта ПСИ, которые будет согласованы со стороны заказчика и проверены на полноту. Таким образом, мы минимизируем кейсы, которые не будут проверены на стороне подрядчика перед передачей релиза.
Консистентность и полнота данных на тестовых стендах. Важно чтобы тестовые стенды, где тестирует заказчик и где тестирует подрядчик, были схожи.
Требование проводить регресс подрядчиком перед передачей релиза вам.
Споры и конфликты
Часто возникают споры о том, что включено, а что не включено в объем обязательств подрядчика.
Что делать:
Составлять функциональную карту продукта на самом начальном этапе.
Составлять матрицу ответственности подрядчика и заказчика, в том числе, с фиксацией того, какие артефакты в проекте должны появится и кто является исполнителем по их созданию (БТ, ТЗ, ПСИ и т.д).
Ответственно подходить к согласованию со стороны заказчика ТЗ на разработку функционала, чтобы минимизировать проблемы в дальнейшем.
Заложить в договор некоторый объем дополнительных дней на доработки по Change Request. Может быть, изменятся требования в рамках реализации проекта или, действительно, включить в проект что-то из функциональности.
Стараться решать все споры путем переговоров. Но если не получается, эскалируем на руководство компании подрядчика или приступаем к юридическим аспектам ваших договорных отношений.
Завершение
Я поделилась основными проблемами, с которыми сталкивалась при работе с подрядчиками, и тем, как боролась с ними в роли Руководителя проекта на стороне заказчика.
На вкус и цвет все подрядчики разные, но главное — найти к ним подход. Правильно выстроенная совместная работа с подрядчиком — равно успешное выполнение проекта.
Учитесь на чужих ошибках и меньше совершайте своих. Если у вас так же, как у меня, возникали сложности на проектах — поделитесь ими в комментариях, расскажите, как решали. Всем успешных проектов!
