Что делать, если оценка времени идет не так?

26

Допустим, вы оценили время рассмотрения дела в 3 дня. На второй день вы заметите, что ситуация растет, и появляются новые сценарии, которые не учитывались при оценке времени. Новое открытие приводит к дополнительным 2 дням (всего 5 дней). Это типичная проблема, с которой вы рано или поздно столкнетесь как разработчик.

  • Какую стратегию можно использовать, когда вы собираетесь уведомить руководителя проекта о новом времени доставки?
  • Часто возникает вопрос почему? Как вы мотивируете новое время доставки?

Дело в том, что во время SDLC многие проекты не уделяют много времени анализу и проектированию.

РЕДАКТИРОВАТЬ: В очень сложных проектах, независимо от того, сколько разумного времени вы уделяете Analysis & Design, всегда есть сюрпризы, так как бизнес-правила слишком сложны. Однако в таких случаях я считаю, что руководитель проекта должен осознавать всю сложность и иметь правильное отношение, когда возникают неожиданные сюрпризы. Вопрос в том, как справиться с руководителями проектов, которые не понимают всей сложности.

Амир Резаи
источник
1
Я думаю, что лучший вопрос, что вы делаете, когда оценка была правильной ? В большинстве случаев этого не будет.
Тим Пост
@Tim Post Вы правы насчет "В большинстве случаев этого не будет", я хотел зарезервировать.
Амир Резаи
1
+1 - Спасибо за редактирование, которое содержит слова мудрости. Тот факт, который вы подчеркнули («« В очень сложных проектах, независимо от того, сколько разумного времени вы уделяете Analysis & Design, всегда есть сюрпризы, поскольку бизнес-правила слишком сложны.) »» - это очень верно.
Картик Сринивасан

Ответы:

17

Доставка плохих новостей

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

Как и со всеми плохими новостями, лучше предоставить подробную информацию (а не просто сказать, что «будет поздно»), поэтому предоставьте как можно больше / многие из:

1) Пересмотренные оценки / сроки выполнения задач, которые ускользнули.

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

3) Очень краткие причины, по которым произошло проскальзывание (не крутите, только правду, но не говорите, что вы оправдываетесь). В этом случае вы заявляете: «Мы оценили на основе правил X и Y, но теперь они включают Z, который никогда не упоминался». Возможно, он сможет использовать это, объясняя задержку клиентам и информируя их о важности тщательности в первую очередь.

4) Если возможны альтернативы, чтобы вернуть вещи в нужное русло (обычно это сокращает объем, но могут быть и другие варианты - другие части проекта могут быть заблаговременными, и может быть возможность перемещать задачи вокруг).

Помните, что с проскальзываниями психологическое воздействие / доверие заслуживает кульминации. Возможно, вам удастся избежать неприятностей с одним, но второй будет намного жестче, а третий еще жестче.

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

Предотвращение необходимости доставлять плохие новости

Здесь есть два сценария: во-первых, вы сами не делали оценки, и в этом случае вы мало что можете сделать, кроме как подтолкнуть вас к участию в оценках в следующий раз.

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

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

Вы можете сделать это, увеличив оценки для ваших правил (это работает, но вы никого не информируете о том, что на самом деле происходит), но лучше заявить о своих оценках "Исторически правила, которые мы получаем, являются упрощенной версией о том, чего они действительно хотят. На выполнение правил, которые они заявили, уйдет 3 дня, однако мы должны предоставить еще 3 дня для правил, которые не были упомянуты, но, вероятно, будут обнаружены во время разработки и тестирования ».

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

Но суть: если вы всегда недооцениваете из-за определенного фактора (в данном случае это ползучесть), то включите это в свои оценки.

Джон Хопкинс
источник
2
+1 «Как и во всех плохих новостях, лучше предоставить подробную информацию». Однако не все понимают детали / сложность проблемы.
Амир Резаи
@ Амир - Я добавил немного больше, хотя как человек, который понимает всю сложность, простая истина заключается в том, что вы обязаны объяснить это. Они не собираются учиться по-другому.
Джон Хопкинс
Хорошие моменты! «с примерами - трудно спорить с примерами» & «мягко предположить, что в его интересах доставить вовремя». Что касается «если это всегда происходит, это не должно быть сюрпризом», проблема в том, что дополнительное время для сюрприза не является постоянным. Таким образом, вы можете даже не брать среднее значение для них, так как они, как правило, имеют большие различия.
Амир Резаи
+1 «Помните, что с проскальзываниями психологическое / авторитетное воздействие накапливается».
Картик Сринивасан
16

Оценки, основанные на времени, - это предположения о будущем, которые в конечном итоге всегда будут неудачными. Это бессмысленная битва, которую вы не можете выиграть.

Прекратите оценку в днях и начните использовать относительную оценку вместо этого. Вот простой пример:

  1. Назначьте номер для каждой задачи. Самая сложная задача может быть 10, а самая простая задача 1.
  2. Начните программировать, чтобы завершить свои задачи.
  3. Через неделю прекратите работу и сложите номера всех выполненных заданий. Допустим, в итоге вы получите 14. Это ваша недельная скорость.

На следующей неделе повторите процесс снова. Бьюсь об заклад, ваша скорость изменится, но не сильно. После нескольких недель с этим ваша скорость должна быть довольно стабильной, и это то, к чему мы стремимся. Теперь вы можете начать строить планы с уверенностью. Выберите задачи, которые суммируют с вашей скоростью, и ваш PM может быть совершенно уверен, что он будет выполнен, как и было обещано. Вот как вы должны решать свои проектные лидеры.

Мартин Викман
источник
Можете ли вы привести пример того, как вы отслеживаете размер задач? Вы создаете таблицу с типами задач (например, «создать новую форму», «добавить метод к веб-сервису X») или это более интуитивное чувство?
съеживаться
Просто сравните с задачами, которые вы оценили и выполнили ранее.
Мартин Уикман,
+1 - «Оценки, основанные на времени, - это предположения о будущем, которые в конечном итоге всегда будут неудачными. Это бессмысленная битва, которую вы не можете выиграть». Я впервые узнаю об относительных оценках, и это определенно пища для размышлений. Спасибо.
Картик Сринивасан
Какая блестящая идея! Я определенно буду исследовать это дальше.
meetpd
3

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

Обратитесь за помощью к товарищам по команде, если это возможно. Убедитесь, что вы все еще поставляете как можно более качественное программное обеспечение.

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

Morten
источник
3

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

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

user281377
источник
2

Всегда информируйте соответствующие заинтересованные стороны о вашем прогрессе, включая (особенно!) Тот факт, что ваши оценки были чрезмерно оптимистичными. Они не будут счастливы, но они будут знать, где на самом деле стоит проект, и могут планировать соответственно.

В идеале ваш список функций должен быть MoSCoWed - должен, должен, мог, не будет.

Когда вы направляетесь к перебегу, отрежьте Coulds, а затем - Needs. Сокращайте возможности, чтобы вы могли отправлять их вовремя: ваш проект обычно не живет изолированно, и вы выходите за пределы даты выпуска, что означает, что последующие проекты также будут перегружены своим графиком.

В идеале у вас будет только ~ 60% Musts. Если вам приходится резать тех, у вас очень большие проблемы (с очень серьезным перебором), в этом случае вам придется срезать углы.

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

Фрэнк Шиарар
источник
4
+1 @Frank Хороший вопрос по поводу "Вырезать функции, чтобы вы могли отправить вовремя". Проблема в том, что я не руководитель проекта.
Амир Резаи
@Amir В этом случае ваш клиент (вроде как) ваш руководитель проекта. Вы говорите: «Я позади. Я могу отключить эту функцию или эту функцию. Что мне делать?»
Фрэнк Шиарар
@Frank Так как мы делаем Scrum, и дело перенесено из отставания в спринт, кажется, что PM написано в камне, чтобы уменьшить количество дел. Однако опытный ПМ может не иметь такой проблемы.
Амир Резаи
Я не люблю Москоу. Единственный ум с этим - аббревиатура. Просто держите свои задачи в приоритетном отставании.
Мартин Уикман
1
@Martin пожимает плечами «должен» означает «если вы не отправляете эту функцию, у вас ничего нет». Это информация, отличная от приоритетного невыполненного задания, которое «какую функцию вы бы предпочли в первую очередь?» У вас все еще есть приоритетное отставание от MoSCoW.
Фрэнк Шиарар
2

Оценка проекта азартная, простая и понятная. Там нет награды без риска.

Если менеджер не понимает этого, это первое, что я бы объяснил.

Вопрос в том, кто покрывает риск?

Если у вас контракт с фиксированной ценой, вы покрываете риск.

Если время и материалы, то он покрывает риск.

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

Майк Данлавей
источник
1

Я считаю, что лучшая стратегия - постоянно улучшать ваши оценки . Я знаю, я говорю: ваш вопрос как-то неуместен.

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

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

Для меня оценка не может быть правдой или ложью. Это может быть просто улучшено . Оценка не является обязательством. Вот почему это называется оценкой.

Лучшее, что вы можете сделать, когда опаздываете (а также когда «рискуете заблаговременно доставить», потому что проблема одна и та же: вы плохо оценили), заключается в эскалации и доведении этого до клиента как можно скорее. Это называется управлением рисками. Чем раньше вы дадите отзыв, тем эффективнее будет противодействие. Обычно это означает, что, если у вас есть доказательства того, что вы не можете доставить все, вам следует поговорить с вашим клиентом, сказать ей, что вы можете выполнить только 70% обязательств, и пусть она решит, что имеет для нее большую деловую ценность и что ее следует развернуть в первую очередь .

Я писал об этом здесь Неправильная оценка, помогите! Я опаздываю! Вырезать черты и остановить водопад!

Ариальдо Мартини
источник
1

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

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

PeterAllenWebb
источник
0

Пусть вся команда знает это и попытается найти решение. Я рекомендую 3 решения, от высокого до низкого приоритета:

а. Попробуйте найти временное исправление или краткий обзор

б. Работа, которую вы можете сделать, сделать это лучше всего. После того, как вы продемонстрировали свою отличную часть работы клиенту, попросите его о помощи: мы можем сделать это, но есть некоторая проблема, и это может снизить производительность вашей работы ... Может быть, вы можете спросить их, есть ли какой-либо ненужный запрос / особенность, которую можно уронить или урезать.

Предложить альтернативный подход к их проблеме, может быть, хорошая идея.

с. Сверхурочная работоспособный

Хонг Лонг
источник
Я обновил свой вопрос. Это руководитель проекта, который будет уведомлен.
Амир Резаи
Я не совсем понимаю. Вы руководитель проекта или только программист?
Hoàng Long
0

Опции:

  • Вырезать особенности
  • Качество резки (оставьте исправления ошибок на потом)
  • Повысить продуктивность
    • Найти и удалить блокировщики
    • Перерыв / отдых
    • Сократить личное / время сна
    • Получите больше рабочей силы
    • Получить лучшие инструменты
    • Подготовка
    • Повысить мотивацию
      • Бесплатное питание
      • [Обещание] поднять / продвижение / отпуск / бонус / и т. Д.
      • Угрозы
      • Улучшение условий труда (улучшение оборудования, мебели и т. Д.)
      • Изменить обстановку - работать в кафе или переместить всю команду куда-нибудь круто - в горный домик или домик у озера?

источник
1
Следует отметить, что каждое это слово является КРАТКОСРОЧНЫМ ответом на вопрос «что делать, если оценка времени идет не так». В частности, угрозы кратковременно повышают мотивацию , а затем оказывают противоположное влияние.
Дэн Рэй
Я согласен, что угрозы - отстой, хотя я уверен, что они работают для некоторых людей и в некоторых ситуациях, особенно если вы планируете отпустить их в любом случае.
0

Это распространенная проблема :)

Одним из более простых подходов является добавление буфера к любой вашей оценке, поскольку всегда возникают непредвиденные проблемы. Размер буфера зависит от размера команды, неопределенности технологии и самой проблемы.

В больших командах больше людей, которые могут заболеть, и меньше людей, которые знают «все».

Новые технологии всегда более рискованны, чем те, которые вы уже знаете.

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

Патрик Корнелиссен
источник