Управление ожиданиями заказчика на 1С-проекте: как договориться о результате до разработки
На 1С-проектах многие проблемы начинаются не с кода. Код, формы, права, отчеты, обмены и регламентные задания появляются позже. Сначала появляется ожидание.
Заказчик говорит: “Нужно добавить поле в документ”. Для него это может быть небольшая правка: открыть форму, добавить новое поле и сохранить.
Команда 1С смотрит на эту же задачу шире. Где это поле будет храниться? Нужно ли показывать его в списке? Кто сможет его видеть и менять? Попадет ли оно в отчет? Нужно ли добавить его в печатную форму? Повлияет ли оно на обмен с другой системой? Нужно ли менять инструкцию для пользователей?
Обе стороны говорят об одной задаче, но видят ее по-разному. Заказчик чаще думает о результате в работе пользователей. Команда 1С — о реализации, ограничениях и последствиях для системы.
Если эту разницу не проговорить в начале, потом легко получить ситуацию: задача сделана, разработчик уверен, что все реализовано, а заказчик говорит: “Мы ожидали немного другое”. Не потому что кто-то плохо работал. Просто в начале не договорились о результате.
В статье разберу, как управлять ожиданиями заказчика на 1С-проекте простыми рабочими способами: что уточнять, что фиксировать, как говорить о сроках и ограничениях, как договариваться о приемке и не превращать каждую задачу в длинное согласование.
Почему ожидания расходятся
Заказчик обычно описывает задачу через свою потребность. Это нормальный язык бизнеса.
Например:
- “хочу видеть отчет по оплатам”;
- “нужно согласовывать договоры”;
- “менеджеры должны заполнять причину отказа”;
- “руководитель должен видеть просроченные задачи”;
- “сделайте как в старой базе”.
Заказчик не обязан сразу говорить про регистры, роли, права, формы, настройки маршрутов, расширения и ограничения типовой конфигурации. Он описывает то, что хочет получить в работе.
Команда 1С, наоборот, смотрит на задачу через систему. Если нужно “добавить поле”, аналитик и разработчик проверяют, в каком объекте оно должно храниться, кто будет его заполнять, где оно должно отображаться, потребуется ли отчет, обмен, печатная форма или изменение прав.
В этом и появляется расхождение. Для заказчика задача может выглядеть как небольшое изменение на форме. Для команды 1С это может быть доработка, которая затрагивает несколько частей системы.
В 1С-проектах слово “просто” лучше всегда уточнять. Иногда за ним действительно стоит небольшая задача. А иногда — данные, права, отчеты, обмены и отдельный сценарий приемки.
Мини-кейс: “просто добавьте причину отказа”
Заказчик просит добавить поле “Причина отказа” в карточку сделки в 1С:CRM. На первой встрече задача звучит просто: менеджер должен выбрать причину, если клиент отказался.
Если сразу передать это в разработку, можно получить технически правильное поле в карточке. Но после показа появляются вопросы: причина отказа должна быть видна в списке сделок, руководитель хочет отчет по причинам отказов, поле нужно сделать обязательным только на этапе “Отказ”, часть причин должна быть скрыта от обычных менеджеров, а данные нужно выгружать в Excel для ежемесячного анализа.
Команда сделала поле. Заказчик ожидал управленческий инструмент для анализа отказов.
Проблема не в поле и не в отчете. Проблема в том, что ожидание не разобрали до разработки. На старте нужно было спросить: кто будет смотреть эти причины, где они должны отображаться, какие решения будут приниматься по отчету и что считать готовым результатом.
Ожидания нужно уточнять, а не додумывать
Бывает, что возникает следующая ситуация: аналитик считает, что задача и так понятна. Особенно если заказчик давно работает с этой базой или запрос похож на типовую доработку либо же в случае недостатка опыта работы у аналитика.
Но первая фраза редко описывает весь результат. Например, запрос “нужен отчет по оплатам” может означать разное.
Руководитель может хотеть видеть просроченную дебиторку. Бухгалтерия — сверяться с документами оплаты. Менеджеры — понимать, кому напомнить об оплате. Директор — открыть отчет перед совещанием. Пользователи — выгружать данные в Excel, потому что им так удобнее анализировать.
Если сделать отчет только по первому описанию, можно не попасть в реальную потребность. Поэтому ожидания лучше уточнять вопросами. В таблице ниже перечисляю важные вопросы, которые необходимо задавать заказчику по каждому полученному требованию:
| Вопрос | Зачем задавать | Пример для 1С |
| Какой результат должен получить пользователь? | Понимаем не только изменение в системе, но и рабочий результат | Не просто “добавить реквизит”, а “менеджер видит причину отказа в карточке CRM” |
| Кто будет этим пользоваться? | Понимаем роли, права и разные сценарии | Отчет нужен руководителю, менеджеру и бухгалтеру, но каждому с разными отборами |
| В каком процессе это используется? | Проверяем влияние на соседние участки | Поле в договоре влияет на согласование, печатную форму и отчет |
| Что считаем успешной приемкой? | Заранее договариваемся, как проверять результат | Пользователь создает документ, запускает маршрут и видит нужный статус |
| Какие ограничения уже есть? | Сразу учитываем то, что влияет на срок и способ реализации | Типовая конфигурация, запрет на изменение объектов, права |
Где чаще всего расходятся ожидания
Есть несколько тем, где ожидания заказчика и команды 1С расходятся чаще всего. Они встречаются и при внедрении любой системы 1С, и при сопровождении, и при обычных доработках.
1. Сроки
Заказчик часто оценивает срок по видимой части задачи. Если нужно добавить кнопку, поле или отчет, кажется, что это недолго.
Команда 1С оценивает задачу шире: нужно понять сценарий, проверить типовой функционал, сделать разработку, протестировать, передать на приемку и выпустить изменение в рабочую базу.
Проблема возникает, когда срок называют без состава работ. Проектная команда говорит: “Сделаем за неделю”. Заказчик может услышать: “Через неделю пользователи уже будут работать в продуктивной базе”, а на самом деле имелось в виду “Через неделю будет первый вариант на тестовой базе”.
Лучше говорить точнее:
За неделю подготовим первый рабочий вариант на тестовой базе. После этого потребуется проверка пользователями, возможные правки и согласование даты релиза.
2. Состав задачи
В 1С небольшое изменение часто затрагивает соседние объекты. Добавили реквизит — нужно понять, где еще он должен появиться: в форме, списке, отчете, печатной форме, обмене, правах или инструкции.
Если это не проговорить, заказчик может считать, что новое поле должно быть везде. Команда может считать, что сделала только то, что было описано в задаче.
В работе с требованиями я обычно отдельно фиксирую не только “что делаем”, но и “что сейчас не трогаем” (то есть, сразу проговариваю ограничения и согласовываю их с заказчиком). Именно второй список часто спасает приемку. Например, можно сразу указать: реквизит добавляем в документ и выводим на форму, но печатные формы, обмен и отдельный отчет в рамках этой задачи не меняем. Если позже это понадобится, оцениваем отдельным пунктом.
3. Качество результата
У заказчика и команды может быть разное понимание качества.
Для разработчика качественно — это когда решение работает без ошибок, не ломает типовой функционал, не создает проблем при обновлении и не ухудшает производительность.
Для заказчика качественно — это когда пользователю понятно, куда нажимать, что заполнять, где смотреть результат и к кому обращаться при вопросах.
На 1С-проектах важны оба уровня качества: технический и пользовательский.
Например, в 1С:CRM можно правильно добавить новый этап сделки. Но если менеджеры не понимают, когда переводить сделку на этот этап, данные будут заполняться случайно. Формально механизм работает, но управленческий результат не появляется.
Поэтому вместе с технической частью нужно проговорить пользовательскую: нужна ли инструкция, нужно ли короткое обучение, кто отвечает на вопросы после релиза и когда собираем обратную связь.
4. Ответственность сторон
Аналитик может помочь разобраться в процессе, предложить вариант реализации, показать ограничения системы и подготовить решение. Но не может и не должен сам принимать бизнес-решение.
Например, если разные подразделения по-разному видят маршрут согласования, не аналитик решает, чье мнение правильное. Нужен ответственный со стороны заказчика, который принимает решение по процессу.
Для масштабных/кроссфункциональных задач лучше сразу определить, кто со стороны заказчика принимает решение, кто дает требования, кто проверяет результат и кто принимает решение, если мнения участников расходятся.
Как говорить об ограничениях спокойно
Когда аналитик или руководитель проекта задает уточняющие вопросы, заказчик иногда воспринимает это как лишнее усложнение. Особенно если задача кажется простой.
Поэтому важна подача. Ограничения лучше объяснять через результат: мы уточняем не потому, что не хотим делать, а потому что хотим сделать так, чтобы пользователи смогли нормально работать.
| Лучше не так | Лучше так |
| Так нельзя сделать быстро | Быстро можем сделать первую часть. Давайте разделим: что нужно к ближайшему сроку, а что можно вынести в следующий этап |
| Вы не описали требования | Нужно уточнить сценарий, чтобы сделать не просто техническое изменение, а рабочий вариант для пользователей |
| Это не входило в задачу | Этого не было в согласованном объеме. Добавим отдельным пунктом и оценим влияние на срок |
| Пользователи сами неправильно работают | Похоже, в сценарии есть место, где пользователи часто ошибаются. Нужно решить: меняем интерфейс, добавляем подсказку или обновляем инструкцию |
| Это долго | Тут есть несколько частей: права, отчет, обмен и тестирование. Покажу, из чего складывается срок |
Договоренности нужно фиксировать письменно
На 1С-проектах много решений принимается в созвонах, чатах и личных сообщениях. Это удобно, но у такого формата есть минус: через несколько дней участники могут по-разному помнить детали.
Поэтому после обсуждения полезно фиксировать короткий протокол встречи (можно даже в произвольной форме). Я обычно направляю его в почте и получаю подтверждение от заказчика, что все договоренности зафиксированы верно либо, что необходимо внести какие-то корректировки.
Пример:
Коллеги, фиксирую договоренности. В текущей задаче делаем новый маршрут согласования для договоров вида “Поставка услуг” при сумме от 500 000 рублей. Участники: инициатор, руководитель отдела, юрист, финансовый контролер. Старые договоры не меняем. Печатные формы не дорабатываем. Приемка: создаем тестовый договор, запускаем маршрут, проверяем уведомления и переходы статусов. Ответственный за проверку со стороны заказчика — Иванова А.А.
Такое резюме занимает немного времени, но помогает всем одинаково понимать объем задачи. Если позже появятся новые пожелания, их проще отделить от уже согласованного объема.
Не обещать лишнего — нормальная профессиональная позиция
Иногда хочется сразу согласиться с заказчиком, особенно если задача важная и срок сжатый. Но в 1С-проектах обещание должно учитывать не только разработку, но и проверку, приемку, релиз и готовность пользователей.
Если команда говорит: “Да, все сделаем к пятнице”, заказчик может ожидать полностью готовое изменение в рабочей базе. А команда могла иметь в виду только разработку на тестовой базе.
Поэтому лучше говорить не “сделаем всё к пятнице”, а “к пятнице подготовим вариант для проверки на тестовой базе”. Не “после релиза всё заработает”, а “после релиза первые два дня собираем вопросы пользователей и исправляем найденные ошибки”. Не “это простая доработка”, а “изменение выглядит небольшим, но нужно проверить права и отчеты”.
Честная формулировка не делает команду слабее. Наоборот, она показывает, что команда видит задачу целиком и заранее предупреждает о важных условиях.
Как разделять обязательное и желательное
У заказчика может быть много пожеланий. Это нормально. Важно не складывать их все в один общий список без приоритета. У нас в компании есть утвержденная форма реестра требований, где один из столбцов как раз “Приоритет требования”. В таблице ниже привожу значения приоритетов и их расшифровку с примерами.
| Уровень | Что означает | Пример для 1С |
| Обязательно | Без этого результат нельзя принимать | Документ проводится, маршрут запускается, права ограничивают доступ |
| Важно | Сильно влияет на удобство работы | Есть понятные статусы, отборы в списке, уведомления ответственным |
| Желательно | Полезно, но можно сделать позже | Дополнительная диаграмма, отдельный вариант печатной формы, цветовая индикация |
| Не сейчас | Не входит в текущий релиз | Интеграция с внешней системой, мобильный сценарий, отдельный управленческий дашборд |
Приемка: договориться, как проверяем результат
Приемка часто показывает, насколько одинаково стороны поняли задачу. Если заранее не договориться о проверке, пользователь может начать смотреть не только согласованный сценарий, но и соседние идеи, которые появились уже после разработки.
Критерии приемки лучше формулировать до передачи результата на проверку. Хороший критерий в 1С должен быть привязан к конкретному действию: создать документ с заданными условиями, заполнить обязательные поля, провести документ, сформировать отчет с нужным отбором, проверить права под конкретной ролью или протестировать обмен на одном примере.
Фраза “проверить, что всё работает” слишком общая. Она не помогает ни заказчику, ни команде.
Лучше так:
Приемка считается успешной, если пользователь с ролью “Менеджер CRM” создает сделку, переводит ее на этап “Согласование условий”, заполняет обязательное поле “Причина перехода”, сохраняет сделку, а руководитель видит эту сделку в отчете по активным согласованиям.
Если ожидания уже разошлись
Иногда расхождение становится заметно уже после разработки. Решение передали на проверку, заказчик посмотрел и сказал: “Мы ожидали немного другое”.
В такой ситуации лучше не спорить, а вернуться к конкретике.
Шаг 1. Зафиксировать, что именно не совпало
Нужно понять, где расхождение: не тот отчет, не хватает поля, не тот маршрут, не учли роль пользователя, неудобно выполнять действие, нет инструкции или непонятно, как проверить результат.
Рабочая формулировка:
Давайте зафиксируем конкретные расхождения: что ожидали, что реализовано сейчас и что нужно изменить в первую очередь.
Шаг 2. Понять причину расхождения
Причины обычно повторяются: требования были описаны слишком общо, не был определен ответственный за приемку, пользователи подключились поздно, не проговорили ограничения типовой конфигурации, не учли права, отчеты или обмены.
Задача такого разбора — не искать виноватого, а понять, где процесс дал сбой и что нужно изменить дальше.
Шаг 3. Согласовать ближайший полезный результат
Когда ожидания уже разошлись, не стоит сразу брать в работу все замечания одним большим списком. Лучше определить ближайший результат, который действительно нужен пользователям.
Например: сначала исправляем критичный сценарий проведения документа, потом добавляем недостающий отбор в отчет, инструкцию обновляем до запуска на всех пользователей, а дополнительные пожелания выносим в отдельный список.
Так разговор возвращается в рабочий формат: что делаем сейчас, что позже, кто проверяет и как это влияет на срок.
Роль аналитика 1С
Аналитик 1С часто находится между бизнесом и разработкой. С одной стороны, нужно понять заказчика на его языке. С другой — передать команде требования так, чтобы разработчик не додумывал скрытый смысл.
Хороший аналитик не просто записывает пожелания. Он помогает заказчику увидеть, как идея будет работать в системе: кто нажимает, где смотрит, какие данные вводит, что происходит дальше и кто проверяет результат.
В обсуждениях с заказчиком я обычно отдельно останавливаюсь на слове “просто”. Если его не разобрать, через неделю это “просто” может превратиться в отчет, права, обмен, печатную форму и отдельный сценарий приемки.
Для 1С это особенно важно, потому что почти любое изменение связано с реальным процессом: договором, заявкой, оплатой, складом, клиентом, задачей, согласованием, отчетом или обменом.
Роль руководителя проекта
Руководитель проекта тоже влияет на ожидания заказчика. Его задача — не только распределить работу между разработчиками, но и удержать понятные рамки задачи или проекта.
Если на каждом обсуждении добавлять новые пожелания без оценки влияния, команда быстро теряет управляемость. Разработчики получают растущий объем, аналитики уточняют требования заново, тестирование сокращается, а релиз становится сложнее.
Поэтому руководителю важно регулярно возвращать обсуждение к простым вопросам: это входит в текущий релиз или в следующий этап, какой срок меняется, если добавить это сейчас, какой риск появляется при ускорении, кто со стороны заказчика подтвердил приоритет и что убираем из текущего объема, если добавляем новое (при работе на проектах по Agile эти вопросы обсуждаются с заказчиком при планировании каждого последующего спринта).
Так разговор идет не на уровне ощущений, а на уровне конкретных последствий: срок, объем, качество и ответственность.
Мини-чек-лист перед стартом новой задачи
Перед началом заметной задачи полезно быстро пройтись по чек-листу. Он не заменяет спецификацию требований, но помогает заранее увидеть слабые места.
| Что проверить | Зачем |
| Понятен пользовательский сценарий | Команда знает, кто, где и зачем будет работать в 1С |
| Определен ответственный со стороны заказчика | Есть человек, который подтверждает приоритеты и спорные вопросы |
| Зафиксирован текущий объем | Понятно, что входит в задачу, а что остается на следующий этап |
| Проговорены ограничения | Команда учитывает типовую конфигурацию, обмены, права и релизное окно |
| Есть критерии приемки | Проверка результата проходит по понятному сценарию |
| Понятна роль пользователей | Ясно, кто будет проверять и кто будет работать после релиза |
| Есть план коммуникации | Пользователи узнают, что изменилось и куда обращаться с вопросами |
Если по нескольким пунктам нет ответа, задача может быть не готова к разработке. Это не значит, что ее нельзя брать в работу. Это значит, что нужно осознанно закрыть пробелы или сразу договориться о рисках.
Как не превратить управление ожиданиями в бюрократию
Уточнять ожидания — не значит писать большой документ на каждую маленькую задачу.
Для небольшой доработки часто достаточно короткого описания в карточке задачи: что меняем, для кого, какой сценарий должен работать, что не входит в текущий объем и как принимаем результат.
Для крупной задачи нужна более подробная спецификация требований. Например, если речь идет о новом процессе согласования в 1С:Документооборот, изменении воронки продаж в 1С:CRM или доработке обмена с внешней системой.
Принцип простой: чем больше участников, рисков и влияния на процесс, тем подробнее нужно фиксировать договоренности.
Пример: простой отчет, который оказался не таким простым
Типовая ситуация: заказчик просит отчет по задачам в 1С:Документооборот. Формулировка звучит просто: “Нам нужен отчет, чтобы видеть просроченные задачи сотрудников”.
Если сразу передать задачу в разработку, можно получить технически правильный отчет: сотрудник, задача, дата, статус, просрочка.
Но после показа могут появиться уточнения: руководителю нужно видеть только свой отдел, службе контроля — все подразделения, просрочка должна считаться не от даты создания, а от планового срока, задачи на заместителях нужно показывать отдельно, отчет нужен не только в 1С, но и в Excel.
Команда могла сделать отчет правильно по первому описанию. Но реальное ожидание заказчика было шире: не просто список задач, а инструмент контроля исполнительской дисциплины.
Что стоило уточнить заранее: кто будет пользоваться отчетом, какое решение принимается по данным, какие колонки обязательны, как считается просрочка, какие задачи нужно исключить и на каких данных проверяем результат.
Пример: внедрение 1С:CRM
В 1С:CRM ожидания часто расходятся вокруг дисциплины работы менеджеров.
Руководитель ожидает, что после внедрения CRM продажи станут прозрачнее. Менеджеры ожидают, что система не будет мешать их работе. Команда внедрения ожидает, что пользователи будут заполнять данные по согласованным правилам.
Если это не проговорить, после запуска появляются знакомые проблемы: часть клиентов продолжают вести в Excel, стадии сделок заполняют формально, причины отказов выбирают случайно, руководитель не доверяет отчетам, пользователи жалуются, что в системе слишком много полей.
Здесь важно честно договориться: CRM не станет полезной только из-за настройки справочников и форм. Нужны правила работы, ответственность руководителей, минимальный набор обязательных данных и понятное объяснение для пользователей, зачем эти данные нужны.
Ожидание “после внедрения всё станет прозрачнее” нужно перевести в конкретные договоренности: какие поля обязательны на каждом этапе сделки, какие отчеты смотрит руководитель, как часто проверяется качество данных, что считается нарушением правил ведения CRM и какие действия менеджера система должна упрощать.
Тогда внедрение становится не только технической настройкой, но и изменением рабочего процесса.
Что получает команда, если ожидания согласованы
Управление ожиданиями не делает проект идеальным. Пользователи все равно будут задавать вопросы. Некоторые требования будут уточняться. Часть решений придется менять после обратной связи.
Но если ожидания согласованы, работать становится спокойнее. Команда получает меньше спорных ситуаций после релиза, более понятные сроки и ограничения, защиту от постоянного расширения объема задачи, понятные критерии приемки и меньше задач “в личку” без контекста.
Заказчик тоже выигрывает. Он лучше понимает, из чего складывается работа 1С-команды, где есть ограничения и что нужно сделать со своей стороны, чтобы результат действительно заработал.
Короткий итог
Управление ожиданиями заказчика на 1С-проекте — это не отдельная сложная методология. Это набор простых рабочих привычек: уточнять слово “просто”, спрашивать про пользовательский сценарий, разделять обязательное и желательное, фиксировать границы задачи, спокойно говорить об ограничениях и заранее договариваться о приемке.
В 1С почти любое изменение связано не только с экранной формой или строкой кода. Оно связано с пользователями, правами, отчетами, документами, обменами, инструкциями, релизами и привычками людей.
Чем понятнее договоренности на старте, тем меньше спорных ситуаций появляется после разработки, приемки и релиза.