Нужны измеряемые критерии завершения проекта (контрольные тесты)

⇐ ПредыдущаяСтр 10 из 18Следующая ⇒

Поговорим теперь о формальном завершении проекта. Чтобы не спорить о том, выполнено ли задание или нет, требуется определить измеряемые критерии достижения цели. В случае ПО это контрольные тесты. Измеряемые критерии позволяют формально завершить проект, разделив ожидания и требования.

Альтернативой формальному завершению проекта является бесконечное движение в сторону ожиданий. Рассмотрим, что может получиться в данном случае:

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

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

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

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

Формальное закрытие проекта

Сравним формальное закрытие проекта с проектом " без конца".

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

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

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

Тем не менее, многие предпочитают неформальное ведение проектов. Этот объясняется влиянием политических рисков. Формальный проект позволяет установить ответственность, и эта ответственность часто пугает как исполнителя проекта, так и заказчика. За неудачу формального проекта несут ответственность в равной степени и Исполнитель, и Заказчик. Оба подписались под требованиями к проекту и взяли на себя ответственность, причем эта ответственность носит личный характер.

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

В нашем случае, менеджер на встрече с топ-менежером заказчика добился решения об измеряемых критериях завершения проекта.

Закрытие и оценка проекта

Менеджер поставил в план разработку документа, описывающего контрольные тесты (рисунок 1.29). Далее в соответствии с тестами продукт был приведен в порядок и в срок сдан заказчику.

Как видно по рисунку, проект примерно в 2 раза превысил ожидаемую себестоимость.

Тем не менее, следует отметить, что в условиях нашего примера проект был для менеджера новым и подвергался влиянию политических рисков. Достигнутый результат в данных условиях можно считать хорошим (нормальным). Данный вывод подтверждается и статистикой Standish Group: 53% проектов завершаются успешно, но с превышение бюджета в 1, 9 раза.

Рисунок 1.29. Тестирование результатов проекта

Анализ статистики

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

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

Приведем типичные статистические показатели Канера-Фолка и прокомментируем их относительно нашего примера.

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

Для разработки ПО характерны следующие статистические показатели соотношения технологических стадий:

- разработка — 37%;

- сопровождение — 63%.

Этап разработки разделяется на стадии со следующими пропорциями:

- постановка — 34%;

- кодирование — 21%;

- тестирование — 45%.

Если рассмотреть наш пример, то мы увидим, что данная статистика работает. Однако если мы посмотрим на первоначальный план, то увидим несоответствие трудоемкости стадий плана средним статистическим показателям. Проверяйте план на соответствие статистике!

Вопросы

1. Что такое проект?

2. Что такое ресурсы проекта?

3. На какие стадии можно разбить жизненный цикл проекта?

4. В какой документ включается смета расходов?

5. Куда входит конструкторская документация?

6. Какой документ завершает проект?

Тесты

1. Можно ли производственную деятельность назвать проектом?

+ Ответ 1. да, если говорить об определенном периоде

Ответ 2. нет, нельзя

Ответ 3. проект — это любая деятельность

2. Какие величины являются ресурсами проекта?

Ответ 1. материальные возможности

+ Ответ 2. деньги, время, люди, материалы

Ответ 3. финансы

3. Как поступить, если нужно переделать техническое задание?

Ответ 1. техническое задание не переделывается

Ответ 2. терепечатать его

+ Ответ 3. написать и подписать протокол согласования

4. Нужно ли в проекте проводить анализ существующей информации?

Ответ 1. нет, не нужно, так как всё делаем по техническому заданию

+ Ответ 2. поиск и анализ информации входит в эскизный проект

Ответ 3. анализ информации делается до проекта

5. Куда входит смета?

+ Ответ 1. смета расходов на проект — в ТЗ, смета расходов на объект — в ТП

Ответ 2. это отдельный документ

Ответ 3. рассчитывается в эскизном проекте

6. Нужно ли делать чертежи для технического предложения и ЭП?

Ответ 1. нет, не нужно

+ Ответ 2. обычно делаются эскизы

Ответ 3. да, нужен полный набор чертежей

7. Что такое зонирование территории?

Ответ 1. разбивка на квадраты

Ответ 2. это огораживание зон заборами

+ Ответ 3. разделение на зоны в зависимости от её предназначения

8. Какой критерий полноты информации об изделии на чертежах?

+ Ответ 1. изготовление и контроль изделия без вызова автора чертежа

Ответ 2. соответствие ГОСТ и нормалям

Ответ 3. при

Министерство образования и науки Российской федерации

__________

Федеральное агенство по образованию

___________

⇐ Предыдущая 5 6 7 8 91011 12 13 14 Следующая ⇒