Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте - Йордон Эдвард

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

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

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

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

7.2 Учреждение «культуры» безнадёжных проектов

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

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

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

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

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

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

7) Каким образом безнадёжные проекты могут повлиять на стиль руководства? Следует ли ожидать, что с самого начала проекта менеджеры будут выжимать из участников команды все соки и затем выбрасывать их за ненадобностью? Или же менеджер проекта будет нести ответственность за хорошее самочувствие участников команды в такой же степени, как за своевременную сдачу работоспособной системы пользователям? Отметим, что если нормальная организация хочет внедрить культуру безнадёжных проектов (вместо того, чтобы периодически бороться с такими проектами), она, по-видимому, хочет, чтобы такие проекты завершались успешно; в соответствии с классификацией в главе 1 это означает, что организация сознательно идёт на проекты типа «невыполнимая миссия» или «отвратительные». Однако, если дела идут паршиво, а люди «сгорают на работе» и разбегаются к концу проекта, почему бы не воспользоваться услугами консультантов? Sharon Marsh Roberts замечает по этому поводу:

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

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

9) Какого типа инфраструктуру должна иметь организация, чтобы поддерживать безнадёжные проекты? Она может включать электронную почту в масштабах всей компании или более развитую инфраструктуру рабочих групп, основанную на использовании Lotus Notes. Кроме того, она могла бы также включать серьёзные изменения в человеческой инфраструктуре – т.е., сеть администраторов и обслуживающего персонала должна разрастаться, а слой бюрократов – сокращаться.