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

3.5 Что делать в случае провала переговоров

Выше я отметил, что если менеджер проекта оказался не в состоянии добиться от заказчика или высшего руководства понимания той неопределённости, которая связана с планом или бюджетом безнадёжного проекта, он должен всерьёз задуматься об отставке; то же самое касается и технических специалистов проектной команды. Но это только один аспект неудачных переговоров; как следует поступить менеджеру, например, если он на 100% уверен, что продиктованный политическими соображениями срок в шесть месяцев явно недостаточен? Как следует ему поступить, если он на 100% уверен, что проектная команда должна состоять как минимум из трех человек, а руководство даёт только двух?
В этой книге я уже несколько упоминал о возможности отставки, и я понимаю, что это не слишком подходящий вариант для некоторых профессионалов; разумеется, для менеджеров отставка является более серьёзной проблемой, чем для технических специалистов, по той простой причине, что они, как правило, на 5-10 лет старше и поэтому обременены долгами, семьями, наполовину заработанной пенсией и т.д. Они в большей степени испытывают сомнения относительно возможности быстро найти другую работу, в то время как молодые и холостые участники проектной команды практически уверены, что смогут устроиться на другую работу за 24 часа.
Важно понимать, что я вовсе не рекомендую использовать отставку в качестве наказания или мести. Она является просто разумным действием, которое следует предпринять, столкнувшись с неразрешимой ситуацией и непримиримыми противоречиями на переговорах. Жизнь на этом не кончается, впереди будут ещё другие проекты и другие работы. Как отметила недавно Sue Peterson:

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

Однако, есть ещё одно соображение, связанное с уходом, которое необходимо принимать во внимание: оно касается лояльности и трудового соглашения между работодателем и работником. Вплоть до 80-х годов многие профессиональные программисты работали в крупных организациях, элементом корпоративной культуры которых являлась «пожизненная занятость». Хотя это никогда не было столь явным или серьёзным, как в японских компаниях, большинство программистов и проектировщиков в крупных банках, страховых компаниях, правительственных учреждениях и компьютерных компаниях (таких, как IBM и DEC) полагали, что в отсутствие войны, голода или чумы они будут продолжать расти вместе с организацией, пока не уйдут в 65 лет на пенсию с золотыми часами.
Небольшие компании никогда не обладали такого рода культурой, и многие профессионалы-разработчики работали именно в таких компаниях, особенно когда компьютерные технологии стали настолько дешёвыми, что даже небольшая семейная лавочка могла приобрести ПК и Web-сервер. Те из нас, кто работали в консалтинговых фирмах, бюро обслуживания и различных начинающих компаниях, всегда знали, что там не было и речи о пожизненной занятости.
Профессионалы в больших компаниях также начали сталкиваться с этой проблемой, поскольку наступление эры даунсайзинга, аутсорсинга и реижиниринга повлекло за собой распад многих софтверных компаний и безработицу в нашей области. Эти явления особенно обострились благодаря слияниям и приобретениям компьютерных компаний, а также в отраслях экономики с высокой степенью конкуренции, где обработка информации играет ключевую роль. Например, когда пару лет назад объединились Chemical Bank и Chase Manhattan Bank, высшее руководство столкнулось с проблемой объединения двух совершенно различных системно-технических платформ и иерархий IT-менеджмента.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71