1 заметка с тегом

понимание задачи

Кто должен писать ТЗ

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

Все обычно так:
Клиент: Вот документ. Вам все в нём понятно?
Дизайнер: Да, все в принципе ясно.
Клиент: Оке, тогда ждем.
Дизайнер: Ок.

На выходе неожиданный результат. Либо обе стороны блуждают в потёмках: спорят. Спорят с разными картинами мира и не видят этого. Разные ожидания вскрываются иногда далеко не сразу, особенно если никто не собирается изучать мир противоположной стороны и доказывает свою «правду».

Любой такой документ (как его называть брифом, ТЗ или пониманием задачи — все равно) должен быть написан тем человеком, который будет решать задачу. Никем другим.

Если клиент приносит мне написанный документ, я его читаю и созваниваюсь с ним. После пишу новый документ. Своими словами, как я понял то, о чём мы говорили. Копипастить нельзя. И обычно это так:
я написал, показал клиенту, созвонились он дополнил, поправил. Я еще раз спросил: всё ли я верно написал, проговорил ещё раз все — по ходу выяснили еще что-то. Я снова это вношу документ. И так до тех пор, пока клиент не скажет: да, всё верно.

Если вы так не делаете, то попробуйте, и офигейте, что большинство людей не правильно или не точно понимают ваши задачи. Даже если вы нарисовали супер понятную схему, и проговорили все (так только вам кажется).

Это касается не только дизайнеров, а вообще всех. Если хотите, чтобы задача была решена — попросите человека написать понимание задачи прежде чем делать что-то.

 1 комментарий   2014   дизайн   понимание задачи   результат   тз