«Продажа» технических идей заказчику

Мы все помним, как в 2007 году первый iPhone произвел настоящую революцию в мире мобильных телефонов — был представлен очень удобный, красивый, полноэкранный смартфон. Журналы пестрели заголовками, какой прорыв совершил Apple — казалось бы, нет и не было ничего похожего на iPhone. При этом едва ли кто помнит сейчас такой телефон, как IBM Simon. На самом деле он был очень похож на iPhone — всю его переднюю панель занимал сенсорный экран. Так же, как у iPhone, у него была лишь одна механическая кнопка. Так же, как и в iPhone, в нем были разные приложения. Но, в отличие от iPhone, IBM Simon появился ещё в 1994 году, аж за 13 лет до iPhone! Так почему же мы хорошо помним появление первого iPhone и совсем забыли об IBM Simon, в котором были реализованы те же идеи, но намного раньше? Идея, на самом деле, была отличной. Но подана она была несвоевременно и не совсем в правильной «упаковке»: дизайн был так себе, цена была слишком высокой, целевая аудитория была не та и т. д.

Так как же «упаковывать» и «продавать» идеи так, чтобы они стали «айфонами», а не «саймонами»?

Пожалуй, многие из нас слышали или произносили фразы:

1. «То, что мы используем, устарело пять лет назад!»
2. «Это совершенно невозможно поддерживать!»
3. «Заказчика интересует только новый функционал!»
4. «Он нас не слышит!»
5. «Я хочу в другой проект/компанию!»

Знакомо? У нас есть классные идеи, мы знаем, как улучшить проект, но заказчик нас почему-то не слышит. Давайте для начала разберемся, как мы «продаем» идеи, как мы их преподносим заказчику. Обычно мы презентуем свои идеи заказчику примерно так:

1. «Необходимо внедрить автоматизированное тестирование!»
2. «Срочно нужно проапгрейдиться до Java 1.8!»
3. «В соответствии с методологией eXtream programming нельзя обойтись без парного программирования!»
4. «Требуется остановить разработку нового функционала на 3 месяца для рефакторинга ядра!»

Давайте теперь проведем мысленный эксперимент: представим на секунду себя на месте заказчика и подумаем, как отвечает заказчик на вопрос, кому это надо. Программистам, инженерам — вот кому. А кто за это платит? Заказчик. Вот корень проблемы! Вот почему не удается внедрить новые классные технологии! Потому что заказчик, — тот, кто платит, тот, кто принимает решения, — не понимает, зачем ему это нужно.

1) Проверяем идею:
Поэтому, в первую очередь, мы проверяем идею: нам нужно подумать, приносит ли пользу заказчику технология, которую мы хотим внедрить в проект. Тут, конечно же, два варианта: приносит или не приносит. К счастью, новые идеи и технологии являются новыми потому, что они делаются, чтобы что-то улучшить, ускорить, где-то снизить затраты, что-то повысить и т. д. Поэтому, скорее всего, если вы об этой идее думаете, пользу заказчику она, скорее всего, принесет. А если вы, проведя мысленный эксперимент, пришли к выводу, что идея пользу ни вам, ни заказчику не принесет, к вам придет успокоение, потому что воду в решете носить никому неохота, — делать то, что не нужно, никому не хочется. Поэтому в любом случае будет счастье: либо идея нужна, либо есть спокойствие и можно искать другие идеи, которые точно нужны.

2) «Упаковываем» идею:
Далее, если мы решили, что идея заказчику нужна, нам нужно «упаковать идею»: подумать, как ее преподнести. Если мы будем говорить, что нам нужно «зарефакторить ядро, потому что у нас есть технический долг», у нас ничего не получится. Нужно идею «упаковать» так, чтобы заказчик нас понял! Заказчик, как правило, мыслит категориями «стоимость», «деньги», «сроки» и т. д. Поэтому, чтобы заказчику стало понятно, нужно преимущества идей, которые мы видим, выразить на языке заказчика. Например, можно сказать, что внедрение той или иной идеи уменьшит затраты — например, на тестирование. Что еще может привлечь заказчика? Скорость запуска, скорость выхода на рынок, увеличение прибыли, расширение пользовательской аудитории (и в итоге увеличение прибыли) и т. д. Привлекательных для заказчиков моментов может быть масса! Но в основном встречаются четыре: увеличение прибыли, уменьшение затрат, ускорение выхода на рынок, повышение качества.

Итак, мы перевели идею на язык заказчика. Продолжаем «упаковку». Что дальше? Если мы придём с этим к заказчику, то успеха, скорее всего, не добьёмся, так как у заказчика возникают следующие вопросы:

• «Сколько это стоит, каков ROI?»
• «Какие здесь риски?»
• «Какие есть альтернативы?»
• «В чём польза?»

Заказчик спросит об этом потому, что именно он вкладывает деньги и должен быть уверен, что каждая копейка будет разумно использована, что вы обо всем подумали и все учли. Поэтому, когда идете со своей идеей к заказчику или менеджеру проекта, нужно иметь в голове ответы на эти вопросы.

3) Выбираем время:
Допустим, идею мы «упаковали», пришли к заказчику, всё объяснили, но идея не проходит. Почему? Может быть, неправильно выбрано время. Правильное время сильно зависит от цикла проекта, и вам тут виднее. А неправильное время — это, обычно, прямо перед релизом или сразу после релиза. Перед релизом мы исправляем баги, заказчику не до этого. После релиза заказчик общается с журналистами, занимается продвижением и т. д., и ему снова не до этого. Хорошее время — ретроспектива; это как раз время, чтобы собрать новые идеи и подумать, можно ли их внедрить.

4) Ищем нужного человека:
Итак, представим, что идею мы «упаковали», выбрали время, пришли к заказчику, а решение не принимается. Почему? Возможно, мы просто пришли не к тому человеку. Нам важно найти именно того человека, у которого есть полномочия принять решение по нашему вопросу. Как вы понимаете, тут может быть два случая: человек, принимающий решения и человек, не имеющий таких полномочий. Обычно всё просто, но иногда человек, не принимающий решения, просто стесняется сказать, что он их на самом деле не принимает, и в итоге водит вас за нос: вы к нему приходите, а он вас куда-то отправляет, и т. д. Выяснить, нужный ли это человек, довольно просто: если после двух-трех попыток человек не говорит ни да, ни нет, а только задает вопросы, скорее всего, он маскируется и на самом деле ничего не решает, и нам нужно поискать кого-то другого.

Иногда бывает так, что человек, принимающий решения, недоступен. Это сложная ситуация, но не безнадежная. В этом случае можно попробовать найти человека, доступного вам и, в то же время, имеющего доступ к лицу, принимающему решения. Мы можем попробовать разобраться в его приоритетах и переупакавать идею так, чтобы она решала задачи не только лица, принимающего решения, но и его. Таким образом, мы делаем как бы «двойную упаковку» идеи.

5) Определяем проблему:

Что дальше? Многие, наверное, знают следующее правило в инженерии: если что-то работает, это лучше не трогать. Поэтому, если даже у вас есть какая-то гениальная идея (например, как сократить скорость тестирования в два раза), но, в принципе, все и так нормально, ребята справляются, продукт хорошего качества и вовремя выходит то, скорее всего, вашу идею оставят без особого внимания. Поэтому нужно создать у заказчика ощущение проблемы — внимание, не саму проблему, а именно ее ощущение! Другими словами, мы открываем глаза заказчику, что у него есть проблема. Как это сделать? Можно, например, поделиться своей болью. Можно прийти к заказчику и пожаловаться, что мы, например, тратим на ручное тестирование очень много времени, а ведь мы могли бы потратить всё это время на разработку новых компонентов и т. д. Или мы рассказываем заказчику об упущенной выгоде: если бы у нас было автоматизированное тестирование, мы бы могли выпускать версии намного быстрее, быстрее реагировать на изменение рынка и новые требования пользователей.

После того как мы рассказали заказчику о проблеме, нам не стоит сразу же предлагать ее решение. Сначала мы ждем, когда заказчик осознает проблему, когда она вызреет. Сколько времени ждать? Самый лучший вариант — если заказчик потом сам к нам приходит и говорит, что действительно есть такая проблема. Всё! Это значит, идея продана. Остаётся идею чуть-чуть «доупаковать», и всё готово. Если этого не происходит, мы сами можем через неделю-другую пойти к заказчику и узнать у него, что он думает о ситуации. Если он начинает кивать, значит, вы на правильном пути.

6) Проводим демонстрацию:
Лучше один раз увидеть, чем сто раз услышать. Хорошо, если мы можем внедрить эту технологию в каком-нибудь маленьком проекте, чтобы показать ее заказчику: «Вот, смотри, как это классно!» Или провести какую-либо демонстрацию. Или показать на примере другой команды, как она хорошо работает. Все, что можно не просто услышать, а увидеть в деле, ощутить — играет на пользу. Поэтому, если есть возможность, мы устраиваем демонстрацию.

7) Тренируемся:

Затем мы обязательно тренируемся. Ведь если даже мы тщательно продумали все эти шаги в голове и идем сразу же к заказчику, скорее всего, попадем впросак. Ведь все мыслят по-разному! И заказчик вам, скорее всего, будет задавать такие вопросы, о которых вы даже не подозревали. Поэтому лучше всего собрать коллег и попросить их покритиковать вашу идею. Или поиграть «в заказчика»: выбираете какого-нибудь коллегу на роль заказчика и пытаетесь его уговорить выбрать вашу идею. Вы удивитесь, как много интересных замечаний они вам дадут. После этого вы можете переработать подачу вашей идеи и с большей вероятностью сможете эту идею внедрить.

8) Проявляем настойчивость:
Если честно, редко идея внедряется с первого раза. Обычно требуется две, три, четыре попытки, порой идея не внедряется никогда. Поэтому проявляйте настойчивость — с первого раза вряд ли что-то получится.

Давайте подведем итоги
Итак, чтобы грамотно продать идею заказчику, мы делаем следующее:

1. Проверяем идею — действительно ли она нужна заказчику?
2. «Упаковываем» идею: выражаем её преимущества на язык заказчика.
3. Выбираем время.
4. Ищем человека, принимающего решения.
5. Создаём ощущение проблемы.
6. Проводим демонстрацию решения проблемы.
7. Перед этим тренируемся.
8. Не получилось? Проявляем настойчивость, все повторяем с самого начала и рано или поздно заказчик вас услышит.

Автор: Николай Малышев, Delivery Manager DataArt.

Автор: DataArt

Источник