вторник, 19 августа 2014 г.

"Решение без проблемы", или история одного требования

Некоторое время назад наш Product Owner захотел от меня странного. Суть его желания заключалась в том, чтобы иметь статистику о том, сколько копий продукта сейчас работает у какого клиента. Изначально, подобная постановка требования меня не смутила и я бодро взялся за реализацию. Впрочем, когда мы с моими программистами стали прорабатывать варианты реализации, то быстро упёрлись в вопросы, для ответа на которые нам следовало понимать конечную цель  сбора этой статистики.

Пытаясь восполнить пробел в информации я стал задавать Product Owner`у вопросы, призванные прояснить конечную цель требуемой функции программы. Вот тут-то и начались проблемы, которых я не ожидал: диалог с Product Owner`ом у меня совсем не клеился. Я пытался узнать, зачем ему эта функция, какую проблему он хочет решить. Он же отвечал мне совсем на другой вопрос: что именно должна делать функция, какой отчёт он хочет увидеть и так далее. Это было весьма трудное общение, осложнённое тем, что поймать его было не так-то просто и он не горел желанием тратить много времени на обсуждение этого требования. Более того, его явно раздражала моя настырность и мои вопросы.

Признаться честно, в определённый момент я просто сдался. Решил, что я, наверное, зря пристаю к человеку и выдумываю на ровном месте какие-то сложности. "Надо просто взять и сделать" (с).  Закончилось это так: демонстрация нашей разработки была проведена практически "на бегу", после чего прошло уже полгода, а ей так НИ РАЗУ и не воспользовались.

Сухой осадок: выброшенные на ветер деньги и испорченное от осознания бесполезности проделанной работы настроение.

Почему так получилось? Я вижу две причины:

  1. Product Owner, видимо, сам не понимал, зачем ему нужна эта функция в программе. Такое часто бывает, что люди делают что-то просто так, без чёткого осознания связи своих действий со своими целями и проблемами. Видимо, PO попался в эту же ловушку и сделал свою работу некачественно. Грубо говоря, принёс вместо требования bullshit.
  2. Я согласился взять в работу требование без внятного понимания его цели и решаемой проблемы. Грубо говоря, я пропустил bullshit "сверху" в свою команду, не добился того, чтобы входящее требование соответствовало определённому стандарту качества. 
Мораль этой истории состоит в том, что ошибки совершенные "сверху по потоку" запросто приводят к тому, что вся дальнейшая работа становится бесполезной. Garbage in, garbage out. Чтобы защититься от некачественных данных на входе и, тем самым, обеспечить качественный результат на выходе, недостаточно быть просто умным и понимающим - надо обладать определённой твёрдостью и упрямством. Слишком мягкий человек, даже понимая, что он прав, рискует согласиться с плохим решением, просто чтобы не вступать в конфликт с коллегами.


2 комментария:

  1. В целом согласен, иногда проще сделать чем убедить почему делать не надо. Если сделать - полчаса, а разговоры о том зачем оно надо уже заняли один час (а может еще и не одного человека), то начинает казаться что продолжение спора - пустая трата времени.
    Кропе упёртости и упоротости тут могут помочь еще и инструменты. Например если ко мне придет продакт менеджер с фичей - я спрошу "а как ты проверил что эта фича поможет бизнесу?" - и тут он либо покажет мне результаты эксперимента, доказывающие важность фичи, либо подумает о том что такой эксперимент всё-таки надо провести, потому что lean и всё такое.
    Или можно еще использовать методики инженерии требований. Например такая упрощенная, но вероятно полезная в энтерпрайзе вещь как описанная здесь: http://www.amazon.com/Visual-Software-Requirements-Developer-Practices/dp/0735667721/

    ОтветитьУдалить
    Ответы
    1. К сожалению, степень просветлённости наших менеджеров такова, что вопросы про бизнес они не очень хорошо понимают :)

      Удалить