Системный аналитик и метрики продукта — взболтать, но не смешивать?
IT-компании, которые занимаются продуктовой разработкой, часто ищут в свои команды аналитиков. Зачем тут аналитик? Чтобы проверять гипотезы, придуманные командой, разрабатывать системы метрик (и поддерживать их), проводить разные эксперименты, а потом выдавать рекомендации по улучшению продукта. Это и есть продуктовый аналитик, также известный под кодовым именем “аналитик данных”.
В удалённых каналах Альфа-Банка мы тоже разрабатываем продукты. Но у нас в командах нет других аналитиков, кроме системных, в обязанности которых входит сбор и анализ требований, а также проектирование и документирование решений. Внимательный читатель заметит тут небольшое противоречие. Это что же выходит, что системные аналитики активно занимаются еще и аналитикой продуктовой?
Под катом — небольшое исследование, которое и призвано было оценить, насколько сильно системные аналитики вовлечены в процесс работы с метриками продукта.
Как проходил набор в Школу системного анализа Альфа-Банка
Крупные IT-компании довольно давно проводят школы для студентов и выпускников инженерных и математических специальностей. Кто не слышал о Школе анализа данных Яндекса или Школе программистов HeadHunter? Возраст этих проектов уже измеряется десятилетием.
Не отстают от них и банки. Достаточно вспомнить Школу 21 Сбербанка, Raiffeisen Java School или Финтех Школу Tinkoff.ru. Эти проекты призваны не только дать теоретические знания, но и развить практические навыки, сформировать портфолио молодого специалиста, повысить его шансы на трудоустройство.
В конце мая мы анонсировали первый набор в Школу системного анализа Альфа-Банка. Прошло два месяца, набор окончен. Сегодня я хочу рассказать, как он проходил и что могло быть сделано иначе. Всех заинтересованных приглашаю под кат.
Привет, Хабр! Меня зовут Леша, я системный аналитик одной из продуктовых команд Альфа-Банка. Сейчас я занимаюсь развитием нового интернет-банка для юридических лиц и индивидуальных предпринимателей.
А когда ты аналитик, тем более в подобном канале, без документации и плотной работы с ней — никуда. И документация — это та штука, к которой всегда возникает много вопросов. Почему веб-приложение не описано? Почему в спецификации указано, как должен работать сервис, а работает он вообще не так? Почему вообще спецификацию в состоянии понять только два человека, один из которых ее написал?
При этом игнорировать документацию нельзя по очевидным причинам. И чтобы упростить нам жизнь, мы решили провести оценку качества документации. Как именно мы это делали и к каким выводам пришли — под катом.
Всем привет! Меня зовут Леша. Я работаю системным аналитиком в Альфа-Банке, где занимаюсь развитием электронных каналов, в частности, новым интернет-банком для юридических лиц и индивидуальных предпринимателей.
Кросс-функциональность в Scrum предполагает, что команда обладает всеми компетенциями, необходимыми для самостоятельной разработки продукта. Но должен ли каждый член команды фокусироваться строго на своей основной компетенции? Или стоит развивать кросс-компетенции, на которых специализируются коллеги?
Сегодня я хочу рассказать об опыте развития кросс-компетенций, полученном моей командой при реализации модуля почтовой корреспонденции в новом интернет-банке. Как мы до этого дошли и что из этого вышло? Всех заинтересованных прошу под кат.
Всем привет! Меня зовут Леша. Я работаю в подразделении Альфа-Банка, занимающемся развитием электронных каналов. Интернет- и мобильный банкинг – это все про нас.
Часто, говоря про Scrum, мы подразумеваем одну команду, работающую над одним продуктом и состоящую не более чем из девяти человек. Но иногда продукт бывает настолько сложным, что для его реализации к назначенному сроку девяти человек бывает мало. Что же делать?
Сегодня я хочу рассказать о нашем опыте масштабирования Scrum, когда над одним продуктом работало сразу несколько команд. Как мы до этого дошли и что из этого вышло? Всех заинтересованных прошу под кат.