Кто должен отвечать за неадекватное ТЗ и как разработчику 1С организовать работу в условиях неопределенности

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

Анализ проблемы: почему возникает конфликт ответственности

Проанализируем типичную ситуацию. Заказчик (например, бухгалтер или менеджер) ставит задачу на своем «птичьем» языке, исходя из своих текущих болей. Разработчик, стремясь помочь, берет задачу в работу «как понял». Спустя неделю выясняется, что результат не соответствует ожиданиям, потому что «подразумевалось совсем другое». В итоге ответственность становится обоюдной, что на практике означает ее полное отсутствие. Руководство видит отсутствие результата, а виноватыми оказываются оба: один не смог объяснить, другой — понять.

Рассмотрим причины затягивания сроков в таких условиях:

1. Разрыв в ментальных моделях: Пользователь мыслит бизнес-процессом, разработчик — структурами данных (регистрами, документами).
2. Проклятие знания: Заказчик уверен, что детали очевидны, и не описывает их.
3. Отсутствие фиксации: Устные договоренности забываются или искажаются со временем.
4. Страх уточнения: Разработчик боится показаться некомпетентным и берет в работу даже то, что ему не до конца ясно.

Решение 1: Переход к письменной фиксации и правилу «Нет ТЗ — нет задачи»

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

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

1. Принимаем задачу только в письменном виде (через почту, мессенджер или внутреннюю систему тикетов).
2. Если задание размыто, не начинаем кодить. Вместо этого составляем уточняющие вопросы.
3. Критически важный момент: Если заказчик не может составить ТЗ сам, это должен сделать разработчик, но обязательно утвердить его у заказчика перед началом работы.

Используем фразу: «Я подготовил описание задачи, как я ее понял. Подтвердите, что реализация именно этого функционала решит вашу проблему». Это перекладывает ответственность за «хотелки» на заказчика.

Решение 2: Использование контрольных примеров в Excel

Проанализируем один из самых мощных инструментов в арсенале программиста 1С — контрольный пример. Когда речь идет о расчетах, отчетах или сложных алгоритмах, устных объяснений недостаточно. Разберем по шагам, как применять этот метод:

Попросим заказчика предоставить расчет в Excel на реальных данных. Например, если нужно изменить логику расчета премий, пусть заказчик заполнит таблицу:

1. Исходные данные (сотрудник, сумма продаж, стаж).
2. Промежуточные вычисления.
3. Итоговый результат, который он хочет видеть в 1С.

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

Решение 3: Разработчик как бизнес-аналитик

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

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

Для реализации такого подхода необходимо:

• Понимать предметную область (бухучет, складскую логистику).
• Знать типовые возможности платформы и конфигурации.
• Предлагать свои варианты реализации («Я могу сделать так, как вы просите, но это потребует рефакторинга всей системы. Давайте попробуем решить это через расширение или подписку на событие»).

Технический аспект: как избежать фатального рефакторинга

Разберем ситуацию, когда новое требование заставляет переписывать весь код. Это часто случается из-за отсутствия понимания границ задачи. Посмотрим на примере задачи для 1С:Управление нашей фирмой:

Заказчик просит: «Нужно блокировать отгрузку, если нет оплаты в течение 72 часов». Разберем, какие вопросы должен задать разработчик, чтобы не переделывать код трижды:

// Пример уточняющего алгоритма для разработчика:
1. Как считать 72 часа? (Календарные или рабочие?)
2. От какого момента отсчет? (От даты заказа или даты планируемой отгрузки?)
3. Что считать фактом оплаты? (Поступление на счет или только привязку к заказу?)
4. Для каких категорий клиентов действует правило?

Если реализовать задачу «в лоб», без учета праздников и выходных, заказчик придет в понедельник и скажет, что система работает неверно. Чтобы этого избежать, используем в коде гибкие настройки. Например, выносим константы (срок в часах, тип календаря) в настройки параметров учета или дополнительные реквизиты.

Административный регламент и «принцип трех гвоздей»

Выясним причину, по которой задачи часто меняются на лету. Это отсутствие фиксации трудозатрат. В условиях одной компании важно донести до руководства: уточнение ТЗ — это тоже работа. Если разработчик тратит 4 часа на обсуждение и 1 час на кодинг, это нормально.

Рассмотрим рекомендации по управлению очередью задач:

1. Единая точка входа: Не принимайте задачи в коридоре или на обеде. «Напиши в тикет/почту, иначе я забуду».
2. Оценка трудоемкости: Каждое изменение в «кривом» ТЗ должно сопровождаться комментарием: «Это изменение сдвинет срок готовности еще на два дня, так как нужно переделывать структуру хранения данных».
3. Приоритезация: Если задач много, пусть их приоритет расставляет руководитель. Это снимет с вас ответственность за то, что «задача Марии Ивановны не делается вторую неделю».

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

Итог: кто же платит?

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

Чтобы минимизировать эти потери, мы должны:

• Работать только с письменными подтверждениями (даже если это скриншот письма).
• Требовать контрольные примеры в числовом виде.
• Выступать в роли эксперта, который помогает заказчику сформулировать потребность, а не просто «пишет код».
• Фиксировать границы задачи: «Я делаю пункты А, Б и В. Пункт Г — это уже новая задача».

Такой подход переводит отношения из плоскости «раб и господин» в плоскость профессионального сотрудничества, где ответственность за результат распределена справедливо.