Share This
Связаться со мной
Крути в низ
Categories
//Четыре примера работы аналитиков: кейсы IT-компаний

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

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

chetyre primera raboty analitikov kejsy it kompanij ef462b4 - Четыре примера работы аналитиков: кейсы IT-компаний

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

chetyre primera raboty analitikov kejsy it kompanij 828e57d - Четыре примера работы аналитиков: кейсы IT-компаний

Иллюстрация с сайта pixabay.com

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

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

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

Наша команда внедряла систему управления портфелями проектов в ИТ-департаменте отечественной нефтяной компании. Заказчик предоставил описание процесса, в том числе методики ранжирования и выравнивания проектов относительно заданных ограничений. Ранее эти операции выполнялись с использованием нетривиальной модели, реализованной в файле 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. Лобзов А.В. Балансировка портфелей и выбор проектов при наличии альтернативных вариантов достижения стратегических целей.

chetyre primera raboty analitikov kejsy it kompanij f37280d - Четыре примера работы аналитиков: кейсы IT-компаний

Иллюстрация с сайта pixabay.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

chetyre primera raboty analitikov kejsy it kompanij b8ba917 - Четыре примера работы аналитиков: кейсы IT-компаний

Иллюстрация с сайта pixabay.com

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

chetyre primera raboty analitikov kejsy it kompanij ec5c3fb - Четыре примера работы аналитиков: кейсы IT-компаний

Иллюстрация с сайта pixabay.com

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

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

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

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

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

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

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

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

Выводы

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

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

***

Аналитикам приходится решать нетривиальные рабочие задачи и вырабатывать соответствующие навыки. Если вы только задумываетесь о карьере в этой отрасли, мы рекомендуем пройти обучение на факультете Системной и бизнес-аналитики в GeekBrains. Занятия ведут опытные преподаватели, а студенты за время обучения выполняют четыре проекта. Личный куратор помогает им быстро разобраться задачами, на решение которых в ином случае ушли бы недели. Успешно окончившие курс студенты получают диплом о профессиональной подготовке и помощь в трудоустройстве: год обучения в онлайн-академии эквивалентен году реальной работы.

Интересно, хочу попробовать!

  • 7 views
  • 0 Comment

Leave a Reply

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Связаться со мной
Close