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