Сделано

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

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

СТРЕЛЬБА ВСЛЕПУЮ С ОГРОМНОГО РАССТОЯНИЯ

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

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

Барри Боэм в своем эссе 1988 года на тему разработки ПО[23 - “Understanding and Controlling Software Costs,” IEEE Transactions on Software Engineering, vol. 14, no. 10, October 1988, pp.1462–77; а также Barry Boehm Software Engineering Economics (Prentice Hall, 1991).] пришел к выводу, что ошибки графиков растут пропорционально тому, насколько рано сделаны предположения (рис. 2.3). Если общий расчет графика осуществлен рано, он может попасть мимо цели аж на 400 %, причем в обоих направлениях (подозреваю, что ошибки в графике всегда играют против нас, отнимая больше времени, чем мы ожидали). На этапе проектирования, когда многие решения становятся очевидными, диапазон отклонений от графика немного сужается. Только когда проект перейдет в стадию реализации, расчеты становятся обоснованными и реалистичными, но даже тогда остается 20 %-ная вероятность того, что график недостаточно точен.

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

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

ГРАФИК – ЭТО ВЕРОЯТНОСТЬ

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

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

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

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

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

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

ДЕЛАТЬ ПРОГНОЗЫ СЛОЖНО

На этапе проектирования (глава 5 (#litres_trial_promo) и глава 6 (#litres_trial_promo)) одна из задач команды – разбить проект на небольшие части. Эти части, которые нередко называют элементами (единицами) работы или иерархической структурой работ (work breakdown structure, WBS[26 - Многие учебники и руководства описывают, как выстроить структуру разделенной работы. Я коснусь этой темы в главе 14, однако если вы хотите получить более подробную информацию, начните с http://en.wikipedia.org/wiki/Work_breakdown_structure (http://en.wikipedia.org/wiki/Work_breakdown_structure) или Total Project Control, Stephen Devaux (Wiley, 1999).]), становятся пунктами общего графика проекта. Элементы работы (скрестим пальцы) оптимально распределяются[27 - В книге Кента Бека Extreme Programming Explained (Addison-Wesley, 1999) (Бек К. Экстремальное программирование. Разработка через тестирование. СПб.: Питер, 2017) предлагается модель распределения работы для программистов, где они сами выбирают рабочие единицы. В идеале это решение – компромисс между благом проекта и благом членов команды.] среди программистов, затем подсчитывается время на создание каждой из них и выстраивается график. Программист должен выделить каждому элементу работы определенное время и на основе этих прогнозов составить график.

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

Мир основан на прогнозах

Прогнозы – задача непростая, поскольку мало кому нравится рассчитывать сложные вещи, да еще нести за это ответственность. Намного приятнее хвастаться своими способностями («Эта книга, фильм или сайт отстой: я бы сделал намнооооого лучше!»), но когда требуется взять дело в свои руки и выдать результат – поставить подпись на договоре с подробным перечнем наших обязанностей, – все меняется. Как известно, что бы мы ни пообещали сделать, в момент выполнения обещания все покажется невозможным и нежелательным. Ситуация грозит оказаться намного сложнее, чем мы думали. Программисты похожи на всех остальных людей и вполне оправданно боятся делать какие-либо прогнозы. Если они скажут, что задачу можно выполнить за определенное время, то рискуют сесть в лужу.

Как показывает мой опыт, даже те, кто понимает процесс прогнозирования и верит в него, не любят этим заниматься. Отчасти из-за нестыковки предположений («Как же это сделать, если у меня так мало информации?») с временными рамками («Скажите точно, сколько часов займет эта работа»). Однако никаких поблажек быть не должно: все, кто работает в проектировании и строительстве, решают примерно одинаковые «головоломки», будь то строительство небоскреба, ремонт кухни или запуск космического корабля на другие планеты. Если почитать, как все эти люди делают прогнозы, то вы увидите, что их проблемы и методы не слишком отличаются от сфер разработки или программного обеспечения. Основное отличие в том, сколько времени им дают на расчеты и насколько дисциплинированно они его распределяют (мы обсудим это подробнее в главе 5 (#litres_trial_promo) и главе 6 (#litres_trial_promo)).

ГРАМОТНЫЕ ПРОГНОЗЫ ЗАВИСЯТ ОТ КАЧЕСТВЕННОГО ПРОЕКТИРОВАНИЯ

Самое важное, что я узнал о грамотных прогнозах, – их можно получить только при качественном проектировании и ТЗ. Хорошие технические расчеты зависят от надежной информации и квалифицированных специалистов. Если спецификация никуда не годится, а программиста просят назвать цифры, опираясь на совершенно непонятные каракули на доске, все должны понимать, что получат весьма расплывчатые подсчеты. Проще говоря, прогнозы касаются всех, и команда должна сделать все возможное, чтобы помочь проектировщикам сделать их верными. Если разработка прогнозов кажется тяжелой повинностью или если в этом процессе не участвуют тимлиды, не ожидайте ничего надежного и правдоподобного.

Если лидеры допускают недостоверные прогнозы в графике и не возражают против высоких рисков, то это не проблема. В небольших, коротких проектах приблизительные прогнозы – как раз то что нужно. Требования часто меняются, а бизнес умеет быть гибким. Нет ничего плохого в некачественных прогнозах, если никто не путает их с качественными.

Я обнаружил один полезный метод: когда программист ворчал, что от него требуют прогнозов по проекту, я спрашивал: «На какие вопросы я могу ответить, чтобы у тебя было больше уверенности относительно сроков?» Направляя разговор к большей конкретике, я давал ему возможность высказать все испытываемые им страхи и недовольства и помогал решить проблему. Конечно, мне приходилось часть работы брать на себя и доказывать, что он выполняет далеко не все свои обязанности, но в любом случае мы обсуждали, как составить надежные прогнозы.

Перечислим еще несколько методов.

• Определить базовые показатели доверия прогнозам. Догадка = 40 % доверия. Обоснованный расчет = 70 %. Детальный и тщательный анализ = 90 %. Лидеры команды должны согласовать, какая точность им нужна, сколько времени они дают программистам на ее расчеты и как справиться с рисками, если прогнозы не оправдаются. Не зацикливайтесь на цифрах: используйте их просто для того, чтобы четко обозначить качество прогнозов. Доверие на уровне 90 % означает, что прогнозы оправдываются в 9 случаях из 10. Если вы решили попросить команду улучшить качество прогнозов, то нужно дать ей больше времени.

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

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

• Прогнозы зависят от того, насколько хорошо программист понимает цели проекта. Прогнозы строятся на том, как программист интерпретирует спецификации (если они есть), а также цели и задачи проекта. В своей книге «Психология программирования» (The Psychology of Computer Programming) (Dorset House, 1971) Джеральд Вайнберг показывает, как отсутствие понимания основных целей напрямую воздействует на предположения программистов. Даже если технологическая задача предельно ясна, подход программиста к ее решению может значительно измениться в зависимости от общего направления всего проекта.

• Прогнозы должны опираться на предыдущие результаты работы. Хорошая привычка для программистов – отслеживать свои прогнозы по проектам. Им следует обсуждать это со своим менеджером, который должен стремиться понять, кто в его команде делает грамотный «мониторинг». Экстремальное программирование использует термин производительность, когда речь идет о вероятных результатах работы программистов (или команды) в зависимости от их предыдущих результатов[28 - См. Kent Beck and Martin Fowler, Planning Extreme Programming (Addison-Wesley, 2002) (Бек К., Фаулер М. Экстремальное программирование. Планирование. СПб.: Питер, 2003), pp. 60–62.].

• Качество спецификаций и проектирования диктует, насколько точными должны быть прогнозы технических специалистов. Это обсуждается между менеджерами проекта и программистами. Чем выше требования по прогнозам, тем выше должно быть качество спецификаций. Подробнее о спецификациях мы поговорим в главе 7 (#litres_trial_promo).

• Существуют методы построения грамотных прогнозов. Самый известный из них – PERT[29 - PERT – Program Evaluation and Review Technique, метод оценки и анализа проектов. Стандартная формула: (оптимистический прогноз + (4 ? наиболее вероятный прогноз) + пессимистический прогноз) / 6. Однако существует масса вариаций и теорий о том, как лучше рассчитывать взвешенную оценку.], который позволяет минимизировать риски, выводя средний показатель по высоким, средним и низким прогнозам. Метод хорош по двум причинам. Во-первых, это заставляет всех осознать, что прогнозы – лишь предварительный диагноз и что результаты могут быть совершенно разными. Во-вторых, это дает менеджеру проекта возможность регулировать агрессивность или консервативность графиков (больше веса можно приписать низким или высоким прогнозам).

САМЫЕ ЧАСТЫЕ УПУЩЕНИЯ

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

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

• Учтены в графике больничные и отпуска всех участников процесса?

• Заложены в график сезонные праздники или другие периоды года, когда работа заходит в тупик (например, со Дня благодарения до Рождества в США, лето в Европе)? Важные дедлайны крайне тяжело соблюдать в этот период.

• Был ли доступ к графику у членов команды? Просили ли их регулярно отчитываться о проделанной работе (не вызывая при этом раздражения)?

• Кто-нибудь следил за общим графиком ежедневно или еженедельно? Было ли у этого человека достаточно полномочий, чтобы задавать грамотные вопросы и вносить коррективы?

• Проявляла ли команда интерес к графику? Если нет, то почему? Участвовала ли она в построении графика и выборе задач, которые следует выполнить, или график спустили сверху?

• Лидеры команды добавили больше функций или помогли убрать больше функций? Лидеры команды когда-нибудь говорят «нет» на новые задачи и дают разумные указания команде о том, как отвечать на новые (поздние) задачи?

• Членов команды поощряют отказываться от новой работы, которая не вписывается в задачи и видение проекта?

• Какой процент вероятности был использован в прогнозах – 90 %, 70 %, 50 %? Это было отражено в общем графике? Клиент или вице-президент учитывали это? Обсуждались ли другие предложения, которые заняли бы больше времени, но имели более высокую вероятность?

• Выделено в графике время для его корректировки и дискуссий между лидерами и менеджерами?

• Учитывал ли график сокращение рабочих часов во время праздников? Внесены в график потенциально опасные погодные изменения?

• Были ли достаточно качественными спецификации и план проекта, чтобы разработчики сделали на их основе грамотные прогнозы?

• Обладают ли специалисты, осуществляющие расчет, должной подготовкой и опытом?