«Мы не пишем ТЗ, — гордо сказал мне руководитель агентства. — Мы работаем только по Agile». Хочется порассуждать на тему того, нужно ли в 2026 году писать техническое задание на разработку информационного продукта и в каком виде. Или это все замшелые водопадные технологии, которые уже давно прогрессивным разработчикам и вайбкодерам никуда не уперлись.

Вообще, сам термин «техническое задание» для разработки в последнее время стал встречаться реже — и в обсуждениях и в профильных статьях. Чаще его заменяют словом «требования» (reqirements) или Product vision и это действительно ближе к истине — в таком документе мы фиксируем требования заказчика и видение того, каким должен быть создаваемый продукт, что он должен уметь и как выглядеть. Вне зависимости от подхода к разработке такой документ на старте проекта должен быть обязательно, и при этом быть хорошо проработанным — хотя бы для создания MVP. Потому что и у заказчика проекта и у его разработчика перед глазами должен быть так сказать единый «образ победы» — того продукта, который они совместными усилиями делают. Без такого документа вы не сможете ни бюджет спрогнозировать даже примерно, ни сроки готовности, да и функционал самого продукта может в итоге оказаться совсем не таким, как его представлял себе заказчик. Сколько раз приходилось наблюдать ситуацию, когда не только отдельные фичи, но даже использованные в постановке задачи термины понимались сторонами по‑разному, что приводило к спорам на приемке очередного этапа работ. Поэтому кстати, считаю раздел с терминами обязательным и всегда включаю его в свою документацию — чтобы у всех было единое понимание того, что такое «Заказ», из чего состоит «Заявка», кто такой «Администратор» и тому подобное

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

Для начала представлюсь — меня зовут Роман, я аналитик и проджект разработки информационных систем, в основном с веб‑интерфейсом. Занимаюсь этим делом давно, и понятно что сдавать проекты различной крупности приходилось неоднократно. Но рассказать хочется об одной недавней разработке, когда на этапе сдачи выплыло особенно много незапланированных изначально вещей, что сделало ее (сдачу) особенно длинной и болезненной. Надеюсь, что пытливый читатель возьмет этот опыт на вооружение и хотя бы продумает пути завершения проекта заранее.