2.0 Этапы развертывания проекта (Часть 1)

Посвящение #

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

Этот шаг требует, чтобы существующий или будущий руководитель проекта подготовил предложение с изложением упомянутых выше пунктов. Бизнес-планы и заявки на гранты являются примерами такого рода проектных предложений. Потенциальные спонсоры проекта оценивают заявку и выделяют необходимое финансирование, если она будет одобрена. Формально проект запускается после утверждения. На начальном этапе необходимо ответить на следующие вопросы:

  • Почему именно этот проект?
  • Возможно ли это физически?
  • Каковы желаемые результаты?
  • Каковы ограничения проекта (что входит в объем проекта)?

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

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

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

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

Определение #

После принятого плана инициирования проекта началась вторая фаза: фаза определения. На этом этапе максимально точно определяются требования, связанные с результатом проекта. Этот этап влечет за собой определение ожиданий всех сторон, участвующих в разработке проекта. Сколько файлов требуется для архивирования? Должны ли метаданные быть в формате Data Documentation Initiative (DDO) или Dublin Core (DC) будет достаточно? Разрешены ли файлы в исходном формате или только те, которые соответствуют «Предпочтительным стандартам»? Обязан ли депонент гарантировать правильную обработку набора данных в архиве, или это ответственность архивиста? Какие гарантии будут предоставлены в отношении результатов проекта? Список запросов может продолжаться бесконечно.

Очень важно установить потребности как можно раньше в процессе.

Wijnen (2004) устанавливает следующие типы проектных потребностей в качестве вспомогательного средства для запоминания:

  • Предпосылки
  • Требования к функционалу
  • Требования к функционалу
  • Ограничения дизайна

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

Законодательство, правила, регулирующие условия труда, и процедуры утверждения – все это примеры. Эти критерии неизменны внутри проекта.

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

На этапе определения проекта, который включал создание веб-приложения для консорциума крупных организаций, не было принято никаких решений о браузере, который будет поддерживать программа. Консорциум думал, что это будет Microsoft Explorer, поскольку это был браузер «для всех».

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

Когда стало очевидно, что два браузера несовместимы, программисты защитно ответили: «Разве они не могут установить Firefox? В конце концов, это бесплатно ». С другой стороны, организации обязали государственных системных администраторов, которые по какой-то причине отказались установить Firefox вместе с Explorer.

Даже если бы они захотели установить его, процедура была бы долгой, и потребовались бы дополнительные расходы, связанные с временем, затрачиваемым системными администраторами на работу. Наконец, определено, что приложение необходимо адаптировать для Explorer. Это потребовало значительно больших усилий, что привело к тому, что проект отстал от графика больше, чем он уже был, что потребовало согласования дополнительных затрат. Позднее расследование показало, что различные организации использовали разные версии Microsoft Explorer.

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

Позже пользователи (молодые люди) были вовлечены в разработку обучающей видеоигры. Когда игра была почти готова, ее решили протестировать с группой молодых людей. Их первые оценки казались умеренными и дружелюбными. Однако, когда их подтолкнули, они признали, что сочли игру «очень скучной» и «не будут играть в нее сами». Если бы эти молодые люди участвовали в проекте на раннем этапе, игра, несомненно, имела бы успех. В настоящее время игра практически не размещена на интернет-сайтах.

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

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

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

Список требований устанавливает параметры, в которых должен работать проект.

Этот список используется для оценки команды проекта. В результате клиент не может добавить дополнительные потребности после фазы определения.

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

Дизайн #

Набор требований на этапе определения может использоваться для принятия проектных решений. На этапе проектирования создается один или несколько дизайнов, которые, по всей видимости, соответствуют цели проекта. На этапе проектирования могут быть созданы диорамы, рисунки, блок-схемы, деревья сайтов, дизайн экранов HTML, прототипы, изображения и схемы UML, в зависимости от темы проекта. Руководители проекта используют эти чертежи, чтобы выбрать окончательный дизайн проекта. Далее следует фаза разработки. После того, как дизайн выбран, он не может изменяться на последующих этапах проекта, как в случае с определяющей фразой.

Фраза «конструкторский отдел» в данном случае неуместна; скорее, это относилось к группе сотрудничающих дизайнеров. Вдобавок все были слишком заняты, включая начальника отдела.

Один проект требовал создания ряда дизайнов, которые имели решающее значение для успеха проекта. Дизайн разработан молодым дизайнером в команде проекта. Хотя в конечном итоге за проекты отвечал руководитель группы дизайнеров, он никогда не присутствовал на собраниях проектной группы, во время которых рассматривались проекты. Руководитель проекта постоянно приглашал его и отправлял ему электронные письма с рисунками его молодого коллеги, но письма игнорировались. Руководитель проекта и молодой дизайнер ошибочно считали, что проект принял руководитель отдела. Началась фаза реализации. Когда проект был почти завершен, результат был доставлен начальнику отдела, который разозлился и приказал, чтобы все это можно было переделать.