Форма договора обычно отражает ожидания.

До тех пор пока заказчики не поймут, что разработчики это всего лишь "руки" для решения их проблем, а "голова" и ответственность за решения должна быть на заказчике бесполезно обсуждать формат договора.

Мой опыт — крупный энтерпрайз. Заказчики там в основном такие.

Все так, однако, бизнес-риски заставляют заказчика менять требования (с пониманием здесь все ОК, просто за некое время требования эволюционировали), а это начинает влиять на разработчиков. Не всегда хорошо...

Если с пониманием все ОК (у бизнеса с пониманием эволюционности требований действительно все ОК, да??? ?), то не вижу проблем с объяснением преимуществ Agile. Реально вагон аргументов ЗА. Включая контракты с полуоткрытым скопупом. По опыту "все ОК с пониманием" только на словах но не на уровне финансовых обязательств.

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

Бизнес видит в маркетинговых слоганах agile "серебряную пулю", зачастую слишком полагаясь на магию со стороны подрядчика

Ага

Карго-культ :)

Это какая-то общая беда

Типа мы будем делать ритуалы по agile, пинать разработчиков (как обычно), а они за это мобилизуются и все быстро сделат.

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

Такое тоже видел :)

Даже при смене работы ловил себя на том, что говорю те же самые слова, но уже другим людям и в других компаниях

Потому что "маркетинг" продан и сверху людей убедили

Если сводить все к просым идеям, то "простое" решение этой проблемы — просто всего лишь внедрить agile в управление бизнесом. ХЗ как это сделать :) МБ Герману Оскаровичу с его евангелистами удастся это в Сбере, а мы посмотрим :)

Мастерклассы пусть потом запустят

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

Но так же могу сказать, что в такой ситуации работает либой гибкий подход, даже без задумывания о том что это Agile/SCRUM/Kanban и тп — если разработчикам поставить интересную задачу (хотя бы очевидно полезную для бизнеса) и дать свободу, то они свернут горы. Технари они такие :)

Если мотивация конкретных людей (не путать со спонсором проекта) не завязана на результат, то бесполезно что-то оптимизировать.

Ага, бонус топам в качестве мотивировки хорошо работает, проверяли

Или так :) Бонус топам, стимул (палка с заостренным концом) миддл-уровню.

Но лучше конечно бонусы всем :)

Наш кейс был как раз про острые палки

Зато решения не затягивались, что приятно

К сожалению острые палки работают только для относительно простой работы. Например, для внедрения крупной ERP-системы, когда пордячиквнедряет ее уже 10-й раз, а от заказчика требуется лишь изложить требования в нужном формате и не сильно настаивать на кастомизации.

В общем так и не услышал я ответа, как заключать контракты без предварительой работы аналитиков и ТЗ долгого. В заказной разработке есть вид сделки time and material , работашь на почасовке и все. Но даже там оказываются кейсы, когда заказчик говорит «да это же на 40 часов работы было, а вы все 120 возились, я отказываюсь платить» Хотя на старте все проговорено было, что мы не платим за аналитику и прочее, экономим тут и начинаем работать

В остальном острые палки мешают.

Андрей, а что вы хотите услышать?

Как убедить заказчика взять на себя ответственность за бизнес-результат?

По мне (см мой монолог выше) дело не в формате договора, а в ответственности. Если заказчик готов взять ответственность на себя за бизнес, то формат договора приложится.

Предварительную аналитику тяжело зачарджить заказчику

Да вот заказчик говорит «да, идет, ответственность на мне» но как вы и заметили, как только денег начинает касаться , сразу гм :)

Значит, он лукавит :)

Возможно, он лукавит вынужденно — у него есть фиксированный бюджет и таймер отрубания головы (собственной головы конкретного представителя заказчика) если задача не будет решена к такому-то сроку. Обычно в сроке делается запас, но все равно страшно. Да? :)

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

Может есть где-то математическая модель, которая показывает , например 2 кривых - стоимость проекта во времени, одна для водопада, другая аджайл. Где можно двигать ползунок (число неожиданных изменений требований) и кривые меняются

Алексей, тут как раз вам поможет Agile :) SCRUM вообще рулит — много некрупных интераций, в ходе которых растет оыт и естественно повышается точность оценки.

для time and material оценок нет, поэтому аппеляция про 40 часов это лишь внутреннее ожидание заказчика ничем не подтвердженное

Нельзя без оценок, это хаос.

Но оценки нужно уточнять.

Есть такая штука у Макконнелла в Construx

Может есть где-то математическая модель, которая показывает , например 2 кривых - стоимость проекта во времени, одна для водопада, другая аджайл. Где можно двигать ползунок (число неожиданных изменений требований) и кривые меняются

Если взять один и тот же объем фнкциональных требований — грубо говоря утвержденное ТЗ, то цена разработки Водопадом будет ниже чем Agile :)

Бог с ним, пример не самый подходящий скорее. Про мат модель интересно. Задал на входе количество людей в проекте, их ставки. Построил идеальную модель по водопаду и по скраму. Потом начал увеличивать количество изменений в проекте. Цель наглядно показать усредненную выгоду от процесса по аджайл

Software Development's Defect Cost Increase

Software Development's Defect Cost Increase

+1

Про "скоуп и очкование" - тут либо заказчик бизнес-риски берет на себя или хочет переложить их на подрядчика. Если бизнес-риски на заказчике (продукт не выстрелит, не закроет проблему), то от подрядчика нужно как можно лучше понять функциональные требования и как можно качественнее реализовать продукт. Agile в разработке помогает лучше понять и качественее делать продукт. Но ничего не делает с бизнес-рисками.

а вот и не все так однозначно. контрактование не заключается в двух вариантах: фикс прайс и TnM.

У него ещё своя патентованная прога есть, только с ней повозитесь

Иван, я специально не указывал формат договора :) Я чисто про ответственность писал.

Ответственность и мотивация — главное.

А чтобы эффективно риски поделить для начала нужно этим делением заняться :)

рискшаринг модели тоже есть

К примеру?

Если нет ответственности и мотивации, но есть желание спихнуть риски на другую сторону, то это проблема.

Нельзя без оценок, это хаос.

Некоторые с вами поспорят) http://www.slideshare.net/Askhat/no-estimate

рискшаринг модели тоже есть

Есть что-то системное по этой теме?

говорят скоро СкрамТрек запустит тренинг по agile-контрактам и вообще отношениям, когда есть заказчик и подрядчик. там будут и примеры и системно все ;)

Некоторые с вами поспорят) http://www.slideshare.net/Askhat/no-estimate

Завидую им :)

Но какие-то оценки есть всегда — оценка это цена ресурсам которую планируется заплатить за фичу — это обратная связь от разработчика заказчику.

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

Я не спорю Я не из заказной разработки, у нас с этим проще)

Глянул презентацию — работа "без оценок" как цель, идеал — супер.

Но не как карго-культ :)

Чтобы "без оценок" заработало разработчики должны быть в теме бизнеса, иметь адекватный опыт (хз какой конкретно, но адекватный ?) и разработка с тестированием и деплоем на прод должна быть максимально автоматизирована.

Если сводить все к просым идеям, то "простое" решение этой проблемы — просто всего лишь внедрить agile в управление бизнесом. ХЗ как это сделать :) МБ Герману Оскаровичу с его евангелистами удастся это в Сбере, а мы посмотрим :)

не так уж и сложно, мы этому учим - Agile Product Management + Agile Marketing и владелец бизнеса может спокойно заниматься стратегией :)

Чтобы "без оценок" заработало разработчики должны быть в теме бизнеса, иметь адекватный опыт (хз какой конкретно, но адекватный ?) и разработка с тестированием и деплоем на прод должна быть максимально автоматизирована.

Все так, к этому и стремимся)

не так уж и сложно, мы этому учим - Agile Product Management + Agile Marketing и владелец бизнеса может спокойно заниматься стратегией :)

Это очень круто. А планировать бюджет по Agile учите? Без отрубания голов в случае неудач :)

@RuslanKuzminov юнит-экономика считается планированием бюджета? :)

Научим! =)

@RuslanKuzminov юнит-экономика считается планированием бюджета? :)

А что это такое? Название слышал, но знаю сути.

@roman_kolchin если очень абстрактно - расчет бюджета исходя из издержек на единицу продукции, чтобы не уйти в убыток

говорят скоро СкрамТрек запустит тренинг по agile-контрактам и вообще отношениям, когда есть заказчик и подрядчик. там будут и примеры и системно все ;)

Очень интересно. А но основании чьего реального опыта? Российского? Просто я когда-то был на тренинге по agile и изложил там свои проблемные кейсы, то мне после серии предложений и моих -контр-аргументов предложили не работать с такими заказчиками :)

Unit-экономика это расчет доходов и расходов на одного клиента

@roman_kolchin у меня куча аджайл-проектов в заказной разработке, я просто все проекты делаю в аджайл парадигме :)))

и в общем-то заказчика никто не спрашивал, все равно отчитываться раз в неделю

Если простыми словами то инструмент оперативной оценки доходности бизнеса =)

и в общем-то заказчика никто не спрашивал, все равно отчитываться раз в неделю

У Вас аджайл — это итерационная разаботка? Или контракты с открытым скоупом?

Если простыми словами то инструмент оперативной оценки доходности бизнеса =)

Спасибо. А как быть с кучей инфраструктурных и бэкофисных инвест-проектов, которые напрямую не аллоцируются на конкретных клиентов. Особенно если проекты с долгосрочной окупаемостью.

Или вся соль в том, чтобы не пропускать проекты без по-клиентного обоснования?

@roman_kolchin второй вариант, вот сейчас французский стартап с нуля делаем

@roman_kolchin второй вариант, вот сейчас французский стартап с нуля делаем

Стартап с нуля.... ?

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

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

Весь вопрос - КАК мотивировать и поделить ответственность.

UNIT-экономика - это инструмент для работы на открытом рынке. Тут вся соль в том, что на одном листе вы видите все ключевые метрики бизнеса + можете моделировать влияние метрик на результат (например, стоит задача кратно поднять прибыль => через unit-экономику ищем точки для роста => принимаем решение на что влиять в первую, вторую, итд очередь). Кучу инфраструктурных и бэкофисных инвест-проектов (если требуется) можно засунуть в фиксированные расходы (капексы показать через амортизацию)

@roman_kolchin нужно быть избирательным и брать только нормальных клиентов :)

"Кучу инфраструктурных и бэкофисных инвест-проектов (если требуется) можно засунуть в фиксированные расходы (капексы показать через амортизацию)"

Не совсем понял что вы имеете в виду?

Инвест проект генерит два потока — расходы и доходы, обычно с лагом.

Для клиенто-ориентированных проектов доходы более мнее понятны.

Для инфраструктурных и бэкофисных — нет.

Амортизация влияет лишь на налогооблагаемую базу.

прямой доход? или улучшение работы компании?

А как оценить полезность бэкофисного проекта с точки зреня unit-экономики?

можем уйти в отдельный чат если интересно :)

Интересно, но пока это чисто любопытство :) Сам я не на стороне клиента работаю и буду работать, в бюджетный процесс не вовлечен поэтому.

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