web_foxЕсть проект. В рамках проекта нужно изменить уже существующую систему.
Разработчику поставлена задача сделать конкретное изменение. Он оценивает его как 1-2 недели на глаз. Что, конечно, сигнал, что сроки придуманы и с высокой вероятностью будут нарушены. Разработчику дано предложение день разобраться и спланировать промежуточные результаты со сроками. Для нового разработчка не привычно самому себе строить детальный план на задачу, т.к. он никогда такого не делал и это вызывает у него затруденение. Самому лезть в техническую часть и разбираться как можно декомпозировать задачу желания (а, возможно, и смысла) нет.

Как можно улучшить данную ситуацию, что не правильно?

1. Планирование

1.1. Неправилен срок оценки. Любая задача в плане должна длиться не больше 3-х рабочих дней. Если называют 10, прошу рассказать, из каких шагов/подзадач будет состоять ее решение. Не все могут оценить сразу на глаз. Эта проблема решается так - прошу проанализировать, сколько времени на анализ понадобится? Обычно на анализ уходит не больше 2-х часов, очень часто хвататет получаса.

1.2. За сроки отвечает человек, у которого роль ПМ в команде. Сам разработчик в первую очередь отвечает за КАЧЕСТВО решения, сроки - не его вопрос. ПМ вопрос решает типично - умножает на 4 полученные оценки. Начальство их делит на 2, получаются более ли менее реалистичные сроки.



2. Контроль

Существенно зависит от человека.
2.1. Сотрудники. Есть люди, которым есть большой кредит доверия, они, если ошибаются со сроками, то в основом из-за того, что при начальном анализе что-то не учли или что-то всплыло во время разработки. Для таких - контроль по датам завершения мелких подзадач (п. 1.1 выше) и вопросы, не изменился ли план в части появления новых, не учтенных задач.

2.2. Сотрудники. Есть люди, которые замечены в излишней расслабленности (в команду стараемся таких не брать, но не всегда получается). Для таких - методы из п. 2.1 + ненавязчивое наблюдение, чем они заняты в течение дня + выборочный контроль подзадач. Если написание процедуры на 1 экран оценено в 3 дня, будет отдельный разговор.

2.3. Аутсорсеры.
Эти всегда просрачивают. Метод решения - выставлять в 2 раза более сжатый срок, к которому они опоздают, и в итоге сделают решение примерно к тому сроку, к которому требуется.

В новогодние праздники тема затерялась.Отвечаю с опозданием
web_fox1. Тогда вопрос. Как вы учитываете факт, особенно, если вы работаете как я сейчас 10008308 ? Лично я работаю с MSProject. Получается, что все задачи в календарном плане нужно разбивать на две (озвученная исполнителем длительность + буфер)?
Вообще-то Проджект (2007) умеет вести несколько дат - плановые даты, фактические, разницу + обсчитывать сценарии (PERT анализ, я не пользуюсь). Если вопрос был про план - в него забиваются реалистичные оценки + в явном виде запас времени на этап. Планирование вообще без буфера - утопия. Стоит 1 задаче с критического пути опоздать на 1 день - весь проект "поехал".


web_fox2. Знает ли человек о буфере?
Скорее да, чем нет. Это неважно, в свои сроки он в любом случае должен попадать. Или своевременно переоценку сделать.


web_fox3. Нет ли проблем с тем, что вы всё время работаете с нарушением декларируемых исполнителями сроков?
Есть. К счастью, только меньшая часть исполнителей постоянно их нарушает. бОльшая довольно быстро обучается давать более ли менее реалистичные оценки.


web_fox4. Ну и совсем трудный вопрос, или даже проблема, что при планировании с преднамеренным нарушением сроков, совсем не понятно как считать показатели освоенного объёма.
1. План должен быть один
2. План должен быть реалистичным. Реалистичность достигается коррекцией оценок на известную погрешность.
3. EV, AC, PV рассчитываются как пээмбуке описано.