В мире разработки принято считать: чем подробнее техническое задание, тем надёжнее проект. Мол, написали всё заранее, согласовали, подписали, потом просто берёшь и реализуешь – как по инструкции. И если что-то пошло не так, всегда можно ткнуть пальцем: «В ТЗ не было!»
Но с опытом приходит осознание: подробное ТЗ не гарантирует успеха. Более того, в некоторых случаях оно прямо вредит проекту – отнимает время, мешает гибкости, парализует команду и становится чем-то, что существует само по себе, а не ради результата.
Особенно остро это ощущается в проектах на 1С. Мы не пишем ERP с нуля – мы меняем и адаптируем уже живую систему под бизнес. А бизнес, как известно, меняется быстрее, чем согласовывается документ на 80 страниц. В итоге разработчик работает «по старому ТЗ» в «уже новом мире».
В этой статье мы разберём:
- Когда и почему большое ТЗ становится тормозом;
- Как отличить вредный формализм от полезного уточнения;
- Какие альтернативы работают в реальных 1С-проектах.
«Мы всё описали» – иллюзия полного охвата
Разработчики 1С нередко сталкиваются с проектами, в которых перед стартом заказчик требует «полное и финальное ТЗ». Не «драфт», не «описание ожиданий», а именно то, что якобы охватывает всё. Включая каждую галочку, каждый параметр формы, все сценарии ошибок и даже формулировку подсказок на кнопках.
Обычно такое ТЗ выглядит впечатляюще: 40–80 страниц, таблицы, схемы, шапки с утверждениями. И внушает ощущение «серьёзности». Но за этой серьёзностью скрывается одна большая ложь: будто бы всё уже известно.
Почему так не бывает
- Бизнес не стоит на месте. К моменту, когда вы дочитали страницу 80, в компании уже что-то поменялось. Новый поставщик, другое налогообложение, увольнение бухгалтера, интеграция с новой системой – всё это делает вчерашнее ТЗ неактуальным.
- Пользователи не читают ТЗ. Тот, кто писал, – не тот, кто будет работать в системе. А значит, требования в ТЗ – это проекции ожиданий менеджеров, а не реальное поведение операторов, логистов, кассиров. Появляется разрыв между бумагой и практикой.
- Разработчик превращается в машиниста. Он больше не мыслит, не проектирует – он «выполняет инструкции». А инструкции написаны людьми, которые, возможно, не понимают ограничений платформы, принципов транзакционности или даже базовых архитектурных подходов в 1С.
Пример из практики
Проект по автоматизации учёта договоров. ТЗ – 63 страницы. Подробно расписано всё, включая подписи «Ответственный за ввод», «Генерация печатной формы», «Контроль сроков по цвету строк». По итогу:
- Внедрение затянулось на 4 месяца дольше;
- Заказчик потерял интерес к функциональности, которую сам же утвердил;
- 70% поправок вносились вопреки ТЗ, по срочным звонкам и чатикам.
Разработчики оказались в ловушке: если делать по ТЗ – плохо, если не по ТЗ – «нарушение регламента».
Неживое описание живых процессов
Часто ТЗ превращается в формальный пересказ интерфейсов 1С:
«На форме документа "ПоступлениеТоваров" расположить кнопку "ЗаполнитьПоПоставщику", которая вызывает обработку "ЗаполнениеПрайсом"…»
Но такие требования никак не объясняют:
- зачем эта кнопка,
- какую боль решает пользователь,
- что будет, если кнопка сломается или не даст нужного результата.
ТЗ описывает «что», но не объясняет «почему». Разработчик программирует вслепую, а заказчик в итоге получает не тот результат, что ожидал, хотя формально всё «по ТЗ».
Противоречия и забытые моменты
Объёмные ТЗ почти всегда содержат внутренние конфликты:
- В одной части говорится «не показывать цены пользователю», в другой – «дать возможность изменить цену вручную».
- Табличная часть описана без учёта валют, а позже появляются требования по мультивалютному учёту.
Бумажный монстр растёт, его никто уже полностью не читает. В итоге все работают по памяти, создаются «серые зоны», где исполнитель действует на своё усмотрение, а заказчик потом возмущён: «Я же думал, что будет по-другому!»
Прокрастинация вместо запуска
Чем толще ТЗ – тем больше поводов не начинать. Согласование формулировок, уточнение бизнес-правил, проверка каждой запятой. Иногда месяцами крутятся только правки по ТЗ, без единой строки кода.
Парадоксально, но избыточно формализованное ТЗ может откладывать реальный запуск на 3–6 месяцев, в то время как MVP с активной обратной связью был бы готов за 3 недели.
Когда разработка умирает в «подписанном» виде
Самый трагичный финал: ТЗ завершено, согласовано, проект стартует… и быстро застревает.
- Команда боится отходить от буквы документа.
- Пользователи злятся: «Сделали фигню».
- Бюджет исчерпан, результат не работает.
В итоге: все в минусе, а формально никто не нарушил ТЗ. Бумажный монстр победил.
Почему «идеальное ТЗ» – это миф
1. Разработчик 1С – не фрезеровщик
Во многих организациях ТЗ пишется так, будто разработчик – это исполнитель с завязанными глазами, который будет действовать строго по инструкции, не зная контекста. Такой подход работает в условиях серийного производства: в цехе, где болт должен быть ровно 12 мм, с допуском ±0,1 мм.
Но 1С-разработка – это живая, интерактивная среда. В ней каждое внедрение уникально: в одной компании контрагенты – физлица, в другой – юрлица с тысячами договоров. Даже одинаковые конфигурации ведут себя по-разному, потому что зависят от настроек, шаблонов, справочников, прав доступа и привычек пользователей. Любая попытка описать это в ТЗ – заведомо проигрышна: не хватит ни страниц, ни времени.
2. Чем толще документ – тем тоньше внимание
Когда ТЗ становится слишком объёмным (30, 50, 80 страниц), его перестают читать. Заказчик – потому что устал, исполнитель – потому что не верит в актуальность, а аналитик – потому что занят написанием следующей версии. В итоге документ теряет своё основное назначение – быть средством коммуникации.
И даже если прочитают – восприятие будет искажено: разработчик воспримет ТЗ как инструкцию к действию, заказчик – как договор с гарантиями, а аналитик – как ритуал передачи ответственности. Но всё это не работает в динамике реального проекта.
3. Противоречия внутри ТЗ
Особенность 1С – это тесное переплетение модулей: одна кнопка может делать запись в регистр, заполнять 2 таблицы и влиять на отчёт. Поэтому даже небольшие изменения могут приводить к конфликтам.
В толстом ТЗ почти неизбежны противоречия:
- в начале написано, что пользователь не может редактировать документ после проведения;
- в середине – что он может менять ответственного;
- в конце – что при любом изменении должна запускаться перепроводка.
Эти вещи не могут сосуществовать, но пока их не реализуют, никто не заметит. А когда реализуют – виноват будет разработчик, потому что «не так понял».
4. Реальность важнее теории
Многие ТЗ создаются «на будущее» – описывают редкие случаи, которые могут никогда не произойти. При этом не описываются очевидные повседневные действия: например, что делать, если пользователь забыл выбрать дату, или нужно внести данные задним числом.
В 1С именно эти нюансы важнее всего: потому что они проявляются сразу при сдаче. Живое общение и быстрые итерации решают такие ситуации куда эффективнее, чем заранее написанная конструкция.
Как выйти из ловушек бумажного монстра и остаться живым
Итак, вы поймали себя или заказчика на мысли: «У нас есть документ на 80 страниц, но реальной ясности – как у трёхстрочного мемо». Важно понять: из ТЗ-ловушки невозможно выбраться с помощью ещё одного ТЗ. Нужен сдвиг в методе работы, особенно в мире 1С, где реальность всегда выходит за пределы описания.
Вот рабочие стратегии, проверенные на практике:
1. Начинаем с MVP – в 1С это особенно уместно
Минимально жизнеспособный продукт (Minimum Viable Product) звучит как термин из стартапов, но в 1С-проектах он имеет свою уникальную трактовку. Это:
- простая обработка или документ, покрывающий 70% ежедневных операций;
- макет интерфейса, собранный из готовых компонентов 1С (регистр, форма, отчёт);
- быстрый прототип, на котором можно показать работу, а не описывать словами.
Пример: вместо «подробного ТЗ по расчёту бонусов», – быстрое добавление ручной таблицы бонусов в реализацию + флажок «проверено». А потом наблюдаем, что не устраивает пользователей.
2. Используем «живое ТЗ» – документы-черновики в 1С
Вместо красивых PDF – документы Google Docs, скриншоты с пояснениями, тестовые базы с пометками. Такие материалы:
- меняются на лету;
- видимы всем (аналитик, программист, заказчик);
- формируются вместе с разработкой, а не заранее.
3. Прототип – как старт диалога, а не конец разработки
Одна из ошибок – думать, что показ прототипа = финальная стадия. Наоборот, первый прототип – способ вызвать вопросы:
- «А как это будет работать с розницей?»
- «А если документ не проведён?»
- «А кто это будет заполнять?»
Очень удобно показывать «недоделанный» интерфейс – чтобы не боялись критиковать. Это не слабость, а метод: черновик вызывает реальное обсуждение, а не молчаливое согласие с фантазией из ТЗ.
4. Подключаем пользователя на раннем этапе
Как только появляется первый работающий кусок (хоть одна кнопка), даем пощупать его реальному пользователю.
Это резко:
- снижает конфликтность – пользователь чувствует, что влияет;
- сокращает срок внедрения – нет эффекта «что вы нам тут понаделали»;
- выявляет скрытые потребности – то, чего в ТЗ вообще не было.
Важно: пользователь не обязан читать ТЗ, но обязан реагировать на реальные формы и отчёты.
5. Контроль не через документы, а через сценарии
Замените контроль «по бумаге» на контроль по жизненным сценариям:
- Что происходит, когда опоздала отгрузка?
- Как менеджер узнаёт, что не хватает остатков?
- Где можно проверить, что бонус рассчитан корректно?
Такие сценарии проверяются на живой базе. Именно они – настоящая проверка реализации. ТЗ может быть идеально оформленным, но бесполезным, если не описывает реальных ситуаций.
6. Ретроспектива и документ-память
После завершения первой итерации создаётся не классическое ТЗ, а документ, описывающий:
- какие решения были приняты;
- что осталось «долгом»;
- какие компромиссы согласованы.
Это не «список требований», а интеллектуальная память проекта, которую можно обновлять и использовать в будущем. Их удобно хранить прямо в комментариях к задачам или в Wiki корпоративного портала.
Парадокс: самый живой результат – не из самого «правильного» ТЗ, а из самого честного взаимодействия. Формализм мимикрирует под профессионализм, но настоящая зрелость – это умение работать в условиях неопределённости, не теряя цели и уважения к участникам процесса.
Как перейти от ТЗ к живому процессу: практические шаги
Вы уже поняли: избыточное формальное ТЗ в проектах – не гарантия успеха, а зачастую причина провала. Но как не сорваться в противоположную крайность – полную анархию, «договаривайтесь на словах» и «а мы думали, вы сами додумаетесь»?
Здесь важно не выбросить логику проектирования вместе с «водой» формализма. Нужно перевести проект в режим живого процесса, в котором заказчик, аналитик и разработчик – это не три фазы, а три участника одной системы обмена смыслом.
1. Принцип «быстрой петли»: покажи – обсуди – уточни
Вместо того чтобы тратить недели на согласование 30-страничного ТЗ, лучше через 2–3 дня показать работающий прототип. Это может быть:
- макет отчёта в Excel;
- диаграмма в Figma или Draw.io;
- пустая форма 1С с парой кнопок;
- MVP на управляемых формах, который ещё «не работает, но уже видно».
Важно: в 1С это особенно просто – ведь 1С позволяет делать итерактивные изменения быстрее, чем во многих других системах. Используйте это как силу.
2. Диалоговая спецификация вместо монолога
ТЗ – это не документ, это договор. Лучше всего он живёт в совместной вики, Git-репозитории, трекере задач или хотя бы в Google Docs с комментариями. Формулировки пишутся не «с третьего раза, как надо», а проходят путь эволюции – обсуждаются, уточняются, привязываются к конкретным задачам.
Формат рабочей заметки гораздо полезнее, чем «канонический PDF». Если в задаче есть «описание бизнес-цели», «пример входных и выходных данных», «скриншот текущего интерфейса» и комментарий: «Вот здесь сомневаемся – нужно уточнить», – это уже мощнее 10 страниц заколдованного ТЗ.
3. Протокол вместо приказа
Переведите мышление из логики «утвердили» → «делаем» в логику «зафиксировали договорённость на текущий момент».
Для этого полезны еженедельные синхронизации, где вы не просто отчёт даёте, а возвращаетесь к требованиям:
- А это всё ещё нужно?
- Условия не поменялись?
- А вот это мы попробовали – не летит, может, пересоберём?
Так появляется настоящая обратная связь, и проект остаётся живым, даже если документация где-то не догнала.
4. Инструменты, которые работают в 1С-среде
Вот список подходящих инструментов и практик, проверенных на проектах 1С:
- Трекеры задач – вместо абстрактных требований работают конкретные задачи с комментариями.
- Живые формочки – ранние черновики форм, даже без логики, помогают обсудить экранные сценарии.
- Excel – если клиент мыслит таблицами, используйте Excel как прототип будущих форм/отчётов.
- Комментарии в коде – для фиксации решений и даже «невидимого ТЗ» прямо в модулях.
- Демонстрация экрана – показать, как работает или не работает – порой в 10 раз быстрее, чем объяснить письменно.
- Юнит-тесты и фиксация кейсов – на больших проектах (например, с ERP или БП) тест-кейсы часто заменяют многословное ТЗ: они фиксируют ожидания.
5. Принцип «жизненного цикла требования»
Любое требование не должно быть просто «написано» – оно должно пройти путь:
- Формулировка → Прототип/пример → Реализация → Обратная связь → Правка или отказ
ТЗ, которое невозможно переписать – это не ТЗ, а религия. В живом проекте любой пункт должен быть подвижен, пока не доказал свою состоятельность.
Финальные мысли
Раздутое ТЗ – это не техническая ошибка, а симптом страха. Бизнес боится, что его не поймут. Разработчик боится, что его обвинят. Менеджер боится, что проект рухнет.
Но медицина тут одна – открытый процесс, а не закрытый документ.
Живое взаимодействие, понятные смыслы, общее дело. Именно так можно заменить формальный контроль на осознанное доверие – и вместо бронзового ТЗ получить работающий результат.
