После получения иерархической структуры работ необходимо оценить срок выполнения каждого известного на данный момент участка работ. Собственно, ради этого и производится, большей частью, разбиение работ в ИСР. Основные ошибки, которые допускают начинающие руководители проектов, это отстранение исполнителя от оценки сроков и агрессивное расписание.
Во всех учебниках жирным шрифтом написано: для получения надежной оценки по срокам она должна производиться непосредственным исполнителем работ.
Дело в том, что редко случается, чтобы исполнитель делал одну и ту же работу в проекте. Во-первых, это часто невозможно, а во-вторых, людям обычно не нравится однообразная работа. Поэтому редко удается занять одного программиста, скажем, исключительно реализацией доступа к базе данных. Скорее, помимо реализации доступа он будет работать над большим блоком работ, включающем реализацию программного и пользовательского интерфейсов, стресс-тестирования, локументирования и т.п. Степень знаний у программиста в каждой из областей разная — в какой-то области он подготовлен лучше и времени уйдет меньше, а в другой — потребуется дополнительное время на обучение. Никто, кроме самого программиста, не знает о степени его подготовки в той или иной области. А писать будет именно он, и никто другой.
Опять же, во всех учебниках написано: агрессивное расписание — недопустимо. Что такое агрессивное расписание? Это попытка руководителя проекта уменьшить сроки, выданные исполнителем на выполнение работы. Конечно, руководитель проекта поступает так не от врожденной вредности — на него давит свое начальство и требует уменьшить первоначально выданные сроки.
Можно, конечно, поставить жесткие сроки программистам по задачам и наказывать за их неисполнение, но к чему это приведет? К двум вариантам:
Вариант 1: да, программист будет сидеть по 12 часов в день и писать код. Но в этом коде будет масса ошибок, и увеличится время на их исправление, так что в итоге общее количество времени не изменится. Вроде бы на первый взгляд, получается то же самое, но есть сильнейший побочный эффект: демотивация. Программист будет постоянно находиться в состоянии стресса и, в поисках способа выйти из него, начнет искать другую работу. Что вы почувствуете, когда программист, работающий над задачей, стоящей на критическом пути, положит вам на стол заявление об уходе?
Вариант 2: то же самое, только программист будет работать, как обычно, но начнет искать новую работу сразу. При этом уверяя вас, что все будет сделано в срок и будет всяческими хитростями оттягивать этот срок до устройства на другую работу. После чего положит на стол заявление об уходе.
Можно понять желание руководителя проекта не ссориться со своим руководством, но тут уже приходится выбирать из двух зол: либо защищать сроки, выданные исполнителями и показаться неуживчивым в начале проекта, либо сорвать сроки проекта в конце. Второе гораздо хужее — хотя, конечно, это зависит от принятых в организации традиций.
Какие есть способы выхода из данной ситуации? Их несколько:
- Убрать, где возможно, задачи с критического пути. Можно ли начать функциональное тестирование, не дожидаясь окончания написания всего кода? Пускай выдаются ошибки, просто переведите пока их состояние в багтрекере в статус «заморожен».
- Очень часто критический путь удлинняется не из-за необходимой последовательности задач, а из-за нехватки ресурсов и назначения одного человека на выполнение многих задач — потому что не хватает людей. Посмотрите, не тот ли это случай и если так — объясните это своему руководству. Это его проблемы, а не ваши.
- Можно ли добавить в проект людей на критический путь и, тем самым, уменьшить его? Почему нельзя посадить рядом с программистом технического писателя и создавать документацию одновременно с написанием кода? Точно нельзя? Вы уверены? Попробуйте, у меня всегда получалось. Потом, конечно, приходится править и переписывать эту документацию, но это 15-20% от ее объема. К тому же, в процессе документирования технический писатель задает вопросы, от которых качество кода улучшается и меньше приходится его переделывать.
- Можно ли вынести реализацию части содержания в следующую версию продукта? Если поставить руководство перед выбором: сдвинуть сроки или уменьшить содержание, что оно выберет? А маркетологи? Уверен, что оба выберут второе, но попробуйте сами, чтобы убедиться.
Давайте представим, что на все 4 вопроса дан ответ «Нет!». Это сразу переводит проект в разряд высокорисковых и требует специальных мер для снижения общего риска проекта, как это описано у Эдварда Иордона. Он рекомендует предложить заказчику разделить задачи на три группы важности: «необходимо выполнить», «нужно выполнить» и «можно выполнить». Этот прием основывается на принципе Парето 80/20, в нашем случае это звучит как «80% необходимых заказчику функций обеспечиваются 20% функционала программы». Поэтому есть смысл реализовать сразу эти необходимые 20%, и дальше, обезопасив компанию, делать релизы с постепенным добавлением функционала и регрессионным тестированием. Конечно, все три группы задач реализовать таким образом все равно не успеть, но работающий продукт с 50% функционала, поставленный к сроку — это гораздо лучше, чем фраза, сказанная в день, когда запланирована сдача продукта: «К сожалению, сейчас мы не можем вам ничего показать, но через месяц все обязательно будет работать».
В оценке сроков есть одно обстоятельство, играющее отрицательную роль — врожденный оптимизм программистов. Программист может выдать, безо всякого давления, сроки, в которые он не уложится. Не потому, что он переоценил свои силы, а потому, что помимо собственно основной работы есть многое другое — аттестации, написание анкет для отдела кадров, пресейловая активность. Кроме того, люди болеют и имеют желание уходить в отпуска в самый неудобный момент. В реальности, только 60-70% человек тратит непосредственно на работу по проекту.
Для уменьшения влияния этих побочных эффектов при оценке, есть трюк, который позволяет сильно увеличить правильность оценки. Об этом будет сказано позже, когда пойдет речь про оценку рисков.
Николай Бодунов