Правильная ссылка на эту страницу
http://az-design.ru/Projects/AzBook/src/004/02MS1300.shtml

Глава 13. Как осуществить задуманное

       Один из мифов о руководстве проектами гласит, что кому-то навыки даются с рождения, а кому-то — нет. Как только этот миф упоминался в разговоре с другими руководителями проектов, я неизменно просил их объяснить, в чем состоит суть таких способностей — как узнать, что человек наделен ими, в какой мере и можно ли их развить у других. После дебатов мы обычно приходили к единственному выводу — ко многим другим нужным качествам и навыкам, о которых рассказывается в этой книге, нужно добавить еще умение осуществлять задуманное. Одним людям удается в должной мере применить свое мастерство и талант на благо продвижения проекта, другим — нет, даже если они по своему индивидуальному мастерству ни в чем не уступают первым. Способность добиваться желаемого результата — это сплав знаний о том, как стать катализатором процесса и управлять им в различных ситуациях, и мужества, необходимого, чтобы справиться с этой ролью.
       Эта способность настолько важна, что используется при найме руководителей проекта в качестве своеобразной лакмусовой бумажки. Даже если руководители проектов не в состоянии дать этой способности точного определения без упоминания других умений и навыков, они считают, что могут определить ее наличие у других. К примеру, многие кадровики задают в отношении кандидата следующий вопрос: “Если в какой-нибудь важной части проекта что-то не заладится, мог бы я со всей уверенностью послать этого человека разобраться с проблемой и организовать ее решение, верю ли я в то, что он найдет способ оздоровления ситуации, независимо от степени сложности возникшей проблемы?” Если после собеседования ответ на этот вопрос дается отрицательный, то кандидату нужно отказать1 {Вопрос заключается не только в том, способен ли человек на все это, вопрос ставится следующим образом: “Сможет ли этот человек понять, когда ситуация начнет выходить из-под его контроля и своевременно запросить помощь?”. Он должен уметь справляться еще и с такой ситуацией.}. В соответствии со сложившимися представлениями, если у кандидата недостаточно гибкости, чтобы применить свои навыки к возникшей ситуации, то с типовым проектом он не справится. Эта глава посвящена способностям осуществлять задуманное.

Правильно расставляйте приоритеты

       В качестве руководителя проекта большую часть своего времени я тратил на составление разнообразных списков приоритетов, расставляя задания по степени важности. Я был убежден, что несмотря на все знания, которые за мной числились, вся моя деятельность, фактически, сводилась к составлению этих списков. Я сгребал в кучу все, что нужно было сделать, включая требования, характеристики, ошибки, в общем, все, а затем расставлял все это по степени важности для проекта. Целыми днями я занимался правкой этих списков, включая в них новую информацию, затевая вокруг них обсуждения и споры с другими специалистами, и всегда доводил свои списки до полного совершенства. После этого я упорно вел команду в соответствии с указанным в них порядком следования заданий. Иногда в этих списках фигурировал мой ежедневный распорядок работы, иногда — прикидки, чем будут заниматься группы людей в течение ближайших месяцев. Но процесс и эффект от него оставались прежними.
       Я уделял так много времени составлению списков, поскольку знал, что правильная расстановка приоритетов — это залог прогресса. От четкого определения понятий, что является главным, а что второстепенным, от влияния этих понятий на каждый шаг в работе команды зависит успешная реализация всего замысла. Расстановка приоритетов должна отражаться в каждом посланном вами электронном сообщении, в каждом заданном вопросе и на каждом проводимом совещании. Каждый программист или тестировщик должен вкладывать свою энергию в те дела, которые напрямую ведут к успеху. А кто-то должен определять, что это за дела, и заставлять команду ими заниматься.
       Больше всего к пустой трате времени при работе над проектом приводит путаница в заданиях и в очередности их выполнения. Многие недоразумения и оплошности происходят из-за того, что некто А предполагает одни приоритеты (добиться результата как можно быстрее), а некто Б — другие (добиться стабильности в работе продукта). Такое случается с программистами, тестировщиками, маркетологами, как, впрочем, и со всеми остальными специалистами команды. Если подобных конфликтов удастся избежать, то останется больше времени на достижение реальных целей проекта.
       Я не хочу тем самым сказать, что дебатов вокруг приоритетов вообще быть не должно, их просто не может не быть. Но они должны вестись на ранней стадии, еще в ходе планирования. Если одни и те же аргументы реанимируются в процессе разработки, значит, люди недостаточно усвоили суть решения или забыли все логические выкладки и нуждаются в напоминании, почему было принято именно такое решение. Дебаты можно поддержать, но начать следует с вопроса, что, собственно, изменилось с тех пор, как были сверстаны планы, и зачем пересматривать приоритеты. Если ничего не изменилось (конкурент не придумал ничего нового, цели групп не обновлялись, увеличения или сокращения ресурсов не происходило, новые крупные проблемы не возникали), твердо придерживайтесь ранее принятого решения.
       Возражения вряд ли возникнут или окажутся кратковременными, если список приоритетов будет вывешен на стене, чтобы каждый мог познакомиться с согласованной очередностью действий. Списки приоритетов дают всем возможность усвоить общую логическую структуру, исходящую из принятых решений. Если приоритеты ясны и понятны, то не нужно тратить время на их тщательное разъяснение.
       Итак, если в чем-то работа команды не ладилась и люди не могли сосредоточиться на главном, я знал, что это мой просчет: либо я неверно расставил все по местам, не сумев как следует довести до людей порядок действий, либо не сумел выдержать и добиться определенного ранее порядка. В данном случае работа над расстановкой приоритетов и составлением списка имеет главенствующее значение.

Типовые списки приоритетов

       Постоянная работа со списком приоритетов облегчает внесение поправок и изменений. Если каким-то чудом в рабочем графике отыщутся дополнительные ресурсы или время, будет вполне понятно, что их нужно потратить на следующее по важности задание. К тому же если рабочий график нужно сократить, то всем понятно, работу по какому из следующих наименее важных заданий следует остановить. Все это крайне важно, поскольку независимо от хода событий гарантирует возможность выполнения наиболее важного задания и проведения быстрой корректировки без особых усилий и моральных издержек. Следует также заметить, что любые ошибки, допущенные вами при расстановке приоритетов, имеют относительный характер: в том, что задание под номером 10 оказалось важнее задания под номером 9, нет ничего страшного. Поскольку список упорядочен, допустить слишком грубую ошибку довольно трудно. Кроме того, имея в своем распоряжении столь явно расставленные приоритеты и заставляя команду их придерживаться, можно, в конечном итоге, легко выкроить время, необходимое и на выполнение задания, стоящего под номером 10.
       Для большинства проектов используются три наиболее важных типовых списка, содержащих расставленные по приоритетам цели, характеристики и работы (рис. 13.1). Цели проекта обычно являются частью концептуального документа (см. главу 4) или вытекают из него. Списки характеристик и работ появляются в результате проектирования (см. главы 57). Поскольку каждый из данных перечней наследует структуру приоритетов своего предшественника, чтобы заново уточнить приоритет каждого уровня и сопоставить уровни, вызывающие сомнения, можно организовывать обсуждения. Хотя не все решается в спорах, они гарантируют, что все принятые решения действительно касаются важных вопросов.
       Списки приоритетов могут также понадобиться и для других важных дел. Сюда могут быть включены работы по исправлению ошибок, по реализации предложений заказчика, по порядку премирования работников и распределения ресурсов команды. Они могут быть составлены по тому же принципу расстановки приоритетов в том порядке, который позволил бы принести наибольшую пользу проекту или организации. Независимо от того, насколько сложен используемый для этих целей инструментарий (скажем, для отслеживания ошибок), никогда не забывайте о том, что суть ваших действий заключается в расстановке приоритетов. Если используемые вами инструменты не помогают расположить все по порядку, найдите для этого другие инструменты. К примеру, процесс классификации ошибок, когда люди собираются, чтобы решить, к какому сроку какую ошибку нужно исправить (если это вообще представляется возможным), фактически и есть коллективное составление списка приоритетов, относящихся к исправлению ошибок. Ошибки могут классифицироваться не отдельно, а по группам, но сути дела это не меняет.


Рис. 13.1. Три наиболее важных списка приоритетов

       Если применяются три наиболее распространенных списка приоритетов, проверьте их согласованность друг с другом. Каждая работа должна обеспечивать реализацию какой-нибудь характеристики, а каждая характеристика соответствовать какой-нибудь цели проекта. Если добавляется новая работа, она должна выполняться в русле определенных характеристик и целей. Это обязательное условие, препятствующее появлению случайных элементов. Если вице-президент или программист хочет вставить в перечень что-нибудь экстраординарное, нужно заставить его обосновать свое желание конечными целями проекта: “Босс, конечно, это сильная характеристика, но каких целей проекта она поможет нам достичь? Либо нам нужно скорректировать цели и учесть последствия, либо вообще не стоит тратить на нее силы”. Если приучить команду к согласованному принятию решений на всех трех уровнях, то ее функционирование станет целенаправленнее, а время не будет тратиться понапрасну.

Первоочередные и все остальные приоритеты

       Как правило, любой список приоритетов можно разделить на две части. В верхней части располагается все, что нужно сделать в первую очередь, то есть все дела, без которых достичь успеха невозможно. Во второй части располагается все остальное. Приоритеты второй и третьей очереди тоже существуют, но понятно, что они в корне отличаются от первоочередных. Превратить второстепенное задание в первоочередное крайне трудно.
       К проведению черты, отделяющей первоочередные приоритеты, нужно подходить очень серьезно. Следует всеми силами бороться за то, чтобы верхняя часть перечня была как можно короче и компактнее (такое же правило применимо к любому перечню задач концептуального документа). Пункт списка, относящийся к первоочередным приоритетам, означает: “Без этого мы просто не сможем жить”. Это не должны быть задания, которые неплохо было бы иметь в верхней части перечня или которые очень хотелось бы там иметь: подобный подход слишком слабо отвечал бы задачам проекта. К примеру, при сборке автомобиля к первоочередным приоритетам можно было бы отнести установку двигателя, колес, трансмиссии, тормозов, рулевого колеса и педалей, а к приоритетам второй очереди — установку дверей, ветрового стекла, системы вентиляции и радиоприемника, поскольку ездить на машине можно и без всего этого. Функциональность автомобиля сохраняется, эти элементы можно убрать, а то, что осталось, все равно будет называться автомобилем.
       Определить, где провести эту черту, всегда было нелегко, дело не обходилось без продолжительных дебатов вокруг всего, без чего не может прожить заказчик, и это вполне естественно. Хотелось бы, чтобы все дебаты происходили и заканчивались еще на ранней стадии. Как бы ни было трудно, в итоге получался перечень, содержащий жизнеспособные мнения и взгляды команды. Изучив и запротоколировав все “за” и “против” относительно созданного перечня, можно двигаться вперед. Процесс споров и дебатов, направленный на совершенствование перечня, на 90% готовит к ответам на обычные вопросы или возражения, возникающие впоследствии (например, почему мы оборудовали машину тормозами, а не кондиционером), и позволяет сразу же их отклонить, поскольку все эти возражения уже звучали и их несостоятельность была доказана.
       Сложности в выборе приоритетов всегда носят больше эмоционально-психологический, чем прагматический характер, независимо от того, что говорят на этот счет люди. Исключение желательных (но не обязательных) вещей, как и при соблюдении диеты или экономии денег, требует дисциплинированности, выдержки и сосредоточенности на главном. Говорить: “Для нас важна стабильность” — это одно, а сопоставить стабильность с другими важными свойствами — совсем другое. Многие руководители перед этим пасуют. Они занимают выжидательную позицию, откладывают трудный выбор на потом или вовсе отказываются от него и в результате приводят проекты к краху. Без трудного выбора прогресс невозможен. Если подходить к нему отвлеченно, то слово “важный” ровным счетом ничего не означает. Поэтому составление списков приоритетов и определение места, где должна пройти черта, отделяющая первоочередные приоритеты, требует от руководителей, да и от всей команды принятия нелегких решений и ясности мышления.
       Ясность представлений способствует осуществлению задуманного в процессе реализации проектов. При этом каждый сотрудник ежедневно занимается вполне осмысленной работой, зная, зачем он это делает и как его занятие согласуется с тем, что делают все остальные. Когда команда задает вопросы, почему одно дело важнее другого, у нее есть для этого ясные и разумные основания. Даже если что-то меняется и уточняется, все проходит в рамках все той же системы, основанной на списках приоритетов.

Приоритеты — это сила

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

Станьте генератором приоритетов

       Разговаривая с программистами или тестировщиками и выслушивая их проблемы и трудности, я все больше убеждался в том, что моя основная задача — помочь им сосредоточиться на главном. Ее суть состояла в том, чтобы убрать из их сознания все второстепенное и третьестепенное, и помочь увидеть четкую последовательность дальнейших действий. Существуют тысячи способов реализации проекта создания конкретной веб-страницы или системы управления базами данных, но лишь их малая толика способна реально охватить все обозначенные цели. Зная об этом, я всегда приветствовал случаи, когда программисты искали меня, столкнувшись с решением, в сроках реализации которого они не были уверены.
       Но вместо мелочной опеки (“Делай это. Не делай то. Не делай так. Ты что, уже сделал? Ну, и что теперь делать?”) я доводил до сознания подчиненных, что моя задача — в нужный момент помочь им расставить приоритеты. Поскольку они не имели такого же широкого взгляда на проект, какой был у меня, я должен был помочь им хотя бы на какое-то мгновенье увидеть, как все, чем они занимались, соотносится с проектом в целом. Когда весь день уходит на отладку модуля или на тестирование компонента программы, весьма полезно выслушать объяснение общих положений проекта и заверения в том, что находишься на правильном пути. Порой, чтобы убедиться, что все “держат руку на пульсе”, хватало и полуминутного разговора.
       Когда же поступала новая информация по проекту, то именно я должен был в ней разбираться (либо самостоятельно, либо в ходе коллективного обсуждения), чтобы найти ей место в перечне приоритетов. Рабочий список приоритетов приходилось пересматривать довольно часто, поскольку в него нужно было вносить изменения, связанные с поступавшей информацией. Могло измениться мнение вице-президента. При изучении потребительских качеств продукта могли вскрыться новые проблемы. Конкурент мог внести в свой продукт какие-нибудь неожиданные изменения. Наши приоритеты были похожи на живой организм, на состоянии которого моментально и непосредственно отражались любые изменения в целях или в направлении развития проекта.
       Поскольку вся работа по расстановке приоритетов лежала на мне, я дал возможность команде сосредоточиться на главном и таким образом способствовал прогрессу в ее работе. Иногда можно было воспользоваться приоритетами, определенными моим руководством (в концептуальных документах, в целях группы); а иногда я должен был готовить их самостоятельно, реагируя на возникновение неоднозначных или непредвиденных обстоятельств. То есть в первую очередь я был тем самым механизмом, который генерировал приоритеты. Если когда-нибудь собирательному образу руководителя проекта поставят памятник, я думаю, что на нем будет такая надпись: “Ведите ко мне толпы заблудших, запутавшихся, обозленных и огорченных программистов, жаждущих просветления”.

Все получится, если сказать “нет”

       Побочным эффектом от наличия списка приоритетов является частое использование слова “нет”, которое многим дается совсем не легко. Однако не научившись говорить “нет”, невозможно следовать каким бы то ни было приоритетам. Мир велик, а перечень первоочередных приоритетов краток. Поэтому большая часть из того, что в мире (или в вашей команде) многим представляется грандиозным, должно быть отклонено из-за несоответствия целям проекта. Это совсем не означает, что идеи сами по себе плохи, суть в том, что они не способствуют реализации данного конкретного проекта. Итак, для руководителей проектов действует следующий основной закон: если вы не можете сказать “нет”, значит, вы не в состоянии управлять проектом1 {Дополнительное обсуждение вопроса о том, когда говорить “да”, а когда “нет”, можно найти в эссе Ричарда Бреннерса (Richard Brenners) “Saying No: A Short Course” по адресу http://www.ayeconference.com/Articles/Sayingno.html.}.
       Употребление слова “нет” начинается с руководства. Когда именно специалисты могут сказать “нет” в ответ на какие-либо запросы, определяется старшим руководством. Если руководитель команды независимо от расставленных приоритетов все время говорят “да”, его примеру последуют другие. Программисты начнут разрабатывать только то, что им нравится. Руководители проектов начнут добавлять (или убирать) требования по своему усмотрению. Даже если отдельные избранные ими действия окажутся удачными, потеря командой единых правил и работы в направлении установленных приоритетов приведет к возникновению конфликтов. Порой все это может выразиться в форме разногласий в среде программистов, но чаще всего результатом будет разлад в конечных намерениях. От этого пострадает буквально все, и стабильность, и производительность, и потребительские свойства продукта. Без следования приоритетам заставить команду согласованно работать над созданием единого продукта очень трудно. Лучшие ведущие специалисты и руководители команд знают, что всему не вписывающемуся в рамки приоритетов нужно говорить “нет”, устанавливая ту же норму и для всей команды.
       Когда вы говорите решительное “нет”, проект получает положительный импульс. Исключение из чьих-то планов ненужных задач дает людям больше энергии и стремления заниматься порученным делом в полную силу. Число совещаний и стихийных дискуссий сокращается, а их эффективность возрастает. Слово “нет” вызывает цепную реакцию: все остальные тоже начинают им пользоваться в пределах своей компетенции. Бывало, я специально просил об этом своих сотрудников: “Стоит вам только почувствовать, что вас просят о чем-то, не согласующимся с нашими приоритетами, говорите “нет”. Или сошлитесь на меня. И не тратьте свое время на пустые споры; если в ответ вам выразят недовольство, сразу посылайте всех ко мне”. Я не хотел, чтобы специалисты впустую тратили свое время на дебаты вокруг приоритетов, поскольку это была не их, а моя прерогатива. Даже если им никогда не приходилось сталкиваться с подобной ситуацией, я се равно выигрывал от того, что внушал им серьезное отношение к приоритетам и выказывал свой решительный настрой на защиту их интересов.

Учитесь говорить “нет” по-разному

       Иногда вам нужно сказать “нет” в ответ на требование придать продукту какое-нибудь новое свойство. А иногда возникает необходимость вмешаться в чей-то разговор или в работу какого-нибудь совещания и сказать решительное “нет” дискуссиям, если те грозят обернуться сменой приоритетов. Для того чтобы подготовиться к этому, вам нужно освоить ряд способов выразить свое несогласие.
       — Нет, это не соответствует нашим приоритетам. Если проект находится на ранней стадии реализации, вам нужно аргументировано доказать, зачем придерживаться именно этих приоритетов, причем нужно выслушать и сторонников иных приоритетов. Возможно, у них есть какие-то толковые идеи или им нужно объяснить суть поставленных задач. Вести дискуссию нужно вокруг приоритетов проекта, а не абстрактных ценностей отдельных характеристик или исправления допущенных ошибок. Если проект находится в поздней стадии реализации, нужно объявить “реформаторам”, что их предложения уже давно выпали из обоймы. Даже если приоритеты выстроены недостаточно умело, их не стоит менять ради новой идеи относительно той или иной характеристики. Чем в более поздней стадия находится разработка проекта, тем серьезнее должны быть стратегические просчеты, которые могут послужить причиной корректировки целей.
       — Нет, на это может не хватить времени. В рамках любого проекта всегда предлагается масса очень неплохих идей. Если вы стремитесь сохранить список приоритетов компактным, отвечайте уклончиво: дайте понять, что рассматриваемая идея может быть и хороша, но по сравнению с другими задачами и приоритетами проекта ей все же чего-то не хватает. Если она включена в список приоритетов второй очереди, скажите, что ее реализация вполне возможна, но слишком больших ставок на это делать не стоит.
       — Нет, если только вы не сделаете <вставьте сюда ваше условие>. Иногда есть возможность обратиться к человеку с ответной просьбой. Если ваш вице-президент попросил вас добавить поддержку новой характеристики, скажите ему, что вы сможете это сделать только при условии, что он уберет одно из своих требований, входящих в список первоочередных приоритетов. Таким образом, можно отвести удар от себя и заставить просителя реально взглянуть на вещи, хотя, может быть, и без особого успеха. Точно так же можно поступить из политических соображений или для создания благоприятного впечатления о собственной персоне: “Салли, если ты сможешь доказать, что идея стоит того, я готов ее рассмотреть”. Но можно получить и обратный эффект. (А что если Салли действительно поверит в ваши слова? Или, хуже того, поймет, что вы, образно говоря, послали ее куда подальше?)
       — Нет, только не сейчас. Предположим, вы разрабатываете веб-сайт или программный продукт, подлежащий дальнейшему обновлению. Предложите отложить рассмотрение просьбы до следующего выпуска продукта. Это же может касаться и всех приоритетов второго уровня. Подобный прием часто называют отсрочкой.
       — Нет, никогда. Ни в коем случае. Некоторые запросы настолько не соответствуют долговременным целям, что впору стукнуть кулаком по столу. Немедленно рубите все концы и, экономя собственное время, делайте повторное рассмотрение этого предложения невозможным. Иногда для объяснения причин нужно приложить определенные усилия (чтобы ни у кого не возникло соблазна повторить попытку). Например: “Нет, Фрэд, поисковая машина нашего веб-сайта никогда не будет поддерживать Эсперанто. И хватит об этом”.

Реально оценивайте ситуацию

       Ощущение действительности у одних команд может быть развито значительно выше, чем у других. Можно найти массу историй о командах разработчиков проектов, которые смогли сбыть свою продукцию лишь спустя месяцы или годы после разработки или допустили бюджетный перерасход в миллионы долларов1 {См. книгу Роберта Гласса (Robert Glass) “Software Runaways” (Prentice Hall, 1997).}. Постепенно такие команды начинают понемногу приукрашивать действительность, скатываясь к опасной и крайне непродуктивной черте. Как правило, чем больше команда отрывается от реальности, тем труднее осуществить задуманное. В данном случае (имеется в виду потеря командой ощущения действительности, а не ее склонность к вранью) руководители должны стать воплощением честности и показать людям, что они выдумывают несуществующие вопросы, не видят проблемных ситуаций или опираются на неверные приоритеты.
       Я припоминаю, как несколько лет назад присутствовал на совещании небольшой команды разработчиков, создававшей нечто, чем хотела воспользоваться моя команда. Их презентация была посвящена новым характеристикам и технологиям, которыми они собирались оснастить свой новый продукт. Я сидел в самом конце комнаты и чувствовал себя все более и более неуютно. В презентации не было упомянуто ни одного серьезного вопроса, их как бы вообще не существовало. И тогда я понял причину своего беспокойства: игнорируя важные вопросы, организаторы впустую тратили время всех присутствующих.
       Я огляделся и понял, что ситуация еще сложней, чем кажется: в числе присутствующих кроме меня не было никого из руководства моей организации. Вообще-то, к этому времени кому-нибудь из руководителей проектов или ведущих программистов пора было задать пару острых вопросов, но я не знал, способен ли на такое кто-нибудь из присутствующих. В моей голове роилась тысяча вопросов, тогда я решительно поднял руку и выпалил часть самых простых из них: “Каков ваш график работы? Когда вы сможете предоставить нам работоспособный код? Кто ваши заказчики и в какой очередности вы реализуете их запросы по отношению к нашим? Стоит ли нам вообще надеяться на вас и вашу команду?” Они абсолютно не были готовы к этому и буквально рты поразевали.
       Стало ясно, что ранее они подобных вопросов не рассматривали. Хуже того, они не ожидали, что на них придется отвечать потенциальным клиентам. Я вежливо разъяснил им, что совещание не подготовлено и извинился за то, что они не поняли, чего я от них ожидал, когда соглашался прийти на это совещание (я ведь думал, что они были в курсе дела заранее). Я сказал, что без ответов на эти вопросы совещание и для них самих прошло впустую, после чего предложил отложить встречу до тех пор, пока у них не будет достойных ответов на мои элементарные вопросы. Они смущенно согласились и закончили совещание.
       На языке руководителя проектов все, чем я занимался в этой истории, называлось “не верю” по аналогии с карточной игрой “верю — не верю”, где выигрывает тот, кто первым избавится от всех карт. Делая ход, игрок объявляет свои карты и кладет их в кучку рубашкой вверх. При этом говорить правду он не обязан. Если второй игрок думает, что первый его обманывает, он может сказать: “Не верю”, и заставить первого игрока вскрыть карты. Если он угадает, то первый игрок забирает всю кучку себе (откатываясь далеко назад). Но если он ошибается, то вся кучка достается ему самому.
       Высказывая свое “не верю”, можно дать толчок развитию событий1 {См. статью “How to detect bullshit” no адресу http://www.scottberkun.com/essays/53-how-to-detect-bullshit/.}. Если люди будут ожидать от вас серьезных поставленных ребром вопросов, они подготовят ответы на них еще до встречи с вами. Тогда вам и вашей команде не придется тратить время впустую. Следует помнить, что все виды обмана, включая самообман, работают во вред проекту. Чем скорее вскроется правда, тем раньше вы сможете предпринять какие-нибудь действия. Поскольку многие предпочитают избегать конфликтов и притворяться, что все идет хорошо (даже если совершенно очевидно, что это не так), кто-то должен раскрыть людям глаза. Чем правдивее будут отношения, тем реальнее ваша команда будет смотреть на вещи, двигаясь с высокой скоростью к намеченной цели.
       Прямые вопросы могут быть неприятны людям или организациям и восприниматься как оскорбление или недоверие. Попытки вывести ситуацию на чистую воду могут рассматриваться не как стремление установить истину, а как личные нападки. Возможно, к ситуации, аналогичной той, о которой я рассказал, следует подходить более официально. Составьте перечень вопросов, ответы на которые ожидаете получить, и передайте его организаторам накануне совещания. Или подготовьте перечень вопросов, которые любой специалист организации может задать любому другому человеку (включая вице-президентов и руководителей проектов) в любое время, и вывесите его на стене конференц-зала. Тогда все потенциальные “не верю” станут публичным достоянием, что можно будет ввести в норму, не вызывая обид. Естественно, руководителям время от времени все равно придется говорить “не верю”, демонстрируя команде свою решительность в борьбе за правду.

Определите критический путь

       Согласно терминологии руководителя проекта, критический путь — это наикратчайшая последовательность действий, ведущая к завершению проекта. При исследовании критического пути анализируются диаграммы или блок-схемы, сделанные на основе всех работ и отражающие зависимость каждой работы от остальных. Правильно составленная блок-схема показывает, где могут быть узкие места. К примеру, если работы А, и В не могут быть завершены, пока не будет доделана работа А, значит, именно через работу А проходит критический путь данной части проекта. Его значение заключается в том, что срыв сроков или некачественное выполнение работы А серьезно повлияет на завершение работ Б и В. Поэтому для руководителя проектов важно уметь спланировать критический путь и расположить его работы по приоритетам. Иногда относительно второстепенный компонент сам по себе может оказаться в критически важной зависимости, которая препятствует завершению по-настоящему первоочередной работы. Без анализа критического пути об этом можно не узнать до тех пор, пока не станет поздно что-либо предпринимать1 {Анализ критического пути детально расписан во многих учебниках по управлению проектами. Краткое изложение можно найти по адресу http://en.wikipedla.org/wiki/Critical_path. Более глубоко эта тема изложена в книге Стефана Дево (Stephen Devaux) “Total Project Control” (Wiley, 1999).}.
       Исходя из общей точки зрения, критический путь есть ко всем ситуациям. Для них не требуется таких же детально проработанных блок-схем и расчетов, но рассуждения при оценке тех или иных ситуаций, с которыми приходится сталкиваться руководителям проектов, строятся сходным образом: проблему нужно рассматривать как взаимосвязанную цепь элементов и оценивать при этом все узкие места и критические моменты. Нужно ответить на вопрос, какие именно действия и решения зависят от других решений и действий, а затем подумать, достаточно ли им уделено внимания, не упущены ли в ходе обсуждений какие-нибудь реально существующие проблемы. Процесс разработки проекта можно значительно ускорить, если обратить внимание команды непосредственно на те элементы, факторы и решения, которые оказывают основное влияние на ход работ.
       Нужно всегда иметь представление о критическом пути:
       — Разработки проекта (об этом ранее уже упоминалось).
       — Человеческих взаимоотношений (какие взаимоотношения между людьми подвержены высокой степени риска?).
       — Процесса принятия проектных решений высокого уровня (кто тормозит работу всей команды?).
       — Процесса создания программного кода и классификации ошибок (нет ли каких-нибудь бесполезных форм, совещаний или согласований?).
       — Процесса информационного наполнения Интернета или корпоративной сети.
       — Любых совещаний, ситуаций или процессов, влияющих на выполнение целей проекта.
       Для того чтобы добиться желаемого результата, нужно иметь обостренное чувство критического пути. Мысль о нем должна присутствовать всегда, когда вы входите в кабинет, просматриваете электронную почту или участвуете в принятии решения. Действительно ли проблема является ключевой? Может ли она быть решена в ходе этого обсуждения или размышления? Сконцентрируйте свою энергию (или энергию всех присутствующих) в первую очередь на подобных рассуждениях и определите, что нужно сделать, чтобы сократить критический путь или выделить достаточно ресурсов и не допустить задержек в работе. Если удастся обнаружить критический путь, то расставить по местам менее значимые вопросы станет намного легче.
       В некоторых организациях одним их методов оптимизации критических путей (не относящихся к сфере разработки) может стать распределение полномочий внутри команды. Вместо того чтобы согласовывать все подряд, дайте возможность отдельным специалистам принимать самим соответствующие решения и определять необходимость подобных согласований. Ту же самую практику введите и в отношении различного рода санкционировании, документирований, оформлений и других возможных бюрократических издержек (см. главу 10). Зачастую наилучшим способом оптимизации критического пути в организационной сфере является упразднение каких-нибудь процессов и передача полномочий в низшие звенья и самим командам, а не порождение новых процессов или иерархических структур.

Будьте непреклонны

  Мир реагирует на поступки и ни на что другое.
  Скотт Адаме

       Увидеть проблему по силам многим достаточно умным людям, но далеко не всем из них захочется потратить силы и энергию на поиск ее решения, а затем набраться мужества для его реализации. Всегда найдутся более простые выходы из ситуации: оставить все, как есть, принять половинчатое решение, переждать, пока проблема не исчезнет сама по себе (скрестив пальцы на удачу), или обвинить во всем других людей. Куда труднее встретить проблему во всеоружии и противиться тем способам ее разрешения, которые идут вразрез с поставленными целями. Настоящие руководители проекта так просто не сдаются. Если речь идет о чем-то важном для проекта, они проявят настойчивость, применив любые средства для поиска ответа или решения проблемы. Для этого может понадобиться реорганизация неэффективно работающей команды, принуждение строптивой аудитории к признанию поставленных целей, поиск ответов на вопросы или улаживание существующих разногласий.
       Иногда придется просить людей делать то, что им не нравится, или поднимать такие вопросы, на которые им не хочется отвечать. Без подобного принуждения вас будут склонять к более легкому выходу из положения. Ко многим проектам привлекаются люди, играющие специфические роли и не желающие отвечать за то, что лежит за пределами их ограниченной области (или на стыке их и чьих-то еще интересов). Возможно, еще большую сложность создает стремление большинства из нас избегать любых конфликтных ситуаций. Часто именно руководителю проекта приходится задавать неудобные вопросы, предъявлять претензии и добиваться истины, невзирая на доставляемые другим неприятности (хотя его задача — преподнести все как можно мягче). Ничего другого руководителю проекта просто не остается.
       Зачастую те ситуации, которые изначально представлялись невозможными или безвыходными, рушатся под натиском психологических усилий непреклонного руководителя проекта. В этом отношении классическим примером может послужить миссия “Аполлона-13”. Гин Кранз (Gene Kranz) в своей книге “Failure Is Not an Option” (Berkeley Publishing, 2001) описал, какие усилия были предприняты для ремонта системы жизнеобеспечения поврежденного космического корабля. Инженерная задача, с которой пришлось столкнуться команде, была из разряда сложнейших, и даже самые опытные специалисты сильно сомневались, что в сложившейся ситуации можно хоть что-нибудь сделать. Причем нужно было не только отыскать выход, но и сделать это в условиях острого дефицита времени. Кранз отказался от всех облегченных способов выхода из ситуации и нацелил команду на исследование всех возможных вариантов, подытоживая проводимые диспуты и направляя энергию в нужное русло. Все три версии этой истории, фильм “Аполлон-13”, книга Кранза и книга “Lost Moon” (Pocket, 1995), написанная капитаном корабля Джимом Ловеллом (Jim Lovell) и Джеффри Клуджером (Jeffrey Kluger), дали самые превосходные оценки одному из величайших в истории примеру успешного управления проектом и решения сложнейшей проблемы.
       Удачливые руководители проектов, прежде чем окончательно опустить руки, просто рассматривают намного больше всевозможных вариантов, чем обычные люди. Они исследуют те предположения, которые были безоговорочно отвергнуты другими, поскольку на их счет были высказаны какие-то опасения со стороны высшего руководства или они были забракованы экспертизой, в результатах которой никто не посчитал нужным усомниться. Вопрос: “Как вам удалось добыть эти сведения?” — самый простой способ разузнать, что является мнимым, а что действительным, хотя многие просто боятся или забывают его задать. Непреклонность основана на уверенности, что независимо от того, кто выступает в роли оппонента, в 99% случаев решение проблемы может быть найдено (включая и те случаи, когда изменению подвергается сама формулировка проблемы), а если его все-таки не удастся найти, оперируя доступной информацией, значит, нужно глубже исследовать проблему. Всегда в первую очередь нужно думать об успехе проекта.
       Когда я работал в подразделении Microsoft, занимавшемся разработкой Windows, моим руководителем был Хиллел Куперман (Hillel Cooperman), возможно, самый страстный и преданный делу руководитель за всю мою практику. Мне запомнилось, как однажды я пришел к нему в кабинет с одной дилеммой. Моя команда застряла на решении довольно сложной проблемы, имевшей отношение как к разработке, так и к политике. Для создания одного важного для нас компонента нам нужно было привлечь другую организацию, которая не хотела этим заниматься. Я обсудил вопрос со всеми заинтересованными лицами, заручился поддержкой влиятельных людей, но ничего так и не сдвинулось с места. Казалось, никакого разумного решения просто не существует, хотя вопрос по-прежнему оставался для нашего проекта важным, и я знал, что отступать некуда. После того как я обрисовал сложившуюся ситуацию, произошел следующий диалог: “И что ты успел перепробовать?” — я опрометчиво ответил: “Да все, что можно”. Он посмеялся надо мной: “Неужели все? И как же тебе это удалось? Да если бы ты все перепробовал, то наверняка нашел бы приемлемое решение, которого у тебя до сих пор почему-то нет”. Сложилась забавная ситуация, поскольку мы оба отлично знали, куда дальше зайдет разговор.
       Затем он спросил, не нуждаюсь ли я в совете. Разумеется, я ответил утвердительно. Он несколько минут походил взад-вперед по комнате, бормоча что-то в такт своим шагам, и придумал массу новых вещей, над которыми следовало бы задуматься. “Так, кому ты еще не звонил? Электронная почта для этих дел не подходит. Да, с кем из тех, кто с тобой не согласен, у тебя хорошие отношения? Достаточно ли убедительно ты уговаривал их откликнуться на свою просьбу? Может быть, мне тоже следует вмешаться и обработать кого-нибудь на более высоком уровне? Сможет ли это сработать? Что если обратиться к нашему вице-президенту? Проявил ли ты достаточную настойчивость, подталкивая своих разработчиков к поиску обходного решения? Сколько раз ты пытался это сделать, пару раз? Неоднократно? Сделал все, что мог? Предлагал ли ты им напитки за счет фирмы? Или пообедать? Как ты с ними разговаривал, с каждым с глазу на глаз или со всеми сразу? Прояви настойчивость. Выход обязательно найдется. Я верю, ты решишь эту проблему. Только ни за что не сдавайся”.
       В результате он оказал мне двойную поддержку: напомнил, что мною еще не все перепробовано, но при этом дал понять, что принимать решение — это по-прежнему только моя прерогатива. Я, конечно, устал от всего этого, но его кабинет покидал с убеждением, что запас неисследованных путей еще не исчерпан, и мне следовало этим воспользоваться. Он подтвердил то, что кроме меня решать этот вопрос некому, и это придало мне дополнительные силы для проявления своей непреклонности. Решение крылось в одном из этих путей, мне просто нужно было его отыскать. Я в конце концов нашел решение этой проблемы (оно заключалось в организации обходного пути), как, впрочем, и десятка других, накопившихся к тому времени, но это произошло лишь потому, что я был нацелен на решение, оно не пришло ко мне само по себе.
       Среди всего прочего, я научился у Хиллела тому, что битвы выигрываются усердным трудом. Если вы поймете, что окончательно измотаны, но будете биться над конкретной проблемой до конца, вы найдете новые возможности для ее решения. Если вы останетесь непреклонным достаточно долго, то люди усомнятся в собственных предположениях. Вы подтолкнете их к рассмотрению ранее упущенных возможностей, в которых зачастую и кроется ответ на нужный вопрос. Даже если возникнут трения и понадобятся переговоры, сознание собственной правоты и ваша настойчивость, скорее всего, заставят людей уступить. Иногда они могут сдаться только затем, чтобы вы оставили их в покое. Настойчивость при условии, что вы не перейдете на оскорбления, сама по себе может стать весьма эффективным приемом.
       Непреклонность лежит в основе способностей добиваться желаемого результата. Существует масса способов пустить проект под откос, поэтому если за ним не стоит хотя бы одна заряженная на победу сила, толкающая его вперед, выискивающая альтернативные варианты его развития, хранящая веру в то, что из любой проблемы и западни всегда можно найти достойный выход, — проект обречен на провал. Эту силу представляют хорошие руководители проекта. Они двигают проект, находятся в постоянном поиске каких-то лучших, более быстрых и разумных путей его развития. Они выискивают все хаотичное и превращают его в нечто вполне разумное. Руководитель проекта при всем скептическом отношении к окружающему миру, необходимом в его работе, проявляет оптимизм, считая, что все проблемы могут быть решены при достаточной настойчивости и сосредоточенности. По причинам, которые они сами не вполне могут объяснить, руководители проектов неизменно выискивают всевозможные неоднозначные и сомнительные моменты и не сдаются до тех пор, пока не исследуют все возможные варианты выхода из возникшей ситуации. Они верят в то, что мысль непобедима, а чтобы отыскать хорошие мысли, следует немало потрудиться.

Оставайтесь в рамках здравого смысла

       Непреклонность не означает, что следует стучаться во все двери подряд, отлавливать людей на проходной или торчать на работе до обморочного состояния. Может быть, работать с полным напряжением сил и неплохо, но работать всегда лучше с умом, а не только с усердием. Будьте непреклонны в силе духа, но в поступках лучше полагаться на сообразительность и здравый смысл. Отказ сдаваться не должен означать, что нужно страдать от бессмысленных, глупых или бесполезных поступков (хотя иногда избежать их не удается). Нужно искать разумные обходные пути или наиболее быстрые способы решения проблемы. Воспользуйтесь помощью окружающих вас людей и не думайте, что вы все должны делать самостоятельно. Но важнее всего быть восприимчивым ко всему, что происходит вокруг вас, вокруг отдельных сотрудников и всей команды.
       Основная ошибка многих руководителей проектов заключается в том, что они забывают изучить тех, с кем работают, и соответствующим образом скорректировать свои подходы к ним. “Морские котики” и армейские рейнджеры тренируются в выполнении заданий в различных условиях местности: в пустынях, болотах, джунглях, тундре. Без этих тренировок эффективность их действий окажется ограниченной: им придется выживать на незнакомой местности, поскольку у них не будут выработаны соответствующие навыки (представьте, что солдат в зелено-оливковом камуфляже пытается остаться незамеченным на заснеженном поле). Перво-наперво на основе имеющихся навыков они учатся, как оценивать обстановку и продумывать тактику и стратегию применительно к создавшейся обстановке. Этот же прием вполне подойдет руководителям проектов. Вместо окружающей местности руководителям проектов следует уделить внимание изучению различной социальной, политической и организационной обстановки, в которую они попали, и воспользоваться правильными подходами применительно к создавшейся ситуации.
       Придерживаться здравого смысла и оценивать окружающую обстановку особенно важно в следующих ситуациях:
       — Настраивая и побуждая людей к действию.
       — Организуя работу команды и планируя действия.
       — Улаживая споры или отыскивая выходы из тупиковых ситуаций.
       — Проводя переговоры с представителями других организаций или учреждений.
       — Требуя дополнительные ресурсы.
       — Убеждая людей в чем-нибудь.
       — Разбираясь с отчетами (с персоналом).
       Далее приводится краткое руководство для руководителей проектов по использованию здравого смысла при оценке обстановки. Данный перечень вопросов пригоден как при общении с отдельными сотрудниками, так и в работе с большой командой или группой людей.
       — Какой стиль общения был использован? Прямой или опосредованный? Каким было это общение, открытым или сдержанным? Применялись ли общепринятые приемы доказательства отдельных положений? Было ли общение по электронной почте более эффективным? Или эффективнее оказалось проведение совещаний? Как принимались решения, в открытом обсуждении или кулуарно? Выберите такие подходы к общению, которые будут эффективными независимо от того, с кем именно вы беседуете.
       — Насколько развито у сотрудников коллективное чувство юмора? Какие темы закрыты для шуток или вопросов? Как другие справляются деликатными (сложными, спорными) темами или решениями?
       — Можно ли выиграть спор, оперируя данными? С помощью логических доводов, высказанных в ходе дискуссии? Строго придерживаясь целей проекта? Кто громче всех кричит? Кто откровеннее всех скучает? Продумайте, как использовать аргументы, которые можно изложить в подходящих для данной аудитории стиле, формате или тоне, кто бы это ни был: тестировщик, которого вы остановили в коридоре, или полный зал разработчиков.
       — Кто хорошо справляется с <вставьте то, что вы пытаетесь сделать>, и смогу ли я научиться этому у него или повторить его действия? Обращайте внимание на эффективные приемы работы. Кто в них преуспел больше всех? Кто завоевал наибольшее уважение? Как они сумели этого добиться? Кто потерпел неудачу, пытаясь это сделать? По каким причинам?
       — Что в моем поведении ценится этим человеком или группой больше всего? Сообразительность? Смелость? Расторопность? Ясность высказываний? Терпеливость? Покорность? Какая манера поведения ценится меньше всего или порицается? Программисты и управленцы могут сильно расходиться в оценке. Поэтому перед тем как кого-то в чем-то убеждать, следует изучить его шкалу ценностей.
       — В чем заключаются особенности организационной культуры? В каждом университете, в каждой корпорации или команде существуют различные взгляды на культурные ценности. Если вы думаете, что в вашей организации в этом смысле нет ничего особенного, значит, длительный срок пребывания в ее стенах наложил на вас свой отпечаток, и вы утратили способность замечать эти особенности (а может быть, вы изначально не были способны к этому). В одних организациях ценится лояльность и уважительное отношение к интеллектуалам, обладающим яркой индивидуальностью. В других организациях упор делается на производственную этику и строгое выполнение возложенных обязанностей.
       Руководитель проекта должен корректировать стиль своей работы, основываясь на ответах на данные вопросы. Входя в чей-то кабинет или на чье-нибудь совещание, всегда нужно действовать по обстановке. Надо брать пример с морских пехотинцев: сначала оценить сложившуюся обстановку, а потом уже делать выводы о том, каким должен быть путь к достижению целей проекта. Не стоит выбирать трудный путь, если есть более разумный подход к решению поставленных задач.

Партизанская тактика

       Придерживаться здравого смысла означает быть в постоянном поиске разумного подхода и стремиться применять его как можно чаще. В приводимом далее перечне собраны тактические приемы, когда-то успешно примененные мною или кем-то в отношении меня самого. Не знаю, насколько полезными окажутся для вас некоторые из этих приемов, но в целом я уверен, что этот перечень заставит вас задуматься о поисках разумного подхода к достижению поставленных целей. Некоторые приемы достаточно рискованны (о чем вы будете предупреждены), поэтому их следует применять с осторожностью. Даже если вам из этого перечня ничего не подойдет, узнав о нем, вы станете более осмысленно оценивать окружающую вас обстановку.
       — Ищите тех, кто обладает реальными полномочиями. Не тратьте попусту время на споры с людьми, которые не имеют никакого влияния на проблемный вопрос. Серьезный подход к делу требует разузнать, кто принимает решения или может повлиять на возникшую проблему или ситуацию. Отыщите этих людей (ими могут оказаться и не самые главные из присутствующих, в зависимости от характера проблемы это могут быть разные люди), поговорите ними с глазу на глаз и сделайте выводы. Или, по крайней мере, выясните суть их возражений. Если вы не можете заручиться поддержкой наиболее влиятельного человека (скажем, Салли или вице-президента), найдите того, кто может в большей степени повлиять на него самого (лучший специалист из команды Салли). Проберитесь как можно выше к верхним ступеням этой лестницы. Но будьте осторожны: не пытайтесь ввести людей в заблуждение. Добейтесь поддержки влиятельных людей, но при этом, если потребуется, привлеките и сторонников противоположной точки зрения или раскройте перед ними свои карты. “Послушайте, при всем нашем несогласии у нас не вызывает сомнения, что это решение принадлежит Салли. Я собираюсь поговорить с ней об этом завтра и хочу, чтобы вы присутствовали при этом разговоре”. (См. главу 16.)
       — Обращайтесь к первоисточнику. Если информация имеет сложный характер, не тратьте зря время, выслушивая ее в чьем-то пересказе или пользуясь лишь письменными отчетами или сообщениями электронной почты. Найдите автора этой информации и поговорите с ним непосредственно. Никакие отчеты или сообщения не смогут ответить вам на возникшие вопросы, а кроме того, в общении могут вскрыться некоторые важные моменты, не нашедшие письменного отражения. Обращаться к первоисточнику всегда надежнее и ценнее, чем получать информацию по другим каналам, и ваши усилия в этом направлении будут вполне оправданы. К примеру, если два программиста спорят о том, что именно сказал третий, то лучше сходить к этому третьему или уточнить все по телефону. Всегда стремитесь добыть истинную информацию и настраивайте на то же самое других.
       — Меняйте способ общения. Если общение не складывается, нужно изменить его способ. Вместо обмена сообщениями по электронной почте позвоните по телефону. Вместо звонка заявитесь прямо в офис. Каждый чувствует себя более комфортно, пользуясь теми или иными способами общения. (Вообще-то, предпочтительнее всего личное общение у классной доски. Если общение по электронной почте по каким-то причинам приобретает неуправляемый характер, соберите людей в комнате, оборудованной классной доской.) Не допускайте, чтобы ограничения, накладываемые конкретными технологиями общения, становились на вашем пути. Иногда смена способа общения приводит к разным ответам на одни и те же вопросы, поскольку восприимчивость людей меняется в зависимости от избранного способа. Если речь идет об улучшении динамики общения между вами и вашими сотрудниками, играющими важную роль в каком-нибудь серьезном деле, придется потратить время и деньги на авиаперелет или на поездку в их офис.
       — Оставайтесь с людьми наедине. Когда вы разговариваете с человеком без свидетелей, его отношение к вам отличается о того, которое складывается при разговоре в присутствии большой группы людей. На совещаниях выступающие должны приспосабливать свою речь, чтобы она как можно лучше воспринималась всеми присутствующими в зале. Иногда, в зависимости от состава слушателей, можно услышать совершенно разные вещи. Если вы хотите добиться откровенного мнения или провести с кем-то задушевную беседу, нужно остаться с человеком наедине. Следует учесть и влияние людей друг на друга: если Джим прислушивается к мнению Бет, а вы хотите в чем-нибудь убедить Джима, то вам сначала следует в приватной беседе убедить в этом Бет. Не заманивайте никого в западню, но и не уклоняйтесь от выяснения всего, что может ускорить прогресс.
       — Устраивайте охоту на людей. Если появилось срочное дело, времени на которое явно не хватает, нужно выкроить его из вашего рабочего графика и взять в осаду офис или то место, где работает нужный вам специалист. Подобные вещи мне приходилось проделывать неоднократно. Если сотрудник не отвечал на мои звонки и сообщения электронной почты, то, вернувшись с какого-нибудь совещания, он заставал меня сидящим возле его двери. В порядке вещей было и то, что его останавливала заранее предупрежденная мною охрана. В том, что вам придется бегать за кем-то, в ком вы остро нуждаетесь, нет ничего зазорного. Ищите этого человека в буфете. Обойдите во время обеденного перерыва все близлежащие забегаловки. Спрашивайте у секретарей, на каком совещании он может присутствовать, и ждите его за дверью. Не нарушая этикета, ведите решительную охоту и всегда добивайтесь своего. (В личную жизнь постарайтесь не вмешиваться. Если вы охотитесь за информацией, переступать эту грань нельзя ни при каких обстоятельствах.)
       — Прячьтесь. Если накапливается много работы и вам нужно выиграть время, чтобы нагнать упущенное, превращайтесь в невидимку. Время от времени я занимал конференц-зал (в соседнем здании) и сообщал об этом только узкому кругу людей, которым полагалось знать, где я находился. Там без каких-либо помех я разбирал электронную почту, вел корректуру технических условий, оценивал работу подчиненных или подчищал какие-нибудь другие важные “хвосты”. В небольших организациях такого же эффекта можно добиться, работая дома или в ближайшем кафе (что стало намного проще с появлением беспроводных сетей). Я всегда именно так и поступал, когда чувствовал в этом необходимость. У руководителя проекта редко бывает время, когда его никто не отвлекает, поэтому приходится предоставлять такое время самому себе.
       — Пользуйтесь советами. Не совершайте невынужденных “слепых полетов”. В каждой конкретной ситуации считайтесь с тем, что кто-то продумал ее глубже вас и может дать дельный совет, как добиться нужного результата. Воспользуйтесь любыми доступными знаниями или опытом других людей. Отведите их в сторонку и попросите поделиться своим опытом с вами, неважно, к чему это относится, к общению с конкретным человеком, к решению, к плану и т.д. “Послушай, Боб, я хотел бы услышать от тебя совет по поводу этого бюджета. У тебя не найдется пара минут?” Или: “Джейн, я пытаюсь поработать над этой проблемой вместе с Сэмом. Посоветуй, как его убедить отказаться вот от этой характеристики?” Для многих людей просьба дать совет только повысит их доверие к вам, поскольку если вы просите человека поделиться с вами его мнением, значит, вы оказываете ему уважение.
       — Просите оказать любезность, умоляйте, идите на подкуп. Воспользуйтесь своей репутацией, чтобы извлечь выгоду из оказываемого вам доверия и великодушного отношения. Если вам нужно, чтобы разработчик выполнял сверхурочную работу, возникшую из-за ваших просчетов или связанную с задержкой требований, попросите его об одолжении. Выйдите за рамки жестких рабочих взаимоотношений и просто попросите его об этом. Предложите ему пообедать за ваш счет (двадцать долларов тоже кое-что значат независимо от степени его расположенности к вам) или скажите, что один обед будет за вами (и потом обязательно сдержите обещание). Худшее из всего, что может быть, это отрицательный ответ на вашу просьбу. Чем благосклоннее вы были по отношению к другим, тем больше сможете поставить на кон в этом деле. Можно пойти и дальше. Нет ничего зазорного в том, чтобы что-то предлагать людям, убеждая их оказать вам помощь в выполнении работы, которую нужно сделать во что бы то ни стало.
       — Сталкивайте людей лбами. Если делать все предельно осторожно, то в этом нет ничего плохого. Если Сэм оценивает продолжительность работы в 10 дней, а вы думаете, что он лукавит, обратитесь к Бобу. Если Боб определил меньший срок, вернитесь вместе с ним к Сэму. В разговоре сразу выяснится, каким должен быть реальный срок выполнения работы. Если вы однажды так и сделаете, то никто из разработчиков больше не отважится лукавить относительно сроков работы (поскольку вы сказали “не верю”). Однако у Сэма может быть такой характер, что вы испортите с ним отношения, поэтому делать все нужно как можно тактичнее и только в случае острой необходимости. Хорошие ведущие программисты сами должны заставить всех раскрыть карты, но если они этого не делают, все придется решать вам.
       — Подготавливайте почву. Никогда не ходите на важное совещание, не имея никакого представления о мнениях наиболее влиятельных из участвующих в нем людей. Всегда приходите на него, заранее зная, кто готов поддержать ваше мнение, а кто, скорее всего, будет против, и имея готовую стратегиею, разработанную для того, чтобы справиться с ситуацией (см. главу 16). Если под угрозой находится что-то важное, предпримите необходимые меры, чтобы до начала совещания поколебать позицию противников или сплотить сторонников. Не прибегайте ко лжи и манипуляциям, не вводите людей в заблуждение, лучше как следует подготовьтесь и разберитесь со всеми подходящими доводами и возражениями.
       — Покупайте людям кофе и что-нибудь вкусное. Как бы глупо это ни звучало, но я понял, что люди, с которыми я вел многодневные споры, в конце концов, становятся более покладистыми после чашки хорошего кофе, выпитой в ближайшем кафе. Измените динамику взаимоотношений: неважно, нравится вам этот человек или нет, потратьте буквально двадцать секунд на приглашение. Даже если он скажет: “Нет, лучше поговорить именно здесь?” — вы ничего не потеряете. Перенос разговора в другую, может быть, менее формальную обстановку поможет ему допустить возможность вариантов, которые раньше он не принимал во внимание. С точки зрения биологии, после того как люди попробовали что-нибудь вкусное или побывали в более приятной обстановке, их настроение улучшается. Я знавал руководителей проектов, которые специально для таких случаев держали в кабинете пончики и пирожные (а также ром и шотландское виски). Можно ли считать это проявлением доброжелательности? Да, но на первый план выходят психологические выгоды от того, что люди, с которыми вы работаете, неплохо перекусят и станут ассоциировать вас с чем-то хорошим.

Выводы

       — В списке приоритетов можно отразить все, что угодно. Значительную часть своего времени руководитель проекта затрачивает на правильную расстановку приоритетов и руководство командой в соответствии с ними.
       — Тремя типичными списками приоритетов являются список целей (концепция), список характеристик (функциональная спецификация) и перечень работ. Их необходимо согласовать друг с другом. Каждая работа должна обеспечивать реализацию заданной характеристики, а каждая характеристика следовать определенной цели.
       — Между первоочередными и всеми остальными приоритетами нужно провести жирную черту.
       — Все задуманное будет осуществлено, если вы научитесь говорить “нет”. Если вы не можете сказать “нет”, значит, у вас фактически нет никаких приоритетов.
       — Руководитель проекта должен быть воплощением честности в команде и постоянно держать ее в курсе реального состояния дел.
       — Знание критического пути в процессах разработки и управления командой позволяет повысить эффективность работы над проектом.
       — Чтобы осуществить задуманное, вы должны проявлять непреклонность и оставаться в рамках здравого смысла.

Упражнения

       1. Подумайте о нерабочей ситуации, в которой не было заранее определенного лидера, может быть о каком-то общественном событии или учебном проекте. Кто вызвался стать лидером и почему? Этот человек открыто попросил об этом или сам взял на себя управление ситуацией?
       2. Добровольно согласитесь вести какое-нибудь дело, в котором никто не обязан на вас работать и добиться желаемого можно только через убеждение и влияние. Создайте какую-нибудь социальную группу на веб-сайте Meetup (www.meetup.com) или запись о команде из спортивной лиги в вашем сетевом окружении. Используйте это в чисто исследовательских целях, чтобы проверить свою способность добиваться желаемого.
       3. Кто в вашей организации имеет репутацию человека, который всегда осуществляет задуманное? Как такие люди этого добиваются? Есть ли в организации люди, которых считают не способными осуществлять задуманное? Есть ли какая-нибудь взаимосвязь между их положением в команде и способностью осуществлять задуманное?
       4. Для каждой имеющейся задачи определите одного, наиболее важного человека, способного добиться ее осуществления (чаще всего это какой-нибудь программист или руководитель команды). Удостоверьтесь в том, что ему известна важность его роли в выполнении задачи и ваша готовность всячески содействовать его успеху.
       5. Как вы следите за приоритетами своей команды? Как вы обеспечиваете их наглядность и ясность для всех сотрудников? Попросите своих специалистов высказаться насчет способов, позволяющих сделать приоритеты более запоминаемыми.
       6. Представьте себе проект, где критический путь для большинства работ проходит через работу одного-единственного специалиста. Какие “за” и “против”можно высказать по поводу подобной ситуации? Каков диапазон возможных действий, которые можно предпринять либо для сокращения рисков, либо для повышения шансов на успех?
       7. Приходилось ли вам работать под руководством человека, постоянно меняющего свое мнение? Как это обстоятельство влияло на ваши возможности осуществления задуманного? А что вы можете сказать о ком-то, кто никогда не менял своего мнения?
       8. Если здравомыслие является частью способности добиваться задуманного, то как это может отразиться на процессе найма на работу руководителей проектов и лидеров? Как во время собеседования можно оценить чью-то возможность проявлять убедительность?
       9. Вы решили стать неутомимым руководителем проекта. Вы изо всех сил стараетесь добиться задуманного и никогда не сдаетесь. Ваш начальник и другие руководители команды заметили это и явно насторожились в ответ на ваше новое отношение к работе. Как добиться желаемого, не раскачивая лодку и не расстраивая других лидеров?
       10. Как выбрать подходящий момент для визита к начальнику или к начальнику своего начальника, чтобы добиться задуманного? Как проявить благоразумие, проталкивая нужный вопрос вверх по цепочке управления?
       11. Если говорить: “Мы не должны смириться с провалом”, то это будет пустым звуком. Многие используют высказывания из кинофильмов в надежде на то, что произнесенные фразы дадут все необходимое для достижения успеха. Пригласите в рабочее время свою команду посмотреть фильм “Аполлон-13”. Обсудите с ней, какими качествами, позволяющими добиться успеха, обладали Кранз и его команда. И чем от них отличается ваша команда?




<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:56 MSK


Постоянный адрес статьи:
http://az-design.ru/Projects/AzBook/src/004/02MS1300.shtml