Эту фразу произнес один из архитекторов, когда возникла очередная спорная ситуация с заказчиком. И эта фраза, а точнее образ мысли – очень большая проблема в любом проекте. В таком подходе нет даже намека на системное мышление и системный подход. Почему?
В подавляющем большинстве случаев ТЗ пишет группа сотрудников или один сотрудник, которым руководство спустило сверху задачу вида «Нужно, чтобы система Х заработала к концу этого года».
Зачем нужна эта система Х? Какие задачи она должна выполнять? Какие проблемы решать в компании? Ответы на эти и другие важные вопросы знает то самое руководство, поставившее задачу, но оно не пишет ТЗ. Кроме того, руководство – это не одна понятная роль. Финансисту нужно сократить издержки, менеджеру нужно сократить время выполнения задач и увеличить количество выполняемых задач, руководителю компании/подразделения – оптимизировать штат и т.д. Получается, что задача поставлена, делать и отчитываться надо, а идти наверх, искать исполнителей ролей, выяснять и спрашивать «зачем?» и «для кого?» страшно/долго/не понятно к кому/не положено и т.д. И люди начинают выполнять задачу ради задачи, попутно стараясь решить этой задачей насущные проблемы своего уровня (а задача то была поставлена уровнем выше, и проблемы там были совершенно другие), потом передают результаты задачи другой группе (проектной команде), которая приходит с четкой целью - реализовать требования ТЗ, и начинает делать задачу ради задачи ради задачи.
В результате долгой работы, на которую тратят свое время и силы много разных сотрудников, получается нечто по ТЗ. Но изначальных задач и проблем руководства это нечто не решает, потому что о них никто не думал. Пользоваться этим нечто нельзя, потому что группа ответственных сотрудников писала ТЗ, потом команда проекта реализовывала пункты ТЗ и сдавала систему по этим пунктам, но они все вместе не думали, как эта система будет использоваться и зачем.
начинаешь задавать “неудобные” вопросы про надсистему - сразу становишься “душным” или человеком, вбивающим палки в колеса проекта и тормозящим работы :)) но, надо сказать, иногда хорошо действуют объяснения (с примерами) про то, что вариантов реализации - тьма, как сфокусировать решение, если не будет понимания того, как это решение планируется использовать.