Как простой Telegram-бот помогает с подбором и при этом экономит деньги
Или как освободить скрининг от человеческого фактора.
Последние несколько лет я активно участвую в процессе подбора системных аналитиков в департамент развития цифровых сервисов. Начинал с проведения скринингов и технических интервью, а уже будучи руководителем направления, принимал решение о распределении кандидатов по командам и их трудоустройстве.
Минувший год удивил значительным сокращением вакансий системных аналитиков на позицию junior. Бизнес, финансирующий деятельность команд, в большей степени заинтересован в найме опытных специалистов, способных сразу приступить к разработке новых цифровых продуктов. Всё меньше команд готовы вкладываться в развитие начинающих специалистов.
Но найм никто не останавливает. При этом бизнес выражает недовольство из-за отвлечения технических экспертов от работы над продуктами для проведения технических интервью. А многие кандидаты демонстрируют знания и навыки на уровне junior, что также не бьется с потребностями бизнеса. Поэтому было решено проанализировать процесс подбора и найти точки роста, чтобы закрывать потребности в найме с минимальными затратами времени технических экспертов. В результате появился скрининг-бот, о котором речь пойдет ниже.
Как Git LFS влияет на опыт ведения документации рядом с кодом
Подход к ведению документации рядом с кодом используется в Альфа-Банке на протяжении нескольких лет. Он хорошо подходит для документирования API и сервисов, не требующего примеров пользовательского интерфейса. Однако с документацией на мобильные и веб-фронты ситуация немного сложнее.
В статье обозначу проблему, связанную с ведением фронтовой документации рядом с кодом, и приведу одно из решений на базе Git LFS. Затем поделюсь результатами двух пилотов, проведённых в Банке во втором квартале 2023. Их результаты помогут оценить влияние Git LFS на опыт ведения фронтовой документации рядом с кодом. Статья подойдёт всем, кто занимается подготовкой технической документации на программные продукты.
Есть разные подходы к ведению требований к ПО: одни пишут полноценные сценарии использования, другие выбирают пользовательские истории, а третьи — вообще избегают формализации требований, считая это пустой тратой времени.
Но я так не считаю. Формализация — большой и важный этап разработки требований. В статье об этом расскажу: как происходит ведение требований у нас, какие этапы мы проходим, каких правил придерживаемся и что будет, если отклоняться от правил. Если вы системный или бизнес-аналитик, владелец продукта или просто работаете с требованиями к программному обеспечению, то эта статья для вас.
В Альфа-Банке мы уже больше 5 лет ведём документацию рядом с кодом. Но она используется не для всех проектных документов. Дело в том, что документация у нас делится по слоям: фронт, миддл и бэкенд. Если с миддлом — слоем микросервисов — всё хорошо, то вот с переводом фронт- и бэк-документации в Bitbucket возникает трудность в необходимости хранения бинарников с примерами пользовательского интерфейса.
В статье я опишу, как мы работаем с миддл-документацией, и поделюсь текущими наработками, а на примере документации по фронту обозначу существующие трудности и расскажу, какие варианты решения мы рассматриваем. Статья подойдёт техническим писателям, системным аналитика и всем, кто занимается подготовкой технической документации на программные продукты.
В рамках одного из первых проектов в Альфе мы с командой делали приложение по работе с группами платежей. Приложение позволяло вместо поштучной обработки каждой отдельной платёжки выбирать сразу несколько платёжных поручений, подписывать их и отправлять в Банк на исполнение. Всего за несколько кликов. Очень удобный функционал для клиентов, работающих со множеством платежей одновременно.
В текущем спринте нам с командой надо было реализовать операцию по отправке группы платежей в Банк (подписание и прочие подготовительные операции выполнялись в старой версии системы). Времени — всего неделя. Из наработок, которые мы могли бы переиспользовать, API, позволяющий отправлять в Банк на исполнение единичный платёж.
Команда принимает решение — для каждого платёжного поручения группы, выбранного на фронте, делать вызов существующего API для поштучной отправки платежей. Спустя неделю отчитываемся о достижении цели спринта. Новый функционал открыт на клиентов. Теперь они могут за пару кликов отправлять сразу десять, двадцать и больше платежей в Банк на исполнение. Ценность определённо есть.
Но какой ценой была достигнута цель спринта? Ростом нагрузки на сеть. Увеличением времени обработки запросов клиентов. Таймаутами. Решение было неоптимальным. У команды образовался техдолг.