Как

продавать

Agile?

Асхат Уразбаев

ScrumTrek

• Agile Coach

• Управляющий партнер

В прошлом

• Программист, менеджер проектов, методолог

«Продажа» Agile

Разговор (1)

• Нам нужно парное программирование (и это круто)

• Нет, не нужно (а ты гик)

Разговор (2)

• Какая проблема самая важная для вас?

• У нас много багов в коде

• Нам нужно парное программирование!

• У нас нет времени

Разговор (3)

• А почему это проблема?

• Ну мы не можем разработать достаточно быстро. Срываются сроки релиза. Заказчики жалуются.

• А парное программирование может помочь?

• Не уверен

• Может попробуем поработать так одну итерацию?

• Хорошая идея!

Общий подход к «продаже»

• Выявление проблемы (потребности)

• Выявление последствий проблемы

• Предложить решение, обсудить его выгоды

• Рассмотреть опасения

• Установить безопасное окружение для пилотирования

• Общий Commit

Потребности

• Скрытая потребность

• Неосознаваемая заказчиком

• Явная потребность

• Осознаваемая заказчиком

Материалы

Нил Рекхем "СПИН-продажи"

СПИН

• Ситуационные вопросы

• Проясняющие текущую ситуацию

• Проблемные вопросы

• Нащупывающие реальные проблемы

• Извлекающие вопросы

• Выясняющие важность проблем

• Направляющие вопросы

• Направляющие на варианты решения проблем

Применимость Agile

• Agile противопоказан

• Заказчик не заинтересован в результате

• Agile работает

• Нужно максимально быстрое и эффективное достижение бизне-цели

Заказчик хочет знать сроки окончания проекта

Старинные методы оценки

• Scrum –метод управления изменениями.

• Так его и продавать :-)

Мой заказчик утверждает, что его требования не поменяются

«Мы обычно согласовываем процедуру изменений»

(Не беспокойтесь, меняют требования все и всегда!)

А давайте мы вам будем показывать раз в 2 недели результат?

Общие правила

• Backlog ака список функциональности

• Заказчик может поменять любую несделанную фичу на эквивалентную по размерам

• Фичи оценивает вендор

• Заказчик может добавить или удалить фичу.

• Заказчик может поменять порядок несделанных фич

• В любой момент заказчик может принять решение остановить разработку

• Заказчик формально принимает сделанные фичи

• Что если заказчик будет напихивать новые фичи, и упираться при разговоре о изменении срока?

• Все разговоры вести вокруг баклога

• Демонстрировать незыблемость позиции относительно согласованных правил

• Переводить разговор в конструктивное русло (например - что можно выкинуть из плана или что можно урезать)

• Уметь говорить НЕТ

Что если заказчик будет раздувать scope фич: «Такое поведение тут подразумевалось! Вы должны это сделать»

Партнерство

• Подчеркивать с самого начала, что заказчик и вендор являются партнерами

• Постоянно объяснять, что увеличение scope затягивает сроки

• С самого начала вникать в бизнес-потребности заказчика и просить его аргументировать изменения

• В крайнем случае, отыграетесь, когда заказчик попросит новые фичи :-)

Что если заказчик будет менять фичи, которые находятся в работе в текущей итерации?

• Создавать приемочные тесты

• Приемочные тесты согласовывать с заказчиком до начала планирования итерации

Что если мой заказчик при наличии проблем будет сваливать вину на нас?

• Инвестировать как можно больше в хорошие отношения с заказчиком

• Регулярно проводить демонстрации и знакомить его с командой

• Приглашать на стендапы, ретроспективы и так далее

• Обеспечить высокую прозрачность разработки

Мой заказчик очень занятый человек и он не может уделить мне достаточно времени

• Создавать ритм общения. Например, пусть заказчик встречается с вами каждый второй четверг

• Настаивать на соблюдении ритма

• Тщательно готовится к встрече

• Ловить за пуговицу в коридоре

• Опять - хорошие отношения!

• Звонить и вытягивать на общение

И все-таки мой заказчик неадекватен. Что делать?

• Заранее согласовывать в контракте процедуру выхода. Она должна быть по возможности простой для каждой из сторон

• Если общение заходит в тупик, дать понять, что вы готовы прекратить работу

• Как правило, это действует отрезвляюще

• Если нет, то все равно это не ваш клиент

Мой заказчик – технический человек. Он постоянно вмешивается в работу команды

• Формулируйте с заказчиком правила его участия в работе команды (лучше заранее)

• Вовлекайте в работу на ключевых этапах (формирование архитектуры, дизайн компонентов)

• Целенаправленно повышайте его уровень доверия

• Обеспечьте высокий уровень прозрачности разработки

• Ни в коем случае не устраивайте войну! Вы проиграете!

• Хвалите его :-)

4П: продажа Agile заказчику

Правила

Партнерство

Потребности

Психология

Асхат Уразбаев

askhat@scrumtrek.ru

Twitter: zibsun

Skype: askhatu

ЖЖ: zibsun.livejournal.com