Это статей я крупно рискую быть затоптанным армией фанатов Scrum, Kanban, XP и других методик гибкого планирования. Мне придется привести аргументы в пользу того, что мир не черно-белый, и что стандартная диаграмма Ганта тоже полезна, а в некоторых случаях даже приоритетна для менеджмента проектов в IT.

Ладно, я знаю, что оправдания и водянистые введения никому не нравятся, но этот дисклеймер нужен для того, чтобы вы обратили внимание и на альтернативный опыт.

Небольшое введение для новичков в проектном менеджменте. Что такое Agile и Waterfall модели, и чем они отличаются друг от друга?

Waterfall — каскадная модель, в которой четко видна последовательность действий в проекте. Рабочие задачи выставлены одна за другой, что визуально показано сменой блоков. По оси X отложено время выполнения, поэтому диаграмма Ганта показывает не только последовательность и взаимосвязи, но и время на каждую задачу.

В целом, бессмысленно словами описывать визуально понятную вещь. Проще показать.

Это классическое изображение Waterfall модели, но задачи не обязательно идут последовательно. Некоторые процессы могут идти параллельно, особенно если не зависят от предыдущих отрезков реализации проекта. Такой метод называется гибридным и частично решает главную проблему каскадной модели — «неповоротливость» и большие затраты времени на разработку.

Agile — с английского название этой модели переводится как «Гибкая», и это лучшее описание принципов метода планирования. На самом деле, Agile — это целая группа методов проектного менеджмента, самые известные из которых: Scrum, Kanban, FDD и другие концепции.

Объединены они одним принципом работы. Проект делится на итерации (отрезки), называемые спринтами. Они ограничены во времени (неделя, две недели, месяц). Перед каждым спринтом ставятся конкретные задачи по параллельной работе над частью проекта. Результатом спринта должна быть полноценная часть продукта, готовая к тестированию.

Проверка на ошибки, к слову, проводится сразу, а не в конце реализации проекта, как при Waterfall. Это позволяет их быстро исправлять, и экономить время на доработки крупных проблем, которые возникнут из-за ошибки в дальнейшем.

При Agile моделях организациях команды работа над элементами проекта ведется параллельно, а не последовательно. Такой подход имеет много преимуществ:

  • Высокая скорость достижения результатов.

  • Изменения в проект могут быть внесены на любом этапе и реализованы уже в следующем спринте.

  • Постоянный фидбек от заказчика и гибкое планирование.

  • Распределенная и децентрализованная модель работы команды.

И многие другие плюсы. Но есть один значимый минус — сроки и стоимость реализации такого проекта оценить заранее невозможно. Все будет зависеть от того, в какую сторону пойдет разработка, сколько потребуется спринтов, и какое время специалистов будет в итоге задействовано.

Возвращаемся к вопросу в заголовке: «Agile или Waterfall. Какой метод организации выбрать для работы с заказчиками?»

Большинство новичков в менеджменте IT проектов выросли в парадигме: «Agile/Scrum — хорошо, Диаграмма Ганта — устаревший метод». Для них тезис: «Waterfall — лучшее решение для разработки проектов на заказ» звучит почти как оскорбление. Но реальный опыт работы с заказчиками показывает, что 90%+ клиентов IT-компаний хотят еще до начала сотрудничества точно знать, сколько времени и денег нужно для получения результата.

Абсолютное большинство заказчиков — это представители бизнеса. Их почти никогда не устраивает формулировка: «Точно сказать сложно, давайте начнем работу над проектом, а потом определимся, когда сможем закончить, и сколько это стоит» от менеджера IT-компании. Для предпринимателя подписаться на что-то неограниченное по времени и бюджету очень сложно. Это договор с неизмеримой степенью риска. И сколько ты не доказывай ему преимущества Scrum и гибкого подхода, в мозгу бизнесмена эти доводы будут звучать как попытка обмануть поубедительней.

Четкое понимание сроков и стоимости разработки дает только планирование работ по модели Waterfall со включением временных буферов и погрешности на непредвиденные задержки.

Из этого утверждения есть 2 исключения, при которых можно использовать гибкие системы менеджмента для проектов под заказ:

  • Заказчик абсолютно доверяет подрядчику. Сценарий, который практически не встречается в реальной жизни. Клиент должен быть полностью уверен, что исполнитель не преувеличит сроки и не раздует смету. Даже когда директор компании-заказчика и менеджер проекта хорошо знакомы лично, договориться на «открытые» сроки и бюджет очень сложно. Более того, это даже опасно для личных отношений между людьми. Мысль о том, что смета раздута, все равно промелькнет.

  • Заказчик полностью погружен в работу над проектом. Это более реалистичный сценарий, актуальный для стартапов. Когда у клиента бизнеса еще по факту нет, он прямо сейчас строится силами сторонней команды. Тогда он на правах руководителя будет ежедневно включен в разработку, а также лично будет видеть и утверждать объем работ. Заказчик должен понимать, что подписывается на «открытый» бюджет и сроки разработки.

Но даже в этом случае четкое предложение от другой команды разработчиков с фиксированной ценой и определенным дедлайном для заказчика будет выглядеть привлекательней. Бессознательно предприниматель будет стараться сократить риски, где это возможно. Это профдеформация. 

Представьте себя на его месте: Вы ищете сантехника, чтобы починить протекающий кран. Первый говорит —  10 долларов, сделаю за полтора часа, а второй — не может назвать сумму и утверждает, что итоговая цена будет зависеть от того, как пойдет работа.

Agile методики менеджмента — отличное решение для работы над собственными проектами IT-компании. В таком случае проблемы прогнозирования сроков и суммы затрат перестает быть острым, а компания может использовать все преимущества гибкой системы работы над проектом. 

Но именно для продаж, взаимодействия с клиентами ничего лучше старой доброй диаграммы Ганта придумано не было. Американский институт управления проектами (PMI) до сих пор рекомендует Waterfall в качестве оптимальной методологии планирования и управления. По версии организации, лучший подход — использование гибридных моделей, когда этапы работы идут не строго последовательно, а некоторые дела выполняются параллельно. В целях экономии времени и оптимизации управления проектом.

Источник — Курс «Как стать классным менеджером проектов и не ох..еть»

Ссылка на курс для жителей России

Комментарии (4)


  1. AlastorMoody
    04.05.2022 17:24
    +3

    Источник — Курс «Как стать классным менеджером проектов и не ох… еть»

    Ссылка на курс для жителей России

    udemy.com/course/pmcourse/?referralCode=7BA56281935B50900042

    То есть вы в качестве поста дали описание аджайлу и ватерфоллу просто для того, чтобы попиарить рефералку собственного курса, или это просто создаётся такая видимость?


  1. Ndochp
    04.05.2022 17:47
    +2

    Американский институт управления проектами (PMI) до сих пор рекомендует Waterfall в качестве оптимальной методологии планирования и управления.

    Вика так и пишет про изменения в их программном документе:
    2017 PMBOK Guide, Sixth Edition The sixth edition (September 2017) added several topics and included agile practices for the first time.
    2021 PMBOK Guide, Seventh Edition The seventh edition (2021) presents major structural changes, such as replacing the 10 knowledge areas with 12 principles and including agile practices more comprehensively.


  1. JordanCpp
    04.05.2022 23:51
    +1

    Для начала выполнять свои обязанности. Типа на работе работать. Это уже даст серьезный буст в любом деле.


  1. ValeryGL
    06.05.2022 09:40

    Вы ищете сантехника, чтобы починить протекающий кран. Первый говорит —  10 долларов, сделаю за полтора часа

    1. После того, как договорились на 10 долларов, вы и сантехник обнаруживаете, что кто-то просто не умеет закрывать кран и чинить тут нечего. Ваши действия?

    2. Слесарь починил кран, собрал всё назад и, получив 10 баксов, заодно рассказал, что нужно менять подводку к крану и сгнившую тумбочку. Будете ли вы злиться на слесаря, что он не сделал еще и это на 10 баксов? А на то, что он теперь для ремонта подводки нужно еще раз вызывать слесаря, разбирать весь сетап и т.д., хотя можно было бы сразу, пока тумбочка рабозрана?

    В случае T&M это бы решалось по ходу работы, как там в XP это называется - Whole team, Onsite customer.