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