Как продать

4/06/2010

Ag;)e

Асхат Уразбаев, Agile CoachScrumTrek

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

• ScrumTrek– Agile Coach– Управляющий партнер

• В прошлом– Программист, менеджер

проектов, методолог

AgileRussia.ru

«Продажа» Agile

AgileRussia.ru

Разговор (1)

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

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

AgileRussia.ru

Разговор (2)

• Какая проблема самая важная для вас?• У нас много багов в коде• Нам нужно парное программирование!• У нас нет времени

AgileRussia.ru

Разговор (3)

• А почему это проблема?• Ну мы не можем разработать достаточно быстро.

Срываются сроки релиза. Заказчики жалуются. • А парное программирование может помочь?• Не уверен• Может попробуем поработать так одну итерацию?• Хорошая идея!

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

• Выявление проблемы (потребности)• Выявление последствий проблемы • Предложить решение, обсудить его выгоды• Рассмотреть опасения• Установить безопасное окружение для пилотирования• Общий Commit

© ScrumTrek.ru, 2008

Потребности

• Скрытая потребность– Неосознаваемая заказчиком

• Явная потребность– Осознаваемая заказчиком

© ScrumTrek.ru, 2008

Материалы

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

© ScrumTrek.ru, 2008

СПИН

• Ситуационные вопросы– Проясняющие текущую ситуацию

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

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

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

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

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

• Agile работает– Нужно максимально быстрое и эффективное

достижение бизне-цели

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

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

• Scrum –метод управления изменениями. • Так его и продавать :-)

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

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

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

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

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

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

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

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

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

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

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

относительно согласованных правил• Переводить разговор в конструктивное

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

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

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

Партнерство

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

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

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

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

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

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

заказчиком до начала планирования итерации

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

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

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

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

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

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

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

• Настаивать на соблюдении ритма• Тщательно готовится к встрече• Ловить за пуговицу в коридоре • Опять - хорошие отношения!• Звонить и вытягивать на общение

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

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

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

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

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

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

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

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

• Целенаправленно повышайте его уровень доверия• Обеспечьте высокий уровень прозрачности

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

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

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

Правила Партнерство

Потребности

Психология

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

• askhat@scrumtrek.ru • Twitter: zibsun• Skype: askhatu• ЖЖ: zibsun.livejournal.com