День 2089. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 28. Не меняйте оценку в зависимости от того, что хочет услышать получатель
Предположим, клиент спрашивает, сколько времени вам потребуется, чтобы завершить следующую часть вашего проекта. Основываясь на анализе прошлого опыта, вы отвечаете: «Около двух месяцев».
«Два месяца? — усмехается клиент. — Моя 12-летняя дочь сделает это за три недели!»
В ответ вы, сопротивляясь искушению предложить ему нанять свою дочь, делаете вторую попытку: «Хорошо, как насчет одного месяца?»
Что изменилось за эти несколько секунд? Задача не уменьшилась. Вы не стали более продуктивным. У вас не появился вдруг добровольный помощник, готовый помочь выполнить работу. Просто клиенту не понравился ваш первый ответ, и вы предложили альтернативу, кажущуюся более привлекательной. Если ваша оценка и ожидания заказчика слишком расходятся, то вам придётся провести переговоры, чтобы прийти к какому-либо соглашению. Однако нет никаких оснований изменять продуманную оценку только потому, что она кому-то не понравилась.
Оценка — это предсказание будущего. Мы основываем оценки на том, что известно о текущей задаче, на предыдущем опыте решения аналогичных задач и некоторых предположениях. Особо дотошные могут также принять во внимание любые неподконтрольные им факторы, возможные риски, потенциальные изменения в постановке задачи и неопределённость, которая может повлиять на планы. Чем меньше мы знаем обо всех этих факторах, тем ниже вероятность, что оценка будет соответствовать реальному положению дел. Кто-то другой, учитывающий иной набор параметров, может получить совсем иную оценку времени выполнения той же работы.
Цели и оценки
Важно отличать оценки от целей. Допустим, разработчик обсуждает новый проект со старшим менеджером. Продолжительность проекта, по оценке разработчика, в 4 раза превышает ожидания менеджера. Но, уступив давлению менеджера, разработчик соглашается на гораздо более короткий срок, даже при том, что уложиться в него нет никакой возможности.
Более рациональным подходом для разработчика было бы сказать: «Я пришёл к своей оценке согласно таким-то и таким-то расчётам. А как вы получили свою?» Скорей всего, у менеджера не было никакой оценки — у него была цель. У разработчика тоже не было оценки — у было предположение. Цель и предположение оказались далеки друг от друга. Если бы одна из двух сторон разработала верную оценку, то они могли бы быть ближе друг к другу. Вместо этого обсуждение превратилось в напряжённый спор, и человек, обладавший большей властью, выиграл его, получив обещание от другого.
Когда корректировать оценку
Ваша оценка не должна зависеть от того, что хочет услышать заказчик. Тем не менее иногда имеет смысл изменить оценку или, говоря точнее, выполнить переоценку:
- если обнаружится, что предположение или часть информации были неверными;
- после начала работы, когда вы лучше поймёте задачу;
- когда объём работы изменится;
- если обнаружится, что вы продвигаетесь быстрее, чем ожидали (такое случается);
- когда меняются условия, например люди, работающие над проектом;
- когда исчезнут риски или пропадёт зависимость.
Если не произойдёт каких-либо изменений, подобных этим, то не следует изменять прогноз. Если ваша оценка не совпадает с чьими-то целями, ожиданиями или ограничениями, то вы должны совместно исследовать это расхождение. Не следует оставлять конфликт неразрешённым. Вы можете подвергнуть сомнению свои предположения, обсудить риски и попробовать альтернативные методы расчётов, чтобы подтвердить или опровергнуть оценку. Возможно, исходные данные, на которые вы опирались, плохо подходят для оценки рассматриваемой работы. Вы можете договориться об объёме, ресурсах или качестве, чтобы увидеть, получится ли более приемлемая оценка. Но если ваша оценка получена в результате тщательного анализа, то не уступайте просто ради того, чтобы кому-то угодить. Люди перестанут доверять вашим прогнозам, зная, что могут изменить их, оказав достаточное давление.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 4.
>>Click here to continue<<