Всем привет! На основе своего опыта хотел поделиться мнением о границах проекта и понимании этих границ. Сразу предупреждаю, что не являюсь РП и менеджером проекта, а работаю аналитиком, поэтому со стороны РП или функциональных архитекторов картина может видеться по-другому.
Итак, что же такое проект? Процитирую определение: проект - это ограниченное во времени предприятие (мероприятие), направленное на создание уникальных продуктов и услуг или получение принципиально новых результатов. Таким образом четко определить, что заказчик хочет, невозможно, т.к. в природе второго такого проекта не существует. Соответственно проект имеет свои риски, которые заключаются в том числе в неопределенности границ проекта. И если при постройке, например, многоквартирного дома заказчик решит, что хочет подземный паркинг или вертолетную площадку на крыше – это будет однозначно новыми и даже, порой, - невыполнимыми требованиями. В айти проектах требования поступают постоянно, поэтому очень важно определить ту границу, где поступившие требования входят в рамки проекта, а какие являются новыми. Естественно, заказчик пытается включить в проект максимум требований за тот же бюджет, задача же исполнителя классифицировать требование как новое или дополнительное и соответственно получить за их реализацию дополнительную оплату.
Итак, посмотрим, на какой стадии проекта какое количество требований можно получить. Крупные проекты классически реализуются по водопаду, поэтому будем рассматривать проект по этой технологии.
1. Обследование
На обследовании осуществляется знакомство с бизнесом заказчика, его отделами. Команда проекта пытается определить объем проекта. Но, конечно, это будет очень приблизительно, хотя заказчик на данном этапе хочет получить уже четкий бюджет и сроки. В большинстве своем на этом этапе можно определить примерно 50% необходимых работ.
Процент зафиксированного объема работ к общему итоговому проекту
2. Техническое проектирование
Далее переходим к стадии технического проектирования. Обычно на этом этапе уже выбрана программа, на которой будем автоматизировать заказчика, поэтому нам проще в части того, что уже какие-то базовые механизмы в программе есть. По крайней мере закупать и продавать, например, она умеет. На этой стадии понятие объема проекта возрастает примерно до 60%, т.к. вводим примеры в программу, показываем специалистам заказчика примеры. Начинается более плотный диалог с заказчиком и сбор требований.
3. Техническое задание
После технического проектирования переходим к написанию ТЗ в формате to be. При этом активно участвует заказчик, вносит правки в ТЗ, замечания. И вот, наконец, после всех утверждений и согласований ТЗ готово. Но морально, да и практически заказчик не готов к тому, что ТЗ это окончательный объем требований, поэтому предлагает договориться, что если что-то вспомнят, то внесут в ТЗ. Это очень важная договоренность, тут решать менеджеру проекта – какие будут условия и договоренности. Как показывает практика – требования будут изменяться, дополняться и появляться постоянно. Мало того, что нам заказчик мог просто не дать контакт каких-то ключевых пользователей и мы не знаем в принципе об их требованиях и процессах. Организация – тоже живой организм, поэтому требования, которые были несколько месяцев назад, неизбежно меняются. Но это не относится к теме статьи, зафиксирую только, что на стадии отработки ТЗ понимание объема проекта возрастает до 85%.
4.Разработка
После получения ТЗ начинается разработка. На этом этапе границы проекта примерно остаются прежними. Заказчик самой разработки не видит и только отвечает на разного рода уточнения.
5. Сдача разработок и обучение сотрудников заказчика
Далее начинается интересный этап сдачи разработок и обучение. Вот здесь возникает основная масса новых требований, уточнений и т.п. Кроме того, на показах подключаются специалисты из смежных направлений и может выясниться, что то, что устраивает в работе склад, вовсе не устраивает финансистов. Приходим к тому, что нужен реестр требований, чтобы их квалифицировать. Квалификация идет как по виду – новое требование или уточнение требований проекта, а также устанавливаются приоритеты разработки. Соответственно требования уже могут уходить за границы проекта, их оставляют на развитие системы. Границы проекта тут нужно держать тщательно, т.к. одно требование может быть для реализации объемом как отдельный проект. В целом только тут, после сдачи разработок, приходит понимание объема проекта в целом. Определю процент понимания в 95%.
6. Процессное тестирование
И последний этап перед внедрением – процессное тестирование. Это уже огранка проекта, исправление ошибок, небольших требований и тому подобная активность. После этой стадии проект готов к запуску.
Какие выводы можно сделать на основании этой информации? На старте большого проекта границы можно очертить очень условные (предположить можно примерно 50-70% потребностей). Соответственно со стадиями проекта понимание минимально необходимого объема разработок для запуска программы повышается, а вот требования и вовсе уходят за границы проекта. Соответственно руководителям и менеджерам проекта нужно закладывать риски и уметь договариваться с заказчиком об увеличении бюджета проекта и сроков.
