Что такое ИТ. Project Management Body of Knowledge, pmboK (англ. свод знаний по управлению проектами) руководство
 Скачать 0.53 Mb.
|
|
Workflow, воркфлоу, рабочий процесс — это набор стандартных последовательных действий, которые выполняются на постоянной основе в компании или в команде для достижения определённых целей, например, для реализации проекта. Есть различные подходы, рекомендации известных авторов и экспертов, но в целом процесс разработки сводится к нескольким этапам: Определение концепции. Планирование и подготовка. Проектирование. Реализация и тестирование. Внедрение. Эксплуатация и развитие. Несмотря на последовательное представление этапов, задачи каждого этапа часто выполняются одновременно, в большем или меньшем объёме, в зависимости от степени готовности продукта и других факторов. Выполнение задачи, проведение мероприятия в хорошо построенном процессе приводит к появлению артефакта или части продукта. Артефакт — это объект, созданный в процессе работы: документ, схема, макет, задача, компонент, код и т.д. Например, к артефактам относятся: результаты обсуждения, которые фиксируются в протоколе или заметках; проведённые интервью, которые сохраняются в аудио- или текстовом формате; процесс планирования, который сопровождается созданием графика, расписания; изучение клиентского пути, оформленное в виде визуальной карты; результат проектирования архитектуры, выраженный в виде схемы, модели; код, который создается в процессе программирования; результаты тестирования в виде отчёта с описанием ошибок и т.д. Разберем по отдельности каждый из этапов жизненного цикла проекта. Определение концепции Предполагается, что сама идея продукта к моменту старта проекта уже существует. Основное внимание на этом этапе уделяется уточнению целей, проверке гипотез, анализу рынка, поиску оптимального решения проблемы. В ходе определения концепции мы выполняем следующие задачи: 1) Определение стейкхолдеров С кем говорить о проекте? Кто влияет на проект? На данном этапе надо определить стейкхолдеров, то есть заинтересованных лиц, участников, которые влияют на реализацию проекта, владеют нужной информацией, участвуют в разработке и т.д. 2) Сбор информации, создание словаря Что говорят участники? Что важно знать для реализации? Какую терминологию надо использовать? Чтобы собрать всю необходимую информацию для последующей работы, рекомендуется использовать различные методики: от интервью до обсуждения набросков будущей системы. В ходе сбора информации необходимо понять проблемы и потребности, условия для разработки продукта, текущее состояние дел и возможности, потенциальные риски, процесс, структуру компании, нормативные документы, правила, ограничения, пожелания, ожидания и так далее. Уже на этапе определения концепции формируется словарь, который уточняется по мере детализации. Важно поддерживать его актуальность и полноту. 3) Определение потребности Какая существует проблема? Каковы причины ее появления? Из всей собранной информации необходимо выявить основную потребность или главную проблему, которую нужно решить. 4) Исследование целевой аудитории Кто наши пользователи? Целевая аудитория, пользователи входят в группу заинтересованных лиц и изучению требуется уделить особое внимание, особенно если их лояльность будет влиять на успех продукта. 5) Изучение пути клиента/пользователя Какие действия пользователи совершают для решения проблемы? Какие у них ожидания? Нужно изучить действия пользователя, понять текущие шаги, его путь до знакомства с продуктом, во время использования и после. 6) Анализ рынка и конкурентов Есть ли конкуренты или аналоги? Как решают проблему конкуренты? Проектируя будущую систему, важно изучить отрасль, конкурентов, хорошие решения, аналоги и сделать выводы. 7) Описание образа продукта Что мы будем делать? В результате сбора и анализа данных должно появиться общее описание продукта, его образ, видение, концепция. 8) Определение целей Каковы наши цели? Конечно, цели закладываются на этапе идеи, но по мере анализа информации цели оформляются в более точные формулировки. 9) Описание функций Какие функции нужны пользователю? Какие функции должны быть в системе? Понимая потребности пользователя, ситуацию на рынке и собственные цели, мы можем сформулировать, какие функции должны быть в системе. 10) Принятие решения и заключение договора Делаем ли проект? Этот вопрос необходимо задавать себе и команде на каждом шаге (особенно на старте, когда взвешиваются все за и против). На курсе мы, конечно, рассматриваем вариант, когда решение о разработке положительное — делаем. Однако исследование иногда приходит к выводу о том, что в этом конкретном случае лучше наоборот, не делать. Этот шаг подразумевает также закрепление отношений заказчика и исполнителя в договоре и оформление прочих юридических документов. Планирование и подготовка К моменту планирования и подготовки уже есть понимание, какой продукт мы хотим разработать. Но до старта нужно также оценить возможности по дальнейшей разработке. В ходе этого этапа мы получаем ответы на следующие вопросы: 1) Управление бэклогом Что в итоге нужно сделать? Для оценки и расчётов полезно все функции фиксировать в виде пользовательских требований. Например, можно составить список пользовательских историй. И если на этапе концепции было важно охватить все пожелания пользователей и других заинтересованных лиц, то на этапе планирования нужно расставить приоритеты и обозначить границы. 2) Оценка трудозатрат Сколько нужно времени на разработку? На данном этапе сложно давать точную оценку, однако уже можно обозначать приблизительные трудозатраты для расчёта расходов. 3) Обозначение границ и версий Что сделаем в первую очередь? Реализацию проекта можно разделить на логические отрезки. В гибких методологиях рекомендуется выделять минимальный объём функций для выпуска первой версии. Это необходимо для итерационного выпуска продукта и скорейшего получения обратной связи. 4) Планирование бизнес-модели Сколько стоит разработка? Какие ресурсы доступны? Как продавать продукт? Время рассчитать бюджет. Имея оценку трудозатрат, можно посчитать затраты на реализацию. Также стоит учитывать прочие расходы, в том числе на будущее внедрение, продвижение и поддержку. Если проект подразумевает получение прибыли, то это отличный момент продумать модель монетизации, оценить ёмкость рынка и возможную окупаемость. 5) Оценка и управление рисками Что может пойти не так? Далее важно оценить риски, возможные последствия и необходимые действия для уменьшения риска, продумать шаги в случае наступления рисков. 6) Выбор модели/методологии Как будем разрабатывать? Обычно к этому моменту уже просматривается подход к реализации. Происходит выбор модели, методологии разработки, определяются роли, планируются мероприятия. По необходимости проводится обучение, консультации. 7) Создание команды Кто будет разрабатывать? Конечно, последовательность шагов будет зависеть от проекта и стартовых условий автора идеи. На этом этапе команда может уже активно включаться в работу, либо может стартовать набор необходимых участников. 8) Организация работы Что по условиям работы? Какие нужны инструменты? Важные организационные вопросы: офис, оформление, ПО и прочие инструменты для выполнения задач, проведения коммуникаций и так далее. 9) Формирование плана работ Какой план? Сейчас у нас есть уже не просто идея, а целая концепция продукта (сайта, приложения) с описанием функций, которые мы расставили в порядке приоритетности. У нас уже есть целый офис жаждущих работать специалистов. Нужен план или дорожная карта с описанием полномочий работников, конкретных шагов по достижению целей, паттернов поведения в случае непредвиденных ситуаций. 10) Постановка задач Что конкретно делать каждому? Разные команды по-разному могут выполнять переход от требований к конкретным задачам исполнителя. Важно изначально договориться (или принять правила компании), какого размера будут задачи, какие формулировки будут использоваться, как будут следить за прогрессом и так далее. Проектирование (спецификация, архитектура) На самом деле, проектирование началось уже с того момента, когда мы зафиксировали ожидаемые функции. Описывая требования бизнеса и требования пользователя, изучая проблематику и рынок, мы уже формируем образ будущего продукта. Однако теперь нам надо этот образ детализировать. В рамках этого этапа необходимо определиться со следующими вопросами: 1) Описание ролевой модели Как пользователи отражены в ролях? Изучение пользователей даёт нам понимание, какие роли должны быть в системе и с какими ограничениями. 2) Описание бизнес-процесса Каков бизнес-процесс? Случается так, что для определения функций необходимо сравнить текущий бизнес-процесс as is (как он есть) и будущий бизнес-процесс to be (как будет), например, с учётом автоматизации какого-либо отрезка процесса. Эта задача опциональна, но она может быть полезной. 3) Моделирование вариантов использования Какие действия нужны в системе? Тоже опциональная, но полезная задача — моделирование вариантов использования. Описание вариантов и сценариев использования помогают более детально рассмотреть взаимодействие человека с системой. 4) Создание наброска Как система примерно будет выглядеть? Не обязательно, но полезно сделать набросок. Уровень детализации наброска зависит от целей. Его можно сделать еще на этапе концепции и продемонстрировать заинтересованным лицам для обсуждения. 5) Детализация требований Какие конкретно требования? Для оценки и планирования достаточно было обозначить функции, дополнить схемой или наброском. Но для того чтобы спроектировать конкретное техническое решение, продумать все детали, выбрать нужные технологии и корректно выполнить задачи, нужно детально описать задание. Описание может оформляться в спецификацию или критерии приёмки пользовательских историй. Требования — не просто «хотелки» всех желающих высказаться и повлиять на проект. Ответственные за описание требований должны постоянно проверять полноту, взаимосвязи, корректность, влияние на цели и т.д. Помимо функциональных возможностей, нужно описывать требования к безопасности, надежности, скорости работы и т.д. 6) Проектирование UI/UX Как будет выглядеть система? Какое будет ее поведение? Над пользовательским интерфейсом мы задумываемся с момента появления идеи, отражаем его в наброске. Далее, уже с пониманием своей целевой аудитории и всех шагов пользователя, продумываем его путь в системе и внешний вид самой системы. Иногда речь может идти о дизайне новых устройств, звуков, принципа работы. 7) Моделирование требований Как посмотреть на систему до реализации? Требования — это не только перечисления функциональных возможностей, а пользовательский интерфейс — это не вся система. Чтобы отразить максимальное количество уровней системы, мы моделируем требования, используя разные виды диаграмм. Например, рассматриваем отдельно модель данных, статусы документов и пр. Бизнес-процесс, о котором шла речь раньше, — это тоже модель. 8) Проектирование архитектуры Как будет устроена система? Из каких частей? Какие технологии использовать? Требования, макеты, диаграммы позволяют продумать структуру, внутреннее устройства системы, возможные интеграции, а также выбрать технологии, инструменты, языки программирования и пр. Реализация и тестирование Часто руководства по проджект-менеджменту объединяют этапы проектирования, реализации, тестирования и внедрения в один общий этап реализации проекта (между планированием и эксплуатацией). Однако нам важно углубиться в детали, поэтому мы подробно рассмотрели этап проектирования и только сейчас переходим к реализации. В ходе этого этапа мы приближаемся к воплощению. 1) Конструирование и программирование Ранее мы поставили задачи, описали требования и решения, определили внешний вид системы и внутреннее устройство. Теперь — приступаем к созданию продукта. Разнообразие инструментов и технологий позволяют погружаться на разный уровень глубины программирования. Но любой процесс программирования сопровождается контролем качества реализации. Помимо тестирования самого продукта, проверяется код, соответствие соглашениям, лучшим практикам и т.д. 2) Планирование тестирования Как будем тестировать? На основе требований разрабатывается план тестирования, который может включать не только прохождение по сценариям пользователя, но и, например, проверять устойчивость при большой нагрузке, скорость ответа с сервера, количество ошибок пользователя при выполнении операции и пр. 3) Выполнение тестирования В результате тестирования фиксируются отчёты, замечания, проблемы, ошибки. Важная задача по улучшению качества тестирования (и как следствие, качества продукта) — автоматизация тестирования. Внедрение Внедрение тесно связано с разработкой и эксплуатацией. Если это заказная разработка, то на этом этапе можно наблюдать, как команда разработки передает продукт заказчику, сопровождая его необходимой документацией. В ходе этого этапа решаются следующие задачи: 1) Подготовка инфраструктуры, выполнение поставки, ввод в эксплуатацию Куда и как разворачивать систему? Обычно процесс интеграции, поставки и развёртывания начинается одновременно с программированием. Однако это необходимо только при наличии сложной архитектуры, частых релизов и т.п. В ином случае данная задача может быть решена разработчиком с помощью специализированных инструментов (например, если в вашем проекте по созданию сайта-визитки задействован один разработчик). Необязательно ждать завершения проекта для отслеживания прогресса. Для выполнения тестирования и проведения демонстрации могут создаваться дополнительные окружения и стенды (помимо промышленного). 2) Демонстрация системы Демонстрация проводится время от времени по мере разработки. Это помогает проверить, совпадают ли ожидания с реальностью. Современные методологии рекомендуют организовывать процесс именно так, чтобы автор идеи и все заинтересованные лица могли наблюдать прогресс. 3) Подготовка руководства пользователя До полноценного выпуска система должна проверяться на соответствие законам. С пользователем (особенно в случае наличия платных функций) заключается особое соглашение (то самое, которое никто не читает перед установкой). 4) Завершение разработки, оформление закрывающей документации Попадание продукта в промышленную эксплуатацию в принципе означает окончание разработки. Это значит, что пора завершить работу и с административной точки зрения, в том числе подписать закрывающие документы. Эксплуатация и развитие Кажется, что пора радоваться и открывать шампанское. Однако далеко не для всех проектов ввод в эксплуатацию является конечной точкой. Стоит вернуться к бизнес-модели, которую мы описывали на старте, освежить план продвижения и приступить к его выполнению. А также обеспечить мониторинг, организовать поддержку и пообщаться с теми пользователями, для кого предназначается продукт. В ходе этого этапа мы уходим от выполнения задач в цикл развития и задаем новые вопросы: 1) Продвижение и продажи На этапе продвижения выполняется огромный спектр работ, связанных с рекламой, маркетингом и монетизацией. 2) Технический мониторинг Мониторинг работы системы желательно начинать со старта разработки. Важные нагруженные системы, для которых заявляются определённые характеристики и работоспособность которых влияет на прибыль, нуждаются в дополнительных инструментах контроля состояния. Для побочных систем эта задача необязательна. 3) Поддержка и развитие Что говорят пользователи? На что жалуются? Что нравится? За что платят? Сбор информации для развития продукта происходит из множества источников. Можно продолжить коммуникацию с заинтересованными лицами, можно исследовать рынок, можно общаться напрямую с пользователями, можно собирать статистику использования, можно пересмотреть цели и изменить продукт. А можно остановиться и порадоваться успеху. Этапы жизненного цикла Project Life cycle, жизненный цикл проекта – это последовательность этапов, через которые проходят проекты от инициации до завершения. Определение концепции Планирование и подготовка Проектирование Реализация и тестирование Внедрение Эксплуатация и развитие Жизненный цикл определяет рабочий процесс. Понимание жизненного цикла позволяет организовать эффективную работу команды. Workflow, воркфлоу, рабочий процесс – это набор стандартных последовательных действий, которые выполняются на постоянной основе в компании или в команде для достижения определённых целей, например, для реализации проекта. Важно помнить, что, несмотря на последовательное представление этапов, задачи каждого этапа ЧАСТО выполняются одновременно, в большем или меньшем объёме в зависимости от степени готовности продукта и других факторов. Выполнение задачи, проведение мероприятия в хорошо построенном процессе приводит к появлению артефакта или части продукта. |