Все лекции. Лекция 1 общее представление о проектной деятельности 1 Проектная деятельность общее представление. Понятие проекта
 Скачать 0.68 Mb.
|
|
12.4 Agile Как уже говорилось, далеко не все проекты могут быть организованы таким образом, чтобы к ним могли быть эффективно применены методы классического проектного управления. Типичный пример: приготовление одного блюда идеально ложится на классический подход, а вот вовремя приготовить и подать ужин из нескольких разных блюд с учетом обратной связи от посетителей будет практически невозможно с таким подходом. Agile – семейство гибких итеративных методов к управлению проектами. Проект разбивается не на последовательные фазы, а на небольшие подпроекты, которые постепенно превращаются в финальный продукт проекта. Этапы инициации и планирования проводятся для всего проекта в целом, а последующие этапы: разработка, тестирование и прочие проводятся для каждого подпроекта отдельно. Это позволяет передавать результаты подпроектов быстрее, а, приступая к новому подпроекту, в него можно внести изменения без больших затрат и влияния на остальные части проекта. Фактически, Agile – это культура сотрудничества, адаптивности, принятия неопределенности, набор ценностей и принциповтого, как нужно реализовывать проекты. На основе этих принципов были разработаны гибкие методы: Scrum, Kanban, Crystal и т.д. Эти методы следуют одним и тем же принципам, хотя имеют значительные отличия. Сильные стороны Agile Главное преимущество Agile – гибкость и адаптивность. Подход позволяет осуществить быстрый запуск проекта, быстро реагировать на изменения, поддерживать связь между командой проекта и заинтересованными сторонами. Все это обуславливает его нынешнюю популярность и значительное количество программ для различных областей, которые были созданы на его основе. Сфера Agile – разработка инновационных продуктов. Инновационные проекты разрабатываются в условиях высокой неопределенности, требования к продукту могут уточняться по ходу выполнения проекта. Реализация инновационного проекта классическим подходом практически невозможна, т.к. в таких условиях не построить адекватный план проекта. Слабые стороны Agile Agile — это просто набор ценностей и принципов. Основной минус подхода состоит в том, что требуются высококвалифицированные и мотивированные сотрудники, которым придется самостоятельно выстраивать свою систему управления, руководствуясь данными принципами. Также требуется значительно количество времени от Заказчика. Существуют готовые методы, которые облегчают использование Agile подхода. К таким методам относятся Scrum, Kanban, Crystal, SAFe, Nexus и т.д. 12.5 Scrum Метод, признанный в семействе Agile наиболее структурированным. Scrum используется для проектов, в которых необходимы «быстрые победы» в сочетании с толерантностью к изменениям. При таком подходе продукт проекта разбивается на части, подходящие для немедленного применения Заказчиком. Такие части оформляются в виде «беклога» (задел продуктов, Product BackLog). Чаще всего такой метод применяется для разработки программного обеспечения. Наиболее важные для Заказчика части первыми отбираются для выполнения в «спринте» (Sprint, cпринт – это итерация продолжительностью от 2 до 4 недель). В результате выполнения спринта Заказчик получает готовую к использованию часть продукта проекта. После окончания одного спринта проектная команда начинает следующий спринт. Продолжительность спринтов одинакова, но команда сама устанавливает ее, оценивая свою производительность и особенности проекта. Чтобы убедиться в соответствии проекта требованиям Заказчика, перед началом любого спринта происходит переоценка еще не выполненного содержания проекта и вносятся в него изменения. Весь процесс реализации проекта основывается на пяти основных встречах: Упорядочивание (планирование) BackLog. Проводится перед началом нового спринта. Обсуждается то, что уже удалось сделать по проекту и что еще нужно сделать. Инициатор ставит задачи, соответствующие новому этапу. Планирование спринта. После расстановки приоритетов и определения задач инициатором команда принимает решение о своих действиях на протяжении наступающей итерации и ищет способы достижения поставленной цели. Планировать спринт нужно в самом начале итерации, но по окончании упорядочивания Беклога. Летучки – это ежедневные встречи для обмена сведениями (до 15 минут). Члены команды делятся информацией о статусе своей работы и состоянии проекта, однако никакие решения не принимаются и проблемы не обсуждаются (для этого выделяется отдельное время, устраиваются дополнительные встречи). Подведение итогов спринта. На этом этапе исследуется и адаптируется созданный продукт. Члены команды делятся своими результатами со всеми заинтересованными лицами. Важно удостовериться, что продукт спринта соответствует целям проекта. Ретроспектива спринта. Этап, проводящийся сразу же после предыдущего, но до планирования нового спринта. Оценивается слаженность пройденного этапа, исследует появившиеся проблемы в работе. Благодаря ретроспективе команда может сделать выводы и повысить эффективность следующего спринта. Сильные стороны Scrum: Подходит для проектов, требующих быстрых результатов. Подходит для применения командами, в которую вошли сотрудники с небольшим опытом работы в области реализации конкретного проекта – постоянные коммуникации в команде позволяют наладить обмен опытом между членами команды. Внесение изменений в требования к продукту проекта не оказывает сильного влияния на управление проектом. Получаемая практически мгновенная обратная связь от выполняемых действий позволяет быстро исправлять ошибки. Слабые стороны Scrum: Значительные требования к составу проектной команды, члены которой должны быть способны к самоорганизации и обладать сразу несколькими компетенциями, за счет чего, собственно, сотрудники и могут дополнять и заменять друг друга. Процесс организации работ по проекту подходит далеко не для каждого продукта (не каждый продукт можно разбить на части, выполнять итерациями). 12.6 Lean Подход Agile не уточняет, как именно разрабатывать небольшие подпроекты. Был предложен подход Lean («бережливый»), который представляет собой скорее образ мышления и концепцию, при помощи которой можно самостоятельно сформировать подходящую систему управления проектами. Метод Lean дополняет принципы Agile за счет внедрения схемы потока операций (workflow) для выполнения отдельной итерации. В Lean работу разбивают на некоторые части (пакеты), реализующиеся независимо друг от друга. В отличие от Scrum каждый пакет различается своим потоком операций с этапами (планирование, тестирование, разработка и т.д.) – главное, чтобы эти этапы были важны для качественного осуществления проекта. Метод допускает параллельное выполнение нескольких задач на разных этапах, а это в свою очередь повышает гибкость и сокращает скорость выполнения проекта. Сильные стороны Lean: Подходит для проектов, требующих четкого исполнения и ровного качества. Сочетает в себе структурированность и гибкость. Слабые стороны Lean: Предполагает детальную проработку всех задач и этапов проекта (в реальности во многих проектах далеко не все части проекта требуют к себе такого внимания). 12.7 Kanban Слово Канбан (Kanban) в переводе с японского обозначает: kan – «видимый, визуальный», ban – «карточка, доска». Подход Канбан – это также не конкретная методика, описывающая детали как управлять проектом, а некий набор принципов, ориентированный прежде всего на выполнение задач проекта. Задача руководителя проекта — это создать приоритизированный пул задач, а задача команды проекта — выполнить как можно больше задач из этого пула. В Канбан поток работы проекта разбивается на столбцы, а задачи обозначаются специальными карточками. Карточки перемещаются по этапам, на каждом из которых повышается процент завершения. В итоге получается готовый элемент продукта. Доска со столбцами может быть реализована как в физическом виде, так и в электронном. Пример такой доски представлен в презентации к лекции. Существует несколько основ, на которых держится вся система Канбан: Карточки создаются для каждой задачи, где фиксируется вся нужная информация о ней. Регламентированные количество задач для каждого этапа, что позволяет отслеживать возникновение «заторов» в потоке операций. Непрерывное улучшение: постоянный анализ рабочего процесса и поиск путей повышения его эффективности. Можно выделить следующие отличие между Канбан и Scrum: В Канбан не задаются временные рамки ни на что (ни на задачи, ни на спринты), оценка сроков выполнения задачи может не делаться. В Канбан задачи крупнее, их количество меньше. Канбан позволяет приостановить выполнение одной задачи, если появились иные срочные задачи или изменился приоритет текущей. Незавершенные задачи, подвешенные даты – норма для этого метода. Отсутствуют роли членов команды и участников (кроме инициатора проекта). Один член команды может заниматься выполнением нескольких задач в одно и то же время. Сильные стороны Канбан: Идеально подходит для применения сплоченными и замотивированными командами с налаженной коммуникацией. Точный расчет нагрузки на исполнителей, правильная расстановка ограничений и фокусирование на постоянном улучшении. Гибкость к изменениям. Слабые стороны Канбан: Подходит для команд, члены которых обладают пересекающимися друг с другом навыками, иначе эффективность метода существенно снизится. В случаях, когда приходится иметь дело с четко установленными сроками, лучше использовать другие методы. ЛЕКЦИЯ 13 - ОЦЕНКА ХОДА РЕАЛИЗАЦИИ ПРОЕКТА 13.1 Введение После того, как процесс планирования проекта завершился, и необходимые одобрения получены, можно распечатать план работ и созывать команду для старта их реализации. Кажется, что план готов и можно последовательно выполнять по нему работы. Однако на этапе реализации проекта настоящая работа команды только начинается, когда приходится непосредственно выполнять поставленные задачи, решать возникающие трудности, координировать и сопоставлять задачи внутри команды, оценивать и принимать неизбежно появляющиеся изменения, информировать о ходе проекта заинтересованных лиц и т.д. Прежде всего, для принятия каких-либо решений в рамках проекта нужно понимать статус проекта: что уже было сделано, что еще предстоит сделать, а что стоит и переделать. Поэтому в проектной деятельности выделяют процесс мониторинга и контроля. Такой процесс позволяет заинтересованным сторонам понять текущее состояние проекта, какие были предприняты шаги, какие намерения так и остались намерениями, а также построить прогноз в отношении достижения целей проекта (в том числе прогноз по расходованию денежных средств, соответствия расписанию и содержанию). Мониторинг и контроль работ проекта — это процесс отслеживания, проверки и ведения отчетности о ходе исполнения для достижения целей исполнения, определенных в плане управления проектом. Возникающие задачи в рамках процесса мониторинга и контроля можно условно рассматривать с двух сторон: со стороны команды проекта и со стороны выполняемых ими работ. Команда проекта Для успешной реализации проекта важно, чтобы вся команда проекта была в курсе текущей ситуации в проекте, чтобы любой член команды мог свободно сообщать о возникающих трудностях и предлагать собственные решения, а не только критиковать и перекладывать ответственность за проект. После того, как будет выбран режим коммуникаций, распределена ответственность, необходимо выстроить систему информирования о текущем состоянии проекта, в том числе систему отчетности и контроля. Работы проекта Работы проекта могут быть выполнены по-разному, с разным качеством, и не всегда члены команды готовы приложить достаточно усердия и стараний без напоминания. Но если итог не будет удовлетворять поставленным требованиям, то проект с большой вероятностью будет провален. Кроме того, в процессе выполнения могут возникать новые задачи, которые не были учтены на этапе планирования; выполняемые задачи могут оказаться на порядок сложнее, чем представлялось в начале проекта; могут поменяться внешние условия и т.п. Ведь проект – как живой организм. Соответственно, необходимо отслеживать соответствие между получаемыми результатами и требованиями к ним, и стремиться, чтобы поставленные задачи были решены с должным качеством. Процесс отслеживания соответствия зависит, прежде всего, от типа проекта и команды проекта: сверка может проходить на общем собрании команды проекта, может быть выполнена единолично руководителем проекта, могут быть организованы промежуточные встречи-приемки с Заказчиком и т.д. 13.2 Какие действия предпринимаются на этапе реализации? Руководитель проекта может: Координировать действия всех участников проекта: налаживать необходимые связи между участниками проекта, обеспечивать вовремя необходимые ресурсы, назначать на новые задачи исполнителей и т.д. Оценивать прогресс выполнения работ проекта по различным показателям (время, стоимость, качество, содержание) и инициировать по результатам оценки корректирующие или предупреждающие действия (например, назначать новых исполнителей, корректировать план работ). Информировать как команду проекта, так и других заинтересованных лиц о ходе выполнения проекта и появляющихся изменениях в нем. Отслеживать возникающие изменения в проекте, планировать и организовывать их выполнение, выявлять и анализировать новые риски. Каждый член команды проекта может: Выполнять назначенные на него задачи согласно обозначенным требованиям (к содержанию, к срокам). Отчитываться о ходе выполнения задач: сколько уже выполнено, сколько еще осталось сделать. Вовремя информировать о возникающих трудностях, предлагать решения об их устранении. Инициировать изменения, как к требованиям к результату проекта, так и к организации всего проекта. Принимать участие во встречах команды проекта. 13.3 Информирование заинтересованных лиц Представьте ситуацию, когда Заказчик или другое влиятельное лицо находится в информационном вакууме и не имеет достоверной информации о ходе проекта. Что он думает о проекте и как он принимает тогда решения? И такая ситуация точно не будет способствовать успешному достижению целей проекта. Поэтому лучше изначально решить, кому и какую информацию о ходе проекта предоставлять, чтобы понимание стало верным. Как гласит одно из следствий из закона Чизхолма (Chisholm's Laws): "Всё, что может быть понято неправильно, будет понято неправильно". Кто именно должен понимать статус проекта, кого стоит информировать о ходе проекта? Руководитель проекта. Именно он отвечает за весь проект, ему принимать важные решения, касающиеся проекта. Соответственно, руководитель проекта должен обладать полной информацией о ходе проекта. Команда проекта. Для успешной реализации проекта важно, чтобы любой член команды понимал, что происходит в проекте, какие ему необходимо выполнять задачи, и как эти задачи могут повлиять на проект. Основываясь на этой информации, команда проекта сможет сообщать о возникающих трудностях и изменениях, предлагать решения. Заказчик и другие заинтересованные лица. Информирование с заданной периодичностью заинтересованных лиц помогает удерживать их вовлеченность в проект и управлять их ожиданиями, а значит позволяет повысить вероятность поддержки проекта и минимизировать их сопротивление. Для более точного определения адресатов удобно использовать матрицу заинтересованных сторон, о которой шла речь в одной из прошлых лекций. Кстати, по мере развития проекта состав заинтересованных сторон и уровень их вовлечения могут меняться, и это стоит учитывать. Вовремя доставленная и адекватная информация о проекте напрямую способствует успеху. Важно, чтобы была выстроена адекватная система информирования о текущем состоянии проекта, в том числе система отчетности и контроля. Такая система позволит не только оперативно принимать решения, но и снизить вероятность возникновения конфликтов, как внутри команды проекта, так и с другими заинтересованными лицами из-за недопонимания. 13.4 Отчетность в проекте Отслеживание статуса проекта заключается в сборе фактических данных, таких как даты начала и завершения задач, количество потраченных часов и денег, и в оценке предполагаемых сроков, трудозатрат и бюджета для оставшихся задач. Формат отчета об исполнении выбирается в зависимости от того, для кого он предоставляется: для руководителя проекта, для команды проекта, для заказчика или других заинтересованных лиц. В соответствии с адресатом отчета выбирается также и периодичность предоставления, например, ежедневно, еженедельно, ежемесячно или по запросу. Главное, чтобы работа руководителя проекта и команды проекта не свелась только к заполнению отчетов! Формат отчета может быть как простым, так и детально проработанным. В простом отчете может содержаться следующая информация об исполнении: выполнена задача или нет (% выполнения задачи); сколько осталось дней до завершения текущей задачи; возможные смещения по срокам или бюджету будущих задач. В расширенных отчетах может дополнительно содержаться следующая информация: выполненные задачи за определенный период и их показатели (срок, бюджет, ресурсы); прогнозные значения показателей будущих задач или проекта в целом; анализ выполненных работ; сводная информация о рисках проекта; сводная информация об изменениях в проекте; другая значимая информация, которая рассматривается и обсуждается. Оценка выполнения работ проекта может производиться с разной периодичностью, в зависимости от требуемой точности: контроль в моменты окончания работ (0% – работа не выполнена, 50% – работа в процессе выполнения, 100% – работа выполнена); контроль в заранее определенных ключевых точках проекта (контроль по вехам); регулярный оперативный контроль с заданной периодичностью (например, ежедневно, еженедельно). Существует два основных подхода к подготовке отчета членами команды проекта: со стороны задач и со стороны назначений ресурсов. Выбор подхода зависит от принятых в организации стандартов, типа проекта, важности подсчета потраченных трудозатрат, в том числе количества свободного времени для обновления данных в плане работ и т.д. А) Идея подхода обновления информации по ресурсам заключается в том, что команда проекта отражает как фактические трудозатраты на назначенные задачи, так и предстоящие в своих периодических отчетах. Такой подход обеспечивает более точную картину о состоянии проекта, но требует достаточно больших затрат времени руководителя проекта и команды проекта. Обычно такой подход используется, когда выплаты сотрудникам зависят от потраченных часов, скорости работы. Тогда процент завершения по трудозатратам обозначает долю фактически отработанных часов по отношению к запланированным часам. Пример 1. Отработав на задаче 16 часов из 40, вы получите 40% завершения по трудозатратам, хотя задача могла длиться и 3 дня, и 5 дней, и 10 дней, и так далее. Пример 2. Допустим, сотрудник прислал отчет, что он выполняет задачу, запланированная длительность которой была равна 5 дней. Он потратил 24 часа на решение этой задачи и выполнил половину (% завершения по трудозатратам равен 50). Тогда руководитель проекта сможет построить следующий прогноз по выполнению задачи при восьмичасовой рабочей неделе: осталось потратить 24 часа, т.е. 3 дня; всего задача займет 6 дней, значит превышение длительности – 1 рабочий день. Б) Смысл подхода обновления информации по задачам состоит в том, что собираются данные о фактической и оставшейся длительности, о датах начала и окончания задачи. Такой подход менее трудоемок, но и является менее точным. При таком подходе процент завершения показывает долю фактической длительности выполненной части работы по отношению к запланированной длительности работы. По сути, это значение показывает – насколько выполнена работа с точки зрения запланированной длительности. Пример 3. Допустим, вы отработали 3 дня из девятидневной задачи, тогда % завершения будет равен 30, несмотря на фактическое количество потраченных часов. Также и с проектом, отработав по проекту 18 дней из 120, вы получите 15% завершения всего проекта. В зависимости от типа проекта и потребностей участников в качестве инструментов для составления отчетов могут использоваться следующие: текстовые редакторы (MS Word, Pages, Google Docs); табличные редакторы (MS Excel, Numbers, Google Sheets); информационные системы управления проектами (MS Project, OpenProj, Oracle Primavera, др.). |