Читать книгу "Искусство управления IT-проектами - Скотт Беркун"
Шрифт:
Интервал:
Закладка:
Угол снижения
Типовые графики разработки проектов могут быть сведены к простой диаграмме, наподобие показанной на рис. 15.3. Диаграмма составлена с предположением, что показатель прогресса проекта является постоянной величиной, а проект завершится точно по графику при соблюдении постоянного темпа работы. Разумеется, все это из области фантастики. Эта диаграмма никогда не станет отражением реальных событий, поскольку темпы работы команды и ее продуктивность никогда не будут постоянными величинами (по многим рассмотренным ранее причинам).
Рис. 15.3. Характерный пример графика выполнения этапа с неправдоподобными допущениями
Скорее всего, большинство проектов могут оказаться в ситуации, воспроизведенной на рис. 15.4. В какой-то точке пути по направлению к конечной дате команда поймет, что работа идет не так быстро, как ожидалось. Такое может случиться из-за того, что команде поставили дополнительную задачу (см. раздел «Контроль изменений» в главе 14) или не оправдались сделанные ею оценки. Неважно, по какой причине это произошло, но теперь команда оказалась перед выбором: как преодолеть расстояние, оставшееся до конечной даты? Есть только три варианта:
1. Сдвинуть график. Отодвинуть чуть дальше конечную дату в соответствии с новым пониманием угла наклона линии, отражающей ход выполнения проекта.
2. Изменить угол наклона. Поверить в то, что команду каким-то образом удастся заставить работать быстрее и производительнее, чтобы своевременно компенсировать возникшее отставание (например, приготовиться к аварийной посадке). Можете, конечно, попробовать этот вариант, но чем-то все равно придется пожертвовать. Например, возросшим риском наделать ошибок, вялостью и усталостью команды к началу следующего этапа.
3. Подойти к окончанию этапа, ничего не меняя. Определите те характеристики или работы, на которые придется потратить больше усилий или которые являются более рискованными. Затем либо прекратите ими заниматься, отложив до следующего этапа (если он предвидится), либо снизьте к ним качественные требования и оставьте все как есть.
Рис. 15.4. Реализация графика зачастую расходится с планом. Как с этим справиться – целиком зависит от критериев выхода
На чем остановить свой выбор – полностью зависит от критериев выхода. Это именно та ситуация, в которой наибольший выигрыш складывается из четкого понимания того, что именно подразумевается под окончанием этапа. Вместо того чтобы изобретать критерии на ходу, в состоянии стресса, вызванного трудной посадкой, лучше просто оглянуться назад и внести поправки в критерии, определенные несколькими неделями ранее. Принятие решения в сложной ситуации эндшпиля значительно облегчится, если есть уже знакомые команде критерии, на которые всегда можно сослаться.
Почему не срабатывает изменение угла снижения
Если опять обратиться к аналогии с самолетом, то изменение угла снижения, чтобы попасть на полосу, делает заход на посадку нестабильным. Проекты во многом подобны самолетам – при увеличении скорости снижения (завершения) становятся плохо управляемыми. Чтобы стабилизировать скорость снижения, нужно одновременно проделывать слишком много манипуляций. Если пилот, сидя за штурвалом приземляющегося самолета, видит, что самолет сносит мимо полосы, он заходит на посадку заново (переместить посадочную полосу, в отличие о графика, невозможно). В сложных погодных условиях пассажирские самолеты часто заходят на второй круг. В проектах же такая возможность предоставляется крайне редко. Они подобны самолетам, у которых топливо на исходе: ресурсов хватает только на одну попытку. Имея в запасе единственную попытку, здравомыслящие пилоты будут снижаться очень осторожно и по хорошо продуманному плану. Благоразумные руководители проекта обязательно последуют их примеру. Если дата или набор характеристик должны быть неизменными (как посадочная полоса), вы должны начать готовиться к посадке как можно раньше.
При расстановке приоритетов в работе действует основной психологический принцип. При прочих равных условиях люди склонны уклоняться от того, что им не хочется делать.[91]А значит, в процессе выполнения графика все оставшиеся работы и неисправленные ошибки становятся неприятной обузой текущего этапа. Пусть даже недоделаны какие-то пустяки, если команда поощряется за определенное количество исправленных за день или за неделю ошибок, у нее появляется естественное стремление выбирать ошибки попроще, чтобы выполнить квоту.
К концу этапа люди становятся усталыми, унылыми и раздражительными, что отрицательно сказывается на производительности труда. Сложные ошибки имеют особенность появляться максимально близко к концу этапа. Программист смотрит на одну из таких ошибок, понимает, что она не из легких, и под гнетом других навалившихся на него забот сваливает ее на кого-нибудь другого, кого можно назначить ответственным за ее устранение. Как писал Вейнберг (Weinberg): «… проблемы не решаются, а просто переходят их рук в руки». Этому естественному искушению поддаются время от времени даже самые лучшие программисты.
Элементарная склонность к затягиванию сложной работы проявляется и в обнаружении ошибок, хотя причины этого кроются уже не в психологии. Дефекты, которые выявляются дольше всех или проявляются под конец этапа, обычно (как и следовало ожидать) оказываются самыми непростыми[92](рис. 15.5). Если тенденция касается сложных, но низкоприоритетных ошибок, ей не стоит придавать особого значения, но если речь идет о высокоприоритетных ошибках, то такая тенденция становится серьезной проблемой. Подобные ошибки не только выявляются дольше среднестатистических, но и исправляются намного дольше. Обе прямые линии проектного пути, показанные на рис. 15.4, нельзя считать правильными: на самом деле линия приближения проекта к контрольной дате является близкой к асимптоте (кривой) и выглядит примерно так, как на рис. 15.6. Команда может работать с прежней интенсивностью, но результативность – в смысле приближения к целям – падает. Чем ближе контрольная дата, тем справедливее это утверждение.
Рис. 15.5. Самые сложные ошибки почему-то обнаруживаются и устраняются ближе к концу этапа. А это значит, что подход к конечной дате не выглядит прямолинейным – скорее это кривая линия на шкале прогресса (см. рис. 15.6)
Внимание!
Сайт сохраняет куки вашего браузера. Вы сможете в любой момент сделать закладку и продолжить прочтение книги «Искусство управления IT-проектами - Скотт Беркун», после закрытия браузера.