Давайте поговорим о необходимости совмещения или разделения системного и бизнес-аналитиков в команде разработки ИТ продукта. Почему иногда нужно их разделять и на разных людей, а иногда совмещать вместе.
Начнем с эффекта масштаба корпораций, но не того эффекта, который позволяет им масштабировать выручку, а того, который заставляет их растить штат, хотя эти два эффекта и очень связаны.
Представим что вы инди-хакер или разработчик одного мини-продукта с одной простой функцией. Например инженерный калькулятор или сайт-лендинг для семейной пекарни. Вы в целом выполняете все функции на проекте - вы понимаете цель (к чему нужно прийти), понимаете каким путем туда пойдете (технологии и ТЗ), сами идете туда (пишите код) и даже проверяете, что туда пришли (тестируете продукт). Эффект 1 человека тут прекрасно работает, вы можете все техническое задание держать в голове, сам продукт не сложный и все прекрасно. Почему в корпорациях не работает столько одиночек на все руки?
По разными причинам:
1) Для более сложных продуктов нужна специализация.
2) Для более масштабных продуктов нужен взгляд со стороны.
3) Для долгих продуктов нужно параллелить усилия.
Специализация. Нельзя быть одновременно крутым дизайнером, который знает про все новые тренды и инструменты и крутым бэк-разработчиком. который знает все фреймворки. Сначала вы упретесь в нехватку времени, что было хорошо описано в книге "Алиса в стране чудес" - «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!». Это конечно про ИТ и про постоянно появляющиеся новые технологии. И даже если вы будете не спать ночами, читать все статьи и форумы и работать за двоих, то упретесь в другое ограничение - разный стиль мышления. Дизайнер и бэк-разработчик по разному мыслят, один про креативность и визуализацию, а другой про оптимизацию ресурсов, следование техническим стандартам и поиск багов (хотя надо сказать, что разработка та еще творческая профессия).
Взгляд со стороны. Возьмем разделение разработчика и тестировщика. Казалось бы кто лучше протестирует свой код, как не сам разработчик, но тут мы видим два парадокса. Во -первых для лучшего тестирования нужен взгляд со стороны, то есть посмотреть под привычные вещи с нового ракурса. В разработке для этого придумали параллельную разработку, но она не закрывает все узкие моменты. А во-вторых - нужно жестко и критично посмотреть на продукт со стороны. Когда ты его сам разрабатываешь с нуля, видишь как создается твое детище, очень сложно относится к нему критически, потому что свое это "настоящее и любимое". Как раз для этого нужен тестировщик, человек с холодной головой и беспристрастным взглядом. В моем опыте, был случай, когда на проекте тестировщики очень подружились с разрабами, кто уменьшило нахождение багов на 25%. Баги конечно были, просто их меньше находили.
Параллельность.
Несмотря на производственный цикл, аналитика-разработка-тестирование, некоторые вещи можно параллелить. Разработчик может проектировать систему когда есть верхнеуровневые требования, а тестировщик писать тест-кейсы по аналитике. не дожидаясь конца разработки.
Теперь вернемся к бизнес-аналитику и системному аналитику. Задача первого хоть как-то понять желания бизнеса и оформить Бизнес-Требования. Задача второго - сделать так, чтобы итоговая разработка была сделана четко по бизнес-требованиями. На увеличении масштаба проектов это приводит к тому, что бизнес-аналитик все сильнее погружается в бизнес, варится там вместе с заказчиком и временами сам подсказывает заказчику, в каких случаях нужно автоматизировать работу, а в каких случаях потерпеть. Он хороша знает про важность MVP, про тестирование бизнес-гипотез, про отчеты, собранные на коленке в Экселе. А системный разработчик наоборот все больше уходит в разработку - ему теперь нужно понимать корпоративную архитектуру, разбираться откуда брать какие данные, какие компоненты присутствуют в системе и даже временами писать контракты функций. Другими словами задача бизнес-аналитика - сэкономить деньги заказчика и верить, что это решение реально принесет эффект бизнесу, а задача системного аналитика, чтобы на выходе получилось именно то, что заказчик попросил - с нужной нагрузкой, безопасностью и возможность масштабирования и поддержки.
Как понять, что у вас 1 человек совмещает две функции и пора их разделять:
1. Он становится узким звеном в производственном процессе, то есть задачи идут, разработчики простаивают, а аналитик перегружен. По принципам Элияху Голдратта и его книги "Цель" - начните с 1 звена, которое дает наименьшую производительность.
2. Команды разработки большие - более 5-6 разработчиков на 1 мини-продукт.
3. Очень запутанный и хаотичный бизнес и нужна помощь в упорядочивании хаоса.
4. Ресурсы на поддержку приложения очень высокие - неясные экранные формы или разная логика на разных экранных формах, под нагрузкой приложение часто падает или виснет, слишком много дефектов на грани бизнеса и разработки.
Как понять, что у вас 2 человека, а нужен один:
1. Low-code платформа, которая изначально нужна для того, чтобы обходиться без аналитиков
2. Маленький продукт (2-3 экранные формы) без необходимости роста, нет нагрузки.
3. Вам не важно качество продукта :)
4. В бизнес затесался сотрудник с ИТ опытом, то есть он может и свои бизнес-задачи закрывать и говорить с разработкой на 1 языке, что довольно редкий случай.
На практике чаще происходит, когда из 1 специалиста появляется два с разными ролями по ходу роста бизнеса. Это естественный путь эволюции. Обратная ситуация это скорее изменение цели продукта, схлопывание бизнеса или стагнация, которая ведет к уменьшению качества продукта.
