Аннотация
- Докладчик
- Дмитрий Лобасев
Берем заказчика, который за свой определенный бюджет хочет разработать некий программный продукт. Требования, как водится, самые высокоуровневые, про Agile заказчик не слышал никогда и его это слово интересует мало - он оперирует классическим треугольником: бюджет, сроки и нужная бизнесу функциональность (которая, конечно, по ходу проекта будет меняться).
Понятно, что для нас, как разработчиков, риски в таком проекте крайне высоки: как дать правильные оценки, как построить открытые отношения с заказчиком, как бороться с изменениями в скоупе.. как, наконец, выстроить эффективный процесс на основе Scrum и не облажаться?
Я расскажу об опыте нашей команды, который мы получили на недавно завершившемся (успешно!) fixed price Agile проекте для одного крупного заказчика, который теперь использует наш продукт на тысячах торговых точек по всей России. Посмотрим на ключевые практики, которые мы для себя определили и успешно применяли, и которые могут быть полезны в ваших проектах.
Видео
Для этого доклада нужен подкаст (аудиозапись)?
Презентация
Примечания и отзывы
До нас выступали Дмитрий Лобасев с докладом про применение Agile для проектов с фиксированной стоимостью и Константин Гурнов с докладом про построение Enterprise Scale Agile в компании Luxoft. Первый доклад немного разочаровал меня своим содержанием и преподносимыми подходами. Больше все это походило на отчаянные попытки выбраться за рамки подписанного контракта с прикрытием тылов на случай юридических разборок. По итогу остались недовольны и команда и заказчик. Непонятно чем в таком случае должен помочь такой опыт слушателям. На следующий день мы обсуждали доклад с Димой. Возможно просто не вся информация была донесена и воспринята правильно, но я не увидел особой пользы в этом выступлении.
©
Дмитрия Лобасева я видел у нас на собраниях сообщества AgileRussia, он рассказывал про DevProm — систему управления проектами, которая «лучше всех». На этот раз доклад был про другое.
Судя по реакции зала, действительно многих волнует вопрос, как совместить разработку по agile с договорами по fix price, и, думается, это очень непросто сделать — заказчики привыкли мыслить в терминах «деньги-товар».
Дмитрий рассказывал не слишком зажигательно (про DevProm у него получается заметно лучше) о том, как участвовал в проекте, который оформлялся по всем канонам fix price, но при этом делался по agile. По масштабу и характеру этот проект, как я понял, был похож на наши типичные проекты с Спортмастером.
Никакой особой магии там не было — в договорах фиксировали только высокоуровневые требования, и регулярно передоговаривались, писали корректировки к договорам. Суть доклада можно было свести к мысли «апеллируйте к разуму заказчика, объясняйте ему, договаривайтесь, ну и иногда можно схитрить».
Интересная тема, неплохой докладчик.
Вызвал ооочень много вопросов аудитории. Суть примерно такая. Находим заказчика, фиксируем требования начинаем работать по Fixed price, делаем продукт, проводим демо, собираем обратную связь (важно: все изменения в требованиях фиксируем), все переделки/новые хотелки стоят денег. Тут заказчик радоваться начинает и может быть даже продукт уже вовсю использует/продает, но мы то помним что баблосы ограничены были в начале проекта и мы их выработали ;) Приходим к клиенту и говорим, что дальше надо еще денег. Дальше варианты:
- Хороший. Клиент поверил в нас, понял схему работы и вот он T&M.
- Не очень хороший. Клиент в шоке, ведь первоначальные требования не все реализованы, а деньги закончились (в порыве радости заказик забыл, что новые хотелки денег стоят). Но деваться клиенту некуда, т.к. продукт надо дописать и мы получаем T&M. Правда потом клиент может не захотеть с нами делать новый продукт.
- Плохой. Клиент не просто в шоке, но и начинает откровенно придираться ко всему и вся. Но мы юридически прикрыты и в худшем случае просто потратим время на разборки, ну и продукт не доделаем.
После доклада осталось чувство, что в истории Дмитрия все-таки кто-то кого-то обманул :)
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.
