менеджмент. Лекции по теме Основы методологии управления проектами. 1 Форма ответа на задачу
 Скачать 207.05 Kb.
|
|
ПРАКТИЧЕСКОЕ ЗАДАНИЕ №3 Задача № 3.1: Изучите кейсы ниже и по каждому кейсу определите наиболее подходящую методологию управления проектами. Ответ обоснуйте. При от- вете можно использовать модель «Кеневин». При выполнении задания можно воспользоваться теорией из лекции по теме «Основы методологии управления проектами». Таблица 3.1- Форма ответа на задачу
Учебные кейсы:Кейс 1: Вы — системный интегратор, который внедряет решения интер- нета вещей. Один завод (допустим, трубопрокатный) заинтересовался ва- шим продуктом "умная каска", у которой на самом деле может быть масса реализаций — ваша компания может в любую. Нужно разобраться, что было бы актуально конкретно для этого завода: датчики движения, местополо- жения, метка с пропуском и другие. Не забудьте, что у клиента должна быть система управления этим решением. Есть ряд проблем — как обеспечить по- крытие связью, обеспечить каски электропитанием и т.д. Подумайте, какие еще есть сложности. Кейс 2: Вы — руководитель ИТ-проектов в ИТ-компании численностью 1000 человек. У компании головной офис в Москве, 3 филиала: в Казани, Вологде и Костроме. На данный момент расчет зарплаты сотрудникам и учета необходимых до- кументов происходит руками в Excel силами бухгалтеров. После расчета бухгалтеры-стажеры вручную вводят данные в систему (АБС – существующая в компании система для проводок) для формирования прово- док и перечисления на карточки сотрудникам. Текущие пользователи: 5 сотрудников кадровой службы и 10 бухгалтеров в Москве, 1 кадровик и 2 бухгалтера в каждом филиале в регионах. Главный бухгалтер и главный методолог расчета ЗП - в Москве на всю ком- панию. Базы сотрудников и история начислений — разрозненные в каждом филиале и ГО. Куплено ПО — коробочное решение от вендора, а внедрение и доработка — силами нашей компании. От вендора выделен 1 человек в качестве консуль- танта по функционалу системы. ИТ-ресурсы: в штате нашей компании в отделе внутренней автоматизации 30 человек: 15 разработчиков, 2 аналитика, 5 тестировщиков. Кейс 3: Вашей команде передали крупный e-commerce сайт. Он существует в течении нескольких лет, технически не идеален, непрерывно генерирует опре- деленное количество багов. Одновременно с этим вам надо выполнять задачи по наполнению сайта контентом, и дорабатывать его, создавать новые фичи. У вас нет обязательств выпускать обновления крупными пакетами, у задач есть дедлайны. Кейс 4: Ваша задача создать с нуля операционную систему - конкурента Windows, а затем развивать ее с помощью регулярных, заранее спланирован- ных обновлений. Наивысший приоритет - качество продукта, регулярность обновлений. Сроки и затраты вы определите сами. Кейс 5: Вы - проджект в компании, которая делает продукты для мобильных операторов - платформы, на которых затем строятся сервисы для конечных пользователей вроде голосовой почты, записи разговоров, определителя номера и прочих маленьких привычных полезных функций мобильной связи. Один из ваших продуктов, платформу для голосовой почты, ваши коллеги продали в экзотическую страну Бурунди. Требования к продукту стандартные - никак под заказчика его дорабатывать не нужно, достаточно только установить, интегрировать в сеть и перевести на него абонентов. Кейс 6: Вы проджект в диджитал агентстве, и ваш новый проект - мобиль- ное приложение для производителя витаминов, которое в игровой форме расскажет об их пользе и привьет правильную привычку потребителям. Вы сами определяете многие аспекты его реализации, при этом важно учесть все пожелания заказчика и уложиться в срок и бюджет Кейс 7: Вы - проджект в компании, которая делает продукты на рынке те- лекома, а также готова заниматься заказной разработкой. Ваш sales в Аф- рике (DRC - Демократическая Республика Конго) отозвался на запрос мест- ного оператора разработать систему совместного использования трафика в пакетных тарифах (в России Билайн запускал аналог в свое время - ВСЕ для семьи https://moskva.beeline.ru/customers/products/mobile/tariffs/details/semya- 2019/). При этом этот менеджер по продажам очень торопился заключить контракт и очень хотел во что бы то ни стало заключить эту сделку, что обещал что ваша компания все сделает, нарисовал как будет выглядеть ар- хитектура вашей системы (продавец нарисовал архитектуру, внимание) и всем сказал, что ему ясно, что нужно делать. В контракте нет ТЗ и четко описанных требований (их нужно описать на первом этапе проекта в виде пользовательских сценариев), нет бюджета с вашей стороны (можно при- влекать нужных разработчиков внутри компании), но есть сроки - почему- то это нужно сделать за 4 месяца. При этом срок начинается не с момента согласования требований, а с подписания договора. Основы теории: Рисунок 3.1 – Матрица «Кеневин» Результаты выполнения задания можно оформить в виде таблица – 2.1(Упорядоченные) простые (Simple) системы - характеризуются оче- видностью своей структуры и действующих взаимосвязей. В простых систе- мах причинно-следственные связи очевидны любому агенту системы, они про- сты, предсказуемы, повторяемы и понятны. Управление процессами в таких системах требует необходимости придерживаться согласованного порядка действий. Модель принятия решений в простых системах: – Определить про- блему; – Категоризировать проблему; – Предпринять действие для решения проблемы. В простых системах возможно применение наилучшей практики (Best Practice), потому что в таких системах возможно найти единственный наилучший способ достижения поставленного результата, т. е. выстраива- ется наиболее оптимальный процесс на основе уже разработанных методик, следование которому приведет к достижению цели наиболее эффективным образом. Упорядоченные простые системы понятны, для их решения у команды есть опыт. Уже на старте понятно, что получится в результате, за какие деньги и в какие сроки. Формулапринятиярешений:Определяем–Классифицируем–Реаги- руем. Методологияуправленияпроектами,методыиинструменты: Кас- кадная методология управления проектами и другие наилучшие практики. Пример: производство стульев – задача ясна и понятна. Упорядоченные сложные (Complicated) системы - отличаются нали- чием причинно-следственных связей, но уже не таких очевидных как в про- стых системах. Определение причинно-следственных связей в упорядоченных системах требует уже специальных экспертных знаний и практического опыта, при наличии которых эти связи удается обнаружить и описать. Мо- дель принятия решений в упорядоченных системах: – Определить проблему; – Проанализировать возможные причины их возникновения; – Предпринять действия для решения проблемы. В упорядоченных системах уже нет един- ственной наилучшей практики, но есть хорошие практики, т. к. каждая из систем по-своему уникальна и достижение наилучшего результата воз- можно несколькими способами, каждый из которых является верным. То есть, у менеджера уже появляется выбор из нескольких успешных методов достижения поставленных целей. Упорядоченные сложные системы: задача не уникальна, однако опыта работы в этом направлении у команды нет. Формула принятия решения:Определяем – Анализируем – Реагируем.Методологияуправленияпроектами,методыиинструменты:под-ходыPMI,Prince2и PMBoK Пример: производство стульев в условиях невесомости – технология изготовления понятна, но влияние факторов среды не очевидно. Запутанные (Complex) системы / Неупорядоченные сложные си- стемы - характеризуются настолько разнообразными связями между сво- ими агентами и такое количество агентов, что результат таких взаимосвя- зей становится непредсказуемым, причинно-следственные связи не ясны и не определены, два одинаковых действия в таких системах могут дать разный результат. Но в то же время, такие системы имеют достаточное количе- ство фактов, анализируя которые возможно определить причинно-след- ственные связи между действием и результатом. Модель принятия решений в запутанных системах: – Проанализировать сложившуюся ситуацию; – Понять суть проблемы; – Предпринять действия для решения проблемы. Для решения проблем в запутанных системах строятся гипотезы и создаются эксперименты для подтверждения этих гипотез, которые либо подтвер- ждают наличие причинно-следственных связей, либо их опровергают. В та- ких системах нет ни наилучших, ни хороших практик, т. к. практики возни- кают по мере проведения успешных экспериментов. Если проецировать систему на задачу, то речь идет о непонятной за- даче, но при этом команда с подобной проблемой уже сталкивалась и имеет опыт ее решения. Формулапринятиярешения:Измеряем–Определяем–Реагируем. Методологияуправления проектами, методы и инстру-менты:Agile ,в частностиScrum. Пример: эксперимент, моделирующий на Земле ремонт космической станции в состоянии невесомости. Хаотичные (Chaotic) системы - их особенность в том, что причинно- следственных связей нет, фактов, на которых возможно строить гипотезы и делать выводы отсутствуют. Модель принятия решений в хаотичных си- стемах: – Предпринять действие для решения проблемы; – Проанализиро- вать результат; – Скорректировать действие. Состояние хаоса — это кри- зисное состояние, поэтому в системах, находящихся в состоянии хаоса нет времени на анализ сложившихся ситуаций. Первоочередная задача мене- джера — стабилизировать систему. Из состояния хаоса есть 2 выхода: – Введение жестких ограничений для агентов системы и перевод системы в ка- тегорию простых; – Предпринять быстрые действия, снижающие турбу- лентность системы и перевод ее категорию запутанных. Здесь хорошо работает экспериментальный подход. Хаотичные – аб- солютно новые задачи, которые никто и никогда не решал раньше. Попытка разобраться с такой системой – путь к инновациям. Любой способ решения (стабилизации системы) будет новым. Порой нужно действовать вразрез с традиционными методами менеджмента. Формулапринятиярешения:Действуем–Определяем–Реагируем. Метод:новый,комбинацияметодов. Пример:любойстартап. Задача №3.2. Расписать сценарий применения выбранной методологии для одного из кейсов из перечня кейсов, приведенного выше, либо для случая из Вашей практики. Сценарий применения предполагает описание общего алгоритма реализации проекта, который будет зависеть от типа применяемой методологии управле- ния проектами – см. рисунки 3.2-3.4.  Рисунок 3.2 – Последовательная технология управления проектами (Waterfall) Рисунок 3.3 – Схема работы над проектом по Agile  Рисунок 3.4 – Общая схема работы в рамках фреймворка SCRUMКейс 2: Сценарий применения выбранной методологии для Кейс 2 Создание рабочей группы проекта. Согласно PMBoK, состав участников проекта может быть определен следующим: Менеджер проекта – человек, ответственный за управление проектом Заказчик – представитель компании - руководитель ИТ-проектов Проектная команда – группа работников, вовлеченных в выполнение проектных работ (технические специалисты в области интернет технологий и создания компьютерных игр, редактор текстов \специалист по рекламе, художник, сценарист, музыкальный оформитель) Команда управления проектом – люди из проектной команды, занимающиеся операциями по проект-менеджменту (финансовый директор компании) Спонсор (представитель инвестора) Источники влияния – представители сетевого ИТ бизнеса, не связанные напрямую с получением или применением продукта, но способные оказать положительное или отрицательное воздействие на реализацию проекта Определение сути проблемы, конкретных целей ее решения, факторов риска (отсутствие спроса на мобильное приложение, отсутствие спроса потребителя на конечный продукт производителя из-за неэффективности мобильного приложения, учет необходимости обеспечить легкость и простоту установки и его использования, возможное перенаправление на сайты производителя и дистрибьютров витаминов и др.) Анализ факторов риска и путей выхода из их зоны, актуализация пожеланий заказчика, инвестора и других источников влияния. Мозговой штурм. Составление древа решений (подбор и подгонка удачных практик). Составление предварительной сметы расходов и проекта контракта. Корректировка и согласование спорных позиций и сметы. Заключение контракта. Перевод проблемы в ранг комплекса задач и распределение конкретных задач для каждого исполнителя. Составление графика выполнения работ, определение критериев контроля. Составление матрицы ответственности. Расписание контрольных событий. Составление и согласование концептуальной модели Непосредственное выполнение. Система санкционирования выполненных работ. Промежуточная корректировка полученных результатов работы, согласование с заинтересованными участниками. Завершение работы, презентация конечного продукта. Подписание исполнения контракта. Гарантийное сопровождение. |