Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Всем привет!
Меня зовут Екатерина, и я... аналитик! :)
В IT я уже 11 лет, и большую часть из них занималась аналитикой и управлением.
Это моя первая статья, которая, надеюсь, даст старт серии материалов про профессию аналитика и не только.
Почему этот вопрос так важен, или Аналитическое разнообразие
Профессия аналитика в IT не перестаёт развиваться и удивлять нас большим разнообразием функциональных обязанностей, которые могут различаться в разных компаниях. Каждый, кто работает или работал аналитиком и хоть раз менял место работы, прекрасно понимает, что нет двух одинаковых мест с идентичным набором обязанностей, несмотря на то, что в целом их можно обобщить как «сбор требований, анализ, документирование». Отпечаток на такое разнообразие накладывают предметная область, техническая подготовка команды, зрелость компании и сам продукт.
Нам всем известно, что есть бизнес-аналитики, системные аналитики, аналитики данных и много других. Как вы думаете, кто такие инженеры-аналитики? Чтобы разобраться в этом, вернёмся к истокам и ещё раз рассмотрим несколько базовых направлений в аналитике.
Бизнес-аналитик или аналитик бизнес-процессов. В работе бизнес-аналитика много общения с заказчиками или стейкхолдерами. Его основная задача — выявить и описать все потребности бизнеса с учётом ограничений и рамок проекта, при этом документы нужно написать на всем понятном языке. Качественно построить бизнес-процессы помогает погружённость в предметную область. О том, как качественно собрать и описать требования, есть много полезной литературы: книги американского программиста Карла Вигерса и работы по BABOK — базе знаний по бизнес-анализу.
Системный аналитик. Выступает переводчиком между бизнесом и разработкой. Накладывает уже готовые бизнес-требования на возможности системы и при необходимости её дорабатывает. Системный аналитик должен хорошо знать свой продукт как со стороны функциональных возможностей, так и со стороны технической реализации. Умение проектировать системы (в том числе высоконагруженные), — неотъемлемая компетенция на проектах при отсутствии системного архитектора.
Продуктовый аналитик или аналитик данных. Продуктовый аналитик изучает поведение пользователей при их взаимодействии с продуктом. Анализируя взаимодействие пользователя с продуктом, можно выявить частоту используемости функционала и путь пользователя, а также составить портрет пользователя: к какой категории он принадлежит, какие продукты и функции ему интересны, что он не использует. Чтобы собрать и обработать большой объём данных, необходимо обладать навыками программирования и математическими знаниями, а ещё чувствовать продукт. Это отдельный огромный пласт аналитиков со своими вариациями компетенций и глубиной технических знаний. Могу отметить такие: продуктовый аналитик, Data-аналитик, Data Scientist.
Аналитик требований. Занимается детальной проработкой и описанием декомпозированных задач (требований). Хотя и принято выделять этот вид аналитика как отдельный, мне кажется, это начальный этап развития для любого из описанных выше вариантов. На начальном этапе любой аналитик занимается в большей степени анализом и документированием уже понятных требований, в которых не нужно глубоко знать бизнес предметной области или принимать важные архитектурные решения при разработке нового функционала.
Кто же такие инженеры-аналитики
Инженеры-аналитики в Кошельке — это коктейль из бизнес- и системной аналитики. В зависимости от продукта, в развитии которого участвует аналитик, может преобладать роль бизнес-аналитика или системного аналитика или же на одинаковом уровне важны компетенции обеих ролей.
Мы работаем в продуктовых командах, где у каждого продукта своя чёткая цель и нам важно, чтобы у всех членов команды был фокус на продукт и все действовали в едином направлении.
В чём сложность
Бизнес-аналитик и системный аналитик смотрят на один и тот же продукт по-разному.
Бизнес-аналитик (БА), в первую очередь, ориентируется на потребности бизнеса: кому нужен этот продукт, будет ли он приносить прибыль, какими именно минимальными требованиями можно закрыть потребность, как лучше сделать для пользователя. Зачастую на этом этапе мало кто думает о технологических ограничениях продукта. В этом есть свои несомненные плюсы — фантазия не ограничена системой, и можно смело выходить за рамки типовых решений и создавать новаторские предложения.
Если бы рядом сидел разработчик, он, вероятно, мог быть не так вдохновлён, понимая, что текущий продукт не способен без костылей изящно поддержать новые требования. Итог: раз за разом продукт теряет свою изящность в коде, а разработчик всё больше негодует.
Системный аналитик, напротив, в первую очередь концентрируется на возможностях системы и предлагает такое решение, которое максимально вписывается в текущие возможности, закрывает бизнес-потребность и не выливается в бесконечные доработки. Однако такие решения часто кажутся заказчикам серыми и скучными, в них нет какой-то новизны и ничто не цепляет, хотя всё есть и работает.
Если обобщить, каждый из подходов требует своего распределения внимания:
сверху вниз — от потребностей бизнеса к системе;
снизу вверх — от возможностей системы к бизнесу.
Подход «сверху вниз» обычно используется в продуктовых компаниях, когда стейкхолдером выступает руководитель продукта (product owner) и первичны потребности продукта. На это также влияет то, что компания-разработчик без посредников получает обратную связь от пользователей.
А вот подход «снизу вверх» обычно бывает на заказных доработках, когда есть какой-то типовой продукт, который настраивают под потребности заказчика, и местами притягивают за уши. Такой же подход может быть в задачах интеграции двух типовых продуктов разных компаний, которые нельзя сильно модифицировать, так как на это потребуются ресурсы обеих сторон и процесс может сильно затянуться.
Из этого можно сделать вывод, что совмещение БА и СА решает проблему на стыке компетенций этих двух ролей, однако требует большого уровня концентрации. Именно те компетенции, которые преобладают в опыте аналитика, становятся основными ингредиентами его «аналитического коктейля».
В моём личном коктейле преобладает СА. Когда я стала больше работать с бизнесом продуктов, мне часто в голове приходилось переключать воображаемый рубильник: «Так, стоп! Включить БА и подумать над вопросами “А зачем?” или “Что было бы лучше?”», прежде чем проектировать «А как это технически сделать?».
Чем больше ваша основа для коктейля, тем первичнее вопросы в голове будут возникать именно от неё.
Моё мнение: качественно смешивать можно два направления аналитики, подмешивая некоторые ингредиенты (компетенции) из других направлений.
«Смешать, но не взбалтывать» :)
Если вы можете смешать больше и без головной боли, я вами бесконечно восхищаюсь.
Да, мы инженеры
В разных компаниях подобное совмещение компетенций может называться по-разному. Я однажды столкнулась с понятием «инженер-аналитик». Оно мне показалось самым истинным, и вот почему:
Инжене́р (фр. ingénieur ← от лат. ingenium — способности, изобретательность) — специалист, осуществляющий инженерную деятельность.
Инженеры вовлечены, как правило, во все процессы жизненного цикла технических устройств, являющихся предметом инженерного дела, включая прикладные исследования, планирование, проектирование, конструирование, разработку технологии изготовления (сооружения), подготовку технической документации, производство, наладку, испытание, эксплуатацию, техническое обслуживание, ремонт, утилизацию устройства и управление качеством.
Основным содержанием деятельности инженера является разработка новых и/или оптимизация существующих инженерных решений. Например, оптимизация проектного решения (в том числе вариантное проектирование), оптимизация технологии, менеджмент и планирование, управление разработками и непосредственное контролирование производства. Новые инженерные решения зачастую выливаются в изобретения. В своей деятельности инженер опирается на фундаментальные и прикладные науки.
Классическое определение инженера применимо и к разработке программного обеспечения.
Инженер-аналитик в Кошельке работает над фичей с момента возникновения идеи.
На первом этапе владелец продукта совместно с инженером-аналитиком, data-аналитиком и продуктовым дизайнером прорабатывают видение новой функциональности (переработку старой), с учётом метрик, которых хотим достигнуть, и проблем, которые хотим решить с максимальным удобством для конечного пользователя. Описываются и проверяются гипотезы. Так создаётся концепция фичи.
На втором этапе работы инженер-аналитик углубляется в собранные требования, уточняет и документирует их, погружаясь в техническую сторону задачи, и предлагает оптимальное решение. Совместно с дизайнером более детально прорабатываются макеты экранных форм на предмет всех крайних случаев. После того как уточнены все моменты и команда согласилась с постановкой, задача планируется в разработку. Консультация на всех этапах, поддержка актуальности требований и верификация решения на факт выполнения требований — также неотъемлемые части работы инженера-аналитика.
Инженер — это ответственность и статус. И чем серьёзнее проект, чем сложнее задачи, тем больше разносторонних компетенций нужно применить и тем больше нужно драйва.
Заключение
Аналитическое сообщество всё дальше уходит от чётких ролевых матриц. Будущее — в осознанном и грамотном совмещении компетенций разных направлений аналитики. Преимущество именно в том, что больший фокус отдаётся продукту, а расширенный охват компетенций позволяет более разносторонне и качественно подойти к любой задаче. Уход от классического понимания БА и СА в пользу инженеров-аналитиков выгоден не только продукту, но и самому сотруднику, так как есть возможность расширять свои знания в нескольких направлениях аналитики, получать новые разносторонние задачи и при этом не переключаться между проектами разных продуктов.
