Customer satisfaction для программистов: Все программисты — оптимисты

24 февраля 2015 г.

Ничего не раздражает заказчика больше, чем неверная оценка сроков. Ничего не делает давление на разработчика сильнее, чем неправильно оценненная задача. Причем со временем развития IT-отрасли мало что меняется. Вот цитата из классической книжки Мифический человеко-месяц, которая была выпущена около 40 лет назад:

Возможно, эта современная разновидность колдовства особенно привлекательна для тех, кто верит в хэппи-энды и добрых фей. Возможно, сотни неудач отталкивают всех, кроме тех, кто привык сосредоточиваться на конечной цели. А может быть, дело всего лишь в том, что компьютеры и программисты молоды, а молодости свойствен оптимизм. Как бы то ни было, в результате одно: «На этот раз она точно пойдет!» Или : «Я только что выявил последнюю ошибку!»

Итак, в основе планирования разработки программ лежит ложное допущение, что все будет хорошо, т.е. каждая задача займет столько времени, сколько «должна» занять. (с) Брукс

С тех пор, как мы видим, ситуация не изменилась. Программистам хочется выглядеть перед заказчиком профессионалами высшей категории, из-за этого оценки даются оптимистичные. Бывает, что заказчики играют на этой черте программистов и прибегают к разным уловкам. Например, заказчик начинает спрашивать у разработчиков:

— За сколько мы успеем сделать Х?
— За месяц успеем точно
— А что надо сделать, чтобы в неделю уложиться?
— В неделю почти нереально. Можно вот эту часть проще сделать, вот это убрать, тогда и за неделю уложимся
— А за 3 дня справитесь?
— За 3 дня вообще никак, самый предел это 4 дня и ни днем меньше!
— Ну вы, парни, прямо удивили меня! Договорились, 4 дня, начинаем

Закачики поиграли с нами в снижение сроков, при этом давление на нас повысилось. Как результат заказчики скорее всего будут разочарованы, а мы вымотаны. Уж лучше дать оценку больше, а потом обрадовать заказчика более ранней поставкой.

Как же всё-таки оценивать задачи, чтобы всем было хорошо? В прекрасном докладе 36 от Вадима Макишвили есть интересное объяснение, почему и как надо давать оценку:

Представьте себе точку начала проекта и точку окончания. Программист проводит между ними прямую линию, длина линии будет самой оптимистичной оценкой. Проекты практически никогда по прямой линии не идут, а идут хотя бы по окружности. Получается, что нашу оценку надо умножить на π и к результату прибавить 2 недели. Почему плюс 2 недели? Потому что, если за время, отведенное на проект, вы вообще ничего не делали, то за 2 недели можно накидать почти любую систему.

Это, конечно, полу-шуточное объяснение принципа оценки проекта, но оно отлично показывает, что проекты никогда не идут по оптимистичному пути, всегда возникают проблемы и этот факт надо учитывать.

Запомните главное: Не надо рвать на себе рубашку и выглядеть лучше, чем вы есть. Нужно быть профессионалом. Профессионал от непрофессионала прежде всего отличается тем, что он может предсказывать будущее.


Серия статей «Customer satisfaction для программистов»:

Комментариев нет:

Отправить комментарий

Моя книга «Антихрупкость в IT»

Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...