Мало кто будет спорить, что в сфере сложных ИТ-продуктов и их разработки, правильность постановки задач также важна как и исполнение задачи. Оба этапа критически важны.

Можно найти супер-специалиста и исполнителя, но допустить ошибку в постановке задачи и будут проблемы.

Можно отлично поставить задачу, но дать ее слабому специалисту и будут проблемы.

Потому важно уделить максимум внимания как в части постановки задачи, так и в части исполнения. Только тогда можно ждать требуемый результат.

И вот тут встает вопрос. А кто будет ставить задачу? Кто отвечает за то что будет правильное ТЗ?

Ситуации когда нет ТЗ или оно составлено плохо известно куда приводят. Их не рассматриваем.

Нужно условиться что мы берем достаточно сложные задачи где нужно ТЗ и где оно должно быть написано правильно.

В нашем портфеле заказов, это примерно 80% от всего объема. Лишь 20% столь просты, что не требуют ТЗ.

Так кто же должен делать ТЗ? Да не просто делать, а делать правильно…

И вот тут основная засада во всей отрасли. Заказчики думают что это должен делать исполнитель, а исполнитель думает что это должен делать заказчик. Истина как всегда по середине.

Но тут есть особенность.

За ТЗ в целом отвечает исполнитель. Заказчик как правило не является специалистом, иначе зачем ему исполнитель? Основная причина почему заказчик готов платить деньги за услуги, это то что ему нужны знаний и навыки исполнителя.

А это почти всегда означает что у заказчиках этих знаний нет. Он не сможет правильно поставить задачу.

Потому тут единственный правильный ход, это то что ТЗ должен составить исполнитель, но на основе данных от заказчика. Увидеть риски, задать вопросы, дополнить или переписать какие-то требования.

И вот тут есть подводный камень. Большой такой. Но не заметный сразу. Даже супер исполнитель, не всегда сможет отловить всех тараканов. И иногда пролетают отдельные требования, слишком размытые, вилка вариантов решений у которых может оказаться слишком большой.

И по закону подлости оказывается что Исполнитель действует исходя из принципов бритвы Оккама, т.е. делаем в минимальном варианте, исходя из формулировки. А заказчик под этим требованием ожидал что-то большее, но само требование не содержало этих деталей.

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

Но интересна сама причина. Это размытое требование. Заказчик его сформулировал. А исполнитель не сумел отловить и задать уточняющие вопросы. Запланировал ресурсы и сделал по минимуму, а заказчик хотел по максимуму.

И вот тут выходит то место где все таки заказчик обязан нести ответственность. За конкретные требования.

Глупо полагать что за все отвечает только исполнитель. Все таки исполнитель исполняет, а заказчик ставит задачу. Постановка задачи также важна. И если заказчик сформулировал требование слишком размыто, ну значит стоит ожидать проблем. Либо формулировать требования максимально конкретно, и тогда получать право требовать то что сформулировано. А то что не сформулировано, но как бы подразумевалось — это уж извините.

Да, не стоит тут путать размытое требование и общепринятое. Они кстати очень похожи. Оба не досказаны.

Но общепринятые требования прописаны в стандарте качества, это те требования, которые встречаются в большинстве подобных ситуаций. Формулировка тоже та еще 🙂 Но ее понимание очень важно.

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

Давайте рассмотрим примеры таких требований:

1. Требование «Оценка продукта». Сделали просто 5 звезд, а заказчик сказал… мол ребята вы чего. Должна быть возможность выбора звезд и описания комментариев. Форма, где пользователь запишет что-то.

2. Требование «Сделать внешний вид одного сайта максимально как у второго». Сделали, а в итоге оказалось что как то не так. Что конкретно не так не понятно. Ну в общем нужно переделать.

Вот два примера. Оба рисковые. Но принципиально разные.

Первое требование — общепринятое. Так реально делают все. Посмотрите любой каталог продуктов и в 90% случаев вы с оценкой увидите форму комментария. То что было сделано не так, это нарушение ожиданий. Исправляется за счет исполнителя. Это прописано в ИСО 9000.

Второй требование — это ошибка в постановке задачи. Что значит максимальное? Не понятно. Исполнитель делаем так как видит это в минимальном варианте. И сайт становится максимально похож на основной. Но Заказчику не нравится.

Тут не получится привести примеры общепринятой практики, потому что ее нет. Дизайн то уникальный. Потому это просто размытие требования. Вина больше на заказчике. Хотя и исполнитель при определенном опыте мог бы предвидеть этот риск и либо заломить стоимость такого требования соразмерно разработке дизайна с нуля, либо как то уточнить требование.

Но как уже сказал, даже имя гору опыта за плечами, не всегда удается отловить этот риск. Потому постановка задачи в целом это всегда ответственность исполнителя, но формулировки требований, если они проскочили от заказчика, это ответственность заказчика. Допустил размытое требование — жди проблем. И не нужно удивляться.

Исключение это общепринятые требования. Они прописаны в ИСО 9000 и с ними все понятно.