Аудиоверсия статьи Скачать аудиоверсию можно здесь Говорить «нет» - неотъемлемая часть нашей работы в качестве продакт-менеджеров: стараться угодить всем и принимать во внимание каждую идею - вряд ли можно назвать рецептом достижения успеха при разработке продукта. Но сказать «нет» может быть достаточно сложно, особенно когда мы сталкиваемся с авторитетным, самоуверенным стейкхолдером (заинтересованным лицом, совладельцем, ключевым партнером, руководителем, и т.д.). Эта статья предлагает пять практических советов, которые помогут вам правильно отказать.  В качестве примера представим ситуацию, что вы разговариваете с Джоном, старшим продавцом, который какое-то время работал с определенным продуктом. Джон упоминает о предстоящем релизе продукта и говорит: «Нам необходимо добавить более детализированную отчетность. Я разговаривал с несколькими клиентами, и все они подтвердили, что это крайне важно.” Однако вы знаете, что добавление дополнительной фичи в процесс разработки сейчас невозможно. Команда разработчиков еле справляется с текущей рабочей нагрузкой, и перенос даты релиза - не вариант.  Более того, вы предполагаете, что предложение Джона может быть мотивировано в большей степени его желанием вписаться в план продаж. Джон - влиятельный человек со связями, которому не нравится, когда с ним не соглашаются. Как можно отклонить его предложение, не задев его и не потеряв его поддержки?  Вы также можете ознакомится с содержимым этой статьи на моем YouTube канале.  Отклонить просьбу может быть трудно. Вы, наверное, не захотите разочаровать Джона в данной ситуации, ввиду вашего переживания за негативную реакцию на отказ и возможное возникновение конфликта, ведь вы хотите, чтобы коллеги видели вашу готовность помочь, а не считали вас человеком, всегда говорящим “нет”. Однако говорить “нет” - это неотъемлемая часть работы продакт-менеджера. Если говорить «да» на каждую идею и запрос, то вы получите суп из фич, продукт с размытыми предлагаемыми преимуществами и невнятным юзер экспириенсом. Как однажды сказал Стив Джобс: «Инновации говорят «нет» тысячам вещей. Выбирать нужно с умом». (“Innovation is saying ‘no’ to 1,000 things. You have to pick carefully.”) Если вы считаете, что не можете сказать Джону “нет”, это скорее всего указывает на отсутствие у вас надлежащих полномочий. Возможно, вам не хватает авторитета и уважения, которые необходимы для того, чтобы отвечать за продукт и за его успешную реализацию. Если причина кроется в этом, вам следует узнать о способах, как укрепить свое лидерство в курировании продукта. Ознакомьтесь с моей статьей “Boost Your Product Leadership Power”, где есть подробные рекомендации на эту тему. Придя к заключению, что вы все таки не можете удовлетворить просьбу Джона, у вас может возникнуть соблазн поделиться своим мнением с ним и сказать что-то вроде: «Извини, Джон. Но я не могу добавить эту фичу в текущую версию. Команда разработчиков изо всех сил пытается реализовать уже согласованные фичи, и, как вы знаете, мы не можем сдвинуть сроки». Может показаться, что ответ разумный: он прямолинейный и содержит объяснение. Но будет ли от это толк?  Если Джон не почувствует, что он услышан и понят, ему будет трудно принять отрицательный ответ, независимо от того, насколько убедительны ваши аргументы. Вместо этого он может почувствовать себя отвергнутым и испытать чувство разочарования или гнева. Он может подумать, что вы обесцениваете его мнение и что вас не заботят его просьбы. Следовательно, Джон не сможет больше полностью доверять вам и не захочет поддерживать.  Для того, чтобы избежать подобной ситуации и увеличить шансы того, что Джон примет отказ, выразите понимание к его позиции, прежде чем дать свой ответ. Узнайте, почему добавление этой фичи в релиз так важно для Джона. В чем его личная заинтересованность? Если Джон почувствует, что его понимают, он выслушает вашу точку зрения, ваши аргументы и примет тот факт, что выполнить его просьбу не представляется возможным. Следующие приемы слушания могут помочь вам в этом: Уделяйте максимум внимание собеседнику. Поддерживайте зрительный контакт и демонстрируйте человеку, что вам интересно то, что он или она хочет сказать.  Сохраняйте непредвзятость, даже если вы не согласны с тем, что слышите, или если вам не нравится этот человек. Слушайте с намерением понять, а не ответить. В конце концов, Джон может быть прав, и вам следует добавить эту фичу в релиз. Обращайте внимание на язык тела человека. Невербальная информация, такая как высота и громкость голоса, жесты, мимика и движение глаз, выражает чувства говорящего, что помогает вам раскрыть главные мотивы человека.  Задавайте уточняющие и наводящие вопросы, чтобы убедиться, что вы правильно поняли сказанное, и мотивировать собеседника дать вам больше информации. Вы можете, например, сказать: «Не могли бы вы помочь мне понять, почему добавление этой фичи по вашему мнению важно?»  Стейкхолдеры часто запрашивают добавление определенных фич, не всегда полностью осознавая проблему, которые они нацелены решить. Пока выпускаемый продукт молод или находится в процессе изменения вряд ли его ценность зависит от добавления одной единственной фичи. Вместо того, чтобы обсуждать с Джоном отдельные фичи, переведите разговор к главной задаче. Узнайте, какую проблему пользователя или клиента может решить эта фича. Какую пользу принесет людям внедрение этой фичи? Почему некоторые клиенты, в рассмотренном нами примере, считают важным добавление фичи детализирующей отчетность? И есть ли альтернативный способ добиться желаемого результата? Кроме того, подумайте, согласована ли фича с целью продукта на текущем этапе разработки, с результатом, которого вы хотите достичь, например, выйти на новый рынок или повысить вовлеченность. Поможет ли решение проблемы пользователя достичь этой цели и создать желаемую выгоду? Если ответ положительный, то вам следует подумать о перераспределении усилий по разработке. Вы можете решить добавить эту фичу в релиз, учитывая, что вы внесете соответствующие изменения, пожертвовав сокращением или удалением других фич или переместив срок релиза. Но если ответ отрицательный, то вам следует отклонить эту просьбу.  Может возникнуть соблазн решить вопрос быстро, просто чтобы сразу с ним покончить. Несмотря на нежелание откладывать решение на потом, все таки лучше не торопиться.  Представим, что разговор с Джоном получился нелегким. Он непреклонен в том, что фича должна быть добавлена и не хочет принимать вашу точку зрения. Более того, он сомневается, что вы понимаете, чего хотят клиенты, и угрожает обострить проблему, если вы отклоните его просьбу. В такой ситуации естественно испытывать сложные эмоции, такие как замешательство, беспокойство и гнев. Когда это происходит, лучше всего сделать паузу и отложить решение, чтобы вернуть себе хладнокровие и позволить тяжелым переживаниям утихнуть. Вы можете сказать Джону: «Для меня очень важно найти хорошее решение. Но сейчас я расстроен, и мне нужно время, чтобы поразмыслить над вашими словами. Давайте продолжим разговор после обеда​​». Кроме того, подумайте, можете ли вы и должны ли вы принимать решение самостоятельно. Если решение имеет большое значение, если вам требуется вовлечь других людей для принятия правильного решения, или если вы хотите заручиться их поддержкой, я рекомендую назначить встречу со всеми ключевыми стейкхолдерами и представителями команды разработчиков для обсуждения, и, оценив запрос фичи, принять коллективное решение. Вы даже можете обнаружить, что вам нужно провести исследования и собрать соответствующие данные, например, опросив пользователей или выпустив фейковую фичу, прежде чем вы сможете принять решение.  Хотя иногда невозможно не сказать “нет”, я рекомендую вам изучить, есть ли альтернативный способ удовлетворить основные потребности стейкхолдеров. Представим, что ваше подозрение подтвердилось: просьба Джона, по крайней мере частично, мотивирована желанием выполнить свой план по продажам и получить премию.  Если это так, узнайте, можете ли вы помочь ему в достижении его цели, не добавляя эту фичу, - при условии, если вы действительно хотите помочь Джону в достижении этой цели. Было бы полезно, например, разработать коммерческое предложение, показывающее, что продукт удовлетворяет некоторые потребности клиентов без внедрения дополнительных фич? Или есть другое решение, которое вы можете найти вместе с Джоном? Однако не совершайте ошибку, идя на компромисс и предлагая Джону частично реализовать эту фичу как часть текущего релиза - если только это действительно не решит основную потребность Джона и не повредит  темпу работы команды разработчиков.  Делайте все необходимое, чтобы повысить ценность вашего продукта, но не пытайтесь угодить отдельным стейкхолдерам. Будьте вежливы и проявляйте твердость. Помните: успешные продукты построены не на сомнительных компромиссах или наименьшем общем знаменателе. Перевод статьи подготовлен в преддверии старта курса «Системный аналитик. Advanced» .  Приглашаем всех желающих принять участие в бесплатном демо-уроке курса по теме: "ТЗ по ГОСТ: кому оно вообще нужно?" Редактор