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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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