Границы проекта - взгляд аналитика

10.02.23

Управление проектом

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

Всем привет! На основе своего опыта хотел поделиться мнением о границах проекта и понимании этих границ. Сразу предупреждаю, что не являюсь РП и менеджером проекта, а работаю аналитиком, поэтому со стороны РП или функциональных архитекторов картина может видеться по-другому.

Итак, что же такое проект? Процитирую определение: проект - это ограниченное во времени предприятие (мероприятие), направленное на создание уникальных продуктов и услуг или получение принципиально новых результатов. Таким образом четко определить, что заказчик хочет, невозможно, т.к. в природе второго такого проекта не существует. Соответственно проект имеет свои риски, которые заключаются в том числе в неопределенности границ проекта. И если при постройке, например, многоквартирного дома заказчик решит, что хочет подземный паркинг или вертолетную площадку на крыше – это будет однозначно новыми и даже, порой, - невыполнимыми требованиями. В айти проектах требования поступают постоянно, поэтому очень важно определить ту границу, где поступившие требования входят в рамки проекта, а какие являются новыми. Естественно, заказчик пытается включить в проект максимум требований за тот же бюджет, задача же исполнителя классифицировать требование как новое или дополнительное и соответственно получить за их реализацию дополнительную оплату.

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

 

1. Обследование

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

 

 

 

Процент зафиксированного объема работ к общему итоговому проекту

 

2. Техническое проектирование

Далее переходим к стадии технического проектирования. Обычно на этом этапе уже выбрана программа, на которой будем автоматизировать заказчика, поэтому нам проще в части того, что уже какие-то базовые механизмы в программе есть. По крайней мере закупать и продавать, например, она умеет. На этой стадии понятие объема проекта возрастает примерно до 60%, т.к. вводим примеры в программу, показываем специалистам заказчика примеры. Начинается более плотный диалог с заказчиком и сбор требований.

 

 

3. Техническое задание

После технического проектирования переходим к написанию ТЗ в формате to be. При этом активно участвует заказчик, вносит правки в ТЗ, замечания. И вот, наконец, после всех утверждений и согласований ТЗ готово. Но морально, да и практически заказчик не готов к тому, что ТЗ это окончательный объем требований, поэтому предлагает договориться, что если что-то вспомнят, то внесут в ТЗ. Это очень важная договоренность, тут решать менеджеру проекта – какие будут условия и договоренности. Как показывает практика – требования будут изменяться, дополняться и появляться постоянно. Мало того, что нам заказчик мог просто не дать контакт каких-то ключевых пользователей и мы не знаем в принципе об их требованиях и процессах. Организация – тоже живой организм, поэтому требования, которые были несколько месяцев назад, неизбежно меняются. Но это не относится к теме статьи, зафиксирую только, что на стадии отработки ТЗ понимание объема проекта возрастает до 85%.

 

 

4.Разработка

После получения ТЗ начинается разработка. На этом этапе границы проекта примерно остаются прежними. Заказчик самой разработки не видит и только отвечает на разного рода уточнения.

 

 

5. Сдача разработок и обучение сотрудников заказчика

Далее начинается интересный этап сдачи разработок и обучение. Вот здесь возникает основная масса новых требований, уточнений и т.п. Кроме того, на показах подключаются специалисты из смежных направлений и может выясниться, что то, что устраивает в работе склад, вовсе не устраивает финансистов. Приходим к тому, что нужен реестр требований, чтобы их квалифицировать. Квалификация идет как по виду – новое требование или уточнение требований проекта, а также устанавливаются приоритеты разработки. Соответственно требования уже могут уходить за границы проекта, их оставляют на развитие системы. Границы проекта тут нужно держать тщательно, т.к. одно требование может быть для реализации объемом как отдельный проект. В целом только тут, после сдачи разработок, приходит понимание объема проекта в целом. Определю процент понимания в 95%.

 

 

6. Процессное тестирование

И последний этап перед внедрением – процессное тестирование. Это уже огранка проекта, исправление ошибок, небольших требований и тому подобная активность. После этой стадии проект готов к запуску.

 

 

Какие выводы можно сделать на основании этой информации? На старте большого проекта границы можно очертить очень условные (предположить можно примерно 50-70% потребностей). Соответственно со стадиями проекта понимание минимально необходимого объема разработок для запуска программы повышается, а вот требования и вовсе уходят за границы проекта. Соответственно руководителям и менеджерам проекта нужно закладывать риски и уметь договариваться с заказчиком об увеличении бюджета проекта и сроков.

Проект проектная деятельность оценка проекта этапы проекта

См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2771    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14302    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5852    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4699    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2748    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4187    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10670    0    biimmap    79    

75

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13093    0    Evil Beaver    17    

117
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. roman72 379 18.02.23 01:03 Сейчас в теме
Техническое задание - это конечный результат этапа "Техническое проектирование", а не отдельный этап.

Разработка - этап зависящий от качества исполнения этапа "проектирование".
При качественном проектировании разработка и проектирование должны стремится к соотношению 20/80.
20% длины этапа - разработка, а 80% проектирование - такое соотношение признак качества, его уже достаточно.
Если разработка ещё менее 20%, то это ещё более лучший показатель качества.
Чем качественнее проектирование, тем выше скорость работы разработчика. И качество его работы.

Качество проектирования зависит от этапа "Обследование" (аналитический этап).
Качество этапа "Обследование", т.е. работа аналитика, определяется точностью формулировки конечного результата проекта.
Формулировка конечного результата проекта - это детальное содержание Акта выполненных работ, которое определяется в начале проекта, максимум, после этапа "Обследование".
На входе у аналитиков Требования, на выходе "Акт выполненных работ" (прототип к подписанию) - качество работы аналитика определяется тем, насколько качественно Требования клиента декомпозированы в описание конечного результата, оформленного в виде Акта.
Точность формулировки конечного результата проекта означает, что клиент его подпишет, а если откажется, то подпишет суд, поскольку клиенту не отвертеться от такой детализации Акта выполненных работ.

Все конструкции проектного договора "по ходу дела поймём, выявим, внесём изменения и втиснем в проект" - от лукавого.
Любое отклонение от собранного списка Требований должно иметь следствием изменение срока и/или цены проекта (договора).
Иначе доходность исполнителя от проекта уменьшается. Ожидаемая прибыль не зарабатывается.

Другое дело, что клиент хочет знать цену/срок проекта ещё ранее этапа "Обследование", включая сроки/стоимость самого этапа "Обследование", т.е. уже на этапе пресейла или первого звонка в офис исполнителя.
Здесь могут помочь только методы типа COCOMO, типа как здесь
https://infostart.ru/1c/articles/1176530/
Оставьте свое сообщение