Есть такой тип задач, от которых у разработчика слегка дергается глаз.
Пользователь пишет: “Не работает отчет. Срочно”.
В описании нет названия базы, нет периода, нет скриншота, нет понимания, что значит “не работает”. Отчет не открывается? Пустой? Цифры не те? Ошибка вылетает? Не хватает строк? Непонятно. Зато задача уже выглядит как пожар, потому что слово “срочно” в ней есть.
Разработчик откладывает свою доработку, выходит из текущего контекста, открывает базу, уточняет пользователя, просит скриншот, смотрит период, лезет в отборы. Через 20–30 минут выясняется: в отчете стояла лишняя галочка. Или выбран старый вариант отчета. Или пользователь смотрел не ту организацию.
Система работала нормально. Данные никуда не пропадали. Код не ломался. 1С просто честно показала результат по тем условиям, которые ей задали.
Формально проблему решили. Пользователь доволен, отчет снова показывает нужные строки, все выдохнули.
Но есть неприятный момент: бизнес только что оплатил работу разработчика не за разработку, не за исправление ошибки и не за улучшение системы, а за первичную проверку пользовательского сценария.
Один раз — мелочь. Второй раз — рабочий шум. Когда таких обращений десятки в месяц, это уже не шум, а отдельная статья расходов.
На моей практике подобных обращений было много. Не “пара забавных случаев”, а вполне заметная доля входящего потока. По ощущениям, до половины вопросов, которые доходят до разработки, сначала могли бы пройти простую проверку: база, пользователь, период, отборы, права, инструкция, статус документа, воспроизведение проблемы.
Именно здесь нужна первая линия поддержки 1С. Не как забор между пользователем и разработчиком. И не как место, где обращение должно умереть в ожидании “правильного оформления”. А как нормальная первая проверка перед тем, как подключать дорогого специалиста.
Первая линия поддержки 1С нужна не для того, чтобы отфутболивать пользователей. Она нужна, чтобы разработчик не разбирал вручную то, что можно проверить до кода: период, отбор, права, инструкцию, статус документа и воспроизведение проблемы.
Пользователь видит одно, разработчик — другое
Пользователь обычно видит только результат.
- Отчет пустой.
- Документ не проводится.
- Нужный документ не найден.
- Печатная форма не формируется.
- В списке пропали строки.
- Процесс непонятен.
- “Раньше было по-другому”.
- “После обновления все сломалось”.
И это нормально. Пользователь не обязан думать как разработчик. Он не сидит с конфигуратором, не смотрит роли, не думает про варианты отчетов, регистры, команды формы и состояние объекта. Он работает в своем процессе: оформляет документ, согласует заявку, ищет данные, проверяет остатки, формирует отчет.
Для него “не работает” — это не технический диагноз, а описание того, что он видит на экране.
Разработчик смотрит на то же обращение иначе. У него почти автоматически включается внутренний список вопросов:
- в какой базе это произошло;
- кто пользователь;
- какие у него роли и права;
- какой именно объект 1С открыт;
- какой выбран период;
- какие стоят отборы;
- какая организация указана;
- какой склад или подразделение выбраны;
- проведен ли документ;
- в каком статусе находится процесс;
- не сохранены ли старые настройки формы или отчета;
- актуальна ли инструкция;
- воспроизводится ли проблема у другого пользователя;
- был ли релиз перед появлением ошибки.
Если каждый раз этот список проходит разработчик, первая линия превращается в пересылочный пункт. Не потому, что там плохие люди. Часто им просто не дали понятный порядок проверки и не объяснили, где заканчивается пользовательский вопрос и начинается задача для разработки.
А без такого порядка любое “не работает” легко улетает к разработчику. Даже если причина находится на уровне отбора в форме списка.
Почему в 1С “не работает” часто начинается не с кода
В 1С редко бывает совсем прямой сценарий: нажал кнопку — получил результат. Почти всегда вокруг есть условия.
Отчет зависит от периода, организации, отбора, варианта отчета, прав пользователя и иногда еще от того, как именно пользователь его открыл.
Документ зависит от заполненных реквизитов, даты, статуса, проведения, маршрута, связанных документов и настроек процесса.
Печатная форма может не формироваться не потому, что “сломалась печать”, а потому что документ еще не в том состоянии или в нем не заполнены данные, которые должны попасть в макет.
Обмен может не пройти из-за кода. А может — потому что регламентное задание не выполнялось, расписание отключили, учетные данные устарели или последняя ошибка давно висит в журнале, но ее никто не открыл.
Поэтому до кода в 1С обычно есть целая лестница простых проверок:
- Пользователь работает в правильной базе?
- Понятно, кто именно столкнулся с проблемой?
- Правильно выбран период?
- Нет ли лишних отборов?
- Та ли организация, склад, подразделение или контрагент?
- Есть ли у пользователя нужные права?
- Документ находится в нужном статусе?
- Все обязательные реквизиты заполнены?
- Сценарий соответствует инструкции?
- Проблема воспроизводится у другого пользователя?
- Проблема воспроизводится в тестовой базе?
И только потом уже имеет смысл говорить: похоже, нужна техническая диагностика.
Если перепрыгивать эту лестницу, разработчик становится дорогой кнопкой “разобраться”. Кнопка удобная, спору нет. Но бизнесу она обходится дороже, чем кажется.
Несколько обычных историй из поддержки 1С
Специально не беру экзотику: падения платформы, хитрые блокировки, странные ошибки расширений или обмены, где без разработчика действительно никуда. Возьмем обычные ситуации, которые в поддержке встречаются постоянно.
“Отчет не сходится”
Пользователь формирует отчет, сравнивает цифры с ожиданием и пишет: “Данные неправильные”.
Разработчик открывает отчет и видит, что выбран не тот период. Или остался старый отбор по подразделению. Или отчет сформирован по одной организации, а пользователь ожидает данные по другой. Иногда еще интереснее: пользователь работает с сохраненным вариантом отчета, который когда-то настраивали под отдельную задачу, а теперь он воспринимается как “обычный отчет”.
Кода тут нет. Есть настройки отчета и невидимый для пользователя контекст.
“Документ пропал”
Фраза “документ пропал” звучит тревожно. Особенно если документ важный, пользователь нервничает, а в переписке уже появляются слова “срочно” и “критично”.
Потом выясняется, что документ есть. Просто в списке стоит отбор по статусу, период начинается с текущего месяца, а документ создан раньше. Или выбран другой склад. Или пользователь смотрит список по своему подразделению, а документ относится к другому.
С точки зрения пользователя документ действительно пропал. С точки зрения 1С он спокойно лежал в базе и никуда не собирался.
“Документ не проводится”
Пользователь нажимает “Провести”, получает сообщение и пишет: “1С не дает провести документ”.
Иногда это реальная ошибка. Но часто система просто не пропускает некорректные данные: не заполнен реквизит, не выбран договор, дата не подходит, статус процесса не тот, предыдущее действие не выполнено.
Первая линия не должна читать код проведения. Но она может открыть текст сообщения, посмотреть заполнение документа, сверить шаги с инструкцией и понять: это техническая ошибка или обычная проверка данных.
“Печатная форма не формируется”
Пользователь ожидает печатную форму, а она не появляется или выходит пустой.
Причина может быть простой: документ еще не проведен, не заполнены нужные поля, выбран не тот шаблон, документ находится не в том статусе процесса.
Если первая линия знает условия формирования печатной формы, разработчику не нужно каждый раз объяснять, что сначала надо заполнить реквизиты и довести документ до нужного состояния.
“Обмен сломался”
С обменами лучше быть осторожнее: там действительно бывают технические ошибки. Но даже здесь первая проверка экономит время.
Выполнялось ли регламентное задание? Когда был последний успешный обмен? Какая последняя ошибка? Проблема у всех документов или у одного? Не менялись ли настройки? Не отключали ли расписание?
Если разработчику прилетает просто “обмен не прошел”, он начнет ровно с этих вопросов. Только его время будет стоить дороже.
Пять минут, которые почему-то превращаются в час
Есть опасная фраза: “Да там разработчику на пять минут”.
Иногда правда на пять. Но чаще эти пять минут выглядят так:
- прочитать задачу;
- понять, что в задаче не хватает половины данных;
- уточнить базу;
- уточнить пользователя;
- попросить скриншот;
- дождаться скриншота;
- открыть нужный объект;
- проверить период;
- посмотреть отборы;
- попробовать воспроизвести;
- написать ответ;
- вернуться к задаче, из которой тебя выдернули.
Последний пункт обычно не считают. А он самый неприятный.
Разработчик мог в этот момент держать в голове кусок запроса, форму, обработчик события, нестандартное поведение расширения, последствия релиза. После переключения все это надо снова собрать. Иногда быстро. Иногда не очень.
Поэтому считать надо не только чистое время “посмотрел отчет”. Считать надо весь кусок внимания, который ушел на обращение.
Возьмем условную модель. Она не претендует на точность для любой компании. Лучше потом подставить свои цифры: реальные обращения за месяц, среднее время разбора, стоимость часа разработчика.
| Показатель | Значение для примера |
|---|---|
| Среднее время на разбор простого непроверенного обращения | 30 минут |
| Время на возврат в рабочий контекст | 15 минут |
| Итого на одно обращение | 45 минут |
| Количество таких обращений в месяц | 50 |
| Итого времени разработки | 37,5 часов в месяц |
Теперь переведем это в деньги.
Для примера возьмем условную стоимость разработчика для компании — 250 000 рублей в месяц. В своей команде лучше подставить реальный ФОТ или хотя бы примерную стоимость часа. В реальности можно учитывать оклад, налоги, взносы, отпускные, рабочее место, управление и другие накладные расходы. Но даже грубый расчет показывает порядок.
| Показатель | Расчет |
|---|---|
| Стоимость разработчика в месяц | 250 000 рублей |
| Рабочих часов в месяце | 168 часов |
| Стоимость часа | примерно 1 488 рублей |
| 50 обращений по 45 минут | 37,5 часов |
| Стоимость времени | примерно 55 800 рублей в месяц |
При 80 таких обращениях получается уже 60 часов. При той же стоимости часа — почти 90 000 рублей в месяц.
И это только прямое время. Здесь нет сдвинутого релиза, отложенного рефакторинга, недоделанной проверки, раздражения команды и эффекта “разработчик всегда на подхвате”.
Самое обидное не в том, что обращение простое. Простые обращения тоже надо решать. Обидно, когда оно приходит к разработчику уже как срочная ошибка, а решается проверкой периода или снятием лишнего отбора.
Что должна проверять первая линия
Первая линия не должна угадывать код. Не должна искать ошибку в общем модуле. Не должна разбираться в сложных запросах, подписках на события, расширениях и обменах на уровне разработчика.
Но она должна уметь отличить техническую проблему от ситуации, где система работает по настройкам, а пользователь не видит этот контекст.
Минимально я бы разделил проверки на две группы.
Первая группа — то, что связано с пользователем и интерфейсом:
- правильная база;
- пользователь;
- права и роли;
- период;
- отборы;
- сохраненные настройки формы;
- вариант отчета;
- скриншот;
- воспроизведение у другого пользователя.
Вторая группа — то, что связано с процессом:
- правильная последовательность действий;
- статус документа;
- заполнение обязательных реквизитов;
- условия проведения;
- условия формирования печатной формы;
- актуальность инструкции;
- известные проблемы после релиза.
Если первая линия прошла эти проверки и не нашла причину, разработчик получает уже не “помогите разобраться”, а нормальную задачу с контекстом.
Чек-лист первой проверки обращения 1С
Этот чек-лист не надо превращать в анкету на 40 полей. Часть пунктов поддержка может проверить сама. Пользователя стоит дергать только там, где без него не обойтись: скриншот, описание действия, фактический результат, срочность, влияние на процесс.
| Что проверить | Зачем это нужно |
|---|---|
| База | Пользователь может работать не в той базе: продуктивной, тестовой, архивной или копии после обновления. |
| Пользователь | “У одного пользователя” и “у всех” — разные задачи. |
| Права или роль | Если у пользователя нет доступа, это не обязательно ошибка разработки. |
| Объект 1С | Документ, отчет, справочник, обработка, форма списка, печатная форма — разные точки диагностики. |
| Период | Одна из самых частых причин пустых отчетов и “пропавших” документов. |
| Отборы | Лишняя галочка легко превращает нормальный отчет в “сломанный”. |
| Организация, подразделение, склад, контрагент | Пользователь может ждать данные в одном разрезе, а смотреть другой. |
| Статус документа | Некоторые действия доступны только в определенном состоянии документа или процесса. |
| Проведение документа | Непроведенный документ может не попадать в отчеты, движения и дальнейшие процессы. |
| Обязательные реквизиты | Документ может не проводиться из-за незаполненного поля, а не из-за ошибки кода. |
| Скриншот | Скриншот часто экономит несколько кругов уточнений. |
| Инструкция | Если сценарий уже описан, разработчик не должен каждый раз объяснять его заново. |
| Похожая проблема раньше | Возможно, решение уже есть в базе знаний или старой задаче. |
| Воспроизведение у другого пользователя | Помогает отличить персональную настройку от общей ошибки. |
| Недавний релиз | Если проблема появилась после обновления, это важный сигнал для разработки. |
Когда звать разработчика
Чтобы не было перекоса, важно сказать и обратное: разработчика нужно подключать. Просто не на каждую фразу “у меня не работает”.
Ниже примерная таблица, которую можно адаптировать под свою команду.
| Симптом от пользователя | Что проверить первой линии | Когда передавать разработчику |
|---|---|---|
| “Не работает отчет” | Период, отборы, организацию, подразделение, права, настройки отчета, вариант отчета. | Если на корректных отборах отчет формируется неправильно у нескольких пользователей или после релиза. |
| “Не вижу документ” | Период списка, отборы, статус документа, организацию, подразделение, права пользователя. | Если документ есть в базе, условия корректны, но он не отображается там, где должен. |
| “Не вижу данные” | Период, склад, подразделение, контрагента, статус документа, сохраненные фильтры, доступ к данным. | Если данные есть, права корректные, отборы сняты, но форма или отчет показывает неверный результат. |
| “Документ не проводится” | Заполнение обязательных реквизитов, дату, статус, права, текст сообщения при проведении. | Если документ заполнен корректно, процесс соблюден, но проведение падает с технической ошибкой. |
| “Помогите разобраться в процессе” | Инструкцию, актуальный сценарий, статус документа, следующий шаг процесса, ответственного. | Если инструкция противоречит реальной работе системы или процесс изменился после доработки. |
| “Не формируется печатная форма” | Статус документа, заполнение реквизитов, права, выбранный шаблон, наличие данных для вывода. | Если все условия выполнены, но печатная форма падает с ошибкой или формируется некорректно. |
| “После релиза стало не так” | Что именно изменилось, есть ли описание релиза, воспроизводится ли в тестовой базе, у кого возникает. | Если изменение не описано, ломает согласованный сценарий или воспроизводится как дефект. |
| “Обмен не прошел” | Регламентное задание, расписание, последние ошибки, доступность настроек, дату последнего успешного обмена. | Если задание выполнялось, настройки корректны, но обмен падает с технической ошибкой. |
Плохая задача и нормальная задача
Плохое обращение выглядит так:
“Не работает отчет. Посмотрите”.
Для пользователя фраза понятная. Для разработчика — нет.
Какая база? Какой отчет? Какой период? Какой пользователь? Что значит “не работает”: не открывается, пустой, ошибка, неверные цифры, зависает, нет доступа? Какие отборы? Есть ли скриншот? У другого пользователя так же? Это появилось после релиза или было всегда?
Такое обращение не передает задачу. Оно передает тревогу.
Нормальное обращение выглядит иначе:
В базе “Рабочая база” пользователь Иванов И.И. в отчете “Ведомость по документам” за период 01.06–18.06 не видит документы по подразделению “Отдел продаж”. Отборы проверены, лишних фильтров нет. Организация выбрана корректно. У пользователя Петрова П.П. с аналогичными правами результат такой же. Скриншоты приложены. По инструкции пользователь выполняет сценарий корректно. Проблема появилась после релиза от 17.06.
Вот это уже задача. Разработчику не нужно начинать с пустого места. Он видит объект, сценарий, пользователя, период, результат проверки и связь с релизом.
Шаблон задачи разработчику
Этот шаблон можно забрать в трекер или базу знаний. Не обязательно заполнять все поля на каждую мелочь, но для передачи в разработку такой набор сильно экономит время.
| Поле | Что указать |
|---|---|
| База | Рабочая, тестовая, копия, архивная. |
| Пользователь | Кто столкнулся с проблемой. Желательно с указанием роли или группы доступа. |
| Объект 1С | Документ, отчет, справочник, обработка, форма, печатная форма, процесс. |
| Описание сценария | Что пользователь делал по шагам. |
| Ожидаемый результат | Что должно было произойти. |
| Фактический результат | Что произошло на самом деле. |
| Скриншот | Ошибка, форма, отборы, период, результат отчета. |
| Шаги воспроизведения | Кратко и по порядку. |
| Что уже проверили | Период, отборы, права, инструкцию, другого пользователя, тестовую базу. |
| Когда возникло | Дата и время, если важно. |
| Связь с релизом | Было ли обновление, доработка, изменение процесса. |
| Срочность и влияние | Один пользователь не может выполнить действие или остановлен важный процесс. |
Плохо / лучше
Иногда достаточно поменять формулировку обращения, чтобы убрать половину лишних уточнений.
| Плохо | Лучше |
|---|---|
| “Не работает отчет”. | “В отчете ‘Ведомость по документам’ за период 01.06–18.06 по организации ООО ‘Тест’ не отображаются данные по подразделению. Отборы проверены, скриншот приложен”. |
| “Не вижу документ”. | “Пользователь не видит документ №123 от 18.06 в списке. Период расширили, отборы сняли, склад и подразделение проверили”. |
| “Документ не проводится”. | “Документ не проводится. Обязательные реквизиты заполнены, статус корректный, текст ошибки на скриншоте”. |
| “Пользователь не понимает процесс”. | “Пользователь выполняет шаг 3 по инструкции, но в текущей версии системы нужное действие отличается. Нужно проверить актуальность инструкции или процесса”. |
| “После релиза что-то сломалось”. | “После релиза от 17.06 в форме документа при выполнении действия появляется ошибка. В тестовой базе воспроизводится, скриншот и шаги приложены”. |
Граница ответственности
Здесь легко уйти в крайности.
Первая крайность: все сразу отправлять разработчику. Тогда разработчик становится первой линией, аналитиком, консультантом по процессу и только иногда разработчиком.
Вторая крайность: заставить первую линию держать обращение до последнего, даже когда уже понятно, что там техническая ошибка. Так тоже не надо.
Нормальная схема проще.
| Роль | Зона ответственности |
|---|---|
| Первая линия | Проверить базовые условия: база, пользователь, период, отборы, права, инструкция, скриншоты, воспроизведение. Закрыть типовые вопросы по инструкции. |
| Аналитик | Может быть частью первой линии. Помогает, если вопрос связан с бизнес-процессом, требованиями, логикой работы или изменением сценария. |
| Разработчик | Подключается, когда проблема похожа на ошибку реализации, технический дефект, проблему после релиза, некорректную работу доработки или сбой механизма. |
| Руководитель процесса | Организует работу с обращениями, следит за повторяющимися проблемами, запускает обучение пользователей, актуализирует инструкции, проводит короткие разборы. |
Если десять человек не понимают один и тот же статус документа, проблема уже не только в пользователях. Возможно, инструкция написана плохо. Возможно, статус называется так, что его понимает только автор процесса. Возможно, сценарий слишком хитрый и требует нормального объяснения.
В таких местах первая линия полезна не только как фильтр. Она видит повторяемость. А повторяемость — это уже сигнал руководителю процесса: надо учить, переписывать инструкцию, менять настройки по умолчанию или дорабатывать интерфейс.
Ошибки первой линии
Первая линия тоже может работать плохо. Тогда она не помогает, а добавляет еще один слой хаоса.
Типовые ошибки знакомые:
- поверили описанию “на словах” и не попросили скриншот;
- не уточнили базу;
- не проверили период;
- не посмотрели отборы;
- не зафиксировали пользователя;
- не проверили права;
- не открыли инструкцию;
- не попытались воспроизвести проблему;
- передали разработчику сообщение без контекста;
- сделали вывод “это ошибка” только потому, что пользователь так сказал;
- начали спорить с пользователем вместо диагностики.
Но обвинениями это не лечится. Если первая линия пропускает базовые вещи, часто причина не в лени. Людям могли не дать инструкции, не показать типовые примеры, не объяснить, какие вопросы задавать и когда можно передавать задачу дальше.
Хорошо работает простой формат: раз в неделю взять несколько задач, которые зря дошли до разработчика, и спокойно разобрать, что можно было проверить раньше. Без поиска виноватых. Просто как обучение на реальных примерах.
Как не сделать из поддержки таможню
Есть обратная опасность: можно так увлечься чек-листами, что пользователь будет чувствовать себя не клиентом поддержки, а человеком, который проходит контроль перед входом в 1С.
Плохая первая линия звучит так:
“Заполните все обязательные поля, иначе обращение не будет рассмотрено”.
Хорошая первая линия звучит иначе:
“Чтобы быстрее разобраться, пришлите, пожалуйста, скриншот с отбором и периодом. Часто причина именно там. Если не поможет — передадим разработчику уже с полной информацией”.
Разница большая.
Цель не в том, чтобы пользователь прошел квест. Цель в том, чтобы быстрее решить проблему и не гонять ее между людьми.
Часть информации первая линия может собрать сама: посмотреть права, проверить инструкцию, открыть тестовую базу, воспроизвести сценарий, найти похожую задачу в трекере.
Пользователя стоит просить только о том, что без него действительно не получить: скриншот, описание действия, фактический результат, срочность, влияние на процесс.
База знаний вместо повторных вопросов
Без базы знаний первая линия быстро превращается в пересылочный пункт. Вроде люди есть, обращения принимаются, но почти все равно уходит дальше.
Чтобы первая линия реально помогала, в базе знаний должны быть не красивые регламенты на 40 страниц, а рабочие материалы:
- инструкции по основным процессам;
- частые причины “не вижу данные”;
- частые причины “не проводится документ”;
- описание ключевых статусов документов;
- таблица “симптом — что проверить”;
- список ответственных по процессам;
- правила оформления задач разработчику;
- шаблоны обращений;
- известные проблемы после релизов;
- короткие памятки по отчетам и отборам.
Лучшие материалы для базы знаний рождаются не из желания “написать регламент”, а из повторяющихся обращений.
Если пользователи регулярно не видят документы из-за отбора по статусу — нужна короткая памятка. Если путаются в процессе — нужен короткий разбор сценария. Если после каждого релиза идут одни и те же вопросы — надо заранее готовить понятное описание изменений.
Иногда один короткий митап на 20 минут экономит больше времени, чем десятки отдельных ответов в поддержку.
Первая линия не заменяет разработчика
Важный момент: первая линия не отменяет разработчика.
Разработчика нужно подключать, когда есть техническая ошибка, сломанный сценарий, некорректная работа доработки, проблема после релиза, падение обмена, ошибка в форме, запросе, обработчике, печатной форме или логике проведения.
Но задача для разработки — это не любое сообщение со словом “1С”.
Если разработчик регулярно разбирает периоды, отборы и инструкции, это не гибкость команды. Это плохо настроенный входящий поток.
Разработчик должен заниматься кодом, сложной диагностикой и изменением логики. А не каждый раз выяснять, что пользователь смотрел отчет за прошлый месяц и забыл снять отбор.
Как начать без большого внедрения
Не обязательно начинать с большого регламента, отдельного проекта и красивой схемы поддержки.
Можно сделать проще:
- Взять 20–30 последних обращений в 1С.
- Разделить их на группы: отборы, права, инструкции, процесс, реальные ошибки, доработки.
- Посчитать, сколько из них можно было проверить до разработчика.
- Сделать короткий чек-лист первой проверки.
- Добавить шаблон задачи в трекер.
- Разобрать с первой линией 5–10 реальных примеров.
- Собрать базу знаний из повторяющихся вопросов.
- Раз в месяц смотреть, какие обращения повторяются.
Если сегодня разработчику прилетает “не работает отчет”, а через месяц ему прилетает “отчет такой-то, период такой-то, отборы проверены, скриншот приложен, у другого пользователя воспроизводится” — это уже хороший результат.
Это не подвиг и не зрелый ITSM. Это обычная гигиена входящих обращений в 1С-команде.
Итог
Хорошая первая линия — это не та, которая никого не пускает к разработчику. А та, после которой разработчику не нужно начинать расследование с вопроса: “А какой вообще отчет смотрели?”
В 1С много ситуаций, где проблема выглядит как ошибка системы, но на деле оказывается периодом, отбором, правами, статусом документа, настройкой пользователя, регламентным заданием или инструкцией.
Если такие обращения сразу отправлять разработчику, бизнес платит дважды: сначала деньгами за время дорогого специалиста, потом сроками задач, которые разработчик не сделал, потому что разбирался с лишней галочкой.
Разработчик должен подключаться там, где действительно нужен код, техническая диагностика или изменение логики. А период, отбор, инструкцию, пользователя, скриншот и воспроизведение проблемы можно и нужно проверять раньше.
Одна лишняя галочка в отборе — мелочь. Но если такие мелочи каждый день разбирает разработчик, это уже не мелочь, а регулярная статья расходов.