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