Применение: Данная система отлично подходит для любых проектов по внедрению новых подходов и методологий, R&D проектов, проектов Lean-трансформации, культурной трансформации и в общем любых проектов, связанных с изменениями в организации.
Гибридный подход Agilean
Как и для всех решений и инструментов Agilean, в разработке системы управления проектов мы применяем один и тот же гибридный подход Agilean. Если быть точнее, мы выбираем самое эффективное, универсальное и легко применимое в любом контексте из существующих и доступных методологий и используем для создания гибридного инструмента Agilean.
Выбранные компоненты.
На схеме вы видите 4 потока или измерения, которые присутствуют практически в любом проекте.
А именно:
- ежедневная деятельность (Zoom in: – или то, как мы организуем работу команды на проекте каждый день);
- крупные фазы проекта (Zoom out: Фазы проекта, отражающие стратегические шаги реализации проекта);
- управление изменениями (всё что связанно с управлением стейкхолдерами, политическими аспектами в организации и любыми аспектами, связанными с человеческим взаимодействием);
- коммуникации проекта (План коммуникаций проекта).
Логика выбора
Чуть подробнее почему мы применяем именно эти инструменты и именно в таком сочетании.
SCRUM – защищать или рекламировать эту методологию в виду её популярности не имеет смысла. Хочется лишь отметить, что формат SCRUM давно применяется не только в IT и в принципе доказал свою эффективность как простое и эффективное решение, обеспечивающие скорость реализации, гибкость планирования и высокое качество продукта в связи с постоянной обратной связью от заказчика. Также правильно настроенный SCRUM – это высокая вовлечённость команды, максимально сниженный уровень стресса и абсурда, так хорошо знакомый PM-ам по waterfall и PM BoK проектам. Вешаем доски и применяем эту методологию для планирования и организации вашей ежедневной деятельности по проекту.
DMAIC (LEAN 6 SIGMA) – DMAIC – масштабная технология внедрения проектов со своими инструментами и детальным описанием практически каждого шага. На наш взгляд её приверженность духу waterfall, излишняя склонность к процедурам, регламентам и другой бюрократии делает её морально устаревшей и неэффективной по сравнению с решениями на базе Agile. Однако, в чем она, несомненно, остаётся хороша и эффективна, по нашему мнению, это в планировании крупных фаз проекта.
Её DEFINE, MEASURE, ANALYZE, IMPROVE, CONTROL перекликается с классическим подходом PDCA и является отличным подспорьем для любого менеджера проекта в стратегическом планировании своих действий по проекту.
МОДЕЛЬ ИЗМЕНЕНИЙ 8 ШАГОВ КОТТЕРА – это важное отличие методологии Agilean от других систем управления проектами. Серьёзное отношение к управлению изменениями – это то, что отличает хорошего руководителя проекта от плохого и успешный проект от провального. Знакомьтесь с системой родоначальника change management Джона Коттера и применяйте в качестве лучшей практики.
ПЛАН КОММУНИКАЦИЙ – чем отличается План коммуникаций Agilean от любого другого плана коммуникаций проекта?
В первую очередь – релевантностью. Любой практикующий руководитель проекта сталкивался с ситуацией, когда План коммуникаций проекта сводится исключительно к формальным событиям и сообщениям, которые приходится вымучивать из себя, просто по тому что в контракте у вас стоит пункт внедрение «Плана коммуникаций». В нашей же методологии, если вы применяете модель Коттера, План коммуникаций перестаёт быть обузой и формальностью, а становится живым и эффективным инструментом поддержки каждого из 8 шагов. Вы больше не ломаете голову над вопросом «Что же воткнуть в план коммуникаций?». Смело смотрите на содержание, цели и задачи каждого из 8 шагов Коттера и планируете серию интервью с руководством в шаг «Создание коалиции», массированную атаку всех коммуникационных каналов в шаг «Коммуникация видения» и фокус-группы с работниками в шаг «Быстрые победы».
Общие рекомендации:
Совместите все эти четыре подхода в один график и планируйте ваши действия сразу с учётом всех четырёх измерений и успех вашего проекта гарантирован!
Комментарии (9)
vyatsek
07.08.2019 17:00-1Вообще странное течение в IT, говорят делайте скрам, канбан и прочий аджаил. Но никто не показывает продукты, которые были сделаны по этим методиками/методологиям.
Японская аппаратура 90х знак качества, недавно пользовался японским массажным креслом (Yamaguchi Axiom Chrome Limited)
История создания Technics (https://www.youtube.com/watch?v=0il1-dWX1vU)
Советы про скрам-аджайл напоминают апологетов гербалайфа из 90х.
Опять таки имеет смысл детально изучить как разрабатывается ядро линуса, т.к. этот продукт работает уже 3ий десяток лет, когда аджайла еще и впомине не было.
Но посыл прос: сначала результат, потом исследование процесса получения, но не наоборот.
uzverkms
07.08.2019 17:01уровень стресса и абсурда, так хорошо знакомый PM-ам по waterfall и PM BoK проектам
Так вот кто виноват в проблемах на проектах. Хотя в этой фразе прекрасно всё — смешались в кучу кони, люди.
in_heb
07.08.2019 23:04Вообще не понял что хочет сказать автор статьи. Какой-то адовый рерайтинг статей об аджайле.
Это обзорная статья или вы что-то новое предлагаете?
Надеюсь, что вы не внедряете что-либо в реальной жизни вашей манерой изложения.AgileChange Автор
07.08.2019 23:24Это новое сочетание старых инструментов для успешного внедрения проектов НЕ связанных с разработкой ПО.
YRatay
08.08.2019 14:47Методология интересна. Противопоставление watefall не корректна. Найдется много PM и в этой схеме (Agilean) в состоянии «уровень стресса и абсурда». Будет сложно работать по Agilean когда у вас ресурсы буду «шариться» между несколькими проектами. А про бессмысленность Плана коммуникаций:"… сводится исключительно к формальным событиям и сообщениям, которые приходится вымучивать из себя..." — это от не понимания/знания. Тут waterfall и PMBoK не причем…
AgileChange Автор
08.08.2019 14:52Я согласен, что стресс и абсурд при желании можно где угодно создать, но когда я говорил про waterfall, я имел в виду, что гибкий бэклог генерит гораздо меньше дезинформации, стресса и абсурда, чем расписанный на долгий период вперёд график проекта (вот тут я детально писал о причинах habr.com/ru/post/422327). А большая доля различия Скрам и Вотерфолл — это как раз гибкость планирования.
Согласен, что неправильное использование Плана коммуникаций это от непонимания, незнания. Но в формате работы по Коттеру такого непонимания, незнания автоматически становится меньше, потому что его модель изменений очень точно, глубоко и понятно описывает, какие коммуникации и когда в течение жизни проекта нужно сделать.YRatay
08.08.2019 18:18Как всегда надо подходить ко всему разумно.
Методы и принципы PMBoK (основанный на waterfall, но не ограничен им) ни как не ограничивает в гибкости планирования и так же позволяет гибко формировать ТЗ/ФД (бэклог) и заложено в методе «набегающая волна». PMBoK (и waterfall) не ограничивают и не требует "… расписанный на долгий период вперёд график проекта..."AgileChange Автор
08.08.2019 19:02Вы говорите о методологии и да там есть много разумных практик, перекликающихся с Agile методами, но я больше говорю о практике. Я из ни разу не видел и не слышал о waterfall проекте в России, где заказчик не требовал бы полного графика от подготовки до заключительной фазы.
То есть можно конечно увлечься релятивизмом и сказать, что кое где кое кем все же делается не так. Но это вопрос научно-методологического пуризма.
Статья же об исключительно практическом инструменте и самой расхожей ситуации в реальности
Mimus_spb
Толи схема, толи система, толи аджайл, толи лин, толи скрам, толи срам, толи кушал, толи радио слушал.