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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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