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

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

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

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

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

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

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

Мораль этой истории состоит в том, что ошибки совершенные "сверху по потоку" запросто приводят к тому, что вся дальнейшая работа становится бесполезной. Garbage in, garbage out. Чтобы защититься от некачественных данных на входе и, тем самым, обеспечить качественный результат на выходе, недостаточно быть просто умным и понимающим - надо обладать определённой твёрдостью и упрямством. Слишком мягкий человек, даже понимая, что он прав, рискует согласиться с плохим решением, просто чтобы не вступать в конфликт с коллегами.