Валерий Комсков – Введение в профессию бизнес-аналитика. Отправная точка для приобретения опыта (страница 2)
Информационная архитектура (Information Architecture) определяет структуры данных и описывает все потоки данных, которые используются для поддержки бизнес-архитектуры. Такие операции, как идентификация, систематизация, категоризация, хранение данных, относятся к информационной архитектуре. Может представляться в виде модели данных (Data Model).
Архитектура решения (Solution Architecture) – архитектура программного обеспечения (ПО), которое реализует функции бизнес-архитектуры.
Технологическая архитектура (Technology Architecture) описывает архитектуру IT-окружения, которое используется для поддержки информационной архитектуры и архитектуры решения.
Системная архитектура (System Architeture) – представление системы, которое показывает реализацию функциональных возможностей аппаратными средствами и компонентами ПО, устанавливает связь архитектуры программного обеспечения и архитектуры аппаратных средств, а также регламентирует взаимодействие пользователя с этими компонентами.
Архитектура ПО (Application Architecture) – составная часть системной архитектуры. Описывает организацию системы с точки зрения программных компонентов, из которых она состоит, и связи между компонентами.
Архитектура данных (Data Architecture) – составная часть системной архитектуры. Описывает структуры данных и логические связи между ними.
Каждым из видов архитектуры занимается соответствующий архитектор.
Бизнес-архитектор (Enterprise Architect) отвечает за то, чтобы бизнес-стратегия компании использовала правильную архитектуру технологических систем для достижения своих целей. EA несут огромную ответственность и, как правило, подчиняются непосредственно директору по информационным технологиям (CIO). Они должны идти в ногу с последними тенденциями в технологиях и определять, подходят ли технологии для компании. EA берет бизнес-стратегию компании и описывает архитектуру технологических систем, которая будет необходима для поддержания этой стратегии. Архитекторы уровня enterprise ориентируются на бизнес-потребности, придумывают, как решить какую-либо бизнес-задачу, разрабатывают глобальный план работы приложения и алгоритм его взаимодействия с другими. EA должен представлять, как все приложения работают вместе, иметь всю информацию. Он принимает концептуальные решения.
Архитектор решений (Solution Architect). Если EA решает, что делать, то SA – как делать.
Архитектор решений отвечает за разработку одного или нескольких приложений или сервисов в организации. Решает проблему, которую определил бизнес:
• как технологии могут быть использованы для решения бизнес-проблемы;
• какую платформу или стек технологий можно использовать для создания решения;
• как станет выглядеть приложение, какими окажутся модули и как они начнут взаимодействовать друг с другом;
• как вещи будут масштабироваться и поддерживаться.
Архитектор решений часто работает под методическим руководством бизнес-архитектора.
Technical (software) Architect – техлид в обычных реалиях. Это технический эксперт, который пытается решать проблемы, поставленные SA-архитектором. TA ставит задачи разработчикам и занимается уровнем реализации конкретной системы. На уровне конкретной информационной системы определяет стек технологий этой системы, сервисы, подходы к разработке, выбирает БД и интерфейсы для взаимодействий с другими системами.
Аналитик (Analyst)
Бизнес-аналитик (Business Analyst) описывает бизнес-процессы, как они есть (as is), и, общаясь с заказчиком и заинтересованными сторонами, составляет предложение, какими они должны быть (to be), чтобы решить задачи бизнеса (достичь целей).
Бизнес-аналитик фиксирует бизнес-требования и их решения по реализации в виде бизнес-процессов. При этом может рисовать схемы бизнес-процессов, писать use case – бизнес-сценарии, которые необходимо проверять при приемке решения. Бизнес-аналитик выбирает любой способ фиксирования результатов своей деятельности и передает эту информацию системным аналитикам каждой из систем, которые участвуют в реализации решения. Они составляют свои документы.
Системный аналитик (Systems Analyst) становится связующим звеном между внедрением нового продукта, то есть усовершенствованием бизнес-процессов, и его разработкой. Он опрашивает заказчика, занимается сбором функциональных требований, фиксирует их, обсуждает со своей командой разработки, после чего команда принимает совместное решение о том, какую конфигурацию внедрения программного продукта предложить заказчику. После обсуждения и согласования аналитик описывает постановку задачи в документе, который согласовывает с заказчиком.
Продуктовый аналитик (Product Analyst) – мостик между бизнесом и данными. Он работает рука об руку с менеджером продукта и помогает продуктовой команде принимать верные решения.
Продуктовая аналитика позволяет увидеть, как пользователи взаимодействуют с продуктом. Условно можно выделить две задачи продуктовой аналитики: сбор данных и их интерпретация.
Сначала продуктовый аналитик собирает множество цифр из разных источников: какие кнопки нажимают пользователи, как часто они используют продукт, какие функции продукта популярны, а какие нет. Эти измерения показывают, что происходит с продуктом, но не объясняют почему.
На втором этапе аналитик вытаскивает из цифр инсайды, которые проливают свет на поведение пользователей. Благодаря этому продуктовая команда понимает, какой продукт она сделала и куда двигаться дальше.
Таким образом, продуктовый аналитик работает с данными, изучает метрики, строит воронки и следит за тем, к каким результатам приводит малейшее изменение продукта.
Дизайнер (Designer)
User Experience (UX) – это путь клиента от точки входа до точки выхода. То, насколько клиенту удобно, например, заполнить на сайте заявку на кредит. Отвечает за функциональность.
User Interface (UI) – это вид интерфейса. Отвечает за статику.
UX-дизайнер – это проектировщик, который изучает потребности пользователей, строит логические схемы работы интерфейса, тестирует прототипы на целевой аудитории и составляет ТЗ для UI-дизайнера.
UI-дизайнер определяет цветовую палитру, располагает объекты в интерфейсе так, чтобы он был удобным и понятным. Визуализирует рабочий прототип, отрисовывает кнопки, формы и другие компоненты. На выходе мы получаем макет.
Специалист по информационной безопасности (Application security)
Анализирует приложение с точки зрения информационной безопасности: определяет требования к приложениям и проверяет реализацию на соответствие этим требованиям. Занимается поиском и анализом уязвимостей.
Разработчик (Developer)
Если говорить о веб-приложении, frontend-разработчик занимается клиентской стороной интерфейса, отвечает за вывод информации для пользователя. Backend-разработчик занят серверной разработкой – тем, чего не видит пользователь, реализацией бизнес-логики приложения. Fullstack – человек, который объединяет в себе обязанности front и back (они тесно связаны).
Пример
Вы выбираете рейс из Нью-Йорка в Гонконг. Вы находитесь в зоне frontend. Нажмите клавишу поиска, и вы переместитесь в зону backend, чтобы вам могли правильно вернуть лучший, самый короткий и дешевый рейс в мгновение ока. Как только отобразятся результаты, вы снова окажетесь в зоне frontend.
Отдельно выделены gamedev-разработчики (разработчики игр) и iOS/Android-разработчики – группы разработчиков под эти ОС.
1С/SAP-разработчики и так далее – разработчики на определенном коробочном решении. Такие решения закупаются фирмой и дорабатываются под ее нужды, здесь имеются специализированный язык и свои инструменты.
Тестировщик (QA Engineer)
Есть несколько видов тестирования. Соответственно, разные его виды выполняют разные тестировщики.
➤ По отношению к объекту тестирования.
1. Функциональное. Тестирование конкретной функциональности, которая была разработана в соответствии с требованиями.
2. Безопасности. Проверка разработанного продукта на соответствие требованиям безопасности, имитация атаки или несанкционированных действий.
3. Производительности. Стресс-тестирование, тестирование нагрузки, стабильности.
➤ По доступу к коду.
1. Тестирование черного ящика в том случае, когда мы не знаем алгоритмы.
2. Тестирование белого ящика в том случае, когда учитываются механизмы системы внутри.
3. Тестирование серого ящика – комбинация первого и второго.
➤ По степени автоматизации.
1. Ручное – тест-кейсы.
2. Автотестирование – специально написанный код для автоматизации проверки определенного кейса.
➤ По степени изолированности компонента
1. Модульное – тестирование определенных модулей системы (компонентов).
2. Интеграционное – тестирование взаимодействия модулей.
3. Тестирование системы в целом (полной системы).
Техническая поддержка (Tech Support)
Техническую поддержку часто подразделяют на уровни, чтобы улучшить обслуживание организации или базы клиентов.
Level 1/2/3 support – несколько уровней поддержки приложения по степени знания системы.
На этом этапе обеспечивается общая техническая поддержка, в рамках которой обрабатываются типовые обращения. Цель создания такой службы – обеспечение постоянной поддержки пользователей на определенном уровне. Значительное число входящих вопросов решается на первой линии.