Как "продать" Agile менеджеру?

Очень часто задают такой вопрос - ну мы вроде тут все за Agile. А как продать Agile менеджеру или заказчику?

Я стал придумывать, как рассказать об этом, и у меня появилось такое ощущение, что никакой особой специфики нет. Все продается примерно одинаково. Давайте рассмотрим пример.

Представим себе программиста Александра, который считает, что парное программирование это мегакруто. Саша пришел в совершенно новую компанию, там у него эдакий "типичный" менеджер проекта. Саша считает, что парное программирование будет полезно и хочет "продать" ему эту практику.

Александр понимает, что если он сразу бабахнет про парное программирование, будет отправлен слишком серьезно и далеко. Он понимает, что надо исходить из проблем бизнеса, говорить языком денег и прибыли, только так можно убедить человека в преимуществе парного программирования.

Александр: Какие проблемы?
Менеджер: Багов много. Заказчики просто задрали, жалуются и жалуются. Что-то сделали тут, там отвалилось. Поправили там – тут отвалилось.
Александр: Парное программирование как раз решает эту проблему!
Менеджер: Да ты что, с ума сошел? Какое парное программирование? Это же когда двое за одним компьютером? Это слишком дорого!
Александр: Дело в том, что пока мы исправляем баги, уходит времени больше, чем если бы мы написали сразу все правильно. А писать сразу все правильно реально.
Менеджер: Так что ты предлагаешь?
Александр: Я предлагаю не тратить время на исправление багов, а сразу сделать все правильно. Это даст нам экономию времени, плюс довольные пользователи от того, что у нас работает система.
Менеджер: Да ты просто гик. Начитался книжек умных. У нас тут своя специфика, у нас это не заработает!

Итак, Александр провалился. Менеджер оказался ему не по зубам.

Чего не хватает? Менеджер еще не понимает всю проблему целиком, со всеми ее последствиями. Он видит лишь симптом "баги в production". Разговор мог бы пойти так:

Александр: Ну, подумаешь, баги в продакшне, ну и что? Баги всегда есть.
Менеджер: Так заказчики ведь недовольны!
Александр: Ну и что? Мы же не теряем на этом деньги.
Менеджер: Теряем! Полмиллиона долларов. Помнишь, у нас был заказчик-банк? В итоге они купили продукт у другой компании!
Александр: Хм. Вообще-то мы можем это пофиксить. Парное программирование…

Александр превратил маленькую проблему "много багов" в большую "мы теряем деньги". Ну что ж, для некоторого количества менеджеров такой подход сработает. Но наш менеджер так просто не сдастся.

Менеджер: Парное программирование - слишком дорогое удовольствие. Багов может и станет меньше, но производительность упадет вдвое! А что прикажешь делать со следующим релизом? В топку?

Тут Александр может вступить в бой, доказывая, чтоо производительность особенно не снизится. Вряд-ли впрочем, преуспеет. Можно было поступить иначе. Откатим разговор на несколько реплик назад.

Менеджер: Да уж теряли! Полмиллиона долларов. Помнишь, у нас был заказчик-банк? В итоге они купили продукт у другой компании!
Александр: И что ты предлагаешь?
Менеджер: Вообще говоря, это твоя проблема. Ты разработчик, ты и должен заниматься багами.
Александр: Тут подумать надо. Нам надо писать код так, чтобы в нем не было ошибок. Давай подумаем, какие есть подходы, чтобы не делать ошибок? Что-то я такое читал.
Менеджер: Ну там парное программирование, ревью кода.
Александр: Парное программирование? Не знаю… Это может дать снижение производительности. Хотя твоя идея мне нравится.
Менеджер: Дорогое может быть удовольствие! А вдруг мы в два раза медленнее работать будем?
Александр: Да, ты прав. Твою идею сначала надо попробовать безопасно. Я категорически против внедрять парное программирование сразу.

И тут Александр задвигает Менеджеру план по опробованию парного программирования.

Александр: Мы попробуем твою идею в течение одной итерации и я расскажу тебе что у нас получится.
Менеджер: А производительность не пострадает?
Александр: А вот мы и проверим. Через 2 недели я тебе расскажу.

По правде говоря, Александр немного сжульничал. Он изначально намеревался внедрить парное программирование. Но теперь это выглядит как идея менеджера, а Александр просто спешит попробовать ее на практике. Этот прием очень хорошо срабатывает, если вас, конечно, не сильно беспокоят всякие глупости из серии "но это же была моя идея".

Итак, потребности бывают скрытые и явные. Скрытая потребность это когда заказчик не знает, что ему нужно парное программирование, просто испытывает проблемы. А явная это точное знание того, что нужно. Для того, чтобы перевести потребность из скрытой в явную нужно задавать вопросы.

Цикл тут такой:
- Мы выявляем проблему и потребности,
- затем рассматриваем ее последствия,
- предлагаем решение, обсуждаем его выгоду.
- Рассматриваем опасения и устанавливаем безопасное окружение для экспериментов.
- Затем мы соглашаемся вместе на эксперимент, когда все согласны это попробовать.

Метод продажи, который я описал в более общем виде и в применении к продажам товаров и услуг описал Нил Рекхэм в книге «СПИН-продажи»

Написано по мотивам выступления на конференции AgileDays в Екатеринбурге