Искусство управления IT-проектами - [20]

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

Позже, когда планирование стало частью моих обязанностей, я понял, в чем состоит невысказанная правда об этих планах. Они не были подарком из будущего. Для составления совершенных календарных планов не существует ни магических формул, ни особой науки. Вопреки моему юношескому восприятию, планирование не было изолированной задачей: оно всегда представляло и охватывало множество различных аспектов настоящего и будущего проекта. Планы являются простой формой предсказания. И неважно, насколько пунктуально они составлены или насколько убедительно выглядят – по сути, это всего лишь сборник множества мелких расчетов, каждый из которых невозможно избавить от различных непредвиденных упущений и неточностей. Хорошие планы получаются только у тех руководителей или команд, которые неуклонно ищут и достигают разумных оценок различных аспектов разработки программных продуктов. Нельзя быть узким специалистом и ожидать при этом, что когда-либо вам удастся создать хороший календарный план.

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

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

Расчет – дело тонкое

В процессе проектирования (обсуждаемого в главах 5 и 6) одной из задач проектировщиков, программистов и тестировщиков является разбиение проекта на небольшие части работы, которая имеет некие завершенные формы. Эти части, часто называемые элементами структурной декомпозиции работ (Work Breakdown Structure, WBS[14]), или просто работами, становятся строками в главном календарном плане проекта. Работы разумно (скрестите пальцы) распределяются[15] среди программистов команды и в соответствии с ними строится календарный план. Каждая из этих работ должна иметь предполагаемый срок завершения, назначенный программистом, и на основе этих предположений создается календарный план.

По самому простому определению качественные оценки работ имеют высокую вероятность оправдаться, у поверхностных оценок такая вероятность крайне низка. Я не ожидаю наград за подобное определение, но в нем имеется, по крайней мере, одно рациональное зерно: определять планку каждого проекта – прерогатива его руководителей. Этот процесс требует активного пересмотра оценок, а также нажима на подчиненных, руководства ими и принуждения их к работе с целью добиться соответствующей отдачи. Я думаю, что вполне разумно широко привлекать к расчетам команду тестировщиков и контролеров качества продукции, позволяя им участвовать в обсуждении проекта, задавать вопросы или отпускать комментарии. Как минимум, это поможет им в собственных оценках работ по тестированию, которые могут никак не соотноситься с расчетами на работы программистов. Зачастую тестировщики обладают лучшим видением недостатков проекта и потенциальных причин сбоев, которые другими специалистами могут быть упущены.

Весь мир держится на расчетах

Трудности планирования заключаются в том, что далеко не всем нравится вести сложные расчеты, за которые потом придется отвечать. Всегда хочется прихвастнуть и козырнуть мастерством («эта книга, фильм или веб-сайт никуда не годится, я бы смог все сделать намного лучше»), но стоит только заставить нас подойти и поставить подпись рядом со своим именем в контракте, в котором детализируется возлагаемая на нас ответственность, взгляд на вещи резко изменяется. Мы знаем, насколько вероятна ситуация, при которой сегодняшние обещания, когда придет время заняться делом, завтра могут обернуться полной несостоятельностью. Может статься, что все окажется намного сложнее, чем мы думали. Программисты – такие же люди, как все, и имеют серьезные основания побаиваться расчетов. Говоря о том, что смогут справиться с задачей в определенные сроки, они рискуют сильно ошибиться.