Матричные модели совмещают принципы построения функциональных и процессных организационных систем. В этих структурах существуют жестко регламентированные процессы, которыми управляет менеджер процесса.
Принципы матричной модели следующие.
1. Работники осуществляют свою деятельность под оперативным руководством менеджера процесса и административным контролем руководителя функционального «колодца».
2. Роль менеджера процесса состоит в координации действий внутри процесса.
Матричная модель, с одной стороны, не полностью реализует преимущества процессного подхода, с другой – не полностью устраняет недостатки функциональной системы. На практике матричные структуры хорошо применимы для организации управления проектной деятельностью и мало подходят для регулярного менеджмента, так как в них формируется некоторое двоевластие процессов и функций.
Если применять разные организационные модели в пределах отдельных бизнес-процессов, то для каждого можно использовать преимущества той или иной модели. При этом для организации в целом будет применяться процессная модель структуры, а в рамках отдельных подразделений – другие модели.
Пример
1. Для структурного блока, реализующего бизнес-процесс разработки новых и совершенствования существующих продуктов, целесообразно использовать матричную модель структуры.
2. Для организации процессов воспроизводства ресурсов (зависимость от монополистов-поставщиков), воспроизводства средств производства (использование подрядчиков для выполнения работ), продвижения и продаж (работа с ограниченными клиентскими группами) подходят модели, ориентированные на контрагента.
3. Структура финансовых служб будет выглядеть привычнее при использовании функциональной модели.
Выбор тех или иных субмоделей зависит от специфики бизнеса.
Требования
Требование – это любое условие, которому должна соответствовать разрабатываемая система или программное средство. Требованием может быть возможность, которой должна обладать система, или ограничение, которому она должна удовлетворять. Проще говоря, это пригодное для реализации описание того, что должно быть сделано. Применительно к ПО требования описывают свойства, которыми должна обладать программа.
Существует три основных вида требований, сразу скажу, что есть и другие, но для начала давайте рассмотрим три основных, с которыми работает бизнес-аналитик. Это бизнес-требования, пользовательские требования и функциональные требования. На картинке стрелочками показано, что из одного бизнес-требования может вытекать множество пользовательских требований, а из пользовательского – множество функциональных требований. Получается своеобразная матрешка.
Бизнес-требования – это набор требований к конкретному проекту, процессу или информационной системе. Их обычно выдвигает сам заказчик проекта или его ключевые пользователи. Это требования, описывающие высокоуровневые бизнес-цели организации. Они объясняют, зачем организации нужны такие информационные системы и каких целей она намерена достичь с их помощью.
Примеры
• Уменьшить среднее время реализации заявок на 30 %.
• Увеличить количество выпускаемой продукции на 10 %.
Прежде чем создавать любую новую систему или дорабатывать существующую, нужно понять, каких бизнес-целей мы стремимся достичь.
Пользовательские требования (User requirements) – требования, описывающие задачи, которые определенные классы пользователей должны иметь возможность выполнять в системе.
Пример
КАК сотрудник одного из отделов
Я ХОЧУ иметь возможность формировать и подавать заявки в электронном виде,
ЧТОБЫ сократить время на хождение по кабинетам, ускорить создание продукта, исключить ошибки и сократить время на переделывание после отклонений.
Чтобы было понятнее, как из одного бизнес-требования может вытекать несколько пользовательских требований, приведу еще один пример.
Бизнес-требование:
уменьшить среднее время реализации заявок на 30 %.
Пользовательское требование:
КАК сотрудник обслуживающего подразделения
Я ХОЧУ иметь возможность видеть список входящих заявок в виде таблицы,
ЧТОБЫ было удобно фильтровать, отслеживать заявки и предотвращать их потерю.
Системные требования – требования, описывающие поведение системы в определенных условиях. То есть это конечный вид требований, с которыми будут работать программисты.
Пример
1. Необходимо реализовать форму подачи заявки со следующими полями: …
2. Наименование поля «Тип заявки».
3. Формат: выпадающий список с поиском по вводу символов.
4. Варианты значения выпадающего списка: …
5. Поле обязательно к заполнению.
Обычно тем, кто хочет стать бизнес-аналитиком, советуют прочитать книгу Вигерса. Но я не рекомендую браться за нее, пока вы не начнете работать и не закончите несколько проектов, поскольку она может вас запутать. Но классификацию требований по Вигерсу я приведу, так как иметь представление об этом нужно.
Классификация требований по Вигерсу
Каждая система имеет свои функциональные и нефункциональные требования.
Проще говоря:
• функциональные требования описывают, как должна вести себя система;
• нефункциональные требования описывают особые свойства системы или ограничения, которые на нее накладываются.
Системные требования (System requirements) – это требования к системе в целом, к ПО и оборудованию, а также к структуре данных, необходимой для реализации системы, и алгоритмам, которые ими манипулируют.
Примеры
Масштабируемость, отказоустойчивость.
Бизнес-правила (Business rules) – корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Проще говоря, это формализованные или неформализованные правила, которые используются в работе и накладывают ограничения на бизнес-требования. Бизнес-правила не являются требованиями к ПО, поскольку они находятся снаружи границ любой системы ПО, но напрямую влияют на бизнес-требования.
Пример
SMS клиентам могут отправляться с 9:00 по 21:00 по часовому поясу клиента.
Ограничения (Constraints) – это требования, которые определяют, какие действия система не будет выполнять. Или это требования к возможности применения тех или иных технических решений.
Примеры
Система не сможет собирать персональные данные пользователей, т. к. это ограничено законодательством.
У заказчика достаточно много ПО написано на Java, поэтому для удешевления поддержки система должна быть написана на этом языке программирования.
Необходимо разобраться в обоснованности этих ограничений: бывает, что они противоречат бизнес-целям и являются следствием перестраховки стейкхолдеров
Сбор требований
«Начинайте с конца, чтобы не сделать ошибку в начале».
Выявление и сбор требований – это комплекс мероприятий, направленных на получение и анализ нужной информации. Полученные выводы станут основой для функциональных требований к будущей системе или ее модификации.
Мудрость, вынесенная в подзаголовок, говорит о том, что начать нужно с определения конечной цели. А итогом нашей работы должны стать функциональные требования, реализация которых:
1. даст пользователям возможность выполнять необходимые задачи в системе, тем самым удовлетворяя их потребности и решая проблемы;
2. поможет достичь поставленных бизнес-целей.
Вообще устоявшийся термин «сбор требований» не совсем корректен. Он подразумевает, что у пользователя уже есть готовые требования и вам необходимо только собрать их, а это чаще всего в корне неверно. В лучшем случае у заказчика есть пожелания, часто не формализованные, и под сбором требований подразумевается получение информации, на основе которой вы будете их создавать.
Есть много методов выявления требований. Вот список тех, с которыми мне приходилось сталкиваться в практике работы бизнес-аналитиком.
1. Интервьюирование.
2. Анализ документации.
3. Моделирование процессов.
4. Анализ существующих внешних решений.
5. Прототипирование.
6. Моделирование.
7. Наблюдение.
8. Анализ данных.
9. Анализ текущих систем.
Необходимо совмещать первичные и вторичные методы выявления требований. Первичные – это когда мы условно принимаем на себя входящий поток, а вторичные – когда мы сами инициируем обратную связь благодаря тому, что предложили. Это может быть, например, прототип, какие-либо функции или способы их реализации, определенная модель того, как должно быть, и т. д.
Эффективность различных каналов коммуникации
Коммуникация – процесс передачи информации между людьми.
Рисунок на слайде взят из книги Алистера Коберна Agile Software Development (быстрая разработка ПО).
Существуют разные способы коммуникации, которые могут выбрать люди при совместной работе.
На рисунке показана связь между эффективностью коммуникации и богатством (насыщенностью) используемого канала связи.
Нижняя левая дуга показывает документальные способы передачи информации. В этом случае способов получения обратной связи нет.
• Записи на бумаге.
• Аудио и видеозаписи.
Верхняя правая дуга представляет способы коммуникации, при помощи которых можно получить обратную связь:
• переписка по e-mail;