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