Выберите собственную роль, назовите её. Кратко опишите её. Кто я? В чем моя задача в этой роли? Например: я — специалист по контекстной рекламе, привожу лиды.
Оооооо... тут меня настигла одна мысль.... ))
— Отступление —
Моя текущая должность - Product Manager. Продукт - Know Your Customer - в трейдинговой компании (CFD брокер).
Когда я начал проходить R1 Распожаризацию (и учитывая, что в 2021 я проходил практикум по системному мышлению), то я довольно легко выделил что команда разработки - это система создания продукта. Про продукт и про команду нужно думать очень по разному. С тимлидом мы еще более явно разграничили что он - операционный менеджер команды разработки, я - менеджер продукта
— Конец отступления ----
Теперь приступим к выполнению этого упражнения.
Выделение роли: попытка 1.
Моя роль… ну давайте назовем ее пока что Product Manager без уточнения должность это или роль. Если роль - Product Manager, то домен… Product Management!! Никакой не KYC!
Нет, ну конечно же, я точно не говорю о том, что:
- Домен KYC не интересует меня
- Что я не знал раньше о существовании дисциплины Product Management (знал, книги читал, и так далее)
Однако во всех своих недавних выделениях ролей и методов работ, именно о методах управления продуктом - я не задумывался вовсе!
Какой практический вывод из этих рассуждений?
Как минимум - что когда я буду продолжать пытаться описывать свой KYC домен (один из моих запросов на это обучение - приобрести навык и построить модель нашего домена - KYC), я должен вставать в роль не продакт менеджера, а… Compliance Officer / KYC Analyst … (тут еще нужно подумать).
Как максимум - что о домене продакт менеджмента мне тоже стоит подзадуматься… какие там ключевые объекты… практики… (звучит как будто бы практики продакт менеджмента для меня стали открытием, но, вроде бы нет, хотя все что я делал до этого – скорее было сделано по наитию, без явного или с полу явным выделением объектов из фона).
Пока что я больше сфокусирован на домене KYС.
Назовите и опишите в целом ту предметную область, которую видит эта роль.
Как это вообще работает? Например: при посещении сайтов-партнеров пользователь видит креативы, которые я утверждаю, кликает на них и попадает на сайт моей фирмы
Выделение роли: попытка 2.
Давайте я все таки встану в роль связанную с KYC доменом, допустим, Compliance Officer
— Простыня текста о поиске моей роли —
Загляну в следующее задание чтобы знать, куда меня дальше поведет текущая дорога размышлений.
- Представить мои функции…
- Расписать свою типичную задачу…
Да нет, ну никакой я не Compliance Officer. Compliance officer делает следующее:
A Compliance Officer is a vital corporate professional responsible for ensuring a company adheres to all legal standards, regulatory requirements, and internal policies. They mitigate risks of non-compliance, such as fines and reputational damage, by implementing policies, monitoring operations, training staff, and maintaining compliance documentation
Никакой я не KYC Analyst или AML Investigator (я не анализирую триггеры, не провожу расследований, не работаю с документами, которые предоставляют клиенты). Я строю продукт!
У меня (1) есть знания о “бизнес” домене – KYC – то есть я могу выделить из фона объекты, важные именно для предметной области KYC, (2) есть навыки описания требований к системам, интервьюирования стейкохлдеров, проектирования софта - функции, базы данных, составления описания алгоритмов и так далее, (3) управления работами по разработке софта.
И вот этот вот перечисленное в п.2 и 3 я должен применять так, чтобы софт выполнял работу по методам из п.1. Ну а точнее - я организую работу людей в моих командах под это дело (или все таки тим лид организует? Ну как-то мы оба.)
Результат моей работы будет оцениваться исходя из того, смог ли мой продукт (система) выполнить работу по методам, специфичным к KYC домену.
Чем тогда я отличаюсь от менеджера операционной команды, в которой вся работа выполняется биологическими агентами? Да ничем. (эта мысль и ранее мне проходила в голову)
Раньше как было - департамент/команда и ее руководитель. Департамент (сотрудники в нем) выполнял работу по методу Х.
Сейчас как: возможная степень автоматизации - крайне высока, люди нужны все меньше и меньше. Но нужен кто-то, кто организует работу машин по ЭТОМУ ЖЕ (как минимум - аналогичному) методу. Вот тебе и продакт менеджер. И важное отличие здесь - менеджер внутреннего продукта. Я не управляю продуктом, который пересекает границу нашего предприятия и исполняет работу в других предприятиях (т.е. продается им).
По сути я строитель проектировщик + прораб (? :D) систем автоматизированного исполнения KYC и AML политик. О как!
Выделение роли: попытка 3.
Хорошо, тогда выделим на сейчас роль - проектировщик … это что - архитектор? Но я не принимаю решения о внутреннем устройстве системы (окей, иногда принимаю). Но совершенно точно я принимаю решения о функциональном наполнениии продукта. Тогда я - функциональный архитектор?
Выделение роли: попытка 4.
Окей, то есть я - функциональный архитектор автоматизированного исполнения KYC и AML политик.
Это очень сильно мне откликается. То есть я продумываю, какими функциями должен обладать продукт, чтобы обеспечивать выполнение работ по методам в соответствии с KYC и AML политиками.
Конечно, это не единственная моя роль.
Я и работами управляю (строю планы работы), и за производительностью продукта слежу (отслеживаю метрики), и отчетность сам строю и много чего еще.
Но определением требуемой функциональностью продукта - я занимаюсь прям очень много.
— Конец простыни текста о поиске моей роли —
Теперь вернемся к заданию - “Как это вообще работает?”.
У продукта есть стейкхолдеры, ключевые:
- Compliance
- операционные команды, работающие с продуктом
Стейкхолдеры приносят свои потребности. Допустим, нужно со всех клиентов теперь дополнительно запрашивать документ Х и верифицировать его. По сути они приносят новый метод и работ и мне нужно создать софт, который либо полностью, либо частично автоматизирует исполнение работ по этому методу. Я разбиваю новый метод на составляющие: (1) запрос документа у клиента, (2) OCR документа, (3) авто-валидация документа, (4) передача документа на ручную верификацию, (5) возврат запроса на документ клиенту и так далее.
Далее для каждой части я определяю, можем ли мы использовать существующий функционал продукта или требуется создавать новый. Но при переиспользовании функционала все равно потребуется организовать исполнение работ (вызов функций) в надлежащей последовательность (собрать workflow).
Далее идет большая часть по разработке софта и передаче в экплуатацию.
Это все выше - про design time.
И теперь наступает run time созданной системы.
Клиенты компании (трейдеры) выполняют привичные для себя действия. Одна из систем отслеживает их поведение и при необходимости - запускает работы по новому методу. То есть запрашивает документ у клиента, уведомляет его и так далее в соответстии с методом.
Ну вот примерно так и работает домен KYC в run time, и домен Product Management в run time (который ?обеспечивает? design time домену KYC).