Генерал настолько хорош или настолько плох, каким его делают собственные солдаты. Дуглас МакАртур
Будьте настойчивы в отстаивании права формировать свою собственную команду. Можно ожидать от команды сверхурочной работы, но при этом помните, что они участвуют в марафоне и могут пробежать в спринтерском темпе только последние 100 ярдов. Добейтесь для них щедрого вознаграждения, если проект закончится успешно, но не дразните их обещаниями будущих экстраординарных наград, потому что это только собьёт их с толку. Приложите максимум усилий для создания спаянной и дружной команды, готовой к сотрудничеству; очень важно обладать необходимой квалификацией, однако ещё более важно, чтобы она была дополнена психологической совместимостью. Все сказанное должно способствовать максимальному единению участников проекта.

К сожалению, этого явно недостаточно для большинства менеджеров безнадёжных проектов, поскольку они работают в организациях, пренебрегающих человеческим фактором даже в «нормальных» проектах. Хотя может показаться, что в таких условиях безнадёжные проекты обречены на провал, иногда получается как раз наоборот. Как отмечалось в главе 3, менеджер может быть вынужден согласиться с нереальными сроками или бюджетом, но в качестве компенсации может настаивать на своих решениях по вопросам персонала (на праве нанимать нужных исполнителей, соответствующим образом вознаграждать их и обеспечивать им нормальные условия работы).

Безнадёжный проект может восприниматься как угроза теми, кто желает сохранить бюрократическое статус-кво. Менеджер проекта имеет возможность обойти бюрократические ограничения, связанные с персоналом, с помощью непосредственных распоряжений высшего руководства, однако он должен быть готов к тому, что, поступая таким образом, приобретёт себе вечных врагов в лице кадровой службы и различных других администраторов. Тем не менее, если безнадёжный проект будет иметь громкий успех, он может послужить катализатором к изменению кадровой политики в последующих «нормальных» проектах.

В любом случае, в этой главе я вовсе не ставлю перед собой задачу менять сложившуюся в организации культуру управления людскими ресурсами. На эту тему уже написано достаточно много, включая отдельные главы в моих книгах Rise and Resurrection of the American Programmer и Decline and Fall of the American Programmer (ряд ссылок содержится также в конце этой главы). Главный вопрос данной главы заключается в следующем: если вы уже знакомы с «основами» управления персоналом, что нового привносят безнадёжные проекты?

4.1 Кадровые вопросы

Первая отличительная особенность безнадёжного проекта — явно выраженный акцент на правильном формировании проектной команды. Сотрудничая с софтверными организациями в разных странах, я сталкивался с четырьмя наиболее общими стратегиями формирования команды безнадёжного проекта:

1) нанять суперпрограммистов и предоставить им свободу действий;

2) настаивать на привлечении команды, которая готова к «невыполнимой миссии» и имеет опыт совместной работы;

3) набрать команду из простых смертных, но при условии, что они будут знать, на что идут;

4) взять любых сотрудников, которых вам дают, и сделать из них команду «невыполнимой миссии».

Первая стратегия выглядит весьма заманчиво, поскольку существует предположение, что суперпрограммисты будут невероятно продуктивны и достаточно изобретательны, чтобы предложить для безнадёжного проекта новые решения. С другой стороны, эта стратегия рискованна, поскольку суперпрограммисты обычно являются суперэгоистами и могут не ужиться друг с другом. Кроме того, такая стратегия для многих организаций проблематична, поскольку руководство не желает платить суперпрограммистам такую высокую зарплату, какую они требуют. И даже если это вам по карману, мало шансов на то, что они согласятся работать над безнадёжным проектом — ведь они все работают в Netscape или Microsoft или ещё где-нибудь, где, по их мнению, имеют место действительно впечатляющие проекты.

Вторая стратегия почти наверняка будет идеальной для большинства организаций, поскольку она не требует привлечения суперпрограммистов; кроме того, такой тип проектной команды воспет телесериалом «Невыполнимая миссия». Однако, если ваша организация предпринимает свой самый первый безнадёжный проект, такой команды просто не существует. Если же такие проекты ранее имели место, и они носили характер «самоубийственных», «камикадзе» или «отвратительных» проектов, то их команды в дальнейшем, скорее всего, распались и прекратили своё существование. Таким образом, стратегия сохранения в целости проектной команды успешного безнадёжного проекта должна, как правило, планироваться заранее как корпоративная стратегия, исходя из предположения, что безнадёжные проекты могут снова иметь место в будущем (более детально это будет обсуждаться в главе 7).

Третья стратегия по вполне очевидным причинам является наиболее распространённой для тех организаций, в которых мне довелось побывать. В большинстве организаций нет суперпрограммистов и нет тех, кто уцелел в предыдущих безнадёжных проектах. Следовательно, команда каждого нового безнадёжного проекта комплектуется заново. Участники команды вполне компетентны и, возможно, выше среднего уровня разработчиков в данной организации, однако от них нельзя ожидать сотворения чудес. Для данной стратегии жизненно важно, чтобы участники команды понимали, на что они идут; даже хотя они являются простыми смертными, им придётся совершать необычайные подвиги в разработке ПО.

Последней стратегии следует избегать при любых затратах. Если проект превращается в «свалку» для сотрудников, которых не хотят брать ни в какие другие проекты, он почти наверняка будет «самоубийственным». Такой тип команды также воспет Голливудом, особенно в таких фильмах, как Чёртова Дюжина ; их смысл заключается в том, что отверженных и неудачников может сплотить сильный, харизматический лидер и заставить их совершать чудеса, которые все считали невозможными. Все это хорошо, однако Голливуд ничего не рассказывает нам обо всех таких проектах с собранными из неудачников командами, которые закончились провалом. Мне думается, что если вы согласитесь руководить таким проектом (или участвовать в нем), то вас ждёт судьба самоубийцы.

Все сказанное приводит нас к центральному вопросу формирования команды безнадёжного проекта: до какой степени менеджеру проекта следует настаивать на своём праве принимать кадровые решения? Как было отмечено выше, большинство менеджеров вынуждены примириться с фактом, что они не получат карт-бланш, чтобы нанимать самых талантливых суперпрограммистов в мире; кроме того, существующая в организации политика может не позволить менеджеру по собственной воле, не спрашивая разрешения, привлечь в проект лучших сотрудников организации, поскольку они либо уже участвуют в других важных проектах, либо их с пеной у рта отстаивают другие менеджеры. Тем не менее, существует один аспект, на котором, по моему убеждению, менеджер должен настаивать как на своём абсолютном праве: это право наложить вето на попытку других руководителей навязать проектной команде неугодного им сотрудника. В противном случае и без того уже высокий уровень риска в проекте может повыситься до недопустимых пределов.

Естественно, такая ситуация порождает разнообразные и весьма неприятные политические баталии. Менеджеру проекта придётся, вероятно, выслушивать всякие успокаивающие заверения вроде: «Не надо беспокоиться. У Чарли были некоторые проблемы в предыдущих проектах, но в твоём с ним будет все в порядке» или чрезвычайно льстивые речи наподобие: «Ты такой грандиозный менеджер, что я уверен в твоей способности развернуть Чарли на 180° и получить от него реальную отдачу» или разные призывы проявить лояльность и мужество. Мой совет — держаться до последнего и быть непреклонным в своём праве отвергнуть любого, кто, по вашему мнению, не подходит для проектной команды.

Один из критериев, которые следует принимать во внимание при таких решениях — это вероятность того, что предполагаемый участник команды покинет проект, не дожидаясь его окончания. Разумеется, большинство разработчиков не расскажут вам ничего о своих планах уйти в середине проекта; однако, некоторые из них все же расскажут вам заранее о своих личных намерениях — женитьбе, разводе, планируемой экспедиции в Гималаи и т.д. — которые могут выключить их из работы над проектом. Крайне нежелательно в самом разгаре проекта лишиться некоторых сотрудников и оказаться вынужденным принять в проект новых людей.

В главе 3 я рассматривал варианты действий, которые имеются у менеджера проекта в случае неудачи переговоров: уйти в отставку, обратиться за помощью к более высокому руководству, игнорировать бюрократические правила и принимать свои собственные решения, или определить для себя проект как самоубийственную миссию. Игнорирование правил обычно является наиболее сложным делом, поскольку включение дополнительных участников в проектную команду может быть связано с ограничениями штатного расписания, которое менеджеру проекта неподконтрольно. С другой стороны, иногда имеется возможность «одолжить» людей из другого проекта или даже нанять по контракту временных исполнителей.

Можно также попытаться изолировать нежелательного участника команды, которого включили в проект против воли менеджера; его можно загрузить какой-нибудь безобидной работой или отправить изучать поведение африканских мух цеце до самого конца проекта. Doug Scott описал ещё более хитрый вариант такой стратегии:

Безнадёжные проекты к концу зачастую оказываются в таком отчаянном положении, что высшее руководство готово выбросить любые средства, например, чтобы нанять ещё 20 человек. В таких случаях я всегда соглашаюсь. Я поручаю этим субъектам менять перегоревшие предохранители у кофейного автомата и другие важнейшие задания, в то время как я занимаюсь своими лучшими сотрудниками. (Среди этих людей, если вдруг повезёт, тоже могут оказаться хорошие исполнители.) Затем вы можете способствовать уходу из проекта лишних людей и продолжать настаивать на их замене все новыми и новыми людьми. Например, в одном случае я сократил первоначальный персонал на 20% и, несмотря на это, получил нужный результат, причём гораздо более высокого качества. В этом нет ничего удивительного.

4.2 Лояльность, отношение, мотивация и вознаграждения

Вопросы отношения к безнадёжному проекту обсуждались мной в главе 2; оно является важным элементом политики в проектах такого рода, а также одной из ключевых характеристик команды, которой менеджер проекта должен уделять максимальное внимание. В идеальном случае (с точки зрения менеджера проекта) участники команды должны дать клятву верности и преданности безнадёжному проекту; для молодых и неженатых технарей это звучит не так уж дико, как может показаться. С другой стороны, отношение существенно зависит от таких факторов, как длительность проекта. Можно полностью посвятить себя 3-х или 6-ти месячному проекту, но вряд ли это возможно для трехлетнего проекта.

Отношение к проекту также существенно зависит от способности менеджера проекта обеспечить необходимую мотивацию участников команды. До некоторой степени это определяется его харизмой. Некоторые менеджеры способны вызвать у участников команды такую преданность, что они последуют за ним хоть на край земли, не обращая внимания на рискованность проекта; другие же настолько бездарны в этом отношении, что их команды и палец о палец бы не ударили, даже если целью проекта было бы спасение человечества от вторжения пришельцев.

Конечно, можно возразить, что менеджер должен брать в свою команду только тех, кто проявляет высокую заинтересованность. Можно также утверждать, что данное обсуждение вообще бессмысленно, поскольку большинство разработчиков ПО и так обладает достаточной мотивацией, как отмечают в [1] Tom DeMarco и Tim Lister:

Для любого работника нет ничего более обескураживающего, чем чувствовать, что его собственной мотивации явно недостаточно, и она должна «подкрепляться» его боссом. Достаточно редко приходится прибегать к драконовским мерам, чтобы заставить ваших людей работать; большинство из них любит свою работу.


Существуют, однако, уровни или степени мотивации. Мы можем рассчитывать на то, что разработчик ПО проявит определённую степень мотивации в «нормальном» проекте, но безнадёжные проекты требуют более высокой степени, поскольку участникам команды месяцами придётся выдерживать изнурительную работу, политическое давление и технические трудности. Кроме того, в начале проекта менеджер сталкивается с такой проблемой, как отсутствие точного знания мотивации каждого из участников команды. Как отмечает Doug Scott:

Вы предполагаете, что менеджер знает, что за людей он получает в свою команду. У меня обычно получалось так, что их включали в команду до того, как я успевал узнать о них что-либо хорошее или плохое.



Во многих случаях основные факторы, влияющие на мотивацию (или демотивацию), сосредоточены вокруг тех процессов, которые происходят в команде (ниже я буду обсуждать эти вопросы более детально). Существует, однако, два конкретных фактора, которые также оказывают значительное воздействие на мотивацию и которые находятся под непосредственным контролем менеджера: вознаграждения за работу и сверхурочное время.

4.2.1 Стимулирование участников проекта

Было бы здорово, если можно было бы решить проблему мотивации, посулив большие суммы денег каждому участнику проектной команды (и менеджеру, конечно!). Frederick Herzberg [2], тем не менее, полагает, что не всегда можно обойтись одними деньгами:

Деньги, выгода, комфорт и тому подобное являются факторами «гигиены» — их отсутствие вызывает неудовлетворённость, однако они не могут заставить людей полюбить свою работу и дать им необходимые внутренние стимулы. Что действительно может дать такие стимулы, так это ощущение значительности достигнутых результатов, гордость за хорошо выполненную работу, более высокая ответственность, продвижение по службе и профессиональный рост — все то, что обогащает работу.


Эта оценка, по-видимому, достаточно точно характеризует «нормальные» проекты. Что же касается большинства безнадёжных проектов, то деньги все же играют в них важную роль. На самом деле, они могут являться главной целью всего проекта. Многие начинающие компании Силиконовой Долины предпринимают безумные и безнадёжные проекты в надежде на то, что им удастся разработать какое-нибудь совершенно «убойное» приложение для нового технического устройства и продать миллион его копий на сгорающем от нетерпения рынке. Если участники проектной команды являются акционерами и собираются поучаствовать в распределении прибыли, то денежное вознаграждение, очевидно, составляет весьма существенную часть мотивации их участия в проекте. Действительно, многие компании Силиконовой Долины намеренно придерживают зарплату на 20-30% ниже преобладающего на рынке уровня, заинтересовывая своих специалистов возможностью серьёзного участия в акционировании и других формах распределения будущей прибыли. Эта стратегия направлена не только на повышение мотивации, но также и на снижение расхода наличности, поскольку зарплаты сотрудников зачастую составляют единственные самые крупные затраты начинающей софтверной компании.

Разумеется, существуют такие из ряда вон выходящие безнадёжные проекты, в которых деньги не играют никакой роли. Разработчик ПО, получивший единственный в жизни шанс в проекте, подобном полёту Аполлона 11 на Луну, не нуждается в деньгах; он, безусловно, согласен с комментарием Стива Джобса по поводу проекта Macintosh: «Само путешествие — это награда».

С другой стороны, мне доводилось встречаться с угнетающе скучными безнадёжными проектами в дряхлеющих правительственных учреждениях, в которых никто не питает ни малейшей надежды на какое-либо дополнительное вознаграждение. Размеры зарплаты определяются уровнем, установленным для государственных служащих, и её структура закреплена законодательством — она не допускает никаких премий, акционирования или участия в распределении прибыли. В таких ситуациях, очевидно, глупо даже обсуждать денежное вознаграждение в качестве стимула — это может только расстроить участников команды.

Однако, как насчёт организации, располагающей необходимой гибкостью? Если безнадёжный проект достаточно важен для организации, для неё вовсе не является запредельной возможность зарезервировать значительный премиальный фонд для поощрения проектной команды, если ей удастся завершить проект в срок. Возможность премирования существует и для «нормальных» проектов, однако премии там обычно гораздо более умеренные. Приятно получить в конце проекта чек на 1,000$, однако третью часть этой суммы составят налоги, и того, что останется, явно недостаточно, чтобы заметно повлиять на жизненный уровень типичного разработчика ПО со средним уровнем доходов. Однако, в безнадёжных проектах дело обстоит иначе: премиального чека на 10,000$ может оказаться достаточно для покупки новой машины (пускай даже самой скромной по современным меркам!) или отдыха за границей. Чека на 100,000$ достаточно, чтобы заплатить за обучение ребёнка в престижном колледже или купить дом (или, по крайней мере, заплатить за него первый взнос). Наконец, чека на 1,000,000$ достаточно, чтобы обеспечить себе достойную пенсию.

Допуская возможность такого вознаграждения, сделаем некоторые замечания:

5) Не забывайте о том, что 20%-ное повышение зарплаты имеет гораздо большее значение для молодого программиста, зарабатывающего 25,000$ в год, чем для опытного и квалифицированного программиста, зарабатывающего 75,000$ в год. При более высокой зарплате предельная налоговая ставка обычно существенно выше и может достигать 50%, поэтому опытный программист приносит домой не намного больше молодого, и, следовательно, зарплата при этом рассматривается, скорее, как фактор гигиены. Что же касается молодого программиста, налоговая ставка при его зарплате достаточно низка, и этих 20% может вполне хватить для выплаты ежемесячных взносов за его первый автомобиль или переезда от родителей в арендованную квартиру.

6) Помните, что возможность заработать большие деньги может по-разному подействовать на мотивацию людей. Руководство может полагать, что она просто побудит всех работать более интенсивно, однако, она может также заставить участников команды чересчур критически и подозрительно относиться друг к другу — например, какой-либо из участников команды может выразить своё недовольство следующим образом: «Джордж имел наглость отсутствовать в сочельник на работе, чтобы побыть со своей глупой семейкой, как раз тогда, когда у нас был важный этап тестирования. Похоже, он собирается оставить нас без премии!»

7) Помните, что размер премии отнюдь не связан прямой, линейной зависимостью с продуктивностью или количеством времени, затрачиваемого проектной командой. Мне приходилось наблюдать, как в некоторых организациях высшее руководство пытается соблазнить проектную команду двойной премией — обычно при отставании проекта от графика — поскольку руководство, очевидно, верит, что двойная премия заставит людей работать вдвое больше. Однако, если участники команды уже работают по 18 часов в день, законы физики не позволят работать вдвое больше даже самым рьяным из них.

8) Для того, чтобы премия работала как стимул, проектная команда должна верить, что она реально существует и высшее руководство не будет искать удобный предлог, чтобы отменить её. Разумеется, если вознаграждение связано с успехом на рынке, то никаких гарантий быть не может — например, даже если проект закончится успешно, то возможный обвал на финансовом рынке может нарушить все планы компании по продвижению её продукта. Однако, если премия целиком зависит от высшего руководства, и проектная команда знает, что в предыдущих безнадёжных проектах их участники самым бессовестным образом были оставлены без всякого вознаграждения, то «обещание» премии сыграет, скорее всего, роль отрицательного стимула. Аналогично, если проектная команда приходит к выводу, что она практически не влияет на успех проекта — например, он может зависеть от своевременной поставки нового оборудования, которое разрабатывается внешним поставщиком — то обещанная руководством премия будет восприниматься скорее как «игра в лотерею», а не как стимул.

9) Проектная команда должна также верить, что распределение премии будет справедливым. Это вовсе не означает уравниловки; однако, если команда знает, что львиная доля вознаграждения достанется менеджеру проекта, а другим участникам останутся крошки со стола, то результат предсказуем. Такие вопросы необходимо обсуждать в самом начале проекта; вряд ли участников проекта могут успокоить такие заявления менеджера, как «доверьтесь мне и ни о чем не беспокойтесь — я приложу все усилия, чтобы каждому досталось по справедливости».

Что касается проектов, в которых большие премии невозможны или нежелательны, менеджеру проекта важно не забывать о том, что существуют достаточно разнообразные виды нематериального вознаграждения, с помощью которых можно так же серьёзно стимулировать участников проекта. Это также справедливо и для «нормальных» проектов, но для безнадёжных особенно важно. Важно также помнить, что пресс, под которым находится команда безнадёжного проекта, давит также и на членов их семей. Как отмечает Doug Scott:

Первым делом следует ослабить тот пресс, под которым находятся ваши люди, поэтому первоочередное вознаграждения должно доставаться супругам и семьям участников проекта — карьера и деньги конечно хороши, но не надо забывать и о семье, которая вынуждена нести определённые лишения. Для начала важен и букет цветов. Оказывайте поддержку всей семье — ведь они все так или иначе участвуют в работе.


Букет цветов — это, конечно, красивый жест, но для членов семьи иногда важнее более «практичные» вознаграждения — особенно для супруги, которая вынуждена в одиночку управляться с хозяйством и ухаживать за детьми, в то время как её «сильная половина» пропадает круглые сутки в безнадёжном проекте. Внимательный менеджер проекта может выяснить, нужно ли супруге такси, чтобы отвезти ребёнка домой из школы, или может ли кто-нибудь в офисе по дороге домой заглянуть в магазин, чтобы помочь супруге, которая сидит дома с больными детьми. Если дети действительно серьёзно больны и нуждаются в медицинской помощи, то менеджер проекта должен перевернуть землю, если потребуется сломать бюрократические преграды, и сделать все, чтобы обеспечить необходимую помощь и успокоить участника проекта, волнующегося о своей семье.

Конечно, такая забота требует денег, но, как правило, не таких уж больших, которые вполне укладываются в статью бюджета под названием «прочие затраты». Конечно, если бюрократы обнаружат это, то они поднимут вой, что такие расходы официально не предусмотрены. Менеджер, который уступит такому нажиму, будет просто бесхарактерной тряпкой; если это необходимо, менеджер должен оплачивать такие расходы из своего собственного кармана, поскольку он обычно получает гораздо большую зарплату, чем технические специалисты в его команде. В любом случае, воевать с бюрократами — это забота менеджера; самое последнее дело вынуждать технических специалистов попусту тратить своё время и эмоциональную энергию на борьбу с бухгалтерией, чтобы доказать им целесообразность покупки дополнительной пиццы на ужин, если команда задержалась на работе до позднего вечера.

Скромные вознаграждения такого рода в течение всего проекта обязательно сделают своё дело, однако существуют и более действенные нематериальные поощрения, которые могут быть сделаны по окончании проекта. Я не имею ввиду продвижение по службе или новые возможности для карьеры, которые в конечном счёте попадают в ту же категорию, что и прямые денежные вознаграждения. Ниже приведены примеры некоторых поощрений, которые, может быть, не так действенны, как премиальный чек на миллион долларов, но, тем не менее, могут оказать благотворное действие в безнадёжном проекте:

10) Дополнительный отпуск — если проект закончится успешно, предоставьте его участникам отпуск такой же продолжительности, как и весь проект. Большинство из нас не знает толком, что делать с двухнедельным отпуском — однако, если бы нам предоставили шестимесячный оплачиваемый отпуск, мы могли бы отправиться в кругосветное морское путешествие, о котором всегда мечтали. Любопытный тест: выскажите эту идею своему менеджеру и посмотрите на его реакцию. Если вы услышите что-нибудь наподобие: «Что?!? Ты, наверное, спятил? Шестимесячный отпуск за шестимесячный проект?!? Мы дадим тебе пару дней и не вздумай больше искушать судьбу!», то это означает только одно: менеджер полагает, что разработчики ПО — это не более чем бессловесные рабы. Такая позиция многое говорит о том, какое отношение к трудовым соглашениям принято в данной организации.

11) Оплаченная свобода действий — когда безнадёжный проект завершится, привлеките участников команды к шестимесячной работе над «Проектом Х» (эту замечательную идею предложил Larry Constantine на конференции по программному обеспечению в Мельбурне в 1995 году). Вопрос: что такое «Х»? Ответ: все, что они пожелают. Вместо того, чтобы сразу же оказаться втянутыми ещё в один безнадёжный проект (или в скучный до безобразия «нормальный» проект, что на самом деле ничуть не лучше), участники команды получат хорошую возможность в течение шести месяцев осваивать Java, изучать новейшие объектно-ориентированные методологии или даже вернуться в колледж, чтобы получить свою степень магистра. Надо проявить некоторую изобретательность, придумывая «официальное» название для Проекта Х, чтобы поставить в тупик бюрократов; что-нибудь вроде «эвристической объектно-ориентированной клиент-серверной системы стратегического прогнозирования с возможностями Internet» может произвести необходимый эффект.

12) Создание полностью оснащённой домашней компьютерной системы — хотя ПК сегодня стали намного дешевле, и у каждого из нас есть дома какой-нибудь компьютер, он может быть необязательно самым суперсовременным. У многих из нас стоят медленные 486-е или даже древние 386-е ПК, в то время как остальной мир мчится вперёд на ПК Pentium с 200 Мгц. Один из интересных моментов, связанных с безнадёжными проектами, заключается в том, что они зачастую оснащаются самым совершённым компьютерным оборудованием, поскольку руководство готово раздуть бюджет до невообразимых размеров, свято веря, что передовая технология может спасти проект. Если к концу проекта какое-либо оборудование становится ненужным, отдайте его участникам команды в качестве премии; если же такой открытый подарок нарушает слишком много бюрократических правил, передайте его хотя бы во временное пользование.

4.2.2 Сверхурочная работа

В то время как премии и дополнительные отпуска являются положительным стимулом, необходимость сверхурочной работы во время проекта обычно считается отрицательным стимулом. Тем не менее, в безнадёжных проектах она почти всегда неизбежна; это единственный способ, дающий менеджеру проекта хоть какой-то шанс уложиться в жёсткий график. И, как отмечалось ранее, для неё зачастую не требуется никаких специальных просьб менеджера: молодые, холостые и фанатичные участники команды, которых возбуждает брошенный вызов и возможность использования в проекте самой передовой технологии, рады работать по 60, 80 или 100 часов в неделю.

Несмотря на это, сверхурочным временем необходимо правильно распоряжаться, чтобы избежать отрицательного воздействия на команду и не поставить под угрозу успех проекта. Один из способов это сделать — убедиться, что высшее руководство знает реальную стоимость сверхурочной работы; как отмечает консультант Dave Kleist:

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


Независимо от того, получают участники команды компенсацию за сверхурочную работу или нет, самой большой ошибкой будет отсутствие учёта этого времени, исходя из неверного допущения, что поскольку участникам команды это время не оплачивается, то оно как бы «свободное». Даже если с точки зрения бухгалтерии именно так оно и есть, с точки зрения менеджера проекта сверхурочное время никак не должно рассматриваться в качестве свободного. Даже если предположить, что все участники команды способны всю жизнь без устали работать по 18 часов в день, для менеджера критически важно фиксировать, сколько таких «невидимых» сверхурочных часов затрачивается в течение работы над проектом. Для менеджера это единственный способ точно измерить производительность команды и вероятность своевременного достижения каждой промежуточной контрольной точки в графике проекта.

Каждому известно, что люди не в состоянии работать всю жизнь по 18 часов в день; даже если они будут очень стараться, все равно скоро устанут. Когда люди устают, они делаются раздражительными и вспыльчивыми, работают менее продуктивно и делают гораздо больше ошибок. Все это самым серьёзным образом может повлиять на успешную работу над проектом, и менеджер должен понимать, когда следует ослабить давление, а когда следует попросить поработать сверхурочно.

Все это может показаться не столь важным для трех-шестимесячного проекта, когда молодая и энергичная проектная команда способна «безвылазно» сидеть на работе от начала до конца проекта. Однако, для более длительных проектов тщательный контроль за сверхурочной работой крайне необходим; влияние долгой и тяжёлой сверхурочной может неожиданно сказаться самым коварным образом. Как отметил Doug Scott:

При грамотном планировании следует знать, что потребность в сверхурочной работе может возникнуть довольно неожиданно, как вспышка, и затем так же сойти на нет. Невозможно держать людей на работе 90% времени и более в течение длительного срока.



И, как отмечено в [3], важно, чтобы менеджер понимал, что каждый участник команды может совершенно по-разному относиться к сверхурочной работе:

У каждого индивидуума свой собственный метаболизм. Некоторые люди — «совы», а другие — «жаворонки» и хорошо работают рано утром. Независимо от этого, не будет никакого вреда здоровью от десятичасового рабочего дня. Когда проект набирает обороты, можно ожидать, что его участники будут работать как минимум по 60 часов в неделю. Если этого не происходит, проверьте в первую очередь, нет ли чего-нибудь такого в организации проекта, что мешает им работать.
Лидер проекта должен рассчитывать на максимально возможное время работы. При этом, во-первых, он сам должен показывать пример. Нельзя ожидать от людей готовности к сверхурочной работе, если вы сами этого не делаете. Такую работу надо лично возглавлять. Во-вторых, надо быть вместе с ними, чтобы отвечать на неотложные вопросы, помогать в борьбе с бюрократической волокитой и фиксировать возникающие в эти часы проблемы.


Одна из опасностей, которые менеджер проекта должен предвидеть — это чрезмерная добровольная сверхурочная работа той части молодых энтузиастов, которые не представляют пределов своих собственных возможностей и не задумываются о возможных побочных эффектах такой работы до изнеможения. Как показано на рис. 4.1, производительность труда действительно может расти в первые 20 часов сверхурочной работы (благодаря повышенному содержанию адреналина в крови, концентрации внимания и т.д.). Но рано или поздно каждый достигнет своей точки насыщения, после чего начнётся спад, поскольку возрастёт количество ошибок и ослабнет концентрация внимания. Таким образом, наступит момент, когда участник команды будет демонстрировать «отрицательную» продуктивность, поскольку усилия, затрачиваемые на исправление ошибок и дефектов в программах и их переписывание, будут сводить на нет всю выполненную работу. Предполагая, что масштаб на рис. 4.1 достаточно точен (хотя это может зависеть от возможностей конкретного разработчика ПО), менеджер может относительно безболезненно настаивать на 60-часовой рабочей неделе; при работе от 60 до 80 часов следует чётко установить пределы индивидуальных возможностей каждого разработчика; при 80-90-часовой рабочей неделе менеджер должен заставлять разработчиков отправляться домой и отдыхать.



Рис. 4.1 Зависимость производительности от количества рабочих часов

4.3 Значение коммуникации

В безнадёжных проектах одним из важных вопросов, связанных с человеческими ресурсами, является природа и степень взаимодействия между менеджером проекта и остальной командой. По моему убеждению, идеальная ситуация — когда у менеджера проекта нет секретов от команды, и каждый участник команды знает о проекте все. Это означает, что каждый участник команды располагает текущей, актуальной информацией относительно состояния проекта, первоочередных приоритетов, рисков, ограничений, политики и т.д.

При таких условиях в команде может быть создана атмосфера взаимного доверия и доброжелательности. Если участники команды прилагают экстраординарные усилия к работе над проектом и приносят в жертву личную жизнь, для них было бы крайним разочарованием обнаружить, что менеджер проекта скрывает от них важную информацию или играет за их спиной в политические игры. Поскольку в безнадёжном проекте все процессы протекают интенсивнее и быстрее, чем в «нормальном», выше вероятность, что участники команды обнаружат утаивание информации или непристойные политические игры вокруг них.

Очевидный контраргумент против такой философии заключатся в том, что менеджер должен оберегать команду от посторонних помех, особенно от каждодневных мелочных политических игр, которые происходят вокруг проекта. В большинстве случаев участники команду по достоинству оценят возможность освободиться от политики; однако они также нуждаются в уверенности, что в ответ на прямой вопрос менеджер не станет темнить или лгать им. В большинстве проектов, нормальных или безнадёжных, регулярно проводятся совещания, на которых обсуждается состояние проекта и поднимаются различные острые вопросы; если участники команды удовлетворены тем, что они всегда могут узнать о том, что происходит в проекте, тогда они спокойно смогут на 99% сконцентрироваться на своей непосредственной работе.

Уровень коммуникации между отдельными участниками команды также весьма важен, особенно в таких сложных ситуациях, когда участники команды прежде не работали вместе. Очень важно, чтобы внутрикомандное взаимодействие оберегалось от постороннего вмешательства, тогда можно будет поддерживать честный и откровенный обмен информацией. Для большинства сегодняшних проектов это обязательно подразумевает наличие электронной почты и различных средств групповой работы, наподобие Lotus Notes. Однако, помимо этого, менеджеру проекта следует планировать еженедельные совместные завтраки или обеды, чтобы участники команды могли пообщаться друг с другом вне стен офиса.

4.4 Проблемы формирования проектной команды

Открытые и честные взаимоотношения являются важной составляющей процесса формирования эффективной команды. Подбор исполнителей, обладающих психологической совместимостью друг с другом — другая ключевая составляющая. Как отмечалось выше, крайне важно, чтобы менеджер проекта имел свободу действий при выборе участников команды, а также может оказаться полезным использовать методы наподобие тестов оценки личности Бриггса-Мейерса, чтобы попытаться заранее оценить способность участников команды к взаимодействию друг с другом.

Ещё одна составляющая заключается в концепции командных ролей. Многие менеджеры проекта сосредотачиваются на чисто «технических» ролях, таких, как проектировщики баз данных, специалисты по сетям, эксперты по пользовательскому интерфейсу и т.д. Хотя все они важны, не менее важно подумать о ролях «психологического» плана, которые могут играть один или более участников команды. Эти роли присутствуют и в «нормальных» проектах, однако в безнадёжных они приобретают особую важность. Rob Thomsett в [4] определил восемь ключевых ролей в проекте следующим образом:

13) Председатель (chairman) — выбирает путь, по которому команда движется вперёд к общим целям, обеспечивая наилучшее использование её ресурсов; умеет обнаружить сильные и слабые стороны команды и обеспечить наилучшее использование потенциала каждого участника команды. Можно подумать, что таким человеком является, как правило, официальный руководитель проекта; однако, в самоуправляемых командах им может быть любой человек.

14) Оформитель (shaper) — придаёт законченную форму усилиям команды, направляет внимание и пытается придать определённые рамки групповым обсуждениям и результатам совместной деятельности. Такой человек может иметь официальную должность «архитектора» или «ведущего проектировщика», но главное то, что эта роль «воображаемая». В безнадёжном проекте особенно важно иметь единое и чёткое представление о проблеме и её возможном решении.

15) Генератор идей (plant) — выдвигает новые идеи и стратегии, уделяя особое внимание главным проблемам, занимается поиском возможных новых подходов к решению проблем, с которыми сталкивается группа. Для такой роли мне больше нравится название «провокатор» — человек, который пытается внедрять в команде радикальные идеи и технологии, искать новые решения технических задач.

16) Критик (monitor-evaluator) — анализирует проблемы с прагматической точки зрения, оценивает идеи и предложения таким образом, чтобы команда могла принять наиболее сбалансированные решения. В большинстве случаев такой человек поступает как «скептик», уравновешивая оптимистические предложения оформителя и генератора идей. Критик хорошо знает, что новые технологии отнюдь не всегда работают, обещания поставщиков относительно возможностей новых средств и языков программирования иногда не сбываются, и все может пойти не так, как было задумано.

17) Рабочая пчёлка (company worker) — превращает планы и концепции в практические рабочие процедуры, систематически и эффективно выполняет принятые планы. Другими словами, в то время как оформитель придаёт законченную форму крупным технологическим решениям, генератор идей предлагает радикальные новые решения, а критик занимается поиском изъянов и недостатков в этих предложениях, рабочая пчёлка — это тот человек, который работает, не привлекая внимания, и выдаёт «на гора» тонны кода. Очевидно, любой безнадёжный проект нуждается по крайней мере в паре таких пчёлок, но сами по себе они не способны принести успех проекту, поскольку не обладают необходимой широтой кругозора.

18) Опора команды (team worker) — поддерживает силу духа в участниках проекта, оказывает им помощь в трудных положениях, пытается улучшить взаимоотношения между ними и в целом способствует поднятию командного духа. Другими словами, такой человек выполняет в команде роль «дипломата». Им может быть и менеджер проекта, однако им может быть также любой из участников команды, который несколько более, по сравнению с другими, восприимчив к ущемлению прав личности и более внимателен к чувствам участников команды. Как правило, эта роль также особенно важна в безнадёжных проектах, поскольку команда зачастую испытывает сильный стресс, и по меньшей мере один или два её участника начинают вести себя как равнодушные ко всему «супермены».

19) Добытчик (resource investigator) — обнаруживает и сообщает о новых идеях, разработках и ресурсах, имеющихся за пределами проектной группы, налаживает внешние контакты, которые могут оказаться полезными для команды, и проводит все последующие переговоры. Я предпочитаю называть такого человека «уборщиком мусора», поскольку он всегда знает, где отыскать бесхозный ПК, свободный конференцзал, дополнительный рабочий стол или почти что любой другой ресурс, в котором нуждается команда. Такие ресурсы могут быть добыты по официальным каналам, а могут и нет; но даже если их можно достать «нормальным» способом, это нередко требует заполнения 17 форм в трех экземплярах, после чего приходится шесть месяцев ждать выполнения всех бюрократических процедур. Безнадёжный проект не может ждать так долго и не может позволить, чтобы вся работа застопорилась из-за того, что какой-то помощник вице-президента из зависти не разрешает воспользоваться единственным в организации свободным конференцзалом. Командный добытчик имеет, как правило, много друзей и связей в своей организации, с помощью которых можно выпросить или одолжить необходимые ресурсы. Самое главное во всем этом то, что добытчик обожает свою деятельность.

20) Завершающий (completer) — поддерживает в команде стремление к настойчивости в достижении цели, активно стремится отыскать работу, которая требует повышенного внимания, и старается, насколько это возможно, избавить команду от ошибок, связанных как с деятельностью, так и с бездеятельностью. Такой человек обычно играет доминирующую роль во время тестирования системы на завершающей фазе жизненного цикла проекта, однако его роль на более ранних стадиях тоже важна. Команде необходимо время от времени — а ещё лучше каждый день! — напоминать, что они не делают себе карьеру на всю жизнь, а всего лишь участвуют в проекте с жёсткими сроками и промежуточными контрольными точками, которые необходимо достигать вовремя, чтобы не провалить проект.

К сожалению, даже наличие исполнителей на каждую роль и психологическая совместимость не гарантируют, что команда будет представлять собой единое целое. Как отмечено в [1]:

Вряд ли вам удастся заставить команду стать сплочённой. Вы можете на это надеяться, можете скрещивать пальцы, можете предпринимать все возможное, но превратить команду в единое целое не в вашей власти. Этот процесс слишком хрупкий, чтобы им можно было командовать.


Если процесс формирования такой команды протекает успешно, обычно это бывает заметно по некоторым внешним признакам. Как замечают DeMarco и Lister, в преуспевающих командах обычно присутствует сильное ощущение общности интересов и гордости за свою команду, а также (по крайней мере, в безнадёжных проектах типа «невыполнимая миссия») чувство, что они в состоянии хорошо выполнять свою работу и получать от этого удовольствие. С другой стороны, если организация не в состоянии обеспечить создание такой сплочённой команды, это может привести к тому, что DeMarco и Lister называют «командным самоубийством» (teamcide) — т.е., принимается сознательное или бессознательное решение плыть по течению и не совершать никаких действий для создания сплочённой и целостной команды. Такая ситуация обычно порождается следующими причинами:

21) Оборонительное руководство — не доверяющее проектной команде. Отметим, что при этом для команды становится очень важным наличие «защитника», как обсуждалось в главе 2.

22) Бюрократия — изобилие бумажной работы. Если команда обладает хоть каким-то здравым смыслом, она просто откажется заниматься бумажной работой или невнятно пообещает вернуться к ней после окончания проекта.

23) Физическое разобщение участников команды — (например, по различным зданиям, городам или странам) — конечно, электронная почта и средства групповой работы могут частично решить эту проблему, однако этого явно недостаточно для поддержки командного духа, который столь необходим для успеха безнадёжного проекта.

24) Фрагментация рабочего времени участников проекта — особенно в ситуациях, когда участники команды часть своего времени официально заняты в безнадёжном проекте, а в остальное время занимаются сопровождением старой системы или организацией рождественской вечеринки в компании. Трудно вообразить себе, что в безнадёжных проектах может происходить такое, однако это на самом деле случается в больших бюрократических организациях.

25) Снижение качества продукта — хотя команда может быть готова к тому, чтобы допустить некоторое снижение уровня качества с целью своевременной разработки «достаточно хорошего» ПО, обычно существует некоторая нижняя грань, которую они откажутся перейти. Понятие качества может подразумевать наличие дефектов (ошибок), отсутствующие функции, примитивный пользовательский интерфейс или некачественную документацию.

26) Нереальные сроки — настолько жёсткие сроки, что команда абсолютно не верит в возможность их выполнения. Такая разновидность «командного самоубийства» обычно превращает проект «невыполнимая миссия» в «самоубийственный» проект.

27) Произвол руководства — роспуск проектной команды после завершения проекта. Как было отмечено выше, некоторые команды по завершении проекта приходят к выводу, что он невыразимо скучен, а пользователи, для которых они разрабатывали свои программы — неблагодарные деревенщины; таким образом, единственное удовлетворение, полученное от проекта, заключается в удовольствии от совместной работы в одной команде с конкретными людьми. В самом деле, это удовлетворение может быть настолько большим, что участники команды выражают надежду на перспективу продолжения совместной работы в будущих проектах. Но на их беду тот командный дух, который помог им добиться успеха, зачастую воспринимается руководством как угроза для своего благополучия, поэтому роспуск такой команды после завершения проекта является обычным делом. Такая перспектива, в свою очередь, является настолько деморализующей, что команда может распасться ещё до окончания проекта.

Последнее, что следует сказать относительно формирования сплочённой команды: даже если удаётся это сделать, то никак не в самый первый день проекта. Типичная команда в процессе своей эволюции проходит четыре стадии, которые также относятся к процессу достижения понимания и поиску общего решения прикладной проблемы:

28) Формирование: участники команды определяют цели, роли и направление работы.

29) Утряска: команда устанавливает правила и процедуры принятия решений и, как правило, пересматривает роли и ответственность.

30) Нормирование: вырабатываются процедуры, стандарты и критерии.

31) Выполнение: команда начинает функционировать как целое.

В идеальном случае команда оказывается уже прошедшей первые две стадии ещё до начала проекта — поскольку участники команды работали вместе в предыдущих проектах. Тем не менее, все проекты разные, и в каждой проектной команде обычно имеются один или два новых человека, присутствие которых повлечёт за собой некоторое «формирование» и «утряску». Но независимо от того, сколько времени потребуется на весь процесс — день, неделя или месяц — он все равно произойдёт; если это окажется возможным, менеджеру проекта следует постараться как можно больше ввести команду в курс дела ещё до «официального» начала проекта, с тем, чтобы к этому моменту уже оказаться в стадии «выполнения».

Важно также не забывать, что даже сплочённая команда может развалиться под воздействием тех стрессов, которые они испытывают в безнадёжном проекте. В своём письме ко мне Dale Emery рекомендует, чтобы менеджер проекта внимательно следил за процессами, происходящими в команде:

Уделяйте внимание взаимоотношениям, складывающимся в команде, и не жалейте усилий на поддержку готовности людей к совместной сверхурочной работе. Давление, которое испытывают участники безнадёжного проекта, может превратить небольшие недоразумения в большие конфликты. Периодическое «измерение температуры» в группе может помочь вам и команде справляться с проблемами во взаимоотношениях, когда они ещё находятся в самом зародыше.


В худшем случае может случиться, что команда так и не пройдёт первые две стадии, или, иначе говоря, встанет на путь «командного самоубийства», не сумев справиться с перечисленными выше проблемами. Если через какое-то время менеджер проекта (или кто-нибудь из более высокого руководства) обнаружит, что так оно и произошло, может оказаться слишком поздно формировать новую команду. Се ля ви.

4.5 Условия работы

Проблемы создания нормальных условий для работы уже так много лет обсуждаются среди разработчиков ПО, что кажется бессмысленным снова их поднимать. Tom DeMarco и Tim Lister, чья книга уже не раз цитировалась в этой главе, уделяют большое внимание тем преимуществам, которые даёт создание нормальных условий для работы; например, если разработчики ПО работают в достаточно тихом помещении, вероятность появления у них ошибок уменьшается на одну треть по сравнению с теми, кто работает в шумном офисе и постоянно отвлекается на посторонние дела. Проанализировав работу 600 разработчиков ПО, DeMarco и Lister смогли получить результаты, убедительно говорящие о том, что продуктивность работы тех, кто находится в хорошем офисе и может закрыть дверь, не отвечать на телефонные звонки и не отвлекаться на посторонние дела, почти в 2,6 раза выше, чем у находящихся в обычном офисе.

Хотя DeMarco и Lister опубликовали свою работу в 1987 году, с тех пор в условиях работы большинства разработчиков ПО мало что изменилось — за исключением фирм-разработчиков ПО. Условия работы в Microsoft и в большинстве других софтверных компаний Силиконовой Долины в самом деле достаточно цивилизованные — отдельные помещения с закрытыми дверями, наличие содовой, сока и других напитков, и «постоянный» телефонный номер, который остаётся за программистом даже в том случае, если он перебирается в другое помещение.

Что касается разработчиков ПО, работающих в банках, страховых компаниях, правительственных учреждениях, промышленных предприятиях и сотнях других компаний, которые до сих пор смотрят на программное обеспечение как на «накладные» расходы, то им приходится работать не в нормальных офисах, а в отгороженных клетушках, где возможность сконцентрировать свои умственные усилия на решении какой-либо проблемы варьируется от плохой до полностью отсутствующей. Звучит набившая оскомину музыка, не прекращаются телефонные звонки, лают собаки, кричат люди, и нет никакого спасения от кого угодно (от курьера до директора), кто может засунуть голову в твою комнату и отвлечь тебя. Как отмечают DeMarco и Lister:

Проектировщики с полицейскими наклонностями проектируют рабочие места наподобие тюрем: оптимальная вместимость при минимальных затратах. Мы бездумно соглашаемся с ними в вопросах проектирования рабочих мест, хотя в большинстве организаций, испытывающих проблемы с продуктивностью работы, не существует более подходящего фактора её повышения, чем рабочие места.
До тех пор, пока сотрудники будут тесниться в шумных и неприспособленных помещениях, нельзя говорить о сколько-нибудь продуктивной работе.


К сожалению, мои рассуждения относительно сложившейся ситуации вряд ли смогут оказать на нашу индустрию большее воздействие, чем гораздо более детальные и убедительные выкладки DeMarco и Lister. Однако не следует забывать, что мы здесь говорим о безнадёжных проектах, к которым применимы другие правила, и я думаю, что менеджеру проекта следует принять такую философскую позицию, которая подразумевает отсутствие вообще каких бы то ни было правил.

Если вы являетесь менеджером безнадёжного проекта с практически нереальными сроками, то сведений о том, что хорошие условия работы могут улучшить продуктивность в 2,6 раза, может оказаться достаточно, чтобы заставить вас сломать множество преград. То, чего вам удастся в этом деле достичь, может оказаться всего лишь временным; как только проект закончится, налетит хозяйственная служба, все отберёт и вернёт вас обратно в крохотные клетушки. Однако, если безнадёжный проект продолжается хотя бы полгода, и вы достаточно изобретательны, стоит попытаться обеспечить подходящие условия для работы таким образом, чтобы хозяйственная служба вообще не знала о том, что происходит.

Для этого есть несколько возможностей:

32) Лобовая атака — если у вашего проекта есть защитник и/или владелец, которые крайне заинтересованы в его успехе, объясните им, насколько важно, чтобы проектная команда работала в хороших условиях. Если защитник проекта является руководителем высокого уровня, то организовать временный переезд команды в более подходящее помещение будет относительно несложно.

33) Самовольный захват — не спрашивая ни у кого разрешения, займите какое-нибудь пустое помещение, которое пока никем не занято, в то время как хозяйственная служба пытается подсчитать, сколько сотен людей они смогут туда впихнуть. Такой захват обеспечит 90% успеха в борьбе за условия работы; пока бюрократы будут ругаться, спорить и отправлять в разные стороны гневные послания, вам, может быть, уже удастся закончить проект и незаметно удалиться на прежнее место.

34) Дистанционный доступ — разрешите всем работать дома и организуйте еженедельные рабочие совещания в ближайшем «МакДональдсе» (в 9 часов утра, когда почти нет посетителей). Пока кто-нибудь обнаружит исчезновение команды, может пройти не одна неделя. Для дополнительного отвлечения внимания можно посадить чучела за столы, которые обычно занимала проектная команда; руководству понадобится достаточно много времени, чтобы отличить их от других зомби, сидящих в офисе.

35) Переход в ночную смену — это более радикальный вариант, однако он может оказаться достаточно эффективным, если большая часть работы может выполняться без взаимодействия с пользователями. Не слишком приятно просить людей работать в ночное время вместо дневного, однако фактически это гарантирует отсутствие обычных отвлечений. Подобная стратегия наверняка вызовет гнев местных бюрократов, но самая замечательная вещь заключается в том, что бюрократы не остаются в офисе до полуночи! Они будут слать сердитые записки и послания по электронной почте, при этом следует игнорировать их и делать вид, что никогда их не получали. Если это не удаётся, просто откажитесь менять свой график работы; пока они не додумаются отключать свет или поменять замки на двери офиса, вряд ли им удастся помешать вам в рамках обычного безнадёжного проекта.

36) Преграды и заслоны — если ваша команда работает в обычном «открытом» офисе и упомянутые выше стратегии неприменимы, тогда постарайтесь сделать все возможное, чтобы сосредоточить команду в смежных помещениях. После этого сделайте все необходимое, чтобы забаррикадироваться от остальной толпы в офисе. Отключите селекторную связь и вопящий из угла громкоговоритель (и будьте готовы проделывать это еженедельно, поскольку обслуживающий персонал может снова включить их). Выключите телефоны из сети, или, как советуют DeMarco и Lister, набейте вату в звонок. Если вы сможете проделать такое на целом этаже или вообще во всем здании, то будет ещё лучше. Поднимите над зданием пиратский флаг, как это сделал Стив Джобс со своей командой в Apple во время проекта Macintosh. Установите охрану, чтобы гнать прочь непрошеных визитёров.

Некоторые из этих могут спровоцировать более резкую ответную реакцию корпоративной бюрократии, чем другие; команда и её менеджер должны решить, какая стратегия будет наиболее эффективной. Но я хотел бы подчеркнуть, что вполне серьёзно рассматриваю все эти стратегии, невзирая на очевидный факт, что они нарушают «правила игры», принятые почти в каждой крупной компании. Бороться с бюрократией таким способом — не для робкого десятка; но ведь и сами безнадёжные проекты тоже не для робкого десятка. Если менеджер безнадёжного проекта не проявляет желания бороться и отстаивать право на нормальные условия работы, то с какой стати проектная команда должна проявлять готовность идти на экстраординарные жертвы ради организации и менеджера проекта?

4.6 Заключение

Талантливых исполнителей, сплочённой команды и хороших условий для работы все же недостаточно, чтобы гарантировать успех безнадёжного проекта. С другой стороны, их отсутствие почти наверняка гарантирует провал проекта. Как будет ясно из следующих двух глав, хорошо организованные процессы разработки и хорошая технология также являются важными составляющими успеха; однако, все же самая главная составляющая — это люди. Как сказал Рональд Рейган: «Окружите себя самыми лучшими людьми, которых вы только сможете найти, передайте им в руки власть и не мешайте им».



Литература к главе:

• Tom DeMarco, Tim Lister. Peopleware. Dorset Publishing, 1987.

• Frederick Herzberg. One More Time: How Do You Motivate Employees? Harvard Business Review, September-October 1987.

• John Boddie. Crunch Mode. Englewood Cliffs: Prentice-Hall/Yourdon Press, 1987.

• Rob Thomsett. Effective Project Teams: A Dilemma, a Model, a Solution. American Programmer, July-August 1990.



Дополнительная литература:

• Larry Constantine. Constantine on Peopleware. Englewood Cliffs, NJ: Prentice Hall, 1995

• Watts Humphrey. Managing for Innovating: Leading Technical People. New York: McGraw-Hill, 1987.

• Gerald M. Weinberg. Understanding the Professional Programmer. New York: Dorset House, 1988.

• 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», что означает «сортировать, классифицировать». AmericanHeritageDictionary (3-е издание) определяет его следующим образом:

triage — существительное



1) Процесс распределения раненых по группам в зависимости от их потребности в оказании немедленной медицинской помощи. Применяется на поле боя, в местах катастроф и госпиталях в условиях ограниченных медицинских ресурсов.

2) Система, используемая при распределении дефицитных товаров (например, продовольствия) среди тех, кто способен получить от этого наибольшую выгоду.



Большинство из нас знакомы с медицинской трактовкой этого термина, однако для безнадёжных проектов более подходящим является второе определение: распределение дефицитных ресурсов (самым дефицитным из которых обычно является время ) таким образом, чтобы извлечь из этого наибольшую выгоду. Или, как отметил Stephen Covey в [1], «главное — это быть уверенным в том, что главное — это главное». (В самом деле, можно будет достичь гораздо лучших результатов в проекте, если каждый участник команды вместо увесистого тома методологии разработки ПО получит экземпляр замечательной книги Covey!)

Большинство подходов, связанных с прототипированием и RAD, вполне сочетаются с данной концепцией, а некоторые даже явно на неё ссылаются. Однако, большинство подходов RAD делают акцент только на быстром получении некоторого — какого угодно! — результата (работающего приложения), который можно показать пользователю с целью (а) продемонстрировать, насколько ощутим достигнутый прогресс, и (б) получить замечания, касающиеся функциональности системы и (преимущественно) пользовательского интерфейса. Все это весьма полезно, однако если проектная команда будет расходовать свои ресурсы на проектирование начальных прототипов с внешне привлекательными, но несущественными возможностями, то как команда, так и пользователь будут зря терять время.

Большинство методологий разработки ПО, независимо от того, базируются ли они на классической «каскадной» модели жизненного цикла, или на более современной «спиральной» модели и прототипировании, имеют незаметное на первый взгляд, но довольно коварное свойство. Оно выражается следующей фразой: «неважно как, но ко времени завершения проекта мы сделаем все ». Возможно, причина этого заключается в том, что в детстве родители запрещали нам выходить из-за обеденного стола, пока мы не оставим пустые тарелки; в любом случае, невысказанный девиз многих проектных команд — «мы не оставим невыполненным ни одного требования».

Разумеется, это честный девиз, но в безнадёжных проектах он почти всегда невыполним. Как я уже отмечал в главе 1, в большинстве безнадёжных проектов «официально утверждённые» требования превышают ресурсы проектной команды — в особенности, человеческие и временные ресурсы — на 50-100 процентов. В этой ситуации неопытная команда надеется, что, работая сверхурочно вдвое больше, она сможет как-нибудь покрыть этот дефицит; а циничная команда «самоубийственного» проекта предполагает, что их проект все равно затянется на 50-100 процентов по сравнению с первоначальным планом, как и любой другой проект. Но даже если циничная команда ошибается в этом, она все равно предполагает, что раньше или позже (обычно гораздо позже!) она в конце концов реализует все функции, которые требовались пользователю.

Один из ключевых моментов в безнадёжных проектах состоит в том, что некоторые требования не просто останутся невыполненными до официального срока завершения проекта, но и не будут выполнены никогда. Если предположить, что известное правило «80-20» справедливо, то проектная команда сможет добиться 80 процентов «эффекта» от разработанной системы, реализовав 20 процентов требований к ней — при условии правильного выбора этих 20 процентов. И, поскольку пользователю, как правило, не терпится получить работающую систему задолго до того срока, который проектная команда считает разумным, то он может взять эти готовые 20 процентов, приступить к их использованию и навсегда позабыть об оставшихся 80 процентах функций системы.

Это, конечно, чересчур упрощённый подход, но, тем не менее, почти во всех безнадёжных проектах, в которых я принимал участие, приходилось устанавливать приоритеты, разделяя все требования к системе на три категории: «необходимо выполнить», «следует выполнить» и «можно выполнить». Смысл этих категорий очевиден, и тот факт, что их всего три, предупреждает любые бесполезные дискуссии на тему о приоритетах, например, какой приоритет присвоить конкретному требованию — шестой или седьмой. При такой расстановке приоритетов в проекте очевидная стратегия будет заключаться в следующем: в первую очередь сосредоточиться на требованиях, которые необходимо выполнить; затем, если останется время, сосредоточиться на требованиях, которые следует выполнить; и наконец, если произойдёт чудо, заняться требованиями, которые можно выполнить.

Если не следовать такой стратегии с самого начала проекта, то к концу он окажется в крайне неприятной кризисной ситуации. Чтобы понять, почему это происходит, рассмотрим типичный график проекта, изображённый на рис. 5.1:



Начало проекта — Середина проекта — Кризис — Окончание

Рис. 5.1 График проекта



Когда проект начинается, никто и слушать не желает, что его сроки нереальны — в особенности все пользователи и высшее руководство. У менеджера проекта и участников команды может возникнуть неприятное ощущение, что им предстоит выполнять «самоубийственную» миссию, однако если они — оптимисты, то могут поверить, что проект будет иметь характер «невыполнимой миссии» и впоследствии какое-нибудь чудо придёт им на помощь. В этот момент самым важным является то, что конечный срок ещё достаточно далеко (через шесть месяцев или год), и никто не хочет всерьёз задумываться о невыполнимости поставленных задач.

В самом деле, политическое давление и неопытность проектной команды могут привести к тому, что даже в середине проекта он не будет подвергнут никакой переоценке. Как не смешно это звучит, но проблема может оказаться ещё более сложной, если проектная команда использует какую-либо разновидность RAD-подхода, поскольку они, вероятно, уже продемонстрировали пользователю один или более прототипов системы и тем самым поддержали у него иллюзию, что все будет сделано вовремя. Однако, к этому моменту проектная команда скорее всего начнёт понимать, что они пытаются прыгнуть выше головы, и если для менеджера этот безнадёжный проект — первый, он будет наивно верить, что высшее руководство и пользователи тоже в конце концов их поймут.

Увы, но обычно этого не происходит. В конце концов наступает кризис, когда пользователи и/или высшее руководство оказываются вынуждены посмотреть в лицо реальности: несмотря на их требования и искренние заверения менеджера проекта, система не будет готова в срок. Обычно это случается за месяц до окончания проекта, иногда за неделю, а иногда и через день после официального окончания! Последствия могут быть различными: это зависит от степени напряжённости политических баталий к этому моменту, а также от степени изнурённости и разочарованности менеджера проекта. Тем не менее, при этом, как правило, происходит следующее: высшее руководство приходит к выводу, что во всем виноват менеджер проекта, и в итоге несчастного увольняют (если только он сам уже не уволился!) и ставят нового с требованием «ликвидировать весь этот бардак и сдать систему вовремя».

Новый менеджер может быть как закалённым ветераном из самой организации, так и сторонним консультантом. Иногда случается так, что он в самом деле обнаруживает ряд грубых ошибок, сделанных его предшественником (например, отсутствие планирования вообще или отсутствие рабочих графиков) ; иногда новый менеджер приходит к выводу, что его предшественник в основном делал все правильно, но не смог избежать участи козла отпущения, когда высшее руководство наконец убедилось, что их первоначальные требования невыполнимы.

Однако, независимо от его оценки, почти не подлежит сомнению, что новый менеджер должен быть готов к следующему: все проектные требования в полном объёме не удастся реализовать в соответствии с первоначально установленным сроком — если бы это было не так, то предыдущего менеджера вряд ли бы уволили. Итак, что же следует предпринять новому менеджеру? Две наиболее очевидные возможности заключаются в следующем:

1) пересмотреть срок окончания проекта;

2) пересмотреть требования к системе.

(Консультант John Boddie предлагает ещё одну возможность: менеджер проекта может стать одним из тех, кто добьётся официального прекращения проекта, если его действительно невозможно спасти. Новому менеджеру сделать такое гораздо проще, чем его предшественнику, поскольку тот вложил в проект столько личных усилий и эмоций, что ему трудно представить себе, как вообще можно прекратить проект. Boddie даёт несколько хороших советов относительно политически приемлемых способов прекращения проекта в своей статье «Calling Doctor Kevorkian», опубликованной в журнале American Programmer, February 1997.)

Первая возможность в принципе вполне допустима, однако в безнадёжном проекте практически нереальна. В самом деле, ведь основной причиной, побудившей пользователей настаивать на таких нереальных планах, является неотложная потребность в системе, которая позволила бы им справиться со своими проблемами в бизнесе. Поскольку новый менеджер приходит в проект в тот момент, когда уже близок первоначально установленный срок завершения, высока вероятность того, что пользователи уже строят планы эксплуатации новой системы. Последнее, что им хотелось бы слышать — это то, что проект продлится ещё 6-12 месяцев.

Поэтому наиболее часто — и успешно — применяемый приём заключается в определении приоритетов для первоначальных требований. Отметим, что при этом новый менеджер разговаривает с позиции силы — это не его вина, что проект оказался в таком плачевном состоянии; при этом не высказывается вслух, но подразумевается, что руководство и пользователи в первую очередь были настолько глупы, что позволили загнать себя в такой тупик. Новый менеджер может даже поставить своё согласие на участие в проекте в зависимость от успешного окончания переговоров — например, заявив: «Если вы хотите, чтобы я вытащил вас из этой ямы, то должны принять как факт, что мы сможем реализовать в срок только небольшой процент первоначально заданных функций. Таково реальное положение вещей, согласны вы с ним или нет».

Такое заявление будет прямым и честным, хотя и обескураживающим. Однако при этом уместно задать вопрос: что же делать со всем тем, что было наработано до наступления кризиса и прихода нового менеджера? Ведь команда, вероятно, уже успела много напрограммировать и оттестировать, и может быть, даже успела разработать некоторую документацию и проектные модели. Что же делать со всей этой частично выполненной работой. Наиболее разумный ответ: большую часть придётся выбросить.

Такое утверждение может показаться чересчур пессимистичным. В самом деле, почему бы просто не отложить всю частично выполненную работу в сторону и вернуться к ней позднее? В лучшем из миров так оно и происходит; однако это возможно при наличии хороших средств и процессов контроля версий, конфигурационного управления, контроля исходного кода и т.д. — всего того, что отвергается в пылу сражения, когда все усилия команды сосредоточены на получении как можно больших результатов.

Реальная причина, по которой вся эта частично выполненная работа превращается в напрасный труд, заключается в следующем: ни у кого не найдётся времени, чтобы снова к ней вернуться. Предположим, что участники проектной команды (теперь уже под руководством нового менеджера, к которому они могут относиться с уважением или нет) способны реализовать только самый минимум необходимых функций, причём работа над проектом обычно доводит их до такого истощения, что половина из них уходит. Кроме того, проект уже так осточертел пользователям, что они не будут приставать с вопросами относительно функций, оставшихся нереализованными; или же, наоборот, они будут настолько довольны минимальным набором функций, что также никогда не потребуют доделать систему до конца. Даже если они это сделают, и даже если проектная команда все ещё будет существовать в первоначальном составе, высока вероятность, что в попытках реализовать «скелет» системы в неё будет внесено так много архитектурных изменений, что наполовину законченные компоненты системы (соответствующие второстепенным функциям) никогда больше не будут использоваться.

Заметьте, что мы в данном обсуждении ещё ни разу не коснулись таких тем, как структурный анализ, SEI-CMM или любые другие «книжные» методологии и процессы создания ПО. Все, что говорилось по поводу приоритетности, продиктовано исключительно здравым смыслом, что для безнадёжных проектов является критически важным. Чтобы эта концепция работала, все акционеры и заинтересованные лица должны принять согласованное решение, какие требования следует отнести к категории «необходимо выполнить», какие к «следует выполнить» и какие к «можно выполнить». Разумеется, если владелец проекта категорически настаивает на том, чтобы все требования были обязательно выполнены, все дальнейшее обсуждение будет пустой тратой времени. (На самом деле, я бы порекомендовал менеджеру проекта и его команде использовать такое обсуждение в самом начале проекта как лакмусовую бумажку. Если пользователи, владелец проекта, высшее руководство, акционеры и заинтересованные лица не желают принимать такой подход к расстановке приоритетов требований, то наиболее разумным ответным шагом будет выйти из проекта, пока не поздно. В качестве дополнительной лакмусовой бумажки следует предложить пользователям разделить все требования на три равные группы в соответствии с вышеуказанными категориями. Это может уберечь от того, чтобы 90 процентов требований были объявлены критическими.) Если различные акционеры и заинтересованные лица никак не могут достичь консенсуса по поводу отнесения требований к той или иной категории, то проектная команда, пытаясь удовлетворить всех, в результате окажется парализованной из-за отсутствия необходимых ресурсов.

К сожалению, «суровая реальность» такова, что большинство организаций не обладает необходимой дисциплиной, опытом и политической силой, чтобы определить приоритет требований в самом начале проекта. Все, что я описал в предыдущих абзацах, вовсе не является чем-то заумным, и даже самый технологически необразованный менеджер или пользователь в состоянии это понять; в самом деле, этот подход одинаково хорошо подходит для любых проектов с ограниченными ресурсами и недостатком времени. Однако, даже если все хорошо понимают, о чем идёт речь, политические баталии вокруг безнадёжного проекта могут сделать почти невозможным достижение консенсуса по приемлемым для всех приоритетам. Только когда в проекте наступит кризис, тогда, наконец, противоборствующие стороны придут к соглашению, которое им надо было бы достичь в самом начале проекта.

Из таких мрачных прогнозов можно сделать одно исключение: оно касается организаций, для которых безнадёжные проекты являются образом жизни. Разумеется, пользователи и высшее руководство не дураки, и они обычно извлекают уроки из своего опыта, даже если для их усвоения потребуется три или четыре проваленных проекта. Как было отмечено выше, первого менеджера безнадёжного проекта обычно губит неспособность расставить приоритеты в начале проекта, в то время как выжившие постепенно до этого доходят. Я ещё вернусь к этим вопросам в главе 7.

5.2 Важность управления требованиями

Все вышесказанное предполагает, что в безнадёжном проекте необходимо уделить особое внимание такому относительно новому аспекту жизненного цикла разработки ПО, как требованиям. Почему я употребил определение «новому»? В конце концов, каждый проект содержит требования, и нельзя сказать, чтобы разработчики были совсем уж незнакомы с этим понятием.

Традиционные методологии создания ПО — включая различные «структурные» и «объектно-ориентированные» методологии, разработкой которых некоторые мои коллеги и я занимались более 20 последних лет — сосредоточены на моделировании требований, обычно с помощью таких графических средств, как диаграммы потоков данных или диаграммы «сущность-связь». Но я в данной главе говорю именно об управлении требованиями в той лихорадочной обстановке, которая присуща безнадёжному проекту.

Эти два понятия — моделирование и управление — не являются противоречивыми или несовместимыми. Можно потратить время и силы как на одно, так и на другое; если команда безнадёжного проекта считает, что для лучшего понимания требований к системе полезно построить объектно-ориентированную модель, у меня нет никаких возражений. Я только хотел бы предостеречь проектную команду, чтобы она делала то, что именно она сама считает важным и полезным, а не то, что считают «правильным» блюстители чистоты методологии (здесь частично затрагиваются вопросы «наилучшей» практики, которые будут обсуждаться ниже).

Мой опыт говорит о том, что в большинстве безнадёжных проектов не используются формальные методы моделирования, такие, как SA/SD или OOA/OOD. Отчасти это из-за того, что эти методологии кажутся проектной команде слишком громоздкими и бюрократическими; отчасти из-за того, что CASE-средства, поддерживающие эти методологии, кажутся слишком неудобными для использования; и, как правило, из-за того, что они не видят, каким образом можно преобразовать полученные в результате анализа модели в работающий код — единственное, что в конечном счёте нужно пользователю. (В «нормальном» проекте, наоборот, SA/OOA-модели сами по себе воспринимаются, как весьма полезные. Пользователи и специалисты, определяющие бизнес-политику организации, будут толпиться вокруг диаграмм потоков данных и тихо бормотать друг другу: «Так вот в чем заключается наш бизнес! Может быть, имеет смысл провести реинжиниринг бизнес-процессов и изменить все это перед тем, как создавать новую автоматизированную систему».)

В самом деле, в экстремальной ситуации проектная команда даже не будет документировать ни одно из пользовательских требований; в своё оправдание (которое наверняка слышал каждый менеджер проекта!) они говорят, что это требует слишком много времени, требования слишком часто меняются и, кроме того, пользователи сами не знают, что им нужно. Таким образом, команда обычно полагается на методы и средства прототипирования, с помощью которых можно наглядно продемонстрировать всю важную проектную работу, а также выявить реальные требования к системе.

С точки зрения «приоритетности», о которой шла речь в разд. 5.1, все это порождает одну главную проблему: невозможность сколько-нибудь организованным способом управлять требованиями. Как можно в любой момент времени сказать, какие требования «необходимо выполнить», какие «следует выполнить» и какие «можно выполнить»? Интересно отметить, что методологии SA/SD и OOA/OOD также не дают ответа на этот вопрос. Можно, конечно, определять приоритеты, раскрашивая кружочки на диаграммах потоков данных, но они изначально предназначены вовсе не для этого. Методологии SA/SD и OOA/OOD предназначены в первую очередь для понимания и объяснения требований, а не для управления ими в динамике.

Именно динамическая составляющая управления требованиями обычно вызывает наибольшие трудности. Если бы вам в самом начале проекта удалось убедить всех акционеров и заинтересованных лиц согласиться с приоритетностью требований, и если бы эти приоритеты никогда не менялись в течение проекта … ну что ж, если вы в самом деле в это верите, то вы, наверное, также верите в фей и колдунов. В реальных же безнадёжных проектах обычно возникают в различных вариантах следующие дилеммы:

3) Акционеры и заинтересованные лица не могут полностью согласиться с предложенными приоритетами. Разумеется, если они совсем не согласны, проект будет просто парализован; однако, нередко можно встретиться с такой ситуацией, когда для 80 процентов требований устанавливаются приоритеты и начинается работа над проектом, в то время как политиканы продолжают спорить относительно оставшихся 20 процентов. В результате этих споров требования с высоким приоритетом иногда появляются в самый последний момент. Это ставит перед проектной командой трудную задачу, однако вряд ли возможно этого избежать.

4) Во время проекта изменяется ситуация в команде. Например, в одно прекрасное утро менеджер проекта приходит в офис и обнаруживает, что два его лучших программиста, Матильда и Эзекиель, решили создать реггей-бэнд и только что уехали в Нэшвил в поисках контракта для записи диска. Никто не предполагал, что такое может случиться, однако это случилось. Первые три вопроса, которые вынужден выяснить менеджер, заключаются в следующем: «Над какими обязательными требованиями работали эти мерзавцы, каков статус этих требований и кому я могу их перепоручить?»

5) Изменяются обстоятельства вовне проектной команды. В зависимости от финансовых успехов компании увеличивается или уменьшается бюджет. Срок окончания проекта отодвигается или приближается (и даже очень сильно) в зависимости от того, насколько департамент маркетинга осведомлён относительно изменения конкурентной ситуации на рынке. Меняются решения правительства, меняются технологии (не всегда в лучшую сторону!), поставщики приходят и уходят, и т.д., и т.п. Каждое из этих внешних событий может оказать некоторое воздействие на решения, принятые в отношении приоритетов требований.

6) Нередко наступает «момент истины», когда пользователи, высшее руководство и участники проектной команды вынуждены признать, что система не будет готова в срок. Разумеется, если в начале проекта была проделана достаточно квалифицированная работа по определению приоритетов требований, такой кризис может и не наступить вообще. Но что если команда вынуждена признать, что она не может выполнить в срок даже все необходимые требования? Как было отмечено выше, менеджеру проекта обычно «снимают голову» и заменяют на другого; при этом, если новому менеджеру удаётся отодвинуть конечный срок, то приоритеты могут быть оставлены без изменения. Однако в этот момент все же, как правило, ранее принятые решения подвергаются серьёзному пересмотру. Конечный срок уже маячит впереди на расстоянии нескольких недель, и пользователи могут волей-неволей согласиться с тем, что некоторые требования, считавшиеся ранее абсолютно необходимыми, вообще перестают быть таковыми.

Этот перечень можно продолжать дальше, но думаю, что вывод ясен: управление приоритетом требований является критически важной частью «процесса» безнадёжных проектов. Конечно, если безнадёжный проект содержит всего дюжину требований, то управлять ими будет совсем несложно; можно нацарапать их на бумажной салфетке и просто пересматривать по мере необходимости. Однако, большинство проектов включает сотни требований, а многие — даже тысячи; проект самолёта Боинг-777 (который вполне можно считать мешком программ с крыльями) включал, по слухам, 300.000 требований. Но это ещё не все, ведь требования обычно не являются независимыми; некоторые требования зависят от других требований, а некоторые в свою очередь порождают другие требования.

Все это подразумевает необходимость в методах, процессах и средствах для описания зависимостей между требованиями и управления большим количеством таких зависимостей. В решении данной проблемы могут, конечно, помочь такие известные методы, как структурный анализ и объектно-ориентированный анализ, но, к сожалению, до сих пор эти методы традиционно игнорировали атрибуты требований, такие, как приоритет, стоимость, риск, план, владелец и разработчик, который занимается его реализацией. В результате проектным командам, испытывающим потребность в управлении требованиями, приходилось использовать доморощенные средства, базирующиеся на электронных таблицах, текстовых процессорах или наспех созданных приложениях, чтобы обеспечить хотя бы некоторую степень автоматизированной поддержки.

К счастью, в настоящее время появилось новое поколение средств, обеспечивающих более комплексную и сложную поддержку управления требованиями. Вот некоторые из доступных на сегодняшний день средств: Requisite (Requisite, Inc.), DOORS (Zycad Corp.), RTM (Marconi Systems). Поскольку данная глава посвящена в основном процессам, а не средствам, я не буду вдаваться в детали этих трех продуктов; но поскольку средства влияют на процессы, важно знать хотя бы о их существовании (ветераны-разработчики ПО вспомнят старую поговорку: «Если единственным вашим инструментом является молоток, то все ваши проблемы выглядят как гвозди»).

Существует один аспект в комбинации процессов и средств, который следует особо отметить. Как было сказано выше, многие команды безнадёжных проектов отказываются от использования формальных методологий SA/SD или OOA/OOD, поскольку они выглядят слишком громоздкими и бюрократическими. Что интересно, акционеры и заинтересованные лица рассуждают точно так же. Если предоставить им выбор, то они предпочли бы, чтобы их не заставляли изучать, как читать диаграммы потоков данных; в самом деле, руководители и конечные пользователи высокого уровня иерархии жалуются, что они ничего не понимают во всех этих «технических» диаграммах. У них также не хватает терпения продираться сквозь сотни страниц с диаграммами и мелкими деталями описаний элементов данных или спецификаций процессов. Конечно, если времени и терпения достаточно, то проектная команда в состоянии преодолеть сопротивление и убедить конечных пользователей в том, что тщательно разработанные модели на самом деле приносят большую пользу — однако в безнадёжных проектах вечно не хватает ни времени, ни терпения.

Что пользователи в состоянии понимать — так это их собственный родной язык, например, английский для большинства североамериканских проектов. И что большинство из них предпочитают читать — это небольшой документ из 10-20 страниц, суммирующий все требования к системе. Требования в таком документе могут называться «характеристиками», а сам документ в целом — «Требования к системе» («Product Requirements Document» — PRD) или «спецификация высокого уровня» или ещё какой-нибудь подходящей фразой. Главное, что этот документ небольшой и на английском языке. Он не должен содержать рекламной «шелухи», а также непонятной терминологии или обозначений, заставляющих пользователей задумываться, что бы это значило. В идеальном случае каждый абзац или даже каждое отдельное предложение должны соответствовать конкретному требованию, чтобы и пользователи, и участники проектной команды могли использовать их в качестве отправной точки для своей дальнейшей работы.

Во всем этом есть один интересный момент — он заключается в том, что у нас уже одно знакомое всем средство для создания таких документов; оно называется «текстовый процессор». В самом деле, начальная версия такого документа обычно исходит от пользователей — например, в виде записки от вице-президента по маркетингу к исполнительному директору по поводу возникшей потребности в новом замечательном продукте со свойствами X, Y и Z, который мог бы соперничать с продуктом конкурента — даже когда департамент информационных технологий ещё ничего об этом не знает. На этой ранней стадии пользователи рассматривают текстовый процессор как своё средство, а записку службы маркетинга — как свой документ; в результате они проявляют гораздо большую готовность участвовать в последующих дискуссиях по поводу приоритетности требований, если при этом продолжают использоваться аналогичные средства и документы. Таким образом, мы наблюдаем тенденцию, ведущую к документо-центричному управлению требованиями, когда средства, используемые специалистами по ИТ (например, Requisite, DOORS или RTM), тесно интегрируются с текстовыми процессорами и документами, в которых пользователи хорошо разбираются (я должен честно признаться, что это в какой-то степени рекламный трюк, поскольку такая интеграция является одним из основных свойств Requisite, и я был одним из членов правления компании Requisite, когда писал эту книгу. Но поскольку я играю роль объективного автора, я искренне рекомендую вам познакомиться со всеми тремя перечисленными здесь продуктами.)

Ещё одно последнее соображение: очень важно, чтобы все акционеры и заинтересованные лица участвовали в процессе выработки начальных требований, их документирования и определения приоритетов. Разумеется, это касается любых проектов, однако нехватка времени и политические баталии, присущие безнадёжным проектам, нередко соблазняют менеджера проекта рассуждать следующим образом: «Ладно, мы будем двигаться дальше и обойдёмся без этого идиота Мелвина из департамента маркетинга; все, на что он способен — это не соглашаться никогда и ни с чем». При этом может возникнуть следующая проблема: Мелвин, получив серьёзную «политическую» пощёчину и чувствуя, что его игнорируют (и что менеджер проекта считает его идиотом!), скорее всего найдёт способ саботировать проект.

Теоретически каждый понимает и соглашается с такой точкой зрения, однако на практике просто удивительно наблюдать, как безнадёжные проекты потихоньку обрастают все новыми и новыми требованиями. Дополнительные требования, модификации существующих требований и недвусмысленные предложения игнорировать некоторые требования — все это сваливается на проектную команду в виде телефонных звонков, посланий по электронной почте и разговоров с глазу на глаз с менеджером проекта. Многие из этих предложений предваряются такими успокаивающими фразами, как «извини, что я забыл об этом сказать на нашем последнем совещании, но … » или «я рассчитывал, что у нашей группы управления будет время справиться с этой проблемой, но … ».

Существует ли у менеджера проекта такая формальная группа управления — т.е., группа, состоящая из акционеров и заинтересованных лиц, которая оценивает полученные в проекте результаты и принимает определённые решения относительно приоритетности требований — или нет, в данном случае не имеет значения; это зависит от того стиля управления и организации проектов, который сложился в каждой организации. Но что действительно имеет значение для успешного завершения безнадёжного проекта — это тщательное документирование каждой модификации, вносимой в исходные требования, и извещение о ней всех акционеров и заинтересованных лиц. Если вице-президент по финансам хочет потихоньку вставить в проект ещё одно приоритетное требование, это замечательно; однако при этом менеджер проекта должен позаботиться, чтобы об этом узнали вице-президент по маркетингу и исполнительный директор.

5.3 SEI, ISO-9000. Формальные процессы против неформальных

Некоторые менеджеры, прочтя предыдущий раздел данной главы, могут высказать недовольство: «Вот здорово! Это выглядит гораздо более формальным, чем все, что мы когда-либо делали!» Когда мне приходилось сталкиваться с такой реакцией в некоторых консалтинговых проектах, это просто ставило меня в тупик. С одной стороны, я уверен, что документирование, определение приоритетов и управление требованиями просто необходимы (независимо от того, какие средства и методы для этого используются) ; с другой стороны, я опасаюсь следующего: когда проектной команде, и без того заваленной работой выше головы, навязывается совершенно новый и незнакомый процесс, то этот процесс — например, управление требованиями — может оказаться последней каплей, переполнившей чашу терпения.

В самом деле, у меня нет для этой дилеммы другого решения, кроме как надеяться, что проектная команда все же сможет справиться с одной новой идеей среди прочих своих средств и процессов. Однако, меня охватывает гораздо большее беспокойство, когда я вижу команды, которые предпринимают свой первый безнадёжный проект с решением (или, что более вероятно, с указанием, навязанным им блюстителями методологии), обязывающим их использовать формальные процессы, например, те, которые регламентируются SEI-CMM или ISO-9000. Формальные процессы — это великая вещь, если вы хорошо знаете, что делаете, и если вы уже использовали их прежде. Однако, реальность такова, что такие формальные процессы, как правило, ранее вообще не использовались в организации, и безнадёжный проект представляет собой пилотный проект для апробации структурного анализа или ISO-9000.

Какое безумие! Это действительно последняя капля, которая переполнит чашу терпения; в конце концов типичный безнадёжный проект пытается выполнить то, что раньше никогда не делалось, и (несмотря на мои предостережения в главе 4) команда нередко состоит из людей, которые никогда раньше не работали вместе. Так мало того, они ещё вынуждены осваивать использование незнакомой методологии или процесса, не будучи уверенными в том, что это им необходимо в первую очередь, и, напротив, будучи убеждёнными, что это только затормозит их работу. Чему же тогда удивляются блюстители методологии, когда они в подобных обстоятельствах сталкиваются с сопротивлением? Консультант Doug Scott недавно привёл мне пример такой ситуации:

В одном проекте, насколько мне известно, потребовался диаграммер для ERD, и они приобрели Excelerator. Обнаружив, что он поддерживает методологию SSADM, они внедрили её без какого-либо обучения персонала, после чего обнаружили, что темп работы на проектом значительно снизился (фактически, работа просто остановилась), в то время как каждый был занят чтением руководств, освоением средств и решением проблемы, что делать дальше (или переделывать то, что было сделано в «неправильном» порядке). Почти идеальный сценарий для тех, кто наблюдает за безнадёжными проектами.


Чтобы достичь успеха, проектная команда должна придти к соглашению, какие процессы будут формализованы — например, контроль исходного кода, управление изменениями и (хорошо бы) управление требованиями — и какие будут выполняться на полностью неформальной основе (например, проектирование пользовательского интерфейса). Бессмысленно навязывать какой-либо процесс в обязательном порядке, если никто не собирается ему следовать. Блюстители методологии просто зря теряют время, пытаясь сделать это, а в результате, что гораздо хуже, может напрасно потерять время проектная команда (во многих случаях эти деятели не совершают ничего полезного, кроме суеты вокруг департамента информационных технологий и надоедания и без того уставшей от всего проектной команде).

Это означает, что менеджер безнадёжного проекта должен безоговорочно настаивать на процессах, которые он считает принципиально важными — например: «Каждый, кто посмеет внести изменения в исходный код, минуя процесс управления изменениями, будет немедленно уволен!» Или проектная команда должна сама сознательно пойти на внедрение процесса, понимая, что это позволит сократить затраты. Такое может скорее произойти в том случае, если участники команды ранее уже работали вместе и приобрели общий опыт использования различных процессов создания ПО; и наоборот, это маловероятно, если только один из участников команды встанет и скажет: «Я глубоко уверен, что структурный анализ является критически важным для успеха нашего проекта», в то время как другие и понятия не имеют, о чем это он говорит. Ещё одно утверждение, следующее из этого правила: попытка внедрить в безнадёжном проекте новый, незнакомый процесс может закончиться катастрофически, даже если команда верит, что он может помочь в работе. Проблемы с освоением, неизбежная путаница и споры по поводу деталей процесса обычно сводят на нет все выгоды.

Это означает, что такие формальные подходы, как SEI-CMM, ISO-9000 или внедрение новых методологий анализа/проектирования должны иметь место где-нибудь за пределами безнадёжного проекта. Внедрение таких процессов имеет смысл как часть долговременной корпоративной стратегии, и должно начинаться с выполнения пилотного проекта (который не должен быть безнадёжным проектом), сопровождаясь организацией необходимого обучения.

Если все это уже сделано, и если все другие разработки ПО в организации уже выполняются на третьем уровне SEI-CMM, то интересно выяснить, следует ли также использовать такие процессы в безнадёжном проекте. Как однажды заметил Watts Humprey на конференции в докладе по поводу SEI-CMM: «Если процесс нельзя использовать в критических условиях, его вообще не следует использовать».

Я не уверен, что многие согласятся с этим утверждением, особенно если безнадёжный проект рассматривать как единственное в жизни исключение из правил. Если это в самом деле так, то, возможно, имеет смысл отказаться от формальных процессов и предоставить проектной команде возможность использовать любые методы, которые она сочтёт приемлемыми. Однако не забывайте при этом моё утверждение, высказанное в главе 1: безнадёжные проекты становятся нормой, а не исключением. Если это так, то официально принятые в организации процессы следует, при необходимости, усовершенствовать, чтобы сделать их пригодными для использования в безнадёжном проекте. Тогда и только тогда утверждение Humprey будет иметь смысл.

Между прочим, если вы в самом деле столкнулись с потребностью усовершенствовать сложившуюся практику работы команды безнадёжного проекта, я рекомендую обратиться к методологии PSP (Personal Software Process), автором которой является Watts Humprey. Её основные положения изложены в моей книге «Rise and Resurrection of the American Programmer. Можно также прочесть книгу [2], хотя я честно предупреждаю: в ней 789 страниц.

5.4 «Достаточно хорошее» программное обеспечение

Определение приоритетов требований, обсуждавшееся выше, может быть одним из способов, помогающих безнадёжному проекту двигаться в «разумном» направлении. Для достижения успеха вовсе не обязательно реализовывать все требования; будет «достаточно хорошо», если мы сможем реализовать требования, которые «необходимо выполнить», и приемлемое количество требований, которые «следует выполнить».

Существует, однако, ещё один аспект в разработке ПО, порождающий трудности в безнадёжных проектах: неявно подразумеваемое требование достижения идеального качества. Обычно оно выражается в терминах количества дефектов (ошибок), но может быть также выражено в терминах переносимости, независимости от платформы, гибкости, сопровождаемости и других «стей». Даже в «нормальных» проектах достаточно трудно удовлетворить всем этим требованиям, а в безнадёжных проектах сделать это просто невозможно. Вместо этого проектная команда должна придти к решению — и по возможности согласовать его с акционерами и заинтересованными лицами — относительно того, какое качество является достаточно хорошим.

Важность такого решения объясняется тем, что достижение абсолютного качества съедает все ресурсы проекта — особенно время. Если вы хотите разработать сертифицированную, не содержащую ошибок программу и математически доказать её корректность, на это потребуется время. Это может также потребовать более высокого уровня таланта и способностей, чем те, которыми располагает проектная команда. Кроме того, одному или более участникам команды придётся расходовать дополнительную энергию, следовательно, они не смогут работать над другими задачами. Короче говоря, выполнение таких требований, как надёжность, переносимость и сопровождаемость, невозможно без компромиссов, и это необходимо учитывать в процессе определения приоритетов требований.

Командам безнадёжных проектов приходится сталкиваться с такой неприятной реальностью лицом к лицу, поскольку альтернатива — «совершённое» ПО, которое не будет готово даже тогда, когда пройдут все мыслимые сроки. Лучше всего, когда команда с самого начала проекта настроена прагматично на создание достаточно хорошего ПО, однако, мой опыт, к сожалению, говорит о том, что многие обычные разработчики ПО соглашаются с понятием достаточно хорошего ПО только тогда, когда упираются в тупик — например, когда оказываются в кризисном положении за месяц или два до окончания проекта.

Вплоть до этого момента времени они выражают своё недовольство: «Как вам понравится, если мы будем использовать ваш „достаточно хороший“ подход применительно к ПО ядерного реактора или системы управления воздушным движением?» Разумеется, я отвечу, что мне это совсем не нравится; и, если кто-нибудь вздумает затеять безнадёжный проект для создания такого рода высоконадёжных приложений, тогда я просто перестану летать на самолётах и буду держаться как можно дальше от предприятий с ядерными реакторами. С другой стороны, нам обычно и не приходится сталкиваться с безнадёжными проектами такого рода; скорее, это может быть кадровая система на ядерном предприятии или система резервирования авиабилетов. Это, конечно, не означает, что кадровые системы и системы резервирования авиабилетов должны работать со сбоями, однако все же непосредственные последствия этих сбоев будут не столь серьёзны.

В любом случае, совершённая надёжность, сопровождаемость, переносимость и т.д. не являются необходимыми, практичными или даже желательными в большинстве безнадёжных проектов. В самом деле, достичь такого совершенства невозможно даже в «нормальных» проектах, хотя в этом случае мы можем позволить себе установить планку своих стандартов гораздо выше, поскольку не связаны такими жёсткими ограничениями на время, бюджет и людские ресурсы. Что же касается безнадёжных проектов, то пользователям в действительности нужна система, которая достаточно дешева, достаточно производительна, обладает достаточными возможностями, достаточно устойчива и будет готова достаточно скоро — вот в чем заключается их определение «достаточно хорошего» ПО.

Почему же нам не удаётся создать «достаточно хорошее» ПО? Это обычно объясняется совокупностью следующих причин:

7) Мы стремимся определять качество только в терминах дефектов, не задумываясь о других его аспектах — которые, с точки зрения пользователя, включают, например, готовность к определённой дате.

8) Мы предполагаем, что малое количество дефектов равносильно лучшему качеству, и полагаем, что пользователь всегда предпочитает такое качество — хотя существуют обстоятельства, когда пользователь готов пойти на компромисс и примириться с некоторыми ошибками в обмен на более скорое завершение работы или возможность продукта работать на различных программных/технических платформах и др.

9) Мы стремимся определить требования к качеству (дефектам) один раз, в самом начале проекта, и зафиксировать их, хотя обстоятельства могут измениться в течение проекта не один раз.

10) Мы так долго твердили, что процессы являются критически важными, что при этом зачастую забываем об их «нейтральности» — дурак, вооружённый процессами и средствами, все равно останется дураком. Невозможно обеспечить качество, если просто слепо следовать всем деталям методологии структурного анализа или рекомендаций SEI-CMM.

11) Мы рассматриваем обеспечение качества как процесс, укладывающийся в жёсткую схему, заданную в начале проекта раз и навсегда (или, что ещё хуже, для всех проектов во всей компании).

12) Мы недооцениваем нелинейный характер зависимостей между такими ключевыми параметрами проекта, как численность персонала, плановые сроки, бюджет и количество дефектов — все эти аспекты в безнадёжных проектах являются ключевыми.

13) Мы игнорируем динамику процессов: запаздывания, циклы обратной связи и т.д. Например, большое количество сверхурочной работы в течение данной недели может выразиться в повышении продуктивности и прогрессе в работе над проектом в целом; но, с другой стороны, оно может повлечь за собой большее количество ошибок на следующей неделе (о которых конечные пользователи и высшее руководство могут ничего и не узнать), которые снизят продуктивность работы (в терминах конечных результатов) и, может быть, даже отбросят проект назад.

14) Мы игнорируем такие факторы, как моральное состояние команды, адекватные условия для работы и др.

Каким же образом мы сможем создать «достаточно хорошее» ПО? Как отмечает James Bach [3], для этого требуется несколько вещей:

15) Утилитарная стратегия — искусство количественного анализа и максимизации чистого выигрыша в неопределённых ситуациях — обобщает идеи системного анализа, управления рисками, экономики, теории принятия решений, теории игр, теории управления и нечёткой логики.

16) Эволюционная стратегия — рассматриваемая не только по отношению к жизненному циклу проекта, но также к людям, процессам и ресурсам.

17) Героические команды — не Могучие Гениальные Программисты, а обычные умелые специалисты, способные к эффективному сотрудничеству.

18) Динамическая инфраструктура — противоположность бюрократии и засилью политики. Высшее руководство уделяет необходимое внимание проектам, уделяет внимание положению на рынке, предупреждает и разрешает конфликты между проектами, и становится на сторону проекта в случае конфликта между ним и бюрократами.

19) Динамические процессы — процессы, поддерживающие работу в эволюционирующей среде. Динамический процесс, в свою очередь, является часть идентифицируемого мета-процесса и всегда может подвергаться изменениям.

5.5 Наилучшая практика и наихудшая практика

Не один раз уже в этой книге я предупреждал об опасностях, связанных с вмешательством блюстителей методологии и попытками насильно внедрить в практику проектной команды лишённые гибкости методологии или процессы создания ПО. То же самое касается внешних консультантов, гуру, знахарей, целителей, заклинателей змей и книг. Дажеэтой книги: если то, что я рекомендую, не находит должного понимания, и проектная команда не испытывает по этому поводу особого энтузиазма, то такую рекомендацию лучше проигнорировать!

Однако это особенно справедливо по отношению к методологиям и процессам создания ПО. Вместо того, чтобы следовать рекомендуемой кем-либо практике — или, что ещё хуже, практике, навязываемой сверху руководством и комитетами по методологии, которые обычно сами не знают то, о чем они говорят — гораздо лучше следовать практике, которую сама команда считает «наилучшей» в данных обстоятельствах. В этом заключается существо подхода «наилучшей практики», который стал популярным в последние пару лет: основного подхода, принятого на вооружение организациями-разработчиками ПО, признанного удачным настоящими разработчиками.

К сожалению, у команд безнадёжных проектов практика такого рода зачастую отсутствует, поскольку их проект, как правило, рассматривается как первый проект такого рода в организации. Если он даже не первый, то все равно рассматривается как исключение — поэтому никто не побеспокоился заранее составить перечень хорошо и плохо зарекомендовавших себя методов. Что ещё хуже, большой процент безнадёжных проектов заканчивается провалом (иначе они не назывались бы «смертельными маршами»!). Таким образом, люди, которые могли бы помочь полезными советами в последующих безнадёжных проектах, уже ушли, были уволены, покончили жизнь самоубийством, заработали нервное расстройство или превратились в закоренелых циников.

Если вы в самом деле начинаете первый в организации безнадёжный проект, то, вероятно, самое лучшее, что вы можете сделать — это документально фиксировать все реально работающие процессы, которые могли бы пригодиться в последующих безнадёжных проектах. Один из способов сделать это — провести «ревизию» в самом конце проекта. Тем не менее, это делается редко, и результаты обычно настолько неинтересны, что никому неохота их читать. Причины этого очевидны: как было отмечено выше, проектная команда к концу проекта находится в таком измочаленном и потрёпанном состоянии, что предложение документально описать их опыт будет скорее всего встречено градом насмешек; кроме того, многие из тех, кто внёс наибольший вклад в работу, к концу проекта уже давно исчезли.

Таким образом, альтернативой может быть серия «мини-ревизий» в течение всего проекта. Если ваша работа состоит из мини-этапов, таких, как передача новой версии прототипа пользователю, запланируйте полдня на проведение мини-ревизии сразу после окончания этапа. Решите, что в практике работы было хорошим, а что оказалось негодным; что заслуживает особого внимания на следующем этапе, а от чего следует отказаться. Следует отметить, что такого рода «самокопание» полезно для всей проектной команды, и тот факт, что их опыт будет полезен для будущих команд безнадёжных проектов, может подсластить пилюлю. Кроме того, такое подведение итогов в конце этапа обычно поднимает дух команды, их суждения становятся более оригинальными, искренними и не такими циничными.

Что же касается организаций, которым недоступен положительный опыт других команд, то я бы порекомендовал несколько источников. Данная тема затронута в одной из глав моей книги Rise and Resurrection of the American Programmer ; другие материалы, касающиеся наилучшей практики, можно найти на сайте консультанта Кристины Комафорд http://www.christine.com. Возможно, наиболее амбициозным проектом, находящимся в настоящее время в процессе разработки, является проект министерства обороны США, информацию о котором можно найти на сайте http://spmn.com.

Ниже перечислены «наилучшие практики», рекомендуемые в этом проекте (не забывайте данный мною ранее совет о том, что не следует воспринимать эту информацию буквально как «заповедь», которой необходимо следовать; наоборот, она может служить полезной отправной точкой для ваших собственных идей относительно наилучшей практики):

20) Формальное управление рисками — я буду обсуждать его позже в данной главе.

21) Согласованные интерфейсы — аппаратные интерфейсы, программные интерфейсы и интерфейсы между вашей системой и другими внешними системами.

22) Экспертные оценки — экспертизы, проверки, сквозной контроль. Это весьма распространённая и понятная практика, однако в безнадёжных проектах от неё зачастую отказываются, поскольку считают, что это затормозит работу. В принципе, большинство из нас понимает полезность таких экспертиз, но в экстремальных условиях безнадёжных проектов каждый успевает только делать своё дело, и ему не до того, чтобы показывать свою работу остальным участникам команды.

23) Планирование и управление, основанное на метриках — речь идёт о том, что в основу наших планов и оценок должны быть положены данные, накопленные в предыдущих проектах. Однако, как было сказано выше, предыдущих безнадёжных проектов может просто не быть, а если даже они и были, маловероятно, чтобы кто-нибудь позаботился записать какие-либо полезные данные (кроме подсчёта потерь, понесённых командой). Все же, если имеются в распоряжении какие-либо данные, полученные в «нормальных» проектах, их можно было бы использовать для выверки оценок, сделанных в безнадёжном проекте — хотя бы для того, чтобы убедиться в их безумной оптимистичности!

24) Бинарная оценка качества по результатам этапов — другими словами, вместо того, чтобы заниматься подведением итогов каждые три месяца, во время которых команда рапортует, что она написала 97 процентов кода, следует подводить промежуточные итоги еженедельно, или даже ежедневно, фиксируя достигнутые результаты с помощью «бинарных» признаков. Одним из способов выполнения этого является стратегия «ежедневного завершения проекта», которая обсуждается в следующем разделе.

25) Свободный доступ к информации о проектных планах и фактических результатах — это согласуется с моими рекомендациями в предыдущих главах. Безнадёжный проект будет испытывать достаточно большие трудности, если менеджер будет скрывать от остальной команды информацию о состоянии проекта.

26) Фиксация дефектов в соответствии с заданными показателями качества — одна из идей данного проекта заключается в том, что дефекты идентифицируются, фиксируются и устраняются на ранних стадиях процесса разработки. Это позволяет не только точно установить уровень дефектности в разработанной системе, но и устранять дефекты в тот момент, когда стоимость их устранения относительно невелика, а не дожидаться стадии тестирования системы.

27) Конфигурационное управление — как бы оно не называлось (контроль версий, контроль исходных кодов, или как-нибудь ещё), конфигурационное управление обычно рассматривается как важная практическая составляющая проектов, протекающих в экстремальных условиях.

28) Ответственность и подотчётность руководства перед сотрудниками — увы, но в большинстве безнадёжных проектов этому моменту не уделяется достаточно внимания; как было отмечено выше, многие безнадёжные проекты относятся к типу «самоубийственных» или «камикадзе».

Одно из наиболее значительных достижений данного проекта министерства обороны — это понятие наихудшей практики ; особенно хорошо оно применимо к безнадёжным проектам, где зачастую бывает более важно предотвращать катастрофы, а не заниматься поисками наилучшего решения проблем. Список таких практик приведён ниже:

29) Не следует ожидать более чем 10-процентного сокращения сроков по сравнению со среднестатистической нормой для аналогичных проектов — разумеется, если вы действительно в это верите, то не следует даже и начинать безнадёжный проект!

30) Не пытайтесь использовать новую технологию как средство для сокращения сроков — у вас будет и без того достаточно проблем кроме отлавливания ошибок в бета-версиях новых средств и технологий, добытых у знакомого поставщика. Более детально этот вопрос будет обсуждаться в главе 6.

31) Не навязывайте заказчику решения, специфичные только для него — полезный совет для любого проекта.

32) Не следует заниматься поиском панацей — об этом стоит вспомнить, когда ваше руководство (сразу же после визита очередного настойчивого поставщика!) предлагает использовать для «спасения» проекта какое-нибудь «поражающее воображение» средство или методологию разработки.

33) Не упускайте возможность удалить из критического пути те элементы, которые находятся вне сферы вашего контроля — если ваша проектная команда не в состоянии их контролировать, то иметь такие элементы на критическом пути означает повышенную степень риска. Это относится к таким вещам, как инструментальные средства поставщика, оборудование, программные продукты и другие компоненты, поступающие от внешних поставщиков. Это касается также вещественных результатов деятельности и политических решений акционеров и заинтересованных лиц, имеющих отношение к проекту.

34) Не следует ожидать точной оценки состояния проекта от чисто формальных оценок, выполненных множеством чересчур активных и некомпетентных критиков — проектная команда не должна об этом беспокоиться, поскольку она уже знает, что такие сеансы оценки представляют собой политические ритуалы. Этот совет предназначен скорее для руководителей высокого уровня, которые наблюдают за безнадёжным проектом с безопасного расстояния, пытаясь при этом определить, в каком состоянии он находится.

35) Не следует ожидать, что в результате более чем 10-процентного отставания от плана удастся избежать более чем 10-процентного снижения функциональности разработанного ПО — эта рекомендация является критически важной для команды безнадёжного проекта, поскольку вероятность отставания от плана более чем на 10 процентов во время выполнения проекта достаточно высока. В самом деле, для безнадёжного проекта опасно даже 10-процентное запаздывание, поскольку команда, вероятно, уже так много работает сверхурочно, что у них просто не хватит сил, чтобы тратить каждый день на работу ещё на 10 процентов больше времени. Однако, самым главным в этой рекомендации министерства обороны является следующее: менеджер проекта должен помнить, что зависимость между временем работы команды и функциональностью ПО не является линейной.

В течение прошлого года на своих семинарах в разных концах света я задал нескольким сотням менеджеров проектов два вопроса: «Если ваш коллега предпринимает свой первый безнадёжный проект, какой единственный совет для достижения успеха вы могли бы ему дать? И что единственное вы бы посоветовали ему не делать?» Я был весьма заинтригован, обнаружив, что никто даже не упомянул средства или технологии в качестве «одной самой важной вещи»; не были также упомянуты и формальные методологии и методы, такие, как структурный анализ или объектно-ориентированное проектирование. Некоторые рекомендовали стратегии управления человеческими ресурсами (например, «наймите хороших исполнителей» и «добейтесь, чтобы команда была действительно нацелена на успех»), однако почти все рекомендации были направлены на проведение переговоров, контроль за выполненным объёмом работ (которому хорошо способствует обсуждавшееся ранее определение приоритетов требований) и управление рисками (о котором речь пойдёт ниже).

Ещё один последний подход, заимствованный из упоминавшегося проекта министерства обороны, может оказаться полезным для безнадёжных проектов, хотя он в большей степени предназначен для менеджеров за пределами проекта, чем для менеджера самого проекта и участников его команды. Он называется «тест на алкоголь»: какие вопросы следует задать команде безнадёжного проекта, чтобы быстро определить, не утратили ли они чувство реальности до такой степени, что проект пора прекращать? Вопросы такого рода часто задаются консультантами, которых высшее руководство уполномочило проанализировать состояние проекта. Я сам был в таком положении, и я обычно могу заключить, что проект находится в плачевном положении, когда вижу остекленевший взгляд менеджера проекта, который напоминает взгляд лани, застигнутой светом фар приближающегося автомобиля.

Иногда безобидный вопрос типа «знаете ли вы, кто является вашим заказчиком?» приводит всех в полное замешательство, и в гробовом молчании каждый озадаченно смотрит на своего соседа, а потом все внимательно вглядываются в пол. Если вас интересуют некоторые другие вопросы «теста на алкоголь», ниже приведён их список:

36) Используете ли вы (и поддерживаете в актуальном состоянии) сетевой график работ?

37) Располагаете ли вы утверждённым планом и бюджетом?

38) Знаете ли вы, за разработку какого ПО несёте ответственность?

39) Можете ли вы перечислить первые десять проектных рисков?

40) Известен ли вам процент сжатия вашего плана по сравнению с нормальным?

41) Каков оценочный объём вашего ПО? Каким образом он вычисляется?

42) Известна ли вам та часть внешних интерфейсов, которая находится вне вашего контроля?

43) Достаточными ли знаниями о предметной области располагают ваши специалисты?

Как было отмечено выше, «тест на алкоголь» проводится в том случае, когда кто-либо в организации — как правило, не менеджер проекта, а кто-либо, стоящий на существенно более высоком уровне иерархии — почувствует, что проект идёт не так, как надо. Для того, чтобы выжить в политических схватках, менеджеру проекта и всей команде периодически следует задавать друг другу подобные вопросы. Менеджеру проекта вообще все время следует быть бдительным по отношению к другим признакам, говорящим о тревожном состоянии проекта, даже если в соответствии с официальным графиком PERT все выглядит как положено. Такими признаками могут быть:

44) Уход ключевых участников команды — это может произойти по ряду причин, однако важно вовремя почувствовать, не утратили ли участники проекта веру в свою способность завершить проект. Если начнут уходить ключевые разработчики, другие могут последовать за ними.

45) «Фактор обратной корреляции Дильберта» — чем больше карикатур Дильберта появляется на дверях в офисе и на досках объявлений, тем хуже идут дела в проекте.

46) Чрезмерный юмор висельников — если проектная команда начнёт носить в офисе чёрные рубашки и проигрывать на аудиосистеме погребальные мелодии, значит, что-то идёт не так.

47) Проекту даются новые имена, например, «Проект Титаник» — другая разновидность юмора висельников, которая, однако, является более серьёзным признаком того, что проектная команда утратила веру в успех, чувство причастности к проекту и вообще какой-либо интерес к работе.

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

49) Бестолковая суета — бурная деятельность при отсутствии видимых результатов. Выходом из такой ситуации может быть использование идеи «мини-этапов» и стратегии «ежедневной сборки проекта».

5.6 Принцип «ежедневной сборки проекта»

В дискуссии по поводу прототипирования, контрольных точек и мини-этапов неявно подразумевалось, что очередные результаты, получаемые проектной командой, появляются через интервалы, измеряемые месяцами или неделями. К этому приучил большинство из нас прежний опыт «нормальных» проектов, и это согласуется с обычным темпом деловой жизни — например, еженедельными совещаниями персонала, ежемесячными отчётами о состоянии работ, ежеквартальными презентациями для высшего руководства и т.д.