Как продать Agile заказчику
-
Upload
askhat-urazbaev -
Category
Technology
-
view
3.260 -
download
0
description
Transcript of Как продать Agile заказчику
Как
продавать
Agile?
Асхат Уразбаев
ScrumTrek
• Agile Coach
• Управляющий партнер
В прошлом
• Программист, менеджер проектов, методолог
«Продажа» Agile
Разговор (1)
• Нам нужно парное программирование (и это круто)
• Нет, не нужно (а ты гик)
Разговор (2)
• Какая проблема самая важная для вас?
• У нас много багов в коде
• Нам нужно парное программирование!
• У нас нет времени
Разговор (3)
• А почему это проблема?
• Ну мы не можем разработать достаточно быстро. Срываются сроки релиза. Заказчики жалуются.
• А парное программирование может помочь?
• Не уверен
• Может попробуем поработать так одну итерацию?
• Хорошая идея!
Общий подход к «продаже»
• Выявление проблемы (потребности)
• Выявление последствий проблемы
• Предложить решение, обсудить его выгоды
• Рассмотреть опасения
• Установить безопасное окружение для пилотирования
• Общий Commit
Потребности
• Скрытая потребность
• Неосознаваемая заказчиком
• Явная потребность
• Осознаваемая заказчиком
Материалы
Нил Рекхем "СПИН-продажи"
СПИН
• Ситуационные вопросы
• Проясняющие текущую ситуацию
• Проблемные вопросы
• Нащупывающие реальные проблемы
• Извлекающие вопросы
• Выясняющие важность проблем
• Направляющие вопросы
• Направляющие на варианты решения проблем
Применимость Agile
• Agile противопоказан
• Заказчик не заинтересован в результате
• Agile работает
• Нужно максимально быстрое и эффективное достижение бизне-цели
Заказчик хочет знать сроки окончания проекта
Старинные методы оценки
• Scrum –метод управления изменениями.
• Так его и продавать :-)
Мой заказчик утверждает, что его требования не поменяются
«Мы обычно согласовываем процедуру изменений»
(Не беспокойтесь, меняют требования все и всегда!)
А давайте мы вам будем показывать раз в 2 недели результат?
Общие правила
• Backlog ака список функциональности
• Заказчик может поменять любую несделанную фичу на эквивалентную по размерам
• Фичи оценивает вендор
• Заказчик может добавить или удалить фичу.
• Заказчик может поменять порядок несделанных фич
• В любой момент заказчик может принять решение остановить разработку
• Заказчик формально принимает сделанные фичи
• Что если заказчик будет напихивать новые фичи, и упираться при разговоре о изменении срока?
• Все разговоры вести вокруг баклога
• Демонстрировать незыблемость позиции относительно согласованных правил
• Переводить разговор в конструктивное русло (например - что можно выкинуть из плана или что можно урезать)
• Уметь говорить НЕТ
Что если заказчик будет раздувать scope фич: «Такое поведение тут подразумевалось! Вы должны это сделать»
Партнерство
• Подчеркивать с самого начала, что заказчик и вендор являются партнерами
• Постоянно объяснять, что увеличение scope затягивает сроки
• С самого начала вникать в бизнес-потребности заказчика и просить его аргументировать изменения
• В крайнем случае, отыграетесь, когда заказчик попросит новые фичи :-)
Что если заказчик будет менять фичи, которые находятся в работе в текущей итерации?
• Создавать приемочные тесты
• Приемочные тесты согласовывать с заказчиком до начала планирования итерации
Что если мой заказчик при наличии проблем будет сваливать вину на нас?
• Инвестировать как можно больше в хорошие отношения с заказчиком
• Регулярно проводить демонстрации и знакомить его с командой
• Приглашать на стендапы, ретроспективы и так далее
• Обеспечить высокую прозрачность разработки
Мой заказчик очень занятый человек и он не может уделить мне достаточно времени
• Создавать ритм общения. Например, пусть заказчик встречается с вами каждый второй четверг
• Настаивать на соблюдении ритма
• Тщательно готовится к встрече
• Ловить за пуговицу в коридоре
• Опять - хорошие отношения!
• Звонить и вытягивать на общение
И все-таки мой заказчик неадекватен. Что делать?
• Заранее согласовывать в контракте процедуру выхода. Она должна быть по возможности простой для каждой из сторон
• Если общение заходит в тупик, дать понять, что вы готовы прекратить работу
• Как правило, это действует отрезвляюще
• Если нет, то все равно это не ваш клиент
Мой заказчик – технический человек. Он постоянно вмешивается в работу команды
• Формулируйте с заказчиком правила его участия в работе команды (лучше заранее)
• Вовлекайте в работу на ключевых этапах (формирование архитектуры, дизайн компонентов)
• Целенаправленно повышайте его уровень доверия
• Обеспечьте высокий уровень прозрачности разработки
• Ни в коем случае не устраивайте войну! Вы проиграете!
• Хвалите его :-)
4П: продажа Agile заказчику
Правила
Партнерство
Потребности
Психология
Асхат Уразбаев
Twitter: zibsun
Skype: askhatu
ЖЖ: zibsun.livejournal.com