Типичная история провального заказа на 1С выглядит так. Заказчик пишет программисту: «Нужно, чтобы отчёт по продажам считался правильно». Программист понимающе кивает, берёт деньги, делает. Через неделю заказчик смотрит результат и говорит: «Это не то, я имел в виду совсем другое». Начинается спор, переделки за свой счёт, испорченные отношения. А корень один: «правильно» и «другое» — это не задача, это ощущение. Никто не написал, что именно должно получиться.
В 2026 году большинство конфликтов между заказчиками и программистами 1С возникает не из-за низкой квалификации, а из-за того, что стороны по-разному поняли задачу. И лечится это не выбором гениального исполнителя, а одним документом — техническим заданием. Хорошее ТЗ не про бюрократию, оно про то, чтобы вы и мастер видели один и тот же результат до того, как потрачены деньги. Разберём, что в нём должно быть, какими словами это описывать и как зафиксировать приёмку, чтобы потом не спорить о вкусах.
Эта статья — практическая в разделе про доработку 1С. Смежные темы: как принять готовую работу, как оценить её стоимость, как выбрать между доработкой типовой и нетиповым решением.
Что вы узнаете из статьи
- Почему без ТЗ срывается даже простая доработка
- Что обязательно описать, чтобы исполнитель понял вас правильно
- Какими формулировками говорить о задаче на языке бизнеса
- Как приложить примеры, по которым легко проверить результат
- Как зафиксировать критерии приёмки и сроки
Почему без ТЗ проекты срываются
Беда устной постановки в том, что каждый достраивает картину в своей голове. Вы говорите «нужна скидка постоянным клиентам» и видите конкретную таблицу с порогами и процентами, которую держите в уме. Программист слышит ту же фразу и представляет совсем другую механику — может быть, флаг «постоянный» и фиксированные 5%. Оба уверены, что поняли друг друга, и оба правы внутри своей версии. Расхождение всплывает только на сдаче, когда переделывать дорого и обидно.
ТЗ убивает эту неоднозначность в зародыше. Оно превращает «нужна правильная скидка» в проверяемое описание: при каком условии, какой процент, на какие товары, как округлять, что показывать в чеке. После такого документа исполнителю просто нечего домысливать — задача описана так, что двух прочтений не остаётся. И заодно ТЗ помогает на развилке доработать типовую или заказать нетиповое: когда задача выписана подробно, сразу видно, тянет она на пару правок или на большой проект.
Ещё ТЗ защищает обе стороны юридически и по деньгам. Для заказчика это гарантия, что он получит описанное, а не «как понял мастер». Для исполнителя — защита от бесконечных «а ещё добавьте вот это» под видом той же задачи. Когда границы зафиксированы на бумаге, новые хотелки честно становятся новой оплачиваемой работой, а не поводом для конфликта.
Что обязательно включить: чек-лист
Рабочее ТЗ на доработку 1С держится на нескольких обязательных блоках. Первый — точная среда: какая конфигурация и какой релиз, типовая она или уже дорабатывалась, какая платформа. Без этого исполнитель не знает, во что вмешивается, а заодно не может честно оценить стоимость доработки. Одна строчка «УТ 11.5, типовая, доработок не было» экономит часы выяснений.
Второй блок — текущее и желаемое поведение. Опишите, как программа работает сейчас и как должна работать после. Не «исправьте отчёт», а «сейчас отчёт суммирует все продажи подряд, нужно, чтобы он группировал по менеджерам и считал процент выполнения плана по каждому». Третий блок — формат результата: это новый отчёт, печатная форма, дополнительное поле в документе, обмен с внешней системой? Чем конкретнее, тем меньше места для разночтений.
Четвёртый и, пожалуй, самый ценный блок — примеры на реальных данных. Возьмите три-четыре конкретных случая с числами: «у клиента Иванова оборот за квартал 480 000 ₽, значит скидка 7%, итог по позиции с ценой 1000 ₽ — 930 ₽». Такие примеры стоят десяти абзацев описания: программист сразу видит логику, а вы получаете готовый материал для приёмки. Пятый блок — сроки и критерии готовности, о них ниже. Удобно оформить всё это списком пунктов, чтобы ничего не потерялось и каждый пункт можно было отметить как выполненный.
Как описывать задачу на языке бизнеса
Главное правило заказчика: вы описываете что и зачем, а не как. Ваша территория — бизнес-логика и цель, территория программиста — код и реализация. Не нужно писать «добавьте регистр накопления» или «измените процедуру проведения» — это не ваша работа, и попытки говорить на чужом языке чаще вредят, чем помогают. Пишите от результата: «директор хочет видеть в одном отчёте, кто из менеджеров не выполнил план, чтобы говорить с ними предметно».
Хорошее описание всегда отвечает на вопрос «как мы поймём, что получилось». Поэтому избегайте оценочных слов вроде «удобно», «быстро», «нормально» — они у каждого свои. Заменяйте их на проверяемые факты: вместо «отчёт должен быстро открываться» — «отчёт по 10 000 строк формируется не дольше 5 секунд». Вместо «удобная печатная форма» — «на одном листе А4, с логотипом сверху и подписью директора снизу». Конкретика — лучший враг будущих споров.
Не бойтесь показаться слишком дотошным. В мире доработок 1С избыток деталей почти никогда не вредит, а вот их нехватка стабильно оборачивается переделками. Если сомневаетесь, добавлять ли подробность, — добавляйте. Лишнюю строчку программист просто примет к сведению, а недостающую он домыслит по-своему, и не факт, что так, как вы хотели.
Как зафиксировать приёмку и сроки
Критерии приёмки — это место, где ТЗ превращается из описания в инструмент. Сформулируйте их как проверяемые сценарии: при таких входных данных программа должна выдать такой результат. Лучше всего переиспользовать те самые примеры из блока с данными — они уже описаны, остаётся договориться, что после сдачи вы прогоните именно их. Совпало с ожидаемым — принято, не совпало — возвращается на доработку. Никаких споров о вкусах, только сверка с числами. Подробно сам процесс проверки разобран в материале про приёмку работы по 1С.
Со сроками работает та же логика конкретности. Вместо «сделайте поскорее» — дата готовности и, если задача большая, разбивка на этапы с промежуточными результатами. Полезно сразу прописать гарантийный период: сколько времени после сдачи исполнитель бесплатно правит баги, не связанные с вашими новыми хотелками. Стандартная практика — от двух недель до пары месяцев. Эта строчка избавляет от неловких разговоров, когда через неделю после сдачи вылезает ошибка.
Отдельно зафиксируйте, что считается выходом за рамки. Если в процессе у вас появятся новые идеи — а они появятся, — пусть в ТЗ заранее будет написано, что это отдельная задача с отдельной оценкой. Так вы не загоните исполнителя в бесконечную бесплатную доработку, а себя — в ощущение, что «обещали же сделать». Чёткая граница выгодна обоим.
Как платформа помогает с постановкой задачи
На Где.Эксперт программиста 1С выбирают по реальным отзывам и истории заказов — видно, кто умеет не просто кодить, а грамотно собирать требования и оформлять задачу так, что потом нет споров. Многие специалисты сами помогают довести вашу идею до нормального ТЗ ещё на этапе консультации.
Это снимает главную тревогу заказчика: что он опишет задачу криво, получит не то и потеряет деньги. Можно начать с обсуждения, на котором мастер задаст правильные вопросы и переведёт ваш рассказ в проверяемую постановку с примерами и критериями приёмки. Оплата идёт по факту выполнения, без депозитов, а отзывы прошлых клиентов показывают, кто действительно умеет слышать заказчика, а не делать «как понял».
Часто задаваемые вопросы
Обязательно ли ТЗ для маленькой доработки?
Для правки в час-два хватит понятного описания в переписке. Как только задача сложнее одного действия — отчёт, обмен, изменение проведения, — ТЗ окупается: вы и исполнитель одинаково видите результат.
Что обязательно должно быть в ТЗ?
Конфигурация и релиз, текущее и желаемое поведение, конкретные примеры с числами, формат результата, критерии приёмки и сроки. Главное — что должно получиться, а не как это запрограммировать.
Нужно ли разбираться в программировании?
Нет. ТЗ описывает задачу на языке бизнеса. Ваша зона — что и зачем, на примерах. Как реализовать в коде — придумает программист.
Кто пишет ТЗ?
Лучше вместе: заказчик описывает задачу и примеры, программист оформляет техническую постановку и согласовывает. Главное, чтобы документ устраивал обе стороны до старта.
Как зафиксировать приёмку?
Через проверяемые сценарии: при таких данных — такой результат. Приложите 2–3 примера с числами. Тогда приёмка — это сверка, а не спор о вкусах.
Заключение
Техническое задание — самый дешёвый способ застраховать проект по доработке 1С от провала. Оно не требует от вас знания кода: ваша работа — описать на языке бизнеса, что должно происходить и зачем, и подкрепить это конкретными примерами с числами. Всё остальное — забота программиста. Один аккуратный документ экономит недели переделок и спасает отношения с исполнителем.
Соберите ТЗ по простому чек-листу: среда и релиз, текущее и желаемое поведение, формат результата, примеры на реальных данных, критерии приёмки и сроки. Замените все «удобно» и «быстро» на проверяемые факты, заранее договоритесь, что считается выходом за рамки, — и приёмка превратится из спора в спокойную сверку с ожидаемым.
Найдите программиста 1С на Где.Эксперт — обсудите задачу на консультации, согласуйте ТЗ и платите по факту выполнения, без депозитов.