Качество – это такая, блин, понимаешь, штуковина…

Я тут какое-то время назад попытался высказать свое отношение к качеству заказных информационных систем, но в силу ряда причин хочется эту тему немного развить.

В двух словах качество ИС – это степень ее соответствия целям Заказчика, а соответственно – его ожиданиям и потребностям. Эти ожидания и потребности удовлетворяются не только функциональными возможностями продукта и совсем не его техническим качеством. В этом проявляется инвариантность качества: тот факт, что продукт совершенно идеально прошел тестирование и ни одной баги не вернулось с прода совсем не говорит о том, что продукт качественный. Легко может получиться так, что методология использования продукта не учитывает специфику процессов Бизнеса, в связи с чем использование продукта попросту не удобно. И Бизнес совершенно справедливо будет говорить о низком качестве ИС. Ему, Бизнесу, совершенно по барабану, сколько багов осталось в финальном билде, добравшемся до прода. Ему важно, чтобы продукт помогал достичь те цели, которые перед Бизнесом стоят. И вот тут впору вспомнить, что такое ИС.

Как метко подмечено в стандартах ГОСТ Р34-ой серии (ЕКС АС) информационная система представляет собой совокупность видов обеспечения: программного, информационного, методического, организационного, документационного и т.д. Поэтому наряду с функциональными возможностями продукта качество ИС определяется качеством видов обеспечения, входящих в ее состав. И их наличием тоже. Попытаюсь объяснить на примере.

Скажем, есть некоторый банк, для которого вы пилите систему квартальной отчетности ЦБ РФ. Работу системы можно организовать по-разному. Можно сделать так, что сбор всех данных и формирование отчетов будут осуществляться в конце квартала. А можно сделать так, чтобы это осуществлялось периодически на протяжении отчетного квартала. И та, и другая реализация обеспечивают формирование квартальных отчетов. Т.е. на первый взгляд соответствуют потребностям Бизнеса. Но первая система несет в себе большой риск: если произойдет какой-то сбой, связанный с ошибками загрузки данных и их агрегации, то будет сорвана квартальная отчетность и банк попадет на бабки. Во второй системе этот риск минимизируется за счет распределения заливки данных на протяжении квартала. Получается, что методическая основа у систем разная и у второго варианта она более качественная, т.к. учитывает нежелание Бизнеса на ровном месте попасть на бабки.

Идем по примеру дальше. Второй вариант реализации, в отличие от первого, накладывает некоторые ограничения на организацию работ с системой (организационное обеспечение). Оно заключается в том, что в Бизнесе должен быть выделен человек, который будет периодически заливать в систему данные и всячески контролировать успешность ее работы. Отсутствие таких организационных решений или пофигистическое отношение к ним сводит на нет эффективность методик, заложенных в систему и соответственно убивает качество ИС, т.к. в силу неправильной эксплуатации с ней непременно возникнут проблемы.

Ну и так далее.

В итоге напрашивается следующий вывод: качество ИС как некоторое соответствие продукта потребностям Бизнеса закладывается ровно в тот момент, когда мы формулируем контекст системы и определяем те виды обеспечения, которые для проектируемой ИС должны стать обязательными.

Вот тут и начинает играть наш треугольник: изменяя конфигурацию видов обеспечения, мы начинаем управлять соотношением между качеством системы и сроками / стоимостью ее реализации. Но это уже тема отдельного монолога.

Комментарии

Популярные сообщения из этого блога

Карта компетенции аналитика

Оценка эффективности работы руководителя проектов

Драйв