Содержание:
3. Сравнение Agile методологии управления проектами и Waterfall Методология
4. Управление проектами, типы проектов
1. Управление проектами IPMA
Статья посвящена проблеме, с которой сталкивается большинство руководителей предприятий и специалистов по внедрению информационных систем класса ERP. Какой подход выбрать – Agile или Waterfall, чтобы в итоге ожидания в достаточной степени удовлетворили потребности бизнеса. Обсудим, что ожидает и что получает бизнес, а также – почему успех или провал проекта при автоматизации с Нулевого этапа практически не зависят от подхода, выбранного на этапе presele.
С момента выпуска 1С:ERP 2.4 наблюдается высокий спрос и бум внедрений среди российских компаний как крупного, так и среднего бизнеса. Руководители и собственники предприятий массово посещают семинары, мастер-классы, бизнес-форумы по автоматизации и переходу на «цифровую экономику». Как следствие, через некоторое временя бизнес «идет» к различным интеграторам и специалистам по внедрению информационных систем класса ERP. Наиболее часто в этой роли выступают франчайзи 1С. Западные вендоры и представленные ими ERP-системы, довольно часто бывают слишком дорогим удовольствием для Российского бизнеса. В связи с этим в данной статье я ограничусь внедрением прикладных решений 1С.
Я умышленно оставляю за рамками данной статьи детальное описание процесса выбора системы бизнесом. Так как считаю, что как каждая компания прошла свой собственный путь становления, то точно также она проходит путь принятия решения о внедрении системы класса ERP. Вместе с тем, на мой взгляд, можно выделить следующие базовые потребности или «силу», двигающую бизнес к принятию подобных решений:
- Мечта любого генерального директора — сделать так, чтобы поручения исполнялись, а важные задачи решались при его минимальном вовлечении.
- Мечта собственника — сделать так, чтобы инвестиции приносили отдачу при его минимальном участии.
- При этом бизнес должен быть полностью прозрачен для руководителя и собственников, то есть работать четко и по ясным правилам, не зависеть от человеческого фактора и своевременно информировать о возникающих отклонениях от заданного направления.
Я не утверждаю, что данный перечень полностью описывает все «движущие» силы, которые приводят к принятию решений, но вместе с тем считаю, что базовые моменты я описал. Итак, решение принято на высшем уровне: «Внедряем ERP на нашем предприятии». В данной ситуации в большинстве компаниях начинается еще более мучительный и длительный процесс – процесс выбора Исполнителя и подхода к управлению проектом. На рынке представлены все варианты как малых, средних, так и крупных предприятий интеграторов. Учитывая большой выбор интеграторов систем ERP в сфере 1С заказчики с разными бюджетами на внедрение легко могут подобрать подходящего исполнителя. Правда, почти всегда на первое место выходит не интегратор и бюджет (хотя это имеет немаловажное значение), а подход к управлению проектом и контролю качества.
Есть два основных подхода управления проектами: «гибкая методология» - Agile подход и классический или «жесткий» подход - методологии Waterfall. Давайте рассмотрим в рамках данной статьи краткое описание данных подходов.
Когда мы говорим о методологии, то предполагаем описание объектов, субъектов и методов воздействия субъектов на объекты. Так описывает управление проектами IPMA, так же описывает его и PMI. PMI сформировала интересную картину объектов управления (портфель, программа, проект), описала их жизненные циклы, методы управления, их уровни зрелости. В PMI много внимания уделено и субъектам: ключевым ролям, компетенции менеджера проекта (PMCDF) и т.д. Институт управления проектами (PMI) выпустил 6 сентября 2017 шестое издание Руководства к Своду знаний по управлению проектом (PMBOK Guide). Помимо традиционных стилистических и технических исправлений, новый PMBOK включил в себя идеи из PRINCE2, теории систем, гибких подходов к проектному управлению Agile. На этот раз коллеги из PMI написали однозначно – «…настоящее Руководство не является методологией». И для пущего понимания описали подробно, как использовать Руководство (термины Руководство, PMBOK Guide используются в тексте настоящей статьи как синонимы — прим. автора).
Разработчики рекомендуют использовать PMBOK Guide для создания методологии управления проектами в организации. Методология может быть создана собственными внутренними экспертами организации или с помощью внешних профессиональных консультантов. Это первый уровень адаптации — процессы и инструменты из PMBOK Guide приспосабливаются под конкретную организацию. Второй уровень адаптации — когда проектная методология организации учитывает особенности каждого отдельного проекта и позволяет руководителю проекта изменять процессы управления в определенных пределах.
Таким образом, хотя PMBOK Guide у многих профессионалов ассоциируется с жестким классическим проектным управлением, Институт управления проектами делает каждое последующее издание Руководства все более гибким и адаптивным.
2. Что такое подход Agile
Авторы Agile подхода со своей стороны также не претендуют на то, чтобы называть Agile методологией управления проектами. «Agile - это набор принципов», - пишут они на сайте. То же написано и на другом сайте: «What is Agile? Not a methodology!». Именно так, первой фразой и с восклицательным знаком. Поэтому говорить о сравнении двух методологий управления проектами мы можем только с большим допущением. По мнению авторов Agile — это набор принципов. Но к чему эти принципы могут быть применены? Изначально они применялись к ИТ-проектам. Позже стали говорить о том, что по Agile подход можно управлять вообще любым проектами. А сегодня Герман Греф, например, говорит уже о "гибкой, юркой" организации, применяя определение Agile подход в целом к "Сбербанку".
Действительно, сегодня слово Agile часто применяют в двух смыслах: Agile Project Management (управление проектами по принципам Agile и с помощью практик Agile; "гибкое управление проектами") и Agile Organization (организация, работающая по принципам Agile; "гибкая организация").
Соответственно, когда мы говорим о гибком управлении проектами, то обычно имеется в виду применение практик, входящих в семейство Agile: SCRUM, Extreme Programming, Agile Canban, Scrumban и т.д. И в этом контексте обычно обсуждается, как команде проекта можно применить эти инструменты для наиболее эффективного решения задач проекта.
Когда же речь идет о гибкой организации (как в случае с Германом Грефом), то имеется в виду построение такой компании, которая очень быстро реагирует на рыночные изменения, в которой портфель проектов соотнесен со стратегией, налажено кросс-функциональное взаимодействие при реализации проектов и т.д.
Несмотря на такие довольно серьезные различия в принципах все чаще встает вопрос, какую технологию применить к тому или иному проекту для достижения наилучшего результата.
Для того чтобы нам погрузиться в процесс выбора, приведу краткое описание проекта по внедрению информационной системы, которое рассказал мне один мой знакомый. Причем оговорюсь сразу, описание подготовлено с акцентом на один из подходов.
«Однажды мы с коллегой планировали проект по внедрению новой системы ERP на предприятии. Заказчики провели обследование и подготовили описание будущей информационной системы подразделений, ранее не автоматизированных. Мы расписали все в календарном графике, согласно утвержденному бюджету, назначили исполнителей и ответственных лиц. С формальной точки зрения у нас все было супер.
Но не тут-то было... Уже в самом начале Заказчик начал резко менять требования к продукту, и весь наш Гантт посыпался. Но мы ребята опытные, быстро в проджекте внесли изменения, получили прогнозные сроки. Хотя... как быстро? Две бессонных ночи!
И такой ритм работы стал "нормальным". В общем это чем-то напоминало подвиг.
И несмотря на то, что все шло вперед и уже близился конец проекта, я чем-то "задним" чувствовал, что не к добру все это.
Так и случилось. Последний гвоздь в крышку гроба нашего проекта забили во время демонстрации результата Заказчику. За несколько минут до самой презентации выяснилось, что у компании Заказчика уже месяца два, как сменились приоритеты и вообще-то от нашего продукта ожидают большего.
Как выяснилось потом, ожидали не просто большего, а совсем другого.
Формально мы были правы т.к. все сделали по ТЗ, а «политически» были совсем неправы. Пришлось все переделывать, и в итоге ушли в большой минус, как по срокам, так и по бюджету, я уже не говорю, что морально и физически были подавлены.
После этого "акробатического номера" я для себя понял, что для определенного вида проектов, классика не подходит. И нужно как-то так организовать работу, чтобы мы с наименьшими издержками выходили на то, что нужно Заказчику. Что как-то нужно сократить количество переработок.
Исходя из представленного описания, большинство читателей могут сделать вывод, что в данном случае Agile подход, как подход к управлению проектами будет наиболее подходящим решением. Рассмотрим далее, а действительно ли Agile нам предоставит преимущества перед классической методологией Waterfall?
Я знаю, что навлеку много критики и получу массу комментариев… Но для начала приведу «историческую справку» по истории возникновения неформализованного подхода (Agile) методологии управления проектами:
Идея неформализованного управления проектами возникает тогда, когда Заказчик осознает высокую стоимость бумажной работы. Впрочем, неформализованный подход к управлению проектами не дает возможности совершенно избавиться от нее. Просто он позволяет уменьшить требования к ведению документации и свести ее до минимального необходимого уровня. Чтобы этот подход оказался действенным, организация должна обеспечить возможность эффективного общения, сотрудничества, взаимного доверия и командной работы.
Эти четыре элемента являются основополагающими в корпоративной культуре. По мере возрастания доверия обязанности по спонсорству над проектом могут быть переданы с высшего исполнительного уровня на средний.
Методические указания (функциональные задачи) даются Заказчиком в форме общих рекомендаций или контрольных списков. Это радикальным образом уменьшает стоимость проектирования методологии и время реализации цифровой модели предприятия с использованием прикладного решения 1С:ERP Управление предприятием.
3. Сравнение Agile методологии управления проектами и Waterfall Методология
Из представленного описания, по моему мнению, можно выделить следующие ключевые моменты:
1. Исполнителями выполнено планирование проекта и назначение лиц
2. В самом начале Заказчик начал резко менять требования к продукту
3. Выполнена актуализация плана проекта с учетом изменений
4. Команда проекта при выполнении работы начинает фиксировать опасения, что результат может не совпасть с ожиданиями заказчика.
5. И перед сдачей результата заказчику каким-то чудом выяснилось, что «у компании Заказчика уже месяца два, как сменились приоритеты и вообще-то от нашего продукта ожидают большего».
6. А далее лавинообразное развитие событий: как выяснилось потом, ожидали не просто большего, а совсем другого.
7. Формально мы были правы т.к. все сделали по ТЗ, а политически были совсем неправы.
8. Пришлось все переделывать, и в итоге ушли в большой минус, как по срокам, так и по утвержденному бюджету.
9. И по итогам проекта автор сделал интересный вывод: «Для определенного вида проектов, классика не подходит. Нужно как-то организовать работу так, чтобы мы с наименьшими издержками выходили на то, что нужно Заказчику».
Я уверен, что каждый читатель, с учетом своего опыта, может добавит в данный перечень еще много моментов или «белых пятен», на которые, по его мнению, стоит обратить внимание. Вместе с тем в рамках данной статьи я предлагаю рассмотреть представленные ключевые моменты.
Итак, приступим:
1. Исполнители проектов по внедрению информационных систем часто сталкиваются с изменениями в требованиях заказчика, в том числе на начальном этапе. В большинстве своем это связано с окружающей информационной средой. Например, на предприятии могла произойти замена руководителей, которые пришли с новыми требованиями. Или действующие руководители могли посетить очередной бизнес форум, а потом приняли решение, что необходимо на их предприятии реализовать данный функционал, который повысит их конкурентные преимущества. В данном случае я не могу склонить чашу весов в пользу той и иной методологии. Как Waterfall, так и Agile подход имеют в своем арсенале инструменты по реагированию и внесению изменений в проект. С точки зрения классических методологий Waterfall рекомендуется формализовать изменения и подготовить описание изменений. Причем глубина и детализация описания определяется и согласовывается с заказчиком. Происходит оценка изменений проекта и дальнейшие утверждение заказчиком изменений в проекте. Agile подход, согласно принципам неформализованного управления проектами, минимизирует затраты на описание и оценку изменений и принимает новые требования в работу «прямо с колес». В качестве инструмента планирования авторы рекомендуют использовать SCRAM или Agile KANBAN доску. Хотя даже в кругу специалистов по Agile-практике нет единогласия в том, нужно ли использовать доски как инструмент планирования. В общем подход гибкий, и каждый сам принимает решение.
2. Как и в первом, так и во втором подходе присутствуют инструменты по «сближению двух векторов»: ожиданий заказчика и результатов, передаваемых заказчику от исполнителя. Принципиальным отличием двух подходов является способ определения частоты демонстрации результата. При подходе Waterfall демонстрации прописаны в план-графике (Гантт ) и команда проекта старается его придерживаться, причем шаги между демонстрацией и результатом может быть как 10 дней, так и один месяц, и более. Agile рекомендует недельный и двухнедельный спринт. Исходя из своего опыта замечу, что при внедрении информационных систем в подразделениях ранее неавтоматизированных две недели на разработку какого-то нового функционала, взаимоувязанного с соседними блоками, часто бывает недостаточно. Причина - нет требований к смежным подсистемам, которые напрямую увязаны с функционалом, разрабатываемым в настоящее время. В этом случае архитекторам, бизнес-аналитикам и разработчикам приходится прогнозировать будущие потребности заказчика, опираясь только на свой собственный опыт. В некоторых случаях заложенные аналитики и разрезы в текущий функционал удовлетворяют потребности смежных подсистем. В других случаях приходится значительно переделывать ранее выполнение механизмы и функционал, что приводит к многократному увеличению трудозатрат на разработку единой информационной системы с взаимоувязанными блоками.
Ниже представлю обзорное сравнение плюсов и минусов указанных подходов:
Как видно из представленной таблицы, оба подхода имеют инструменты, которые можно применить для наиболее эффективного решения задач проекта. Для оценки эффективности применения той или иной методологии необходимо проанализировать задачи проекта.
4. Управление проектами, типы проектов
Рассмотрим, к какому основному типу проектов наиболее эффективно применять ту или иную методологию. На основе предложенной классификации мы сможем определить, к какому управлению проектами по типу проектов может быть применен тот или иной подход для наиболее эффективного достижения целей:
- Полностью типовые проекты, в которых разрабатываются стандартные продукты по обкатанной методике. Часто такие проекты называют «Типовой». Им соответствует нижний левый квадрант матрицы (рис. 1).
- Полностью инновационные проекты, когда организация должна разработать совершенно уникальный результат и при этом не представляет, как это делается. Такие проекты называют «мозговой штурм». Им соответствует правый верхний квадрант схемы.
- Встречаются и промежуточные варианты, когда уникальные продукты создаются типовыми методами или же типовые продукты производятся инновационными способами. Эти типы проектов условно называются «смешанные», и им соответствуют два оставшихся квадранта.
Управление проектами типа проектов «Типовой»
В каждой отрасли есть свои типовые проекты. Например, в торговых сетях - это массовая реорганизация торговых точек, изменение формата торговли, открытие и закрытие магазинов. В банках — открытие и закрытие отделений. В организациях, оказывающих масштабные профессиональные услуги (проектных институтах, IТ-компаниях), — разработка проектно-конструкторской документации, программного обеспечения, внедрение IТ-систем по общепринятым методологиям и стандартам: бизнес-процессы по продажам, закупкам, складским операциям в среднем и малом бизнесе с неразветвленной структурой компаний. В строительных, нефтегазовых компаниях — строительство и реконструкция зданий, сооружений, разведка и освоение месторождений. Особенности и риски таких проектов, типовые проблемы, которые могут возникнуть, хорошо известны руководителям проектов, давно работающим в компании. При управлении проектами такого типа на практике чаще всего используется методология Waterfall с типовыми описанными процедурами управления и контроля качества. Большим преимуществом в данном случае является получение заказчиком типового продукта и минимизация стоимости сопровождения типового прикладного решения, минимизации обучения сотрудников и разработки инструкций.
Управление проектами «Мозговой штурм»
Проекты данного типа связаны с инновационной деятельностью и разработкой продуктов, которые никто ранее не делал. Поэтому нет полной определенности, возможна ли в принципе реализация всех задач проекта. Такие проекты полностью уникальны. Это проекты связанные с разработкой предприятиями новых продуктов в новых областях (где у компании нет опыта) и опытно-конструкторские разработки, а также выполнение проектов строительными и нефтедобывающими компаниями.
Поскольку ход таких проектов уникален и постоянно подвержен изменениям, то нет экономической целесообразности тратить силы на регламентацию процесса управления проектами и детальной проработки документации с описанием процессов. Наибольшего эффекта здесь можно ожидать от команды проекта, ее опыта, мотивации и компетенции.
А как стоит управлять проектами «Мозговой штурм»?
Уникальные проекты слабо регламентированы и не формализованы. Их успех полностью зависит от личности менеджера проекта и климата в команде, то есть от того самого человеческого фактора, влияния которого хотели бы избежать. Однако если приоритетом бизнеса является реализация именно такого уникального и неформализованного проекта, то приходится с этим смириться. Многие интеграторы, реализуя подобные проекты, накапливают опыт, чтобы перевести проекты в категорию «смешанный» и со временем — «типовой».
Если проект «мозговой штурм» разовый для компании, то для минимизации рисков стоит отдать его на подряд профессиональной команде с опытом реализации подобных проектов. Поскольку вырастить в короткие сроки свою профессиональную команду с достаточным опытом не представляется возможным. В этом случае бизнес может частично переложить риски срыва сроков проекта или убытки на компанию исполнителя и тем самым в случае неудачного проекта частично компенсировать свои затраты (хотя бы моральные). Еще одним довольно эффективным способом, является привлечение на проект внешнего менеджера. Практика показывает, что многие проблемы в проектах связаны с разногласиями между сотрудниками заказчика и их незаинтересованностью в проекте. Кроме того, часто на руководителя проекта, назначенного из числа сотрудников компании, может оказывать большое давление первое лицо. Этого можно избежать при внешнем менеджере проекта и хорошо составленном контракте.
При управлении проектами такого типа на практике чаще всего используется подход- Agile. Так как бизнес-процессы слабо регламентированы, не формализованы и уникальны, то реализация и доведение системы до требуемого состояния — это совместный процесс команды: как экспертов со стороны исполнителя, так и экспертов со стороны заказчика. И ключевым фактором успеха проекта данного типа является непосредственное участие экспертов со стороны заказчика в приемке и тестировании разработанного функционала. В данном случае заказчик получает через 2-4 недели тот функционал, который ранее нигде не был описан и регламентирован. В связи с тем, что озвученные требования не всегда представляет собой полную и исчерпывающую информацию по требуемому результату, на следующих коротких итерациях эксперты со стороны заказчика дополняют требования. Они вносят изменения и таким образом происходит доведение механизмов и функционала до необходимого уровня. Контроль и управление процессом доведения функционала до «необходимого уровня» с использованием подхода – Agile является полностью творческим подходом и в настоящее время практически не существует способов измерения границ и сроков окончания данного процесса. Это основная ловушка в которую могут попасть и заказчики, и исполнители. Ведь нет границ и способов измерить сроки окончания процесса отладки функционала. При данном подходе успех полностью зависит от менеджеров проекта со стороны заказчика и со стороны исполнителя.
Управление проектами типа проектов «Смешанный»
Проекты типа «Смешанный» — нечто среднее между «типовым» и «мозговым штурмом». Это проекты, некоторые блоки которых типовые, а некоторые — уникальные. Либо проекты, в которых последовательность выполнения типовых блоков может меняться, а их состав варьироваться.
Большинство компаний стремится перевести такие проекты в категорию «типовой» и регламентировать управление ими. Если же уникальные блоки слишком большие по объему, то проекты дробят и назначают либо отдельные очереди, либо на каждый блок своего руководителя. Типовыми блоками управляют с использованием подхода – Waterfall, а нетиповыми — Agile. А стандартизация проектов типа «Смешанный» позволяет минимизировать риски, снизить стоимость поддержки при эксплуатации системы, обеспечить эффективную работу бизнеса по типовым и неформализованным уникальным бизнес процессам.
Литература:
· Правильный выбор. Практическое руководство по принятию взвешенных решений
Руководителю проекта о принятии решений в проекте
Автор: Джон Хэммонд, Ральф Кини, Говард Райффа
· Управление проектом: пять пороков команды
Этот бизнес-роман посвящен тому, как грамотно строить корпоративную среду, команду единомышленников
Автор: Ленсиони П.
· Управление продуктом в Scrum. Agile-методы для вашего бизнеса
Учебник для руководителя команды agile-разработки продукта
Автор: Пихлер Р.
· Управление проектами от А до Я
Букварь для тех, кто не хочет изучать PMBOK, но хочет узнать об управлении проектами
Автор: Ньютон Р.
· Гибкое управление проектами и продуктами
Практическое руководство от опытного специалиста по Scrum
Автор: Вольфсон Б.
· Теоррия ограничений: Цель-2. Дело не в везении
О проверенных временем и многочисленными компаниями по всему миру теории ограничений и методике мыслительных процессов
Автор: Элияху Голдратт
· Проектное управление в сфере информационных технологий
Российский опыт управления ИТ-проектами
Автор: Алексей Челяпин
· Бережливое производство плюс шесть сигм в сфере услуг
Объединение двух методик управления традиционно приносит отличные результаты не только в производственных проектах
Автор: Майкл Л. Джордж
· Scrum. Революционный метод управления проектами.
Книга основателя методики Scrum, которая поможет вам реализовывать проекты в несколько раз быстрее и эффективнее.
Автор: Джефф Сазерленд
· Ноев проект. Секреты практического проектного менеджмента
Еще один роман об управлении проектом. Вспомните "Deadline. Роман об управлении проектами" Тома де Марко.
Автор: Клайэм Р., Лудин И.
Специалист компании ООО "Кодерлайн"
Алексей Хлопиков.
