В Альфа-Банке мы уже больше 5 лет ведём документацию рядом с кодом. Но она используется не для всех проектных документов. Дело в том, что документация у нас делится по слоям: фронт, миддл и бэкенд. Если с миддлом — слоем микросервисов — всё хорошо, то вот с переводом фронт- и бэк-документации в Bitbucket возникает трудность в необходимости хранения бинарников с примерами пользовательского интерфейса.
В статье я опишу, как мы работаем с миддл-документацией, и поделюсь текущими наработками, а на примере документации по фронту обозначу существующие трудности и расскажу, какие варианты решения мы рассматриваем. Статья подойдёт техническим писателям, системным аналитика и всем, кто занимается подготовкой технической документации на программные продукты.
В рамках одного из первых проектов в Альфе мы с командой делали приложение по работе с группами платежей. Приложение позволяло вместо поштучной обработки каждой отдельной платёжки выбирать сразу несколько платёжных поручений, подписывать их и отправлять в Банк на исполнение. Всего за несколько кликов. Очень удобный функционал для клиентов, работающих со множеством платежей одновременно.
В текущем спринте нам с командой надо было реализовать операцию по отправке группы платежей в Банк (подписание и прочие подготовительные операции выполнялись в старой версии системы). Времени — всего неделя. Из наработок, которые мы могли бы переиспользовать, API, позволяющий отправлять в Банк на исполнение единичный платёж.
Команда принимает решение — для каждого платёжного поручения группы, выбранного на фронте, делать вызов существующего API для поштучной отправки платежей. Спустя неделю отчитываемся о достижении цели спринта. Новый функционал открыт на клиентов. Теперь они могут за пару кликов отправлять сразу десять, двадцать и больше платежей в Банк на исполнение. Ценность определённо есть.
Но какой ценой была достигнута цель спринта? Ростом нагрузки на сеть. Увеличением времени обработки запросов клиентов. Таймаутами. Решение было неоптимальным. У команды образовался техдолг.
Недавно Совкомбанк вместе со Сколково проводил онлайн-чемпионат для системных аналитиков и Java-разработчиков на площадке All Cups. В нём принимал участие наш системный аналитик, Алексей @alobzov Лобзов.
Собственно, Лёша и стал победителем чемпионата. В этом посте мы взяли у него небольшое интервью, в котором он поделился своими впечатлениями.
Как мы унифицировали онбординг аналитиков удалённых каналов доступа
Испытательный срок — это не только время, за которое компания проверяет, правильного ли сотрудника взяли на ставку, справляется ли он с обязанностями и как в целом работает. Это в том числе (об этом часто забывают) период, за который сотрудник не менее пристально оценивает компанию: соответствуют ли задачи озвученным на собеседовании, как дела с командой, адекватно ли выстроены рабочие процессы, да и вообще — нравится работать тут или нет.
И при этой оценке компании со стороны сотрудника важную роль играет то, насколько хорош ваш онбординг (а он может драматически отличаться не только в рамках всей организации, но и даже в каждом отдельно взятом департаменте). Где-то это прекрасное и пошаговое погружение нового коллеги в работу, процессы, особенности коммуникации. Где-то по принципу “А я думал, дали пистолет — и крутись как хочешь”.
Сегодня я хочу рассказать, как мы унифицировали онбординг специалистов для одного из подразделений Альфа-Банка — центра компетенций аналитики удаленных каналов доступа. Под катом — что и как мы делали (и зачем), результаты, критерии для оценки новичков, а также пара полезных схем и шаблонов для тех, кто тоже хочет наладить онбординг.
Знакома ли вам ситуация, когда потребности вашего бизнеса растут, а людей под их реализацию не хватает? Что в таком случае делать? Где искать людей с нужными компетенциями и стоит ли вообще этим заниматься?
Так как проблема, прямо скажем, не новая, то пути её решения уже есть. Одни компании прибегают к аутстаффинговой схеме и привлечению специалистов из внешних организаций. Другие расширяют географию поиска, пользуются услугами кадровых агентств. А третьи находят людей без опыта и растят их под себя.
Одним из наших наиболее серьезных проектов подготовки системных аналитиков с нуля, наверное, была Школа системного анализа, о которой докладывал Кирилл Капранов на прошедшем в ноябре AnalyzeIT MeetUp #3. Однако прежде, чем войти в проект, мы решили провести эксперимент, взяли человека без опыта и попробовали вырастить из него системного аналитика, удовлетворяющего нашим требованиям. Под катом — как готовили аналитика и что из этой затеи в итоге вышло.