Но вместо мелочной опеки («Делай это. Не делай то. Не делай так. Ты что, уже сделал? Ну, и что теперь делать?») я доводил до сознания подчиненных, что моя задача – в нужный момент помочь им расставить приоритеты. Поскольку они не имели такого же широкого взгляда на проект, какой был у меня, я должен был помочь им хотя бы на какое-то мгновенье увидеть, как все, чем они занимались, соотносится с проектом в целом. Когда весь день уходит на отладку модуля или на тестирование компонента программы, весьма полезно выслушать объяснение общих положений проекта и заверения в том, что находишься на правильном пути. Порой, чтобы убедиться, что все «держат руку на пульсе», хватало и полуминутного разговора.
Когда же поступала новая информация по проекту, то именно я должен был в ней разбираться (либо самостоятельно, либо в ходе коллективного обсуждения), чтобы найти ей место в перечне приоритетов. Рабочий список приоритетов приходилось пересматривать довольно часто, поскольку в него нужно было вносить изменения, связанные с поступавшей информацией. Могло измениться мнение вице-президента. При изучении потребительских качеств продукта могли вскрыться новые проблемы. Конкурент мог внести в свой продукт какие-нибудь неожиданные изменения. Наши приоритеты были похожи на живой организм, на состоянии которого моментально и непосредственно отражались любые изменения в целях или в направлении развития проекта.
Поскольку вся работа по расстановке приоритетов лежала на мне, я дал возможность команде сосредоточиться на главном и таким образом способствовал прогрессу в ее работе. Иногда можно было воспользоваться приоритетами, определенными моим руководством (в концептуальных документах, в целях группы); а иногда я должен был готовить их самостоятельно, реагируя на возникновение неоднозначных или непредвиденных обстоятельств. То есть в первую очередь я был тем самым механизмом, который генерировал приоритеты. Если когда-нибудь собирательному образу руководителя проекта поставят памятник, я думаю, что на нем будет такая надпись: «Ведите ко мне толпы заблудших, запутавшихся, обозленных и огорченных программистов, жаждущих просветления».
Побочным эффектом от наличия списка приоритетов является частое использование слова «нет», которое многим дается совсем не легко. Однако не научившись говорить «нет», невозможно следовать каким бы то ни было приоритетам. Мир велик, а перечень первоочередных приоритетов краток. Поэтому большая часть из того, что в мире (или в вашей команде) многим представляется грандиозным, должно быть отклонено из-за несоответствия целям проекта. Это совсем не означает, что идеи сами по себе плохи, суть в том, что они не способствуют реализации данного конкретного проекта. Итак, для руководителей проектов действует следующий основной закон: если вы не можете сказать «нет», значит, вы не в состоянии управлять проектом.[77]
Употребление слова «нет» начинается с руководства. Когда именно специалисты могут сказать «нет» в ответ на какие-либо запросы, определяется старшим руководством. Если руководитель команды независимо от расставленных приоритетов все время говорят «да», его примеру последуют другие. Программисты начнут разрабатывать только то, что им нравится. Руководители проектов начнут добавлять (или убирать) требования по своему усмотрению. Даже если отдельные избранные ими действия окажутся удачными, потеря командой единых правил и работы в направлении установленных приоритетов приведет к возникновению конфликтов. Порой все это может выразиться в форме разногласий в среде программистов, но чаще всего результатом будет разлад в конечных намерениях. От этого пострадает буквально все, и стабильность, и производительность, и потребительские свойства продукта. Без следования приоритетам заставить команду согласованно работать над созданием единого продукта очень трудно. Лучшие ведущие специалисты и руководители команд знают, что всему не вписывающемуся в рамки приоритетов нужно говорить «нет», устанавливая ту же норму и для всей команды.
