Я провёл годы в лотерейном бизнесе, где все делается в экстремальных условиях, поскольку это единственный способ существования и развития отрасли. Если вы не желаете работать в таком режиме, то не сможете играть в этой песочнице. Разработчики в данной отрасли мирятся с таким положением, поскольку им доставляет удовольствие добиваться успеха в краткосрочных и в высшей степени интенсивных проектах и получать взамен значительную свободу действий, включая, в частности, двухмесячные отпуска между проектами. Эти команды считают себя элитой, и компании всячески поддерживают такие убеждения.
И, как отмечает Doug Scott:
Руководством движут различные мотивы. Они знают, что риск лишиться своей власти в наши дни особенно велик, и стремятся этого избежать, затевая различные проекты. Они также понимают, что на их выполнение нам потребуется не так уж мало времени из-за различных бюрократические процедур. Они полагают, что если особо обозначить важность конкретного проекта по сравнению с остальными, то эти процедуры можно будет обойти, не предпринимая для этого никаких специальных действий. Они понимают, что не могут привлечь к этой работе самых лучших специалистов; они также понимают, что самые лучшие технологии могут помочь в том случае, если они не потребуют длительного цикла обучения, что, в свою очередь, лишает возможности использовать такие технологии в данном проекте. Или наоборот, они верят шумной рекламе и считают, что новые технологии чудесным образом окажутся вполне зрелыми, свободными от ошибок, и их тотчас же сможет понять каждый.
Однако, если безнадёжные проекты являются нормой, следует ли тогда называть их безнадёжными? Не становятся ли они частью корпоративной культуры? Далее мы обсудим, почему такая трансформация может иметь место в нормальных организациях-разработчиках ПО, и затем перейдём к более серьёзному вопросу: каким образом можно изменить культуру обычной сегодняшней организации с тем, чтобы она могла эффективно справляться с безнадёжными проектами, не считая их какой-то аномалией?
Начнём с анализа вероятности того, что безнадёжные проекты будут становиться нормой. На протяжении всей книги я приводил по крайней мере три причины, по которым это могло бы стать реальностью:
* Организация находится в разгаре продолжающегося кризиса – это может быть результатом неудачного совпадения нескольких неожиданных кризисов, случившихся за небольшой промежуток времени; однако чаще это относится к организациям, оказавшимся в трудном положении, отчаянно пытаясь справиться с «потоком изменений» на рынке или с используемой технологией. В большинстве случаев такие организации оказываются в слишком отчаянном положении, чтобы суметь отступить на шаг назад и реорганизовать свою работу таким образом, чтобы спокойно планировать и выполнять все свои проекты. Редким исключением является ситуация, когда в компанию приходит новый руководитель, призванный вывести её из кризиса; при этом он может внедрить в компании совершенно иной стиль работы.
* Руководство и пользователи принимают такой подход в качестве своей стандартной позиции во время переговоров – как отмечалось в главах 1 и 2, в таком духе зачастую начинается первый безнадёжный проект; однако, если такой подход сработает один раз, почему бы не повторить его снова? Если департамент маркетинга или департамент финансов, или некоторое другое подразделение в организации столкнётся с необходимостью «перманентного» реинжиниринга для достижения конкурентоспособного уровня, они могут также принять соответствующее решение и настаивать, чтобы все разработчики и поставщики, с которыми они взаимодействуют, аналогичным образом подвергли себя реинжинирингу. С точки зрения таких подразделений департамент информационных технологий рассматривается как ещё один «поставщик» продуктов и услуг. Вариацией на эту тему является указание высшего руководства департаменту информационных технологий: «Если ваши люди не улучшат радикально свою продуктивность вовсех проектах, мы отдадим все на аутсорсинг в Индию!»
* Это часть «стратегического преимущества» компании — такой подход может иметь место в организациях, подобных EDS, и он является вполне определённым в таких организациях, как Cambridge Technology Partners. Он имеет смысл для консалтинговых организаций, где производительность проектных команд является их бизнесом. Однако, мы можем легко вообразить такую же ситуацию в других областях деятельности, связанных с информационной индустрией, таких, как банковское дело, страхование и телекоммуникации – там, где способность продвинуть новый программный продукт на рынок в значительной степени зависит от скорости его разработки. В той мере, в какой сказанное справедливо, я ожидаю появления все большего и большего количества организаций, прививших у себя культуру безнадёжных проектов.
Однако то, что имеет некоторый смысл для организации в целом, совсем не обязательно должно иметь такой же смысл для отдельных разработчиков и менеджеров проектов. Точка зрения организации имеет, безусловно, важное значение, однако я хочу уделить основное внимание точке зрения разработчика и менеджера; в конце концов, я не слишком надеюсь на то, что многие директора и вице-президенты по маркетингу прочтут эту книгу.
Главный вопрос для разработчика и менеджера проекта заключается в следующем: если удалось пройти через один безнадёжный проект, следует ли повторять этот опыт снова? Как можно себе представить, ответ на этот вопрос существенно зависит от того, насколько успешным был первый проект. В конце концов, если вы только что завершили «самоубийственный» или «отвратительный» проект, то, скорее всего, находитесь в состоянии физического и эмоционального истощения. Вашему самолюбию нанесён серьёзный урон, личная жизнь, возможно, оказалась разрушена. Кто на целом свете захочет ещё раз повторить такое? Даже так называемые проекты «камикадзе», где вы жертвуете своими личными потребностями в угоду столь возвышенным (но проигрышным) целям корпорации, могут в конце концов оказаться несостоятельными. Вы можете считать свою жертву благородной, однако если вы не выступаете в амплуа страдальца, то вряд ли вам захочется добровольно повторить этот эксперимент.
Отметим, что «отвратительный» проект, как говорилось в главе 1, может закончиться успешно; таким образом, у высшего руководства и пользователей будет повод для хорошего настроения. У менеджера проекта тоже может быть такой повод, особенно если он к концу проекта собрал хороший урожай в виде разнообразных вознаграждений. Если вы – один из участников команды, успешно прошедший через проект, вы можете быть довольны результатами, а можете и нет; в конце концов тот факт, что пролито море крови и причинен вред многим жизням и карьерам, может вас и не беспокоить. В самом деле, это становится частью корпоративной культуры – не обращать внимания на чужую кровь, которая проливается во имя проекта.
Очевидно, наибольшими шансами найти добровольцев для повторения опыта обладает проект «невыполнимая миссия»: проект, который не только успешно завершился, но и внушил каждому чувство истинной гордости за то чудо, которое они сотворили. Если по окончании проекта есть время покопаться в его результатах, то в этот момент крайне важно ответить на вопрос: «За счёт чего мы сумели добиться успеха?» Было ли это всего лишь везением? Может быть, это полностью зависело от харизмы менеджера проекта, или от гениальности проектировщика базы данных, или от того, что конечный пользователь и системный аналитик безумно влюбились друг в друга и поженились к концу проекта? Основной вопрос заключается в следующем: существует ли какая-нибудь разумная причина ожидать, что мы сумеем повторить этот фокус?
На эти вопросы важно ответить как можно раньше, поскольку организация, скорее всего, захочет повторить опыт независимо от желания отдельных личностей. Как было отмечено выше, в экстремальной ситуации организация поступает так, поскольку она вынуждена это делать; некоторые организации достаточно долго движутся к своему концу, и последние пять-десять лет были не чем иным, как бесконечной вереницей безнадёжных проектов. Даже в менее экстремальных ситуациях неудачи одного безнадёжного проекта может быть недостаточно, чтобы заставить организацию отказаться от подобного подхода; как отмечалось в предыдущих главах, в провале зачастую обвиняют менеджера проекта или новую технологию. «В следующий раз», – клянётся директор, – «мы не повторим те же самые ошибки; у нас будет новый менеджер проекта и новая супертехнология».
Разумеется, если первый же безнадёжный проект закончится успешно, вероятность того, что конечные пользователи и высшее руководство попытаются его повторить, будет гораздо выше; однако, может наступить момент, когда участники проектной команды решать сделать ручкой и станцуют конгу по направлению к двери. Пугать такой акцией бессмысленно; руководство обычно полагает, что легко найдёт новых добровольцев. Самое лучшее, что могут сделать доведённые до изнеможения участники проекта – это пожелать всем доброго здоровья и отправиться искать более спокойных и нормальных условий существования где-нибудь в другом месте.
Давайте предположим, что некоторая организация решила изменить свою культуру и начала выполнять все свои проекты в стиле безнадёжных. Как было отмечено выше, это может произойти без какого-либо осознанного решения и независимого от того, желают ли отдельные личности примириться более чем с одним безнадёжным проектом. Предположим, тем не менее, что это сознательная стратегия руководителей, отвечающих за информационные технологии, или ещё более высокого руководства, которому они подчиняются. Какими будут последствия и как типичная организация может осуществить такие изменения?
Самое важное, что должно произойти – это замена «нормальной» культуры разработки ПО на «радикальную» культуру, которую олицетворяют собой безнадёжные проекты. Такие изменения не могут произойти легко или быстро, поскольку бюрократия будет усиленно отстаивать старые порядки. Правда, в разумной организации понимают, что успех первого безнадёжного проекта – это в основном дело случая и результат упорства части команды. Если организация хочет заранее прогнозировать успех в последующих безнадёжных проектах, она должна измениться.
Изменения захватывают средства и технологии, процессы и методологии, стили управления и стратегии планирования, используемые организацией-разработчиком ПО. Они подразумевают решение таких вопросов, как:
* Каких сотрудников следует принимать на работу? В рамках закона и этических норм и при отсутствии какой-либо дискриминации организация, вероятно, будет стремиться найти более молодых и энергичных людей, отдавая предпочтение неженатым и тем, кто не слишком интересуется чем-либо, помимо работы. Молодые, неженатые трудоголики – это именно то, что требуется многим организациям для их безнадёжных проектов.
* Что следует говорить потенциальным новым сотрудникам об организации. Мне кажется, что не только неэтично, но и просто глупо скрывать тот факт, что организации собирается следовать стратегии безнадёжных проектов. В самом деле, организации, внедряющие такой подход, обычно весьма гордятся этим, так же, как и любым другим аспектом своей культуры. Организация может не пожелать акцентировать внимание на том, что только небольшой процент пришедших новобранцев успешно пройдёт через первый безнадёжный проект (так же, как в колледжах не признаются, что большая часть вновь пришедших первокурсников провалится на экзаменах и будет отчислена), однако ей следует предупредить, что рабочий день вряд ли будет укладываться в рамки «с 9 до 5».
* Каким образом безнадёжные проекты могут повлиять на карьерную политику – в частности, продвижение по службе, повышение в должности и премии? Например, в юридических фирмах и компаниях «Большой Шестёрки» новобранцам принято говорить, что должно пройти от семи до девяти лет, прежде чем они смогут стать партнёрами; они могут занимать промежуточные ступеньки «менеджера» или «старшего менеджера», но ни у кого не должно быть иллюзий, что долгие часы и тяжёлая работа закончатся через год или два.
* Каким образом безнадёжные проекты могут повлиять на стиль руководства? Следует ли ожидать, что с самого начала проекта менеджеры будут выжимать из участников команды все соки и затем выбрасывать их за ненадобностью? Или же менеджер проекта будет нести ответственность за хорошее самочувствие участников команды в такой же степени, как за своевременную сдачу работоспособной системы пользователям? Отметим, что если нормальная организация хочет внедрить культуру безнадёжных проектов (вместо того, чтобы периодически бороться с такими проектами), она, по-видимому, хочет, чтобы такие проекты завершались успешно; в соответствии с классификацией в главе 1 это означает, что организация сознательно идёт на проекты типа «невыполнимая миссия» или «отвратительные». Однако, если дела идут паршиво, а люди «сгорают на работе» и разбегаются к концу проекта, почему бы не воспользоваться услугами консультантов? Sharon Marsh Roberts замечает по этому поводу:
Я считаю, что организации необходимо найти способ обновления своих ресурсов. Одна альтернатива – использование множества консультантов, от которых ожидается работа в стиле «заработай кучу денег и отваливай». Другая альтернатива – иметь «зону безопасности», в которой сотрудники могли бы отсиживаться между безнадёжными проектами.
* Какими средствами должна быть оснащена сама организация, если каждый проект будет безнадёжным? Если окажется, что главным фактором успеха первого безнадёжного проекта стала технология повторного использования с соответствующей библиотекой классов или визуальное средство быстрой разработки приложений, то, возможно, каждый проект должен иметь в распоряжении эти средства.
* Какого типа инфраструктуру должна иметь организация, чтобы поддерживать безнадёжные проекты? Она может включать электронную почту в масштабах всей компании или более развитую инфраструктуру рабочих групп, основанную на использовании Lotus Notes. Кроме того, она могла бы также включать серьёзные изменения в человеческой инфраструктуре – т.е., сеть администраторов и обслуживающего персонала должна разрастаться, а слой бюрократов – сокращаться.
* Какого рода процессы подходят для культуры безнадёжных проектов? Механизм определения приоритетов, формальные процессы и многое другое из того, что обсуждалось в главе 5, должно быть принято на уровне организации, чтобы каждая команда могла получить необходимую ей поддержку, когда она пытается реализовать соответствующие процессы на практике в конкретном безнадёжном проекте. Отметим также, что на процессы оказывает влияние (хотя и небольшое) длительность проекта; большинство организаций находит, что вероятность успеха краткосрочных безнадёжных проектов выше. Как отмечает Bill Hamaker:
Вместо нескольких крупных безнадёжных проектов лучше выполнить побольше небольших проектов. Сконцентрируйтесь на создании такой организации, которая умеет извлекать уроки из результатов каждого безнадёжного проекта. Отведите достаточно времени между проектами, чтобы специалисты могли оценить все плюсы и минусы разработки; это время будет для них своего рода отдыхом.
В главах 6 и 7 я затрагивал вопросы обучения проектной команды новым процесса и средствам. Однако, потребность в таком обучении изменяется, если безнадёжные проекты становятся частью корпоративной культуры. В этих случаях соответствующие процессы и средства должны быть частью корпоративных стандартов, что исключает необходимость внедрения их в начале каждого проекта как чего-то радикально нового.
В реальности, разумеется, существует некоторый переходный период, когда организация меняет свой режим работы, переходя от прежней формы выполнения проектов к новому стилю. Однако даже во время переходного периода идеальным вариантом было бы проводить обучение не в самом безнадёжном проекте, а в нормальной обстановке; разумеется, такое обучение следует рассматривать как часть переходного процесса. При удачном стечении обстоятельств это позволит сделать процесс обучения более упорядоченным и не загонять его в цейтнот, как это обычно бывает, если обучение проводится в середине безнадёжного проекта.
Соответствующее обучение также должно проводиться для новых сотрудников, принимаемых на работу. Новичкам – например, выпускникам колледжей, которые никогда не занимались полноценной разработкой ПО – нет необходимости объяснять, что новый подход отличается от старого подхода; в самом деле. ведь они даже не слышали такое понятие – «безнадёжный проект». В чем они действительно нуждаются, так это в обучении методам, процессам и средствам, которые организация считает эффективными для применения в безнадёжных проектах. Они, скорее всего, будут сильно отличаться от тех процессов и средств, с которыми новобранцам приходилось иметь дело прежде. (Ирония заключается в том, что как только прежние новобранцы примут участие в своём первом безнадёжном проекте, менеджер велит им «игнорировать все, чему их научили в классе» и усвоить более прагматичный подход к разработке ПО.)
Хотя такие формы обучения выглядят разумными и рациональными, во многих небольших организациях они игнорируются; обучение проводится непосредственно во время работы, разработчикам приходится вникать в тонкости процессов и средств по ходу дела. Ещё хуже дело обстоит для менеджеров – как заметил мой приятель Tim Lister, единственное обучение, которое получает большинство менеджеров проектов, заключается в двух словах: «Желаю удачи!»
Разумеется, руководства и аудиторное обучение методам, процессам и средствам управления проектами являются важными и полезными. Однако многие организации считают, что «реальную работу» ничем не заменишь – в самом деле, они вполне сознательно игнорируют аудиторное обучение, полагая, что если вы пройдёте через реальный безнадёжный проект, то приобретёте опыт, который никогда не получите, занимаясь в классе.
Вместо того, чтобы спорить о достоинствах и недостатках аудиторного и «боевого» обучения, я думаю, что организациям стоит рассмотреть компромиссный вариант: имитацию безнадёжного проекта. Аналогия с «имитатором полётов» является более близкой, чем это может показаться на первый взгляд: пилоты авиалиний используют эти имитаторы не только для отработки нормального взлёта и посадки, но и действий в различных аварийных ситуациях, что они не могут позволить себе на реальных самолётах. Имитатор полётов даёт отличную возможность врезаться в гору, никого при этом не убив. Почему бы менеджеру проекта вместе со всеми участниками команды не направить полет своего проекта в подобие такой горы, чтобы они могли приобрести опыт решения возникших проблем, никого при этом не убивая? И почему бы не потребовать от разработчиков и менеджеров, чтобы они раз в год посещали имитатор безнадёжного проекта, как это делают пилоты авиалиний?
Скептики могут возразить, что такой имитатор не в состоянии воспроизвести тот постоянный цейтнот и напряжение, которые имеют место в реальном проекте; пилоты авиалиний, использующие свои имитаторы для отработки действий в аварийных ситуациях, будут убеждённо возражать против такой точки зрения. Однако, если нам действительно необходимо смоделировать стрессовую ситуацию в софтверном проекте, мы можем позаимствовать хорошо знакомую тактику из военной области: «военные игры». Как отмечают Tom DeMarco и Tim Lister в своей книге Peopleware [1]:
Военные игры помогают вам оценить свои относительные достоинства и недостатки, и помогают организации в целом оценить свои слабые и сильные места.
Наиболее эффективной для участников формой военной игры, позволяющей стимулировать творческий беспорядок, является командная игра.
Таким образом, военная игра по отношению к безнадёжным проектам может заключаться в следующем: несколько разных проектных команд получают один и тот же «проектный сценарий» – одинаковые требования, одинаково сжатый временной интервал, одинаковые ресурсы для работы. Или, если культура безнадёжных проектов в организации ещё не получила надлежащую формализацию и стандартизацию, предоставьте каждой команде возможность использовать любые средства и процессы, которые она захочет – все, что они смогут выпросить, одолжить или украсть в честной игре. Australian Computer Society проводит такие военные игры на своих ежегодных конференциях, начиная с 1994 года, и некоторые местные консалтинговые фирмы используют эти игры как часть своего собственного процесса обучения.
Чтобы организовать в безнадёжном проекте военную игру или любой другой «имитатор полётов», необходимо иметь имитационную модель, на которой можно было бы проиграть последствия технических и управленческих решений. Эта концепция обсуждается в моей книге Rise and Resurrection of the American Programmer, и в конце данной главы также приведён ряд ссылок; особенно следует отметить работу Tarek Abdel-Hamid, Stuart Madnick Software Project Dynamics[2], которая описывает полную и детальную имитационную модель для проекта среднего размера.
Имитационная модель может быть в принципе реализована на любом языке программирования, однако для этих целей существуют специализированные языки и средства. Возможно, наиболее известными из них являются SIMSCRIPT, DYNAMO и GPSS; модель, описанная Abdel-Hamid и Madnick, реализована на DYNAMO (в приложении к книге приведён полный текст программы). Несколько позже появился ряд средств «визуального» моделирования, большинство из которых достаточно дёшевы. Из коммерческих продуктов я отдаю предпочтение перечисленным ниже средствам:
* iThink (Macintosh, Windows). High Performance Systems Inc., Hanover, NH. Тел. 603-643-9636, факс 603-643-9502.
* VenSim (Windows). Ventana Systems Inc., Belmont, MA. Тел. 617-489-5234, факс 617-489-5316.
* Professional DYNAMO (Windows). Pugh-Robert Associates, Cambridge, MA. Тел. 617-864-8880, факс 617-864-8884.
* Extend (Macintosh, Windows). Imagine That, Inc., San Jose, CA. Тел. 408-365-0305, факс 408-629-1251.
Даже при наличии хороших средств и множества опубликованных материалов невозможно отрицать тот факт, что для создания модели, отражающей среду конкретной компании и предоставляющей руководству возможность проигрывать разнообразные сценарии безнадёжных проектов, необходимо серьёзное отношение к делу и немалые инвестиции. Исходя из своего личного опыта участия с начала 90-х годов в ряде подобных проектов по созданию имитаторов и сценариев военных игр, могу сказать, что на построение адекватной и хорошо настаиваемой модели требуется по крайней мере несколько человеко-месяцев; в качестве дополнительной иллюстрации интересно отметить, что модель, опубликованная в [2], была предметом диссертации Abdel-Hamid.
Это означает, что такая работа лежит за пределами возможностей одного-единственного менеджера проекта, если он хочет использовать такой подход в процессе обучения. Ясно, что эти инвестиции носят стратегический характер, и ими должна заниматься корпорация в целом, причём вряд ли они под силу небольшой компании из десяти человек. Однако для организации-разработчика, в штате которой работают сотни и даже тысячи человек, такие инвестиции будут весьма скромными. Напомним, о чем идёт речь: руководство пытается найти способы утвердить процессы и технологии, которые могли бы обеспечить уверенность в выполнимости планов, бюджетов и функциональности, являющихся вдвое или втрое более претенциозными по сравнению с «нормальными» проектами. Планируя такие радикальные изменения, руководство зачастую готово затратить огромные суммы денег – в некоторых случаях буквально миллионы долларов – на оснащение разработчиков новыми рабочими станциями, средствами визуального программирования и объектно-ориентированными методологиями. Ворчать по поводу затрат шести человеко-месяцев на разработку имитатора просто смешно, а лишать свои проектные команды возможности получить опыт на модели безнадёжного проекта перед тем, как рисковать миллионами долларов, просто глупо.