Почему важно подвергать сомнению задачу?

Один из главных советов, которые я даю своим ребятам (DS'ам и не только) - ставьте под сомнение поставленную задачу!

Почему? Часто (в моей практике, процентах в 70) заказчик предлагает неоптимальное или субоптимальное решение.
С одной стороны соблазн - побыстрее пилить модельку и внедрять ее в прод, с другой стороны - "это не моя зона ответственности".
Данная точка зрения имеет право на жизнь, и большинство ее придерживается.
НО, добиться больших карьерных успехов (начиная c middle+), с таким подходом будет сложно.

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

Приведу один очень наглядный пример из моей практики.

У нас была система blockchain + mobile + ML, где исполнялись некоторые сервисные процессы по обслуживанию POS-терминалов:
1. В процессе было несколько точек контроля (прибытие инженера на склад, магазин, получение оборудования, проведение тестовой транзакции)
2. Каждая точка проверки была обмазана аналитическими правилами и ML
Проблема: система порождала большие затраты на безопасность процесса и наши бизнес-аналитики, чтобы снизить нагрузку с call-центра попросили прикрутить еще одну модельку с транскрибацией и анализом голоса.

Меня это напрягло, система становится все более сложной. И тут я решил посмотреть на процесс в целом (да, выполнить работу BA) и понял, что нафиг все эти ваши проверки и большая часть ML.
- не будем вообще тормозить инженера на этих контрольных точках - пусть делает как делает, мы только сохраним данные
- и поставим всего одну точку контроля - перед тем как выплатить ему деньги 😆
- простой логрег с выводом feature importance позволил сохранить безопасность процессов, сильно упростив систему как для инженера, так и для оператора, сократив количество звонков в Call-центр на 50%))

Как думаете, какие плюшки я получил за это?))