В последнее время не было личных постов, так что решил выдать ещё один инсайт с работы (последний был немного провокационный про очные встречи VS удаленку)
В мире есть куча разных стратегий ведения переговоров (часто противоречащих друг другу) - например, вот неплохая подборка релевантной литературы. Одна из самых известных книг на эту тему - "Сначала скажите 'Нет'" Джима Кемпа. Как можно понять из названия, автор предлагает сказать "Нет", чтобы пресечь бесплодные дискуссии, отбросить ложные предположения и избежать ненужных компромиссов.
Переговоры на работе у меня возникают часто, но есть нюанс - обычно другая сторона является бизнес-заказчиком, а значит силы не равны. Поэтому в первые месяцы работы в Яндексе❤️ я считал, что нужно сделать точь-в-точь то, что просит заказчик, потому что он лучше знает что ему нужно.
Так вот, великим открытием последних месяцев для меня стало то, что ЭТО НЕ ТАК. Можно и нужно вести переговоры, даже если по орг. структуре твоя команда исполнитель и де юро должна сделать то, что ее попросят. Более того, ты можешь предложишь заказчику решение лучше чем то, которое он изначально хотел получить. В качестве примера приведу пару обобщенных дискуссий - всю конкретику вычистил, так что должно быть применимо для всех:
Заказчик: Сделайте мне 50 <чего-то>
Мы: А почему именно 50?
Заказчик: Ну чтобы точно хватило
Мы: А давайте мы вам как аналитики прикинем сколько точно хватит?
Заказчик: А, не знал что так можно, давайте
В итоге оказывается что достаточно 35 <чего-то>, все довольны
Мы: К какому числу вам нужно <решение>?Результат - все довольны, мы не делаем необъятную задачу к завтрашнему дню, а заказчик получает то, что ему действительно нужно к близкому сроку
Заказчик: К завтрашнему дню
Мы: А что у вас завтра?
Заказчик: <что-то>
Мы: Хм, а для <что-то> на самом деле нужно не всё <решение>, а 20% от него - давайте мы эти 20% быстро сделаем к завтра, а остальные 80% уже потом?
Заказчик: Да, супер, давайте
Итого - сначала скажите "Нет", в книге не врут
А если без пафоса - то можно обсуждать и менять примерно все условия изначального запроса, а именно:
1) Сроки - вдруг к этому времени нужно не полноценное решение, а разовая выгрузка
2) Конкретную реализацию - возможно лучше не разово собрать эксельку, а сразу сделать регулярно обновляемый дашборд. Заказчику обычно не важна конкретная реализация, нужно просто закрыть боль, а как именно уже не так принципиально
А если начать так делать, то есть риск получить респект от заказчика - ведь в его глазах вы из просто исполнителя вырастете до полноценного партнёра по решению проблемы, который и предложит как сделать лучше, и объяснит что к завтра много не надо
Скинь знакомому айтишнику (и не только айтишнику), который
#карьера