Путь камикадзе

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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] определил восемь ключевых ролей в проекте следующим образом:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.6 Заключение

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

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

1) Tom DeMarco, Tim Lister. Peopleware. Dorset Publishing, 1987.

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

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

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

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

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

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

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

4) Ken Whitaker. Managing Software Maniacs. New York: John Wiley & Sons, 1994.