Как создать ТЗ (техническое задание) на программу или сайт

Так как помимо основной работы я довольно часто занимаюсь созданием сайтов и программ на заказ, то приходится общаться с заказчиками. Большинство встреченных мной заказчиков не имеют ТЗ, вот для них я и решил набросать эту заметку.

Некоторые пункты могут отсутствовать в вашем задании, рассматривайте его как ознакомление, некий образец. Дальше я буду употреблять термин «приложение» - это универсальный термин, под приложением будет пониматься как и программа для декстопа, так и сайт, так и апи, так и сервис и тд.

Письменный вид

Начнем с того, что все должно быть в письменном виде. При общение голосом сложно будет зафиксировать список пунктов, да и как потом возвращаться и снова разбирать? Голосом можно обсудить саму концепцию и (если будут иметься) пожелания, небольшие доработки, а все остальное - только документы.

Формат документа любой – вплоть до обычного текстового файла. Но если проект предполагается делать не одну неделю, то лучше использовать какой-то сервис, позволяющий редактировать данные совместно. Гугл таблицы или, что лучше – трелло.

Графический интерфейс



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

В макете нарисованы все кнопочки, формы, вид и взаимное расположение всех элементов. Прописана анимация. Именно оттуда верстальщик (в случае сайта) берет размеры, номер цвета и всю необходимую информацию для создания верстки.

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

Да, да, рисунок в том же фотошопе, любом графическом редакторе или даже от руки.

Функции

Это то, что скрывается внутри, под графическим интерфейсом. Либо же то, что должно выполнять приложение. Для программы или сайта это может быть как список основных процессов, так и то, что происходит по нажатию каждой кнопочки.

Обычно, когда есть набросок внешнего вида, то почти все понятно по названиям кнопок. Да и проекты часто заимствуют у друг друга функции, так что тут иногда мало приходится расписывать. Например, если это программа по управлению базой данных, то в ней имеется кнопка «Добавить» - понятно, что надо добавить сущность. Или кнопка «Сохранить в файл» - понятно, что надо отобразить окно проводника и предоставить пользователю возможность сохранить себе файл.

Но все же этот этап очень важен, а в нем часто имеются многие очевидные моменты для заказчика, но не для меня (для исполнителя). Например, то же сохранение отчета в файл - в каком формате? Если заказчик говорит, что для экселя, то опять же уточняем версию и формат файла – csv там например.

Такие моменты требуют обсуждения, не стоит пренебрегать ими.

Обработка ошибок и перфекционизм

При разработке любого приложения всегда имеет место компромисс. Например, без прямого указания заказчика я не тестирую свои сайты на всех браузерах – я понятия не имею, как они будут выглядеть на IE 9 например.

Или если работа идет над программой, принимающей какие-то данные, то по умолчанию мы предполагаем, что эти данные всегда будут в таком формате. Естественно, что основную обработку ошибок я реализую – например, если не удалось скачать файл, но вот что внутри – нередко по умолчанию предполагаем, что этот файл имеет постоянную структуру.

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

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

Итоги

В заключение скажу, что я могу работать и без ТЗ. Совсем без него. В этом случае вы просто оплачиваете мне почасовую работу. Мы вместе будем разбираться в том, что вы хотите (нередко заказчики сами не до конца представляют того, что хотят), вместе набросаем интерфейс, функции, выберем кмс, даже обсудим возможность продвижения – но это все в рамках оплачиваемого времени.

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