Шрифт
Source Sans Pro
Размер шрифта
18
Цвет фона
Планирование ориентировано на деятельность, а не на функцию
Критическая проблема традиционных подходов к планированию заключается в том, что они сфокусированы на выполнении той или иной деятельности, а не на поставке функциональности. Диаграмма Гантта для традиционно управляемого проекта, или структура распределения работ, идентифицирует виды деятельности, подлежащие выполнению. Именно по ней мы определяем прогресс команды. Первая проблема планирования по видам деятельности связана с тем, что клиенты не получают никакой стоимости от выполнения видов деятельности. Единицей стоимости для клиента является функция. Планирование, таким образом, должно осуществляться на уровне функций, а не видов деятельности.
Вторая проблема возникает при анализе ранее составленного традиционного календарного графика. Когда мы анализируем календарный график, в котором представлены виды деятельности, наше внимание приковано к поиску пропущенных видов деятельности, а не отсутствующих функций.
Дополнительные проблемы объясняются тем, что планы на основе видов деятельности (процессно-ориентированные планы) зачастую ведут к проектам, которые не укладываются в календарные графики. Сталкиваясь с невозможностью выдержать сроки, заложенные в календарный график, некоторые команды пытаются сэкономить время за счет неуместного снижения качества. Существует также практика принятия политики, которая ограничивает возможности внесения изменений в продукт, в том числе и очень ценных изменений. Вот основные причины, по которым в результате планирования по видам деятельности трудно уложиться в сроки, предусмотренные календарным графиком:
• запланированные работы не завершаются досрочно;
• запаздывание распространяется на последующие этапы календарного графика;
• работы не являются независимыми.
Каждая из этих проблем рассматривается в последующих разделах.
Несколько лет назад я занимался двумя крупными проектами, которые отнимали много времени. Мне нужно было запрограммировать ряд интересных функций для продукта, а также подготовить документацию для аудита соответствия требованиям стандарта ISO 9001. Если программирование доставляло мне удовольствие, то подготовка документов – нет. Неудивительно, что я умудрился раздуть объем программирования так, что оно заняло чуть ли не все мое время и практически вытеснило подготовку к аудиту.
Я вовсе не одинок в таком подходе к работе. Если говорить начистоту, то подобное поведение настолько распространено, что у него есть даже свое название – закон Паркинсона (1993 г.). Этот закон гласит:
«Работа растягивается так, чтобы занять все отведенное на нее время».
Паркинсон говорит, что нам требуется столько времени на завершение какого-либо дела, сколько, на наш взгляд, будет позволено. Если на стене висит диаграмма Гантта, из которой следует, что на тот или иной вид деятельности отведено пять дней, то программист, которому поручена эта работа, будет стараться растянуть удовольствие на полные пять дней. Чтобы избежать досрочного завершения, он может, например, добавить в программу какие-нибудь лишние функции (практика, известная как украшательство). Или может использовать часть времени на изучение какой-нибудь новой технологии, которая, на его взгляд, полезна для дела. Единственное, на что он редко когда идет, так это досрочное завершение работы. Во многих организациях в случае досрочного завершения работы шеф может обвинить исполнителя в предоставлении раздутой оценки. Или, как вариант, шеф станет рассчитывать на досрочное выполнение и других работ. Зачем рисковать и нарываться на то или другое, когда лучше немного побродить по сети и сдать работу в срок?
Пять дней, отведенные в календарном графике на работу, – это, по существу, разрешение разработчику использовать именно столько на выполнение задания. Человеку свойственно при опережении графика заполнять сэкономленное время другими, более интересными для него занятиями.
Поскольку традиционные планы составляются на основе видов деятельности, они по большому счету сфокусированы на взаимозависимости работ. Рассмотрим диаграмму Гантта (рис. 2.1), где представлены четыре вида деятельности и их взаимозависимости.
Для досрочного начала тестирования требуется совпадение следующих событий:
• досрочное завершение программирования среднего уровня, которое зависит от срока завершения добавления таблиц в базу данных;
• досрочное завершение программирования пользовательского интерфейса;
• досрочное высвобождение тестировщика.
Ключевым моментом является то, что даже в этом простом случае досрочное начало тестирования зависит от выполнения всех трех условий. В то же время если для досрочного начала тестирования необходимо выполнение целого ряда условий, то для задержки тестирования достаточно наступления любого из перечисленных ниже событий:
• задержка завершения программирования пользовательского интерфейса;
• программирование среднего уровня требует больше времени, чем планировалось, и завершается позже;
• программирование среднего уровня укладывается в отведенное планом время, но начинается позже из-за задержки добавления таблиц в базу данных;
• недоступность тестировщика.
Другими словами, для досрочного начала необходимо сочетание условий, а для задержки начала достаточно одной причины.
Проблема осложняется тем, что, как мы уже говорили, работы очень редко завершаются досрочно. Это означает, что они обычно начинаются с опозданием и что запаздывание распространяется на последующие этапы календарного графика. Поскольку досрочное завершение – явление редкое, такой вид деятельности, как тестирование на рис. 2.1, начинается досрочно еще реже.
Считается, что работы не зависят друг от друга, если сроки исполнения одной из них не влияют на сроки исполнения другой. При строительстве дома время подготовки котлована для фундамента не зависит от времени, необходимого для покраски стен. Когда работы не зависят друг от друга, задержку окончания одной из них можно компенсировать досрочным завершением другой. Многократное подбрасывание монеты – другой пример независимых видов деятельности. Если при первом подбрасывании выпадает орел, то это никак не влияет на вероятность выпадения орла при втором подбрасывании.
Являются ли работы, производимые в процессе разработки программного обеспечения, независимыми? Могут ли вариации сроков их завершения компенсировать друг друга? К сожалению, нет. Многие виды деятельности, связанные с разработкой программного обеспечения, нельзя считать независимыми. Например, если я пишу клиентскую часть приложения и первый экран отнимает на 50 % больше времени, чем запланировано, высока вероятность того, что каждый из оставшихся экранов также потребует больше времени. Если операции процесса разработки не являются независимыми, то вариации сроков их завершения не компенсируют друг друга.
В типичном плане проекта многие работы не являются независимыми, однако мы снова и снова забываем об этом. Когда кто-то задерживает сдачу первого из нескольких сходных элементов, мы слышим такое оправдание: «Да, я запоздал в этот раз, но дальше отставание будет наверстано». Это следствие надежды на то, что опыт, полученный при выполнении первой работы, позволит завершить оставшиеся работы раньше, чем предусмотрено планом. В реальности же подобная ситуация должна говорить нам, что, если какая-то работа занимает больше времени, чем запланировано, все остальные сходные работы тоже, скорее всего, потребуют больше времени.
