Алина - Системный аналитик

Элементы модели процесса Модель процесса состоит из семи основных элементов: Действие (activity) - непосредственная часть процесса, может представлять собой задачу или подпроцесс Событие (event) - явление, которое без задержки происходит во время процесса. Событие может быть триггером для начала процесса, его итогом, а также может возникать в промежутках между действиями Поток (flow) - связывает действия и события. Результат направленного потока — достижение цели процесса Точка принятия решения - момент, в котором принимается решение о направлении процесса Ссылка (link) - связывает несколько моделей. Если действие подразумевает целый подпроцесс, его можно описать в виде отдельной модели и сослаться на него с помощью ссылки Роль, или участник процесса (role) - лицо, которое выполняет действие Данные (data) - данные, которые используются в процессе. Модель процессов можно представить в виде диаграммы. Для этого используются специальные нотации для моделирования процессов (BPMN, UML и нотацией Гейна — Сарсон). С самыми часто встречающимися в работе системного аналитика я вас познакомлю в следующих постах

Модель процесса Модель процесса состоит из семи основных элементов: 1.   Действие, которое может быть представлено как задача или подпроцесс. 2.   Событие, которое может быть триггером для начала процесса, его итогом, а также может возникать в промежутках между действиями. 3.   Поток, который связывает действия и события. 4.   Точка, в которой принимается решение о направлении процесса. 5.   Ссылка, которая связывает несколько моделей. 6.   Роль, или участник процесса. 7.   Данные, которые используются в процессе Модель процесса можно представить в виде диаграммы. Для этого используются специальные нотации для моделирования процессов. С самыми часто встречающимися в работе системного аналитика я вас познакомлю в следующих постах.

Потребность в информации и процессах Выявляя пользовательские и функциональные требования, системный аналитик определяет: процессы, которые команде разработки потребуется реализовать в системе; информацию, которую системе потребуется создавать, хранить, предоставлять по запросу и обрабатывать. Процесс — это последовательный поток работы или действий. Информация — это знания об объектах, таких как факты, события, предметы или идеи, которые в зависимости от контекста имеют определённое значение в предметной области. Давайте выявим разницу между информацией и процессом на примере. Пользователь будущей системы может сказать: «Система должна предоставлять мне возможность просматривать историю моих заказов за пять лет» — это потребность в реализации процесса. «Система должна сохранять историю заказов покупателя за пять лет» — это потребность в информации. Такие функциональные требования называются ориентированными на процессы или на информацию. Анализируя выявленные требования, системный аналитик составляет: модели процессов; модели данных в предметной области системы. Модели процессов описывают действия участников, связи между действиями и связи между разными процессами. Также они показывают, какие данные нужны для выполнения этих действий и процессов, какие данные создают и изменяют участники и как они используют хранимые данные. Модели процессов нужны, чтобы определить, как система может обеспечить выполнение этих процессов и действий. Модели данных необходимы для определения структуры данных, используемых в системе для выполнения процессов и действий.

Бизнес-требования • Содержат бизнес-цели организации или заказчика. Бизнес-целью может быть желание увеличить прибыль, снизить издержки, увеличить долю рынка и прочее • Исходят от тех, кто финансирует проект, заказчиков, отдела маркетинга или ответственного за концепцию продукта • Пример: в течение года с помощью бонусной системы увеличить количество постоянных клиентов до 1000 человек Пользовательские требования • Содержат описание того, какие возможности система должна предоставить пользователю для удовлетворения его потребностей. Также содержат описание важных атрибутов или характеристик продукта • Исходят от пользователей и других заинтересованных лиц, влияющих на проект • Пример: возможность списания бонусных баллов со счёта пользователя при заказе товаров с сайта Функциональные требования • Содержат сценарии поведения продукта в различных условиях • Исходят от системных аналитиков • Пример: отображаемая стоимость товара должна уменьшиться на величину списываемых бонусных баллов Нефункциональные требования • Содержат ограничения, налагаемые на систему, которые определяют ее атрибуты качества (безопасность, производительность, масштабируемость, доступность, юзабилити, совместимость, техническое обслуживание) • Исходят от системных аналитиков • Пример: Приложение должно поддерживать устройства, работающие на операционных системах: iOS 9.0- 16.0, Android 7.0 – 12.0 (учитывая специфические особенности марок Xiaomi, Huawei)

Чем бизнес-аналитик отличается от системного аналитика? Зачем на проекте столько аналитиков? Бизнес-аналитик говорит, что нужно сделать, системный аналитик — как это нужно сделать. Представьте владельца ресторана с низким рейтингом заведения в интернете. В отзывах клиенты жалуются, что счёт несут очень долго. Ресторатор нанимает бизнес-аналитика, задача которого — понять, почему посетителям долго несут счёт и что с этим можно сделать. Бизнес-аналитик заметил, что официанты записывают заказ на бумаге, листок передают на кухню, а потом долго ищут его, когда нужно рассчитать клиента. Бизнес-аналитик описал проблему, оценил её масштаб и предложил варианты решения. Владелец ресторана рассмотрел предложенные варианты и решил внедрить систему управления заказами, которая будет автоматически формировать чек к каждому заказу. Для внедрения такой система ресторатор обращается к системному аналитику. Системный аналитик собирает требования от владельца ресторана, официантов, поваров и других. Затем он проектирует систему, ставит разработчикам конкретные задачи с чёткими инструкциями: как должна выглядеть база данных с заказами, какую информацию о заказах там нужно хранить, как должен работать интерфейс этой системы

Каких дополнительных специалистов можно привлечь на проект? В процессе разработки ПО могут появиться задачи, которые нужно решать эпизодически или в период расширения проекта. В этом случае команда может привлекать дополнительных специалистов. Бизнес-аналитик помогает улучшить бизнес-процессы и внедрить решения, предлагая изменения в организационных процессах и регламентах. Эти решения не всегда подразумевают разработку ПО. Иногда достаточно перестроить организационные процессы, изменить регламенты, должностные инструкции или порядок ведения документов. UX/UI-дизайнер отвечает за разработку графического интерфейса ПО, учитывая удобство и эстетику. UX/UI-дизайнер должен хорошо понимать целевую аудиторию: кто будет пользоваться продуктом, какие у этих людей цели и задачи, к чему они привыкли и к чему не привыкли. Архитектор ПО занимается проектированием сложных приложений, определяя правила взаимодействия компонентов и используемые технологии. Архитектор должен иметь большой опыт в разработке, знать стандартные архитектурные решения, понимать возможности и ограничения различного ПО. Среди прочих задач архитектора — закладывать возможности для масштабирования программного обеспечения и следить за тем, чтобы команда разработки (или несколько команд) работала слаженно, придерживалась заданной архитектурной концепции. DevOps-инженер автоматизирует процесс поставки ПО, облегчая сборку и установку приложения на компьютеры пользователей. Специалист сопровождения отвечает за поддержку пользователей, принимая обращения и формируя предложения по доработке ПО. Чем масштабнее проект, тем больше вопросов может возникнуть на стыке компетенций основных специалистов. Привлечение дополнительных специалистов поможет уменьшить количество ошибок и чётче увидеть картину проекта.

Проектная команда занимается созданием программного обеспечения (ПО). Зона ответственности каждого участника проектной команды определяет его роль в разработке. Product Owner (PO, владелец продукта) – владеет всем массивом информации о товаре/услуге, о потребностях целевой аудитории и компетенциях проектной команды: • анализирует рынок и потребности аудитории • собирает и обрабатывает обратную связи от конечных пользователей и стейкхолдеров (акционеров проекта) • формирует бэклог продукта (что туда войдёт и в какой последовательности команда будет это выполнять) • контролирует выход версий продукта от идеи до презентации заказчику Project manager (PM, Менеджер проекта, руководитель проекта, РП или просто менеджер) – отвечает за то, чтобы проект был успешно завершён в срок: • составляет и контролирует план работы • управляет рисками на проекте • отвечает за коммуникацию в команде и вне её Системный аналитик – разрабатывает требования к программному обеспечению: • собирает и описывает требования к будущему продукту • изучает различные документы и источники данных (стандарты, документацию, электронные базы и т.д.) • проектирует и согласовывает решение • отвечает на вопросы команды, вносит уточнения и правки • документирует результаты разработки Разработчик – разрабатывает и развивает ПО с помощью языков программирования. Всю разработку можно условно разделить на две группы: 1. Frontend-разработка - отвечает за визуальную (клиентскую) часть программного обеспечения, с которой взаимодействует пользователь 2. Backend-разработка - отвечает за серверную часть программного обеспечения, которая хранит и обрабатывает информацию. Инженер по тестированию (QA-engineer) или тестировщик – проверяет результаты работы разработчиков и обеспечивают качество продукта: • описывает и проверяет сценарии использования ПО • фиксирует ошибки • под конец разработки подтверждает, что ПО качественное и им можно пользоваться Без этих участников проектной команды разработку ПО вряд ли удастся довести до ума, но иногда для успеха проекта может потребоваться больше ведущих игроков.

Матрица Кепнера-Трего как инструмент поиска решений Мы хотим принимать только такие решения, которые приведут нас к успеху. Используя матрицу Кепнера-Трего можно принять более взвешенное решение, усилить уверенность в принятом решении и систематизировать процесс анализа альтернатив. Шаг 1: Составьте подробный список вариантов решений для анализа Шаг 2: Сформулируйте значимые критерии. Присвойте каждому критерию вес по шкале от 1 до 5, где 5 – наиболее важный критерий, 1 – наименее важный Шаг 3: Взвесьте критерии, оценив каждый из вариантов решений по шкале от -2 до 2, где -2 – полное несоответствие критерию -1 – частичное несоответствие 0 – отсутствие влияния 1 – соответствие с ограничениями 2 – полное соответствие Шаг 4: Умножьте вес критерия на его оценку для каждого из вариантов решений Шаг 5: Сложите общее количество баллов по каждому из вариантов и выберите решение. Наибольший балл будет у наиболее оптимального решения. В качестве примера представлена матрица Кепнера-Трего для выбора преподавателя на предстоящий семинар. Используйте этот инструмент как в работе, так и в повседневной жизни!

Как изучать сложные системы? Сложная система – это система, состоящая из множества простых подсистем. Соблюдайте 3 основных правила при изучении сложных систем: ✔️ Смотрите на систему как можно шире и учитывайте всю информацию о ней. Иногда мы не видим некоторых деталей, потому что концентрируемся на одной части информации и игнорируем другую. Для правильной оценки результата важно смотреть на все факторы в комплексе ✔️ Принимайте к сведению все причинно-следственные связи. Отслеживайте происходящие в системе изменения, события, их влияние друг на друга ✔️ Учитесь вовремя задавать вопросы и переносить ответы на работу других систем. Правильно заданный вопрос о системе поможет извлечь максимально полезный опыт, который можно использовать при работе с другими системами. Обучение в сложных системах предполагает непрерывное развитие, готовность меняться и умение получать и использовать новую информацию. Исследуя сложные системы, вы заметите, что раз за разом ваш навык системного мышления будет становиться всё лучше!

Причина-следствие в системах Один из важнейших навыков в системном мышлении – научиться видеть систему в динамике. Как вы уже знаете, любое изменение одного из элементов системы обязательно скажется на состоянии других. Например, если при сильном ветре у дерева сломалась ветка, через некоторое время на ней обязательно засохнут и опадут листья. На системном уровне это называется «причинно-следственная связь». Обратная связь сигнализирует о том, что элементы системы изменились. Еще примеры: вы видите, что превышаете скорость и опускаете педаль газа или вы получаете согласие от собеседника и перестаете высказывать аргументы. Обратная связь в этих ситуациях возникает быстро, и вы сразу видите результат ее применения. Однако во многих системах мы не получаем обратную связь сразу и, как следствие, мы действуем, но не знаем точно, как именно наши действия влияют на ситуацию. Такая задержка во времени может создавать иллюзию отсутствия негативных последствий и не важно, о чем идет речь: об отношениях или непродуманных решениях в управлении бизнесом. Поэтому крайне важно внимательно отслеживать ответные реакции системы и уделять время анализу обратной связи. Это поможет: 🔹 выявлять закономерности 🔹 гибче реагировать на изменяющуюся ситуацию 🔹 оценивать причины последствий 🔹 принимать новые и более эффективные решения

Системное мышление Ежедневно каждый из нас сталкивается с большим потоком информации. С помощью системного мышления мы рассматриваем эти потоки информации как часть большой системы, которая состоит из множества элементов, влияющих друг на друга. Системное мышление — понятие достаточно эфемерное, но оно позволяет понимать связи между предметами и явлениями и воспринимать целостным то, что нас окружает. Вот критерии, по которым сможете самостоятельно проанализировать, насколько развито ваше системное мышление: 1. Понимаете, что каждая задача или процесс – это не просто винтик, а часть большого механизма 2. Рассматриваете процессы и задачи с разных точек зрения, рефлексируете по ним 3. Выявляете сложные причинно-следственные связи 4. Выявляете риски, принимаемых решений 5. Мыслите без стереотипов, формулируете прорывные идеи 6. Выходите с инициативой, смело задаете вопросы 7. Не боитесь признать свои ошибки Именно системное мышление в нелогичном мире 🌏 поможет вам принимать эффективные решения!✨

Добро пожаловать в увлекательный мир системного анализа! Меня зовут Алина Сунгатуллина, я - ведущий системный аналитик, кандидат технических наук, имею опыт 15+ лет в IT. За моими плечами участие в более 30 проектах (бизнес-процессы, монолитные приложения, микросервисы, базы данных, интеграции и многое другое) в сферах образования, транспорта, рекламы, e-commerce и fintech. В своем авторском канале публикую полезные для бизнеса и коллег по "цеху" материалы про системное мышление, системный анализ, современные технологии, интересные новости в IT, управление требованиями, интеграции и проектирование архитектуры - обязательно на "человеческом" языке, на своем опыте, с возможностью применить на практике. Мои интересы: 📚 Чтение профессиональной литературы 🧑‍🎓 Развитие и самореализация 🧑‍🏫 Ментерство 🧑‍💻 Участие в квизах и хакатонах Факты обо мне: 🎈 Летала на воздушном шаре 🏂 Увлекаюсь сноубордом 🕵️ Люблю запутанные детективы