Есть одноименная книга под авторством Джима Кемпа — «Сначала скажите нет». Если скажу, что пост ей не вдохновлен — нагло совру. Однако пересказом я заниматься не буду, затрону разве что основные идеи. И то, своими словами, как понял и запомнил я. Если тема заинтересует, советую купить и почитать.
Сам же я читал достаточно давно и мне запомнилось, что эта книга про переговоры на с целью выстраивания долгосрочных отношений. Однако основные идеи применимы даже на бытовом уровне. И тем более от них будет польза и в нашей рабочей жизни, жизни разработчиков, которые так или иначе участвуют во внутрикорпоративной или внутрипроектной коммуникации.
Более всего эти принципы полезны в жизни лидов. На этой позиции коммуникация — встречи, конференции, планерки — занимает существенную часть рабочего дня. И от того, как будет вести себя на них тимлидер, может зависеть в том числе успех его команды и его проекта.
Зачем говорить «нет»
«Учение» господина Кемпа довольно однозначно выступает против заключения соглашений по принципу win-win. При таком подходе, вместо того чтобы как следует выслушать друг друга, стороны часто спешат заключить сделку на первой комбинации условий, которое хотя бы минимально устраивают обе стороны. В итоге вместо win-win может получиться min-min. Ну, или что реалистичнее, одна из сторон серьезно проигрывает по условиям.
Конечно, это про продажи и контракты. Однако в профессиональной жизни разработчика, «продажи» в том или ином виде случаются с завидной регулярностью. Особенно у лидов.
Представим ситуацию. Встреча по планированию бэклога на квартал. На ней собрались все кто участвует в разработке, включая продакта Петю и дизайнера Диму. Слово берёт последний и начинается диалог
Дизайнер Дима: Мы разработали и согласовали новый дизайн карточки товара и хотим внедрить его в этом спринте. Кажется, такого не было ни у кого. Смотрите, при наведении мыши на продукт у нас запускается 3D-анимация и разворачивается подробная информация, с чатом, в котором клиента уже ждёт консультант, который помогает с выбором. Сделаем?
Тимлид: Тут работы много: чат, анимации, редизайн. За спринт не успеть. Я бы заложил 2 спринта.
Продакт Петя: Я бы взял еще чуть времени чтобы покрыть риски. Давайте возьмем полтора месяца.
Кажется все довольны, все получили свое. Задумку дизайнера реализуют, ПО получит уникальную фичу которой можно будет похвастаться в резюме, а тимлид выбил целых 3 спринта на разработку. Что может пойти не так? Абсолютно всё. Например:
- Окажется что технологической базы под чат с консультантом у проекта нет
- Выяснится что никто из команды не делал такие богатые анимации какие хочет дизайнер
- Итоговый дизайн окажется неудобен для
- Ресурса команды продаж не хватит, чтобы выделить сотрудников для онлайн-консультирования и чат придется «выпиливать со страницы»
Как итог, команда будет карпеть над «инновацией» в течение неопределенного количества времени, чтобы сделать поделку, которую потом выкинут и не будут внедрять. И на этом этапе она, как и пепел, узнает что такое «гореть». Хорошо, если после этого она не разбежится.
Как говорить «нет»
Мы должны говорить «нет», чтобы развить переговоры, чтобы заблокировать плохие решения или адаптировать их, сделав более-менее оптимальными. Мы говорим не то «нет», которое блокирует инициативу. Мы говорим то «нет», которое позволит узнать больше деталей. И о том, как его сказать и развить диалог сейчас и поговорим.
- Выясните зачем это нужно бизнесу. Бизнесу важнее не конкретное решение, а рост каких-либо показателей. Код ради кода не нужен абсолютно никому. Однако предлагаемое решение, даже если оно преследует светлую высокую цель, может оказаться плохим, если учесть детали его реализации.
- Преподносите свой отказ как запятую, а не как точку. За отказом должен следовать уточняющий вопрос. Потом еще и ещё. Ваша задача — выучить как можно больше информации, прежде чем вы скажете свое финальное и веское слово.
- Задавайте открытые вопросы. «Что», «где», «когда», «как», «почему» и другие вопросительные слова — ваши друзья. Вопросы которые предполагают бинарный ответ содержат в себе половину ответа, что лишает собеседника свободы предоставить вам еще больше информации.
- Адресуйте вопросы конкретным людям. Брошенный в толпу вопрос рискует остаться без ответа (впрочем, отсутствие ответа тоже может быть вашей целью). Но если вы хотите получить информацию, обращайтесь адресно.
- Вовлекайте коллег, чтобы получить больше веса. Иногда «отказ» одного человека может выглядеть как каприз или желание навредничать общему делу. Если же позицию подтверждают и другие члены команды, такие подозрения будут выглядеть безосновательными.
Применяя все это к диалогу, который состоялся в прошлом разделе, мы получим примерно следующий акт коммуникации.
Дизайнер Дима: рассказывает про фичу то же самое. Сделаем?
Тимлид: Хм. Это долго и дорого. Боюсь, не сможем взять. Петя, а чего именно вы хотите добиться этой доработкой?
Продакт Петя: У нас очень много корзин брошеных. А вот с кол-центра конверсия отличная. Поэтому хотим быстрее подключаться к консультированию.
Тимлид: А анимация тогда зачем?
Продакт Петя: Ну, чтобы запомниться как-то
Тимлид: Коллеги, фронты. У нас кто-то на Three.js писал? Кажется тут обычными трансформами не обойтись… в ответ тишина и «лес рук» Давайте тогда без анимаций. Дим, можем упростить?
Дизайнер Дима: Да, в общем-то можно и простой переход. Ну, для начала по крайней мере…
Тимлид: Плюс насколько я знаю у нас бэк сокеты так и не затащил, без этого чат мы сделать не сможем. Петь, мы можем какое-нибудь вендорское решение прикрутить?
Продакт Петя: Думаю можем, проверю бюджет. А сами точно не сможем?
Тимлид: Сможем, но это может еще серьезнее бюджет поесть. Вы сразу на всех хотите запускать? Или нам еще на АБ-тестирование заложиться?
Продакт Петя: Ох, наверное лучше на треть трафика, а то продажи могут не вывезти. АБ сильно добавит сложности?
Тимлид: У нас механизм есть, отлажен. Так что почти не добавит, пара часов работы. Итого, если мы не делаем анимацию, подключаем вендорский чат и запускаемся с АБ, то нам достаточно одного полноценного спринта.
Конечно, пример выдуманный. Конечно, в реальности диалог может пойти не так гладко и тимлиду придется «пободаться» за правду. Но если подвести итог, кто что получил после такого раунда переговоров? Задумку дизайнера реализуют, но не всю сразу. Если гипотеза про чат в карточке товаров сработает, то ПО получит рост показателей продукта и фичу чтобы хвастаться в бане. а тимлид выбил целых 3 спринта на разработку. Даже если потом эту «поделку» выкинут, будет не так обидно. Ну и бюджет целее.
Словом, классные переговорные навыки лида могут серьезно улучшить проект и жизнь каждого сотрудника в команде.
Почему мы можем говорить «нет»
Не хочется надувать щёки, но разработчик обычно понимает внутреннее устройство продукта гораздо лучше чем продакт. Чем дольше разработчик на проекте, тем тоньше он понимает его устройство, его готовность к модификации, видит подводные камни, помнит набитые с молчаливого согласия с менеджментом коллег шишки. И конечно он должен остановить плохую инициативу. Это облегчит жизнь и его коллегам, и ему самому. А это, если разработчик награжден должностью лида, его прямая обязанность.
Новые на проекте разработчики тоже имеют право на «нет». Если это опытный сотрудник, он мог проходить что-то похожее на прошлых проектах. Если это новичок в профессии, он может выступить в роли второй головы в пословице про то, что одна голова — это не лучшее решение.
В конце концов, повторим и запомним, что наше «нет» это не отказ. По крайней мере не отказ сразу. Наше «нет» — это попытка узнать о проблеме и мотивации менеджмента больше, придумать оптимальное решение. Все это необходимо чтобы
