Сделано
Шрифт:
Самое важное, что я узнал о грамотных прогнозах, – их можно получить только при качественном проектировании и ТЗ. Хорошие технические расчеты зависят от надежной информации и квалифицированных специалистов. Если спецификация никуда не годится, а программиста просят назвать цифры, опираясь на совершенно непонятные каракули на доске, все должны понимать, что получат весьма расплывчатые подсчеты. Проще говоря, прогнозы касаются всех, и команда должна сделать все возможное, чтобы помочь проектировщикам сделать их верными. Если разработка прогнозов кажется тяжелой повинностью или если в этом процессе не участвуют
Если лидеры допускают недостоверные прогнозы в графике и не возражают против высоких рисков, то это не проблема. В небольших, коротких проектах приблизительные прогнозы – как раз то что нужно. Требования часто меняются, а бизнес умеет быть гибким. Нет ничего плохого в некачественных прогнозах, если никто не путает их с качественными.
Я обнаружил один полезный метод: когда программист ворчал, что от него требуют прогнозов по проекту, я спрашивал: «На какие вопросы я могу ответить, чтобы у тебя было больше уверенности относительно сроков?» Направляя разговор к большей конкретике, я давал ему возможность высказать все испытываемые им страхи и недовольства и помогал решить проблему. Конечно, мне приходилось часть работы брать на себя и доказывать, что он выполняет далеко не все свои обязанности, но в любом случае мы обсуждали, как составить надежные прогнозы.
Перечислим еще несколько методов.
• Определить базовые показатели доверия прогнозам. Догадка = 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 .
• Существуют методы построения грамотных прогнозов. Самый известный из них – PERT [29] , который позволяет минимизировать риски, выводя средний показатель по высоким, средним и низким прогнозам. Метод хорош по двум причинам. Во-первых, это заставляет всех осознать, что прогнозы – лишь предварительный диагноз и что результаты могут быть совершенно разными. Во-вторых, это дает менеджеру проекта возможность регулировать агрессивность или консервативность графиков (больше веса можно приписать низким или высоким прогнозам).
29
PERT – Program Evaluation and Review Technique, метод оценки и анализа проектов. Стандартная формула: (оптимистический прогноз + (4 x наиболее вероятный прогноз) + пессимистический прогноз) / 6. Однако существует масса вариаций и теорий о том, как лучше рассчитывать взвешенную оценку.
Хотя надежные прогнозы намного улучшают качество графиков, многие факторы, влияющие на графики, не связаны с самой работой. И получается, что даже если ваши прогнозы по единицам работы идеальны, реальные риски графика связаны с теми факторами, которые нигде не учитываются. Хотя шансы подхватить чуму крайне малы в большинстве стран мира, вероятность того, что главный программист заболеет гриппом или уедет в отпуск, довольно высока. Есть ряд распространенных упущений графика, которые должны знать все менеджеры проекта. Обжегшись на одном упущении, вы захотите отслеживать его в будущем. Вот почему проектный менеджмент – и управление графиком в частности – требуют опыта. Есть масса разных вариантов сесть в лужу и только один способ научиться обходить упущения – нести ответственность за последствия.
Предлагаю личный список вопросов, которые помогли мне предусмотреть потенциальные проблемы графиков на ранних этапах. Чаще всего я спрашивал, что пошло не так, уже после завершения проекта и пытался сформулировать вопрос, который можно было бы задать раньше, чтобы избежать проблемы. (Чего не хватило? Что мы не учли? Что бы изменило ситуацию или позволило бы мне внести коррективы?)
• Учтены в графике больничные и отпуска всех участников процесса?
• Заложены в график сезонные праздники или другие периоды года, когда работа заходит в тупик (например, со Дня благодарения до Рождества в США, лето в Европе)? Важные дедлайны крайне тяжело соблюдать в этот период.