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

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

Artefact, артефакт – это объект, созданный в процессе работы: документ, схема, макет, задача, компонент, код и т.д.

Этап 1: Определение концепции

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

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

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

Этап 2: Планирование и подготовка

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

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

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

Этап 3: Проектирование (спецификация, архитектура)

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

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

Описание ролевой модели	Как пользователи отражены в ролях? Изучение пользователей даёт нам понимание, какие роли должны быть в системе и с какими ограничениями.
Описание бизнес-процесса	Какой бизнес-процесс? Случается, что для определения функций необходимо сравнить текущий бизнес-процесс as is (как он есть) и будущий бизнес-процесс to be (как будет), например, с учётом автоматизации какого-либо отрезка процесса. Эта задача опциональная, но она может быть полезна.
Моделирование вариантов использования	Какие действия нужны в системе? Также опциональная, но полезная задача - моделирование вариантов использования. Описание вариантов использования и сценариев использования помогают более детально рассмотреть взаимодействие человека с системой, то есть доступные действия в системе.
Создание наброска	Как система примерно будет выглядеть? Полезно, но не обязательно сделать набросок. Уровень детализации наброска будет зависеть от целей. Такой набросок можно сделать еще на этапе концепции и продемонстрировать заинтересованным лицам для обсуждения.
Детализация требований	Какие конкретно требования? Для оценки и планирования достаточно было обозначить функции, дополнить схемой или наброском. Но для того чтобы спроектировать конкретное техническое решение, продумать все детали, выбрать нужные технологии и корректно выполнить все задачи на разработку, нужно погрузиться в детальное описание. Такое описание может оформляться в спецификацию или критерии приёмки пользовательских историй. Требования – это не просто хотелки всех желающих высказаться и повлиять на проект. Ответственные за описание требований должны постоянно проверять полноту, взаимосвязи, корректность, влияние на цели и т.д. Помимо функциональных возможностей, нужно описывать требования к безопасности, надежности, скорости работы и т.д.
Проектирование UI/UX	Как будет выглядеть система? Какое будет поведение? Над пользовательским интерфейсом мы задумываемся с момента идеи, отражаем его в наброске. Далее, уже с пониманием своей целевой аудитории и всех шагов пользователя, продумываем его путь в системе и внешний вид самой системы. Иногда речь может идти о дизайне новых устройств, дизайне звуков и так далее.
Моделирование требований	Как посмотреть на систему до реализации? Требования – это не только перечисления функциональных возможностей, а пользовательский интерфейс – это не вся система. Чтобы отразить различные уровни, слои, срезы системы, мы моделируем требования, используя разные виды диаграмм. Например, рассматриваем отдельно модель данных, статусы документов и пр. Бизнес-процесс, о котором шла речь раньше, – это тоже модель.
Проектирование архитектуры	Как будет устроена система? Из каких частей? Какие технологии использовать? В продолжение темы моделирования, важно сказать о проектировании архитектуры решения. Требования, макеты, диаграммы позволяют продумать структуру, внутреннее устройства системы, возможные интеграции, а также выбрать технологии, инструменты, языки программирования и пр.

Этап 4: Реализация и тестирование

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

В ходе этого этапа мы приближаемся к воплощению:

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