Какие вопросы описаны ниже:
1. Кто сообщает об ошибке, в какой форме?
2. Кто обрабатывает ошибку?
3. Какую информацию необходимо сообщить, чтоб собеседнику стало понятно, о чём речь?
4. Правило 3-х вопросов. О чём это?!
5. Кто всё это будет описывать???
6. Дополнительные возможности платформы для облегчения взаимопонимания.
Давайте рассмотрим типичную для мира 1С ситуацию... У пользователя возникла ошибка! Почти всегда, вне зависимости от масштабов ошибки, - это трагедия! Кто-то совершил преступление (ошибся), и его надо наказать!
Люди опытные понимают, что виновен почти всегда пользователь! Но бывают исключения.
Итак, пользователь сообщает нам об ошибке... Как он это обычно делает?
1. Проще всего позвонить на первую линию консультаций. В моём опыте почти все считают архитектора или РП той самой первой линией консультаций)
2. Пишут письмо, в котором из полезной информации максимум скриншот!
3. Если первая линия консультаций рядом - её зовут к себе. Если гора не пошла к Магомеду, то тётя Галя пошла к горе!
4. Пользователи между собой обсуждают ошибку. При хороших обстоятельствах ошибка решается сама собой. Но это редкость!
5. Очень модно в Whats App или в Telegramm сфоткать ошибку и отправить. Разбирайся как хошь!
Конечно же, никто не станет читать инструкцию! Нормальный человек, особенно в РФ, пока ничего не сломал, в неё смотреть не станет!
Разберемся с вопросом: "Кто обрабатывает ошибку"?
1. Звонят руководителю проекта/архитектору. Такую линию консультаций необходимо по возможности отсекать. НО! Бывает, звонят привилегированные пользователи, которым отказать сложно)
2. Звонок/письмо на линию консультаций. Это практически идеальный вариант. Начинает работать маршрутизация для подобных задач.
3. На демонстрации доработок аналитику/консультанту сообщают об ошибке.
4. Тестировщик находит ошибки при прохождении сценариев работы.
Для того, чтобы описанный бардак привести в нормальное состояние, необходимо установить правило:
Главное - сценарий работы!
Второе важное правило - ошибку нужно задокументировать!
Какую информацию необходимо сообщить, чтоб собеседнику стало понятно, о чём речь?
1. Уже выяснили, что это сценарий работы. НО! Он должен состоять не из фраз:
-- Я тут вот зашла и нажала кнопку...
-- В окошке выбрала сотрудника/контрагента/номенклатуру и вылезла ошибка...
Это всё из разряда "Вдруг, как в сказке, скрипнула дверь. Всё мне стало ясно теперь!"
Сценарий - это:
- Названия конкретных объектов метаданных
- Последовательность заполнения реквизитов, с указанием значений заполнения
- Последовательность нажатия кнопок.
2. Нужен контрольный пример! Объяснять на пальцах/калькуляторе затея бесполезная! Запомнить почти нереально. Часто слышу такое:
-- Ну в письме же есть скриншот!
-- Я же сказала Вам фамилию/название контрагента или номенклатуры
3. Нужны скриншоты. ОБЯЗАТЕЛЬНО! Часто по одному скриншоту всё ясно.
4. Ссылки на проблемные объекты. При большом объёме справочной информации и документооборота тяжело найти пример, на который указывает пользователь. В последней части статьи описано подробнее.
5. Иногда нужно изучить ЛНД/закон, чтоб понять ошибку и исправить её. Необходимо указать: какой ЛНД/закон почитать.
Получается уже не так-то просто! То ли ещё будет)
Правило 3-х вопросов. О чём это?!
Для чёткого понимания со всех сторон баррикад, прошу "гонца" с ошибкой ответить на 3 простых вопроса:
1. В чём заключается ошибка?
2. Почему Вы решили, что это неправильно?
3. Как должно быть правильно? Вот тут нужен контрольный пример!
При ответе на второй вопрос половина ошибок пропадают сами собой! Не стоит забывать, что пользователь не всегда в курсе как должно быть. При обсуждении этого вопроса, оказывается, что ошибки-то и нету)))
Мы подошли к самом интересному: Где же взять пользователя, который согласен всё это описать?))) Кто должен это описывать?
Начну с того, что не каждая ошибка, конечно же, требует такого количества информации.
Но там, где это требуется, должен быть небольшой регламент работы для первой линии консультаций/аналитиков/тестировщиков.
Именно они и должны сделать нормальное описание ошибки. В процессе его составления часть задач решится простой консультацией, часть доработкой инструкций.
Лишь малая часть попадёт к разработчикам. И вот те задачи, которые попадают к разработчикам, должны быть описаны максимально детально!
Попросить пользователя ответить на 3 озвученных вопроса можно и в личной беседе, и в регламенте прописать.
Дополнительные возможности платформы для облегчения взаимопонимания.
Как ни странно, большинство пользователей (и не только!) не знает, что можно кинуть ссылку на проблемный объект метаданных и не объяснять, где его искать.
О чём речь?
В любом объекте метаданных есть показанный на скрине значок. Нажатие на него приводит к такому результату:
Скопированный текст нужно отправить аналитику/разработчику. Они быстрее найдут нужны элемент справочника/документ, и скажут, в чём ошибка.
Если Вам прислали абракадабру, её нужно вставить сюда:
и нажать Перейти
Обмен такими ссылками сильно ускоряет процесс, особенно при большом количестве обращений.
Также можно дать ссылку на отчет, обработку, список документов и т.д. Не нужно помнить, в каком меню это находится.
Пройдя этот тернистый путь, Вы наверняка сможете объяснить собеседнику, в чём же ошибка.
Собеседник в свою очередь сможет максимально оперативно решить Вашу проблему. Ведь для того мы и работаем, чтобы не тратить лишнее время на простые операции!
Есть ещё один плюс использования ссылок. Иногда приходится работать с обфусцированными данными. Тогда пользователь не может назвать ФИО/Название контрагента или товара. Ибо оно выглядит так же непонятно, как и ссылка на объект. Если передать ссылку, то она в любом случае откроется! И будет понятно, на каком примере можно проверить ошибку.
Все эти советы позволят сохранить или наладить хорошее взаимопонимание в команде проекта.
Напомню ранее написанные статьи с общим названием "Ни в ЗУП ногой?! А мне нравится!":
1. Главные сложности решения, что отталкивает?
Статьи под общим названием "Как читать чужой код?":
Часть 1. Общие вопросы. Доработка чужого кода. Code review.
Статья про роль и значимость архитектора на проекте:
1. Кто такой архитектор. Редакция 2!
Полезные обработки:
Пример работы с файлами odt в клиент-серверной модели работы
