Меня зовут Виктор Дмитриев. Я практикующий бизнес-/системный аналитик с опытом управления командой / глубокого бизнес-анализа / запуска Web и Mobile проектов. В отрасли больше 7 лет, успел поработать в следующих компаниях:
- BCG
- Норникель
- Inframine
- KPMG
- Paybis
Месяц назад я написал на vc статью про ошибки, которые часто допускают бизнес-аналитики в своей ежедневной работе. Ошибки, которые были рассмотрены:
- Ошибка 1. Принимаем требования заказчика без уточнения его реальных потребностей
- Ошибка 2. Создали и продолжаем поддерживать систему-франкенштейн
- Ошибка 3. Забыли обработать исторические данные
- Ошибка 4. Принимаем слова руководителей за «чистую монету»
Если не читали, настоятельно рекомендую ознакомиться с прошлой статьёй для полного понимания.
Терминология
Как и в прошлой статье, хочу сразу уточнить, что под термином аналитик / бизнес-аналитик я понимаю роль универсального бизнес-/системного аналитика, который берет на себя обязанности двух этих ролей.
Таким образом, бизнес-аналитик — это роль, которая в проекте отвечает за:
- уточнение и формализацию процессов as-is и to-be
- определение потребностей и болевых точек заказчика
- формализацию и согласование бизнес, функциональных и нефункциональных требований
- описание технических требований: требований к интеграции, миграции, структуре данных
- написание и согласование ТЗ
- и т.д.
Полный список его обязанностей лучше рассмотрим в отдельной статье.
Ошибка 5. Забыли получить согласование ТЗ
Сразу уточню, что в формате взаимодействия заказчик — исполнитель (консалтинговая компания) такая ошибка маловероятна. На таких проектах почти всегда присутствует ПМ (проектный менеджер), в роад-мапе которого будет заложено время на согласование документации.
Однако, когда бизнес-аналитик работает в проектном офисе и реализует проекты для внутреннего заказчика, то часто шаг формального согласования ТЗ упускается по ряду причин:
- аналитику кажется, что всё уже обсудили «словами»;
- заказчик — мой приятель по работе, вряд ли он будет «возникать», если что-то пойдет не так;
- на таких проектах часто нет выделенного ПМ-а, а аналитики банально забывают про шаг согласования.
Ситуация: вы собрали требования и описали ТЗ к реализации новой задачи — добавление новых статусов на объект «Заказ». Вы всё подробно расписали — переходы между статусами, обработку исторических данных, возможные действия пользователя с учетом новой статусной модели. Вам кажется, что всё то, что вы обсуждали с заказчиком, отражено в ТЗ, и нет смысла еще раз отнимать время заказчика на согласование ТЗ.
Результат: вы отдаете задачу в разработку, через пару недель получаете релиз и проводите демо для заказчика. В рамках демо оказывается, что многое, что вы фиксировали на встрече по сбору требований, оказалось неправильно. Ожидания заказчика не оправдались. Даже, если представить, что заказчик — ваш коллега и приятель, маловероятно, что он захочет выводить в продакшн статусную модель, которая не соответствует его ожиданиям. Соответственно, у вас два варианта:
1. Согласиться на изменения. Но тогда вам придется опять вовлекать ресурс разработчиков и свой ресурс. При этом вам никуда не деться от согласования этих изменений с вашим руководством (ведь вовлекаются дополнительные ресурсы).
2. Отказываться от изменений. Тогда возникнет две проблемы:
— заказчик будет эскалировать на ваше руководство;
— ваши отношения с заказчиком, вероятно, испортятся.
Так или иначе, у вас появится дополнительная головная боль.
Рекомендуемый подход: всего этого можно было бы избежать, если бы вы не пропустили шаг согласования ТЗ. Поэтому у меня два совета:
1. Получайте формальное согласование ТЗ:
- идеальный путь — организовать встречу, куда пригласить заказчика, разработчиков, тестировщиков и вместе провалидировать требования:
a. вы подтвердите соответствие ожиданий заказчика описанному в ТЗ;
b. разработчики зададут уточняющие вопросы и будут понимать ценность изменений, которые они делают;
c. тестировщики зададут уточняющие вопросы и смогут подготовить тестовые сценарии. - неидеальный (но иногда приемлемый) путь — послать ТЗ по почте с указанием адекватных сроков на рассмотрение и согласование ТЗ. Если за это время комментариев не последует, то можно считать ТЗ согласованным (явно прописать это в письме).
2. Не ждите окончания сбора и формализации требований. Показывайте заказчику промежуточные версии ТЗ, чтобы понимать, что вы движетесь в правильном направлении.
Ошибка 6. Не привлекаете дизайнера на интервью заказчика
Аналогично, ошибка релевантна не всем командам, т.к. дизайнер банально есть не у всех. Однако, я часто с ней сталкивался в своей практике (и сам тоже допускал).
Ситуация: у вас есть достаточно большая задача. Добавить в мобильное приложение вашей финтех-компании новую функциональность — дать возможность вашим пользователям анализировать их расходы в виде разных диаграмм (PFM — personal financial management functionality). Вы подробно собираете все требования: спрашиваете, как должны быть расположены диаграммы, что они должны содержать, в каком цвете должны быть и т.д. После этого вы оформляете это в виде ТЗ, где подробно описываете требования к пользовательскому интерфейсу (UI) и вовлекаете дизайнера только на том этапе, когда ТЗ и требования к UI уже согласованы заказчиком.
Результат: со 100%-вероятностью дизайнер предложит другие, более интересные способы визуализации этих данных, когда ознакомится с ТЗ. Вы будете вынуждены собрать еще одну встречу, внести изменения в ТЗ и потратить свой ресурс и ресурс заказчика.
Рекомендуемый подход:
1. Я не сторонник описания подробных требований к UI аналитиками. Идеальный подход — привлекать дизайнера уже на этапе сбора требований, чтобы вы уточняли, как будет работать бизнес-логика приложения, а дизайнер определял, как будет выглядеть приложение.
Дизайнер сможет готовить небольшие макеты в Figma (или другом софте) и каждую новую встречу с заказчиком выдавать какой-то прогресс. У заказчика:
— будет больше понимания того, что проект движется;
— он сможет давать более осознанный фидбэк, чем если бы просто читал ТЗ;
— он сможет «потрогать» функционал еще без его фактической разработки за счет кликабельных макетов дизайна.
2. Если у вас нет дизайнера, то на примере этой задачи вы могли бы сделать что-то типо простого макета в Excel — сгенерировать данные (пользовательские траты), сформировать сводные таблицы, диаграммы и т.д.. Это дало бы заказчику возможность примерно представить, как будет выглядеть эта аналитика в мобильном приложении.
Ошибка 7. В процессе сбора требований вы общаетесь не с тем человеком
Ситуация: вы работаете в проектном офисе вашей компании, к вам приходит представитель отдела управления готовой продукцией (руководитель склада) и просит реализовать новый шаблон форм для формирования заказов на отгрузку (форм, по которым продукция отгружается со склада), потому что его команде не удобно работать с формами в текущем виде.
Результат: вы, ничего не подозревая, подробно уточняете у заказчика требования, описывайте их в ТЗ и даже не забываете согласовать ТЗ (см. ошибку 5). Далее, вы отдаете задачу в разработку, через пару недель получаете релиз и проводите демо для заказчика. На демо также не возникает никаких проблем. Релиз уходит в продакшн.
На следующий день к вам приходит руководитель отдела продаж. Оказывается именно его отдел занимается формированием форм на отгрузку продукции (тех форм, которые вы изменяли в этой задаче). И старый шаблон форм был не случайно таким, каким он был — он содержал всю необходимую информацию, которая нужна была логистической компании.
Команде приходится в срочном порядке возвращать старые шаблоны форм, а ваш авторитет как аналитика слегка подпорчен.
Рекомендуемый подход:
1. Всегда уточняйте роль вашего заказчика в запрашиваемой разработке. Является ли он «владельцем процесса». Эта роль не всегда определена в компаниях, но ее можно выявить, исходя из должностных обязанностей сотрудника. Нарисуйте BPMN-диаграмму, где процесс будет подробно расписан по ролям — так вы сможете потенциально увидеть некоторые упущения.
2. Если вы только пришли на проект / в компанию, уточните роль пришедшего к вам заказчика со своим руководителем, прежде чем слепо браться за описание требований.
3. Если к вам пришел сотрудник, а не руководитель отдела, уточняйте, получено ли согласование руководителя на такого рода изменения. Всегда можете сами «сходить» к руководителю и завалидировать эти требования с ним.
Ошибка 8. Не фиксируете все договоренности в заметках встреч
Актуально, скорее, для аналитиков, работающих в проектных офисах, чем в консалтинговых командах. В консалтинговых командах аналитики чаще всего более ответственно подходят к фиксации всех договоренностей (и ТЗ, и заметки встреч).
Ситуация: обсудили с заказчиком определенное изменение, например, добавление страницы формирования заказа. В рамках встречи выяснили, какие поля должны быть на этой странице, в каком порядке они должны появляться, какая валидация на эти поля и т.д. Через некоторое время всё это подробно описали в ТЗ в виде вариантов использования (use cases) и функциональных требований.
Результат: вы описали в ТЗ подробную реализацию изменений, затратив значительное количество времени. В результате, может оказаться что что-то вы просто поняли не так, как это подразумевал заказчик. Т.к. у вас нет никакого подтверждения, почему вы описали так, а не иначе, то в этой ситуации проблема переходит в область «его слово против вашего», где заказчик всегда одерживает верх. У вас не останется другого выбора, кроме как внести правки в ТЗ, а это требует вашего дополнительного ресурса.
Рекомендуемый подход:
1. Пишите небольшие заметки (meeting minutes / meeting notes / MEMO, etc.) с ключевыми итогами каждой встречи по шаблону (простой пример):
- Участники
- Темы обсуждения
- Договоренности
- Дальнейшие планы
Заметки помогут, с одной стороны, по свежим следам задокументировать и систематизировать полученные знания вам как аналитику, с другой стороны, получить формальное согласование от заказчика, что вы всё поняли правильно.
2. Делайте записи встреч (если встречи проходят онлайн). Вряд ли вы их будете часто просматривать, но это поможет вам решить проблему в конфликтных ситуациях.
Конечно, фиксации договоренностей в заметках встреч не гарантирует того, что вам не придется вносить изменения в ТЗ, но однозначно митигирует этот риск.
Что будет дальше?
Потенциальные темы для обсуждения:
- Прохождение собеседования на позицию аналитика
- Курсы для прокачки скиллов аналитика
- Hard и sofl скиллы аналитика
- Опыт прохождения Go Practice Simulator
- Как собирать и описывать требования
- Методологии моделирования бизнес-процессов
- Структуры вопросов для интервьюирования заказчика
- Зарплаты аналитиков
- Опыт работы аналитиком в Европе
и многое другое.
Постараюсь выпустить следующую статью раньше, чем через месяц:)
Источник: vc.ru
Бизнес аналитик примеры решения задачи
«Такое решение не имело аналогов на рынке»
Алексей Лобзов – главный системный аналитик АО «Альфа-Банк» и выпускник университета «МИФИ» по специальности «Прикладная информатика» (в области международного сотрудничества). Алексей рассказал корреспонденту Proglib о системе управления портфелями проектов, разработанной специализирующейся на вопросах проектного управления консалтинговой компанией .
Описание задачи
Наша команда внедряла систему управления портфелями проектов в ИТ-департаменте отечественной нефтяной компании. Заказчик предоставил описание процесса, в том числе методики ранжирования и выравнивания проектов относительно заданных ограничений. Ранее эти операции выполнялись с использованием нетривиальной модели, реализованной в файле Excel. Задача состояла в автоматизации процессов, причем решение должно было быть интуитивно понятным и удобным в использовании.
Этапы реализации
Разработка решения по ранжированию не составила труда. У нас уже была методика, определяющая перечень влияющих на ранг характеристик проектов. Были и содержащие значения этих характеристик карточки проектов. Имея исходные данные и формулу вычисления ранга, мы разработали функциональность ранжирования проектов портфеля. Решение было полностью самописным.
Наиболее интересна задача выравнивания проектов относительно заданных ограничений:
- количества стартов проектов в промежуток времени;
- объема платежей за единицу времени;
- количества доступных специалистов.
Мы точно знали, что Microsoft Project (на тот момент версии 2013 года) имеет близкую к нашей задаче функцию распределения доступных ресурсов и трудовых затрат. Внедряемая система включала модуль календарного планирования на базе Microsoft Project Server , поэтому мы решили построить решение на движке Microsoft.
- Совместно с архитектором мы разработали сводную модель план-графиков проектов портфеля. В нее включались наиболее приоритетные проекты, попадающие в выделенный на исполнение лимит денежных средств;
- Затем провели тестирование и отладку модели, выставляя ограничения на даты стартов проектов, назначая затраты и трудовые ресурсы, устанавливая лимиты и выполняя выравнивание средствами Microsoft Project.
Отлаженная модель решала задачи выравнивания, но требовала высокой квалификации от пользователя, поскольку включала множество связанных элементов и была чувствительна к вводу данных.
Следующим шагом было проведено проектирование и реализация приложения с максимально понятным интерфейсом, защищающим пользователя от ошибок ввода. Приложение запускало Microsoft Project и собирало в нем модель из данных по наиболее приоритетным проектам портфеля. Оно отображало перечень проектов и их характеристик, а также ограничений, на которые мог повлиять пользователь:
- скорректировать даты стартов и установить лимит на количество проектов, стартующих в заданный промежуток времени;
- распределить доступные денежные средства по проектам с учетом ограничений на объем платежей в единицу времени;
- распределить трудовые ресурсы, учитывая их доступность.
Такое решение по ранжированию и выравниванию проектов на тот момент не имело аналогов на рынке.
Выводы
Это внедрение было для меня ценным по нескольким причинам:
- Я глубоко погрузился в процессы управления портфелями проектов и получил уникальный опыт их автоматизации. На своей практике не вспомню столь масштабных задач в данной области;
- Удалось подтвердить важность анализа возможностей переиспользования существующих решений. Кто знает, сколько времени и ресурсов мы бы потратили на разработку аналогичного Microsoft Project движка;
- Участие в подобных проектах побуждает делиться знаниями с окружающими.
По результатам внедрения было написано несколько статей:
- Лобзов А.В. На что обратить внимание при балансировке портфеля и выборе проектов // Управление проектами и программами. — 2016. — No2. — С.138–143
- Лобзов А.В. Балансировка портфелей и выбор проектов при наличии альтернативных вариантов достижения стратегических целей .
Превратили платформу интерактивного телевидения «Ростелекома» в современный сервис 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 . Она начинала путь в ИТ как бизнес-аналитик, а затем перешла в управление. Образование Ольга получила в « Ростовском государственном экономическом университете » на факультете « Компьютерных технологий и информационной безопасности » .
Описание задачи
Наиболее интересный для меня кейс – переход от заказной разработки к продуктовой, а именно изучение финтех-рынка и работы инвестиционных и управляющих компаний. Мы делали личный кабинет для таких компаний и их клиентов.
Этапы реализации
- Тестирование гипотезы, что такой продукт необходим рынку;
- Разработка MVP ;
- Выход в продакшн, активные продажи и внедрение новой функциональности;
- Фаза поддержки существующих клиентов, усовершенствование системы.
Пришлось зарегистрироваться на всех релевантных сервисах: так у меня появилось около восьми брокерских счетов. Я тренировала насмотренность, изучала направления UX и проводила интервью с потенциальными клиентами.
Все это важно для создания востребованного рынком продукта. Понимание, как именно должно все работать, пришло после изучения сотен страниц текстов и десятков экранов интерфейса. Представленные решения на рынке были индивидуальными кабинетами под конкретные цели, а мы делали универсальное решение SaaS по модели White Label.
Выводы
Мы вышли на рынок с успешным MVP. Крупные и средние компании из мира финтеха стали нашими клиентами, а команда признана лучшим разработчиком ПО по мнению профессионального сообщества в 2018 и 2019 годах. На базе этого проекта мы начали строить единую экосистему для работы со всеми инвестиционными продуктами.
Для успешности любого проекта нужна глубокая экспертиза. Недостаточно иметь навыки создания схем бизнес-процессов, прототипных макетов или написания ТЗ. Вы должны представлять, как это работает и почему: изучить всю законодательную базу, практики конкурентов, отличать правильный пользовательский опыт от не очень правильного. Придется пообщаться с конкретными пользователями или найти тех, кто работает в похожем решении, чтобы собрать информацию о паттернах поведения.
Хочу подтянуть знания по математике, но не знаю, с чего начать. Что делать?
Если базовые концепции языка программирования можно достаточно быстро освоить самостоятельно, то с математикой могут возникнуть сложности. Чтобы помочь освоить математический инструментарий, «Библиотека программиста» совместно с преподавателями ВМК МГУ разработала курс по математике для Data Science, на котором вы:
- подготовитесь к сдаче вступительных экзаменов в Школу анализа данных Яндекса;
- углубитесь в математический анализ, линейную алгебру, комбинаторику, теорию вероятностей и математическую статистику;
- узнаете роль чисел, формул и функций в разработке алгоритмов машинного обучения.
- освоите специальную терминологию и сможете читать статьи по Data Science без постоянных обращений к поисковику.
Курс подойдет как начинающим специалистам, так и действующим программистам и аналитикам, которые хотят повысить свой уровень или перейти в новую область.
Источник: proglib.io