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

Что делать, когда оценка времени идет неправильно?
Что делать, когда оценка времени идет неправильно? - giuvicente @ Unsplash

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

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

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

EDIT: В очень сложных проектах, независимо от того, сколько разумного времени вы уделяете анализу и проектированию, всегда возникают неожиданности, поскольку бизнес-правила слишком сложны. Однако в таких случаях я считаю, что руководитель проекта должен осознавать сложность и иметь правильное отношение к неожиданным сюрпризам. Вопрос в том, как бороться с руководителями проектов, которые не понимают сложности.

Сообщение плохих новостей

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

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

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

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

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

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

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

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

Избавьтесь от необходимости сообщать плохие новости

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

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

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

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

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

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


LetsCodeIt, 29 мая 2023 г., 04:31