В практике каждого разработчика 1С рано или поздно возникает ситуация, когда полученное техническое задание (ТЗ) содержит явную ошибку. Это может быть как простая опечатка (условные 2+2=5), так и серьезный архитектурный просчет, который в будущем приведет к деградации системы. Разберем подробно, как вести себя в такой ситуации, чтобы сохранить профессиональную репутацию, защитить интересы бизнеса и не стать «крайним» при разборе полетов.
Прежде чем вступать в открытую конфронтацию с аналитиком или заказчиком, проанализируем ситуацию. Нам необходимо убедиться, что мы правильно поняли контекст. В мире 1С часто встречаются кейсы, когда стандартная математика уступает место специфическим бизнес-правилам. Рассмотрим несколько причин, почему «ошибочное» решение может быть осознанным:
Посмотрим на пример из практики: разработчик получает ТЗ на создание регистра остатков для учета заказов, но видит, что согласно алгоритму, регистр никогда не закроется в ноль. С точки зрения архитектуры 1С:Предприятие — это «мусор» в базе. Но с точки зрения бизнеса это может быть способом видеть «зависшие» хвосты по конкретным менеджерам в течение 10 лет. Наша задача — выяснить этот момент до начала кодирования.
Если мы уверены, что в ТЗ действительно ошибка, разберем по шагам правильный алгоритм действий, основанный на коллективном опыте ведущих специалистов.
Первым делом напишем письмо или сообщение в системе учета задач (Jira, Kaiten, Битрикс24). Формулировка должна быть максимально корректной, чтобы не задеть профессиональное самолюбие автора ТЗ. Проанализируем пример сообщения:
«При изучении раздела 4.2 (расчет себестоимости) я обнаружил возможную нестыковку: указанная формула А + Б = В может привести к отрицательным остаткам в случае возврата товара. Подскажите, пожалуйста, возможно я упустил какой-то нюанс бизнес-логики?»
Такой подход позволяет автору «сохранить лицо» и либо исправить ошибку, либо объяснить скрытые причины такого решения.
Если после мягкого уведомления аналитик настаивает на реализации «как есть», рассмотрим стратегию формализации. В крупных компаниях и при работе на внутреннего заказчика ответственность распределяется согласно регламенту. Если ТЗ утверждено и зарегистрировано, программист обязан его выполнять, но он имеет право зафиксировать свое особое мнение. Это делается с помощью служебной записки или комментария к задаче, который увидят руководитель проекта (РП) и стейкхолдеры.
Важно помнить: ошибка в ТЗ — самая дорогая. Согласно закону Боэма, исправление логической ошибки на этапе кодирования в 10 раз дороже, чем на этапе проектирования. Если мы промолчим и внедрим заведомо неверное решение, бизнес потеряет деньги, а виноватым в итоге сделают того, кто «видел, но не сказал».
В случае, если нас заставляют внедрять абсурдную логику, рекомендуется оставлять подробные комментарии в программном коде. Это не спасет от переделки, но поможет коллегам в будущем понять, почему система ведет себя именно так. Посмотрим на пример оформления такого кода:
// ВНИМАНИЕ: Реализация согласно ТЗ №123-Б (автор: Иванов И.И.).
// Логика расчета изменена вопреки типовому механизму по требованию финотдела.
// Разработчик предупреждал о рисках расхождения данных в отчетах (письмо от 01.09.2023).
СуммаИтого = Сумма + (Сумма * 0.05); // Принудительная наценка 5% вне зависимости от условий
Проанализируем, к чему приводит стратегия «я просто кодер, мое дело — копать»:
Рассмотрим реальную историю: заказчик при переходе с Access на 1С:Управление торговлей 10 требовал полностью переписать интерфейс и логику под старую систему, потому что «так привычно». Разработчик предупредил о нецелесообразности, но заказчик настоял. В итоге было потрачено 1.5 года работы и огромные бюджеты. Через полгода эксплуатации пользователи сами отказались от этого «монстра» и перешли на типовые формы, так как они оказались эффективнее. Вывод: иногда стоит проявить твердость и аргументированно отказать в реализации вредных идей, защищая интересы заказчика даже против его воли.
Профессиональный разработчик 1С — это не просто «кодер по ТЗ», а полноценный партнер бизнеса. Если вы видите, что 2+2=5, ваша обязанность как эксперта — поднять этот вопрос. Помните: лучше один раз вступить в конструктивный спор на этапе обсуждения, чем потом месяцами заниматься «ассенизацией» данных в рабочей базе.
Если же вы работаете в системе, где инициатива наказуема, а ошибки аналитиков неприкосновенны — это серьезный повод задуматься о смене места работы, так как профессиональная деградация в таких условиях неизбежна.