Как проектировать системы [часть 1]
Продолжение цикла статей о проектировании информационных систем.
Предыдущие статьи:
Введение
В этой части рассмотрим проработку видения системы со стороны бизнес-заказчика.
Итак, мы узнали, что полезность — ключевая характеристика системы; ожидаемая полезность должна быть зафиксирована в видении решения.
Видение в данном случае — верхнеуровневая ментальная модель, включающая в себя понимание о том, чем система может быть полезна человеку, и каким образом эта полезность достигается; в качестве синонима можно использовать слово «концепт». Давайте попробуем сформулировать, что мы ожидаем от этого артефакта.
Как мы установили ранее, для оценки полезности систем, заказчиком которых выступает бизнес, удобно использовать расчёт финансовой эффективности. Применимо к кейсу с системой для управления командировками, образ мысли должен быть такой:
Сейчас торговые представители компании тратят на оформление поездки один час
Час работы торгового представителя стоит 500 рублей
В компании 10 торговых представителей
Каждый торговый представитель ездит, в среднем, в 3 командировки в месяц
Итого в месяц на оформление командировок тратится 30 часов, или 15000 рублей, а годовые затраты составляют 180000 рублей.
Финансовые приобретения не всегда бывают прямыми: например, реализация благотворительного проекта сама по себе не принесёт компании прибыли, но может значительно повысить лояльность клиентов и привлекательность бренда. Иногда это сложно посчитать, но стоит постараться, чтобы получить хотя бы порядок чисел.
На этом этапе преждевременно принимать решение о наличии или отсутствии выгоды — нужно определить, сколько именно денег принесёт система в том случае, если будет создана и внедрена. Нам важно получить число, которое мы будем сравнивать со стоимостью реализации и полной стоимостью владения (TCO) — да, пока этих данных у нас нет, но они возникнут после проектирования верхнеуровнего дизайна системы.
Ключевой момент: видение может быть сформировано только с участием бизнес-заказчика, так как именно он обладает необходимыми данными для расчёта финансового эффекта. В идеальном случае дальнейшие этапы проектирования должны наступать только лишь в том случае, если бизнес-заказчик готов предоставить все необходимые данные. Соответственно, приступить к формированию видения можно только после того, как определены ключевые стейкхолдеры.
Не менее важно оценить, чем чреват отказ от реализации. Для поиска ответа на этот вопрос хорошо подходит квадрат Декарта.
Квадрат Декарта — метод оценки, позволяющий формализовать плюсы и минусы того или иного решения. Для его заполнения достаточно ответить на четыре простых вопроса.
Из иллюстрации видно, что в результате заполнения квадрата Декарта мы начинаем видеть и неочевидные стороны проблемы — например, в данном случае мы, фактически, планируем потратить ценный ресурс разработчиков ради экономии ресурса торговых представителей. Соответственно, при принятии решения будет необходимо сверять его со стратегией компании: в чём мы заинтересованы больше — в расширении клиентской базы или в других внутренних IT-проектах.
Стоит ли совмещать подготовку видения с бизнес-анализом?
Зачастую это имеет смысл. Именно бизнес-анализ поможет показать узкие места процесса и, соответственно, сформулировать видение таким образом, чтобы фокус был направлен именно на их устранение. Кроме того, именно на этом этапе могут быть выявлены альтернативные способы получения искомой возможности. Например, в процессе анализа можно понять, что аналогичного финансового эффекта можно добиться процессными, а не техническими решениями. Аналитик, как правило, способен посмотреть на проблему шире, чем заказчик, и уберечь его от поиска решения «в лоб».
В предыдущей иллюстрации есть «зона неопределённости» — возможность автоматизации декларирована, но не раскрыта. Для перехода на этап формирования функциональных требований следует сформировать смысловое ядро видения:
Текущие затраты на <что?> составляют <сколько?> рублей в год. Проектируемая система за счёт реализации возможности <какой?> должна обеспечить финансовый эффект <сколько?> рублей в год <на какой период?>. Ключевые аспекты, обеспечивающие указанный эффект <перечислить, например - автоматизация процесса, улучшение пользовательского пути>. Отказ от внедрения системы с вероятностью <какой?> может повлечь <что?>.
Концепт обязательно должен содержать список факторов, влияющих на возможность достижения системой состояния полезности:
Требования законодательства («Необходимо шифровать данные пользователей»)
Ключевые интеграции («Данные о пользователях следует получать из корпоративного каталога»)
Внутренние блокеры («Система должна соответствовать корпоративным требованиям информационной безопасности»)
Риски («Не исключено сопротивление внедрению системы со стороны пользователей»)
Кстати, о риске, приведённом в пример.
Система может быть сколь угодно финансово эффективной, но если она не лечит «боль» пользователя, или делает это неудобным способом, то, вероятно, принесёт больше вреда, чем пользы. Это ещё один вектор оценки полезности — через пользовательский опыт. Не будет лишним включить в видение результаты исследований основных потребностей тех, кто будет использовать систему.
Резюмируем:
Видение системы — буквально «взгляд на систему глазами бизнес-заказчика», поэтому разрабатывается при его непосредственном участии
Видение должно доказывать, что проблема, которую решает проектируемая система, действительно существует
Следует не только подсвечивать проблему, но и указывать, за счёт чего её предполагается решать
Решение не должно противоречить стратегии компании
Не стоит пытаться чинить техническими решениями кривые процессы
