В процессе разработки ПО могут появиться задачи, которые нужно решать эпизодически, а ещё проект может сильно расшириться. И в первом, и во втором случае команда привлекает дополнительных специалистов.
Бизнес-аналитик
Бизнес-аналитик — специалист, который изучает, как устроены процессы в компании, описывает их с точки зрения бизнес-логики, предлагает, как улучшить эти процессы, и помогает компании внедрить решения.
В каких случаях может потребоваться бизнес-аналитик? Например для того, чтобы оценить, оправдана ли разработка ПО для компании, которая хочет автоматизировать или упростить процессы. Если дело того стоит, бизнес-аналитик присоединяется к основной команде разработки.
Решения, которые предлагает бизнес-аналитик, не всегда подразумевают разработку ПО. Иногда достаточно перестроить организационные процессы, изменить регламенты, должностные инструкции или порядок ведения документов.
Бизнес-аналитик помогает чётко обозначить точки А и Б:
- Точка А — то, где мы находимся сейчас. Бизнес-аналитик описывает состояние текущего бизнес-процесса как есть (as is) и обозначает проблемы — например, почему нежелательно оставаться в этой точке.
- Точка Б — то, куда мы хотим попасть. Бизнес-аналитик описывает целевой бизнес-процесс — как должно быть (to be).
Бизнес-аналитик оценивает и эффективность изменений: почему в точке Б лучше, чем в точке А? В чём это выражается? Как это измерить? Если для того, чтобы попасть в точку Б, нужно автоматизировать бизнес-процесс, то есть разработать ПО, то подготовленные бизнес-аналитиком материалы далее попадают к системному аналитику.
Чем бизнес-аналитик отличается от системного аналитика
Может возникнуть вопрос, зачем на проекте столько аналитиков и чем бизнес-аналитик отличается от системного? На самом деле они выполняют разные задачи. Бизнес-аналитик говорит, что нужно сделать, системный аналитик — как это нужно сделать.
Представьте владельца небольшого ресторана, который заметил, что рейтинг его заведения в интернете — 3,5 балла из пяти. В отзывах клиенты чаще всего жалуются на то, что счёт несут очень долго и это раздражает. Ресторатор нанимает бизнес-аналитика, задача которого — понять, почему посетителям слишком долго несут счёт и что с этим можно сделать.
Бизнес-аналитик проследил за тем, как сотрудники ресторана получают заказы и заметил, что официанты записывают заказ на бумаге. Затем листок передают на кухню, а потом долго ищут его, когда нужно рассчитать клиента. Бизнес-аналитик описал проблему, оценил её масштаб и предложил варианты решения. Владелец ресторана и бизнес-аналитик обсудили предложенные варианты и решили внедрить систему управления заказами, которая будет автоматически формировать чек к каждому заказу, вбиваемому в программу.
Чтобы создать и внедрить такую систему, ресторатор обращается к системному аналитику. Системный аналитик собирает требования от всех заинтересованных сторон и потенциальных пользователей этой системы: владельца ресторана, официантов, поваров и других. Затем он проектирует систему, ставит разработчикам конкретные задачи с чёткими инструкциями: как должна выглядеть база данных с заказами, какую информацию о заказах там нужно хранить, как должен работать интерфейс этой системы и прочие.
UX/UI-дизайнер
Если для программного обеспечения нужен графический пользовательский интерфейс, команде не обойтись без человека, который знает, как сделать интерфейс красивым и удобным. За это отвечает UX/UI-дизайнер. Как следует из названия, UX/UI-дизайнер занимается сразу двумя вещами — и UX, и UI.
В чём разница между UX и UI?
UX концентрируется на взаимодействии пользователя с интерфейсом: что ему нужно сделать, чтобы достичь цели. Если UX проработан хорошо, пользователю понятно, где он, какие операции ему доступны и как именно он может их выполнить. При проработанном UX все кнопки находятся на своих местах, а для того, чтобы операция выполнилась, нужно совершить минимум действий.
UI концентрируется на внешнем виде интерфейса и на том, как его воспринимает пользователь. Интерфейс должен не утомлять и не отвлекать читателя.
UI и UX поддерживают друг друга. Если в форме для заполнения главное действие — «заказать», соответствующая кнопка должна не только располагаться в ожидаемом месте (за это отвечает UX), но и выделяться визуально (за это отвечает UI). Именно поэтому обе задачи чаще всего решает один специалист — UX/UI-дизайнер.
Основная задача UX/UI-дизайнера — разработка дизайн-макетов пользовательского интерфейса. Далее их подхватят frontend-разработчики. Чтобы разработать макеты, UX/UI-дизайнер должен хорошо понимать целевую аудиторию: кто будет пользоваться продуктом, какие у этих людей цели и задачи, к чему они привыкли и к чему не привыкли.
Обратите внимание, с какими сложностями вы сталкиваетесь, когда заказываете что-то в интернете? Какое впечатление от работы сервиса у вас возникает? Вспомните, какие сервисы или процессы вас раздражают и как можно их улучшить? UX и UI как раз и отвечают за то, чтобы вам было и удобно, и эстетически приятно пользоваться чем-либо в IT.
Архитектор ПО
Архитектор программного обеспечения — специалист, который занимается проектированием сложных приложений. Они состоят из множества взаимодействующих между собой компонентов (модулей, блоков).
Сложными могут считаться большие приложения, над созданием которых одновременно работает несколько проектных команд. Или приложения, которыми пользуются миллионы пользователей, — например Яндекс Почта. К сложным можно отнести и приложения, к которым предъявляются исключительные требования в части надёжности, скорости работы и других характеристик (например банковские приложения).
Архитектор ПО определяет, по каким правилам приложение должно подразделяться на компоненты, как компоненты взаимодействуют друг с другом, какие технологии используются, чтобы создать компоненты. Разработанные архитектором решения позволяют компонентам правильно взаимодействовать друг с другом и решать задачи пользователей.
Обязанности архитектора ПО может выполнять как отдельный специалист, так и один из старших разработчиков. Архитектор должен иметь большой опыт в разработке, знать стандартные архитектурные решения, понимать возможности и ограничения различного ПО. Среди прочих задач архитектора — закладывать возможности для масштабирования программного обеспечения и следить за тем, чтобы команда разработки (или несколько команд) работала слаженно, придерживалась заданной архитектурной концепции.
DevOps-инженер
После того как разработчик внёс изменения в программный код, приложение с правками должны увидеть другие люди: сначала инженеры по тестированию, а после завершения тестирования — пользователи.
Чтобы другие смогли увидеть приложение, нужно выполнить:
- Сборку (build) — преобразовать программный код в файл, который запустит и выполнит компьютер.
- Установку (deploy) — перенести исполняемый файл на компьютер, доступ к которому есть у пользователей.
После выполнения этих операций инженеры по тестированию или пользователи смогут работать с приложением. Этот процесс называется «поставка ПО».
Если программа простая и состоит из одного-двух компонентов, то поставка ПО не займёт много времени и может выполняться вручную, например, разработчиком. Но что делать со сложным приложением, которое состоит из сотен и тысяч взаимосвязанных компонентов? В таких случаях команда привлекает специального сотрудника — DevOps-инженера. Он занимается автоматизацией процесса поставки ПО, чтобы её запускало нажатие нескольких кнопок (независимо от сложности приложения).
Этот процесс похож на то, как в большой кондитерской упаковывают и доставляют торты. При большом потоке клиентов производитель не занимается упаковкой и доставкой сам, эту обязанность он делегирует подрядчику. Тот положит торты в коробку, перевяжет её, наклеит этикетки и отвезёт заказ по нужному адресу. Примерно ту же роль исполняет DevOps-инженер — быстро и автоматизированно доставляет ПО.
Специалист сопровождения
После того как ПО передано пользователям, у них могут возникать вопросы: «Как мне выполнить эту операцию?» «Почему ничего не работает?» «Почему в отчёте цифра 5, ведь должно быть 7?» и другие.
Эти вопросы можно напрямую передать участникам проектной команды, например, системному аналитику или тестировщику. Но иногда вопросов может быть много, а поступать они будут и днём и ночью. В таком случае потребуется отдельный человек, который будет работать с вопросами и проблемами пользователей, — специалист сопровождения.
В обязанности специалиста сопровождения входит:
- Принять ПО от команды разработки со всей необходимой документацией, изучить возможности программного обеспечения (что оно может делать, а что нет) и начать оказывать поддержку его пользователям.
- Принимать обращения от пользователей. На простые вопросы, которые касаются, например, типовых ошибок, специалист сопровождения может ответить сам. С более сложными ему потребуется привлечь проектную команду.
- Сформировать базу знаний, содержащую ответы на самые частые вопросы пользователей.
- На основании массовых обращений и запросов (места, где чаще всего спотыкаются пользователи) сформировать предложения по доработке ПО.
Чем масштабнее проект, тем больше вопросов может возникнуть на стыке компетенций основных специалистов. А значит, основным участникам проектной команды придётся принимать больше решений за рамками своих компетенций. В этом случае привлечение дополнительных специалистов поможет уменьшить количество ошибок и чётче увидеть картину проекта.