Скотт Беркун - Сделано

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

На этапе проектирования ( глава 5и глава 6) одна из задач команды – разбить проект на небольшие части. Эти части, которые нередко называют элементами (единицами) работы или иерархической структурой работ (work breakdown structure, WBS [26]), становятся пунктами общего графика проекта. Элементы работы (скрестим пальцы) оптимально распределяются [27]среди программистов, затем подсчитывается время на создание каждой из них и выстраивается график. Программист должен выделить каждому элементу работы определенное время и на основе этих прогнозов составить график.

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

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

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

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

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

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

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

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

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

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

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