Залог успеха любого дела — в грамотном управлении процессом его реализации. А любое дело, выполняемое человеком или группой людей, можно назвать проектом. Cуществуют различные методы управления
проектами, наиболее распространенным из которых считается классический «водопад» (Waterfall). Главная особенность такого подхода заключается в том, что нельзя перейти на следующий этап, не завершив
предыдущий. Проект в классическом понимании делится на несколько этапов: инициирование, планирование, реализация, тестирование, доработка и сдача заказчику.
Если говорить об ИТ-проектах, то в них, как правило, еще присутствует этап технологического планирования, где решаются вопросы выбора платформы для реализации будущего проекта, определения языка
программирования, механизмов интеграции и т. д. Разумеется, у каждого из этапов есть строгие календарные и временные рамки, в соответствии с которыми работа должна быть выполнена и представлена
заказчику либо начат переход к следующей фазе, а заказчик подключается уже на завершающем этапе, и его задача состоит в том, чтобы оценить и принять результат или сформулировать претензии, ведущие
к необходимости доработки, исправлений или дополнений.
===========================
Ольга Рубцова, генеральный директор компании «ТехноСофт»: «Люди, которые не умеют и не хотят договариваться, не смогут работать в методологии Agile»
===========================
Метод проектного управления Waterfall отличается тем, что не требует от заказчика еще на самом раннем этапе сформулировать все требования и пожелания к результатам проекта и в дальнейшем следить за
их неукоснительным соблюдением. Хорошо это или плохо? Есть положительная сторона, поскольку это дисциплинирует заказчика и всю проектную команду, а все этапы реализации проекта делает более
прозрачными и предсказуемыми. С другой стороны, мир не стоит на месте. Изменения на рынке происходят с калейдоскопической быстротой, и бизнесу необходимо успевать адаптироваться к ним. Те
пожелания, которые заказчик высказал еще полгода или даже год назад, сегодня уже могут потерять свою актуальность. В этом случае придется мучительно исправлять, дорабатывать и переделывать многое.
А это срыв сроков, перерасход бюджета, но самое главное — стресс для всех участников проектной команды.
==========================
Марина Федорова, директор департамента управления проектами «Энвижн Груп»: «Основные качества любого участника Agile-команды — самодисциплина и ответственность»
==========================
Здесь на помощь приходят новые методы управления проектами, объединенные в общую концепцию под названием Agile. Их главное отличие состоит в том, что проект делится на несколько небольших
подпроектов, которые выполняются не жестко последовательно, как в случае с Waterfall, а параллельно. Затем результаты этапов собирают в готовый продукт. Почему мы говорим именно о «подпроектах», а
не о «стадиях» в классическом подходе? Потому что каждый «подпроект» условно может быть разделен на все те же стадии, что и классический проект. Таким образом удается гораздо быстрее и без
дополнительных усилий и расходов реализовывать изменения и новые возможности. Важнейший принцип Agile-проектов — максимальная вовлеченность заказчика во все подпроекты, а не только участие в
заключительном этапе. По сути, в Agile главным фактором становится не время и соблюдение сроков, а процесс. Agile — это лишь концепция работы, но в ее рамках существует целый ряд методологий,
помогающих грамотно построить проектную команду и организовать рабочие процессы — Scrum, Kanban и другие. Мы сейчас не будем подробно останавливаться на каждой из них, нам было бы интереснее
узнать, в каких случаях целесообразнее применять передовые гибкие подходы к управлению проектами, а когда применение старого доброго «водопада» будет не только привычнее, но и выгоднее с
практической точки зрения.
===========================
Александр Кондратенко, директор департамента программных решений компании «Техносерв»: «Команды, работавшие в классической нотации, не могут изменить подход по щелчку тумблера.
Лучше действовать замещением — параллельно развивать Agile-направление, в которое вовлекать сотрудников, не только обращающих внимание заказчика на результат в соответствии с контрактными этапами и
монолитное решение в конце года, но и способных относиться к каждой сборке, как к конечному продукту»
============================
Waterfall для фундаментальных задач
По мнению Марины Федоровой, директора департамента управления проектами компании «Энвижн Груп», преимущество проектов системной интеграции заключаются в заранее сформированных жестких требованиях к
реализации и определенные сроки. А кроме того, содержат подсистемы, не взаимодействующие друг с другом. «В данном случае наиболее эффективные результаты приносит использование классических систем
управления проектами, предполагающих заранее составленные планы-графики работ, ресурсное планирование в зависимости от этапов выполнения проекта, жесткий контроль за сроками», — отмечает она.
«Классические методы применимы, если в проекте достаточно времени и пул входящих требований формализован осознанной работой команды специалистов, — дополняет Александр Кондратенко, директор
департамента программных решений компании «Техносерв». — Кроме того, классические методы хороши, если требуется разработать специальное программное обеспечение, которое будет основой бизнеса в
течение длительного времени. Даже в этих случаях, планово потратив значительные ресурсы, достаточно часто приходится все оперативно переделывать в самый последний момент из-за запятой в
требованиях, «имелось в виду» и т.д. Порой все непросто переделать, а по сути, создать заново с учетом всех полученных проектных знаний».
В то же время Сергей Стрелков, руководитель направления собственных разработок компании «КРОК», полагает, что в целом для ИТ-проектов метод «водопада» устарел, так как и ИТ-, и бизнес-процессы в
современном мире очень быстро меняются, и реализовать успешный масштабный проект, не учитывая этих изменений, становится практически невозможно. «Но, например, для капитального строительства такой
подход на сегодня не теряет актуальности, ведь даже в условиях цифровизации проектирования и контроля строительства объектов, быстро изменить строящееся здание практически невозможно», — добавляет
он. Не столь категоричен Дмитрий Козаченко, технический директор компании Dassault Systemes в России и СНГ. По его мнению, модель Waterfall полностью фиксирует риски исполнителя и заказчика, но
применять ее нужно только тогда, когда работа происходит не в условиях полной неизвестности. «Как только появляются ИТ-проекты, в которых нужно выполнять работу, не понимая и не зная заказчика,
модель Waterfall работать не будет», — подчеркивает эксперт.
============================
Сергей Стрелков, руководитель направления собственных разработок компании «КРОК»: «Как говорит Луис Герстнер, даже слоны умеют танцевать. Без оправданных изменений любой бизнес
начнет вытесняться более гибкими конкурентами»
=================================
О целесообразности перемен
Гибкие методы управления проектами требуют значительных изменений в организационной структуре и бизнес-процессах компании. Зачастую эти изменения не только затратны, но и весьма болезненны. Есть ли
смысл в столь радикальных переменах? «Если компания хочет стабильно выпускать успешные продукты, которые будут нужны многоим людям, она обязана уметь очень быстро трансформироваться. Будет ли это
Agile или Waterfall — не имеет значения», — говорит Дмитрий Козаченко (Dassault Systemes). Сергей Пономарев, технический директор компании «АСКОН-Интеграционные решения», полагает, что радикальные
изменения ради перехода на Agile востребованы в тех случаях, если компания выпускает ИТ-продукты, предназначенные для массового пользователя. «В нашем случае полностью переходить на метод типа
Agile нецелесообразно, — поясняет он, — Для такого метода мало изменений внутри самого интегратора, важно, чтобы и заказчик был готов работать в режиме гибкого подхода к реализации проекта. А
крупные промышленные предприятия нередко не готовы к формату взаимодействия, который подразумевает Agile-команда. Здесь лучше применять комбинированный подход, включающий элементы разных методов».
=========================
Дмитрий Козаченко, технический директор Dassault Systemes в России и СНГ: «Agile-мышление, как правило, приводит к умению быстро изменяться, познавать новое, часто ошибаться и
исправляться»
==========================
По мнению Ольги Рубцовой, генерального директора компании «ТехноСофт», одна из наиболее частых ошибок состоит в том, что компании выбирают Agile для управления проектами, поскольку «это сейчас
модно». Но при этом не могут изменить ни свое мировоззрение, ни свои подходы, ни своих сотрудников. Они продолжают мыслить по факту терминами Waterfall, внедряя по методологии Agile, а это утопия.
«Agile — не изменение методологии ИТ-систем, а изменение подходов к работе, к процессам, к скорости реакции и скорости принятия решений», — считает она.
«Если компания занимается разработкой программного обеспечения, в рамках которой и родились гибкие методики управления проектами, то обратить внимание на методики Agile однозначно стоит и результат
будет стремиться к положительному. В остальных случаях следует учитывать структуру бизнеса компании и гибкость взаимодействия с заказчиком», — говорит Марина Федорова («Энвижн Груп»).
Сплоченная и дружная команда
В любой проектной команде, работающей по Agile, бизнес-специалисты очень тесно сотрудничают с ИТ-специалистами. Чтобы такое взаимодействие было действительно успешным, нужно, как считает Александр
Кондратенко («Техносерв»), чтобы в состав команды входил ИТ-эксперт, которого бы понимал бизнес и который сам бы понимал представителей бизнеса. «Он должен уметь провести презентацию сборки, где,
конечно же, естьт ошибки, получить предметную обратную связь, сбалансировать ожидания от новых встреч. Основное правило — большая часть пожеланий заказчика должна быть реализована. Наличие схемы
эскалации при отсутствии единой позиции бизнеса приведет к выходу из цикла согласования», — объясняет Александр. «Для нашей компании один из основных секретов успеха проекта — понимание бизнеса и
предметной области не хуже, а зачастую и лучше заказчика. Кроме того, в нашей практике принято еще на этапе предложения описывать степень вовлеченности клиента в работу над проектом», — дополняет
Сергей Стрелков («КРОК»). По мнению Александра Башкирова, руководителя департамента разработки компании “Адванта Консалтинг”, вовлеченность владельца продукта в процесс разработки в некотором
смысле является залогом успеха. «Это необходимое, но не достаточное условие. Достаточностью обладает, например, набор всех Scrum-практик, таких как митинги, грумминги, целеполагание и т. д. Но
основное в том, чтобы сформировать единую команду из айтишников и бизнесменов», — объясняет он.
=========================
Александр Башкиров, руководитель департамента разработки компании «Адванта Консалтинг»: «За счет внедрения гибких методологий работы компания может получить значительные бонусы. Правда,
надо очень четко представлять, что придется перестроить всю компанию, идеологию, мышление»
=========================
Любой проект не может быть полностью застрахован от неудачи, это касается и тех, что управляются по принципам Agile. Впрочем, как показывает статистика, фиаско здесь случаются реже, чем в
Waterfall-проектах. «Если рассмотреть ИТ-проекты, то причина неудач в том, что бизнес зачастую смотрит на Agile как на еще один метод управления командой, что в корне неверно. Agile — стиль работы
компании, команды. Команда в Agile — это не только айтишники. Это бизнес, это все заинтересованные. И попытка «рулить» командой в Agile директивно — почти всегда ведет к провалу, потому что
практически всегда провоцирует конфликт», — комментирует Александр Башкиров («Адванта Консалтинг»).
Выбирай на вкус
Что касается выбора конкретной методологии гибкого управления проектами, здесь однозначного рецепта никто из опрошенных нами экспертов не дал. Александр Башкиров («Адванта Консалтинг») советует
исследовать аналогичные или похожие кейсы. «Исследовать методики и понимать, какая из них лучше всего впишется именно в вашу конкретную компанию, — поясняет он. — Не существует универсального
рецепта типа «бери Scrum — и будет счастье». В одних случаях хорошо работает Scrum, в других — Kanban. Но вот что заработает в вашем конкретном случае — в большой степени зависит от специфики
компании. Поэтому подобрать «самый правильный Agile» не то чтобы сложно, а невозможно».
«У каждой методики есть свои плюсы и минусы. Некоторые хорошо адаптированы для определенных индустрий. Lean подходит для производственных компаний, Scrum хорошо себя зарекомендовал в финансовом
секторе. Необходимо смотреть, чего мы хотим от этого проекта и методологии, что мы меняем с помощью нее. И изучать при этом лучшие практики», — дополняет Ольга Рубцова (“ТехноСофт”).
Начинаем меняться
Итак, стоит ли переходить на новые принципы управления проектами? Нужно ли это для организации, а если нужно, то как подготовиться к подобному переходу? Марианна Крель, директор по организационному
развитию и консалтингу компании «Адванта Консалтин», советует, прежде всего, оценить, является ли новая методология «свежей версией затычки от старой дыры» в управлении или же инструментом
улучшения качества управления, инструментом передела власти или ее укрепления, «костылем» для сокрытия ошибок команды или структурой для достижения командного результата. Важно точно определить, по
какой оси будут идти изменения и как они повлияют на другие оси. Корпоративная система управления проектами (КСУП) состоит из нескольких элементов: бизнес-процессы, информационная система,
методология, люди.
=========================
решения аналогичных задач (hard skills, матрица компетентности в помощь), черты характера человека (склонность к определенным типам деятельности) и компетенции (soft skills)».
==========================
Ошибаются те, кто думает, будто можно изменить только один элемент, не изменяя другие. Сам процесс подготовки, по словам Марианны Крель («Адванта Консалтинг»), включает формулировку целей, ожиданий
и опасений от перехода на новую методологию; определение текущего и целевого состояния, в том числе уровней организационной структуры, типов проектов, скорости получения изменений при
переходе на новую методологию; выбор пилотной зоны и временных правил на период перехода; отслеживание динамики с момента начала перехода, а не просто фиксацию результата; и конечно же, управление
процессом перехода на новую методологию как проектом, с этапами, целями, руководителем и контролем за достижением целей. «Нет никакого волшебного знания, чтобы понять, нужно тебе это или нет, —
считает Ольга Рубцова («ТехноСофт»). — Чтобы подготовиться к такому переходу, надо изучить тематику. Сейчас очень многие, рассуждая об Agile, понятия не имеют, что это такое: нет ни опыта, ни
навыков, ни теоретической базы. Поэтому, как и к любому процессу изменений, надо готовиться, начиная с теоретической базы, и потом обучать людей, планировать процессы, мотивировать персонал,
создавая правильную культуру для того, чтобы эти проекты были успешны».
Выводы
Управление проектами уже давно считается научной дисциплиной, которую изучают в университетах, бизнес-школах, на тренингах и т. д. Однако в ней нет жестких аксиом, а есть наборы рекомендаций,
методологии и схемы. Для успешного выбора пути, по которому пойдет компания, нужно тщательно проанализировать ситуацию в ней и на рынке, выбрать сотрудников, не только готовых, но и способных
работать в проектной команде и определить наиболее подходящую работы методологию либо сформировать свою из нескольких. Ведь универсальных рецептов не существует.
===========================
Сергей Пономарев, технический директор компании «АСКОН-Интеграционные решения»: «Если есть стремление улучшить показатели проектной деятельности, то значит нужно что-то менять. Но,
прежде всего, необходимо выяснить коренные причины неудовлетворительного текущего состояния. И только после этого принимать решение об изменении методологии проектного управления».
Теги: Agile, управление проектами, руководитель проекта, SCRUM, ИТ-директор, ИТ менеджер
Горячие темы: Бизнес в цифре
Журнал IT Manager [ Подписка на журнал ]
Об авторе
Григорий Рудницкий
Историк по образованию. В ИТ-прессе – бумажной и онлайновой – с 2002 года: публикуется в изданиях, ориентированных как на домашних, так и на корпоративных пользователей. Любимые темы: гаджеты, мобильность, облачные сервисы, свободное программное обеспечение.
