
Комментарии 9
Ну блин это жизнь такая. Если нет возможности с заказчиком рассчитывать оплату по факту выполненных работ(он не хочет), то остаётся лишь многократно завышать предварительную оценку и брать типовые стандартные хорошо прогнозируемые работы(и то всегда есть риск что текущее состояния продукта настолько плохое что даже на обычной задаче вляпаться можно) а с чем то хитрым особенном пусть заказчик ищет бедолагу в другом месте.
В этом и проблема была, да. Многие заказчики, в том числе и наш, боялся что работа по факту может быть искусственно завышена нами, и был бы в этом какой то степени прав. Никто бы не работал в обыток.
Но как решили проблему мы? Когда перешли на scrum, сама его суть говорит о том, что не может одна задача занимать больше 8 поинтов (условно). То есть мы начинали ее декомпозировать на более мелкие, что в итоге и дает "реальный" объем работ. И когда заказчик спросит "почему так дорого" - то у нас уже есть четко декомпозированная его задача, и если заказчик адекватные, то он примет это. А если заказчик настаивает на своем, то просто лучше от такого отказываться
Задачу на 80 поинтов ранее оценивали в 30 поинтов и клиент платил за 30 поинтов. Теперь такая задача оценивается в 80 поинтов и клиенту нужно оплачивать 80 поинтов, т.е. стоимость выросла, как и сроки. Клиенты готовы к такому?
Уже давно известно, что первоначальную смету нужно умножать как минимум на 3. :-)
Огромное спасибо за информацию! Возможно вы только что спасли стартап
Сложилось впечатление, что ваша проблема была не в отсутствии Scrum, а отстутствии декомпозиции задач. Почему с часами вы гадали: 'что-то вроде 40', а с storypoint стали дробить сложность? Почему нельзя было начать декомпозировать задачи пользуясь часами, а не storypoint?
Как мы перестали тонуть в сроках и выгорании за один переход: опыт студии из 8 человек