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

10.02.23

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

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

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

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

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

 

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

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

 

 

 

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

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

См. также

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    3006    0    biimmap    39    

38

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    4122    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3451    0    user1853337    8    

29

Кейсы проектов Руководитель проекта Бесплатно (free)

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

20.12.2023    3332    0    1СERP    21    

31

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

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

05.07.2023    15082    0    ASchekachev    37    

55

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

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

28.06.2023    6180    0    stnslv    5    

25

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

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

10.02.2023    5242    0    andironenko    3    

32

Компетенции и навыки РП Бизнес-аналитик Руководитель проекта Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5803    0    MariaTemchina    28    

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

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

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

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

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