📈 Четыре примера работы аналитиков: кейсы IT-компаний

Аналитики крупных компаний рассказали корреспонденту Proglib о самых интересных кейсах, над которыми им приходилось работать.

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

«Такое решение не имело аналогов на рынке»

Алексей Лобзов – главный системный аналитик АО «Альфа-Банк» и выпускник университета «МИФИ» по специальности «Прикладная информатика» (в области международного сотрудничества). Алексей рассказал корреспонденту Proglib о системе управления портфелями проектов, разработанной специализирующейся на вопросах проектного управления консалтинговой компанией.

Описание задачи

Наша команда внедряла систему управления портфелями проектов в ИТ-департаменте отечественной нефтяной компании. Заказчик предоставил описание процесса, в том числе методики ранжирования и выравнивания проектов относительно заданных ограничений. Ранее эти операции выполнялись с использованием нетривиальной модели, реализованной в файле Excel. Задача состояла в автоматизации процессов, причем решение должно было быть интуитивно понятным и удобным в использовании.

Этапы реализации

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

Наиболее интересна задача выравнивания проектов относительно заданных ограничений:

• количества стартов проектов в промежуток времени;
• объема платежей за единицу времени;
• количества доступных специалистов.

Мы точно знали, что Microsoft Project (на тот момент версии 2013 года) имеет близкую к нашей задаче функцию распределения доступных ресурсов и трудовых затрат. Внедряемая система включала модуль календарного планирования на базе Microsoft Project Server, поэтому мы решили построить решение на движке Microsoft.

1. Совместно с архитектором мы разработали сводную модель план-графиков проектов портфеля. В нее включались наиболее приоритетные проекты, попадающие в выделенный на исполнение лимит денежных средств;
2. Затем провели тестирование и отладку модели, выставляя ограничения на даты стартов проектов, назначая затраты и трудовые ресурсы, устанавливая лимиты и выполняя выравнивание средствами Microsoft Project.

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

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

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

Такое решение по ранжированию и выравниванию проектов на тот момент не имело аналогов на рынке.

Выводы

Это внедрение было для меня ценным по нескольким причинам:

1. Я глубоко погрузился в процессы управления портфелями проектов и получил уникальный опыт их автоматизации. На своей практике не вспомню столь масштабных задач в данной области;
2. Удалось подтвердить важность анализа возможностей переиспользования существующих решений. Кто знает, сколько времени и ресурсов мы бы потратили на разработку аналогичного Microsoft Project движка;
3. Участие в подобных проектах побуждает делиться знаниями с окружающими.

По результатам внедрения было написано несколько статей:

1. Лобзов А.В. На что обратить внимание при балансировке портфеля и выборе проектов // Управление проектами и программами. — 2016. — No2. — С.138–143
2. Лобзов А.В. Балансировка портфелей и выбор проектов при наличии альтернативных вариантов достижения стратегических целей.

Превратили платформу интерактивного телевидения «Ростелекома» в современный сервис Wink

О создании сервиса Wink рассказывает Константин Валеев, руководитель центра компетенций по системной аналитике в «Ростелеком Информационные Технологии». Константин окончил «Московский Институт Электроники и Математики», а затем аспирантуру и сейчас пишет диссертацию.

Описание задач и их решение

Нашей компании поручили развивать платформу интерактивного телевидения Ростелекома (сейчас это сервис Wink).

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

1. Провести анализ пользовательской части продукта;

2. Описать модель данных и сценарии использования;

3. Разобраться в архитектуре компонентов и их функциях;

4. Зафиксировать потоки данных.

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

Вторая задача – проект по созданию нового личного кабинета пользователя «Ростелекома», который должен стать не только инструментом управления услугами, но и полноценной точкой контакта клиента с компанией. Проводится интеграция множества систем, притом аналитики здесь выступают и как инженеры по требованиям и как проектировщики:

1. Собирают и документируют требования бизнеса;

2. Анализируют, декомпозируют и детализируют их;

3. На основе требований продумывают потоки, модель и маппинг данных;

4. Вместе с командой дизайна проектируют UX;

5. Совместно с разработчиками проектируют и согласовывают API.

Выводы

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

Для аналитика важно не только разбираться в чем-то уже существующем: продукте, системе, предметной области. Он должен принимать участие и в создании нового – в проектировании будущей системы.

Как сделать реверс-инжиниринг банковской системы с закрытым кодом и без документации

О проекте рассказывает старший аналитик компании Luxoft Анастасия Соболева. Анастасия окончила «Московский университет экономики, статистики и информатики» по специальности «Прикладная информатика в экономике». Ведет Telegram-канал Путь аналитика.

Описание задачи

Сейчас наша команда из 15 человек работает над проектом для крупного российского банка. Система поддерживает процессы фронт-офиса валютного дилинга. Также над проектом работает команда от бизнеса и ИТ-департамента банка.

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

Этапы реализации

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

Все потоки входных-выходных данных и наборы атрибутов удалось определить по документации смежных интегрированных решений, но сама система оставалась «черным ящиком». По наборам атрибутов удалось выделить ее основные объекты. По gap’ам потоков данных с помощью заполнились пробелы происходящего внутри системы при обработке данных. Там, где не нашлось информации, или была неоднозначность – посылали тестовые запросы от внешних систем и смотрели результаты на выходе.

Наша реализация еще в разработке: есть риски наличия «серых зон», поэтому на этапе интеграционного тестирования придется делать сверки, запуская одинаковые запросы через нашу систему и заменяемую.

Выводы

Для меня это был первый опыт масштабного реверс-инжиниринга. Себе в копилку забрала сам алгоритм действий. Очень важно до старта работы (особенно, если у задачи нечеткие границы и много неопределенности) наметить план и декомпозицию того, как этого «слона» будем есть и по каким частям. Важно заранее продумать, в какой последовательности исследовать интеграции и функциональные блоки. Можно смотреть сквозь все интеграции один процесс или идти по взаимодействию с каждой отдельной внешней системой.

Мое устоявшееся мнение – декомпозировать по API. Если несколько интеграций поддерживаются одним API, исследовать их нужно совместно. Если несколько интеграций с одинаковыми процессами, но разными API или технологиями интеграции – смотреть отдельно. Скорее всего потоки и последовательности обработки событий будут различаться.

Еще могу посоветовать для работы PlantUML – это инструмент для кодирования UML-диаграмм. В нем не нужно рисовать стрелочки и квадратики, вместо этого пишется несложный код с определением методов и объектов. Такой инструмент хорошо систематизирует мышление и заставляет думать как разработчик.

«Понимание, как все должно все работать, пришло после изучения сотен страниц текстов и десятков экранов интерфейса»

О создании решения SaaS по модели White Label рассказывает Ольга Крамарченко, проектный и продуктовый менеджер компании Winvestor. Она начинала путь в ИТ как бизнес-аналитик, а затем перешла в управление. Образование Ольга получила в «Ростовском государственном экономическом университете» на факультете «Компьютерных технологий и информационной безопасности».

Описание задачи

Наиболее интересный для меня кейс – переход от заказной разработки к продуктовой, а именно изучение финтех-рынка и работы инвестиционных и управляющих компаний. Мы делали личный кабинет для таких компаний и их клиентов.

Этапы реализации

1. Тестирование гипотезы, что такой продукт необходим рынку;
2. Разработка MVP;
3. Выход в продакшн, активные продажи и внедрение новой функциональности;
4. Фаза поддержки существующих клиентов, усовершенствование системы.

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

Все это важно для создания востребованного рынком продукта. Понимание, как именно должно все работать, пришло после изучения сотен страниц текстов и десятков экранов интерфейса. Представленные решения на рынке были индивидуальными кабинетами под конкретные цели, а мы делали универсальное решение SaaS по модели White Label.

Выводы

Мы вышли на рынок с успешным MVP. Крупные и средние компании из мира финтеха стали нашими клиентами, а команда признана лучшим разработчиком ПО по мнению профессионального сообщества в 2018 и 2019 годах. На базе этого проекта мы начали строить единую экосистему для работы со всеми инвестиционными продуктами.

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

Хочу подтянуть знания по математике, но не знаю, с чего начать. Что делать?

Если базовые концепции языка программирования можно достаточно быстро освоить самостоятельно, то с математикой могут возникнуть сложности. Чтобы помочь освоить математический инструментарий, «Библиотека программиста» совместно с преподавателями ВМК МГУ разработала курс по математике для Data Science, на котором вы:

• подготовитесь к сдаче вступительных экзаменов в Школу анализа данных Яндекса;
• углубитесь в математический анализ, линейную алгебру, комбинаторику, теорию вероятностей и математическую статистику;
• узнаете роль чисел, формул и функций в разработке алгоритмов машинного обучения.
• освоите специальную терминологию и сможете читать статьи по Data Science без постоянных обращений к поисковику.

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