Это страшное слово «техзадание», или Как правильно поставить задачу айтишнику

Когда возникает необходимость поставить задачу на разработку, даже у опытных постановщиков может начаться приступ паники: «А как? А что? Я не умею!» Юрий Алексеенко, руководитель департамента разработки «Сантехники-Онлайн», разбирает основные заблуждения и рассказывает, как создать полезное ТЗ.

Техническое задание должно быть написано в соответствии со стандартами и ГОСТами.

Действительно, существуют отрасли и масштабные проекты, где техническое задание представляет собой сложный стандартизированный документ. Однако в повседневной практике ТЗ не обязательно должно строго соответствовать стандартам и ГОСТам. Главное — ясно и понятно сформулировать требования к проекту и изложить их простым и доступным языком.

Как я могу написать ТЗ, если не разбираюсь в программировании?

Важно отличать техническое задание от технического проекта. Заказчик редко обладает техническими знаниями и не обязан разбираться в программировании. Его задача — описать, что он хочет получить и какую проблему нужно решить. Именно это описание является техническим заданием. А разработку технической архитектуры продукта выполняют специалисты на основе вашего технического задания.

Техническое задание нужно писать канцелярским языком.

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

Техническое задание должно быть объемным и внушительным документом.

На самом деле это не так, и нет необходимости усложнять. Если для описания вашей потребности достаточно одного предложения, то напишите одно предложение.

Идеального технического задания не существует, но есть два ключевых фактора, к которым стоит стремиться:

1. ТЗ должно быть понятным. Подходите к его написанию с точки зрения потенциального читателя и задайте себе вопрос: «Если бы я читал этот текст впервые, понял бы я, о чем здесь говорится?»

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

По роду деятельности мне довелось написать не одну сотню ТЗ. Я анализировал, насколько понятны были описанные мной документы, с какими вопросами возвращались ко мне разработчики, насколько полученный результат соответствовал моим ожиданиям. Это позволило мне задуматься над тем, каким образом можно написать ТЗ так, чтобы получить точный результат и минимизировать количество вопросов от разработчика? С течением времени я пришел к определенной структуре технического задания, которой сейчас готов поделиться с вами.

Опыт показывает, что для разработчика гораздо проще понять задачу, если предоставить обобщенное описание объекта (механизма, процесса и т. д.), касающегося предстоящей разработки. Подразделы вводной части могут включать в себя следующие блоки:

Как сейчас

Если задача разработки включает изменения в чем-то, уже существующем (особенно если это существующее должно быть базой для нового), необходимо описать, как выглядит объект разработки в настоящее время. Изображения экранов (скриншоты) могут значительно облегчить понимание. Разработчики ценят визуальные материалы, пословица не зря гласит: «лучше один раз увидеть, чем сто раз услышать».

Проблематика

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

Именно так — Что надо сделать — я называю основной раздел технического задания. Разработчик понимает, что тут заканчивается обобщенная информация и начинается конкретика.

Излагая задачу, старайтесь придерживаться следующих правил.

Сценарий тестирования — это описание последовательности действий, выполняемых в разработанном продукте, с указанием ожидаемого результата.

Представьте, что продукт уже готов. Как бы стали его проверять? Опишите этот алгоритм проверки.

Описание объемных задач часто вызывает затруднение даже у опытных постановщиков. Мысли путаются, перескакивают с одной темы на другую, в голове хаотично всплывают нюансы и пищат: «Про меня не забудь! Не забудь! Не забудь!» А написать нужно последовательно и понятно. Как же обуздать хаос мыслей и построить их в правильные ряды и шеренги?

Довольно просто: садитесь и начинайте писать. Начните «крупными мазками» записывать роящиеся в голове мысли. Косноязычно, в любой последовательности, как придется. Если в процессе записи одной мысли всплывает другая и вы боитесь ее потерять, сделайте короткую заметку в конце документа.

В итоге наступит момент, когда вы поймете, что мысли и идеи так или иначе уже зафиксированы в тексте. И вот тогда начинайте приводить написанное в порядок: выстраивать в нужную структуру, переписывать «красиво», дополнять деталями.

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

Из этой позиции оцените свой документ: будет ли вам понятно, что в нем изложено.

Составление технического задания — это не такое уж и страшное занятие. Если вы профессионал в своем деле, то вы уже знаете, что именно вам нужно от разработки. И если вы понимаете свои потребности, то вам будет легко их описать. Хотя, честно говоря, написание ТЗ — это не такое уж легкое занятие. Но справиться с ним вам вполне по силам.

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