Правильная ссылка на эту страницу
http://az-design.ru/Projects/AzBook/src/004/02MS0200.shtml

Глава 2. Правда о календарных планах

       Людям свойственно опаздывать. Они часто выбиваются из повседневного графика, пусть всего на несколько минут или пару раз в неделю. (Поскольку возражать люди научились ничуть не хуже, я пойму, если вы откажетесь принимать это утверждение на свой счет.) Студенты опаздывают на занятия, сотрудники — на рабочие совещания, а друзья приходят в бар на десять минут позже назначенного времени. Мы считаем, что понятие “вовремя” относится не к конкретному моменту, а к какому-то интервалу времени, который может быть для кого-то шире, чем для всех остальных. Характерный пример — старшие официанты. Они вас уверяют, что столик вот-вот будет готов, но при этом зачастую заставляют ждать значительно дольше объявленного1 {Как-то в Питтсбурге мы с приятелями зашли пообедать в пиццерию и получили заверение, что столик будет готов через десять минут. Ровно через десять минут мой друг Чад МакДаниел поинтересовался готовностью столика и получил ответ распорядителя, что все будет готово через десять минут. Тогда он спросил: “Это те же десять минут или другие десять минут?” — но его шутку должным образом так и не оценили.}. Существует множество ситуаций, при которых приходится выбиваться из рабочего графика, сюда можно отнести долгие ожидания у телефонной трубки или очереди на прием к врачу. Такие ситуации заставляют скептически относиться к затее планирования рабочего времени, противоречащей нашему жизненному опыту.
       Стоит ли при этом удивляться, что масса проектов не выдерживаются по срокам их реализации. Многие из нас подходят к их планированию с наихудшими представлениями о своевременности поставок или получений каких-либо компонентов. Мы склонны делать оценки на основе смутных предположений, предсказывая результаты работы, исходя из благоприятного стечения обстоятельств, и в то же время с учетом предыдущего опыта не очень-то доверяем тем графикам, которые просматриваем или сами создаем. Данная глава посвящена ответам на вопросы, почему мы так поступаем, как это влияет на календарные планы проектов и как все-таки избавиться от обозначенных проблем.
       Но перед тем как искать способы составления совершенных календарных планов, мы должны понять, какие именно проблемы решаются с их помощью. Если они столь ненадежны, стоит ли вообще тратить время на их создание? Календарные планы служат нескольким различным целям, лишь некоторые из них непосредственно связаны с фактором времени.

Три цели составления календарных планов

       Что бы вы ни планировали, субботнюю вечеринку или обновление корпоративного сайта, все планы подчинены достижению трех целей. Первая — это определение сроков выполнения. Календарный план предоставляет контракт, связывающий всех участников, подтверждающий вклад каждого специалиста в общее дело, который он намерен внести за определенный период времени. Обычно при обдумывании плана реализации проекта — это первое, что приходит в голову. Планы часто ориентированы не на внутренние, а на внешние по отношению к команде разработчиков факторы, поскольку нацелены на выполнение контракта в соответствии со сроками заказчика. Зачастую клиенты платят не только за сам заказ, но и отдельно за срочность его выполнения (представьте работу почтовых служб). Чтобы предоставить возможность клиентам или партнерам строить планы относительно конкретного проекта, надо согласовать временные параметры по этапам его реализации.
       Вторая цель разработки календарного плана заключается в том, чтобы помочь каждому участнику проекта увидеть свою роль в общей работе и способствовать координации усилий отдельного участника и остальных членов проекта. Пока план носит предварительный характер и содержит лишь наметки сроков поэтапной реализации проекта, маловероятно, что в нем удастся учесть все связи и взаимозависимости. Без календарного плана каждый будет сконцентрирован на выполнении своих собственных задач и не будет думать о том, как его работа повлияет на работу других.
       И только после указания всех деталей с указанием следом за ними исполнителей появится возможность провести реальные расчеты и исследовать допущения. Это справедливо даже для небольших коллективов или отдельных разработчиков. Календарный план оказывает психологическое влияние, поскольку с его помощью оглашаются взятые обязательства. Совсем не просто забыть или проигнорировать то, что вывешено на всеобщее обозрение, напоминая команде о том, что должно быть сделано. Для руководителей проекта существенно и следующее обстоятельство: когда обнародован проект календарного плана, могут быть подняты вопросы о реалистичности некоторых его разделов и может быть сопоставлен объем работ по проекту с тем, что возможно выполнить на самом деле.
       Такой психологический способ называется функцией принуждения. К этой функции относится все, что при вступлении в силу естественным образом вызывает изменения во взглядах, отношении или поведении. Поэтому календарные планы являются функциями принуждения, играющими существенную роль в реализации проектов. Если руководитель проекта будет использовать их должным образом, то каждый, чья деятельность нашла в них отражение, будет вынужден тщательно продумывать возложенную на него работу. Эта функция принуждения является решающим фактором реализации потенциала проекта. Даже если календарный план не выдерживается, удваивается по времени или сокращается вдвое, все обязательства и связи, принятые всеми при его предварительной проработке, могут соблюдаться. Итак, вторая цель создания календарного плана может быть достигнута и сможет полностью оправдать усилия, затраченные на его составление, даже если в нем будут допущены существенные неточности. Например, если проект завершается со значительным опозданием, наличие календарного плана все равно позволит завершить работу над этим проектом.
       Третья цель разработки календарных планов состоит в предоставлении команде средства, позволяющего контролировать ход работы и разбить ее на поддающиеся управлению этапы. Разбиение работы на одно- или двухдневные задания помогает исполнителям осознать объем предстоящих работ. Вообразите, что при строительстве дома бригадир определил задание одной строкой: “Построить дом за 120 дней”. При такой “степени детализации” всем, включая и самого бригадира, будет довольно трудно понять, что нужно делать. Но если строитель сможет предоставить объемы работ по неделям, каждый сможет понять, когда и какие задания будут выполняться, в чем заключаются приоритеты, и задать более целенаправленные вопросы и уяснить принимаемые им обязательства. С точки зрения руководителя проекта качественно составленный календарный план дает более понятное видение проекта, на ранней стадии рассеивает претензии, сглаживает оплошности и повышает шансы на благоприятный исход.
       С ростом масштабности и сложности проекта возрастает и роль календарных планов. В больших проектах усиливается взаимозависимость исполнителей, а при выборе решений и сроков повышается вероятность влияния на других людей. Если у вас всего несколько сотрудников, работающих в небольшой команде, то шансы выявить проблемы в работе друг друга намного выше. Ошибки в планировании работ плохо воспринимаются даже в небольшой команде, но в этом случае потерянные полдня компенсируются ударным трудом трех человек в течение того же времени, позволяя наверстать упущенное. Кто-то может задержаться на работе или, если надо, вся команда может сплотиться и помочь отставшим войти в график. При работе над более объемным проектом с привлечением десятков и сотен сотрудников утраченные сутки могут привести к “эффекту домино” и возникновению различных проблем в самых непредвиденных ситуациях, справиться с которыми силами одной команды порой невозможно. Но при любой команде, большой или маленькой, календарные планы дают возможность руководителям и финансистам проекта ставить вопросы, вносить поправки и оказывать помощь команде разработчиков, выявляя возникающие проблемы и оперативно реагируя на них.
       Осознавая эти три цели, нетрудно заметить, что даже самые совершенные календарные планы не решают всех проблем проекта. Планы не могут исправить неудачный проект или его техническое воплощение, не могут защитить проект от слабого руководителя, нечетко сформулированных целей и плохо организованного взаимодействия. Поэтому, сколько бы времени не было затрачено на создание календарных планов, они все равно останутся лишь набором слов и цифр. А вот будут ли они использованы в качестве инструмента управления проектом для его успешного продвижения — зависит от конкретных людей. Осознавая это, пора вытащить толстое руководство и на примере создания программных продуктов исследовать тяжеловесные методологии управления проектами.

Решающие факторы и методологии

       Существует множество различных систем планирования и управления, ориентированных на разработку программного обеспечения. Эти системы часто называют методологиями, то есть наборами методов, направленных на достижение конечного результата в конкретной области. Среди основных методологий разработки программных продуктов можно отметить водопадную и спиральную модели, ускоренную разработку приложений, экстремальное программирование и функционально-ориентированную разработку1 {В оригинале “Feature-driven development”. — Примеч. ред.}. Все эти методологии призваны решать сходные проблемы организации и управления проектами. У каждой из них есть свои сильные и слабые стороны, и чтобы решить, какая именно методология подходит для тех или иных проектов, нужно обладать достаточными знаниями и опытом.
       Однако целью главы, да и всей книги, не является сравнение различных методологий. Я полагаю, что есть концепции, положенные в их основу, и именно ими нужно овладеть, дабы добиться успеха при использовании любой методологии. Во всех случаях методологии нуждаются в корректировке и адаптации под особенности команды и проекта, а такая адаптация возможна только при наличии базовых знаний, более глубоких, чем знание самих методологий. Итак, если вы сможете воспринять и применить основополагающие идеи, рассматриваемые в данной главе и во всей остальной книге, то независимо от применяемой методологии ваши шансы на успех возрастут. Я намерен объяснить аспекты некоторых методов, по мере необходимости прояснения некоторых вопросов, но если вы коллекционируете информацию о методологиях, лучше обратиться к другим источникам2 {Сравнительное обсуждение традиционных и гибких методов разработки программныхсредств вы сможете найти в книге Барри Боэма (Barry Boehm) и Ричарда Тернера (Richard Turner) “Balancing Agility and Discipline: A Guide for the Perplexed” (Addison Wesley,2003).}.
       При всей своей важности для разработки программных средств методы не являются решающими факторами. Нет ничего хуже, чем слепо следовать наборам абсолютно несостоятельных правил только потому, что они изложены в популярных книгах или проповедуются многоуважаемыми гуру. Очень часто я убеждаюсь, что одержимость процессом — весьма тревожный знак, свидетельствующий о затруднениях в руководстве: это может быть попыткой переложить обычные проблемы и ответственность, с которыми сталкиваются руководители, на систему процедур и бюрократических приемов, подменяющих необходимость осмысленных руководящих действий. Возможно, намного более пагубным для команды разработчиков может стать пристрастие к методологии, которой в организации отводится чуть ли не первостепенная роль. Том Демарко (Tom DeMarco) в своей книге “PeopleWare” (Dorset House, 1999) (“Человеческий фактор в программировании”) отмечал:
       Навязчивая идея применения методологий на рабочем месте — еще один пример высокотехнологичной иллюзии. Она берет начало из веры в то, что технология — это единственное, что на самом деле имеет значение... Какими бы ни были технологические преимущества, они могут быть получены только за счет существенного ухудшения социального климата в команде разработчиков.
       Сосредоточенность на приемах и методах, подменяющая организацию процесса, направленного на поддержку человеческого фактора, приводит к тому, что планирование проектов начинается с наложения ограничений на вклад каждого из участников в его реализацию. При этом может быть установлена уйма правил и инструкций, вместо того чтобы подумать о корректировке или совершенствовании этих правил. Поэтому будьте очень осторожны в применении любой методологии: она не должна подавлять инициативу команды1 {Информацию об определениях и понятиях изменений процесса разработки программного обеспечения, а также об управлении этими изменениями можно найти в книге Уоттса С. Хамфри (Watts S. Humphrey) “Managing the Software Process” (Addison Wesley Professional, January 1989).}. Наоборот, она должна стать средством поддержки, стимуляции и помощи команде в продуктивной работе (советы по организации процессов см. в главе 10).
       Использование конкретной методологии не может быть единственной причиной своевременного или несвоевременного завершения проекта. Существуют факторы, воздействующие на все проекты, и руководители проектов должны в них разобраться до того, как приступать к любой работе по составлению календарных планов. Но перед тем как говорить об этом, нужно поговорить о составляющих календарного плана.

На что похож календарный план

       Существует одно основное правило составления всех календарных планов — так называемое “правило трех частей”. При всей его приблизительности и упрощенности оно предлагает самый простой подход к пониманию сути календарных планов. Если у вас уже есть опыт составления календарных планов, то немного потерпите, поскольку я представлю весь процесс в слишком упрощенном виде. Это делается, чтобы заложить элементарную основу для объяснения, что может не получиться, почему это может произойти и как с этим справиться.
       Правило трех частей работает следующим образом: все отпущенное время разбивается на три части: проектирование, разработку и тестирование. В зависимости от используемой вами методологии эти части могут называться по-другому, но во всех методологиях предусматривается выделение времени на реализацию этих трех этапов. В любой конкретный день или час вы либо определяете то, что должно быть сделано (проектируете), либо фактически создаете продукт (пишите программный код), либо проверяете, анализируете и совершенствуете сделанное (проводите тестирование).
       В соответствии с правилом, на каждый день, отводимый на разработку программного кода, выделяется день на планирование и проектирование и день на проверку и доводку сделанного (рис. 2.1). Вряд ли что-нибудь еще может быть проще — перед вами простой механизм проверки любых существующих календарных планов или создания календарного плана “с нуля”. Если все отведенное на реализацию проекта время не разделено приблизительно на три равных этапа работы, должны быть вполне объяснимые причины, почему проекту требуется неравномерное распределение усилий. Если позволяют сроки, правило трех частей допускает некоторый дисбаланс, при котором считается нормальным отводить на тестирование на двадцать и более процентов времени больше, чем на разработку.


Рис. 2.1. Простейшая схема календарного плана, созданного по правилу трех частей

       Рассмотрим гипотетический проект разработки веб-сайта: если вам на его запуск отвели шесть недель, то первым шагом должно стать деление этого времени приблизительно на три части и на основе полученного результата вычисление времени завершения работы. Если оказывается, что времени на работу с ожидаемым высоким уровнем качества не хватает, значит, что-то в корне неправильно. Надо либо менять календарный план, либо сокращать предполагаемый объем работ (или снижать ожидаемое качество). Выкраивание времени за счет тестирования всего лишь увеличит шансы на то, что время, потраченное на написание кода, уйдет впустую, или будет получен код, малоприспособленный для управления и поддержки. Правило трех частей полезно тем, что заставляет выявить ситуацию, при которой выигрывая в одном, проигрываешь в другом. Добавление новых возможностей выливается не только в дополнительную работу программиста по их реализации, но и влечет за собой неизбежные издержки на проектирование и тестирование, на которые кто-то должен идти. Когда календарный план срывается, причина заключается в неучтенных скрытых или проигнорированных издержках.

Разработка по частям (беспроектный проект)

       Стоит рассмотреть и самый простой вариант: отсутствие проекта как такового. Вся работа делается по мере поступления заказов, которые сравниваются по объему с другой работой и включаются в следующее свободное место календарного плана. Некоторые команды разработчиков, создатели веб-сайтов или отделы программирования информационных систем часто именно таким образом и действуют. Эти организации редко вкладывают деньги в крупные проекты или вообще за них не берутся. Гибкие методы (которые будут вскоре рассмотрены) в силу присущей им возможности перенаправления усилий, простоте и ожидае-мости изменений часто рекомендуются таким командам в качестве наиболее естественной системы организации работы. Если вы работаете сразу над несколькими мелкими заданиями (не проектами), вам придется экстраполировать приводимые в данной книге примеры, ориентированные исключительно на проекты.
       И все же правило трех частей применимо и к этим ситуациям. Даже если каждый программист работает в одиночку над выполнением мелких заданий, он, вероятнее всего, затрачивает примерно одну треть общего времени на разработку алгоритма, одну треть — на его реализацию и одну треть — на проверку и отладку. Он может перескакивать по этим этапам взад и вперед каждые несколько минут, но для упрощенного понимания работы какой бы то ни было разновидности правило трех частей применимо для любого масштаба.

Разделяй и властвуй (большие планы равны множеству мелких)

       Изучая большинство методологий разработки программного продукта, вы можете обнаружить, что в их основу заложено правило трех частей. Преследуемые при проектировании или разработке конкретные цели и используемые подходы могут существенно различаться, но желаемые результаты на самом высоком уровне схожи.
       Там, где проекты усложняются из-за своей объемности или продолжительности, календарные планы делятся на части, каждая из которых имеет собственные периоды проектирования, разработки и тестирования. В экстремальном программировании (Extreme Programming, XP) такие части называются итерациями, в спиральной модели — фазами, а в некоторых организациях их называют этапами. Хотя в ХР считается, что эти отрезки времени занимают всего несколько недель, а в спиральной модели счет идет на месяцы, в них заложена одна и та же фундаментальная идея: создание подробных календарных планов для ограниченных периодов времени.
       Чем больше ожидаемых изменений и проектных отклонений, тем короче должен быть каждый этап. Таким образом снижается степень суммарного риска, связанного с выполнением календарного плана, поскольку общий план оказывается поделенным на управляемые фрагменты. Такое деление календарного плана на этапы предоставляет естественную возможность вносить коррективы и повышает шансы на более четкую организацию работ на следующем этапе. (О том, как это делается, рассказывается в главе 14.)

Гибкий и традиционный методы

       Экстремальное программирование и другие гибкие методы предполагают, что будущее всегда изменчиво, поэтому они делают ставку на процессы, включающие естественные изменения направления. Дорогостоящие проекты (скажем, строительство небоскреба, создание игровой видеоприставки или встроенной операционной системы) реализуются по-другому и предполагают большие затраты на планирование и проектирование. При реализации проекта каждый должен следовать решениям, принятым в процессе проектирования, а непомерно высокая стоимость внесения изменений приводит к единственно возможному пути реализации.
       Большинство проектов по разработке программных продуктов представляют собой нечто среднее. В них присутствует некое первичное планирование, но для того чтобы справиться с будущими изменениями требований и желаний заказчиков, работа делится на фазы, в которых время распределяется на проектирование, разработку и проверку качества. Если возникают новые проблемы, их можно решить в течение текущей фазы или поместить в очередь работ для более тщательной проработки и осмысления в следующей фазе.
       В большинстве проектов время, отведенное на первичное планирование, тратится на сбор от заказчиков и бизнесменов информации, достаточной для определения требуемого количества фаз, сути и содержания каждой из них (рис. 2.2). В зависимости от общего плана в каждой фазе может быть отведено больше времени на проектирование или тестирование. Фаза может быть разбита на две меньшие (делая стиль разработки более гибким) или две фазы могут быть совмещены (разработка становится более цельной). Но в любом случае время должно распределяться между фазами таким образом, чтобы можно было воспользоваться преимуществом от проводимых изменений. Сюда включается и реакция на проблемы, возникшие в течение предыдущей фазы, заняться которыми в ходе этой фазы не представилось возможным.
       Все это я объясняю, собираясь перейти к методологии создания календарного плана высшего уровня. В главах 14 и 15 рассматривается порядок управления проектом на протяжении выполнения всего календарного плана, но в них обращается внимание на перспективы управления и руководства, а не на детали применения конкретной методологии. Если вы смогли усвоить материал нескольких последних разделов (даже если вы не совсем согласны с изложенной в них точкой зрения), советы, излагаемые в главах 14 и 15, будут уместны и полезны независимо от того, как вы организовали или спланировали свой проект.


Рис. 2.2. Большой проект должен представлять собой последовательность более мелких проектов

       Так или иначе, я прошу прощения у всех опытных разработчиков, почувствовавших недомогание при чтении данного раздела или вовсе лишившихся чувств. Заканчивая его, я обещаю, что подобный облегченный и упрощенный взгляд на планирование — это практически все, что вам понадобится, чтобы усвоить понятия, излагаемые в оставшейся части главы.

Почему рушатся планы

       Как только что-нибудь идет не так, обычно винят во всем календарный план проекта. Если кто-нибудь допускает просчет, не выполняет требование или попадает под автобус, критике подвергается календарный план (или сотрудник, ответственный за его разработку). Если электрические сети страны выходили из строя на десять дней или лучшие программисты команды становились жертвами эпидемии, обязательно кто-нибудь скажет: “Я же говорил, что план провалится” — и погрозит планировщику пальцем. С тех пор как люди следуют планам, они задирают вверх планку на недосягаемую высоту. Самые лучшие в мире планировщики, с самими светлыми головами, имеющие в своем распоряжении самые лучшие инструменты, все еще пытаются каким-то образом предсказать будущее, но человеку редко удается достичь высот в этом деле.
       Однако если команда приступает к проекту, всецело осознавая возможные причины, по которым план может провалиться, и предпринимает некоторые меры для минимизации подобного риска, календарный план может стать весьма полезным и точным инструментом создания программного продукта.

Выстрел вслепую издалека

       Если календарный план создан в период первичного планирования, то должны быть приняты сотни решений, способные на него повлиять. Будут возникать проблемы и сложности, которые никто не в состоянии предвидеть, поскольку способов, позволяющих принять их во внимание на ранней стадии теоретического планирования, попросту не существует. До тех пор пока не будут осмыслены требования и не пойдет полным ходом проектирование высокого уровня, руководитель проекта обладает слишком скудной информацией для построения реалистичных прогнозов. Кроме того, довольно часто черновой календарный план создается с вымышленными цифрами и грубыми допущениями, и этот муляж вручается команде под видом правдоподобного плана реализации проекта. Зачастую люди попадают в ловушку, где точность подменена подробностью описания. Впечатляющий календарный план с определенными датами и сроками (подробность) совсем не обязательно отражает реальность (точность). Проще достичь подробности, точность дается намного сложнее.
       Тем не менее рано или поздно все проекты и их планы должны быть запущены в дело. Этот “выстрел в тумане” может быть использован для мобилизации команды и расстановки некоторых границ. Он может инициировать процесс исследования с целью конкретизировать календарные планы, поставить важные вопросы и найти на них ответы. Но если в основу календарного плана легли непроверенные и неисследованные поверхностные предположения, к тому же не подвергающиеся дальнейшему уточнению, степень риска весьма высока. Совершенно очевидно, что в начале проекта оценить требуемое время не под силу никому.
       Барри Боэм (Barry Boehm) в 1988 году в своем эссе на тему разработки программных продуктов1 {“Understanding and Controlling Software Costs”, IEEE Transactions on Software Engineering, т. 14, № 10, октябрь 1988, стр. 1462-77; а также книга “Software Engineering Economics” (Prentice Hall, 1991).} писал, что ошибки тем масштабнее, чем раньше при реализации проекта делались расчеты для календарного плана (рис. 2.3). Если все расчеты делались на ранней стадии, отклонения могут составлять до 400 % в обоих направлениях (подозреваю, что ошибки всегда работают против нас, стремясь отнять больше времени, чем мы ожидаем, хотя Боэм в своих данных этого не показал). В период проектирования по мере конкретизации решений расхождение сокращается, но остается еще весьма значительным. И только когда проект достигает стадии реализации, диапазон расчетов календарного плана приобретает разумные очертания, но даже тогда остается 20-процентный разброс вероятности планирования.


Рис. 2.3. Диапазон возможных отклонений от расчетных сроков в процессе реализации проекта (заимствовано из книги Боэма “Software Engineering Economics”)

       То есть руководители проектов должны усвоить, что расчеты для календарного плана со временем становятся точнее. Календарные планы требуют внимания в ходе реализации проекта и корректировки по мере его продвижения.

Календарный план — это оценка вероятности

       Когда я выпустился из университета и работал над своими первыми крупными проектами (Windows и Internet Explorer), то общий календарный план моей команде должен был представлять кто-то поважнее меня. Поскольку я был слишком молод, чтобы в достаточной степени быть причастным к процессу, в мои обязанности после получения календарного плана входило применение этого главного расписания к деятельности небольшого коллектива программистов и тестировшиков, с которыми я работал.
       Когда мы обсуждали, в чем состоит разница между этим главным планом и календарным планом, созданным моей командой на основе списка работ1 {Календарные планы, основанные на имеющихся работах, называются восходящими, потому что они создаются командой, а календарные планы, основанные на потребностях управления, — нисходящими. Обычно разногласия между ними согласовываются.}, главный план казался нам высосанным из пальца. Он был спущен сверху, аккуратно отформатирован, разбит на красивые столбцы из дат и чисел, но при этом казался чем-то искусственным, украденным из будущего.
       При всей своей циничности, мы в основном точно придерживались этих календарных планов. Несмотря на тайну их происхождения, у нас было достаточно оснований доверять своим начальникам, и мы были настолько загружены собственной работой, что особо не переживали за то, что делали они. (В действительности они довольно часто предоставляли элементарные разъяснения для этих первичных спускаемых вниз календарных планов, но мы были настолько заняты и настолько им доверяли, что особого внимания на эти разъяснения не обращали.) Позже, когда планирование стало частью моих обязанностей, я понял, в чем состоит невысказанная правда об этих планах. Они не были подарком из будущего. Для составления совершенных календарных планов не существует ни магических формул, ни особой науки. Вопреки моему юношескому восприятию, планирование не было изолированной задачей: оно всегда представляло и охватывало множество различных аспектов настоящего и будущего проекта. Планы являются простой формой предсказания. И неважно, насколько пунктуально они составлены или насколько убедительно выглядят — по сути, это всего лишь сборник множества мелких расчетов, каждый из которых невозможно избавить от различных непредвиденных упущений и неточностей. Хорошие планы получаются только у тех руководителей или команд, которые неуклонно ищут и достигают разумных оценок различных аспектов разработки программных продуктов. Нельзя быть узким специалистом и ожидать при этом, что когда-либо вам удастся создать хороший календарный план.
       Итак, если все в команде согласны, что календарный план — это набор возможных значений, значит, проблема не в самом плане, а в том, как он используется. Если когда-либо календарный план доводится на совещании команды или рассылается по электронной почте, возникает резонный вопрос: какова вероятность соблюдения приведенного в нем графика работ? Если вероятностные оценки не предлагаются (например, что существуют пять наиболее вероятных рисков и предполагается такая-то вероятность их возникновения) и кто-либо из создателей плана не может предложить каких-либо объяснений относительно сделанных допущений, то остается предположить, что выполнение календарного плана возможно, но маловероятно2 {Причина в том, что любой календарный план является одним из множества возможных. В зависимости от характера непредвиденных обстоятельств (просчеты проектантов, политические революции, нашествия пришельцев и т.д.), заложенных в календарный план, рабочий график может быть разным. Если возможные провалы не рассматривались, календарный план не может вызывать доверия. Его создатель не проявил должного творческого подхода или скепсиса.}. План должен быть открытым для высказываемых командой предложений, чтобы предлагаемые соображения или информация могли дополнить или скорректировать план в целях повышения вероятности его выполнения.
       Весь секрет кроется в том, что календарный план не должен быть совершенным (что, конечно же, радует, поскольку совершенных планов вообще не существует). Планы должны быть приемлемыми для команды и руководства, предоставлять возможность для контроля и внесения корректив, а также иметь вероятность успешного выполнения, удовлетворяющего заказчика, бизнес-интересы или общего спонсора проекта.

Расчет — дело тонкое

       В процессе проектирования (обсуждаемого в главах 5 и 6) одной из задач проектировщиков, программистов и тестировщиков является разбиение проекта на небольшие части работы, которая имеет рекие завершенные формы. Эти части, часто называемые элементами структурной декомпозиции работ (Work Breakdown Structure, WBS1 {Процесс проведения структурной декомпозиции работ описан во многих книгах. К этой теме я вернусь в главе 14, но если вы хотите изучить ее более обстоятельно, начните с материалов, размещенных по адресу http://en.wikipedia.org/wiki/Work_breakdown_structure, или с книги Стефана Дево (Stephen Devaux) “Total Project Control” (Wiley, 1999).}), или просто работами, становятся строками в главном календарном плане проекта. Работы разумно (скрестите пальцы) распределяются2 {В книге Кента Бека (Kent Beck) “Extreme Programming Explained” (Addison Wesley, 1999) предлагается программно-ориентированная модель распределения работ, при которой программисты сами выбирают себе работы. В идеале должен быть выдержан компромисс между тем, что лучше для проекта, и тем, что лучше для отдельных специалистов команды.} среди программистов команды и в соответствии с ними строится календарный план. Каждая из этих работ должна иметь предполагаемый срок завершения, назначенный программистом, и на основе этих предположений создается календарный план.
       По самому простому определению качественные оценки работ имеют высокую вероятность оправдаться, у поверхностных оценок такая вероятность крайне низка. Я не ожидаю наград за подобное определение, но в нем имеется, по крайней мере, одно рациональное зерно: определять планку каждого проекта — прерогатива его руководителей. Этот процесс требует активного пересмотра оценок, а также нажима на подчиненных, руководства ими и принуждения их к работе с целью добиться соответствующей отдачи. Я думаю, что вполне разумно широко привлекать к расчетам команду тестировщиков и контролеров качества продукции, позволяя им участвовать в обсуждении проекта, задавать вопросы или отпускать комментарии. Как минимум, это поможет им в собственных оценках работ по тестированию, которые могут никак не соотноситься с расчетами на работы программистов. Зачастую тестировщики обладают лучшим видением недостатков проекта и потенциальных причин сбоев, которые другими специалистами могут быть упущены.

Весь мир держится на расчетах

       Трудности планирования заключаются в том, что далеко не всем нравится вести сложные расчеты, за которые потом придется отвечать. Всегда хочется прихвастнуть и козырнуть мастерством (“эта книга, фильм или веб-сайт никуда не годится, я бы смог все сделать намного лучше”), но стоит только заставить нас подойти и поставить подпись рядом со своим именем в контракте, в котором детализируется возлагаемая на нас ответственность, взгляд на вещи резко изменяется. Мы знаем, насколько вероятна ситуация, при которой сегодняшние обещания, когда придет время заняться делом, завтра могут обернуться полной несостоятельностью. Может статься, что все окажется намного сложнее, чем мы думали. Программисты — такие же люди, как все, и имеют серьезные основания побаиваться расчетов. Говоря о том, что смогут справиться с задачей в определенные сроки, они рискуют сильно ошибиться.
       По моему опыту, даже если программист разбирается в расчетах и верит в их состоятельность, он все равно берется за них с неохотой. Частично это вызвано несоответствием воображения (“при столь скудной информации я не могу представить, как это все должно работать”) с требованием точно рассчитать время (“скажите мне точно, сколько часов вам понадобится на разработку”). Но не стоит проявлять излишнее сочувствие: подобные сложности возникают у всех, кто занимается разработкой и строительством, строят ли они небоскреб, занимаются перепланировкой кухни или запускают космический зонд для посадки на другие планеты. Я много читал о том, как эти ребята проводят расчеты, и мне вовсе не показалось, что их сомнения и применяемые технологии в корне отличаются от тех, с которыми приходится сталкиваться разработчикам веб-сайтов и программ. Основное отличие состоит во времени, отводимом ими на расчеты, и в рациональности его использования (более детально этот вопрос рассматривается в главах 5 и 6).

Качественное проектирование — залог хороших расчетов

       К чести программистов, самое важное, что я усвоил в отношении качественных расчетов, это то, что они возможны лишь при качественном проектировании и четкой выработке технических требований. Хорошие инженерные расчеты возможны лишь при наличии двух вещей: достоверной информации и хороших специалистов. Если технические требования не выдерживают критики, а программистов просят вообразить что-то конкретное из малопонятных каракулей, нарисованных мелом на доске, все должны четко понять, что в результате будут получены крайне приблизительные и малопонятные расчеты. Из этого следует, что качественные расчеты — дело всех и каждого, коллективные усилия всей команды, всех руководителей и проектировщиков, направленные на то, чтобы сделать все возможное в помощь специалистам при производстве расчетов. Если расчеты воспринимаются рутинной работой или если руководители команд игнорируют процесс, не стоит ожидать надежных или правдоподобных расчетов.
       Если руководители считают слабость расчетов календарного плана допустимой и рост рисков их устраивает, значит, им вполне подойдут и весьма поверхностные расчеты. В небольших и краткосрочных проектах примерные расчеты — именно то, что нужно. Требования могут часто меняться, а характер бизнеса может потребовать большей гибкости. В этом случае весьма приблизительные расчеты вполне допустимы, если только их не путать с высококачественными.
       Я выработал очень удобный прием на случай, когда программист задерживается с расчетами. Я его спрашиваю: “О чем нужно спросить, чтобы придать вам уверенности в расчетах?” Заставив его сосредоточиться, я даю возможность побороть те чувства страха и неуверенности, которые могли им овладеть. Конечно, я должен был бы помочь найти ответы на его вопросы и, возможно, обсудить проблемы, которые, как я считал, он должен был решить самостоятельно, но, по крайней мере, мы поговорим о повышении качества расчетов.
       Вот несколько дополнительных советов, позволяющих добиться качественных расчетов:
       — Установите базовые показатели доверия расчетам. Предположение — 40% доверия, качественный расчет — 70%, подробный и полный анализ — 90%. Руководители команд должны прийти к соглашению, насколько точными должны быть расчеты, сколько времени отвести программистам для их проведения и как управлять риском неверных расчетов. Не заостряйте внимание на цифрах: пользуйтесь ими лишь для конкретизации качества расчетов. Расчет с 90-процентным доверием должен означать, что сроки выдерживаются в 9 случаях из 10. Если вы решите обратиться к команде с просьбой поднять качество расчетов, то должны подкрепить свою просьбу выделением дополнительного времени.
       — Ведущие программисты должны установить планку качества расчетов за счет постановки квалифицированных вопросов и применения разумных подходов, которые должна перенять вся команда. Сделайте все возможное, чтобы исключить любые предлоги для ехидных замечаний и торможения процесса (например, “не настаивайте на этом”, “это всего лишь предположение” и т.д.). Определите разумные потребности для получения качественных расчетов и удовлетворите их наряду с предоставлением достаточного времени на достижение качественных показателей.
       — Программистам нужно доверять. Если нейрохирург скажет, что на вашу операцию ему понадобится пять часов, станете ли вы давить на него, требуя сделать ее за три часа? Я сильно в этом сомневаюсь. Иногда давление должно применяться, чтобы заставить людей проявить честность, но только как мера весьма сбалансированная (обычно необходимость в этом возникает по отношению к программистам, завышающим расчеты на нелюбимые работы и занижающим их на любимые). При случае, получение нескольких оценок (от двух разных разработчиков) может стать одним из способов проверки.
       — Расчеты зависят от понимания программистами целей проекта. Расчеты основываются на программистской интерпретации не только проектировочных спецификаций (если таковые имеются), но также целей и параметров, заложенных в проект. Джеральд Вейнберг (Gerald Weinberg) в книге “The Psychology of Computer Programming” (Dorset House, 1971) отмечал прямое влияние недостаточно четко поставленных целей высокого уровня на низкоуровневые предположения, допускаемые программистами. Какой бы понятной ни была бы технологическая проблема, подходы программистов к ее решению могут в корне меняться в зависимости от общего замысла всего проекта.
       — Расчеты должны основываться на опыте предыдущих работ. Хорошо, если в привычку программистов войдет сохранение преемственности расчетов от проекта к проекту. Эта тема должна стать частью их дискуссии с руководителем проекта; в интересах руководителя выяснить, кто из команды преуспел в тех или иных расчетах. В экстремальном программировании в отношении возможной производительности программиста (или команды), основанной на предыдущих показателях производительности, используется понятие скорость1 {См. книгу Кента Бека (Kent Beck) и Мартина Фоулера (Martin Fowler) “Planning Extreme Programming” (Addison Wesley, 2002), стр. 60-62.}.
       — Качество технических условий или проектирования должно быть доведено до уровня, приемлемого для проведения качественных расчетов. Качество выработки технических условий должно стать темой для обсуждения между руководителем проекта и программистами. Чем выше требуемое качество расчетов, тем выше должно быть качество выработки технических условий. Более подробный разговор о качестве выработки технических условий будет вестись в главе 7.
       — Существуют известные методы улучшения качества расчетов. Наиболее известным является метод PERT (Program Evaluation and Review Technique — метод оценки и пересмотра планов), в котором предпринимается попытка минимизировать риски путем вычисления усредненной величины из результатов лучшего, среднего и худшего расчетов2 {Стандартная формула для метода PERT: лучший расчет + (4 х наиболее вероятный расчет) + худший расчет/6. Имейте в виду, что существует огромное количество разновидностей и теорий наилучших взвешенных расчетов.}. Этот метод хорош по двум причинам. Во-первых, всем дается понять, что расчеты сродни прогнозам, отражающим диапазон возможных результатов. Во-вторых, руководителям проектов дается возможность отрегулировать агрессивность или консервативность календарных планов (больший вес может придаваться низким или высоким оценкам).

Элементарные просчеты

       Хотя качественные расчеты оказывают большое влияние на улучшение календарных планов, множество факторов, влияющих на эти планы, буквально перечеркивают их отдельные элементы. Беда в том, что независимо от качества всех расчетов для отдельных работ, реальные риски срыва календарного плана на бумагу не попадают. Хотя шансы подвергнуться эпидемии в большинстве стран мира крайне незначительны, вероятность подхватить грипп или уйти в вынужденный отпуск ведущему инженеру довольно высока. Существует общий перечень подобных элементарных просчетов календарного плана, о которых должны знать все руководители проектов. Жаль только, что желание их остерегаться возникает только после того, как придется обжечься на одном из них. Поэтому руководителям проектов и особенно руководителям плановых отделов для становления нужен опыт работы. Существует множество различных путей развития неблагоприятных ситуаций, но опыт их предвидения приобретается только в том случае, если руководитель несет ответственность за их последствия.
       Я могу предложить вам свой любимый список вопросов, которые помогали мне замечать на ранних стадиях развития потенциальные проблемы составления календарных планов. Большинство из них родилось из вопросов о том, какие были допущены просчеты, заданных по окончании проекта, и из попыток отыскать вопросы, заданные кем-то на ранней стадии, позволившие избежать ту или иную проблему. (Что было упущено? Что не было принято во внимание? Как внести изменения? Что нужно сделать для исправления ситуации?)
       — Существует ли в календарном плане отдельная форма учета дней болезни и отпусков всех сотрудников?
       — Были ли учтены периоды праздников или другие времена года с большими нерабочими периодами (например, от Дня благодарения до Рождества в США или летние отпуска в Европе)? В эти периоды добиться соблюдения намеченных сроков крайне трудно.
       — Допущены ли сотрудники к календарному плану и вменялось ли им (в мягкой форме) в обязанность регулярно отчитываться за проделанную работу?
       — Проводит ли кто-нибудь ежедневный или еженедельный анализ выполнения календарного плана в целом? Обладает ли этот человек достаточными полномочиями, чтобы задавать резонные вопросы и вносить поправки?
       — Чувствует ли команда причастность к календарному плану и ответственность за его выполнение? Если нет, то почему? Внесла ли команда свой вклад в составление календарного плана и в определение объема работ или все это было спущено им сверху?
       — Чего больше было в действиях руководства командой, добавления требований по характеристикам продукта или помощи в их исключении? Говорили ли когда-нибудь руководители команды решительное нет новым объемам работ и предоставляли ли они своей команде разумную философию реагирования на новые (запоздавшие) требования?
       — Находили ли сотрудники поощрение и поддержку, если говорили нет новым требованиям, если те шли вразрез с их целями и представлениями?
       — Какая вероятность была заложена в расчеты? 90%? 70%? 50%? Нашла ли она отражение в главном календарном плане высокого уровня? Был ли клиент, вице-президент или заказчик уведомлен об этом? Обсуждалось ли другое предложение, более затратное по времени, но имеющее более высокую вероятность соблюдения сроков?
       — Имели ли место периодические согласования и пересмотры календарного плана со стороны руководителей команд и руководителей проекта?
       — Учтено ли в календарном плане сокращенное рабочее время в период праздников. (Обычно череда праздников снижает продуктивность работы.) Учтены ли в плане наиболее вероятные разрушительные погодные явления (например, снежные заносы в Чикаго, торнадо в Канзасе или жара в Сиетле)?
       — Был ли достаточно качественным уровень разработки технических требований и проектирования для получения качественных расчетов времени, отводимого на работы?
       — Была ли у расчетчиков достаточная практика или опыт в производстве расчетов времени, отводимого на работы?

Эффект снежного кома

       Даже при правильной реакции на большинство вопросов предыдущего списка вы, к великому сожалению, не гарантированы от провала, поскольку слишком велика степень взаимозависимости всех усилий, прикладываемых к составлению календарного плана. Все принимаемые командой решения, от выбора замысла до оценок, являются основой многих будущих решений. Чем позднее обнаруживается просчет, допущенный на начальной стадии проекта, тем выше степень его влияния на реализацию проекта. Сложность процесса реализации календарных планов легко недооценить, поскольку причинно-следственная связь зачастую не просматривается (последствия становятся заметными только в случае проявления их причин). В худших вариантах, при обнаружении нескольких крупных упущений, шансы на то, что план не рассыплется, стремятся к нулю (рис. 2.4).
       На самом деле все еще хуже. Вероятность наступления ряда независимых событий равна произведению вероятностей наступления каждого отдельного события (так называемая совместная вероятность). Отсюда следует, что если вероятность прочтения вами этой главы до конца равняется девяти шансам из десяти (9/10), а вероятность того, что вы осилите и следующую главу, также равна 9/10, то суммарная вероятность, что вы дочитаете до конца обе главы, равняется уже не 9/10, а 81/100. Это означает, что если у вашей команды 90-процентная вероятность точного следования еженедельному графику работ, с течением времени шансы срыва сроков возрастают. Вероятность — вещь холодная и беспощадная, напоминающая нам, что энтропия существует повсеместно и не благосклонна ни к проектам, ни к их руководителям.

Отсутствие или слабость концептуального локумента
X
Отсутствие или слабость технических требований
X
Слабые или слишком жесткие расчеты графика работ
X
Отсутствие ресурсов на компоновку
х
Отсутствие ресурсов на проработку пользовательского интерфейса
=
Потеря всех шансов на успех каленларного плана

Рис. 2.4. Эффект снежного кома

Что должно произойти, чтобы календарные планы заработали

       Теперь, когда стало понятно, почему так трудно придерживаться календарных планов, я хочу дать совет, как снизить риски и увеличить полезную отдачу от любого календарного плана. Предлагаемые подходы и поступки идут вразрез с традиционными устоями или привычками, в чем, я думаю, и кроется реальная природа планирования. Поскольку календарный план охватывает весь проект, единственный способ его эффективного использования состоит в том, чтобы приобрести какие-то понятия о природе всего, что требуется для успешной реализации проекта. Это многоплановая задача, относящаяся не только к разработке и управлению.
       — Выбирайте продолжительность этапов в соответствии со степенью изменчивости проекта. Чем больше ожидаемых изменений, тем короче должны быть этапы. Небольшие этапы настраивают команду на менее болезненные поправки в ходе реализации проекта. Управленцы получают более короткие контролируемые интервалы, что сокращает риски внесения изменений. Команда должна быть готова к поправкам на стыке этапов, чтобы все ожидали перемен, а не противились им.
       — Будьте оптимистом во взглядах и скептиком в планировании. Главное психологическое испытание в планировании — придерживаться надлежащей степени скептицизма, без подавления энтузиазма и устремлений команды. В отличие от принципов создания концептуального документа, в котором должен преобладать оптимистический взгляд на будущее, календарный план должен исходить из противоположных перспектив. Числа, положенные в расчеты продолжительности работ, без каких бы то ни было поблажек должны соответствовать закону Мэрфи (“все, что может пойти не так, пойдет не так”). В планах не должно отражаться то, что может произойти при оптимальных условиях. Вместо этого в хорошем плане отображается то, что должно случиться, несмотря на то что несколько существенных положений не оправдали своих ожиданий. Важно привлечь к планированию команду тестировщиков и контролеров качества, поскольку они внесут в разработку свойственный им скептицизм и критический взгляд на вещи.
       — Делайте ставку на проектирование. В процессе проектирования закладываются лучшие гарантии от неизвестных и неожиданных осложнений. Качественное проектирование — это единственный способ сделать более гладким преодоление командой фазы разработки и других фаз реализации проекта. Навыки проектирования отличаются от навыков разработки, поэтому самый сильный или самый продуктивный специалист по составлению программного кода не обязательно будет лучшим проектировщиком или специалистом по решению проблем. Качественному проектированию не учат на курсах информатики, несмотря на всю его важность в поиске путей и решений по разработке и управлению проектами. Эта тематика подробнее рассматривается в главах 5 и 6.
       — Планируйте контрольные точки для обсуждения исключений и добавлений. В календарные планы должны включаться короткие периоды для его пересмотра, позволяющие руководству критически оценить текущий процесс и учесть новую информацию и отзывы заказчика. Все это должно быть включено в главный календарный план и стать частью любого контракта на разработку проекта. В процессе пересмотра существующие работы могут урезаться или к ним могут добавляться новые, если это будет продиктовано результатами анализа текущей обстановки, проведенного руководством. Естественным временем для таких пересмотров являются промежутки между фазами или, в сокращенном варианте, моменты окончания каждой фазы проектирования или разработки, но они могут проводиться и в любое другое время, если возникнут серьезные опасения или явные расхождения между планом и реальным положением дел. Целью подобных пересмотров должно стать оздоровление проекта, освежение плана, уточнение приоритетов и инициирование следующего этапа выполнения календарного плана при ясном видении обстановки и с верой в будущее (см. главы 14 и 15).
       — Посвящайте команду в философию планирования. Какие бы технологии и подходы к планированию не использовались, их нужно доводить до команды. Если каждый программист и тестировщик сможет в общих чертах разобраться в принципах работы календарных планов и конкретной стратегии управления, применяемой в данном проекте, у него появится возможность задавать продуманные вопросы, понять общий замысел и поверить во все то, что планируется сделать.
       — Оцените опыт команды в сфере решаемых проблем. Одной из “волшебных” переменных величин в планировании является опытность команды в сфере тех проблем, которые ей предстоит решать. Если команда создает веб-сайт, управляемый базой данных, и пять или шесть программистов ранее уже не раз занимались такого рода работой, есть основания предполагать, что они лучше справятся с проектированием и расчетом графика работ, чем команда, ранее не делавшая ничего подобного. Этот фактор должен стать решающим в определении степени агрессивности или консервативности календарного плана.
       — Оцените уверенность и опыт команды в совместной работе. Несмотря на то что расчеты выполняют отдельные программисты, созданием чего-нибудь действительно сложного программисты занимаются вместе, как единое целое. Даже команда, составленная из опытных суперзвезд программирования, не достигнет ожидаемой результативности, если входящие в нее программисты ранее никогда вместе не работали (или не сталкивались все вместе со сложными задачами). Нельзя допускать, чтобы только что сформированной команде поручалась работа над сложным и рискованным проектом или предлагался агрессивный календарный план.
       — Беритесь за риски как можно раньше. Если известно, что Салли поручена наиболее сложная работа, учтите это в самом начале календарного плана. Чем выше риск, тем больше времени нужно зарезервировать для того, чтобы с ним справиться. Если вы откладываете учет рисков в календарном плане на более поздний срок, у вас останется меньше степеней свободы, чтобы справиться с этими рисками. То же самое относится к политическим, организационным или ресурсозависимым рискам. Мы поговорим об управлении работами при рассмотрении производственного конвейера в главе 14.

Выводы

       — Календарные планы выполняют три функции: позволяют зафиксировать обязательства, помогают каждому увидеть свою роль в общей работе и дают возможность отслеживать процесс реализации проекта. Даже если календарные планы срываются, польза от них все равно остается.
       — Большие календарные планы должны разбиваться на более мелкие с целью минимизации рисков и увеличения частоты внесения поправок.
       — Все расчеты имеют вероятностный характер. Поскольку календарные планы опираются на множество оценок, они также носят вероятностный характер. Это обстоятельство отрицательно влияет на их точность, поскольку вероятности накапливаются (80 % х 80 % = 64 %):
       — Чем раньше сделаны оценки, тем менее они точны. Но несмотря на это, приблизительные расчеты — единственный способ создания фундамента для более точных расчетов.
       — Календарные планы должны составляться не с оптимистических, а со скептических позиций. Чтобы пролить свет на предположения и приобрести уверенность в успехе, нужно вложить достаточные силы и средства в проектирование.

Упражнения

       1. Если вы пользуетесь ежедневным планированием, взгляните на вчерашний распорядок. Много ли событий произошло в срок? Из тех, которые произошли с опозданием, сколько было связано с вашими ошибками?
       2. Кто из известных вам людей постоянно опаздывает? Меняется ли из-за этого отношение к нему со стороны других сотрудников? Станете ли вы проявлять меньше оптимизма относительно сроков, отводимых ему на какую-нибудь работу? Переживает ли он из-за своих опозданий? Какие существуют мотивации для того, чтобы он изменил своим привычкам?
       3. Найдите оригинал календарного плана предыдущего проекта. Сравните его с реальными событиями. Чтобы вы сделали по-другому, если бы знали все,что знаете теперь? Как воспользоваться этой информацией в интересах следующего проекта?
       4. Проведите день, начиная и заканчивая все дела точно в срок. После задайтесь вопросом, стоило ли ради этого стараться? Почему да или почему нет?
       5. Найдите друга, который работает в какой-нибудь другой сфере. Как он составляет календарное планирование своих проектов? Какими инструментами пользуется для подсчета времени, затрачиваемого на ту или иную работу? Какие в его сфере деятельности наиболее типичные ошибки и чему можно научиться из того, как он с ними справляется? (Если у вас нет таких друзей, то интересно будет поучиться, сравнивая свою деятельность со строительством, кинопроизводством, устроительством свадебных торжеств.)
       6. Правило трех частей — это примерная норма, для которой есть исключения. Какие разновидности проектов требуют другого распределения времени?Могут ли быть проекты, в которых доминирует только одна из этих трех разновидностей работ?
       7. Многие проекты существенно зависят от неподконтрольных вам работ. Какие методы можно применить при составлении календарного плана, чтобы сократить риск подобных зависимостей? Как можно наладить контакт с людьми, ответственными за составление календарного плана, чтобы они создали план, который бы привел к успеху обе команды?
       8. Ваш руководитель настаивает на определенной дате, а ваш опыт подсказывает,что это нереально. Как можно воспользоваться календарным планом, чтобы объяснить вашу обеспокоенность руководителю?
       9. Если элементарные просчеты, рассмотренные в этой главе, касаются большинства проектов, то как должен поступить толковый руководитель проектов:а) поставить в известность команду об их существовании, или б) поощрять людей за стремление уменьшить их влияние на проект? Um delis num velesedip exero eum velenibh ex et, susting exer si.




<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:56 MSK


Постоянный адрес статьи:
http://az-design.ru/Projects/AzBook/src/004/02MS0200.shtml