Уважаемые коллеги, кто как справляется с проблемой просрочки задач?
Например, если один из членов команды постоянно не укладывается в заявленный срок.
Не больничный, не отпуска, отговорки вроде "закопался в решении", "думал сделать так, чтобы при доработке не надо было все переделывать", работаю над очень крутым решением, поэтому долго".

Заранее спасибо

Справляемся по-разному, в зависимости от ситуации:
Пытаемся разобраться в диалоге, что именно происходило и что стало причиной ошибки в оценке
Планируем совместно
Нарезаем задачи на более мелкие (не больше 4 часов каждая)
Вместе выполняем очередную задачу
Ставим наставника
Берём поправочный коэффициент 1,5-Pi на все его оценки
Отправляем человека отдохнуть
Делаем отчёты об исполнении задач публичными
Вводим ежедневный скрам
Наказываем снижением премии
Жалуемся его линейному руководителю
Увольняем

Согласен с Денисом.
Важная часть планирование.
Информация доводиться до руководителя проекта.
Сотруднику объясняется, что решение должно уладываться в рамки цена-качество-время.

Обычно после диалога в основном понимают

Здравствуйте, Careeristka!

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

А как у Вас происходит контроль сроков? В какой момент времени менеджер проекта узнаёт, что разработчик не успевает справиться с задачей?

У нас это происходит так:

1. Перед началом production'а фичи разработчик прорабатывает технический дизайн фичи, который оформляется документально.
2. Разработанный дизайн ревьюится ведущим программистом, который вносит свои замечания, а разработчик - на основе этих замечаний - вносит изменения. После чего дизайн считается принятым.
3. Параллельно разработчик разбивает фичу на подзадачи, каждая из которых не может быть меньше 4-х и больше 24-х часов.
4. Эти задачи и их оценка также ревьюятся ведущим программистом, после чего вносятся изменения в задачи и их оценку, и далее - принимаются.
5. Затем задачи вносятся в систему контроля задач, и разработчик приступает к их выполнению.
6. Приступая к работе над задачей, разработчик ставит её в статус In Progress.
7. В конце каждого дня он обязан проапдейтить эстимейт по задаче. В ситуации, когда всё нормально, часы уменьшаются с запланированной скоростью.
8. Если задача пробуксовывает, то это сразу же становится видно менеджеру проекта, т.к. он собирает статистику каждый вечер после того, как все разработчики проапдейтят информацию по текущим задачам.
9. Далее менеджер пытается выяснить, в чём заключается причина пробуксовки. Если она носит организационный характер, то менеджер обязан помочь в её решении. Если причина - неучтённый технический риск, то он заносится в регистр рисков, и далее мониторится. Кроме того, происходит переоценка сроков. Если причина носит какой-то технический характер (например, разработчик не сталкивался с подобного рода задачами, и не знает, как её решить), то подключается ведущий программист, который помогает разработчику.

Опишите подробно один какой-нибудь случай из вашей практики. Слишком мало информации.

Согласен с Денисом.
Важная часть планирование.
Информация доводиться до руководителя проекта.
Сотруднику объясняется, что решение должно уладываться в рамки цена-качество-время.

Обычно после диалога в основном понимают

Вообще то, нет. Не должно. Эта штука вариативна. А попытка компенсации разброса, вызванного общими причинами всегда ведет к негативным последствиям.

Действия в случае особых и общих причин должны кардинально различаться.
"ГОСТ Р 50779 контрольные карты Шухарта"  предлагает 8 критериев для того, чтобы отличить одну ситуацию от другой. Но лучше Генри Нива почитать. "Организация как система"

Обычно после диалога в основном понимают

Не-а. После диалога проблема маскируется. А ситуация ухудшается. Только теперь этого не видно.

PS. Вероятно, то, что я написал, выглядит несколько странно. Эти штуки контринтуитивны. Но с этим я ничего не могу сделать.

Не-а. После диалога проблема маскируется. А ситуация ухудшается. Только теперь этого не видно.

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

У нас в компании, срыв сроков происходит обычно по двум причинам:
1. Разработчик думает что знает как сделать за указанное при оценке время.
2. Разработчик не думает при оценке ни о чем кроме решения задачи.

Т.к.  разработчиков у нас не очень много (менее 20 человек), по этому для каждого сотрудника есть поправочный коэффициент.
Т.е. оценка каждого умножается на него. Обычно он где-то в диапазоне 1,2 - 1,5.

Т.к.  разработчиков у нас не очень много (менее 20 человек), по этому для каждого сотрудника есть поправочный коэффициент.
Т.е. оценка каждого умножается на него. Обычно он где-то в диапазоне 1,2 - 1,5.

Это тоже неправильно. Поправочный коэффициент должен быть таким, чтобы срыв сроков был в 50% случаев. После чего нужно на основании статистики рассчитать верхний и нижний пределы. И если вам нужен "почти гарантированный результат", то верхний предел и будет такой оценкой. Только разработчику ее показывать не надо, дабы не срабатывало когнитивное искажение "студенческий синдром".
И еще момент. Если программист дает оценку трудоемкости, то это снижает его производительность примерно на треть. Оно вам точно надо?

И если вам нужен "почти гарантированный результат", то верхний предел и будет такой оценкой.

Фактически у нас это он и есть.

Только разработчику ее показывать не надо, дабы не срабатывало когнитивное искажение "студенческий синдром".

Ни в коем случае!:)

Если программист дает оценку трудоемкости, то это снижает его производительность примерно на треть.

Никогда об этом не слышал, можно поподробнее?

Оно вам точно надо?

У нас проекты фикс прайс. Сначала нам из коммерческого департамента спускают проект, мы его оцениваем, затем уже продажники, руководствуясь какими-то внутренними инструкциями продают эти часы клиенту.
Оно нам может и не надо, но по другому в данном случае не знаю как.

Если программист дает оценку трудоемкости, то это снижает его производительность примерно на треть.

Никогда об этом не слышал, можно поподробнее?

Статистика: http://www.ozon.ru/context/detail/id/2338486/
Теоретическое обоснование: http://www.ozon.ru/context/detail/id/21211837/

У нас проекты фикс прайс. Сначала нам из коммерческого департамента спускают проект, мы его оцениваем, затем уже продажники, руководствуясь какими-то внутренними инструкциями продают эти часы клиенту.
Оно нам может и не надо, но по другому в данном случае не знаю как.

Примерно как везде.
По другому можно, но этому учиться надо. Долго.
Продавать часы сильно не выгодно. Продавать лучше пользу клиента. И именно этому учиться долго.

Примерно как везде.
По другому можно, но этому учиться надо. Долго.
Продавать часы сильно не выгодно. Продавать лучше пользу клиента. И именно этому учиться долго.

Спасибо за ссылки.
Может что-нить порекомендуете почитать про продажу пользы?

Спасибо за ссылки.
Может что-нить порекомендуете почитать про продажу пользы?

IMHO, наиболее ярко продажа пользы описана в книге "Цель-3". Только чего то я ее в продаже не вижу.
Еще можно вот эти две:
"Цель-2" http://www.ozon.ru/context/detail/id/6258664/
"Я так и знал!" http://www.ozon.ru/context/detail/id/5572374/

А первая цель это о том, как сделать чтобы было чего продавать. Т.е. об операционном менеджменте.

PS. На всякий случай примете к сведению предупреждение. И отнеситесь к нему серьезно. Изучение этих книг может изменить вас. Изменить необратимо. И это может быть очень больно.
-------------------------------------------------------------
"...но не совершай ошибку, Драко. Настоящая наука не похожа на магию. Ты не можешь заняться ею и остаться прежним, как это происходит, когда ты узнаёшь слова к новому заклинанию. За силу нужно платить. Платить цену столь высокую, что большинство людей отказываются это делать."

Вообще то, нет. Не должно. Эта штука вариативна. А попытка компенсации разброса, вызванного общими причинами всегда ведет к негативным последствиям.

Рассмотрим пример.
Есть 2 недели на реализацию требования Заказчика. Оценили -  решили что делать 2 дня. Через день понимаем, что делать как минимум 5 дней.
Одно из решений: упростить реализацию, сделать за 4 дня , протестировать. И с осознанным риском отдать Заказчику.

Не-а. После диалога проблема маскируется. А ситуация ухудшается. Только теперь этого не видно.

Т.е. что  не разговариваем тогда ? Цель разговора, довести текущее положение, о том что что к указанному сроку надо.
И на этом конечно не заканчиваем, а определяем маяки контроля.

В итоге если это будет систематически или разработчик успеет адаптироваться или придется попрощаться с ним

Продавать часы сильно не выгодно. Продавать лучше пользу клиента. И именно этому учиться долго.

Не могли бы вы пояснить эту идею?

У меня опыт участия в продажах не сильно большой, но в целом он укладывается в следующие рамки:

Сейл: Заказчик, тебе для полного счастья нужна вот такая хрень! Она для тебя сделает ... а еще ...
Заказчик: Ух ты! Хочу! Сколько мне это будет стоить?
Сейл: Надо посчитать, завтра пришлю оценку.
...
Сейл: Команда, мы вроде продали Заказчику ту хрень, которую бросили делать в прошлом году. Срочно нужна оценка, чего нам будет стоить сдуть пыль и довести до ума.
Команда: (после продолжительных подсчетов) X усредненных человеко-часов!
Сейл: Так... Х*1,5*стоимость часа + накладные + маржа + премии + премии мне + поддержание лояльности заказчика = Y.
...
Сейл: Заказчик, счастье обойдется тебе в Y*1,15!
Заказчик: Ну них.. себе счастье! Вы обалдели?
Сейл: Вот смета, убедись.
Заказчик: Да, по вертикали и горизонтали суммы сходятся... Ну, пошли договор заключать.

Т.е. заказчику продается счастье, а суммы подтверждаются часами.

Не могли бы вы пояснить эту идею?

У меня опыт участия в продажах не сильно большой, но в целом он укладывается в следующие рамки:

Сейл: Заказчик, тебе для полного счастья нужна вот такая хрень! Она для тебя сделает ... а еще ...
Заказчик: Ух ты! Хочу! Сколько мне это будет стоить?
Сейл: Надо посчитать, завтра пришлю оценку.
...
Сейл: Команда, мы вроде продали Заказчику ту хрень, которую бросили делать в прошлом году. Срочно нужна оценка, чего нам будет стоить сдуть пыль и довести до ума.
Команда: (после продолжительных подсчетов) X усредненных человеко-часов!
Сейл: Так... Х*1,5*стоимость часа + накладные + маржа + премии + премии мне + поддержание лояльности заказчика = Y.
...
Сейл: Заказчик, счастье обойдется тебе в Y*1,15!
Заказчик: Ну них.. себе счастье! Вы обалдели?
Сейл: Вот смета, убедись.
Заказчик: Да, по вертикали и горизонтали суммы сходятся... Ну, пошли договор заключать.

Т.е. заказчику продается счастье, а суммы подтверждаются часами.

Леонид, вы абсолютно правы. Так обычно и бывает. Но бывает и по другому. Редко. Я например так не умею.

Завод металлоизделий.
- Консультант. У вас сейчас в месяц $100kk продажи, $110kk расход и $800kk связанного капитала. Могу сделать $150kk продажи, $110kk расход и $200kk связанного капитала. Гоже?
- Заказчик. Да. Сколько?
- Консультант. $5k   в месяц в течении 6 месяцев. Потом начнется вышеописанное счастье и тогда будете в течении 12 месяцев отдавать четверть от улучшения продаж и выгоды от уменьшения связанного капитала.

----------------------
Итого доход консультантов:
$30 000 - фиксированная сумма
(150 000 000 - 100 000 000)* 1/4 * 12 = $150 миллионов от увеличения продаж
(800 000 000 - 200 000 000)* 3% * 1/4 * 12 = $54 от уменьшения связанного капитала

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

"Меняться необязательно. Выживание дело добровольное."