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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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