Забавная история об анти-Agile заказчике

В этот раз решил начать описание сложного кейса с истории из детства:

В детстве я очень не любил ответ «Потому что так нужно!». Это так удивительно, когда ты пытаешься выяснить причины поступков или подходов, а в ответ сталкиваешься с тем, что другие люди или не знают почему это так или не хотят тебе отвечать. Вот так меня и мучал вопрос: «Почему нельзя ставить что-то горячее в холодильник? Горячее нужно охладить, а холодильник предназначен для этого!» или «Зачем в футболе офф-сайд? Ведь так же голов меньше!». Смириться с ответом «Потому что такие правила» я не смог и начинал читать-копать-выяснять-додумывать. И это приносило результаты и удовольствие от открытий, хотя иногда меня не любили за такие вопросы :)

Сейчас, занимаясь управлением и консультированием, я понимаю, что моя привычка сослужила мне очень хорошую службу. Так много людей в разных компаниях выполняют те или иные задачи потому что «так принято». И когда задаешь вопрос «А почему?» или «Зачем?», то запускаешь удивительные процессы в голове. Одни люди начинают думать и искать причину, другие сразу же закрываются «в домике», когда правила (даже неписанные) не обсуждаются.

А теперь сам сложный кейс:

Одна команда пришла ко мне за консультацией – они очень хотели работать по Scrum в своей команде, но им попался Заказчик, который задает такие же сложные вопросы. Команда – хорошие и толковые ребята, которые давно зрели к переходу на Agile. Их менеджмент даже выделил денег для троих участников на сертификацию (CSM), которую ребята успешно прошли. Вроде история имела все предпосылки стать успешной, если бы не эти самые вопросы Заказчика.

Команда описала преимущества перехода на скрам и все «плюшки», которые получат. Но тут Заказчик проявил себя в полной мере… Все началось с невинного вопроса: «А почему Скрам работает?». И тут оказалось, что кроме маркетинга и стандартных фраз из курса CSM о коротких итерациях и счастливых Заказчиках, у команды нет объяснений. Дальше Заказчик развил тему и начал спрашивать «А зачем ретроспектива? И зачем делать такой долгий планнинг ? и т.д.». Шквал вопросов, атакующих правила, выбили команду из колеи, ведь простых ответов на них нет.  А как только Заказчик понял, что команда не понимает сути процесса, то сразу перешел в режим отрицания. Дальше Заказчик сам себя накрутил тем, что «додумал» факты о том, что команда хотела проводить «процессные эксперименты за его деньги». И я его понимаю!

В ответ на сложные вопросы Заказчика, команда закрылась в тот самый «домик» и стала ссылаться на «правила» и «лучшие практики». Не стоит говорить, что Заказчика такие ответы не устроили.

Почему-то я подумал, что эта команда не одинока. В нашем мире мы часто просто опираемся на правила и не задумываемся о том, что стоит за ними. Мы предлагаем Заказчику внедрить TDD и авто-тесты или приходим к начальству с новой идеей обучения и т.д. А вот на вопрос «ПОЧЕМУ это работает?» у нас ответа нет :)

 В общем команда осталась с проблемой и недовольным Заказчиком. Непростая ситуация, да?

UPD: Добавил разбор ситуации.

P.S. Хотя можно ли такого Заказчика назвать “анти-Agile”?

Nov 13th, 2012
  1. Nov 13th, 2012 at 14:16 | #1

    Хороший такой заказчик, умный. Имхо, если он задает такие вопросы про процесс, то с ним и по продукту будет выстроено глубокое общение. И вообще, заказчик-то как раз может быть и есть Agile – с точки зрения ценностей, которые заложены манифест, но это так, чисто внутреннее ощущение.

    • Nov 13th, 2012 at 14:21 | #2

      Ага, этот умный! Да я даже не сомневаюсь, что дело с ним будет, вот только это не будет “простой прогулкой”. Это будет хорошая битва, после которой каждый останется доволен.

  2. Nov 13th, 2012 at 14:18 | #3

    как обычно.

    если проблем нет, то зачем что-то менять?
    если проблемы есть, но внедрение нового их не адресует, то зачем внедрять новое?
    если проблемы есть, внедрение нового их адресует (и потенциально решает), но команда не способна это озвучить, то зачем её называть “хорошие и толковые ребята”?

    :)

    • Nov 13th, 2012 at 15:12 | #4

      Ты молодец! вот так и хочется написать универсальный решатель проблем :)

      Проблемы есть!
      Да не знают они, адресуют нововведения их проблемы или нет. Они не делали этого
      Не способны, по причине, которую описал выше. Просто раньше им такие “неудобные вопросы” не задавали :)

  3. Nov 13th, 2012 at 15:23 | #5

    > Да не знают они, адресуют нововведения их проблемы или нет.
    > Они не делали этого

    тогда клиент прав – просто процессные эксперименты на его деньги, потому что модно.

  4. Alexey
    Nov 13th, 2012 at 18:09 | #7

    Ну дык кастомер задал резонные вопросы, он спросил по сути про value, которое ему хотелось бы увидеть от процесса и практик.
    Просто команда не должна отвечать на такие вопросы, для этого и нужен менеджмент. Просто поменеджить ожидания заказчика, показать ему “что лично для него будет проще, дешевле и быстрее” :)
    Нужно показывать конкретные кейсы, которые дадут ему visibility.

  5. Кирилл
    Nov 13th, 2012 at 18:10 | #8

    На самом деле для каждой практики из Agile очень просто составить ответ на вопрос зачем оно надо. Просто надо реально набить шишек в реальной работе и все станет понятно.

    Если заказчик не понимает зачем нужно планирование – то как он прогнозирует деньги ? Планирование нужно в любом случае Agile оно или нет. И планирование нужно в первую очередь заказчику.

    Зачем нужна ретроспектива выясняется после первой же недели работы. Обязательно выплывет что кто-то что-то не успел, плохо записал, не так понял и т.д. Что опять-таки нужно заказчику, так как сбивает с налаженной работы.

    • Nov 13th, 2012 at 18:26 | #9

      В целом – правильно.

      Но опять, Заказчик, для поддержания проформы, задает вопрос “А вы уверены, что у вас это тоже будет работать, как и у Alistair Cockburn?”

      Ведь в этой команде и с этим Заказчиком аджайл происходит впервые.
      И опять все понеслось! :)

      • Кирилл
        Nov 15th, 2012 at 18:38 | #10

        А зачем заказчику говорить про непонятных заграничных тетенек и дяденек :) Надо говорить, что очень хороший способ (например) выявления и разрешения спорных ситуаций и проблем – это регулярное обсуждение (читай ретроспектива), причем можно сослаться даже на признанных гуру тайм-менеджмента (а оно по факту так и есть).

        Или например, что давайте будем планировать работу итерациями по 2 недели чтобы это не привело к неконтролируемой работе.

        Но на самом деле заказчики разные, но повторюсь, от каждой практики заказчику есть какая-то польза, надо ее объяснить.

        Есть так же еще и инженерные практики (TDD и прочие). В принципе про них можно не говорить заказчику, планируется все равно в попугаях (story-point). Ведь они направлены на то, чтобы в итоге команда делала свою работу быстрее и качественнее (что опять-таки быстрее). А аргументы вот тут мы выделим 2 часа на тесты и вы нам их оплатите – совершенно не правильные и заказчика только напугают, а плюса никакого не принесут. На самом деле проверить оценку работ по факту нельзя, ведь нельзя найти 2 абсолютно одинаковые команды, одни что-то одно быстрее будут делать, другие – другое.

Leave a comment