Ничего не раздражает заказчика больше, чем неверная оценка сроков. Ничего не делает давление на разработчика сильнее, чем неправильно оценненная задача. Причем со временем развития IT-отрасли мало что меняется. Вот цитата из классической книжки Мифический человеко-месяц, которая была выпущена около 40 лет назад:
Возможно, эта современная разновидность колдовства особенно привлекательна для тех, кто верит в хэппи-энды и добрых фей. Возможно, сотни неудач отталкивают всех, кроме тех, кто привык сосредоточиваться на конечной цели. А может быть, дело всего лишь в том, что компьютеры и программисты молоды, а молодости свойствен оптимизм. Как бы то ни было, в результате одно: «На этот раз она точно пойдет!» Или : «Я только что выявил последнюю ошибку!»
Итак, в основе планирования разработки программ лежит ложное допущение, что все будет хорошо, т.е. каждая задача займет столько времени, сколько «должна» занять. (с) Брукс
С тех пор, как мы видим, ситуация не изменилась. Программистам хочется выглядеть перед заказчиком профессионалами высшей категории, из-за этого оценки даются оптимистичные. Бывает, что заказчики играют на этой черте программистов и прибегают к разным уловкам. Например, заказчик начинает спрашивать у разработчиков:
— За сколько мы успеем сделать Х?
— За месяц успеем точно
— А что надо сделать, чтобы в неделю уложиться?
— В неделю почти нереально. Можно вот эту часть проще сделать, вот это убрать, тогда и за неделю уложимся
— А за 3 дня справитесь?
— За 3 дня вообще никак, самый предел это 4 дня и ни днем меньше!
— Ну вы, парни, прямо удивили меня! Договорились, 4 дня, начинаем
Закачики поиграли с нами в снижение сроков, при этом давление на нас повысилось. Как результат заказчики скорее всего будут разочарованы, а мы вымотаны. Уж лучше дать оценку больше, а потом обрадовать заказчика более ранней поставкой.
Как же всё-таки оценивать задачи, чтобы всем было хорошо? В прекрасном докладе 36 от Вадима Макишвили есть интересное объяснение, почему и как надо давать оценку:
Представьте себе точку начала проекта и точку окончания. Программист проводит между ними прямую линию, длина линии будет самой оптимистичной оценкой. Проекты практически никогда по прямой линии не идут, а идут хотя бы по окружности. Получается, что нашу оценку надо умножить на π и к результату прибавить 2 недели. Почему плюс 2 недели? Потому что, если за время, отведенное на проект, вы вообще ничего не делали, то за 2 недели можно накидать почти любую систему.
Это, конечно, полу-шуточное объяснение принципа оценки проекта, но оно отлично показывает, что проекты никогда не идут по оптимистичному пути, всегда возникают проблемы и этот факт надо учитывать.
Запомните главное: Не надо рвать на себе рубашку и выглядеть лучше, чем вы есть. Нужно быть профессионалом. Профессионал от непрофессионала прежде всего отличается тем, что он может предсказывать будущее.
Серия статей «Customer satisfaction для программистов»:
Комментариев нет:
Отправить комментарий