Типичная сцена. Заказчик в двух предложениях описывает разработчику, что хочет: «Нужна программа учёта клиентов, ну вы поняли, как обычно». Разработчик кивает, уходит на месяц и приносит то, что понял по-своему. А понял он, естественно, не то, что было в голове у заказчика, потому что в голове было одно, а на словах прозвучало совсем другое. Дальше начинается знакомое: «я не это имел в виду», «но вы же сказали», переделки, испорченное настроение и спор о том, кто кому теперь должен.
Корень почти всех таких историй один — отсутствие нормального технического задания. Кажется, что ТЗ это бюрократия, которая только тормозит, и проще «на словах». Но именно эти сэкономленные на старте полчаса оборачиваются неделями переделок потом. Разберём, что должно быть в ТЗ на разработку ПО, как его составить, не будучи программистом, и почему внятное задание выгодно не только заказчику, но и исполнителю.
Эта статья — опорная в разделе про разработку. Смежные темы: сколько стоит разработка, из каких этапов она состоит, как принять готовый результат.
Что вы узнаете из статьи
- Почему «объяснить на словах» почти всегда заканчивается переделкой
- Какие разделы обязательно должны быть в любом ТЗ
- Как описывать функции так, чтобы их нельзя было понять двояко
- Почему хорошее ТЗ защищает не только заказчика, но и исполнителя
- Как менять задание по ходу, не разрушая проект
Почему без ТЗ проект почти обречён на переделку
Представьте, что вы заказываете мебель и говорите мастеру: «Сделайте мне хороший шкаф». Хороший — это какой? Сколько полок, какой высоты, под одежду или под книги, белый или под дерево? Мастер сделает шкаф по своим представлениям о хорошем, и с вероятностью почти стопроцентной это будет не ваш шкаф. С программой ровно та же логика, только последствия дороже, потому что переделать готовый код иногда сложнее, чем переставить полку.
Главная беда устных договорённостей даже не в том, что разработчик понимает по-своему. Она в том, что через месяц обе стороны помнят разговор по-разному, и каждый абсолютно искренне уверен в своей версии. Заказчик помнит, что просил то-то. Исполнитель помнит, что про это речи не было. Доказать ничего нельзя, потому что доказывать нечем — был только разговор. ТЗ превращает зыбкие воспоминания в зафиксированный факт, на который можно сослаться.
Есть и более тонкая проблема. Пока требования не записаны, заказчик и сам толком не знает, чего хочет — мысль формируется в процессе. И это нормально. Но если она не формируется до начала работы, то будет формироваться во время неё, силами разработчика и за счёт переделок. Письменное ТЗ заставляет додумать задачу заранее, на берегу, когда менять что-то ещё ничего не стоит.
Что обязательно должно быть в ТЗ
Хорошее ТЗ не обязано быть толстым. Оно обязано быть однозначным. Есть несколько разделов, без которых задание не работает, и они одинаковы хоть для маленького скрипта, хоть для большой системы.
Задача и пользователи. Самое начало — зачем вообще нужна эта программа и кто ею будет пользоваться. Не «сделать сайт», а «сделать так, чтобы менеджер за минуту находил клиента по телефону и видел историю его заказов». Когда понятна задача, разработчику ясна не только буква требований, но и их смысл, а это спасает в тысяче мелких ситуаций, где буква молчит.
Список функций. Сердце ТЗ. Перечислите всё, что программа должна уметь, и по каждому пункту опишите, как именно это работает. Не «авторизация», а «пользователь вводит почту и пароль, при неверном пароле видит понятную ошибку, может восстановить доступ по почте». Чем подробнее описана функция, тем меньше места для «я думал, это работает иначе».
Что считается готовым. Критерии приёмки — раздел, который чаще всего забывают, а он бесценен. Как вы поймёте, что функция сделана? Что должно произойти, чтобы вы сказали «принято»? Без этого финал проекта превращается в спор о том, готово оно или нет.
Сроки, этапы и формат сдачи. Когда какой кусок должен быть готов, как разбита работа на этапы и в каком виде вы получите результат — файлы, доступ к серверу, исходный код. Эти вещи кажутся очевидными ровно до того момента, когда из-за них возникает конфликт.
Как описывать требования, чтобы их не поняли двояко
Главный враг хорошего ТЗ — расплывчатые слова, которые каждый понимает по-своему. «Удобный интерфейс», «быстрая работа», «современный дизайн» — это не требования, а пожелания, под которые невозможно ничего проверить. Удобный для кого? Быстрая — это сколько секунд? Современный по чьим меркам? Если требование нельзя проверить, его как будто и нет.
Приём, который сразу всё чинит: формулируйте через действия и измеримые вещи. Вместо «быстрый поиск» — «результат поиска появляется не дольше двух секунд». Вместо «удобная форма» — «форма из таких-то полей, после отправки показывает подтверждение». Хорошая проверка любой формулировки: можно ли по ней через месяц однозначно сказать, выполнено или нет. Если можно — формулировка рабочая.
Ещё один полезный навык — описывать не только нормальный сценарий, но и что происходит, когда что-то идёт не так. Пользователь ввёл неверные данные — что он видит? Связь с интернетом пропала — что делает программа? Именно эти пограничные случаи разработчики и заказчики чаще всего понимают по-разному, и именно из-за них потом спорят. И раз уж речь зашла про объём работы — то, насколько детально проработано ТЗ, напрямую влияет на то, сколько стоит разработка, потому что туманное задание исполнитель закладывает в цену как риск.
Почему ТЗ защищает и исполнителя тоже
Есть устойчивый миф, что ТЗ нужно заказчику, а исполнителю оно как кандалы — связывает руки. На самом деле грамотного исполнителя ничто так не защищает, как чёткое задание. Без него разработчик беззащитен перед бесконечным «а добавь ещё вот это по-быстрому». Каждое такое «по-быстрому» съедает время, которое никто не оплачивает, а отказать неловко — вроде мелочь. Сумма этих мелочей и есть та причина, по которой исполнители выгорают и работают в убыток.
Когда объём зафиксирован в ТЗ, всё становится честным. Что в задании — делается в рамках договорённости. Что сверх — это новая работа с новой оценкой по времени и деньгам, и это уже не наглость со стороны исполнителя, а нормальная практика, на которую можно сослаться. ТЗ превращает скользкие переговоры в спокойный разговор по документу.
Поэтому опытные разработчики сами просят ТЗ и сами помогают его составить — не из любви к бумагам, а потому что выученный на горьком опыте знают: проект без задания почти всегда заканчивается конфликтом, в котором крайним оказывается исполнитель.
Как менять ТЗ по ходу и не сломать проект
Жизнь сложнее любого плана, и по ходу разработки почти всегда всплывают новые идеи и обнаруживаются недодуманные места. Это нормально и не значит, что ТЗ было плохим. Плохо не менять задание, а менять его неуправляемо — устно, по мелочи, не отслеживая, как это копится.
Здоровый подход простой. Любое изменение фиксируется письменно, пусть это будет короткое сообщение в переписке. И сразу обсуждается, как оно влияет на сроки и стоимость. Иногда правка бесплатна и быстра, иногда тянет за собой переделку половины — заказчик имеет право знать это заранее, до того как согласится. Тогда не возникает ситуации, когда «пара мелочей» внезапно сдвинула сдачу на две недели, а почему — непонятно.
Дальше работа двигается по согласованному заданию через этапы разработки, а в конце вы спокойно принять результат разработки, сверяя готовое именно с тем, что записано в ТЗ. Когда есть с чем сверять, приёмка перестаёт быть спором на ощущениях и становится понятной проверкой по списку.
Как платформа помогает зафиксировать договорённости
На Где.Эксперт исполнителя выбирают по реальным отзывам и истории выполненных заказов — видно, кто привык работать по чёткому заданию, а не «как пойдёт», и у кого в прошлом не было историй со спорами о переделках. Это сразу отсекает тех, кто берётся без ТЗ и потом удивляется претензиям.
Задачу можно обсудить до старта: специалист поможет превратить ваше описание «что нужно» в нормальное техническое задание, подскажет, что реально, а что нет, и назовёт честную оценку под зафиксированный объём. Оплата идёт по факту выполнения этапов, а зафиксированные договорённости работают страховкой для обеих сторон — и для заказчика, который получит заказанное, и для исполнителя, защищённого от бесконечных дополнений.
Часто задаваемые вопросы
Зачем нужно ТЗ, если можно объяснить на словах?
На словах через месяц никто не вспомнит, о чём договаривались, а разработчик понял по-своему. ТЗ фиксирует, что делаем и что считается готовым, и защищает обе стороны от споров.
Кто должен писать ТЗ?
Лучше вместе: заказчик описывает задачу на своём языке, разработчик переводит в требования. Если пишет одна сторона — вторая обязательно читает и подтверждает, что там именно то, что нужно.
Что обязательно в ТЗ?
Задача и пользователи, список функций с описанием работы, критерии готовности, сроки и этапы, формат сдачи. Чем точнее функции и критерии, тем меньше разночтений.
Можно ли менять ТЗ в процессе?
Можно и часто нужно, но осознанно: фиксировать письменно и обсуждать влияние на сроки и цену. Плохо — добавлять устно «по мелочи», накапливая невидимый объём.
Насколько подробным должно быть ТЗ?
Достаточно, чтобы посторонний разработчик понял задачу без устных пояснений и мог проверить результат. Для маленького проекта — пара страниц, для крупного — разделы и схемы.
Заключение
Техническое задание выглядит как лишняя бюрократия ровно до первого проекта, сделанного без него. Полчаса, сэкономленные на старте, превращаются в недели переделок, испорченные отношения и спор, в котором обе стороны искренне правы, потому что доказывать нечем — был только разговор.
Грамотный заказчик не жалеет времени на то, чтобы записать: какую задачу решаем, какие функции нужны, как они работают и что считается готовым. Это защищает и его — он получит заказанное, а не додуманное, — и исполнителя, у которого зафиксирован объём и который огорожен от бесконечного «добавь по-быстрому». А когда хочется работать с тем, кто привык к чёткому заданию и не превращает приёмку в спор, проще выбирать по отзывам и истории сданных проектов.
Найдите разработчика на Где.Эксперт — фиксируйте задание до старта, обсуждайте объём заранее и платите по факту выполнения.