Пессимизм при оценке проектов
Проблема
Менеджер приносит новый проект или задачу и просит оценить.
Программист думает: «Ага, ну если ТЗ уже готово, я сяду работать, ничто меня не будет отвлекать, интеграция пройдет нормально, то я сдам задачу через неделю». И озвучивает срок в неделю.
В итоге проходит месяц, менеджер на нервах, программист 3 недели извиняется, что продолбался и овертаймит во искупление, а заказчик рвет и мечет.
Почему так?
Причин может быть много, но я хочу подсветить те, где помог бы пессимизм:
- Программист либо не видал еще «всякого говна», либо просто сам по себе наивный, и предполагает, что ТЗ идеально написано сразу, сторонние команды сработают без накладок, менеджер и заказчик всегда на связи, никто не заболеет и не уйдет в отпуск, кошка ни у кого не начнет рожать перед дедлайном.
Что в этом случае делать?
Вспомнить закон Мерфи «Всё, что может пойти не так, пойдёт не так». Ну и хорошенечко думать обо всех этапах, где что-то может пойти не так, закладываться на эти риски и планировать, что делать.
- Менеджер тоже надеется, что всё пойдет идеально.
Что в этом случае делать?
Подумать о профпригодности менеджера. Уж его-то работа – точно подумать обо всех рисках и резервных планах.
- Менеджер не принимает пессимистичных вариантов от программиста. Говоря «да ладно тебе, да всё нормально будет, да не очкуй».
Что в этом случае делать?
Подумать, что менеджер либо профнепригодный, либо манипулятор, который специально давит на разработчика, выжимая позитивные оценки, чтобы потом спихнуть всю вину с себя под лозунгами «ну ты же сам пообещал, ты и виноват, успевай как хочешь теперь».
А после того, как вы обо всём этом подумали, решите, как вы видите свое дальнейшее будущее с этим менеджером. В этом вам тоже поможет пессимизм, который позволит разглядеть варианты, где всё может пойти не так.
Что делаю я?
Я стараюсь подумать о том, какие аспекты задачи/проекта могут пойти не так. Рассматриваю всё от технических деталей, до человеческого фактора. Расписываю эти риски, закладываю их в оценку, планирую что делать, если каждый из них стрельнет. Оценку могу давать в двух или трех вариантах. Оптимистичную, пессимистичную, и может быть усредненно-реалистичную.
Если требование – получить строго одну оценку, то лучше дам ближе к пессимистичной, потому что, как показывает практика, зачастую так оно и случается.
Ну ты и негативщик!
Да, у окружающих может сложиться мнение, что вы слишком негативно настроены. Однако в реальности как раз окружающие настроены излишне позитивно, ну или просто не думают дальше чем 7.5 секунд и 0.001 шага вперед. Поэтому, когда риски начнут (а они начнут) стрелять, а у вас уже и план готов, как их отработать, и сроками вы заложились, все обвинения в излишнем пессимизме отпадут сами собой.
Итог
Не будьте наивными, думайте о рисках, предполагайте плохие варианты, готовьтесь к ним, закладывайте в оценку.
Проблема
Менеджер приносит новый проект или задачу и просит оценить.
Программист думает: «Ага, ну если ТЗ уже готово, я сяду работать, ничто меня не будет отвлекать, интеграция пройдет нормально, то я сдам задачу через неделю». И озвучивает срок в неделю.
В итоге проходит месяц, менеджер на нервах, программист 3 недели извиняется, что продолбался и овертаймит во искупление, а заказчик рвет и мечет.
Почему так?
Причин может быть много, но я хочу подсветить те, где помог бы пессимизм:
- Программист либо не видал еще «всякого говна», либо просто сам по себе наивный, и предполагает, что ТЗ идеально написано сразу, сторонние команды сработают без накладок, менеджер и заказчик всегда на связи, никто не заболеет и не уйдет в отпуск, кошка ни у кого не начнет рожать перед дедлайном.
Что в этом случае делать?
Вспомнить закон Мерфи «Всё, что может пойти не так, пойдёт не так». Ну и хорошенечко думать обо всех этапах, где что-то может пойти не так, закладываться на эти риски и планировать, что делать.
- Менеджер тоже надеется, что всё пойдет идеально.
Что в этом случае делать?
Подумать о профпригодности менеджера. Уж его-то работа – точно подумать обо всех рисках и резервных планах.
- Менеджер не принимает пессимистичных вариантов от программиста. Говоря «да ладно тебе, да всё нормально будет, да не очкуй».
Что в этом случае делать?
Подумать, что менеджер либо профнепригодный, либо манипулятор, который специально давит на разработчика, выжимая позитивные оценки, чтобы потом спихнуть всю вину с себя под лозунгами «ну ты же сам пообещал, ты и виноват, успевай как хочешь теперь».
А после того, как вы обо всём этом подумали, решите, как вы видите свое дальнейшее будущее с этим менеджером. В этом вам тоже поможет пессимизм, который позволит разглядеть варианты, где всё может пойти не так.
Что делаю я?
Я стараюсь подумать о том, какие аспекты задачи/проекта могут пойти не так. Рассматриваю всё от технических деталей, до человеческого фактора. Расписываю эти риски, закладываю их в оценку, планирую что делать, если каждый из них стрельнет. Оценку могу давать в двух или трех вариантах. Оптимистичную, пессимистичную, и может быть усредненно-реалистичную.
Если требование – получить строго одну оценку, то лучше дам ближе к пессимистичной, потому что, как показывает практика, зачастую так оно и случается.
Ну ты и негативщик!
Да, у окружающих может сложиться мнение, что вы слишком негативно настроены. Однако в реальности как раз окружающие настроены излишне позитивно, ну или просто не думают дальше чем 7.5 секунд и 0.001 шага вперед. Поэтому, когда риски начнут (а они начнут) стрелять, а у вас уже и план готов, как их отработать, и сроками вы заложились, все обвинения в излишнем пессимизме отпадут сами собой.
Итог
Не будьте наивными, думайте о рисках, предполагайте плохие варианты, готовьтесь к ним, закладывайте в оценку.