Как правильно наказывать разработчиков за срыв сроков?

Question

[Игорь Батраков]

В компании отдел разработки зачастую не укладывается в сроки, которые сам и определяет и утверждает. Для этого находятся сотни причин. Что касается "пряника" за сдачу в срок - понятно. Есть премия в виде % от проекта и всякие дополнительные плюшки. А вот как быть с "кнутом" непонятно. Как правильно наказывать, чтобы на было демотивации, но было понятно, что нужно правильней планировать?

Answer 1

[Яков Е]

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

Тут одно дело, когда работа шаблонная, многократно выполненная (как скажем типовой сайт), в таком случае все сроки можно прикинуть более-менее точно. Другое дело, когда что-нибудь создается уникальное и не шаблонное, ошибка может быть в разы.

Я бы посоветовал два-три раза в неделю узнавать у каждого, чем он занимался предыдущие дни, какие проблемы есть, какие решения он видит, чтобы видеть в реальном времени как меняется оценка и ситуация. Но да, тут желательно бы самому разбираться хотя бы на среднем уровне, чтобы понимать о чем речь вообще.

Comments

[Игорь Батраков]

Яков, спасибо за коммент. По поводу уточнений 2-3 раза в неделю, так и пытаюсь делать. Видимо не регулярно, а ближе к дедлайнам. Попробую на начальном этапе чаще. Другое дело, что поначалу вопросов и проблем типа нет..

[Яков Е]

Игорь Батраков: «На стендапах с разработчиками мы просим, чтобы они наглядно показали, что было сделано ими за вчера. Прям пальцем на мониторе. Фразы «я писал абстрактный класс для генерации универсальной библиотеки работы с примитивами» — повод выхватить неиллюзорных люлей. На стройке — та же фигня. Не верьте на слово, а проверяйте. Идите и смотрите. Что из себя представляет «временная мембрана на крыше» мы додумались посмотреть, только когда нас уже залило» ©

Владимир Завертайлов
директор студии Sibirix

[Кирилл Таран]

Игорь Батраков: убрать проблему отсутствия вопросов можно, если разбивать задачи на более мелкие, практически атомарные. Например, если задача разбивается на "создать что-то, включающее три таблицы, два интерфейса и один бизнес процесс", то gj первым двум частям результат можно будет видеть, даже если "всё понятно".

Answer 2

[God Emperor]

Кипятильник же

UPD:

Так то Agile призван отследить подобную хрень.

Answer 3

[Тим]

Тот кто укладывается в сроки - их для вас просто раздул.
Чем больше наказание за срыв - тем больше происходит раздутие срока.
Может дойти до разгильдяйства, которое можно проконтролировать только наблюдая за сотрудником.

У нас применяется практика раздутия сроков, но с контролем. Контролируем трафик, имеем ряд запрещенных сайтов (сжирателей времени), и контролируем приход-уход с работы. Этого достаточно как превентивной меры от лени и занятостью не там делом. Менеджеры получают отчет по активности за неделю в пятницу и могут на выходных принять решение кому в понедельник вставить пистонов.

Те кто ходят на 9:30 и уходят в 17:30 и обедают 1.5 часа получают в соотв. % зарплату в конце месяца. Колво рабочих дней * 8 - сумма по трекингу в офисе или удаленке для тех кто злостный нарушитель.

Answer 4

[Оптимус Пьян]

Ну человек не робот, все имеют право на ошибку, иногда всё сделано на 90% и бах ошибка с которой весь день сидеть можно...
Я бы спросил так: как уменьшить вероятность срыва сроков?

Comments

[abcyu]

Как правило, люди работают очень не равномерно. Да, бывают проблемы с которыми можно биться долго. Но если человек действительно бьется. Многие, ох многие, вместо того, чтобы работать просто на Хабре сидят.

Answer 5

[Дмитрий Ковальский]

Любое наказание - демотивация. Даже словесный бубнеж. Вы заложили погрешность расчетов или просто утвердили названные сроки "как есть"? если да, то у меня для вас плохие новости. Нужно закладывать 20%-50%

Comments

[Игорь Батраков]

Закладывается при небольших проектах, до месяца +100% при больших минимум +25%. Такое ощущение, что работает закон Паркинсона с расширением((, Любая работа занимает все отведенное время + еще столько же времени сверх этого ...

[abcyu]

Игорь Батраков: Все уже проверено до нас. Задолго. "Мифический человеко-месяц". Автор Брукс. Много-много лет назад при разработке ныне мертвой операционной системы понял, что закладывать нужно минимум +100%

Answer 6

[Saboteur]

Нужно не столько наказывать, сколько тщательнее контролировать, чтобы на промежуточной стадии было видно успевает или нет.
Не успевает - овертайм. Можно овертайм даже оплатить отдельно, если причины запоздания убедительны.

Несколько овертаймов, но сданных вовремя проектов - и разработчики будут лучше продумывать свои сроки.

Answer 7

[margarita_free]

Блин, ну как наказывать)))
Как в 50 оттенков серого)))
будет 50 оттенков разработки)))