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

Оптимально для проектов сроком до 3х месяцев и трудоемкостью  до 1 чел/года. Для изготовления более  сложной системы, необходимо, чтобы  ее отдельные модули внедрялись не дольше 3х месяцев, в противном  случае методика не применима.

Учет модели ценообразования. Данная методика разработана с учетом рискованного для Исполнителя и  выгодного для Заказчика "ценообразования  за весь проект". Это не исключает  возможность применения более простой  расчетной схемы повременного типа.

Заказчик готов заплатить  больше, но за результат, а не за усилия (время) Исполнителя. Покупка проекта, а не времени Исполнителя позволяет  Заказчику снять с себя значительную часть ответственности за свои проблемы и ошибки.

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

Методика применима для  небольших заказных и серийных систем.

Данный этап проводится по договору о консалтинге, т.е. оплата этапа повременная. В виду неопределенности задачи спланировать заранее ее стоимость  невозможно. Себестоимость этапа  примерно равна 10% себестоимости всех работ.

Основной продукт этапа - документ "Постановка Задачи" (Product Vision).

Данный документ должен определять цель проекта и включать в себя список ключевых требований без подробной  расшифровки. Важный критерий: несмотря на отсутствие подробного описания, список должен поддаваться статистической оценке трудоемкости со стандартным  отклонением (риском) в приемлемых рамках.

На основе "Постановки Задачи" требуется составить документ "Экономическое обоснование".

Данный документ должен содержать  статистическую оценку трудоемкости (себестоимости) работ. С другой стороны, должен быть сделан анализ экономического эффекта  от внедрения.

При анализе используется статистика трудоемкости (эффективности) аналогичных проектов. При отсутствии данной статистики неизбежны ошибки в оценках причем на порядок, в данном случае следует попробовать получить статистику опираясь на результаты разработки/демонстрации прототипов.

Для оценки рисков требуется  разработать как минимум 2 простейших прототипа (они могут быть выполнены  как один).

"Интерфейсный прототип" - это прототип, имитирующий 1-2 важнейших диалоговых окна программы. Необходимо проанализировать реакцию пользователей с целью изучения рисков связанных с модификацией их требований.

"Архитектурный прототип" - это прототип, проверяющий самые критические места будущей архитектуры. Данный прототип служит для оценки технологических рисков.

Данные прототипы не должны далее использоваться при разработке системы, требуется начать разработку заново. Это связано с тем, что  прототипы служат для нахождения оптимальных решений, но таковыми не являются.

Оценку рисков требуется  выразить в виде возможного превышения трудоемкости (пессимистичная оценка). Именно из данной оценки следует исходить при определении общей трудоемкости (цены) продукта.

В результате мы имеем нечетко  сформулированное задание "Постановка Задачи" и оценку стоимости в "Экономическом  обосновании". Риски от нечеткости требований должны быть покрыты пессимистичной оценкой. С точки зрения юридического договора "Постановка Задачи" может  играть роль ТЗ, но с указанием в  договоре на то, что более приоритетный документ "Документация пользователя" (см. ниже) и система будет приниматься по "Приемочным испытаниям" (см. также ниже)

 

Степень Важности	Продукт этапа	Описание продукта
1	Постановка Задачи	Цель проекта. Список ключевых требований без подробной расшифровки
2	Экономическое обоснование	Оценка экономического эффекта  и себестоимости проекта.
3	Интерфейсный прототип	Модель одного из ключевых интерфейсов пользователя
4	Архитектурный прототип	Модель для оценочной  проверки выбранной архитектуры

 

Условие завершения этапа: подписание сторонами "Постановки Задачи" и "Экономического обоснования".

На данном этапе производится создание серии рабочих прототипов, охватывающих всю систему, и согласуются  все требования с ключевыми пользователями. Себестоимость этапа составляет примерно 30% разработки. Если на данном этапе производится поиск и разработка целой технологии, то его себестоимость увеличивается примерно в 3 раза.

Одновременно в виде пошаговых  сценариев (use case) пишется "Документация Пользователя", раскрывающая пункты "Постановки Задачи". Сначала создаются сценарии поведения системы в целом. Затем создаются индивидуально направленные сценарии - должностные инструкции пользователям. Запрещается использование в документации слова "должен", время описания выбирается как неопределенное или настоящее. Такие стилистические ограничения необходимы для того, чтобы "Документация пользователя" играла не только роль спецификации, но и роль документации для пользователя, как следует из названия документа.

Возможны два варианта взаимодействия "прототип-документация":

1) При относительно четком  представлении о функциональности  до разработки очередного прототипа  должны быть готовы основные  пункты "Документации", описывающие  его работу. В данном случае "Документация" одновременно играет роль нечеткой  спецификации на прототип. Нечеткость  заключается в том, что "Документация" может быть исправлена с целью  соответствия реализации в прототипе,  если прототип реализовал удачное,  но не документированное решение.

2) При отсутствии представления  о лучшем варианте реализации  по краткому заданию на основе "Постановки Задачи" сначала  создается прототип. После одобрения  Заказчиком документируется желаемое  поведение системы.

Пользователь оценивает  прототип и документацию одновременно. Если, осмотрев прототип, пользователь согласен с описанием поведения  конечной системы в "Документации Пользователя", осуществляется переход  к созданию прототипа следующего функционального модуля.

Как отмечено выше, "Документация" фактически заменяет классическое ТЗ,. таким образом на лицо ряд преимуществ:

Описание программы делается на языке, понятном пользователю.

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

Нет необходимости править  ТЗ и Документацию одновременно.

Как правило, заботятся в  первую очередь о ТЗ, обычно документация далеко отстает от текущего состояния  программы. В данном случае этого  не наблюдается.

 

Степень Важности	Продукт этапа	Описание продукта
1	Прототип всей системы	Прототип системы - это  набор прототипов проверяющий не менее 80% пользовательских и архитектурных решений. Все прототипы должны быть приняты Заказчиком.
2	Документация (ТЗ)	Должны быть составлены и  одобрены сценарии не менее 80% поведения  конечной Системы.

 

Условие завершения этапа: этап завершается письменным соглашением  Заказчика и Исполнителя о  том, что конечная система будет  принята, если соответствует последней  согласованной версии "Документации Пользователя"; архитектура и  требования стабильны, не предвидится  изменений более чем на 20% в  ходе следующего этапа.

Важное замечание о  юридической стороне. Вполне возможно, что не удается достигнуть согласия ключевых пользователей с прототипом или описанием в Документации. В данном случае Заказчик должен принять  волевое решение на уровне топ-менеджера  и определиться с требованиями. Если этого не происходит, или если требования выходят за рамки "Постановки задачи" с учетом надбавок на риск, рекомендуется  пересмотреть трудоемкость/цену проекта  или прекратить его. Указанная возможность  прекращения проекта должна быть предусмотрена в договоре.

 

Заключение

 

Широкое применение методика планирования работ на основе проекта  получила в строительстве. Например, для управления проектом сооружения гидроэлектростанции на реке Черчилль в Ньюфаундленде (полуостров Лабрадор). Стоимость проекта составила 950 млн. долларов. Гидроэлектростанция строилась  с 1977 по 1986 г. Этот проект включал более 100 строительных контрактов, причем стоимость некоторых из них достигала 76 млн. долларов. В 1984 году ход работ по проекту опережал расписание на 18 месяцев и укладывался в плановую оценку затрат.

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