'일 만들기' 스태프 엔지니어 가이드, HN에서 '요구사항 공학' 논쟁과 LLM 작성 의혹까지
- 플랫폼 팀은 제품 주도가 아니라 엔지니어링 주도라서 로드맵을 주는 PM도, 따라갈 매출선도, 잃을 시장도 없고, 일은 엔지니어가 만들어내지 않으면 존재하지 않는다는 전제에서 출발함.
- 일을 발명하는 신호를 시스템, 사용자, 조직, 업계 네 방향으로 나눔. 시스템에서는 크래시/포스트모템, 비용, 자신의 토일을, 사용자에서는 지속적 디스커버리, 과부하된 유즈케이스, 파트너-투-프로토타입을 신호로 듦.
- 가장 선호하는 휴리스틱은 과부하된 유즈케이스. 설계 목적이 아닌 문제에 사용자가 플랫폼을 끌어다 쓰는 경우를 사용자가 대신 만들어준 프로토타입으로 보고, 흡수 여부는 "다른 사용자 중 누가 같은 문제를 겪는가"로 판단함.
- buy vs build는 일회성 결정이 아니라 범위, 팀 구성, 기술, 시장이 바뀌면 다시 검토해야 하고, 자신의 토일을 고치는 건 단위 경제성을, 사용자의 토일을 고치는 건 사용자 경험을 개선한다는 구분을 둠.
- 크래시 주도 발견은 가장 최근의, 가장 시끄러운 실패 쪽으로 팀을 편향시키는 최대 지연 지표라는 한계가 있음.
Hacker News 의견들
"inventing work"라는 표현이 좀 이상함. 이건 그냥 요구사항 공학(requirements engineering) 아닌가 싶음.
나도 같은 생각. 글에서 여러 번 나오는 단어가 더 맞는 듯. Discovery.
동의. "defining work"가 더 나은 프레이밍임.
철학 차이인 것 같음. 일이 원래 존재하고 발견하는 거냐, 생각하는 순간 생기는 거냐. 이 사람은 후자 쪽 같음.
변호하자면 요구사항 공학은 좀 수동적으로 들리고 이건 능동적이라, 단어가 완전 틀렸다고는 못 하겠음.
스태프 레벨은 좀 다름. 문제를 주면 요구사항을 뽑는 게 시니어고, 스코프 자체를 발견해야 하는 게 스태프임. 그래서 inventing인데 단어는 별로임.
근데 이 글 LLM으로 쓴 거 아님? 첫 문단에 em dash가 하이픈으로 바뀐 게 두 개 있고, 다섯 번째 문단은 너무 기계적임. 프롬프트만 올릴 거면 솔직히 밝히던가.
난 "what's going to kill us next" 철학 씀. 다음에 우리를 죽일 게 뭔지 찾아서 피하면 됨. 씻고 반복.
"보트에 가장 가까운 악어부터 처리하라"는 말이 딱임.
플랫폼 팀이 제품 주도가 아니라는 프레이밍 자체가 문제임. 그래서 플랫폼 팀이 사용자를 제대로 못 섬기고 망가진 탑이 되는 거임. 시장이 없으면, 섬기는 팀이 떠날 수 있다고 생각해야 함.
토일이랑 포스트모템은 같이 일하는 팀에 꽤 관련 있음.
제품 사람들은 새 기능 아이디어를 어디서 얻음? MS는 경쟁사 보고, 나머지는 고객 페인 포인트 봄. 글에서 말한 그대로임.
제품 사람들이 일을 안 '발명'한다고 가정하는 게 문제임. 기술적인 영역일수록 product가 nonsense를 만들어서 엔지니어가 치우느라 고생함.
VP들이 PM을 꽂는 걸 좋아함. 유명 게임 플랫폼 회사는 스토리지 팀에 PM 둘, 데이터 팀에 하나, 컴퓨트 팀에 하나, dev tools 팀에 하나 있었음.
"no revenue line"이라더니 두 문단 뒤에 Cost 얘기가 나옴. 비용선은 항상 있음. 그리고 비용을 너무 깎으면 플랫폼 안정성이 위험해지고 엔지니어링 조직의 실험 능력도 망가짐.