От кода, до укрощения хаоса: как быть инженером -программистом, сделало меня лучшим оператором
programming product-management software-development product-development data-engineering engineering-management bizops north-star-metrics objective-functions

От кода, до укрощения хаоса: как быть инженером -программистом, сделало меня лучшим оператором

8 августа 2025 г.

Большинство инженеров -программистов, которые хотят приблизиться к «бизнес -стороне» технологий, в конечном итоге становятся менеджерами по продуктам. Это естественный путь, который позволяет вам оставаться близко к техническим проблемам, больше связаться со стратегией и все еще говорить на языке инженеров. В конце концов я тоже пошел этот путь. Но до того, как я это сделал, в 2021 году у меня была редкая возможность присоединиться к недавно сформированной команде Bizops в Headway - не как премьер -министр, а в качестве основателя того, что было представлено в качестве команды спецназа для самых сложных проблем компании. Это была не ваша средняя роль в бизнес -операциях. Он был смоделирован после того, как внутренняя команда в Палантире (откуда взялась некоторые из нас в Headway) - группе лоскутных универсалов, которые глубоко встраивали в критические инициативы, быстро построили контекст и перемещали горы, чтобы открыть рост. Оказывается, мое время в качестве инженера -программиста, особенно в ML, подготовила меня гораздо больше для этого хаоса, чем я ожидал. И чем больше времени я потратил на Bizops, тем больше я понял, насколько эти две дисциплины могут (и должны) учиться друг у друга. Вот два урока, которые выделялись.

Определение метрик North Star очень похоже на настройку объективных функций

Будучи форвардным инженером в Palantir, а затем и инженером по программному обеспечению в Arena AI, одной из областей, на которых я потратил время, была ML Engineering. Как знает любой ML ENG, хороший объем работы входит в функции тонкой настройки, чтобы оптимизировать для конкретного вывода модели. Выяснение правильного баланса входных переменных и добавление в противоположных, быстро стало одной из самых трудоемких частей работы. Настройка потери функции немного немного и в конечном итоге оптимизируется для совершенно другого поведения.

Решение эксплуатационных проблем часто работает одинаково - особенно при разработке систем стимулирования и отслеживании успеха. Например, в Headway мы работаем с тысячами поставщиков психического здоровья по всей стране. В начале мы измерили нашу команду по продажам по количеству подписанных провайдеров. Но это не обязательно переводится на активацию поставщиков, учитывая, что многие подписали, но никогда не видели пациентов. Когда мы перенесли наш северную звездную метрику на активированных поставщиков (тех, кто успешно завершил адаптация и видел пациентов), способ работы команды изменились почти в одночасье. Также было интересно посмотреть, как идея «параметрических метрик» в OPS была почти идеальным аналогом противовеса, используемых в настройке моделей - по сути, вторичные метрики, которые вы определяете, чтобы обеспечить ограждения за команды, в то время как они преследуют метрику North Star (например, если снижение затрат - северная звезда, можно использовать удовлетворение клиента в качестве метрики спаривания)), можно использовать удовлетворенность клиентом в качестве метрики спаривания).

Урок: четко определенная метрика North Star заслуживает такой же одержимости, как и входные данные для целевой функции в настройке модели - небольшое изменение может пройти чрезвычайно долгий путь.

Отличная абстракция и передача передач необходимы для отличных команд, а не просто отличного программного обеспечения

Много хорошего программного обеспечения состоит из хороших абстракций. Вы определяете прозрачные интерфейсы, чистого оркестровки и разлагаете сложность в композиционные модули. Чем более последовательные, интуитивно понятные и чисто определяли контракты API между услугами, тем более масштабируемые, надежные и высокопроизводительные эти системы, как правило, являются.

То же самое относится и к высокофункциональным командам OPS. Всякий раз, когда мы выступали за новые команды, от групп партнерства с плательщиками до управления доходами, я быстро понял, сколько времени нам пришлось потратить, особенно для более крупных команд/команд команд - вдумчивая владение метриками (см. Вышеупомянутый момент), точки передачи, и где можно нарисовать линию между областями общего владения, чтобы сбалансировать индивидуальное владение и разделяемые контекст (аналогично различным услугам в программном обеспечении, которые могут ссылаться на Sareed). Я обнаружил, что опираюсь на свое инженерное прошлое больше, чем ожидал: рассматривать команды как услуги, писать «интерфейсы» в форме четко определенных структур владения метрикой и т. Д.

Урок: Создание хороших команд OPS много делится с созданием хорошего программного обеспечения, выгодным от преднамеренной абстракции, четких контрактов и вдумчивой оркестровки.

Заключительные мысли

Во многих странных способах мое время в Бизопах не отнесло меня к инженерии. В некотором смысле это приблизило меня; Не всегда для самого кода, но, конечно, для ментальных моделей, которые делают инженеров эффективными. Если вы являетесь инженером, интересующимся переходом в сторону бизнеса, не стоит недооценивать, насколько передается ваш инструментарий. Абстракции более сложные. Входные данные немного шумнее. Но под капотом? Есть много системных мышлений.

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE