Разработка #
На этапе разработки собираются все необходимые компоненты для реализации проекта. С потенциальными поставщиками или субподрядчиками связываются, составляется график, заказываются расходные материалы и инструменты, а сотрудники, помимо прочего, проходят инструктаж. Когда фаза реализации готова к началу, фаза разработки завершена. Все вопросы должны быть разъяснены лицам, ответственным за исполнение.
Формальная фаза разработки, возможно, не нужна для некоторых проектов, особенно небольших. Что важно, так это то, чтобы было очевидно, что должно быть выполнено на этапе реализации, кем и когда.
Реализация #
На этапе реализации проект обретает форму. Этот этап влечет за собой фактическое построение результата проекта. Программисты кодируют, дизайнеры создают визуальный контент, подрядчики конструируют, и происходит настоящая реорганизация. Это период, в течение которого проект становится очевидным для посторонних, которые могут полагать, что проект только начался. В
Реализация — это этап «делания», и он имеет решающее значение для сохранения динамики на протяжении всего этого периода.
В одном случае команда проекта не знала, что один из основных членов команды собирается стать родителем и поэтому будет полностью недоступен в течение примерно месяца. Когда пришло время его заменить, был вызван внешний эксперт, чтобы не дать команде остановиться. Хотя команда смогла удержаться, внешняя экспертиза отняла значительную часть бюджета.
По завершении этапа внедрения результат сравнивается со списком требований, установленным на этапе определения. Кроме того, он оценивается по отношению к дизайну. Например, может быть выполнено тестирование, чтобы подтвердить, что онлайн-приложение поддерживает Internet Explorer 5 и Firefox 1.0 и выше. Можно проверить, была ли отделка здания построена в соответствии с соглашением или действительно использовались материалы, указанные на этапе определения. Этот этап считается завершенным, когда все критерии выполнены, а полученный продукт соответствует дизайну.
Те, кто участвует в проекте, должны помнить, что очень редко можно получить продукт, который точно удовлетворяет всем критериям, установленным на этапе определения. В ходе выполнения проекта неожиданные события или достижения в понимании могут вынудить команду проекта отклониться от первоначального набора требований или других проектных документов.
Это возможная причина разногласий, особенно если внешний клиент разместил заказ на результат проекта. В некоторых случаях заказчик может ссылаться на соглашения, достигнутые в процессе определения.
Как правило, требования не могут быть изменены после завершения процесса определения. Это также относится к дизайну: после завершения процесса дизайна дизайн не может быть изменен. Если это становится необходимым (как это иногда бывает), руководитель проекта должен обеспечить, чтобы изменения были доведены до сведения всех заинтересованных сторон (особенно лиц, принимающих решения или потребителей), как можно скорее. Кроме того, очень важно, чтобы внесенные изменения были должным образом зарегистрированы, чтобы избежать недопонимания в будущем. Дополнительная информация о документации проекта включена далее в это руководство.
Закрыть и продолжить #
Хотя это и важно, последующий шаг часто упускается из виду. На этом этапе принимаются все необходимые меры для обеспечения успеха проекта. Последующий этап может включать в себя создание руководств, инструктаж и обучение пользователей, создание службы поддержки, поддержание результата, оценку самого проекта, написание отчета по проекту, организацию вечеринки. отметить достижение результата, переход команды проекта к директорам и роспуск команды проекта.
Ключевой вопрос последующего этапа — когда и где завершится проект. Руководители проектов часто шутят, что первые 90% проекта продвигаются быстро, а последние 10% могут занять годы.
Границы проекта должны оцениваться с самого начала, чтобы проект был закрыт на последующей стадии, когда он достигнет этих пределов.
Иногда для вовлеченных лиц неясно, будет ли конечным результатом проекта прототип или работающий продукт. Это особенно характерно для творческих инициатив с неопределенными результатами. Хотя клиенты могут ожидать получения продукта, команда проекта может полагать, что разрабатывает прототип. Такие ситуации наиболее вероятны в период наблюдения. Рассмотрим пример разработки программного обеспечения, предназначенного для проверки новой идеи. Были серьезные опасения по поводу возможности вообще получить какие-либо выводы.
В итоге проект дал положительные результаты. Команда разработала программное обеспечение, которое хорошо работало, по крайней мере, в рамках тестовой среды. Клиент, незнакомый с информационными технологиями, считал, что получил функциональный продукт. В конце концов, он работал на компьютере в его офисе. Хотя программа работала хорошо, когда ее поместили на ПК пятидесяти сотрудников, у прототипа возникли проблемы, и в некоторых местах она стала нестабильной.
Хотя программисты могли восстанавливать программное обеспечение, у них было мало времени из-за их участия в следующем проекте. Вдобавок они мало интересовались ремонтом того, что считали экспериментальным предметом. Спустя несколько месяцев, когда Microsoft представила Windows Service Pack 2, программа перестала работать полностью. Клиент был в ярости из-за того, что «продукт» был снят с производства.
