FixPrice Agile или SCRUM через Ж… иру
Важно!
- В статье присутствует определенная доля иронии.
- Статья ни в коем случае не ущемляет чьи-либо интересы.
- В статье не противопоставляется SCRUM водопаду и не смешивается «мягкое с теплым».
- У каждого свое мнение на процесс разработки проектов, свой опыт или его отсутствие, свой счастливый клиент или свой провалившийся проект, выполненный по методологии, с помощью проектных методик, руководствуясь принципами или интуицией.
- Будьте добрее!
Scrum — это, конечно, хорошо, когда есть четкий набор задач на спринт, командный дух бесконечно поднят, клиент платит за спринты, потому что он уже привык это делать, а компания получает доход и верит, что проект никогда не закончится.
Водопад — это тоже здорово, клиент четко знает, что уложится в определенный бюджет, все шаги расписаны до мелочей, но до той поры, пока клиент не захочет что-то изменить в проекте или начинает понимать, что проект идет не туда, куда хотелось бы.
В условиях, когда клиент хочет четко знать свои затраты, команда хочет драйва и иметь возможность влиять на ход проекта, а компания хочет стабильно получать свой доход, менеджеру приходится маневрировать между всеми этими требованиями и выбирать подходящую методологию, метод, принципы, правила.
Именно поэтому можно проследить тенденцию к смешиванию методологий, правил и принципов.
Давайте поговорим о клиентах
Как правило, им хочется укладываться в первоначальный запланированный бюджет, иметь возможность регулярно видеть результаты проекта, влиять на ход проекта, вносить изменения в продукт.
Фиксированный бюджет всего проекта у нас предполагает, как пример, водопадная модель, возможность влиять на продукт и вносить изменения широко представлена в гибких методологиях, итерации и регулярные демонстрации характерны также для гибких методологий, документация, покрывающая все этапы проекта ярко представлена в PMI.
Получается такой очень милый клиентам Франкенштейн методологий и подходов к управлению.
Для проектной команды
Наибольший интерес представляют проекты, в которых можно вносить предложения по улучшению, т.е. участвовать в развитии продукта. Так, в процессе мозгового штурма можно придумать новую полезную опцию или использовать интересную технологию/язык программирования. В такой работе переплетается и творчество, и высокие риски, поэтому фиксированный бюджет здесь не подходит, он лишь будет тяжким грузом висеть и ограничивать простор для фантазии. Командам нравится работать на основе time and material, выбирать приоритеты задач в том порядке, в котором будет удобнее разрабатывать. При таком гибком подходе очень легко принимаются новые пожелания клиентов и меняются приоритеты задач.
Для компании
На мой взгляд, интересна водопадная модель. При таком подходе на старте проекта оговариваются и документируются все требования, выставляются рамки, четко видна цель проекта, легко сопоставить требования с актами приемки. Мы получаем минимум неожиданностей, минимум рисков, и при этом, четко прописанные даты и бюджеты. При использовании такой модели порядка больше, компания увереннее прогнозирует получение очередного транша.
Для менеджера
C точки зрения проектной работы идеальной моделью является водопадная модель. Тут на старте нужно постараться задокументировать продукт, предусмотреть все риски, а потом контролировать, что все идет согласно плану А вот с точки зрения командной работы — хочется креатива, хочется подсказывать, делиться опытом, менять курс. Командные обсуждения, brainstorm, daily митинги, меняющийся продукт — это все позволяет сделать Agile философия.
Что же делать в ситуации, когда:
— на глубокую аналитику в начале проекта нет времени или не выделяются финансы,
— есть жестко фиксированный бюджет и этапы сдачи, прописанные в договоре,
— в процессе проекта возникают новые пожелания, которые никоем образом не могут быть перенесены во вторую версию продукта и появляются другие незапланированные задачи?
Смешивать!
Можно работать по водопаду, но оставлять бюджет для маневров. В такой модели договор будет оформлен на основную функциональность продукта, а дополнительными соглашениями можно изменять рамки проекта. Таким образом будет решена задача фиксированного бюджета и добавления новшеств в продукте в процессе разработки.
Можно работать по SCRUM, но с фиксированным набором спринтов. Такая модель больше подойдет стартапам, когда хочется и видеть развитие продукта, и изменять его, и в то же время оставаться в рамках бюджета. До начала спринта отбираются задачи, оцениваются, клиенту предоставляется смета. Эта смета утверждается и уходит в работу, любые изменения переносятся в следующий спринт, при этом если изменение было на 8 часов, то из проекта удаляется любая другая задача на это же количество часов. Здесь и команда может эффективно работать над поставленными задачами, и клиент влияет на процесс, составляя задачи в спринт, и клиент контролирует свой бюджет. В таком случае продукт выходит в свет, даже с урезанной функциональностью.
Существует подход, при котором клиент платит ежемесячно фиксированную сумму, при этом команда обрабатывает различное количество задач из месяца в месяц. Иными словами клиент берет команду в аренду. Он может насыпать им задач на всю неделю, а может совсем не подготовить задач, при этом команда будет получать ежемесячно оговоренную сумму.
Такой подход не обязательно относится к проектам технической поддержки, он уместен и для разработки продукта.
Для клиента такой подход подразумевает фиксированные затраты и высокую заинтересованность в загрузке команды. Для компании, которая предоставляет такой сервис, гарантирована занятость сотрудников и стабильные пополнения бюджета.
В заключении хочу сказать, что каждая компания, клиент, проект — уникальны. Любой из существующих подходов может подойти именно для вашего проекта, а если нет — придумайте свой подход, и найдите того партнера, с которым вы сможете реализовать его.
Очень хочется услышать ваш опыт, получается ли у вас работать только в рамках одной методологии/методики?
Если вы работали по классической каскадной модели, писали концепцию/ТЗ/Рабочий проект/Спецификации/прочее, строили диаграммы Ганта, рисовали водопадные схемы, предусматривали реестр рисков, вели, так называемый, «out of scope» и только после окончания плановых работ вернулись к нему, уложились в плановый бюджет и срок, ваш клиент остался в восторге от проекта, ВЫ КРУТЫЕ и низкий вам поклон! Вы скрупулёзный менеджер, с чувствительными частями тела с одной стороны и железными частями с другой стороны, что помогло вам провидеть ход проекта и отстоять заключенные договоренности, как с командой, так и с клиентом. Напишите в комментариях «ВОДОПАД!», страна должна знать героев в лицо.
Если для своих проектов вы выбрали гибкую модель разработки, основанную на принципах Agile, вы знаете Agile Manifesto лучше, чем пароль от вашей почты, ваши команды высокоорганизованные, ваши Клиенты счастливы от результатов, которые они получают от итерации к итерации, вы чувствуете себя как рыба в воде, меня курс направления, ВЫ МОЛОДЫ! У вас гибкий ум, молниеносная реакция, низкая инертность и высокая говорливость. Вы очень очень очень много комуницируете. Напишите в комментариях «Agile» (пусть все знают, вы можете работать гибко и вы это делаете успешно!)
Если вы умете совмещать методологии с методиками, принципы с правилами и у вас получается, расскажите всем, как вы это делаете?
Что вам не позволяет работать в рамках строго одного метода/подхода/методологии? Клиенты такие разные? Обстоятельства? Менеджеры? Проектные решения? Принципы работы компаний? Неудобства и ограничения?
Комментарии (3)
SlavikF
3 марта 2017 в 23:54
0↑
↓
Самая засада с Agile у меня была, когда я работал QA менеджером в медицинской компании (выпускали медицинский софт). Специфика была такая, что:
— Наше направление деятельности довольно серьёзно регулируется федеральными и штатовскими законами (США), такими как HIPAA, FDA Title 21
— У нас сертификация ISO, так что всё должно идти в соответствии с процессами
— От штата и от ISO к нам аудиторы приезжают и проверяют.Поэтому, что бы писать софт по всем правилам, были такие вещи:
— У нас были чётко описанные WI (Work Instructions) и SOP (Standard Operating Instructions), в которых довольно детально описывалось, как должно проходить тестирование, как проверяются баги и т.д.
— Мы должны были выдавать (или принимать участие) горы документации, включая: требования, трассировку требований, тест план, тест протоколы, анализ рисков и т.д.В общем по моему мнению, у нас был водопад. Да, было несколько забюрократизировано, но в общем вменяемо.
Но потом, похожа какая-то муха укусило начальство, и нам стали говорить, что мы «недостаточно agile»… Наняли начальника разработки специально, чтобы выстраивать agile-процесс.
Я всё никак не мог взять в толк: как можно совместить agile-процесс со всей бюрократией и процессами специфичными для наших продуктов?Вот и натягивали сову на глобус… Сначало ушло несколько разработчиков. Потом ушёл я. Что было потом — не знаю, но сейчас настраиватель agile-процессов уже там не работает.
А вот сейчас я работаю в компании, где у нас SaaS, не связанный с медицинской сферой. У нас — практически чистый Agile, и всё идёт, как надо.
Вывод: Для каждой работы — свой инструмент.
4 марта 2017 в 08:51
0↑
↓
ВОДОПАД! 20% процентов в бюджете, сроке и качестве. В остальных хотя бы что-то одно шло не так.Я как-то на Хабре писал уже в чем разница между проектом, продуктом и услугой. Собственно от непонимания различий идут и холиворы, и проблемы в реальных проектах.
Клиенту начихать, Agile у вас, PMI PMBoK, PERT или FuckDownDrivenDevelopment. Ему нужен продукт, которым он решит свои задачи, пусть даже он купил outstaff.
Проблема номер один: у клиента что-то меняется → должен поменяться продукт, но из этого автоматически не следует что должен поменяться проект. Решение юридическое, но из него вытекает…
Проблема номер два: проект оценивают как услугу (выполнение заказанных действий) → значит если за уплаченный бюджет результат не достигнут, то это проблема клиента.
Разрешение этой курояичности не в балансе между Time/Material или Agile/Waterfall, это всё поиск ВНУТРИ проектов, ёшкина кошка. Ответ лежит в портфельном управлении (не в том как правильно делать проект, а в том чтобы делать правильный проект). Лучше клиенту потратить пусть чуть больше, но заработает намного-намного больше, и тогда вот эти все процессные штучки — развлекухи для праздных умов.
lencom
4 марта 2017 в 09:01
0↑
↓
Смешиваем, поступая интуитивно, ситуативно, с перевесом в ту или другую методологию, клиенты и проекты разные.В чистом виде SCRUM не получается делать, т.к. приходится переключаться между проектами в середине спринта по разным причинам: то согласование дизайна страницы задержали, потому что клиент уехал в Китай по делам, то предоплату по спринту, то проектов несколько параллельно, приходится перебрасывать ресурсы. Поэтому, если это SCRUM, то SCRUM через Ж. Это всё не от хорошего управления, конечно.
Ещё практикуем, как мы называем, «Сайт за 3 встречи» — это водопад с минимальным задействованием клиента и максимальной самостоятельностью команды. 3 встречи — 1. интервью, чтобы узнать бизнес, задачу, видение клиента, задача максимально разговорить, 2. презентация и защита решения, 3. презентация и защита готового результата. Между 1 и 2 команда придумывает и проектирует решение. Между 2 и 3 реализует решение. Это рискованный формат, делаем только с некоторыми клиентами, в основном не с новыми, для некрупных проектов.
Подходит для клиентов, которым нужен результат, а не то, как мы его будем достигать. Плюс для клиента — он экономит время, ответственность на подрядчике. Плюс для нас — свобода выбора инструментов, нет череды длительных согласований (сначала ТЗ, потом контент-план, потом прототипы, потом дизайн).
