Существует множество подходов к ведению IT- проектов и каждый из них находит своих последователей, успешно используется в одних проектах, с треском проваливается в других, приводит в восхищение часть клиентов и вызывает негодование у другой части. Порассуждаем о том, можно ли смешивать подходы, методы и методологии, чтобы достигать поставленных целей.

Важно!

• В статье присутствует определенная доля иронии.
• Статья ни в коем случае не ущемляет чьи-либо интересы.
• В статье не противопоставляется SCRUM водопаду и не смешивается «мягкое с теплым».
• У каждого свое мнение на процесс разработки проектов, свой опыт или его отсутствие, свой счастливый клиент или свой провалившийся проект, выполненный по методологии, с помощью проектных методик, руководствуясь принципами или интуицией.
• Будьте добрее!

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

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

Давайте поговорим о клиентах

Как правило, им хочется укладываться в первоначальный запланированный бюджет, иметь возможность регулярно видеть результаты проекта, влиять на ход проекта, вносить изменения в продукт.
Фиксированный бюджет всего проекта у нас предполагает, как пример, водопадная модель, возможность влиять на продукт и вносить изменения широко представлена в гибких методологиях, итерации и регулярные демонстрации характерны также для гибких методологий, документация, покрывающая все этапы проекта ярко представлена в PMI.
Получается такой очень милый клиентам Франкенштейн методологий и подходов к управлению.

Для проектной команды

Наибольший интерес представляют проекты, в которых можно вносить предложения по улучшению, т.е. участвовать в развитии продукта. Так, в процессе мозгового штурма можно придумать новую полезную опцию или использовать интересную технологию/язык программирования. В такой работе переплетается и творчество, и высокие риски, поэтому фиксированный бюджет здесь не подходит, он лишь будет тяжким грузом висеть и ограничивать простор для фантазии. Командам нравится работать на основе time and material, выбирать приоритеты задач в том порядке, в котором будет удобнее разрабатывать. При таком гибком подходе очень легко принимаются новые пожелания клиентов и меняются приоритеты задач.

Для компании

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

Для менеджера

C точки зрения проектной работы идеальной моделью является водопадная модель. Тут на старте нужно постараться задокументировать продукт, предусмотреть все риски, а потом контролировать, что все идет согласно плану А вот с точки зрения командной работы — хочется креатива, хочется подсказывать, делиться опытом, менять курс. Командные обсуждения, brainstorm, daily митинги, меняющийся продукт – это все позволяет сделать Agile философия.

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

Смешивать!

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

Можно работать по SCRUM, но с фиксированным набором спринтов. Такая модель больше подойдет стартапам, когда хочется и видеть развитие продукта, и изменять его, и в то же время оставаться в рамках бюджета. До начала спринта отбираются задачи, оцениваются, клиенту предоставляется смета. Эта смета утверждается и уходит в работу, любые изменения переносятся в следующий спринт, при этом если изменение было на 8 часов, то из проекта удаляется любая другая задача на это же количество часов. Здесь и команда может эффективно работать над поставленными задачами, и клиент влияет на процесс, составляя задачи в спринт, и клиент контролирует свой бюджет. В таком случае продукт выходит в свет, даже с урезанной функциональностью.

Существует подход, при котором клиент платит ежемесячно фиксированную сумму, при этом команда обрабатывает различное количество задач из месяца в месяц. Иными словами клиент берет команду в аренду. Он может насыпать им задач на всю неделю, а может совсем не подготовить задач, при этом команда будет получать ежемесячно оговоренную сумму.
Такой подход не обязательно относится к проектам технической поддержки, он уместен и для разработки продукта.
Для клиента такой подход подразумевает фиксированные затраты и высокую заинтересованность в загрузке команды. Для компании, которая предоставляет такой сервис, гарантирована занятость сотрудников и стабильные пополнения бюджета.

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

Очень хочется услышать ваш опыт, получается ли у вас работать только в рамках одной методологии/методики?

Если вы работали по классической каскадной модели, писали концепцию/ТЗ/Рабочий проект/Спецификации/прочее, строили диаграммы Ганта, рисовали водопадные схемы, предусматривали реестр рисков, вели, так называемый, «out of scope» и только после окончания плановых работ вернулись к нему, уложились в плановый бюджет и срок, ваш клиент остался в восторге от проекта, ВЫ КРУТЫЕ и низкий вам поклон! Вы скрупулёзный менеджер, с чувствительными частями тела с одной стороны и железными частями с другой стороны, что помогло вам провидеть ход проекта и отстоять заключенные договоренности, как с командой, так и с клиентом. Напишите в комментариях «ВОДОПАД!», страна должна знать героев в лицо.

Если для своих проектов вы выбрали гибкую модель разработки, основанную на принципах Agile, вы знаете Agile Manifesto лучше, чем пароль от вашей почты, ваши команды высокоорганизованные, ваши Клиенты счастливы от результатов, которые они получают от итерации к итерации, вы чувствуете себя как рыба в воде, меня курс направления, ВЫ МОЛОДЫ! У вас гибкий ум, молниеносная реакция, низкая инертность и высокая говорливость. Вы очень очень очень много комуницируете. Напишите в комментариях «Agile» (пусть все знают, вы можете работать гибко и вы это делаете успешно!)

Если вы умете совмещать методологии с методиками, принципы с правилами и у вас получается, расскажите всем, как вы это делаете?

Что вам не позволяет работать в рамках строго одного метода/подхода/методологии? Клиенты такие разные? Обстоятельства? Менеджеры? Проектные решения? Принципы работы компаний? Неудобства и ограничения?

Автор:

Источник