Архитектор решений отвечает за разработку одного или нескольких приложений или сервисов в организации. Решает проблему, которую определил бизнес:

• как технологии могут быть использованы для решения бизнес-проблемы;

• какую платформу или стек технологий можно использовать для создания решения;

• как станет выглядеть приложение, какими окажутся модули и как они начнут взаимодействовать друг с другом;

• как вещи будут масштабироваться и поддерживаться.

Архитектор решений часто работает под методическим руководством бизнес-архитектора.

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 – несколько уровней поддержки приложения по степени знания системы.

На этом этапе обеспечивается общая техническая поддержка, в рамках которой обрабатываются типовые обращения. Цель создания такой службы – обеспечение постоянной поддержки пользователей на определенном уровне. Значительное число входящих вопросов решается на первой линии.

Level 1 support принимает входящие сообщения заказчиков, отвечает на звонки и письма клиента. Идентифицирует клиента, локализует проблему, обычно следует сценарию. Если может, помогает клиенту на своем уровне. Если отсутствуют даже обходные пути, вопрос передается на следующий уровень поддержки.

Level 2 support – это технические специалисты с более продвинутыми навыками общего или специализированного назначения. Тут происходит систематизация, анализ и решение проблем.

Обязанности специалистов второго уровня:

• контакт с персоналом первой линии и помощь ему;

• фиксация и последующий анализ инцидента;

• решение проблемы;

• передача данных по решенной проблеме на первый уровень.

Если проблема, делегированная специалистам второй линии поддержки, уникальна и квалификация персонала не позволяет ее решить, то в установленные регламентом сроки она должна быть передана дальше – на третий уровень.

Level 3 support – это обычно команда разработки, которая лучше всех знает продукт и может помочь в решении проблемы.

Жизненный цикл ПО

Жизненный цикл ПО (SDLC, Software Development Life Cycle) – период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

SDLC – это основные этапы, через которые проходит любой программный продукт. Плюс-минус всегда имеют место следующие этапы.

1. Фаза планирования.

2. Фаза сбора требований/анализа.

3. Фаза дизайна/проектирования.

4. Фаза разработки.

5. Фаза тестирования.

6. Фаза внедрения.

7. Фаза поддержки.

ЖЦ продукта начинается с идеи. После того как мы решили создавать новый продукт, мы приступаем к фазе планирования: прорабатываем идею, пишем бизнес-план, проводим анализ конкурентов, рассчитываем предполагаемую прибыль. Далее запускается сам проект по реализации продукта, если руководство решит, что оно того стоит.

После завершения проекта получается продукт, и начинается операционная деятельность по работе с этим продуктом. И далее, если продукт требует изменений, то строится новый бизнес-план и запускается новый проект.

В ЖЦ проекта начальная фаза заключается в переходе идеи в проект, а финальная фаза наступает после подписания актов приема-передачи, когда продукт передается в операционную деятельность. Поэтому можно сказать, что ЖЦ проекта лежит внутри ЖЦ продукта. Это не какие-то строгие правила, стадия планирования и ее содержимое могут быть пропущены: например, если продукт просто требует доработок или новой функциональности.

Поэтому хотелось бы отметить, что для продукта и проекта этапы ЖЦ могут отличаться. Это стоит понимать и учитывать.

Жизненный цикл проекта

Любой ЖЦ проекта включает в себя четыре фазы.

1. Начальная – фаза перехода идеи в проект. На этой стадии обычно пишется устав проекта, определяются первичные критерии успеха проекта. Также на этой фазе формируются ключевые роли в проекте: менеджер проекта, владелец, спонсор.

2. Подготовка и организация. На этом этапе выделяются ресурсы для проекта, создается команда, составляется план проекта, определяется бюджет, а также ищутся поставщики услуг, если они необходимы.

3. Выполнение работ. Это фаза создания проекта. Именно на этом этапе создается продукт. Менеджер проекта получает отчеты о ходе выполнения проекта и контролирует процесс. Далее происходит финальное одобрение продукта перед подписанием акта приема работ.

4. Финальная стадия. Основная суть этой фазы – подвести итоги после завершения проекта, подписать акт приема-передачи и передать продукт в операционную деятельность.

На графике показано, как в зависимости от стадии проекта меняются такие показатели, как:

• стоимость проекта и численность персоналом – вовлеченность ресурсов (кривая 1);

• влияние заинтересованных сторон, неопределенность проекта, возможность рисков (кривая 2);

• стоимость изменений по проекту (кривая 3).

1. Мы видим, что самая низкая стоимость изменений – в начале, на этом этапе легче всего повлиять на изменение проекта. Именно здесь определяются цели проекта. Под эти цели выбирается оптимальное решение. Если цели изменятся, то может оказаться, что выбранное решение им не соответствует, и у заказчиков начнутся проблемы.

Пример