Жанр: Учеба
Смертельный марш
...оторых повлечет за собой некоторое "формирование" и "утряску". Но
независимо от того, сколько времени потребуется на весь процесс - день,
неделя или месяц - он все равно произойдет; если это окажется возможным,
менеджеру проекта следует постараться как можно больше ввести команду в
курс дела еще до "официального" начала проекта, с тем, чтобы к этому
моменту уже оказаться в стадии "выполнения".
Важно также не забывать, что даже сплоченная команда может развалиться под
воздействием тех стрессов, которые они испытывают в безнадежном проекте. В
своем письме ко мне Dale Emery рекомендует, чтобы менеджер проекта
внимательно следил за процессами, происходящими в команде:
Уделяйте внимание взаимоотношениям, складывающимся в команде, и не жалейте
усилий на поддержку готовности людей к совместной сверхурочной работе.
Давление, которое испытывают участники безнадежного проекта, может
превратить небольшие недоразумения в большие конфликты. Периодическое
"измерение температуры" в группе может помочь вам и команде справляться с
проблемами во взаимоотношениях, когда они еще находятся в самом зародыше.
В худшем случае может случиться, что команда так и не пройдет первые две
стадии, или, иначе говоря, встанет на путь "командного самоубийства", не
сумев справиться с перечисленными выше проблемами. Если через какое-то
время менеджер проекта (или кто-нибудь из более высокого руководства)
обнаружит, что так оно и произошло, может оказаться слишком поздно
формировать новую команду. Се ля ви.
4.5 Условия работы
Проблемы создания нормальных условий для работы уже так много лет
обсуждаются среди разработчиков ПО, что кажется бессмысленным снова их
поднимать. Tom DeMarco и Tim Lister, чья книга уже не раз цитировалась в
этой главе, уделяют большое внимание тем преимуществам, которые дает
создание нормальных условий для работы; например, если разработчики ПО
работают в достаточно тихом помещении, вероятность появления у них ошибок
уменьшается на одну треть по сравнению с теми, кто работает в шумном офисе
и постоянно отвлекается на посторонние дела. Проанализировав работу 600
разработчиков ПО, DeMarco и Lister смогли получить результаты, убедительно
говорящие о том, что продуктивность работы тех, кто находится в хорошем
офисе и может закрыть дверь, не отвечать на телефонные звонки и не
отвлекаться на посторонние дела, почти в 2,6 раза выше, чем у находящихся
в обычном офисе.
Хотя DeMarco и Lister опубликовали свою работу в 1987 году, с тех пор в
условиях работы большинства разработчиков ПО мало что изменилось - за
исключением фирм-разработчиков ПО. Условия работы в Microsoft и в
большинстве других софтверных компаний Силиконовой Долины в самом деле
достаточно цивилизованные - отдельные помещения с закрытыми дверями,
наличие содовой, сока и других напитков, и "постоянный" телефонный номер,
который остается за программистом даже в том случае, если он перебирается
в другое помещение.
Что касается разработчиков ПО, работающих в банках, страховых компаниях,
правительственных учреждениях, промышленных предприятиях и сотнях других
компаний, которые до сих пор смотрят на программное обеспечение как на
"накладные" расходы, то им приходится работать не в нормальных офисах, а в
отгороженных клетушках, где возможность сконцентрировать свои умственные
усилия на решении какой-либо проблемы варьируется от плохой до полностью
отсутствующей. Звучит набившая оскомину музыка, не прекращаются телефонные
звонки, лают собаки, кричат люди, и нет никакого спасения от кого угодно
(от курьера до директора), кто может засунуть голову в твою комнату и
отвлечь тебя. Как отмечают DeMarco и Lister:
Проектировщики с полицейскими наклонностями проектируют рабочие места
наподобие тюрем: оптимальная вместимость при минимальных затратах. Мы
бездумно соглашаемся с ними в вопросах проектирования рабочих мест, хотя в
большинстве организаций, испытывающих проблемы с продуктивностью работы,
не существует более подходящего фактора ее повышения, чем рабочие места.
До тех пор, пока сотрудники будут тесниться в шумных и неприспособленных
помещениях, нельзя говорить о сколько-нибудь продуктивной работе.
К сожалению, мои рассуждения относительно сложившейся ситуации вряд ли
смогут оказать на нашу индустрию большее воздействие, чем гораздо более
детальные и убедительные выкладки DeMarco и Lister. Однако не следует
забывать, что мы здесь говорим о безнадежных проектах, к которым применимы
другие правила, и я думаю, что менеджеру проекта следует принять такую
философскую позицию, которая подразумевает отсутствие вообще каких бы то
ни было правил.
Если вы являетесь менеджером безнадежного проекта с практически
нереальными сроками, то сведений о том, что хорошие условия работы могут
улучшить продуктивность в 2,6 раза, может оказаться достаточно, чтобы
заставить вас сломать множество преград. То, чего вам удастся в этом деле
достичь, может оказаться всего лишь временным; как только проект
закончится, налетит хозяйственная служба, все отберет и вернет вас обратно
в крохотные клетушки. Однако, если безнадежный проект продолжается хотя бы
полгода, и вы достаточно изобретательны, стоит попытаться обеспечить
подходящие условия для работы таким образом, чтобы хозяйственная служба
вообще не знала о том, что происходит.
Для этого есть несколько возможностей:
* Лобовая атака - если у вашего проекта есть защитник и/или владелец,
которые крайне заинтересованы в его успехе, объясните им, насколько важно,
чтобы проектная команда работала в хороших условиях. Если защитник проекта
является руководителем высокого уровня, то организовать временный переезд
команды в более подходящее помещение будет относительно несложно.
* Самовольный захват - не спрашивая ни у кого разрешения, займите
какое-нибудь пустое помещение, которое пока никем не занято, в то время
как хозяйственная служба пытается подсчитать, сколько сотен людей они
смогут туда впихнуть. Такой захват обеспечит 90% успеха в борьбе за
условия работы; пока бюрократы будут ругаться, спорить и отправлять в
разные стороны гневные послания, вам, может быть, уже удастся закончить
проект и незаметно удалиться на прежнее место.
* Дистанционный доступ - разрешите всем работать дома и организуйте
еженедельные рабочие совещания в ближайшем "МакДональдсе" (в 9 часов утра,
когда почти нет посетителей). Пока кто-нибудь обнаружит исчезновение
команды, может пройти не одна неделя. Для дополнительного отвлечения
внимания можно посадить чучела за столы, которые обычно занимала проектная
команда; руководству понадобится достаточно много времени, чтобы отличить
их от других зомби, сидящих в офисе.
* Переход в ночную смену - это более радикальный вариант, однако он может
оказаться достаточно эффективным, если большая часть работы может
выполняться без взаимодействия с пользователями. Не слишком приятно
просить людей работать в ночное время вместо дневного, однако фактически
это гарантирует отсутствие обычных отвлечений. Подобная стратегия
наверняка вызовет гнев местных бюрократов, но самая замечательная вещь
заключается в том, что бюрократы не остаются в офисе до полуночи! Они
будут слать сердитые записки и послания по электронной почте, при этом
следует игнорировать их и делать вид, что никогда их не получали. Если это
не удается, просто откажитесь менять свой график работы; пока они не
додумаются отключать свет или поменять замки на двери офиса, вряд ли им
удастся помешать вам в рамках обычного безнадежного проекта.
* Преграды и заслоны - если ваша команда работает в обычном "открытом"
офисе и упомянутые выше стратегии неприменимы, тогда постарайтесь сделать
все возможное, чтобы сосредоточить команду в смежных помещениях. После
этого сделайте все необходимое, чтобы забаррикадироваться от остальной
толпы в офисе. Отключите селекторную связь и вопящий из угла
громкоговоритель (и будьте готовы проделывать это еженедельно, поскольку
обслуживающий персонал может снова включить их). Выключите телефоны из
сети, или, как советуют DeMarco и Lister, набейте вату в звонок. Если вы
сможете проделать такое на целом этаже или вообще во всем здании, то будет
еще лучше. Поднимите над зданием пиратский флаг, как это сделал Стив Джобс
со своей командой в Apple во время проекта Macintosh. Установите охрану,
чтобы гнать прочь непрошеных визитеров.
Некоторые из этих могут спровоцировать более резкую ответную реакцию
корпоративной бюрократии, чем другие; команда и ее менеджер должны решить,
какая стратегия будет наиболее эффективной. Но я хотел бы подчеркнуть, что
вполне серьезно рассматриваю все эти стратегии, невзирая на очевидный
факт, что они нарушают "правила игры", принятые почти в каждой крупной
компании. Бороться с бюрократией таким способом - не для робкого десятка;
но ведь и сами безнадежные проекты тоже не для робкого десятка. Если
менеджер безнадежного проекта не проявляет желания бороться и отстаивать
право на нормальные условия работы, то с какой стати проектная команда
должна проявлять готовность идти на экстраординарные жертвы ради
организации и менеджера проекта?
4.6 Заключение
Талантливых исполнителей, сплоченной команды и хороших условий для работы
все же недостаточно, чтобы гарантировать успех безнадежного проекта. С
другой стороны, их отсутствие почти наверняка гарантирует провал проекта.
Как будет ясно из следующих двух глав, хорошо организованные процессы
разработки и хорошая технология также являются важными составляющими
успеха; однако, все же самая главная составляющая - это люди. Как сказал
Рональд Рейган: "Окружите себя самыми лучшими людьми, которых вы только
сможете найти, передайте им в руки власть и не мешайте им".
Литература к главе:
1. Tom DeMarco, Tim Lister. Peopleware. Dorset Publishing, 1987.
2. Frederick Herzberg. One More Time: How Do You Motivate Employees?
Harvard Business Review, September-October 1987.
3. John Boddie. Crunch Mode. Englewood Cliffs: Prentice-Hall/Yourdon
Press, 1987.
4. Rob Thomsett. Effective Project Teams: A Dilemma, a Model, a Solution.
American Programmer, July-August 1990.
Дополнительная литература:
1. Larry Constantine. Constantine on Peopleware. Englewood Cliffs, NJ:
Prentice Hall, 1995
2. Watts Humphrey. Managing for Innovating: Leading Technical People. New
York: McGraw-Hill, 1987.
3. Gerald M. Weinberg. Understanding the Professional Programmer. New
York: Dorset House, 1988.
4. Ken Whitaker. Managing Software Maniacs. New York: John Wiley & Sons,
1994.
ГЛАВА 5. ПРОЦЕССЫ
Если вы запомните хотя бы одно слово из данной главы (или вообще из всей
книги), то эти словом должна быть приоритетность (triage). Исходя из
названия главы, вы можете подумать, что речь в основном пойдет о таких
знакомых методологиях, как структурный анализ, или формальных дисциплинах
наподобие SEI Capability Maturity Model (CMM), или различных подходах к
разработке ПО под общим названием RAD (Rapid Application Development). Все
это важные и нужные вещи, но самое главное заключается в том, что в
безнадежном проекте вам не хватит времени на то, чтобы удовлетворить все
потребности пользователя. Если вы будете строить все свои процессы и
методы, исходя из этого непреложного факта, то у вас появятся шансы на
успех; если же вы начнете проект, будучи уверенными, что к кодированию
нельзя приступать до тех пор, пока все диаграммы потоков данных,
полученные в результате структурного анализа, не будут утверждены
пользователем, то вы определенно потерпите неудачу.
Это не означает, что нам следует игнорировать все методологии и стратегии,
связанные с процессами (я поговорю о них позже в этой главе); но моя
мысль, как вы можете убедиться, заключается в том, что они, безусловно,
должны быть частью общей корпоративной стратегии, однако их не следует
навязывать команде безнадежного проекта в отчаянных попытках избежать его
провала. В данной ситуации применима концепция приоритетности - испытывая
нехватку времени и ресурсов, команда безнадежного проекта откажется от тех
методов, которые она сочтет бесполезными или несущественными (например,
детальные мини-спецификации в структурном анализе), и примет на вооружение
только самые полезные для нее методы. Аналогично, менеджер проекта,
располагающий весьма малым временем для чтения данной главы, предпочтет
прочесть наиболее важную информацию и пропустить остальное; я построил
обсуждение в данной главе, исходя именно из этих соображений.
5.1 Концепция "triage"
Слово "triage" происходит от старого французского "trier", что означает
"сортировать, классифицировать". American Heritage Dictionary (3-е
издание) определяет его следующим образом:
triage - существительное
1. Процесс распределения раненых по группам в зависимости от их
потребности в оказании немедленной медицинской помощи. Применяется на поле
боя, в местах катастроф и госпиталях в условиях ограниченных медицинских
ресурсов.
2. Система, используемая при распределении дефицитных товаров (например,
продовольствия) среди тех, кто способен получить от этого наибольшую
выгоду.
Большинство из нас знакомы с медицинской трактовкой этого термина, однако
для безнадежных проектов более подходящим является второе определение:
распределение дефицитных ресурсов (самым дефицитным из которых обычно
является время) таким образом, чтобы извлечь из этого наибольшую выгоду.
Или, как отметил Stephen Covey в Большинство подходов, связанных с
прототипированием и RAD, вполне сочетаются с данной концепцией, а
некоторые даже явно на нее ссылаются. Однако, большинство подходов RAD
делают акцент только на быстром получении некоторого - какого угодно! -
результата (работающего приложения), который можно показать пользователю с
целью (а) продемонстрировать, насколько ощутим достигнутый прогресс, и (б)
получить замечания, касающиеся функциональности системы и
(преимущественно) пользовательского интерфейса. Все это весьма полезно,
однако если проектная команда будет расходовать свои ресурсы на
проектирование начальных прототипов с внешне привлекательными, но
несущественными возможностями, то как команда, так и пользователь будут
зря терять время.
Большинство методологий разработки ПО, независимо от того, базируются ли
они на классической "каскадной" модели жизненного цикла, или на более
современной "спиральной" модели и прототипировании, имеют незаметное на
первый взгляд, но довольно коварное свойство. Оно выражается следующей
фразой: "неважно как, но ко времени завершения проекта мы сделаем все".
Возможно, причина этого заключается в том, что в детстве родители
запрещали нам выходить из-за обеденного стола, пока мы не оставим пустые
тарелки; в любом случае, невысказанный девиз многих проектных команд - "мы
не оставим невыполненным ни одного требования".
Разумеется, это честный девиз, но в безнадежных проектах он почти всегда
невыполним. Как я уже отмечал в главе 1, в большинстве безнадежных
проектов "официально утвержденные" требования превышают ресурсы проектной
команды - в особенности, человеческие и временные ресурсы - на 50-100
процентов. В этой ситуации неопытная команда надеется, что, работая
сверхурочно вдвое больше, она сможет как-нибудь покрыть этот дефицит; а
циничная команда "самоубийственного" проекта предполагает, что их проект
все равно затянется на 50-100 процентов по сравнению с первоначальным
планом, как и любой другой проект. Но даже если циничная команда ошибается
в этом, она все равно предполагает, что раньше или позже (обычно гораздо
позже!) она в конце концов реализует все функции, которые требовались
пользователю.
Один из ключевых моментов в безнадежных проектах состоит в том, что
некоторые требования не просто останутся невыполненными до официального
срока завершения проекта, но и не будут выполнены никогда. Если
предположить, что известное правило "80-20" справедливо, то проектная
команда сможет добиться 80 процентов "эффекта" от разработанной системы,
реализовав 20 процентов требований к ней - при условии правильного выбора
этих 20 процентов. И, поскольку пользователю, как правило, не терпится
получить работающую систему задолго до того срока, который проектная
команда считает разумным, то он может взять эти готовые 20 процентов,
приступить к их использованию и навсегда позабыть об оставшихся 80
процентах функций системы.
Это, конечно, чересчур упрощенный подход, но, тем не менее, почти во всех
безнадежных проектах, в которых я принимал участие, приходилось
устанавливать приоритеты, разделяя все требования к системе на три
категории: "необходимо выполнить", "следует выполнить" и "можно
выполнить". Смысл этих категорий очевиден, и тот факт, что их всего три,
предупреждает любые бесполезные дискуссии на тему о приоритетах, например,
какой приоритет присвоить конкретному требованию - шестой или седьмой. При
такой расстановке приоритетов в проекте очевидная стратегия будет
заключаться в следующем: в первую очередь сосредоточиться на требованиях,
которые необходимо выполнить; затем, если останется время, сосредоточиться
на требованиях, которые следует выполнить; и наконец, если произойдет
чудо, заняться требованиями, которые можно выполнить.
Если не следовать такой стратегии с самого начала проекта, то к концу он
окажется в крайне неприятной кризисной ситуации. Чтобы понять, почему это
происходит, рассмотрим типичный график проекта, изображенный на рис. 5.1:
Начало проекта Середина проекта
Кризис Окончание
Рис. 5.1 График проекта
Когда проект начинается, никто и слушать не желает, что его сроки
нереальны - в особенности все пользователи и высшее руководство. У
менеджера проекта и участников команды может возникнуть неприятное
ощущение, что им предстоит выполнять "самоубийственную" миссию, однако
если они - оптимисты, то могут поверить, что проект будет иметь характер
"невыполнимой миссии" и впоследствии какое-нибудь чудо придет им на
помощь. В этот момент самым важным является то, что конечный срок еще
достаточно далеко (через шесть месяцев или год), и никто не хочет всерьез
задумываться о невыполнимости поставленных задач.
В самом деле, политическое давление и неопытность проектной команды могут
привести к тому, что даже в середине проекта он не будет подвергнут
никакой переоценке. Как не смешно это звучит, но проблема может оказаться
еще более сложной, если проектная команда использует какую-либо
разновидность RAD-подхода, поскольку они, вероятно, уже продемонстрировали
пользователю один или более прототипов системы и тем самым поддержали у
него иллюзию, что все будет сделано вовремя. Однако, к этому моменту
проектная команда скорее всего начнет понимать, что они пытаются прыгнуть
выше головы, и если для менеджера этот безнадежный проект - первый, он
будет наивно верить, что высшее руководство и пользователи тоже в конце
концов их поймут.
Увы, но обычно этого не происходит. В конце концов наступает кризис, когда
пользователи и/или высшее руководство оказываются вынуждены посмотреть в
лицо реальности: несмотря на их требования и искренние заверения менеджера
проекта, система не будет готова в срок. Обычно это случается за месяц до
окончания проекта, иногда за неделю, а иногда и через день после
официального окончания! Последствия могут быть различными: это зависит от
степени напряженности политических баталий к этому моменту, а также от
степени изнуренности и разочарованности менеджера проекта. Тем не менее,
при этом, как правило, происходит следующее: высшее руководство приходит к
выводу, что во всем виноват менеджер проекта, и в итоге несчастного
увольняют (если только он сам уже не уволился!) и ставят нового с
требованием "ликвидировать весь этот бардак и сдать систему вовремя".
Новый менеджер может быть как закаленным ветераном из самой организации,
так и сторонним консультантом. Иногда случается так, что он в самом деле
обнаруживает ряд грубых ошибок, сделанных его предшественником (например,
отсутствие планирования вообще или отсутствие рабочих графиков); иногда
новый менеджер приходит к выводу, что его предшественник в основном делал
все правильно, но не смог избежать участи козла отпущения, когда высшее
руководство наконец убедилось, что их первоначальные требования
невыполнимы.
Однако, независимо от его оценки, почти не подлежит сомнению, что новый
менеджер должен быть готов к следующему: все проектные требования в полном
объеме не удастся реализовать в соответствии с первоначально установленным
сроком - если бы это было не так, то предыдущего менеджера вряд ли бы
уволили. Итак, что же следует предпринять новому менеджеру? Две наиболее
очевидные возможности заключаются в следующем:
* пересмотреть срок окончания проекта;
* пересмотреть требования к системе.
(Консультант John Boddie предлагает еще одну возможность: менеджер проекта
может стать одним из тех, кто добьется официального прекращения проекта,
если его действительно невозможно спасти. Новому менеджеру сделать такое
гораздо проще, чем его предшественнику, поскольку тот вложил в проект
столько личных усилий и эмоций, что ему трудно представить себе, как
вообще можно прекратить проект. Boddie дает несколько хороших советов
относительно политически приемлемых способов прекращения проекта в своей
статье "Calling Doctor Kevorkian", опубликованной в журнале American
Programmer, February 1997.)
Первая возможность в принципе вполне допустима, однако в безнадежном
проекте практически нереальна. В самом деле, ведь основной причиной,
побудившей пользователей настаивать на таких нереальных планах, является
неотложная потребность в системе, которая позволила бы им справиться со
своими проблемами в бизнесе. Поскольку новый менеджер приходит в проект в
тот момент, когда уже близок первоначально установленный срок завершения,
высока вероятность того, что пользователи уже строят планы эксплуатации
новой системы. Последнее, что им хотелось бы слышать - это то, что проект
продлится еще 6-12 месяцев.
Поэтому наиболее часто - и успешно - применяемый прием заключается в
определении приоритетов для первоначальных требований. Отметим, что при
этом новый менеджер разговаривает с позиции силы - это не его вина, что
проект оказался в таком плачевном состоянии; при этом не высказывается
вслух, но подразумевается, что руководство и пользователи в первую очередь
были настолько глупы, что позволили загнать себя в такой тупик. Новый
менеджер может даже поставить свое согласие на участие в проекте в
зависимость от успешного окончания переговоров - например, заявив: "Если
вы хотите, чтобы я вытащил вас из этой ямы, то должны принять как факт,
что мы сможем реализовать в срок только небольшой процент первоначально
заданных функций. Таково реальное положение вещей, согласны вы с ним или
нет".
Такое заявление будет прямым и честным, хотя и обескураживающим. Однако
при этом уместно задать вопрос: что же делать со всем тем, что было
наработано до наступления кризиса и прихода нового менеджера? Ведь
команда, вероятно, уже успела много напрограммировать и оттестировать, и
может быть, даже успела разработать некоторую документацию и проектные
модели. Что же делать со всей этой частично выполненной работой. Наиболее
разумный ответ: большую часть придется выбросить.
Такое утверждение может показаться чересчур пессимистичным. В самом деле,
почему бы просто не отложить всю частично выполненную работу в сторону и
вернуться к ней позднее? В лучшем из миров так оно и происходит; однако
это возможно при наличии хороших средств и процессов контроля версий,
конфигурационного управления, контроля исходного кода и т.д. - всего того,
что отвергается в пылу сражения, когда все усилия команды сосредоточены на
получении как можно больших результатов.
Реальная причина, по которой вся эта частично выполненная работа
превращается в напрасный труд, заключается в следующем: ни у кого не
найдется времени, чтобы снова к ней вернуться. Предположим, что участники
проектной команды (теперь уже под руководством нового менеджера, к
которому они могут относиться с уважением или нет) способны реализовать
только самый минимум необходимых функций, причем работа над проектом
обычно доводит их до такого истощения, что половина из них уходит. Кроме
того, проект уже так осточертел пользователям, что они не будут приставать
с вопросами относительно функций, оставшихся нереализованными; или же,
наоборот, они будут настолько довольны минимальным набором функций, что
также никогда не потребуют доделать систему до конца. Даже если они это
сделают, и даже если проектная команда все еще будет существовать в
первоначальном составе, высока вероятность, что в попытках реализовать
"скелет" системы в нее будет внесено так много архитектурных изменений,
что наполовину законченные компоненты системы (соответствующие
второстепенным функциям) никогда больше не будут использоваться.
Заметьте, что мы в данном обсуждении еще ни разу не коснулись таких тем,
как структурный анализ, SEI-CMM или любые другие "книжные" методологии и
процессы создания ПО. Все, что говорилось по поводу приоритетности,
продиктовано исключительно здравым смыслом, что для безнадежных проектов
является критически важным. Чтобы эта концепция работала, все акционеры и
заинтересованные лица должны принять согласованное решение, какие
требования следует отнести к категории "необходимо выполнить", какие к
"следует выполнить" и какие к "можно выполнить". Разумеется, если владелец
проекта категорически настаивает на том, чтобы все требования были
обязательно выполнены, все дальнейшее обсуждение будет пустой тратой
времени. (На самом деле, я бы порекомендовал менеджеру проекта и его
команде использовать такое обсуждение в самом начале проекта как
лакмусовую бумажку. Если пользователи, владелец проекта, высшее
руководство, акционеры и заинтересованные лица не желают принима
...Поділитися у соцмережах
