06 октября 2010 23:12
Подход плох тем, что в связи с его использованием возрастает цена и сроки реализации.
Полагаю, что если Заказчик не понимает особенности разработки, то подбирая подрядчика он скорей всего выберет более дешёвое предложение с коротким сроком исполнения.
То есть выберет того подрядчика, который не сдерживает риски. Что скорей всего обречёт проект на фиаско.
в Теория и практика управления интернет-проектами
06 октября 2010 15:32
>Б.Аннаков: Очень часто, когда мы получаем оценки от разработчиков, на всякий пожарный мы добавляем рисковый буфер: он сказал 3 дня, а я заложу 5. Мы делаем буфер на риск и непредвиденные обстоятельства. Это правильное управленческое решение. Кто сможет лучше всего дискредитировать этот подход? Кто назовет основные минусы такого подхода? К чему в итоге это может приводить? Кто рассмотрит ситуацию нестатично, а динамично и учтет взгляды всех других людей, то есть разработчика, клиента, управленца, спонсора, тестировщика и так далее. Кто сможет дискредитировать этот подход? Это было бы очень интересно.
Отвечаю на вопрос:
— Такой буфер делает проект дороже в стоимости.
— Не все работы требуют такого буфера.
— Бездумное прибавление некого процента дополнительного времени не гарантирует сдерживание рисков.
— Нужно отдавать отчёт в том, что разработчик не сделал работу за риск-менеджера, и не назвал сроки с буфером.
— В плане для производства нужно устанавливать тот срок сдачи о котором договорились с разработчиком. При этом не называть ему истинной даты истинного дедлайна.
Прошу прощения за сбивчивый ответ.
в Теория и практика управления интернет-проектами
