2019-06-25 11:33:40

Типичная управленческая задача

Про работу

Спринт

Дано: 4 дня, 4 разработчика, 4 задачи на 3 дня каждая, 1 задача на 4 дня.

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


Если оперировать просто цифрами, то 4 человека по 4 дня = 16 человеко-дней и 4*3 + 1*4 задачи тоже = 16, кажется, что по ресурсам все сходится и все можно сделать. Но в реальности сделать все задачи нереально, не смотря на то, что они помещаются в отведенные человеко-дни, несколько разработчиков не могут параллельно делать часть задачи (за исключением редких специфических случаев).

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

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

В реальном мире оптимальным решением является выполнение 4 задач по 3 дня и начать задачу на 4 дня (утилизация 13 из 16). Но поскольку с высокой долей вероятности после выполнения потребуется тестирование и мелкие доработки, которые "съедят" дополнительный день на каждую задачу. Таким образом можно обеспечить реальное качественное выполнение, без перетекания доработок в новые задачи, а не просто утилизацию ресурса на бумаге.

В результате типичного управленческого решения мы получим 3 невыполненные задачи и 2 выполненные, а в результате реального решения 4 выполненные и 1 невыполненную. А в результате решения с резервом - получаем большую эффективность и лучшее качество на более длинном временном отрезке, например, в рамках проекта в целом.

Мораль сей басни в том, что при планировании разработки в небольших командах нужно обязательно закладывать резерв в размере примерно ресурса 1 разработчика. Размер резерва безусловно зависит от размера команды, но должен быть не менее 20-30% от общего ресурса команды.