«Доработайте по-быстрому»: анатомия спора об объёме работ и как ТЗ спасает нервы

18.09.26

Управление проектом и продуктом - Оценка проекта

«Да там по мелочи, доработайте по-быстрому» — фраза, после которой через пару недель почти всегда начинается спор о деньгах. И самое неприятное в нём то, что обе стороны правы: заказчик правда думал про одну колонку, а исполнитель правда сделал всё, без чего эта колонка не работает. Разбираю на своём опыте, как этот спор устроен по шагам, почему «просто честно работать» его не предотвращает и как полстраницы текста до начала работы спасает и деньги, и клиента, и нервы. Без бюрократии на сорок страниц — и с честными оговорками о том, когда ТЗ не поможет вовсе.

Каждый, кто внедряет 1С, знает эту фразу. «Да там по мелочи, доработайте по-быстрому». Её говорят по телефону, в мессенджере между делом, иногда — в коридоре, когда ты уже уходишь. И почти всегда через пару недель начинается спор, в котором обе стороны искренне считают себя правыми и обиженными.

Я через это прошёл достаточно раз, чтобы перестать злиться и начать разбираться, как этот спор устроен. Потому что дело не в жадности заказчика и не в криворукости подрядчика. Дело в механике, которую можно предсказать — и обезвредить одной страницей текста.

Что на самом деле стоит за словом «по-быстрому»

Заказчик видит верхушку айсберга. «Добавьте колонку в отчёт». Для него это буквально одна колонка — что тут делать-то, полчаса.

А я в этот момент мысленно задаю себе десяток вопросов, которые он не задал. В какой из отчётов? Откуда берём данные — они вообще есть в базе или их надо начать где-то фиксировать? По какому разрезу считаем? А в печатную форму эта колонка тоже нужна? А в выгрузку в Excel? А права — её должны видеть все или только руководитель? А как это поведёт себя после ближайшего обновления, если отчёт типовой?

«Одна колонка» легко превращается в новый реквизит, его заполнение в трёх местах, доработку СКД, правку печатной формы и полдня тестирования. Не потому что я «раздуваю», а потому что колонка без данных — пустая, а данные сами себя не соберут.

Вот это расхождение — заказчик оценивает видимую часть, исполнитель обязан оценить всю — и есть корень спора. Всё остальное только следствие.

Как спор рождается по шагам

Сценарий почти всегда один и тот же.

Первое: устная договорённость «по-быстрому», без цифр. Никто не хочет казаться занудой, все на позитиве.

Второе: я делаю работу, и по ходу выясняется, что «колонка» тянет за собой ещё три вещи. Я их тоже делаю — не звонить же по каждому чиху, неудобно.

Третье: выставляю счёт, скажем, на 12 часов. Заказчик смотрит на него с искренним изумлением: «Мы же договаривались по-быстрому, я думал, это входит».

Четвёртое: и вот тут начинается самое неприятное. Оба правы. Он правда думал про одну колонку. Я правда сделал то, без чего колонка не работает. И доказать теперь нечего — договорённость была на словах, а слова у каждого свои.

Худшее в этом споре не деньги. Двенадцать часов по ставке — не та сумма, из-за которой стоит терять клиента. Худшее — что рушится доверие. Заказчик уходит с ощущением, что его развели. Я — с ощущением, что меня заставили работать бесплатно и ещё виноватым выставили. И дальше каждую следующую задачу мы обсуждаем уже как противники.

Почему «просто честно работать» не спасает

Долгое время я думал, что проблема решается порядочностью. Будь честным, не накручивай часы, объясняй — и всё будет хорошо.

Не будет. Честность не устраняет расхождение в оценке объёма, она его только вежливо обставляет. Я могу быть кристально честным и всё равно упереться в «а я думал, это входит», потому что у нас с заказчиком в головах два разных технических задания. У него — «одна колонка». У меня — «колонка плюс всё, без чего она мертва». Пока эти два ТЗ существуют только в головах, спор неизбежен. Их надо вытащить наружу и сверить. До работы, а не после.

ТЗ — это не бюрократия, это фиксация

Здесь многие спотыкаются, потому что при словах «техзадание» представляют сорокастраничный документ с разделами «Назначение системы» и «Термины и определения». Для мелкой доработки такое ТЗ — избыточная бюрократия, которую никто не будет писать, и правильно сделает.

Рабочее ТЗ на маленькую задачу — это полстраницы, иногда абзац в переписке, который вы явно обозначили как согласование. Мне достаточно зафиксировать пять вещей:

Что делаем — конкретно, с именами объектов. Не «доработать отчёт», а «в отчёт „Продажи по менеджерам“ добавить колонку „Маржа, %“, считается как…».

Что НЕ делаем — это пункт, который экономит больше всего нервов. «Печатная форма и выгрузка в этой задаче не меняются». Одна строчка, которая закрывает половину будущих «а я думал».

Откуда данные — если для доработки нужно, чтобы кто-то что-то начал вносить, это проговаривается сразу. Часто на этом пункте задача и разворачивается: выясняется, что данных нет и «быстро» не получится в принципе.

Сколько это стоит и в часах — вилка или фикс, но с числом. Даже грубая оценка «6–10 часов по 3 500 руб.» переводит разговор из «по-быстрому» в понятную плоскость.

Что считаем результатом — по какому признаку задача закрыта и принята.

Всё. Это не защита от заказчика — это защита обоих от собственной памяти. Через месяц вы оба помните разговор по-разному, а текст помнит одинаково.

Момент приёмки: где эта страница отрабатывает

Настоящая ценность ТЗ проявляется не когда всё идёт гладко, а именно в споре. Заказчик говорит: «Это должно было входить». Я открываю согласованный текст, где чёрным по белому — что входило и что нет. Дальше разговор идёт не про то, кто как понял, а про то, что написано. Это принципиально другой тон: не «ты меня обманул», а «смотрим документ».

И если выясняется, что нужное действительно за рамками — это не конфликт, а нормальное расширение: оформляем как отдельную задачу с отдельной оценкой. Заказчик платит спокойно, потому что видит, что это честно новая работа, а не «доработчик задним числом придумал».

Отдельно про поэтапные проекты: там ТЗ и акты по этапам — это вообще единственный способ не увязнуть. Пока предыдущий этап не принят и не оплачен, к следующему не переходим. Звучит жёстко, но именно это защищает и заказчика (он видит результат за свои деньги), и меня (я не тащу трёхмесячный проект в кредит доверия).

Честно: когда ТЗ не спасёт и когда оно лишнее

Не хочу продавать ТЗ как серебряную пулю.

Оно не спасёт, если заказчик изначально не собирается платить и ищет повод. Такому человеку хоть десять подписей соберите — он найдёт, к чему прицепиться. Но и тут ТЗ полезно: оно быстро проявляет таких людей ещё на этапе согласования, до того как вы вложили время.

И оно избыточно на совсем микроскопических правках в рамках абонентки или доверенных отношений, где счёт идёт на минуты и вы друг друга сто лет знаете. Заставлять постоянного клиента подписывать бумагу ради двадцатиминутной правки — это уже не порядок, а недоверие, и оно тоже портит отношения. Здоровье в балансе: чем крупнее и туманнее задача, тем нужнее фиксация; чем мельче и понятнее — тем спокойнее можно на словах.

Что я вынес

«Доработайте по-быстрому» — это не техническая просьба, это ловушка из разных ожиданий. Спор о деньгах, который она порождает, на самом деле почти никогда не про деньги. Он про то, что двое умных людей вложили в одну фразу два разных смысла и не сверились вовремя.

Полстраницы текста до начала работы стоят дешевле, чем один испорченный клиент. Я усвоил это не из книжек по проектному управлению, а из своих же счётов, которые пришлось списать, и из клиентов, которые ушли с обидой там, где мог бы остаться. Теперь у меня простое правило: если задача звучит как «по-быстрому» — именно её и надо зафиксировать письменно в первую очередь. Потому что «по-быстрому» — самое дорогое слово в нашей работе.

техническое задание ТЗ объём работ спор с заказчиком оценка трудозатрат доработка 1С приёмка работ работа с клиентами управление проектами ценообразование

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Внедрение изменений Оценка проекта Бесплатно (free)

Рассказываем, как подразделение из 75 человек с выручкой около 25 млн рублей в месяц встроило GenAI в подготовку проектной документации, разработку и тестирование и превратило эксперименты с ИИ в измеримый бизнес-эффект. Разбираем результаты: экономию около 320 человеко-часов в месяц на работе с документацией, сокращение одной итерации тестирования, ускорение выхода на SLA и дополнительную непроектную выручку. Показываем, как внедрять и масштабировать инструменты с минимальным CAPEX через вовлечение и нематериальную мотивацию команды, а также преодолевать сопротивление изменениям. Объясняем, почему не стоит усложнять промпт-инжиниринг, и делимся готовыми шаблонами промптов, системой метрик и принципами безопасной работы с данными в открытых нейросетях.

19.08.2026    419    18    ismirnof1991    0    

0

Взгляд со стороны Заказчика Оценка проекта Россия Бесплатно (free)

Похожую доработку уже выполняли за 40 часов, поэтому заказчик ожидал такой же оценки во второй раз. Но первый специалист давно знал проект, а второму пришлось начинать с изучения чужого кода и накопленных изменений. Разберём, что на самом деле находится внутри прошлого срока.

27.07.2026    394    0    NikolayMaerov    1    

3

Оценка проекта Управление рисками Бесплатно (free)

Разбираем, почему ERP-проекты не всегда идут по плану и какие «грабли» чаще всего мешают добиться целей: от неподготовленной НСИ и недостоверных начальных данных до слабых коммуникаций и отсутствия плана Б. Показываем, почему мировая статистика и российская практика сходятся в одном: ключевые проблемы чаще лежат не в технологиях, а в организации процессов, роли руководителя проекта и вовлеченности заказчика. Объясняем, как управлять завышенными ожиданиями, человеческим фактором и соблазном «запрограммировать все», не превращая типовую систему в дорогого монстра. А также рассказываем, какие шаги помогают пройти путь от предпроектного обследования и моделирования до опытной и промышленной эксплуатации без отката назад.

16.07.2026    973    0    akislov    2    

2

Взгляд со стороны Заказчика Оценка проекта Бизнес-аналитик Руководитель проекта Россия Бесплатно (free)

Когда задачу еще уточняют, а срок уже требуют назвать, дата легко превращается в обещание на удачу. В статье разбираю, как говорить с заказчиком о сроках при плавающих вводных: что фиксировать, как объяснять переоценку без конфликта и почему старый срок не обязан выдерживать новую версию задачи.

07.07.2026    469    0    NikolayMaerov    5    

3

Оценка проекта 1С 8.3 1С 8.5 1С:Документооборот Бесплатно (free)

Внедрение 1С:Документооборота часто оценивают слишком размыто: “стало удобнее”, “порядка больше”, “всё в одной системе”. Но для руководителя этого недостаточно. Разбираю, какие KPI можно использовать для оценки эффекта от 1С:ДО, где чаще всего врут цифры, что считать до и после запуска и как не подменить пользу красивой отчётностью.

17.06.2026    535    0    YA_826532418    1    

5

Оценка проекта Управление рисками Россия Бесплатно (free)

Техдолг в 1С часто звучит для бизнеса как “разработчики хотят переписать код”. Из-за этого важные улучшения годами откладываются, пока не ломается релиз, обмен, отчет или критичный процесс. Разбираем, как переводить техдолг на язык рисков, сроков, стоимости изменений, зависимости от людей и устойчивости системы.

10.06.2026    1226    0    NikolayMaerov    11    

20

Оценка проекта Управление рисками 1С 8.3 1С:ERP Управление предприятием 2 1С:ERP. Управление холдингом Россия Бесплатно (free)

Почему даже хорошие ERP-системы не спасают от провала проекта. В материале рассмотрены 10 типичных управленческих ошибок до начала внедрения.

09.06.2026    780    0    Adapta    1    

5

Оценка проекта Управленческий учет Бесплатно (free)

Статья о том, сколько на самом деле стоит учет в компании. Не только лицензии, внедрение и зарплаты, а вся цена неуправляемости: ручные отчеты, ошибки в данных, задержки закрытия, бесконечные доработки и решения, принятые по цифрам, которым нельзя верить.

15.05.2026    797    0    apatyukov    0    

4
Для отправки сообщения требуется регистрация/авторизация