Cum tempore
Во многих небольших айти-компаниях есть такая практика. Сейл поговорил с заказчиком, договорился об определённом сроке разработки продукта и этот срок спускается разработчикам. Я ранее писал об этом в статье о пяти признаках проекта, который провалится.
В зрелых компаниях существует принцип неприкосновенности оценки. Срок разработки оценивают только разработчики и если они сказали, что нужно два месяца, никакой начальник не может сказать: «а надо сделать за месяц», потому что это бессмысленно — не успеют.
Однако есть ещё одна проблема. Команда просит два месяца и через два месяца выясняется, что не успели. Вылезли непредвиденные технические сложности, заказчик накидал забытых требований, возникли проблемы с интеграцией с внешними апихами, много всего. И начинаются «вторые 80 %» проекта.
Лучше всего это лечится грамотным сбором требований. Никакие сроки не называются до тех пор, пока продукт (или первая итерация продукта, если он большой) не будет детально спроектирован. Лучше, если проектировать будет не пиэм, а специализированный аналитик, тесно сотрудничающий с разработчиками. Тогда шансы уложиться сильно возрастают. Ещё нужен промежуточный контроль. Об этом можно прочитать в моей заметке о контроле по трём точкам.
