Как продавать Agile?<br />
АсхатУразбаев<br />ScrumTrek<br /><ul><li>Agile Coach
Управляющий партнер</li></ul>В прошлом<br /><ul><li>Программист, менеджер проектов, методолог</li></li></ul><li>«Продажа» ...
Разговор (1)<br /><ul><li>Нам нужно парное программирование (и это круто)
Нет, не нужно (а ты гик)</li></li></ul><li>Разговор (2)<br /><ul><li>Какая проблема самая важная для вас?
У нас много багов в коде
Нам нужно парное программирование!
У нас нет времени</li></li></ul><li>Разговор (3)<br /><ul><li>А почему это проблема?
Ну мы не можем разработать достаточно быстро. Срываются сроки релиза. Заказчики жалуются.
А парное программирование может помочь?
Не уверен
Может попробуем поработать так одну итерацию?
Хорошая идея!</li></li></ul><li>Общий подход к «продаже»<br /><ul><li>Выявление проблемы (потребности)
Выявление последствий проблемы
Предложить решение, обсудить его выгоды
Рассмотреть опасения
Установить безопасное окружение для пилотирования
Общий Commit </li></li></ul><li>Потребности<br /><ul><li>Скрытая потребность
Неосознаваемая заказчиком
Явная потребность
Осознаваемая заказчиком</li></li></ul><li>Материалы<br />Нил Рекхем "СПИН-продажи" <br />
СПИН<br /><ul><li>Ситуационные вопросы
Проясняющие текущую ситуацию
Проблемные вопросы
Нащупывающие реальные проблемы
Извлекающие вопросы
Выясняющие важность проблем
Направляющие вопросы
Направляющие на варианты решения проблем</li></li></ul><li>Применимость Agile<br /><ul><li>Agile противопоказан
Заказчик не заинтересован в результате
Agile работает
Нужно максимально быстрое и эффективное достижение бизне-цели</li></li></ul><li>Заказчик хочет знать сроки окончания проек...
Старинные методы оценки<br />
<ul><li>Scrum –метод управления изменениями.
Upcoming SlideShare
Loading in …5
×

Как продавать Agile заказчику?

1,772 views

Published on

Как продавать Agile заказчику?

  • Be the first to comment

  • Be the first to like this

Как продавать Agile заказчику?

  1. 1. Как продавать Agile?<br />
  2. 2. АсхатУразбаев<br />ScrumTrek<br /><ul><li>Agile Coach
  3. 3. Управляющий партнер</li></ul>В прошлом<br /><ul><li>Программист, менеджер проектов, методолог</li></li></ul><li>«Продажа» Agile<br />
  4. 4. Разговор (1)<br /><ul><li>Нам нужно парное программирование (и это круто)
  5. 5. Нет, не нужно (а ты гик)</li></li></ul><li>Разговор (2)<br /><ul><li>Какая проблема самая важная для вас?
  6. 6. У нас много багов в коде
  7. 7. Нам нужно парное программирование!
  8. 8. У нас нет времени</li></li></ul><li>Разговор (3)<br /><ul><li>А почему это проблема?
  9. 9. Ну мы не можем разработать достаточно быстро. Срываются сроки релиза. Заказчики жалуются.
  10. 10. А парное программирование может помочь?
  11. 11. Не уверен
  12. 12. Может попробуем поработать так одну итерацию?
  13. 13. Хорошая идея!</li></li></ul><li>Общий подход к «продаже»<br /><ul><li>Выявление проблемы (потребности)
  14. 14. Выявление последствий проблемы
  15. 15. Предложить решение, обсудить его выгоды
  16. 16. Рассмотреть опасения
  17. 17. Установить безопасное окружение для пилотирования
  18. 18. Общий Commit </li></li></ul><li>Потребности<br /><ul><li>Скрытая потребность
  19. 19. Неосознаваемая заказчиком
  20. 20. Явная потребность
  21. 21. Осознаваемая заказчиком</li></li></ul><li>Материалы<br />Нил Рекхем "СПИН-продажи" <br />
  22. 22. СПИН<br /><ul><li>Ситуационные вопросы
  23. 23. Проясняющие текущую ситуацию
  24. 24. Проблемные вопросы
  25. 25. Нащупывающие реальные проблемы
  26. 26. Извлекающие вопросы
  27. 27. Выясняющие важность проблем
  28. 28. Направляющие вопросы
  29. 29. Направляющие на варианты решения проблем</li></li></ul><li>Применимость Agile<br /><ul><li>Agile противопоказан
  30. 30. Заказчик не заинтересован в результате
  31. 31. Agile работает
  32. 32. Нужно максимально быстрое и эффективное достижение бизне-цели</li></li></ul><li>Заказчик хочет знать сроки окончания проекта<br />
  33. 33. Старинные методы оценки<br />
  34. 34. <ul><li>Scrum –метод управления изменениями.
  35. 35. Так его и продавать :-)</li></li></ul><li>Мой заказчик утверждает, что его требования не поменяются<br />
  36. 36. «Мы обычно согласовываем процедуру изменений»<br />(Не беспокойтесь, меняют требования все и всегда!)<br />
  37. 37. А давайте мы вам будем показывать раз в 2 недели результат?<br />
  38. 38. Общие правила<br /><ul><li>Backlog ака список функциональности
  39. 39. Заказчик может поменять любую несделанную фичу на эквивалентную по размерам
  40. 40. Фичи оценивает вендор
  41. 41. Заказчик может добавить или удалить фичу.
  42. 42. Заказчик может поменять порядок несделанных фич
  43. 43. В любой момент заказчик может принять решение остановить разработку
  44. 44. Заказчик формально принимает сделанные фичи</li></li></ul><li><ul><li>Что если заказчик будет напихивать новые фичи, и упираться при разговоре о изменении срока?</li></li></ul><li><ul><li>Все разговоры вести вокруг баклога
  45. 45. Демонстрировать незыблемость позиции относительно согласованных правил
  46. 46. Переводить разговор в конструктивное русло (например - что можно выкинуть из плана или что можно урезать)
  47. 47. Уметь говорить НЕТ</li></li></ul><li>Что если заказчик будет раздувать scope фич: «Такое поведение тут подразумевалось! Вы должны это сделать»<br />
  48. 48. Партнерство<br /><ul><li>Подчеркивать с самого начала, что заказчик и вендор являются партнерами
  49. 49. Постоянно объяснять, что увеличение scope затягивает сроки
  50. 50. С самого начала вникать в бизнес-потребности заказчика и просить его аргументировать изменения
  51. 51. В крайнем случае, отыграетесь, когда заказчик попросит новые фичи :-)</li></li></ul><li>Что если заказчик будет менятьфичи, которые находятся в работе в текущей итерации?<br />
  52. 52. <ul><li>Создавать приемочные тесты
  53. 53. Приемочные тесты согласовывать с заказчиком до начала планирования итерации</li></li></ul><li>Что если мой заказчик при наличии проблем будет сваливать вину на нас?<br />
  54. 54. <ul><li>Инвестировать как можно больше в хорошие отношения с заказчиком
  55. 55. Регулярно проводить демонстрации и знакомить его с командой
  56. 56. Приглашать на стендапы, ретроспективы и так далее
  57. 57. Обеспечить высокую прозрачность разработки</li></li></ul><li>Мой заказчик очень занятый человек и он не может уделить мне достаточно времени<br />
  58. 58. <ul><li>Создавать ритм общения. Например, пусть заказчик встречается с вами каждый второй четверг
  59. 59. Настаивать на соблюдении ритма
  60. 60. Тщательно готовится к встрече
  61. 61. Ловить за пуговицу в коридоре
  62. 62. Опять - хорошие отношения!
  63. 63. Звонить и вытягивать на общение</li></li></ul><li>И все-таки мой заказчик неадекватен. Что делать?<br />
  64. 64. <ul><li>Заранее согласовывать в контрактепроцедуру выхода. Она должна быть по возможности простой для каждой из сторон
  65. 65. Если общение заходит в тупик, дать понять, что вы готовы прекратить работу
  66. 66. Как правило, это действует отрезвляюще
  67. 67. Если нет, то все равно это не ваш клиент</li></li></ul><li>Мой заказчик – технический человек. Он постоянно вмешивается в работу команды<br />
  68. 68. <ul><li>Формулируйте с заказчиком правила его участия в работе команды (лучше заранее)
  69. 69. Вовлекайте в работу на ключевых этапах (формирование архитектуры, дизайн компонентов)
  70. 70. Целенаправленно повышайте его уровень доверия
  71. 71. Обеспечьте высокий уровень прозрачности разработки
  72. 72. Ни в коем случае не устраивайте войну! Вы проиграете!
  73. 73. Хвалите его :-)</li></li></ul><li>4П: продажа Agile заказчику<br />
  74. 74. АсхатУразбаев<br />askhat@scrumtrek.ru<br />Twitter: zibsun<br />Skype: askhatu<br />ЖЖ: zibsun.livejournal.com<br />

×