Наверное вы встречали заказчиков, у которых нет техзадания (далее ТЗ).
В этой заметке я постараюсь пояснять с точки зрения исполнителя, что такое ТЗ и зачем оно собственно нужно.
Можете смело заказчика без техзадания отправлять на эту заметку, я думаю, что ответы на свои вопросы он найдет в ней.
Итак, приступим.
Начнем с того, что я поясню, что такое ТЗ.
Если обратиться к википедии, то можно прочесть:
Техни́ческое зада́ние (ТЗ, техзада́ние) — исходный документ для проектирования сооружения или промышленного комплекса, конструирования технического устройства (прибора, машины, системы управления и т. д.), разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).
ТЗ содержит основные технические требования, предъявляемые к сооружению или изделию и исходные данные для разработки; в ТЗ указываются назначение объекта, область его применения, стадии разработки конструкторской (проектной, технологической, программной и т.п.) документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.
Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:
- обеим сторонам
- представить готовый продукт
- выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний)
- уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний)
- заказчику
- осознать, что именно ему нужно
- требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ
- исполнителю
- понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы
- спланировать выполнение проекта и работать по намеченному плану
- отказаться от выполнения работ, не указанных в ТЗ
Иначе говоря, ТЗ — руководство по разработке для исполнителя. То, что поможет исполнителю сделать именно то, что вам требуется и не сделать ошибку, основываясь на своем видении вопроса.
Из личного опыта могу сказать, что ТЗ существенно облегчает сотрудничество заказчика и исполнителя. В процессе обсуждения ТЗ стают понятны многие спорные моменты и пути реализации задачи.
Но что-то я немного отвлекся. О ТЗ я уже написал выше, теперь стоит написать, что делать, если ТЗ у вас лично нет, но при этом вы хотели бы сделать заказ.
На этом этапе слишком частая ошибка заказчиков — лень и фразы по типу «сделайте мне как у воооон того сайта». Это не ТЗ и такие вещи никак не ведут к результативному завершению заказа, а только еще больше размывают рамки того, что нужно сделать, хотя бы даже потому, что делеко не все заказчики понимают, что некоторые вещи нельзя делать по подобию других (например пример не удачен).
Из этой ситуации есть 3 выхода:
- Написать ТЗ самостоятельно. К сожалению очень часто этот способ не лучший выбор, просто потому, что заказчик «не владеет темой». Однако это самый дешевый способ с точки зрения траты средств. К тому же, когда вы пишите ТЗ, вы глубже понимаете то, что вам нужно и переосмысливаете многие вещи. Очень часто это ведет к увеличению нужных вещей и ликвидации ненужных замыслов. Я бы рекомендовал этот путь, если у вас есть достаточно времени на написание ТЗ самостоятельно (обычно достаточно пару страниц, набранных в Word, остальное разработчик доспросит, если будет нужно).
- Поручить написание ТЗ самому разработчику. Этот процесс состоит из того, что разработчик пишет ТЗ и паралельно распрашивает Вас все подробности о заказе. Данный путь удобен в том случае, если Вы готовы приплатить за работу разработчика по составлению ТЗ (бесплатно обычно этого никто не будет делать) + имеете запас по времени для ответа на вопросы разработчика. С другой стороны это развязывает в некоторой степени вам руки — ведь ТЗ составляли не вы и следовательно обо всех моментах реализации должен позаботиться исполнитель и он не сможет сказать потом, что «в ТЗ этого не было». Вам остается только не забыть упоминать ключевые моменты в разговоре, когда разработчик будет составлять ТЗ.
- Заказать ТЗ у специалиста по написанию ТЗ. Обычно в этой роли может выступить техрайтер или опытный разработчик в нужной вам сфере. Путь хорош тем, что как правило опытные в вопросе люди знают что нужно спрашивать и как понятно для конечного исполнителя это документировать. Минус данного пути — цена. Обычно стоит это не дешево и занимает от 2–3 дней до недели-полторы (если проект большой). Я бы рекомендовал идти по этому пути, если у вам нужно создать надежный проект, с учетом всех подробностей и удобный для конечного пользователя.
Какой путь выбирать — смотрите по своему бюджету, наличию свободного времени и доверию к разработчику.
Лично я стараюсь составлять ТЗ самостоятельно — это дает мне больше приимуществ, как заказчику в том плане, что я успеваю продумать то, что мне требуется и глубже представить проблему, которую я ставлю перед исполнителем.
Надеюсь, что данная заметка поможет как заказчикам, так и исполнителям понять друг друга и двигаться в правильном направлении!
Совсем скоро первый день осени, который ознаменует начало нового сезона в блоге.
