Женя, спасибо за интересное интервью. А так же за лестный отзыв ux-специалистов. Приятно такое слышать от технолога.

Присоединяюсь к поздравлению. С юбилеем!

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

Полагаю, что если Заказчик не понимает особенности разработки, то подбирая подрядчика он скорей всего выберет более дешёвое предложение с коротким сроком исполнения.

То есть выберет того подрядчика, который не сдерживает риски. Что скорей всего обречёт проект на фиаско.

>Б.Аннаков: Очень часто, когда мы получаем оценки от разработчиков, на всякий пожарный мы добавляем рисковый буфер: он сказал 3 дня, а я заложу 5. Мы делаем буфер на риск и непредвиденные обстоятельства. Это правильное управленческое решение. Кто сможет лучше всего дискредитировать этот подход? Кто назовет основные минусы такого подхода? К чему в итоге это может приводить? Кто рассмотрит ситуацию нестатично, а динамично и учтет взгляды всех других людей, то есть разработчика, клиента, управленца, спонсора, тестировщика и так далее. Кто сможет дискредитировать этот подход? Это было бы очень интересно.

Отвечаю на вопрос:
— Такой буфер делает проект дороже в стоимости.
— Не все работы требуют такого буфера.
— Бездумное прибавление некого процента дополнительного времени не гарантирует сдерживание рисков.
— Нужно отдавать отчёт в том, что разработчик не сделал работу за риск-менеджера, и не назвал сроки с буфером.
— В плане для производства нужно устанавливать тот срок сдачи о котором договорились с разработчиком. При этом не называть ему истинной даты истинного дедлайна.

Прошу прощения за сбивчивый ответ.