Скотт Беркун – Сделано (страница 8)
Рис. 2.1. Примитивное правило третей в графике проекта
Возьмем, к примеру, гипотетический проект разработки. Если вам дали шесть недель на запуск, то первое, что нужно сделать, – разделить это время примерно на три части и рассчитать, когда работа будет выполнена. Если для ее качественного выполнения времени не хватает, в ваш проект закралась серьезная ошибка. Либо график следует изменить, либо сократить объем работы (или же снизить планку качества). Если урезать время тестирования, то велика вероятность, что время, отложенное на программирование, вы потратите впустую или же такой код будет сложно сопровождать. Правило третей полезно, так как исключает перетягивание каната, свойственное проектам. Чтобы добавить новые функции, нужен не только программист: неизбежны затраты на проектирование и тестирование, которые кому-то придется взять на себя. Обычно проект отстает от графика из-за скрытых или проигнорированных затрат.
Рассмотрим самый простой пример: нет никакого проекта. Вся работа выполняется фрагментарно: поступает запрос или задача, ее оценивают относительно других задач и ставят на ближайшее «окно» графика. Разработчики сайтов и программисты работают именно так. Они редко вкладываются в масштабные задачи. Подобным командам рекомендуются Agile-методы (скоро мы их обсудим) как самая гармоничная система организации работы, потому что они акцентируют внимание на гибкости, простоте и готовности к изменениям. Если вы трудитесь над несколькими небольшими задачами (не проектами) одновременно, вы можете отталкиваться от примеров проектов, которые я привожу в этой книге.
Правило третей применимо к любым ситуациям. Даже если каждый программист работает самостоятельно над небольшими задачами, он, вероятно, тратит примерно треть общего времени на осмысление того, что нужно сделать, еще треть на саму работу и еще треть на проверку корректности результатов. Он может перескакивать с одной задачи на другую каждые несколько минут, но правило третей применимо для общего понимания любой работы и любых масштабов.
В большинстве методологий софтверных разработок явно просматривается правило третей в действии. Конкретные цели и подходы для проектирования или реализации решений могут быть разными, однако в целом желаемые результаты одинаковые.
Ситуация усложняется на масштабных и продолжительных проектах, где графики делятся на небольшие отрезки, внутри каждого из которых выделяются фазы проектирования, реализации и тестирования. Экстремальное программирование называет эти части итерациями; спиральная модель – фазами; а некоторые организации – контрольными точками. Предполагается, что эти отрезки времени занимают всего несколько недель, а спиральная модель уделяет им несколько месяцев, но основная идея неизменна: составить подробные графики по ограниченным периодам времени.
Чем больше изменений ожидается, тем короче каждый этап работы. Это снижает общий риск графика, потому что главный план разделен на контролируемые, посильные части. Перерывы между этапами графика дают возможность внести коррективы и улучшить шансы на то, что на следующем этапе работу удастся срежиссировать более качественно. (Как это сделать, мы обсудим в главе 14.)
Agile и традиционные методы
Экстремальное программирование и другие Agile-подходы предполагают, что будущее всегда изменчиво и непредсказуемо, поэтому они делают ставку на процессы, позволяющие легко изменить направление. Проекты с высокими производственными затратами (например, строительство небоскреба, создание видеоприставки или операционной системы) идут другим путем и вкладывают значительные средства в планирование и проектирование. Это разумно, однако каждый должен воплотить решения, принятые на этапе планирования, и не забывать, что любые изменения связаны с непомерно высокими затратами.
Большинство проектов по разработке находятся примерно посередине. Есть предварительное планирование, однако с учетом изменчивости требований клиентов работа делится на этапы со своими сроками проектирования, реализации и проверки качества. Если возникнет новая проблема, ее можно рассмотреть на текущем этапе работы или отложить в «корзину» и уделить ей внимание уже на следующей фазе.
В большинстве проектов время изначального планирования используется, чтобы получить необходимую информацию от клиентов и бизнес-аналитиков и определить, сколько этапов будет в проекте и чему их посвятить (рис. 2.2): выделить больше времени на проектирование или тестирование, разбить каждый на две небольшие фазы (в соответствии с Agile) или же объединить (монолитный подход). Однако во всех случаях следует предусмотреть время на анализ изменений. Сюда входит решение проблем, которые возникли на предыдущем этапе и им не смогли уделить должного внимания.
Рис. 2.2. Масштабный проект представляет собой последовательность небольших проектов
Вот и все по поводу методологии планирования. В главе 14 и главе 15 мы поговорим о том, как управлять проектом, однако сделаем акцент на функциях менеджера и лидера, а не на подробном применении конкретной методологии. Если вы прочитали последние два параграфа (даже если вы не согласны с моим мнением), то советы из главы 14 и главы 15 будут актуальны и полезны для вас независимо от того, как вы организуете или планируете свой проект.
В любом случае я извиняюсь перед всеми ветеранами разработки, которые потеряли сознание или почувствовали приступ тошноты во время чтения этого раздела. Он закончился, и я обещаю, что этот облегченный и упрощенный подход к графикам – практически все, что нужно для понимания изложенных ниже концепций.
Почему графики срываются
Графики проекта – извечный козел отпущений за все, что может пойти не так. Если кто-то ошибется с расчетом или прогнозом, не выполнит требования, даже если кого-то собьет автобус, – во всем виноват график (и тот, кто за него отвечает). Если электричество отключат во всей стране на десять дней или лучшие программисты команды заразятся чумой, кто-то обязательно скажет: «Вот видите, я же говорил, что график сорвется», – и ткнет пальцем в того, кто его составлял. Это абсолютно несправедливо, но происходит постоянно. Несмотря на всю свою ненависть к графикам, люди предъявляют к ним завышенные требования. Даже лучшие графики в мире, с лучшими умами и лучшими инструментами, – это всего лишь попытка прогнозировать будущее, а человеку она редко удается.
Если команда приступает к проекту, осознавая вероятные причины, по которым график может сорваться, и предпринимает определенные действия, чтобы свести эти риски к минимуму, график станет гораздо более полезным и точным инструментом процесса разработки.
Если график составляется на этапе изначального планирования, сотни решений, которые могут повлиять на него, еще не приняты. Будут трудности и вопросы, которые никто не способен предугадать, и на раннем этапе ориентировочного плана невозможно их учесть. Пока люди не поймут требования и не приступят к проектировке, у менеджера проекта слишком мало информации для реалистичных прогнозов. Однако зачастую черновой график составляют с выдуманными цифрами и совершенно дикими прогнозами, и это «соломенное чучело» вручают команде под видом надежного плана проекта. Его авторы часто становятся жертвами стремления к детализации (вместо того чтобы бросить все силы на достоверность): впечатляющий график с конкретными датами и сроками (детализация) далеко не всегда отражает реальное положение дел (достоверность). Детализация – довольно простая задача, в отличие от достоверности.
Однако все проекты и графики действительно должны с чего-то начинаться. Метод «пальцем в небо» тоже можно использовать – чтобы вдохновить команду и установить определенные границы. Так можно начать процесс анализа и исследования, чтобы конкретизировать график, поднять важные вопросы и ответить на них. Но если в основу графика легли непроверенные и неизученные залихватские предположения, причем без дальнейшей корректировки, вы сильно рискуете. Факты говорят о том, что любому человеку сложно рассчитать необходимое время на раннем этапе проекта.
Барри Боэм в своем эссе 1988 года на тему разработки ПО[23] пришел к выводу, что ошибки графиков растут пропорционально тому, насколько рано сделаны предположения (рис. 2.3). Если общий расчет графика осуществлен рано, он может попасть мимо цели аж на 400 %, причем в обоих направлениях (подозреваю, что ошибки в графике всегда играют против нас, отнимая больше времени, чем мы ожидали). На этапе проектирования, когда многие решения становятся очевидными, диапазон отклонений от графика немного сужается. Только когда проект перейдет в стадию реализации, расчеты становятся обоснованными и реалистичными, но даже тогда остается 20 %-ная вероятность того, что график недостаточно точен.
Рис. 2.3. Диапазон возможных отклонений от сроков проекта (адаптировано из Software Engineering Economics Боэма)
МП должны понимать, что со временем расчет графика становится точнее и обоснованнее. Графики требуют, чтобы на них обращали внимание по ходу работы и вносили корректировки по мере развития проекта.
Когда я работал над своими первыми масштабными проектами после окончания колледжа (Windows и Internet Explorer), кто-то гораздо более авторитетный, чем я, присылал сверху график моей команде. Поскольку я был неопытным новичком и не мог активно участвовать в процессе, мне и небольшому количеству программистов и тестировщиков оставалось только следовать этому «генплану».