Некоторое время назад я решила получить дополнительное образование к уже имеющемуся и немного исчерпавшему себя магистру по Системной инженерии. Для поступления в выбранную школу мне надо было подготовить несколько эссе. Размышляя над ними я сильно превысила требуемые 400 слов, и чтоб добро не пропадало, решила их подправить и вывесить сюда.
Темы для эссе связаны с моей работой, поэтому далее я разберу некоторые аспекты бизнес анализа. Надеюсь, кому-нибудь будет интересно.
По своему опыту могу сказать, что программисты и прочие разработчики програмного обеспечения не всегда понимают зачем нужен аналитик на проекте. Некоторые знакомые инженеры мне часто говорят, что всё могут делать сами, и им вовсе не нужет кто-то, толком не разбирающийся в программировании кто будет им указывать что и как должно работать.
В этой статье я бы хотела рассказать, чем должен заниматься «правильный аналитик». Типа меня, ага.
Для начала, я пожалуй, соглашусь, что аналитик нужен не всегда. Если вы делаете небольшой проект в области где вы хорошо разбираетесь, или если у вас небольшая команда и некий «эксперт» всегда под рукой, то, наверно, вы можете обойтись без нашей помощи.
В других случаях — например, если вы переделываете некую крупную систему, или строите что-то новое в области где вы не совсем эксперт, помощь аналитика необходима.
Ещё добавлю, что аналитики нередко бывают и в правду бестолковыми. Мне встречались случаи, когда аналитик пишет груду никому ненужной документации, тратя на это время, и отвлекая полезных сотрудников от написания кода. Или, когда аналитик вместо требований описывает _как_ оно должно работать — что в принципе является очень частой ошибкой и отдельной темой для статьи.
Несколько лет назад я писала о роли аналитика в Agile проекте. Сейчас я работаю на немного менее Agile, но более финансовом проекте — в одной из крупнейших компаний, торгующих нефтью и её производными, а так же металлами и другими инструментами.
Компания на рынке уже более 20 лет, и со дня основания невероятно выросла. Как нередко в таких компаниях, тут развелось куча системок для разных функций — как система записи трейдов, система рисков, бухгалтерские системы, системы отчёта. В компании как минимум 2 системы для каждой функции, а в некоторых случаях и 8-12 систем. Часто системы склеены между собой какими-то экселями в общих папках, какими-то эксель-макрами и скриптами, какие-то stored procedures вызываются какими-то самопальными программулинами.
Меня попросили переделать систему для управления позицией и риском для торгующих производными финансовыми инструментами — фьючерсами, свопами, опционами и далее по списку.
Ниже я расписала разные типы деятельности которые я веду для этого проекта.
Как я описала выше, в компании существует более одной системы для каждой функции. Некоторые их этих систем поддреживаются IT, поэтому их сравнительно легко идентифицировать, разобрать на компоненты и переделать. Основную проблему для меня являет эксель, и самопальные компоненты и всяческие макро, которые используют трейдеры и риски.
В результате почти каждого контакта с пользователем оказывается, что официальные системы не достаточно хороши для какой-то функции — то отчёт в неправильном формате, то не те единицы измерения, то вообще, используется неправильная модель или трейд совсем не поддерживается. Каждая такая беда разрешается в зависимости от технической подкованности данного пользователя или наличия человека, которому трейдер может навешать её разрешение. Чаще всего решением проблемы бывает несколько хлипко склееных между собой экселей, иногда ещё какая-то локальная библиотечка или база данных…
Переделывая систему рисков, один из вопросов это "должна ли новая система заменить вот этот эксель?". Согласитесь — вопрос непростой. С одной стороны, если это — недочёт существующей системы — новая его должна учесть и исправить. С другой стороны, трейдеры обожают эксель и никогда с него не слезут.
Есть и другая часть вопроса определения задачи. Вот есть система Х и она, кроме всего прочего, умеет конвертировать пси-лямбду в омега-ро. Вроде и полезная трансформация, но не работает для всех инструментов, и не ясно, кто этим пользуется. Никто не признаётся, а задача непростая и было б дешевле добавить эту фичу сейчас а не через полгода.
Моя задача тут — начертить границу системы и добиться того, чтоб все участники процесса согласились с этой линией — от программиста до Риск Офицера.
Ничего удивительного — кто-то должен понимать бизнес юзеров. Честно говоря, у нас и программисты не лыком шиты, но достаточно сильно заняты чтоб разбираться с трейдерскими процессами и экселями.
Помню, в самом начале один трейдер мне сказал «У меня длинная гамма на задней ноге этого спреда». Ага, и ещё дата экспирации между ног.
Моя задача тут — понять, что мне говорят трейдеры и прочие бизнес пользователи, и перевести их требования на язык, понятные инженерам. И обратно.
Следующий пунктик — приоритизация. Конечно, инженер-программист часто сам знает, с чего начать — ну, например, с самого сложного, или может, самого рискованого, или от того, на чём будет строится остальная система. Тут я советовать не буду — тем более, когда не спрашивают.
Но с точки зрения бизнеса тоже есть приоритеты. И как ни странно, они нередко загадочны и непонятны.
Компания, где я работаю, разбросана по всему миру. В каждом регионе есть некие особенности — торгуемые продукты, процессы, уровень отчётности и регуляции. Соответственно, разбитие поставки на фазы весьма логично и предпочтительно.
Передо мной постоянно стоит вопрос - кто первый? Нам сначала разработать опционы для угля, или добавить поддержку Форекса? А может, стоит заняться отсылкой отчётов для директоров?
Для решения этого вопроса есть много техник — например, посмотреть, где самый большой риск. Кто может потерять больше денег за единицу времени — трейдер угля или форекса? Или, можно посмотреть с другой стороны — если поддержку угля мы можем забацать за 2 недели, а форекса за 8 — что стоит сделать быстрее?
Часть моей работы — предоставить некоторые цифры на примере тех начальству, чтоб они решили, что им кажется лучше. Нередко кроме цифр нужно предоставить некое пояснение — например, чем отличается один процесс от другого, или один тип трейда от другого — так, чтобы начальство, далёкое от таких деталей могло сделать выводы. А иногда вообще стоит много подумать — как бы сделать поменьше чтоб толку побольше, а потом доделать немножко чтоб вообще хорошо. Согласитесь, вряд ли программист захочет заниматься такой фигнёй!
Это достаточно интересный пункт. Изменения в системе нередко затрагивают изменения процессов. Иногда изменение процесса достаточно простое, процесс можно изменить во время обучения системе. Однако, нередко изменения процессов затрагивают многие департаменты, в разных географических местах и временных зонах.
В таких случаях необходимо для начала рассмотреть существующие процессы, подвергнув всех участников расспросам с пристрастием, и иногда, пытками. После этого следует документировать существующие процессы и подтвердить, что понимание процессов достаточно корректно. Позже, нужно разработать новые процессы и согласовать их со всеми затронутыми сторонами, убедиться что ничего не пропущено, что все затронутые системы имеют необходимые интерфейсы, а все участники процесса — достаточно извилин чтоб ими воспользоваться. После этого, подготовить необходимую документацию и презентации, и в конце концов, обучить всех участников.
Думаю, и тут согласитесь, что ни программисты, ни руководители проектов не захотят заниматься такой тягомотиной.
Здесь я не буду углубляться — все знакомы со спецификациями, юс кейсами, историями и прочими артефактами.
Последнее, но немаловажное — ввод системы в продакшн.
Для начала, приходится демонстрировать её пользователям. В нашей компании — это трудоёмкое дело, и занимает много времени. Дело в том, что мои бизнес пользователи — занятые люди, живущие в разных уголках мира, поэтому демонстрации обычно проходят один-на-один, подогнанные для этого конкретного пользователя. Я даже не пытаюсь посчитать свои человеко-месяцы, потраченные на это…
Далее — обучение. К сожалению, этой функцей не может заниматься специально обученая девушка — потому что трейдеры задают каверзные вопросы по своим дельтам и гаммам, и нередко оправляют продукт на доработку. А ещё у них свои спредшиты, которые в процессе обучения надо лёгким движением руки превратить... в шорты
Самое сложное — это наверно UAT (user acceptance testing). Это когда надо перевести занятого трейдера с насиженной системы (спредшита или другой) на новую и блестящую. И она колется, не поддаётся, и не сходится, а аналитик пытается разобраться, почему раньше всё работало, а сейчас, когда он нажимает — нет! Тут дельта — 5,2 а там — 5,7 — и в условиях стресса под постоянные матюки пытаешься выяснить — сколько же надо?
А потом в итоге надо ему подготовить и подсунуть бумажку с перечнем тест-сценариев где трейдер должен подписать «Видел, работает» — над каждым пунктом. Веселуха, в общем.
Кто на аналитика?
Темы для эссе связаны с моей работой, поэтому далее я разберу некоторые аспекты бизнес анализа. Надеюсь, кому-нибудь будет интересно.
По своему опыту могу сказать, что программисты и прочие разработчики програмного обеспечения не всегда понимают зачем нужен аналитик на проекте. Некоторые знакомые инженеры мне часто говорят, что всё могут делать сами, и им вовсе не нужет кто-то, толком не разбирающийся в программировании кто будет им указывать что и как должно работать.
В этой статье я бы хотела рассказать, чем должен заниматься «правильный аналитик». Типа меня, ага.
Для начала, я пожалуй, соглашусь, что аналитик нужен не всегда. Если вы делаете небольшой проект в области где вы хорошо разбираетесь, или если у вас небольшая команда и некий «эксперт» всегда под рукой, то, наверно, вы можете обойтись без нашей помощи.
В других случаях — например, если вы переделываете некую крупную систему, или строите что-то новое в области где вы не совсем эксперт, помощь аналитика необходима.
Ещё добавлю, что аналитики нередко бывают и в правду бестолковыми. Мне встречались случаи, когда аналитик пишет груду никому ненужной документации, тратя на это время, и отвлекая полезных сотрудников от написания кода. Или, когда аналитик вместо требований описывает _как_ оно должно работать — что в принципе является очень частой ошибкой и отдельной темой для статьи.
Несколько лет назад я писала о роли аналитика в Agile проекте. Сейчас я работаю на немного менее Agile, но более финансовом проекте — в одной из крупнейших компаний, торгующих нефтью и её производными, а так же металлами и другими инструментами.
Компания на рынке уже более 20 лет, и со дня основания невероятно выросла. Как нередко в таких компаниях, тут развелось куча системок для разных функций — как система записи трейдов, система рисков, бухгалтерские системы, системы отчёта. В компании как минимум 2 системы для каждой функции, а в некоторых случаях и 8-12 систем. Часто системы склеены между собой какими-то экселями в общих папках, какими-то эксель-макрами и скриптами, какие-то stored procedures вызываются какими-то самопальными программулинами.
Меня попросили переделать систему для управления позицией и риском для торгующих производными финансовыми инструментами — фьючерсами, свопами, опционами и далее по списку.
Ниже я расписала разные типы деятельности которые я веду для этого проекта.
* Определить scope
Как я описала выше, в компании существует более одной системы для каждой функции. Некоторые их этих систем поддреживаются IT, поэтому их сравнительно легко идентифицировать, разобрать на компоненты и переделать. Основную проблему для меня являет эксель, и самопальные компоненты и всяческие макро, которые используют трейдеры и риски.
В результате почти каждого контакта с пользователем оказывается, что официальные системы не достаточно хороши для какой-то функции — то отчёт в неправильном формате, то не те единицы измерения, то вообще, используется неправильная модель или трейд совсем не поддерживается. Каждая такая беда разрешается в зависимости от технической подкованности данного пользователя или наличия человека, которому трейдер может навешать её разрешение. Чаще всего решением проблемы бывает несколько хлипко склееных между собой экселей, иногда ещё какая-то локальная библиотечка или база данных…
Переделывая систему рисков, один из вопросов это "должна ли новая система заменить вот этот эксель?". Согласитесь — вопрос непростой. С одной стороны, если это — недочёт существующей системы — новая его должна учесть и исправить. С другой стороны, трейдеры обожают эксель и никогда с него не слезут.
Есть и другая часть вопроса определения задачи. Вот есть система Х и она, кроме всего прочего, умеет конвертировать пси-лямбду в омега-ро. Вроде и полезная трансформация, но не работает для всех инструментов, и не ясно, кто этим пользуется. Никто не признаётся, а задача непростая и было б дешевле добавить эту фичу сейчас а не через полгода.
Моя задача тут — начертить границу системы и добиться того, чтоб все участники процесса согласились с этой линией — от программиста до Риск Офицера.
* Понимать трейдеров
Ничего удивительного — кто-то должен понимать бизнес юзеров. Честно говоря, у нас и программисты не лыком шиты, но достаточно сильно заняты чтоб разбираться с трейдерскими процессами и экселями.
Помню, в самом начале один трейдер мне сказал «У меня длинная гамма на задней ноге этого спреда». Ага, и ещё дата экспирации между ног.
Моя задача тут — понять, что мне говорят трейдеры и прочие бизнес пользователи, и перевести их требования на язык, понятные инженерам. И обратно.
* Приоритизировать
Следующий пунктик — приоритизация. Конечно, инженер-программист часто сам знает, с чего начать — ну, например, с самого сложного, или может, самого рискованого, или от того, на чём будет строится остальная система. Тут я советовать не буду — тем более, когда не спрашивают.
Но с точки зрения бизнеса тоже есть приоритеты. И как ни странно, они нередко загадочны и непонятны.
Компания, где я работаю, разбросана по всему миру. В каждом регионе есть некие особенности — торгуемые продукты, процессы, уровень отчётности и регуляции. Соответственно, разбитие поставки на фазы весьма логично и предпочтительно.
Передо мной постоянно стоит вопрос - кто первый? Нам сначала разработать опционы для угля, или добавить поддержку Форекса? А может, стоит заняться отсылкой отчётов для директоров?
Для решения этого вопроса есть много техник — например, посмотреть, где самый большой риск. Кто может потерять больше денег за единицу времени — трейдер угля или форекса? Или, можно посмотреть с другой стороны — если поддержку угля мы можем забацать за 2 недели, а форекса за 8 — что стоит сделать быстрее?
Часть моей работы — предоставить некоторые цифры на примере тех начальству, чтоб они решили, что им кажется лучше. Нередко кроме цифр нужно предоставить некое пояснение — например, чем отличается один процесс от другого, или один тип трейда от другого — так, чтобы начальство, далёкое от таких деталей могло сделать выводы. А иногда вообще стоит много подумать — как бы сделать поменьше чтоб толку побольше, а потом доделать немножко чтоб вообще хорошо. Согласитесь, вряд ли программист захочет заниматься такой фигнёй!
* Организовывать процессы чтоб «всё работало»
Это достаточно интересный пункт. Изменения в системе нередко затрагивают изменения процессов. Иногда изменение процесса достаточно простое, процесс можно изменить во время обучения системе. Однако, нередко изменения процессов затрагивают многие департаменты, в разных географических местах и временных зонах.
В таких случаях необходимо для начала рассмотреть существующие процессы, подвергнув всех участников расспросам с пристрастием
Думаю, и тут согласитесь, что ни программисты, ни руководители проектов не захотят заниматься такой тягомотиной.
* Создавать артефакты для инженеров
Здесь я не буду углубляться — все знакомы со спецификациями, юс кейсами, историями и прочими артефактами.
* Демонстрации, обучение и UAT
Последнее, но немаловажное — ввод системы в продакшн.
Для начала, приходится демонстрировать её пользователям. В нашей компании — это трудоёмкое дело, и занимает много времени. Дело в том, что мои бизнес пользователи — занятые люди, живущие в разных уголках мира, поэтому демонстрации обычно проходят один-на-один, подогнанные для этого конкретного пользователя. Я даже не пытаюсь посчитать свои человеко-месяцы, потраченные на это…
Далее — обучение. К сожалению, этой функцей не может заниматься специально обученая девушка — потому что трейдеры задают каверзные вопросы по своим дельтам и гаммам, и нередко оправляют продукт на доработку. А ещё у них свои спредшиты, которые в процессе обучения надо лёгким движением руки превратить...
Самое сложное — это наверно UAT (user acceptance testing). Это когда надо перевести занятого трейдера с насиженной системы (спредшита или другой) на новую и блестящую. И она колется, не поддаётся, и не сходится, а аналитик пытается разобраться, почему раньше всё работало, а сейчас, когда он нажимает — нет! Тут дельта — 5,2 а там — 5,7 — и в условиях стресса под постоянные матюки пытаешься выяснить — сколько же надо?
А потом в итоге надо ему подготовить и подсунуть бумажку с перечнем тест-сценариев где трейдер должен подписать «Видел, работает» — над каждым пунктом. Веселуха, в общем.
Кто на аналитика?
