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

Барри Боэм в своем эссе 1988 года на тему разработки ПО[23] пришел к выводу, что ошибки графиков растут пропорционально тому, насколько рано сделаны предположения (рис. 2.3). Если общий расчет графика осуществлен рано, он может попасть мимо цели аж на 400 %, причем в обоих направлениях (подозреваю, что ошибки в графике всегда играют против нас, отнимая больше времени, чем мы ожидали). На этапе проектирования, когда многие решения становятся очевидными, диапазон отклонений от графика немного сужается. Только когда проект перейдет в стадию реализации, расчеты становятся обоснованными и реалистичными, но даже тогда остается 20 %-ная вероятность того, что график недостаточно точен.

Рис. 2.3. Диапазон возможных отклонений от сроков проекта (адаптировано из Software Engineering Economics Боэма)

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

Когда я работал над своими первыми масштабными проектами после окончания колледжа (Windows и Internet Explorer), кто-то гораздо более авторитетный, чем я, присылал сверху график моей команде. Поскольку я был неопытным новичком и не мог активно участвовать в процессе, мне и небольшому количеству программистов и тестировщиков оставалось только следовать этому «генплану».

Мы бурно обсуждали и согласовывали его отличия от графика, который составляли опираясь на конкретные задачи[24]. «Генплан» спускали сверху, и он был великолепно «причесанным», с аккуратными колонками, датами и цифрами. Словно некий артефакт, выкраденный из будущего.

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

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

Итак, если все члены команды согласны, что график – это ряд предположений, то проблемы не в нем самом, а в его применении. Если график показывают на встрече команды или отправляют всем по электронной почте, возникает вопрос: насколько реальны указанные сроки? Если, например, не указаны пять самых вероятных рисков и прогнозы по ним, и тот, кто составил график, не может объяснить свои предположения, следует признать, что график возможен, но нереален