Как получить от клиента идеальное техническое задание?
Конечно, иногда попадаются идеальные тз, с которыми легко и комфортно работается. Но что, если клиент не до конца представляет, что он хочет получить после завершения проекта?
А что если клиент при формировании технического задания не учел технических нюансов, которых он и представить не мог в силу недостаточной осведомленности в работе продакшена?
Ключом к получению идеального технического задания является ряд последовательных вопросов касающихся предстоящего проекта.
Несмотря на то, что некоторые из них могут показаться глупыми и не требующими ответов в силу их абсолютной очевидности, именно простые вопросы зачастую уберегают проект от лишних итераций правок, нарушения дедлайнов, и неверно рассчитанных бюджетов. Все эти пункты — пожиратели времени и денег.
Правильно поставленный вопрос — почти гарантия правильного ответа. Эйнштейн шутливо сформулировал этот постулат следующим образом:
«Если бы меня должны были убить и в моем распоряжении был бы только час на то, чтобы выяснить, как спасти свою жизнь, то первые 55 минут я потратил бы на поиск правильного вопроса. Найди я этот вопрос — и поиск нужного ответа потребовал бы всего пять минут».
У того, кто тратит больше времени на анализ проблемы, больше шансов увидеть суть вещей и наткнуться на то, что другие до сих пор не заметили. Правильными вопросами зачастую являются те, при постановке которых велик соблазн назвать их глупыми.»
Чем больше уточняющих вопросов будет задано клиенту на встрече, посвященной предстоящему проекту, тем более наполненным и подробным окажется техническое задание. Важно понимать, что, как правило, на встрече с заказчиком не может присутствовать вся команда исполнителей. Вместо всей команды во встрече обычно участвует менеджер проекта, который в дальнейшем будет выполнять роль ретранслятора между заказчиком и исполнителями, поэтому я считаю важным собрать как можно больше информации о предстоящем проекте, прежде чем он уйдёт в работу и начнет драть весь пайплайн на куски отсутствием полноценного технического задания.
Согласитесь, зная, что клиент планирует откручивать рекламный ролик в Штатах, лучше уточнить у него, почему в материалах проекта лежит текст для озвучки на русском языке и нужен ли для него перевод, чем постесняться и ничего не спрашивая выдать финальный ролик, который будет отправлен на переозвучку.
Например, клиенту очевидно, что ролик будет откручиваться в Штатах только для русскоязычной аудитории, перевод не нужен. А менеджер проекта решил, что раз рекламная кампания для США, то было бы круто сделать перевод, не спросив об этом клиента, продемонстрировав тем самым свою внимательность к деталям.
В общем, лучше показаться глупым и задать дополнительные вопросы, чем сделать вид, что все понятно и вляпаться потом в лишние итерации правок.
Ниже ряд вопросов, которые я задаю своим клиентам на этапе обсуждения задачи. Да, они могут показаться глупыми, но тем не менее, именно эти вопросы спасали многие наши проекты:
👾 Что вы имеете в виду?
👾 С чем это связано?
👾 А как вы будете это дальше использовать?
👾 А на что ещё это повлияет?
👾 А что, если будет не… а… ?
👾 Правильно я понимаю, что… ?
👾 А как быть с… ?
👾 А есть примеры, где это уже… ?
👾 Есть что-то ещё, что нужно здесь знать?
Возможно, клиента будет раздражать такое количество, казалось бы, глупых вопросов. Но как только он смирится с вашей настойчивостью и начнёт на них отвечать, то откроет для себя новые точки зрения на свою же задачу и, может быть, в процессе даже переосмыслит задачу.
А может быть и наоборот: клиент действительно не хотел отвечать ни на какие вопросы, а хотел, чтобы мы прочитали его мысли. Хорошо выяснить это как можно раньше, чтобы потом это не всплыло в середине проекта, когда реально потребуется участие клиента.
Может быть, в процессе обсуждения задачи клиент вообще поймёт, что на самом деле нужно делать другое, по-другому и не с вами. Может быть, вопросы будут настолько правильными, что клиент пересмотрит свои планы и работа сорвётся. Это тоже нормально.