Staff-инженер в platform-команде должен сам придумывать работу
A Staff Engineer's Guide to Inventing Work
Platform-команды редко получают roadmap от product-менеджера, поэтому staff-инженеру приходится самому решать, что строить дальше. Автор называет это «изобретением работы» и разбирает одиннадцать сигналов из четырёх источников: системы, пользователи, организация и индустрия. Он ранжирует их по двум осям — насколько готовый аргумент даёт сигнал и опережающий он или запаздывающий. Главный навык — объяснить, почему выбран именно этот сигнал, а не десять других.
Overloaded use-cases sit in the middle, which is why they are my favorite. The signal is leading and the argument is already built and running in production.
- dabedee
> Platform-команды управляются инженерами, а не продуктом. Почти никогда нет продакт-менеджера, который вручает тебе roadmap, нет статьи доходов, за которой можно следить, и нет рынка, который можно потерять.
Именно из-за такого подхода и менталитета platform-команды на самом деле плохо служат людям и обычно представляют собой крайне дисфункциональные башни из людей, придумывающих себе работу.
Лекарство от отсутствия рынка — вести себя так, будто команды, которым вы служите, могут уйти. Вся эта статья перечисляет сигналы, и ни один из них не об этом. Быть captive не означает, что у пользователей или внутренних команд нет других вариантов и они этого не замечают. Быть product-led означает заботиться о своих пользователях. Platform-команда должна быть product-led, а не engineering-led в этом очень узком смысле. Иначе вы придумываете работу, как эта статья так замечательно разоблачает.
- fsloth
"эта работа не существует, пока инженер её не придумает".
Это так странно. По-моему, единственная цель, по которой компании нанимают инженеров — поддерживать бизнес. Staff-инженеру не нужен project manager, чтобы сказать, что интересно с точки зрения бизнеса — хотя цели, вероятно, в основном технические.
Я понимаю, что это не всегда так. Но для меня, если ты не можешь привести какое-то обоснование своей работы в бизнес-метриках, ты участвуешь в академическом упражнении.
- juancn
Я использую философию "что убьёт нас следующим".
Выясни, что это, и сделай что-нибудь, чтобы этого избежать.
Стирай, полоскай, повторяй.
- nmehner
"придумывание работы" = "requirements engineering"
"Придумывание работы" — странная фраза, имхо.
- stephbook
Содержание статьи и правдиво, и странно подано.
Автор что, думает, что "продуктовые заказчики" вручают тебе аккуратный список требований, которые тупые программисты-автоматы просто должны перевести в код? Очевидно, нет. Заказчики тоже не знают, чего хотят или могли бы хотеть. Как известно, они утверждают, что хотят более быстрых лошадей.
Затем автор перечисляет "crash led discovery", как будто это так отличается от приоритизации багов в проде. Или, если у тебя нет идей, просто повышение эффективности. Или разговоры с заказчиками, ой, пользователями.
Всё это правда, и ничего из этого не отличается от любого другого софта, просто переведено на другой жаргон.