Зачем существуют профессиональные конференции? Зачем одни подают заявки на доклады, стремятся поделиться практическим опытом или личным мнением относительно того или иного вопроса? Зачем другие платят не маленькие деньги, покупают билеты, слушают, о чём говорят первые?

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

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

Техническое интервью является практически неотъемлемым этапом трудоустройства на ИТ-вакансию. Его цель состоит в первую очередь в оценке технических знаний и навыков кандидата. Его проводят, чтобы понять, насколько кандидат соответствует требованиям открытой вакансии.

О том, как проводить техническое интервью системного аналитика, сказано много. В интернете можно найти записи публичных интервью. Действующие системные аналитики запускают свои «школы» и консультируют «начинашек», рассказывают, как успешно пройти техническое интервью, причём иногда сразу на уровень middle/ middle+.

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

Привет, меня зовут Алексей Лобзов, я руководитель направления развития компетенции системного анализа в Альфа-Банке. В прошлом году мы в банке проводили Analyze IT Meetup. Кроме интересных докладов у нас был круглый стол, куда мы пригласили Лидера компетенции из Сбера, Solution архитектора из СИБУР Digital и Product Owner’а из Альфа-Банка.

Что их всех объединяет? Они все в прошлом были системными аналитиками. Наши герои поделились тем, как из системных аналитиков (СА) перешли на новую позицию. Тема оказалась животрепещущей — было много вопросов как на митапе, так и после, поэтому позже мы той же компанией и на ту же тему записали подкаст в СИБУР Digital.

И если для вас вопрос «А куда расти дальше, если я уже сеньор?» стоит «на повестке дня», то приглашаю почитать статью, подготовленную по материалам круглого стола. 

А с использованием методов линейного программирования.

Сталкивались ли вы с понятием линейного программирования? А его применением на практике? В университете мы изучаем разные разделы математики, нам рассказывают про математические модели и методы, однако вопросу их практического применения часто уделяется недостаточно внимания.

В статье я поделюсь основными тезисами моего доклада, представленного на конференции Analyst Days #16. В нём я постарался показать, как методы линейного программирования могут быть применены в работе команды, живущей спринтами. Под катом вас ждет альтернативный взгляд на планирование спринта.

Или как освободить скрининг от человеческого фактора.

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

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

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

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

В статье обозначу проблему, связанную с ведением фронтовой документации рядом с кодом, и приведу одно из решений на базе Git LFS. Затем поделюсь результатами двух пилотов, проведённых в Банке во втором квартале 2023. Их результаты помогут оценить влияние Git LFS на опыт ведения фронтовой документации рядом с кодом. Статья подойдёт всем, кто занимается подготовкой технической документации на программные продукты.

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

Но я так не считаю. Формализация — большой и важный этап разработки требований. В статье расскажу: как происходит ведение требований у нас, какие этапы мы проходим, каких правил придерживаемся и что будет, если отклоняться от правил. Если вы системный или бизнес-аналитик, владелец продукта или просто работаете с требованиями к программному обеспечению, то эта статья для вас.

В Альфа-Банке мы уже больше 5 лет ведём документацию рядом с кодом. Но она используется не для всех проектных документов. Дело в том, что документация у нас делится по слоям: фронт, миддл и бэкенд. Если с миддлом — слоем микросервисов — всё хорошо, то вот с переводом фронт- и бэк-документации в Bitbucket возникает трудность в необходимости хранения бинарников с примерами пользовательского интерфейса. 

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