Как справиться с хроническими проблемами времени?

Question

В моем штате есть разработчик, который хронически не соответствует срокам и оценкам. В нескольких проектах прошлой недели или двух каждый день я слышу: «Это должно быть сделано к концу дня». Этот разработчик делает хорошую работу.

Я уже говорил с ним о его проблемах. Кажется, он искренне расстроен и недоволен тем, что нужно сделать, чтобы исправить их.

Мои вопросы:

1. Какие виды наказаний за превышение срока являются эффективными?
2. Какими способами я могу заставить этого сотрудника контролировать его действия (оценки времени и т. Д.)?

UPDATE : На основании ответов; вот что я понял.

1. Наказание - плохая идея.
2. Для работника естественно быть неспособным исправить проблемы оценки без вмешательства.
3. Не устанавливайте крайние сроки, если не будет последствий для компании (потерянный контракт), если они не будут выполнены к тому времени.
4. Используйте доступные методы (Agile, контрольный список Джоэла), чтобы помочь разработчику лучше оценить.

Спасибо за ссылки и информацию. Также спасибо за обновление моего мышления.

Answer 1

Я не думаю, что вы должны наказать его. Просто заставьте его понять, как делать точные оценки.

Как руководитель команды, мои члены команды сказали мне, что "не проблема" завершить функцию X к крайнему сроку. Затем я обычно сижу с ними и рассматриваю, какие задачи и подзадачи, по моему мнению, необходимо выполнить, чтобы завершить эту функцию, и сколько времени разработчик думает, что каждый из них займет.

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

Answer 2

Установите Вехи и попробуйте Agile , как предложено @OTisler.

Answer 3

спросите себя: что влечет за собой ваша работа?

Если вы просто слепо передаете оценки от разработчиков (которые, как вы знаете, не могут дать хорошие оценки) по линии управления, и не решаете для себя, достижима ли эта оценка, то вы не выполняете свою работу.

Попытайтесь думать в терминах «добавленной стоимости» (один из моих старых работодателей часто использовал этот термин, и я ненавидел его, но, вероятно, он работает для вас в этой ситуации). Какую ценность вы добавляете? Если вы просто передаете информацию в обоих направлениях между высшим руководством и разработчиками, то в конечном итоге вы не зарабатываете свои деньги. Вы можете быть удалены, и ничего не изменится.

Лучший менеджер, который у меня когда-либо был, был одним из тех, кто просматривал набор требований, данных ему другой командой, и прямо говорил им, что почти треть из них были быками, и их удалили, прежде чем я даже увидел список. Худшее, что я когда-либо заставлял меня писать всю эту дополнительную документацию управленческого типа, которую не делал ни один из других менеджеров, которых я когда-либо просил (у меня действительно сложилось впечатление, что я буквально выполняю его работу за него), не сделал даже дайте мне срок выполнения проекта, и вряд ли приступили к работе. Они оба были в одной компании, как ни странно.

Answer 4

Значит, разработчик хорошо работает, но плохо оценивает время доставки? Я не уверен, что у вас пока что есть ситуация с наказанием.

Возможно, пойдем на какое-то время вперед, попросим его пройти процедуру оценки точки доставки. Это может быть возможностью спросить его, почему шаги X, Y и Z занимают определенное количество времени. Он может пересмотреть свои оценки, просто выполняя упражнение, которое почти наверняка медленнее.

Answer 5

90 часов - это один общий короткий срок выполнения проекта. Самый простой способ - вместо того, чтобы оценивать «свое время», вы измеряете другое. Программисты не должны делать оценки времени для своих проектов, поскольку свидетельства показывают, что расчет собственного времени приводит к большей ошибке, чем наблюдение другого.