Скотт Беркун - Искусство управления IT-проектами

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

Сложности в выборе приоритетов всегда носят больше эмоционально-психологический, чем прагматический характер, независимо от того, что говорят на этот счет люди. Исключение желательных (но не обязательных) вещей, как и при соблюдении диеты или экономии денег, требует дисциплинированности, выдержки и сосредоточенности на главном. Говорить: «Для нас важна стабильность» – это одно, а сопоставить стабильность с другими важными свойствами – совсем другое. Многие руководители перед этим пасуют. Они занимают выжидательную позицию, откладывают трудный выбор на потом или вовсе отказываются от него и в результате приводят проекты к краху. Без трудного выбора прогресс невозможен. Если подходить к нему отвлеченно, то слово «важный» ровным счетом ничего не означает. Поэтому составление списков приоритетов и определение места, где должна пройти черта, отделяющая первоочередные приоритеты, требует от руководителей, да и от всей команды принятия нелегких решений и ясности мышления.

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

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

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

• Какую проблему мы пытаемся решить?

• Если проблем несколько, то какая из них представляет наибольшую важность?

• Как данная проблема соотносится с нашими целями или влияет на них?

• Каков простейший способ исправить ситуацию, позволяющий достичь наших целей?

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

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

Но вместо мелочной опеки («Делай это. Не делай то. Не делай так. Ты что, уже сделал? Ну, и что теперь делать?») я доводил до сознания подчиненных, что моя задача – в нужный момент помочь им расставить приоритеты. Поскольку они не имели такого же широкого взгляда на проект, какой был у меня, я должен был помочь им хотя бы на какое-то мгновенье увидеть, как все, чем они занимались, соотносится с проектом в целом. Когда весь день уходит на отладку модуля или на тестирование компонента программы, весьма полезно выслушать объяснение общих положений проекта и заверения в том, что находишься на правильном пути. Порой, чтобы убедиться, что все «держат руку на пульсе», хватало и полуминутного разговора.

Когда же поступала новая информация по проекту, то именно я должен был в ней разбираться (либо самостоятельно, либо в ходе коллективного обсуждения), чтобы найти ей место в перечне приоритетов. Рабочий список приоритетов приходилось пересматривать довольно часто, поскольку в него нужно было вносить изменения, связанные с поступавшей информацией. Могло измениться мнение вице-президента. При изучении потребительских качеств продукта могли вскрыться новые проблемы. Конкурент мог внести в свой продукт какие-нибудь неожиданные изменения. Наши приоритеты были похожи на живой организм, на состоянии которого моментально и непосредственно отражались любые изменения в целях или в направлении развития проекта.

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

Побочным эффектом от наличия списка приоритетов является частое использование слова «нет», которое многим дается совсем не легко. Однако не научившись говорить «нет», невозможно следовать каким бы то ни было приоритетам. Мир велик, а перечень первоочередных приоритетов краток. Поэтому большая часть из того, что в мире (или в вашей команде) многим представляется грандиозным, должно быть отклонено из-за несоответствия целям проекта. Это совсем не означает, что идеи сами по себе плохи, суть в том, что они не способствуют реализации данного конкретного проекта. Итак, для руководителей проектов действует следующий основной закон: если вы не можете сказать «нет», значит, вы не в состоянии управлять проектом.[77]

Употребление слова «нет» начинается с руководства. Когда именно специалисты могут сказать «нет» в ответ на какие-либо запросы, определяется старшим руководством. Если руководитель команды независимо от расставленных приоритетов все время говорят «да», его примеру последуют другие. Программисты начнут разрабатывать только то, что им нравится. Руководители проектов начнут добавлять (или убирать) требования по своему усмотрению. Даже если отдельные избранные ими действия окажутся удачными, потеря командой единых правил и работы в направлении установленных приоритетов приведет к возникновению конфликтов. Порой все это может выразиться в форме разногласий в среде программистов, но чаще всего результатом будет разлад в конечных намерениях. От этого пострадает буквально все, и стабильность, и производительность, и потребительские свойства продукта. Без следования приоритетам заставить команду согласованно работать над созданием единого продукта очень трудно. Лучшие ведущие специалисты и руководители команд знают, что всему не вписывающемуся в рамки приоритетов нужно говорить «нет», устанавливая ту же норму и для всей команды.