Анти-аджайл Заказчик. Давайте разберемся.

Я тут общался со многими коллегами по поводу паттернов поведения и решения проблем, когда мы не можем убедить  Заказчика в необходимости Agile и т.д. Причина проста – на сайте есть кейс об «анти-аджайл заказчике», который нужно решать.

Удивительно, но мнения коллег почти пополам разделились между двумя опциями:

 

  1. Долбить сильнее и чаще. То есть набрать фактов для решения конкретных проблем в других командах и еще раз (а может и не один) рассказать это Заказчику. Пока он не сдастся под нашим напором.
  2. Долбить качественнее. Использовать разнообразные техники продаж (СПИН) и манипуляций, чтобы его убедить Заказчика.

Посмотрите внимательно на эти подходы. Они очень хорошо отражают ту реальность, в которой многие менеджеры проектов общаются с Заказчиком. Нам проще использовать технику «большого дятла» или манипулятивные приемы, чтобы доказать свою правоту, чем готовить аргументы. Нас так «накачали» идеями, что за счет личных коммуникаций можно решить все, что мы забываем, что нужно понимать суть. Далеко ходить не буду, очень часто ко мне приходят запросы на проведение тренингов и среди тем обязательно проскользнет желание «умение убеждать» и «техники манипуляции».  

Да не будет работать такой подход! Заказчик, судя по описанию и кейсу, очень толковый и работает на уровне логики, чем на уровне эмоций. И все манипуляции и ведение переговоров разобьются о вопросы «А зачем?». Так сказать «Trololo mode on» :)

Как решать кейс?

Как ни удивительно, но здесь пока виден один выход. Раз Заказчик требует логических обоснований и хочет понимать глубинный уровень, то нужно копать в сторону понимания Agile процессов. И не просто копать, а уходить на уровень «Ха» (по модели Сю-Ха-Ри).

Перед тем, как делать рекомендации к решению важно сделать одно предположение: Команда знает почему они хотят перейти на новый процесс и понимают какие проблемы будут решены с помощью этого процесса. А теперь можно перейти к решению.

Вот несколько шагов к решению.

  • Читать книги по agile-процессам и их подходам и пытаться там найти закономерности и базовые правила (Agile Manifesto не предлагать по причине размытости). Но так как книги чаще всего написаны в директивном или описательном стиле, то понять «почему» это работает – не так просто. Мое личное мнение: Большинство книг по Agile написано в виде описания успешных историй. Мотив такой: нам было плохо, потом подумали и решили взять аджайл и стало хорошо. :)
  • Нанять эксперта в этой области. Он принесет свой опыт и понимание особенностей процессов. Не факт, что он сам будет понимать КАК это работает, но у него есть свой опыт и набитые шишки.
  • Само-коучинг. Задавать команде вопрос: «А почему у нас это заработает?» и «Что будет нас мотивировать сегодня-завтра-через месяц?». Это подготовит к вопросам Заказчика и даст возможность «подтянуть» себя.

Конечно, каждый из этих шагов не быстрый. Это не случится за день или два. Но хочется перейти на новый процесс прямо сейчас! Вот поэтому команда будет верить в хороших переговорщиков и манипуляции. Да потому что так хочется найти путь к быстрому решению проблем. Мой любимый вопрос в тему: «Доктор, что вы можете сделать, чтобы я похудел?».

Знаете решение лучше? Комменты работают…

Nov 15th, 2012
  1. Классический запрос к фитнес-тренеру: “похудейте меня, пожалуйста”. Это еще лучше :)

  2. Сергей Сохацкий
    Nov 15th, 2012 at 14:14 | #2

    К сожалению с Agile знаком недавно и очень поверхностно. Вот так случайная встреча, сайт… И я стал как минимум активным читателем :)

    Если я правильно понимаю, то Agile – это методология или “лучшие практики” внедрения ПО… ну где-то так. Поправьте, если ошибаюсь!

    По моему, не очень длительному, опыту внедрения “лучших практик” ITIL – могу только согласиться с Сережей.

    Все Заказчики делятся на 3 категории:
    1. Те, которые самостоятельно пришли к тому, что процессный подход им нужен и они знают зачем
    2. Те, которые просто следуют моде
    3. Те, которые просто не дозрели и не понимают зачем им это нужно. Ведь и так работали нормально – зачем нам что-то менять…. А если и понимают, что нужно что-то менять, то почитав или послушал лекции о ITIL – говорят – нет, это не для нас…. это для буржуев методология.

    3 – Вот этот тот Клиент, о котором идет речь в кейсе.
    И ведь не случайно существует такая категория. Потому, что любая буржуйская методология прежде всего приходя на наш рынок продается как отличный способ получить ОТКАТ и заработать всем деньги.
    Оценить же бенефиты и собственно в результате их получить, могут только те, кто относиться к категории 1.

    Единственный способ – это повышать зрелость Заказчика, а это: экспертное мнение, книги, лекции, само-коучинг.

  3. Nov 15th, 2012 at 16:25 | #4

    >> Конечно, каждый из этих шагов не быстрый. Это не случится за день или два.

    А сделать по скраму совместно с Заказчиком тестовую мини-задачу, скажем на одну-две недели (скажем, с 2х дневными итерациями) – не вариант?
    И сама команда попробует, и Заказчик увидит, что и как.

    Да и еще, меня смутила фраза “А как только Заказчик понял, что _команда не понимает сути процесса_”. Все-таки “не понимают” или “не могут аргументированно объяснить выгоды от процесса”? Это разные вещи.

    • Nov 15th, 2012 at 16:41 | #5

      Валерий,
      “Сделать тестовую итерацию” – аргумент, но мне кажется в глазах Заказчика означает “мы не нашли как вас убедить, давайте вам покажем”.

      “Не понимают” или “не могут аргументировано объяснить выгоды”. Да в том-то и вопрос. Во-первых, людей которые делали Agile в таком проекте в команде нет. Значит как минимум “нет опыта”. Во-вторых, люди, которые глубинно понимают Agile – редкость. В-третьих, как можно объяснить аргументирвано преимущества того или иного подхода в процессе если его не пробовали? :)

      • Nov 15th, 2012 at 16:46 | #6

        Сергей, у меня Заказчики обычно смотрят на ситуацию “с точностью до наоборот” – не надо нас убеждать (“к нам тут уже столько рассказчиков приходило”), покажите нам что это (то, что вы предлагаете) – действительно работает!

Leave a comment