?

Log in

No account? Create an account
Описание предметной области, бизнес-требования, системные требования и как с этим жить - Экономика, управление, ИТ, системы, анализ — LiveJournal
October 17th, 2013
08:46 pm

[Link]

Previous Entry Share Next Entry
Описание предметной области, бизнес-требования, системные требования и как с этим жить
ВнезапноСейчас, в ходе ревью документов по текущему проекту осознал, что имею перед глазами хороший пример для иллюстрации своей позиции в давних спорах по поводу частой и типичной ошибки многих коллег. А точнее двух ошибок, не очевидно (для некоторых) связанных между собой.

Вот эти заблуждения:
1. Бизнес-требования не должны быть (могут быть не) измеряемыми. Многие компании, которые я встречал на этом принципе строят производственный процесс. Как следствие, первая (самая ответственная) ступень проекта в лице бизнес аналитиков и лиц, приравненных к ним, рожает тонны никому не нужной и даже иногда вредной бумаги, разогревая воздух с мощьностью в десятки человеко-лет в год. Делают они это на основе красочного набора других заблуждений, а еще по тому, что так удобней и безопаснейдля себя и иногда для начальства (но это в следующий раз).
2. Многим кажется, что сначала делаем описание предметной области, а потом уже подтягивается весь остальной проект. Или по той же прирчине многие думают, что возможно создать (а еще лучше нарисовать) универсальную модель (например, процессов), которая потом, при случае, окажет нам неоценимую услугу. На практике это в половине случаев (у людей думающих) рождает жуткие приступы проектного паралича, а в другой половине (у людей, делающих) те же, что и в предыдущем абзаце, тонны бумаги киловатты рассеиваемой впустую энергии.

Так вот.

Во-первых, любое требование ЖЕЛАТЕЛЬНО должно быть измеряемым.  Это относится и к бизнес-требованиям. Другое дело, что что бизнес-требование само по себе без обвязки не факт, что реализуемо.

Примеры БТ:
А) Сократить время поиска документов в пять раз и повысить надежность до 100%".
Б) "Уменьшить время на разработку документов на 5% путем снижения вероятности использования неактуальных исходных данных с последующей переделкой".

Можем измерить? Конечно да. Не факт, что это легко и не факт, что можно измерить с нужной нам точностью. Но факт в том, что какие-то измерения с какой-то точностью возможны в большинстве случаев, а иногда это можно измерить достаточно дешево и достаточно точно.

Во-вторых, вот тут-то на сцену и выходит описание предметной области (описание объектов автоматизации и любые другие описания AS IS), которое не может быть выполнено в отрыве от бизнес-целей и детализирующих бизнес-требований. Его задача - выступить одной из сторон разрыва между AS IS и TO BE. А наличие обеих сторон дает нам возможность нормально выстроить и описать решение.
Например:
А) Чтобы предложить системы, сокращающую время поиска в пять раз надо много что знать про ситуацию у заказчика: что будем искать и сколько его, кто ищет, как сейчас ищет и сколько, наконец, сейчас занимает этот поиск и какова сейчас надежность поиска и т.д.?
Б) По примеру с переделками, чтобы выстроить решение и убедиться в его реализуемости надо знать: кто переделывает, сколько их, что переделывают, что есть исходные данные, как распределяется сейчас частота получения неактуальных исходных данных и как распределяется трудоемкость переделок, существует ли вообще резерв оптимизации размером не менее 5% на этом моменте, и т.д.?

В-третьих, само решение: чтобы сделать БТ реализуемым нам нужны системные требования: определение списка систем под раз(/до)работку и внедрение и организационно-методических мер, направленных на реализацию БТ, определение требуемых функций этих систем и их нефункциональных требований.
И мы получаем пачку системных требований:
- ВИ1 Найти документ
- ВИ2 Получить оповещение о новой версии
- Число одновременно работающих пользователей - 800
...
- ВИ56 Подписаться неа изменения
- ВИ57 Разместить документ в системе
...
- ВИ78 Посмотреть историю изменений документа
- DB79 Посмотреть журнал действий с документом
...
- ВИ102 CRUD справочника типов документов
...
- ВИ134 Создать учетную запись ползьователя
...
- И много всего другого.


В итоге на определенной стадии проектирования:
- Бизнес-требования - это TO BE;
- Описание предметной области - это AS IS;
- Системные требования на данной стадии - это часть плана перехода (хотя уже на следующей стадии они станут TO BE, а планом станет архитектура).

Отсюда становится ясно, что порядок обследования (сначала цели и ключевые БТ, затем детали описания текущего состояния предметной области и процессов) прямо противоположен часто принятому порядку изложения в отчете об обследовании и приравненных к нему документах (сначала AS IS, потом TO BE). И вообще, достаточно часто (сюрприз, правда?) последовательность изложения в документе не совпадает с последовательностью получения информации и принятия решений.

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

Tags: ,

(1 comment | Leave a comment)

Comments
 
From:Oleg Babushkin
Date:February 25th, 2019 06:24 pm (UTC)

Заказчики часто говорят о что болит

(Link)
При этом довольно часто убежденно ‘знают’ ,как лечить.
Уже клише, не автоматизируйте процессы , автоматизируйте эффективные процессы.
Boatman's Home Powered by LiveJournal.com