Они строго говоря тоже делятся на 2 части:
- те, кто действительно знают, что такое agile;
- те, кто слышали про agile, и хотят попробовать.
Продажа вторым ничуть не отличается от продажи тем, кто никогда не имел дела с agile - просто происходит легче, так как Заказчик “предрасположен”. Работать с первыми - несравненно сложнее. Итак, как действует agile-Заказчик, который покупает agile-проект? К чему быть готовыми? И зачем он это делает?
- Он потребует чтоб ему представили команду. Причем прямо в ее рабочем месте. При этом он будет смотреть, насколько место обжито командой - то есть на самом ли деле “они работают вместе уже 2 года” или их посадили вместе вчера? Зачем ему это надо - он хочет сработанную команду, с минимальной вероятностью конфликтов. Причем скорее всего потребует зафиксировать состав членов команды в контракте. Замесы типа “у нас вся компания - одна команда, кого не поставь - все будут отлично работать!” не пройдут. Квалифицированный agile-Заказчик всегда покупает именно команду. Почему - см. ниже.
- Он предложит сделать притирочный workshop. Ну там знаете - шарики понадувать, кубики покидать, но все это в режиме реального scrum, пусть и со спринтами по 15 минут. Смотреть при этом он будет на владение терминологей, предупредительность к Заказчику, соблюдений рекомендованных практик. Зачем ему это надо? Проверить, насколько команда умеет работать по agile - имеет поставленный процесс или читала книжку и сейчас вырабатывает соглашения.
- Он захочет увидеть среду continuous integration и какой-то предыдущий проект команды. Потому что даже следы двухнедельной деятельности команды очень трудно эмулировать. И из артефактов станет понятно, насколько толковый тестер, как аккуратно оформляются чейнджсеты и коммиты, и вообще как люди работают вместе. Зачем ему это надо? Увидеть, насколько технически зрелой является среда, в которой работает команда. Это дает некоторые основания считать, что будет качественное решение.
- Он затеет peer code\architecture review предыдущего\одного из проектов команды. Причем среди peers обязательно будет Архитектор Заказчика. Зачем ему это надо? И тут как дважды два станет понятна вероятность получения качественного решения.
- Он попросит посмотреть burnout charts предыдущих проектов\спринтов. И конечно же будет искать ненормальные прекращения спринта, недовыполненные обещания и задавать вопрос “почему?”. Зачем ему это надо - понять, с какой скоростью работает команда, и насколько она аккуратно делает оценки и выполняет обещания.
- И только после этого он затеет тестовый спринт. Причем скорее всего честно вас предупредит - “кроме вас тут еще 4 команды делают тестовый спринт, и вот по результатам выступлений мы выберем лучшую, которой и отдадим проект”. Зачем ему это? Чтобы не только выбрать самую производительную команду, но и задать высокий темп бега с самого старта дистанции.
Итого. Если вы в своей sales-презентации заявили, что “our team is capable to deliver true agile” - будьте готовы к изложенным выше моментам. Если вы не готовы подтвердить декларацию опытной командой - лучше сразу честно сказать, что мы обучение прошли, но команда вместе не работала.
В следующей части я расскажу как продавать agile тем, кто не имеет о нем представления.
В закладки:
Но раз надо - могу собраться.
Спасибо за статьи!
Жаль что так и нет продолжения.
Интересно было бы узнать о :
1. О том как продать Agile тем кто не имеет о нем представления - сомневаются что “это все будет работат”
2. Немного не по теме - как “продать” agile внутри фирмы