Фильтрация заказчиков в проектах на платформе 1С:Предприятие и чек-лист предпроектной оценки с алгоритмом "вежливый отказ"

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

🧭 Что значит «рискованный заказчик»

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

Признаки, которые на входе почти всегда означают убыток:

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

Отдельный случай - задача, которая не окупается сама по себе: маленькая доработка в базе с тяжёлым обменом или проект, который заказчик хочет закрыть чужими руками. Признак виден на входе, и отказ по нему тоже нормален.

📋 Чек-лист предпроектной оценки

Оценка перед проектом отвечает на вопрос, что именно вы берёте в наследство и где проект сломается. Проверять стоит пять зон.

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

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

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

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

Требования к срокам и бюджету. Плановая дата, к которой нужен результат, и бюджет, в который он должен уложиться, должны быть названы на входе. Если ни того, ни другого нет, проект будет тянуться, пока заказчику не надоест.

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

🧮 Как считать трудоёмкость и риски

Трудоёмкость в такой оценке считается по объёму работ, который придётся сделать до новой функциональности: погасить технический долг, разобрать обмены, привести справочники к одному виду. Число объектов метаданных о ней говорит мало.

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

Условный пример того, как выглядит абзац заключения (числа выдуманы для формата, не для расчёта): «При обследовании базы найдено 47 фрагментов устаревшего кода с обращением к несуществующим реквизитам; рефакторинг перед добавлением новой функциональности оценивается в 200 часов. При текущем бюджете проекта эта работа делает его нерентабельным».

🤝 Как формулировать отказ

Отказ строится на трёх опорах: объективные данные, объяснение мотива и альтернатива. Фраза «вы токсичны» не говорится ни в каком виде - в заключении стоят факты из обследования, с которыми можно спорить по существу.

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

Мотив с позиции заказчика. Объясните риск его словами: «В базе уже есть сбои при одновременной работе больше десяти человек; если начать доработку без предварительной оптимизации, есть риск простоя бухгалтерии в закрытие периода. Мы не готовы начинать в такой ситуации без расширения технического задания». Заказчик нередко не знает масштаба своих проблем, и отказ становится поводом их показать.

Альтернатива вместо закрытой двери. Варианты, которые оставляют заказчика и не вешают работу на вас:

1. Этап: сначала рефакторинг или оптимизация, затем новая функциональность. Дороже, зато снимает большую часть рисков.
2. Передача коллеге, который специализируется на таких задачах: проект слишком мелкий, слишком нестандартный или лежит в чужой отрасли.
3. Разовая консультация или обследование с передачей отчёта: покрывает ваши затраты на оценку и даёт заказчику документ, с которым он пойдёт дальше.

Если не подходит ни один вариант, отказ был верным решением. Освободившиеся часы уходят к заказчику, который готов платить за работу и понимает, из чего она состоит.

💰 Экономика отказа

Сравнение двух сценариев объясняет, почему отказ бывает выгоднее заказа.

При первом варианте вы берёте проект с низкой маржой и полной загрузкой команды на несколько месяцев. В процессе выясняется, что постоянные правки съедают маржу, сроки уезжают, а лучшие разработчики заняты переделками. При втором вы обследуете проект, видите риски и отказываетесь; команда простаивает неделю, но берёт проект с прозрачными условиями.

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

Здесь же работает принцип Парето в его управленческой формулировке: небольшая доля заказов даёт большую часть проблем, и отказ от них разгружает команду сильнее, чем кажется. Доли каждый считает по своей истории: у одной команды это 20% заказчиков, у другой - 40%.

🪤 Скрытые издержки проблемного проекта

Прямые убытки видны в смете, остальное - нет.

• Согласования. Переписка и созвоны по меняющимся требованиям не оплачиваются, но идут по тому же рабочему времени, что и код.
• Репутация. Проваленный проект обсуждают, и это влияет на следующие заказы сильнее, чем одна удачная публикация о нём.
• Выгорание. Уход ключевого разработчика после проекта с постоянными переделками стоит дороже, чем недополученная маржа этого проекта.
• Долги по другим проектам. Часы, отданные проблемному заказчику, не попадают к тому, кто их ждал.

🧰 Как встроить оценку в работу

Изменения в процессе небольшие, но их нужно закрепить, иначе оценка отменяется при первой срочной заявке.

1. Чек-лист первого контакта. Десяток вопросов до встречи: есть ли ТЗ, сколько человек работает в системе, какой объём документооборота, кто принимает результат, есть ли свой ИТ-специалист.
2. Порог обязательной оценки. Для проектов дороже определённой суммы обследование обязательно и оплачивается. Порог выбирается по своим данным; в примере выше он был условным.
3. Шаблон заключения. Разделы постоянные: контекст, состояние базы и обменов, карта рисков, оценка работ, варианты продолжения.
4. Формулировки для отказа. Одна-две отработанные фразы на каждый типовой случай, чтобы решение принималось без импровизации: «в текущем состоянии базы мы не можем гарантировать сроки по новой функциональности» звучит предметнее, чем «нам это неинтересно».

📈 Что отслеживать

• Доля отказов после обследования. Ноль отказов означает, что берётся всё подряд, и убыточные проекты попадают в работу наравне с остальными.
• Средняя маржа завершённых проектов. Если фильтрация работает, показатель растёт; отсутствие роста говорит, что оценка неточна.
• Удовлетворённость команды. Ответ на вопрос, с каким заказчиком работалось лучше, показывает, кого искать дальше.
• Число переписываний договора. Третья редакция ТЗ означает, что заказчик не готов к системной работе.

📚 Источники и чем эта статья отличается

Близкие темы на Infostart уже разбирали:

• «Предпроектное обследование: необходимость или уловка?»: обследование как отдельный этап и отдельный продукт.
• «Оценка проекта: угадываем будущее»: многоуровневая оценка проекта от пресейла до сдачи работ.
• «5 причин негатива от клиента к 1С-нику и что с этим делать»: обсуждение на митапе Infostart в Казани о трудностях между заказчиком и исполнителем.

Здесь оценка нужна для решения, брать заказ или отказать: чек-лист пяти зон проверки, расчёт рисков и формулировки отказа.

📦 Файл к статье

К публикации приложен архив 03.4-companion.zip, он в блоке «Файлы» вверху страницы:

• chek-list-predproektnoy-otsenki.md - признаки риска на входе и пять зон проверки перед договором: учётная политика, состояние базы, обмены и интеграции, компетенции на стороне заказчика, сроки и бюджет.
• shablon-zaklyucheniya.md - шаблон письменного заключения с постоянными разделами: контекст, состояние базы и обменов, карта рисков, оценка работ, варианты продолжения.
• formulirovki-otkaza.md - три опоры отказа (данные, мотив с позиции заказчика, альтернатива) и пример формулировки.
• metriki.md - что отслеживать, чтобы понять, работает ли фильтрация.
• README.md: что внутри, как пользоваться и что проверено.

🏁 Итог

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

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

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 27 технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S