Предпоследняя версия требований

Изменяющиеся требования

Как много раз я слышу вопросы: «Что делать с Заказчиком, который меняет требования?» и «Почему Заказчик все время просит что-то доделать или переделать?».

Команды и руководители проектов тратят, наверное, миллионы часов на то, чтобы получить «последнюю версию требований» и спокойно работать по ней. Но как только версия получена, то через какое-то время опять приходит Заказчик и просит сделать что-то «по-другому». И что еще «веселее» – ссылки на договоренности и контракты не имеют воздействия :).

Как ни удивительно, но ответы на эти вопросы лежат на поверхности. Не бывает Заказчиков, которые не меняют требований. Просто частота изменения (и осознания необходимости изменений) у разных Заказчиков разная. Недавно проходил открытый тренинг Outsourcing as a Service в Харькове и, благодаря активной работе группы в играх о требованиях, сформировалась мысль, которую хочу занести в мемориз :)

У вас на руках всегда предпоследняя версия требований Заказчика.

Да-да, все правильно. Не бывает по-настоящему «замороженных» и «утвержденных» требований. А если и есть такая версия, то она обязательно не устраивает (или скоро будет не устраивать) Заказчика.

Этот парадокс (постоянного изменения требований) определяется многими факторами:

  • Невозможно (могу даже математически доказать :)) полностью корректно написать требования. Всегда останется что-то недосказанное, что «заказчик подразумевал, а команда не выполнила»
  • Бизнес меняется. Конкуренты не спят и добавляют новую функциональность. Для того чтобы быть на плаву, нужно постоянно меняться.
  • Стейкхолдеры (stakeholders) постоянно дают новые идеи о том, что должно быть в продукте и как это должно выглядеть.
  • Аппетит приходит во время еды. Как только Заказчик увидит работающий продукт, то обязательно найдется то, что нужно доработать.

Тем не менее, все команды разработки недовольны тем, что требования меняются. Им кажется, что это доказательство того, что команда не может сделать что-то хорошее с первого раза :). Но, как видно из вышеперечисленных пунктов, слова «команда» и «качество» не встречаются среди основных причин возникновения изменений.

Что с этим делать?

На тренинг я подготовил пару аналогий в виде «домашних заготовок»:

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

Не можешь предотвратить – возглавь!

На самом деле опытные разработчики и менеджеры умеют повернуть эту ситуацию во благо команде и Компании. Новые требования – это всегда новая работа для команды. Если вы работаете в аутсорсинге – это возможность продлить контракт, если вы работаете в продуктовой разработке – то это список фич для следующей версии. Главная задача – правильно управлять ожиданиями Заказчика. Принимайте и развивайте идеи об изменении продукта, только всегда говорите, сколько это будет стоить и как долго это будет разрабатываться.

Feb 3rd, 2011
  1. Mantis
    Feb 3rd, 2011 at 10:11 | #1

    Это всё замечательно, когда работаешь в аутсорсинге по time&material.
    Основные проблемы возникают, когда проект fixed price, бюджет уже выеден, а заказчик опять меняет требования и не идет ни на какие допбюджеты с пеной у рта доказывая “ну это же очевидно, вы же профессионалы”.

    • Да, а заказчик в основном склонен искать подрядчика на fixed price, чтобы было все включено и без неожиданностей. Тут стресс и для разработчиков и для менеджеров.

      • Feb 3rd, 2011 at 13:23 | #3

        Фиксед прайс известная проблема. Я даже по нему написал отдельную статью. http://anotherpm.com/blog/?p=687&lang=ru-ru
        Но статья – это даже меньше чем вершина айсберка. Даю гарантию, что можно писать томы книг и защищать кучу диссертаций :)

  2. Feb 3rd, 2011 at 10:58 | #4

    - Ватсон, это был программист! (с)

    совет практически бесполезный, т.к.
    1. проблема при дедикейтед-тим или т&м схемах не возникает;
    2. а при фиксед-кост схеме не лечится указанным способом;

    такие дела.

  3. Feb 3rd, 2011 at 12:27 | #5

    Господа,
    Во-первых, статья была об ОТНОШЕНИИ команды к изменениям в требованиях. Отечественные команды плохо воспринимают сам факт того, что требования меняются и они не видят бизнес-причин, которые повлекли эти изменения.
    Во-вторых, у нас отсутствует умение продать изменение. Не важно, это T&M или Fixed Price, если вы не умеете правильно показать клиенту, что это изменение и рост и объяснить почему лучше сделать это “отдельно”, то будете “с пеной у рта доказывать….”
    В-третьих, во всех нормальных процессах разработки ПО есть системы управления изменениями в требованиях. В waterfall это change requests, в SCRUM – новые стори и т.д. Очень часто, менеджеры игнорируют это и не повышают визибилити этого.

    И еще раз в конце коммента подчеркну: Это пост об отношении к этому процессу, а не ответ на то, что с этим делать.

  4. Feb 3rd, 2011 at 12:54 | #6

    1. не видел команд, которые плохо воспринимают изменения (оплаченое увеличение скоупа) в требованиях. видел те, которые плохо воспринимают изменения, которые клиентом пропихиваются как баги (бесплатную работу) :)

    2. тут спорить не буду, хотя вопрос ооооочень спорный :)
    хотелось бы увидеть пример продажи по такому кейсу (реальный случай):
    [в спеке описано редактируемое текстовое поле, называется "параграф". после демо клиент утверждает, что "параграф" означает "не более 600 символов". естественно это нигде в спеке не указано и ограничение на длину определяется полем в базе, т.е. 65К.]

    3. ну это реально вообще отдельная песня. менеджеры, которые не управляют скоупом проекта?

    вобщем что я хочу сказать – имхо проблема надуманная:
    если клиент готов платить за изменения, это всем нравится… и проблемы нет.
    если клиент за изменения платить не хочет, это всем не нравится… но поможет ли в этом случае возглавление этого процесса пмом? вопрос.

  5. Feb 3rd, 2011 at 13:21 | #7

    @ СОТОНА

    Какой-то неконструктивный спор получается. Аргутент: “Я не видел, значит этого нет” плохо вяжется с миллионами других проектов, которые ведут другие люди.
    Я лично вижу, как постоянные изменения требований бесят разработчиков. Как менеджеры не умеют правильно управлять скоупом проекта, потому что это сложнее, чем кажется… и т.д.

    • Feb 3rd, 2011 at 13:45 | #8

      Да реально при фиксед прайс продать допы очень сложно. И причина тут в том, что платит один, а работу принимает другой.
      Приёмщик понимает, что это рост, это новое веяние, это он сам недосмотрел (если есть смелость это признать). А вот с точки зрения плательщика это ваш с приёмщиком непрофессионализм. Вы обещали, что за эти деньги будет готовое решение, а в итоге решение готово только на половину. Заплатить вам ещё? А потом окажется, что опять решени только на половину? И сколько это будет продолжаться?

      И самое главное, если в syt пообещаете, что будет готовое решение, то у вас вообще ничего не купят. :-)

  6. Feb 3rd, 2011 at 13:29 | #9

    Как в анекдоте:
    Посылает цыган сына за сигаретами.
    - А деньги, – спрашивает сын.
    - С деньгами и дурак купит.
    Сын возвращается, приносит пустую пачку.
    - А сигареты?
    - С сигаретами и дурак покурит.

  7. Кирилл
    Feb 3rd, 2011 at 14:43 | #10

    Проблема не надуманная, а, реально, существующая. И является катастрофическим психологическим демотиватором на долгоиграющих проектах. В данном случаем мне импонирует хинт Сергея, помогающий концентрироваться на работе, а не рефликсировать.

  8. Feb 3rd, 2011 at 16:21 | #11

    хм. сори, если кажется, что неаргументированно :)

    но давай рассуждать логически – что может не нравится в сферическом изменении требований в вакууме?

    т.е. в ситуации, когда
    а) тебя ни в чём не обвиняют
    б) тебя просят улучшить проект, над которым ты работаешь
    в) тебе за это платят

    ответ очевиден?

    теперь давай порассуждаем, что же нас может напрягать в увеличении скоупа?
    а) наезды, что это мы что-то не заметили\не так поняли\это подразумевалось. то есть нам вместо ченжей вменяют баг.
    б) апеляции к незначительности изменений, типа они такие маленькие, что мы должны это сделать бесплатно.
    в) предлагаемое изменение по нашему мнению ухудшает проект (чаще всего с архитектурной точки зрения), хотя нам за это и платят.

    ситуации в) “изменение кажется глупым” действительно бывают, но каков их процент на общем фоне? мой опыт говорит, что маленький.

    итого – из всего множества возможных раздражающих изменений, мы реально можем возглавить малую часть. что делать с остальными?

    • Feb 3rd, 2011 at 16:23 | #12

      p.s.: провёл блиц опрос разработчиков на тему. результаты интересные, но покажу их позже, когда их будет больше.

      оффтоп: а можно сделать так, чтоб пункт “Change” был всегда развёрнут? а то там спрятана капча, которую не видно :(

      • Feb 3rd, 2011 at 20:03 | #13

        Результаты опроса жду в треде или отдельным постом на блоге. Главное набрать репрезентативную выборку :)

    • Feb 3rd, 2011 at 20:17 | #14

      Давай тогда логически :) (версия by anotherpm)

      Что может напрягать с психологической точки зрения в увеличении скоупа:
      а) нет чувства “выполненной работы”. Т.е. ты идешь-идешь к цели, долго упроно ее долбишь, а потом оказывается, что пришли “не туда”. Удовлетворение от работы падает. Мотивация падает.
      б) Заказчик валит все проблемы на вас. Не важно кто виноват, но доделать должны вы. За ваши деньги и время. Конечно никто не любит работать бесплатно.
      в) Последовательная реализация противоречивых требований. Сначала делаем так, потом по другому, как раньше было “не надо”.
      г) Множественные change requests со стороны заказчиков-пользователей, которые не согласованы и не приоритезированы. Т.е. не знаешь, за что хвататься.

      Что напрягает с профессиональной точки зрения
      а) ченджи могут настолько затянуться, что проект станет невыгодным. Вас прессуют все, потому что проект стал похож на чемодан без ручки. Работает только при фиксированной цене и отсутствия правильного подхода к продаже изменений.
      б) Ваши _ожидания_ разбились, так как предположения о проекте были “жестоко отвергнуты бизнесс-реалиями в которых живет Заказчик”. (Как бы намекая, что вы себя переоценили, как профи… :) )
      в) Технологически проект прост и вам уже не интересно его поддерживать, так как вы перестали развиваться.

      Просмотрев оба списка понимаю, что есть набор субъективных причин не любить изменения. И всего лишь одну объективную причину – когда это не выгодно с точки зрения денег.

      И вот вопрос… что же главное, деньги или другие причины….

Leave a comment