Что такое ИТ. Project Management Body of Knowledge, pmboK (англ. свод знаний по управлению проектами) руководство

• Название: Project Management Body of Knowledge, pmboK (англ. свод знаний по управлению проектами) руководство
• Дата: 30.12.2022
• Размер: 0.53 Mb.
• Имя файла: Что такое ИТ.docx
• Тип: Руководство; #869697
• страница: 4 из 4

Этап 5: Внедрение

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

В ходе этого этапа мы решаем следующей задачи:

Подготовка инфраструктуры, выполнение поставки, ввод в эксплуатацию	Куда и как разворачивать систему? Выполнение поставки, ввод в эксплуатацию Обычно процесс интеграции, поставки и развёртывания начинается в то же время, когда и непосредственно программирование. Однако это требуется только при наличии сложной архитектуры, частых релизов и т.п. Иначе данная задача может быть решена разработчиком и специализированными инструментами (например, в случае одного разработчика и сайта-визитки). Непосредственно ввод в промышленную эксплуатацию, развёртывание системы. Здесь стоит отметить, что необязательно ждать завершения проекта для просмотра прогресса. Для выполнения тестирования и проведения демонстрации могут создаваться дополнительные окружения и стенды (помимо промышленного).
Демонстрация системы	Демонстрация системы По возможности демонстрация проводится регулярно по мере разработки. Это помогает подтвердить, что ожидания совпадают с реальностью. Современные методологии рекомендуют организовывать процесс именно таким образом, чтобы автор идеи и все заинтересованные лица могли наблюдать прогресс.
Подготовка руководства пользователя	Подготовка руководства пользователя В идеальном мире инструкция для пользователей рождается по мере реализации продукта. До выпуска в большое самостоятельное плавание система должна проверяться на соответствие законам, а с пользователем (особенно в случае платных функций) заключается соглашение.
Завершение разработки, оформление закрывающей документации	Завершение разработки Попадание продукта в промышленную эксплуатацию в принципе означает окончание разработки, а значит, имеет смысл завершить работы и с административной точки зрения, в том числе подписать закрывающие документы.

Этап 6: Эксплуатация и развитие

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

В ходе этого этапа мы от выполнения задач уходим в цикл развития и задаем новые вопросы:

Продвижение и продажи	Продвижение и продажи На этапе продвижения выполняется огромный спектр работ, связанный с рекламой и монетизацией.
Технический мониторинг	Технический мониторинг Мониторинг работы системы желательно начинать со старта разработки. Эта задача необязательна. Важные нагруженные системы, для которых заявляются определённые характеристики и работоспособность которых влияет на прибыль, конечно, нуждаются в дополнительных инструментах контроля состояния.
Поддержка и развитие	Поддержка и развитие. Что говорят пользователи? На что жалуются? Что нравится? За что платят? Сбор информации для развития продукта происходит из множества источников. Можно продолжить коммуникацию с заинтересованными лицами, можно исследовать рынок, можно общаться напрямую с пользователями, можно собирать статистику использования, можно пересмотреть цели и изменить продукт. А можно остановиться и порадоваться успеху.

Модели ЖЦ проекта

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

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

Разберем, какие существуют виды моделей.

Название модели	Характеристика
Каскадная модель, водопад, waterfall	Для такой модели характерны точный образ продукта на старте, четкий план действий и конкретные задачи, а также постоянный контроль соблюдения этого плана. При таком подходе для перехода к новому этапу необходимо в полном объёме завершить задачи предыдущего.
Гибкая модель, аджайл, agile	В этом случае не требуется единовременное вложение всех средств для получения первой версии продукта и появляется возможность пересматривать видение продукта и адаптировать план. Такая модель дает возможность получать продукт частями (отдельными релизами).
Инкрементная модель	Комбинация подходов, условный мульти-водопад, когда план разбивается на отрезки, каждый из которых выполняется по водопадной модели, но при этом появляются контрольные точки для пересмотра плана, как в аджайле.
Спиральная модель	Жизненные циклы проекта, которые отличаются цикличностью, разрабатываются согласно спиральной модели. На каждом витке определяется эффективность разработки в соответствии с ее стоимостью, большое внимание уделяется оценке рисков для каждой итерации.

Существуют и другие модели, призванные в каждом конкретном проекте учесть особенности этого проекта: V-Model, RAD и т.д.

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

Как выбрать модель?

Чтобы выбрать подходящую модель, необходимо ответить на несколько вопросов о проекте.

1. 
   Кто заказчик?
   
2. 
   Какова суть проекта (сайт, автоматизация, продукт и пр.)?
   
3. 
   Есть ли видение конечного результата? Будут ли меняться требования по ходу работы?
   
4. 
   Насколько проект сложный? Каковы его сроки?
   
5. 
   Нужна ли подробная документация? Нужно ли выпустить первую версию продукта для проверки гипотез?
   
6. 
   Какие возможности (бюджет, инструменты, команда)? Какие риски?
   
7. 
   Какой уровень у специалистов?
   
8. 
   Какой опыт уже есть у создателей? Какие пожелания по организации работы?
   

Для осознанного выбора модели стоит обращать внимания и на прочие особенности моделей:

1. Поскольку водопад предполагает подготовку проектной документации в полном объёме до реализации (написания кода), то из-за отсутствия обратной связи от других специалистов существует риск упустить важные требования. А в сочетании с фиксированными сроками и стоимостью, цена ошибки может быть высокой, поэтому нередко менеджеры закладывают бóльшие коэффициенты при расчёте затрат на проект.

2. Аджайл, в котором коммуникации, напротив, придаётся особое значение, не позволяет в начале определить конечную техническую реализацию, а значит, специалистам необходимо закладывать бóльшую гибкость и расширяемость технического решения для потенциального роста. Эксперты даже советуют сразу закладывать 30-40% времени на переработку кода.

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

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