Что такое качество разработки и качество поддержки? Статья 2

30.06.20

Управление ИТ - Help desk: Служба поддержки

Это вторая из 8 статей про разработку в сфере 1С. В данной статье будут раскрыты следующие вопросы: 1. Ошибки в решениях в пользовательском режиме и их причины. 2. Технические ошибки при разработке решений в 1С. 3. Мы закрыли 100 заявок за 1 день. Есть ли польза от такой поддержки? Польза или вред от SLA.

Качество любой разработки можно оценить по 2 параметрам:

    • Нет ошибок со стороны пользовательского интерфейса.
    • Решение не содержит технических ошибок.

 

  1. Ошибки в решениях в пользовательском режиме и их причины.

 

Перечислим часто встречающиеся проблемы:

  1. Учтены не все сценарии работы. Очевидно, что это ошибка архитектора или аналитика, который выполнял обследование, описывал сценарии работы и ставил задачу разработчику.
  2. При наличии формул выдается неверный результат вычисления. Данная проблема возникает при некачественном тестировании со стороны разработчика и консультанта. Иногда разработчик не обладает достаточными компетенциями для проведения качественного тестирования. В данном случае контрольные примеры ему должен создать консультант или аналитик.
  3. При открытии пользовательской формы объекта метаданных (документа, справочника, отчета, обработки) вылетает ошибка. Это самая постыдная ошибка. Говорит она о том, что после последних изменений доработка не тестировалась. Это говорит о низком уровне ответственности со стороны разработчика и излишней его самоуверенности.
  4. Не удобный интерфейс. Не каждый разработчик способен спроектировать качественный интерфейс. Для этого предназначен этап Design review. Качественный интерфейс должен помочь пользователю решить следующие задачи:
    • Быстро ввести минимальный набор информации для работы механизма
    • Не допустить ошибок при вводе данных, заполнить все обязательные поля.
    • Быстро проанализировать уже введенные данные.
  5. Данные приходится вводить в двух разных объектах, или наоборот получать двумя отчетами. Такая проблема появляется, когда связанные задачи решают разные аналитики и разработчики. Если проектированием занимается архитектор – это показатель нехватки опыта в проектировании сложных механизмов.

 

  1. Технические ошибки в решениях, их причины и последствия для проекта.

 

Перечислим часто встречающиеся проблемы:

  1. Запросы написаны не оптимально. Данная ошибка встречается наиболее часто при проведении Code review. Данный этап проверки очень важен, т.к. напрямую влияет на производительность системы. Бывает, что сервер падает от неоптимального запроса. Проводит проверку архитектор проекта (системный), владеющий компетенциями по оптимизации запросов. На производительность максимальное влияние оказывают следующие ошибки:
    • Запросы в циклах. Иногда вызывается в цикле процедура либо функция, которая выполняет запрос.
    • Использование физической таблицы вместо виртуальной таблицы. Запрос к физической таблице выполняется в разы дольше, чем к виртуальной таблице. При этом выбирается больше ненужных данных.
    • Многократное обращение к одному и тому же источнику данных в рамках пакета запросов.
    • Неверное использование индексов при написании параметров виртуальных таблиц, связей между таблицами и условий запроса.
    • Отсутствие индексов при использовании больших временных таблиц, либо лишние индексы.
  2. Не используется программный интерфейс. Существующий в типовых конфигурациях программный интерфейс позволяет выполнять типичные для конфигурации действия без добавления новых процедур и функций. Программный интерфейс учитывает всегда большое количество сценариев и оптимизирован, насколько это возможно. Создание новый процедур и функций приводит к дублированию функционала, и не каждый разработчик способен написать лучше. Адаптация программного интерфейса под конкретную задачу занимает несколько часов. Написание «с нуля» может занять несколько недель.
  3. Типовые процедуры и функции выносятся в новые модули и там меняются. Часто встречаю ситуации, где разработчик скопировал типовую процедуру и меняет её в новом модуле. Так сказать, чтоб не обновлять потом это место. В данной ситуации забывают, что скопированная процедура имеет ссылки на процедуры и функции общих модулей. В типовых конфигурациях очень часто происходит смена местоположения процедур и функций и изменение количества параметров. Некоторые удаляют вовсе. Скопировав типовую процедуру, вы делаете данный участок кода не обновляемым. Никто не знает, что Вы её заимствовали. Следовательно, при обновлении на новый релиз её не обновят, и Ваш функционал перестанет работать! Такие ошибки выявляются на этапе Code review архитектором проекта.
  4. Неверное использование блокировок и привилегированного режима работы. Новые тенденции среди разработчиков:
    • При выполнении запроса к регистрам накопления включать блокировку. Возникает вопрос: ЗАЧЕМ? В реальности сценариев, при которых она нужна – единицы, а используют повсеместно! Нужно анализировать. Есть ли пользователи, которые могут изменить данные, которые ввел другой пользователь? Чаще всего зоны ответственности разграничены между пользователями и пересечение невозможно. Следовательно, и блокировка не нужна! Есть ещё ситуации, описывать все не буду. Важно использовать блокировку только там, где она влияет на результат запроса!
    • При записи или чтении данных используют привилегированный режим. Якобы некогда разбираться какие права у пользователя, проще записать или прочитать без учета прав. Такой подход  крайне негативно проявляется при использовании RLS. Допустимо это использовать на этапе тестирования функционала, но в релизной версии это недопустимо.
  5. Несоблюдение стандартов разработки. Об этом будет отдельная статья. Это одна из самых больших проблем на текущий момент. Из 10 разработчиков стандарты соблюдают в лучшем случае 2. Троих ещё можно убедить в необходимости их соблюдения. Примерно половина людей, называющих себя разработчиками категорически против стандартов. Чаще всего от  таких слышишь – оно же работает?! Это и выясним в отдельной статье.

 

  1. Как определить качество поддержки? Помогает ли в этом популярный SLA.

 

Чтобы оценить качество поддержки, необходимо разобраться, что это такое? Всем известно о наличии 3-х линий поддержки.

Первая линия поддержки решает следующие задачи:

    • Фиксация потребности в поддержке. Оформление заявки. Обсуждение проблемы с заказчиком. На этом данный этап уже должен закончиться! Не нужно сразу давать ответ по заданному вопросу. Необходимо ввести пример в пользовательском режиме, посмотреть актуальную пользовательскую инструкцию по данному вопросу.
    • Ответ на простые обращения пользователя, в правильности которых сотрудник первой линии уверен. Если в инструкции найден четкий ответ на заданный вопрос, его необходимо озвучить клиенту. При этом необходимо дать ссылки на инструкции.
    • Обеспечение второй линии поддержки дополнительной информацией по сложным вопросам, а также по требующим разработки задачам. Этот этап возникает, если решить вопрос не удалось, либо по заявке требуется доработка. Задача сотрудника первой линии поддержки составить:
  • Максимально подробное описание проблематики;
  • Указать сценарии, для которых актуально обращение;
  • Приложить скриншоты.

 

Чего первая линия поддержки делать НЕ должна:

    • Отвечать на вопросы «по памяти» и «с лёту». Это характеризует не уровень знаний, а уровень безответственности! Ответ на вопрос мог измениться. Например, в связи с изменением концепции и последующей доработкой системы.
    • Стараться закрыть обращения по более сложным вопросам. Для этого есть вторая линия! Задача их обеспечить максимальным количеством информации и сработать как команда. Не надо пытаться «заработать очки»! Вопросы, по которым первая линия может давать консультации, а по которым должна передавать на вторую линию должны быть регламентированы. Всё зависит от предметной области и используемой типовой конфигурации.
    • Не писать ТЗ для разработчиков. Этого делать ни в коем случае нельзя! Связано это с уровнем знаний и навыков первой линии. Обычно это сотрудники с маленьким опытом работы.
    • Не давать ответов по методологическим вопросам! Для этого на проекте есть методолог или архитектор.

Вторая линия поддержки решает следующие задачи:

    • Ответы на более сложные вопросы по описанию от первой линии. Сотрудник второй линии (при необходимости) выясняет недостающие детали у первой линии или у заказчика.
    • Составление ТЗ на разработку. Для этого может потребоваться анализ данных в рабочей базе и консультации с заказчиком. Методологические вопросы необходимо обсудить с методологом. Предлагаемое решение требуется согласовать с архитектором.
    • Актуализация инструкций и FAQ. Это существенно упрощает работу первой линии и повышает качество её работы.

 

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

 

Из всего описанного можем выделить критерии качества поддержки:

  1. Каждая линия поддержки дает грамотный проверенный ответ, старается решить задачу качественно.
  2. Если возникают сложности, необходимо описать всё, что необходимо и передать на следующую линию.
  3. Все линии поддержки соблюдают регламент, и каждая линия решает свой круг вопросов.
  4. Обращение закрывается только после решения вопроса, а не потому, что срок работы по заявке подходит к концу.

Как видно из критериев, срок закрытия заявок и их количество, которые являются основной для расчета SLA, никоим образом не говорят о качестве поддержки.

Качество разработка SLA поддержка 1-я линия 2-я ошибки программирование проект управление проектом разработчик консультант технические

См. также

Help desk: Служба поддержки Бизнес-аналитик Бесплатно (free)

Чтобы снизить нагрузку на техподдержку, к готовому продукту всегда должна прилагаться документация. Но как сделать, чтобы инструкция была понятной и полезной, а ее разработка и актуализация не затянулись на несколько месяцев? Разберем вопрос рациональности использования стандартов и наиболее доходчивые варианты стилистики, организации структуры, детализации при написании инструкций.

24.09.2024    2942    0    chavalah    19    

19

Help desk: Служба поддержки Бесплатно (free)

Часто в холдинговых структурах организуют единый центр обслуживания для обработки обращений сотрудников по работе с ИТ, бухгалтерией, отделом обучения и т.д. О том, как внедрить сервисный подход в бэк-офисе, и какие инструменты помогут эффективно закрывать потребности бизнеса и укладываться в SLA, пойдет речь в статье.

29.01.2024    846    0    user1063453    0    

4

Help desk: Служба поддержки Бесплатно (free)

Расскажем, как оптимизировать первую линию, чтобы она работала как часы. Также покажем, как с помощью тикет-системы уменьшить количество звонков в техподдержку и почему со звонками в компании на 4500 тысяч сотрудников справится один человек.

29.01.2024    1092    0    user1063453    1    

2

Help desk: Служба поддержки ITIL Бесплатно (free)

Для качественной организации техподдержки в компании важно обеспечить у ITSM-портала все необходимые функции, соответствующие уровню зрелости ИТ. Чек-лист по текущим тенденциям, которые можно выделить в построении портала (системы) обслуживания пользователей, представим в статье.

29.01.2024    1132    0    user1063453    0    

1

Сопровождение Help desk: Служба поддержки Бесплатно (free)

Исполнительный директор компании «Гильдия консультантов» Николай Елатонцев на конференции Infostart Event 2021 Post-Apocalypse рассказал, как организовать процессы техподдержки, чтобы это направление бизнеса стало прибыльным и прогнозируемым. Он поделился опытом, как правильно составить договор на техподдержку, зачем фиксировать каждую транзакцию по задаче, и как уведомления помогают в исполнении SLA.

13.03.2023    2433    0    nelatontsev@webgk.ru    8    

13

Help desk: Служба поддержки Бесплатно (free)

ITIL – одно из популярных руководств по управлению ИТ-услугами и выстраиванию эффективного менеджмента. Появилась уже четвертая версия этой библиотеки, и по сравнению с прошлыми в ней много нового, в том числе для Service desk. О том, что изменилось, рассказал автор учебных курсов по управлению ИТ-услугами и тематических публикаций в периодических изданиях, автор и переводчик книг по управлению ИТ, архитектор ITIL 4 Роман Журавлев.

29.10.2021    7138    0    user1455784    0    

10

Help desk: Служба поддержки Бизнес-аналитик Руководитель проекта Бесплатно (free)

Проекты - это, конечно, важно, с завершением проекта внедрения, жизнь прикладного решения, на самом деле, только начинается. И самое интересное еще только впереди… Не случайно в Agile все чаще говорят о “гибком управлении продуктом”, а вовсе не только “проектом”.

20.08.2020    5009    0    MariaTemchina    4    

26

Help desk: Служба поддержки Бесплатно (free)

Чем больше услуг для внешних и внутренних клиентов предлагает бизнес, тем сложнее их обслуживать. Правильный выход в такой ситуации – создать сервисную техническую службу, благо, примеров создания такой структуры очень много. Но даже если вы возьмете лучшие практики и внедрите их у себя, это не значит, что проект «Служба технической поддержки» взлетит. Почему лучшие практики не работают, участникам конференции INFOSTART EVENT 2019 Inception объяснил руководитель службы технической поддержки в группе компаний «Доброфлот» Арсен Сазандрашвили.

03.04.2020    8241    0    Arsen1986    3    

11
Отзывы
4. awk 744 30.06.20 17:38 Сейчас в теме
(3)
Учтены не все сценарии работы

Это не ошибка аналитика или архитектора. Это ошибка заказчика. Т.к. приемку проводил он, задачи согласовывал он и описывал задачи то же он (или его представитель). Здесь аналитик или архитектор лишь интерпретаторы.
При наличии формул выдается неверный результат вычисления. Данная проблема возникает при некачественном тестировании со стороны разработчика и консультанта.
Разработчик не может проводить тестирование. И консультант (в идеале) то же (где ж ты идеал?).
При открытии пользовательской формы объекта метаданных (документа, справочника, отчета, обработки) вылетает ошибка. Это самая постыдная ошибка. Говорит она о том, что после последних изменений доработка не тестировалась. Это говорит о низком уровне ответственности со стороны разработчика и излишней его самоуверенности.
Это наиболее частая ошибка при командной разработке. Говорит о неправильном процессе разработки.
Данные приходится вводить в двух разных объектах, или наоборот получать двумя отчетами. Такая проблема появляется, когда связанные задачи решают разные аналитики и разработчики. Если проектированием занимается архитектор – это показатель нехватки опыта в проектировании сложных механизмов.
Это не ошибка, а следствие не правильно выбранного продукта. Кода для магазина из одного человека берут, например, ERP.
Запросы написаны не оптимально
Не оптимально для чего? Как это можно выявить на этапе кодеревью, а не на этапе нагрузочного тестирования (где ты идеал в реальной жизни?)?
Запросы в циклах
Это не всегда зло.
Запрос к физической таблице выполняется в разы дольше, чем к виртуальной таблице
Это трэш. Виртуальная таблица, на то и виртуальная, что строится из реальной и нигде не хранится. Потому запрос к виртуальной таблице есть ни что иное как запрос или несколько запросов к реальной таблице или таблицам.

Последние два замечания зависят от контекста появления. Это может как быть ошибкой, так и не быть ею.

Использование физической таблицы вместо виртуальной таблицы. Запрос к физической таблице выполняется в разы дольше, чем к виртуальной таблице. При этом выбирается больше ненужных данных.
Выделенная фраза вообще не зависит от реальности или виртуальности таблиц.

Многократное обращение к одному и тому же источнику данных в рамках пакета запросов.
Что такое источник данных в пакете запросов? Почему к нему надо обращаться однократно?

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

То есть кнопки "Проверка модулей" и "Расширенная проверка" - это что то таинственное, загадочное и не знакомое? Они решают 95% таких ситуаций, а остальные 5% можно решить написанием модульных тестов (где ты идеал в реальной жизни?).

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

Из всего описанного можем выделить критерии качества поддержки:

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

Как объективно определить: "грамотность", "старание", "зарытие при подходе времени"?

срок закрытия заявок и их количество, являются основной для расчета SLA

Нет. Это объективные измеримые показатели, а SLA - это контракт, между поставщиком и потребителем услуги. Каждый такой контракт индивидуален. Поэтому нельзя внеконтекста ответить на вопрос: "Помогает ли в этом популярный SLA?".

Вообще о чем статья я так и не понял. Об ошибках разработки или задачах поддержки?

Что такое качество - не раскрыто.
Почему не приведены определения? Например:

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

ГОСТ 15467-79
Качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя

ИСО 8402—86
Качество — степень соответствия совокупности присущих характеристик объекта требованиям

ГОСТ Р ИСО 9000-2015
d4rkmesa; SirYozha; olgun4ik99; tamepjlah; proglex; alest; for_sale; karpik666; biimmap; +9 Ответить
Остальные комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. barelpro 1431 30.06.20 12:02 Сейчас в теме
Маловато про технические ошибки написано. Понятно что статья обзорная, на это можно сделать скидку.

Например сказано про индекcацию в запросе, но ничего про индексацию таблиц данных. Хотя здесь тоже можно перестараться, и в попытке тотально избавиться от table scan покрыть все поля индексами , что в итоге приведет к обратному эффекту - замедлит запись и увеличит объем базы.

Про быстродействие интерфейсов ничего не сказано, хотя визуальная скорость открытия форм - первое на что обращает внимание пользователь и ухудшает апдекс. Тут и тяжелые расчеты при открытии, и использование серверных процедур вместо клиентских или серверных без контекста, и неоптимальные запросы в динамическом списке. Мало кто используется фоновые задания и кеширование. В общем обширное поле для творчества.
2. awk 744 30.06.20 15:50 Сейчас в теме
Блин, ну как так? Такая хорошая первая часть и такое во второй части. Единственное место с которым согласен это пункт 3, до слов "Из всего описанного можем выделить критерии качества поддержки". Если автору интересно могу расписать...
3. barelpro 1431 30.06.20 16:29 Сейчас в теме
(2) Ну что уж тут жалеть, каждый делиться своим опытом, кто что успел пройти.
Мне интересно, распишите пожалуйста
4. awk 744 30.06.20 17:38 Сейчас в теме
(3)
Учтены не все сценарии работы

Это не ошибка аналитика или архитектора. Это ошибка заказчика. Т.к. приемку проводил он, задачи согласовывал он и описывал задачи то же он (или его представитель). Здесь аналитик или архитектор лишь интерпретаторы.
При наличии формул выдается неверный результат вычисления. Данная проблема возникает при некачественном тестировании со стороны разработчика и консультанта.
Разработчик не может проводить тестирование. И консультант (в идеале) то же (где ж ты идеал?).
При открытии пользовательской формы объекта метаданных (документа, справочника, отчета, обработки) вылетает ошибка. Это самая постыдная ошибка. Говорит она о том, что после последних изменений доработка не тестировалась. Это говорит о низком уровне ответственности со стороны разработчика и излишней его самоуверенности.
Это наиболее частая ошибка при командной разработке. Говорит о неправильном процессе разработки.
Данные приходится вводить в двух разных объектах, или наоборот получать двумя отчетами. Такая проблема появляется, когда связанные задачи решают разные аналитики и разработчики. Если проектированием занимается архитектор – это показатель нехватки опыта в проектировании сложных механизмов.
Это не ошибка, а следствие не правильно выбранного продукта. Кода для магазина из одного человека берут, например, ERP.
Запросы написаны не оптимально
Не оптимально для чего? Как это можно выявить на этапе кодеревью, а не на этапе нагрузочного тестирования (где ты идеал в реальной жизни?)?
Запросы в циклах
Это не всегда зло.
Запрос к физической таблице выполняется в разы дольше, чем к виртуальной таблице
Это трэш. Виртуальная таблица, на то и виртуальная, что строится из реальной и нигде не хранится. Потому запрос к виртуальной таблице есть ни что иное как запрос или несколько запросов к реальной таблице или таблицам.

Последние два замечания зависят от контекста появления. Это может как быть ошибкой, так и не быть ею.

Использование физической таблицы вместо виртуальной таблицы. Запрос к физической таблице выполняется в разы дольше, чем к виртуальной таблице. При этом выбирается больше ненужных данных.
Выделенная фраза вообще не зависит от реальности или виртуальности таблиц.

Многократное обращение к одному и тому же источнику данных в рамках пакета запросов.
Что такое источник данных в пакете запросов? Почему к нему надо обращаться однократно?

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

То есть кнопки "Проверка модулей" и "Расширенная проверка" - это что то таинственное, загадочное и не знакомое? Они решают 95% таких ситуаций, а остальные 5% можно решить написанием модульных тестов (где ты идеал в реальной жизни?).

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

Из всего описанного можем выделить критерии качества поддержки:

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

Как объективно определить: "грамотность", "старание", "зарытие при подходе времени"?

срок закрытия заявок и их количество, являются основной для расчета SLA

Нет. Это объективные измеримые показатели, а SLA - это контракт, между поставщиком и потребителем услуги. Каждый такой контракт индивидуален. Поэтому нельзя внеконтекста ответить на вопрос: "Помогает ли в этом популярный SLA?".

Вообще о чем статья я так и не понял. Об ошибках разработки или задачах поддержки?

Что такое качество - не раскрыто.
Почему не приведены определения? Например:

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

ГОСТ 15467-79
Качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя

ИСО 8402—86
Качество — степень соответствия совокупности присущих характеристик объекта требованиям

ГОСТ Р ИСО 9000-2015
d4rkmesa; SirYozha; olgun4ik99; tamepjlah; proglex; alest; for_sale; karpik666; biimmap; +9 Ответить
5. пользователь 01.07.20 17:40
Сообщение было скрыто модератором.
...
6. MamZhan 03.08.20 09:25 Сейчас в теме
Дайте пожалуйста ссылку на 1 часть.
Или лучше в статье указывать ссылки на части очень удобно.
Оставьте свое сообщение