Сейчас в сфере ИТ очень много различных толкований такого важного документа, как ТЗ (Техническое задание). Каждый трактует и составляет его по своему. А между тем, есть государственный стандарт. История у ТЗ солидная: корни уходят ещё в советские ГОСТы. А в IT оно окончательно прижилось в 90–00‑е, когда стал популярен аутсорсинг. Проще говоря, когда организации начали заказывать разработку автоматизированных систем «на стороне». Но если отбросить пыль с ГОСТов, суть-то остаётся кристально понятной и нужной. Это же по сути просто договор на берегу. Назначение ТЗ именно в этом — зафиксировать фантазии заказчика и превратить их в чёткие границы, за которые нельзя выходить. Иначе проект разрастётся до бесконечности, а критерий приёмки «ну, я так примерно и хотел» — это не критерий, а путь к конфликту. Самое сложное здесь — формулировки. Они должны быть как топор: чёткие и без двояких смыслов. Не «красивенький сайт», а «сайт выполнен в сине-белой гамме с круглыми кнопками». Не «быстрая загр