Техническое решение и политические игры

Казалось бы, довольно понятная тема. Кажется, что процесс поиска технического решения довольно прямолинеен в теории

Возьмем “простой пример” - Представим что вы только пришли в компанию и вам поставлена задача поиска “плохих клиентов” aka fraud customers. Предположим, что наша абстрактная компания работает уже долго в индустрии и данных достаточно. Бизнес хочет, как обычно, чтобы это было как можно быстрее, чтобы “плохие клиенты” не успели совершить действий, которые приведут к потере денег

Как первая версия можно рассмотреть следующее решение, которое состоит из трех пунктов
---
1. В момент регистрации клиента происходит кросс чекинг по мейлу / телефону / другим признакам, и в случае нахождения совпадения осуществляется бан / ограничение функциональности / отправка на KYC / другой вариант
2. При осуществлении каких-нибудь платежей, если обнаружена совпадение по платежной информации с одним из “плохих клиентов” осуществляется отправка на доп. Проверку / бан / …
3. В целом, разрабатывается ML Fraud Detection Model (куда уж без этого в 2023!) для обнаружения “плохих клиентов”
---

А теперь представьте вы работаете в большой компании, например в отделе аналитики (со своими data / analytics инженерами конечно!), и вам была поставлена задача (ну или ваш менеджер оценил это так) выкатить все это в течении месяца.

Кажется, идеальная задача под стриминг для пункта 1 и 2, и возможно даже 3. Вы радостно разрабатываете архитектуру решения и предлагаете его внутри команды.

Но тут менеджер вашего департамента сообщает, что у вас нет доступа к streaming части инфраструктуры (в крайнем случае, даже к файлам сырого слоя) по соображениям безопасности / структуры / …

Рассмотрим, что можно сделать
---
1. Подключить команду, занимающуюся streaming инфраструктурой и совместно разработать проект
2. Сделать микробатч решение на вашей собственной инфраструктуре
3. Подключить команду backend разработки и сделать решение через синхронную / асинхронную передачу данных с разработкой сервиса на своей стороне
4. Сказать, что у вас такой возможности нет и передать задачу в другой отдел
5. ..
---

У каждого из этих решений есть вероятность применения в зависимости от взаимотношений и политических решений как внутри отдела, так и в целом, в компании.

Например, вариант 2 может быть достижим в случае, если вам нужна полная изолированность от других отделов (или политическое влияние обладанием этого проекта), а переговоры о предоставлении доступа с другими отделами. закончились неудачно. При этом вам нужно еще “продать” решение бизнесу, почему нужно выбрать именно это решение.

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

Есть люди, для которых такая “несвобода” при принятии решений может быть красным флагом, и если у вас такая ситуация в отделе/департаменте, чтобы не возникло неприятных расставаний в течении работы, есть смысл устраивать role play таких ситуация на сис дизайн/behaioral интервью, если у вас есть такие практики

P.S. Пример выдуманный, все совпадения случайны и не имеют отношения к моей рабочей деятельности за последние  X лет