В рамках одного из первых проектов в Альфе мы с командой делали приложение по работе с группами платежей. Приложение позволяло вместо поштучной обработки каждой отдельной платёжки выбирать сразу несколько платёжных поручений, подписывать их и отправлять в Банк на исполнение. Всего за несколько кликов. Очень удобный функционал для клиентов, работающих со множеством платежей одновременно.

В текущем спринте нам с командой надо было реализовать операцию по отправке группы платежей в Банк (подписание и прочие подготовительные операции выполнялись в старой версии системы). Времени — всего неделя. Из наработок, которые мы могли бы переиспользовать, API, позволяющий отправлять в Банк на исполнение единичный платёж.

Команда принимает решение — для каждого платёжного поручения группы, выбранного на фронте, делать вызов существующего API для поштучной отправки платежей. Спустя неделю отчитываемся о достижении цели спринта. Новый функционал открыт на клиентов. Теперь они могут за пару кликов отправлять сразу десять, двадцать и больше платежей в Банк на исполнение. Ценность определённо есть.



Но какой ценой была достигнута цель спринта? Ростом нагрузки на сеть. Увеличением времени обработки запросов клиентов. Таймаутами. Решение было неоптимальным. У команды образовался техдолг.

Испытательный срок — это не только время, за которое компания проверяет, правильного ли сотрудника взяли на ставку, справляется ли он с обязанностями и как в целом работает. Это в том числе (об этом часто забывают) период, за который сотрудник не менее пристально оценивает компанию: соответствуют ли задачи озвученным на собеседовании, как дела с командой, адекватно ли выстроены рабочие процессы, да и вообще — нравится работать тут или нет.

И при этой оценке компании со стороны сотрудника важную роль играет то, насколько хорош ваш онбординг (а он может драматически отличаться не только в рамках всей организации, но и даже в каждом отдельно взятом департаменте). Где-то это прекрасное и пошаговое погружение нового коллеги в работу, процессы, особенности коммуникации. Где-то по принципу “А я думал, дали пистолет — и крутись как хочешь”.



Сегодня я хочу рассказать, как мы унифицировали онбординг специалистов для одного из подразделений Альфа-Банка — центра компетенций аналитики удаленных каналов доступа. Под катом — что и как мы делали (и зачем), результаты, критерии для оценки новичков, а также пара полезных схем и шаблонов для тех, кто тоже хочет наладить онбординг.

Знакома ли вам ситуация, когда потребности вашего бизнеса растут, а людей под их реализацию не хватает? Что в таком случае делать? Где искать людей с нужными компетенциями и стоит ли вообще этим заниматься?

Так как проблема, прямо скажем, не новая, то пути её решения уже есть. Одни компании прибегают к аутстаффинговой схеме и привлечению специалистов из внешних организаций. Другие расширяют географию поиска, пользуются услугами кадровых агентств. А третьи находят людей без опыта и растят их под себя.

Одним из наших наиболее серьезных проектов подготовки системных аналитиков с нуля, наверное, была Школа системного анализа, о которой докладывал Кирилл Капранов на прошедшем в ноябре AnalyzeIT MeetUp #3. Однако прежде, чем войти в проект, мы решили провести эксперимент, взяли человека без опыта и попробовали вырастить из него системного аналитика, удовлетворяющего нашим требованиям. Под катом — как готовили аналитика и что из этой затеи в итоге вышло.

IT-компании, которые занимаются продуктовой разработкой, часто ищут в свои команды аналитиков. Зачем тут аналитик? Чтобы проверять гипотезы, придуманные командой, разрабатывать системы метрик (и поддерживать их), проводить разные эксперименты, а потом выдавать рекомендации по улучшению продукта. Это и есть продуктовый аналитик, также известный под кодовым именем “аналитик данных”.

В удалённых каналах Альфа-Банка мы тоже разрабатываем продукты. Но у нас в командах нет других аналитиков, кроме системных, в обязанности которых входит сбор и анализ требований, а также проектирование и документирование решений. Внимательный читатель заметит тут небольшое противоречие. Это что же выходит, что системные аналитики активно занимаются еще и аналитикой продуктовой?



Под катом — небольшое исследование, которое и призвано было оценить, насколько сильно системные аналитики вовлечены в процесс работы с метриками продукта.

Крупные IT-компании довольно давно проводят школы для студентов и выпускников инженерных и математических специальностей. Кто не слышал о Школе анализа данных Яндекса или Школе программистов HeadHunter? Возраст этих проектов уже измеряется десятилетием.

Не отстают от них и банки. Достаточно вспомнить Школу 21 Сбербанка, Raiffeisen Java School или Финтех Школу Tinkoff.ru. Эти проекты призваны не только дать теоретические знания, но и развить практические навыки, сформировать портфолио молодого специалиста, повысить его шансы на трудоустройство.

В конце мая мы анонсировали первый набор в Школу системного анализа Альфа-Банка. Прошло два месяца, набор окончен. Сегодня я хочу рассказать, как он проходил и что могло быть сделано иначе. Всех заинтересованных приглашаю под кат.

Привет, Хабр! Меня зовут Леша, я системный аналитик одной из продуктовых команд Альфа-Банка. Сейчас я занимаюсь развитием нового интернет-банка для юридических лиц и индивидуальных предпринимателей.

А когда ты аналитик, тем более в подобном канале, без документации и плотной работы с ней — никуда. И документация — это та штука, к которой всегда возникает много вопросов. Почему веб-приложение не описано? Почему в спецификации указано, как должен работать сервис, а работает он вообще не так? Почему вообще спецификацию в состоянии понять только два человека, один из которых ее написал?



При этом игнорировать документацию нельзя по очевидным причинам. И чтобы упростить нам жизнь, мы решили провести оценку качества документации. Как именно мы это делали и к каким выводам пришли — под катом.

Всем привет! Меня зовут Леша. Я работаю системным аналитиком в Альфа-Банке, где занимаюсь развитием электронных каналов, в частности, новым интернет-банком для юридических лиц и индивидуальных предпринимателей.

Кросс-функциональность в Scrum предполагает, что команда обладает всеми компетенциями, необходимыми для самостоятельной разработки продукта. Но должен ли каждый член команды фокусироваться строго на своей основной компетенции? Или стоит развивать кросс-компетенции, на которых специализируются коллеги?

Сегодня я хочу рассказать об опыте развития кросс-компетенций, полученном моей командой при реализации модуля почтовой корреспонденции в новом интернет-банке. Как мы до этого дошли и что из этого вышло? Всех заинтересованных прошу под кат.

Всем привет! Меня зовут Леша. Я работаю в подразделении Альфа-Банка, занимающемся развитием электронных каналов. Интернет- и мобильный банкинг – это все про нас.

Часто, говоря про Scrum, мы подразумеваем одну команду, работающую над одним продуктом и состоящую не более чем из девяти человек. Но иногда продукт бывает настолько сложным, что для его реализации к назначенному сроку девяти человек бывает мало. Что же делать?

Сегодня я хочу рассказать о нашем опыте масштабирования Scrum, когда над одним продуктом работало сразу несколько команд. Как мы до этого дошли и что из этого вышло? Всех заинтересованных прошу под кат.

Что является основным инструментом, который использует руководитель при управлении проектом? Принято считать, что основным инструментом руководителя проекта является календарный план, в основе которого лежит сетевая модель работ по проекту. Однажды мне довелось реализовать сетевую модель работ на языке Python (код и описание здесь). Ниже приведены уроки, извлеченные по результатам проделанной работы.