В предыдущей серии мы рассмотрели инструменты системного и бизнес-анализа. Сегодня обсудим вопрос, должна ли быть выделенная должность аналитика или это роль.
В водопадном подходе, когда мы последовательно идём по всем этапам разработки, начиная со сбора требований, заканчивая разработкой, тестированием и внедрением в эксплуатацию, скорей всего будет отдельная должность аналитика. Такой подходт зачастую используется в проектной работе, когда есть масштабные проекты, в которых нужно много всего учесть, и после согласования требований мы потом не можем просто их поменять. Такой подход используют большие корпорации либо государственного заказчики.
Продуктовые же команды зачастую используют сейчас итерационные гибкие методы разработки. Итерационно - это значит, что мы все этапы
разработки от сбора требований до поставки работающей функциональности заказчику проходим "спринтами" - небольшими отрезками времени. На момент написания статьи (2023 год) в индустрии разработки ПО за "стандарт" приняты двухнедельные спринты. Но есть команды, у которых продолжительность спринта - 1 неделя, есть спринты по 3-4 недели.
При этом в Скраме, самом популярном гибком подходе, есть только следующие роли: Владелец продукта, Скрам-мастер, член команды разработки. Никаких аналитиков, архитекторов, менеджеров проектов в Скраме нет.
Но даже если мы работаем по Скраму, то этапы сбора требований, проектирования, разработки, тестирования, внедрения и поддержки они все-равно есть, только могут быть не выражены явно. И каждый спринт команда разработки их проходит заново.
Причем не всегда удается этап сбора требований и проектирования поместить в один спринт, тогда запускают параллельно с разрабткой "спринты аналитики", но это уже не Скрам в его классическом виде.
Также довольно популярен процесс организации разработки посредством Канбан-метода. В нем есть этап Discovery, когда мы подготавливаем артефакты на вход команде разработке, затем команда проходит через точку принятия обязательств и в рамках этапа Delivery поставляет требуемую функциональность.
При этом неважно, по какому подходу работает команда разработка, этапы сбора требований и проектирования никуда не деваются, они могут быть только более или менее выражены.
Разница в том, что в водопадном подходе сбор требованй и проектирование по всему проекту происходит в самом начале на всю разрабатываемую систему, то в итеративных подходах эти этапы начинаются каждый раз заново с началом каждой итерации в объеме, необходимом для поставки запланированной функциональности за итерацию.
Роль аналитика
В любом случае кто-то должен выявить потребности стейкхолдеров, чтобы взять их в проработку. Стейкхолдеры должны каким-то образом получать информацию о ходе разработки. Также проектирование, пусть и в неформальном виде, должно пройти до начала кодирования.
В небольших команиях и стартапах, сотрудника с должностью аналитика может и не быть, так как в команде "все делают всё", и тогда члены команды берут его функции на себя.
Например, сбором требований может заниматься продакт либо проджект-менеджер, системным проектированием занимается команда разработки, либо выделенный архитектор, а проектированием API - разработчики, непосредственно выполняющие задачу.
В больших компаниях часто происходит наоборот: есть отдельная должность аналитика, и в зависимости от команды аналитик может брать на себя ещё дополнительные задачи и функции других ролей.
Например, он может отвечать за контроль сроков и процессов разработки по тем функциям, по которым проводили анализ, т. е. практически заниматься проектным менеджментом. Аналитик может помогать выявлять потребности пользователей, если речь идет про продуктовую разработку, т.е. брать на себя часть функций по управлению продуктом.
Где-то аналитик может быть глубоко погружён в системное проектирование и может принимать решения, как те или иные функции будут распределены по компонентам системы, и затем защищать принятые решения на "архитектурном комитете".
Аналитики могут быть погружены в проектирование API, потому что они знают структуры данных и функции, и могут корректно спроектировать API.
Аналитики могут помогать в разборе различных инцидентов, потому что знают, как система работает внутри и могут понять, почему что-то пошло не так.
Главное, помнить, что описанные выше роли - это только точки роста для аналитика, и он вовсе не обязан заменять продакта, проджекта, архитектора и тех. поддержку.
В следующей серии мы рассмотрим навыки бизнес-аналитика, которые требуются для выполнения этой роли.
Подписывайтесь на канал и получайте полезную информацию по управлению проектами, системной и бизнес-аналитике.