제품 및 프로세스 오너로서의 내 워크플로우

다른 스레드에서 누가 내 워크플로우에 대해 더 자세히 공유해달라고 하길래, 댓글로 긴 글 쓰느니 그냥 이렇게 정리해서 올리는 게 낫겠다 싶었어. 누군가에겐 흥미롭거나 도움이 될 수도 있겠지.

25년 넘게 소프트웨어 개발자로 일하면서 코딩하는 걸 정말 좋아했지만, 이제는 개발자나 아키텍트 대신 '제품 오너(PO)'이자 '프로세스 최적화 담당자' 역할을 맡기로 했어.

에이전트들과 나란히 앉아 개발자로 일하려고 하니까 진짜 우울해지더라고. 근데 제품 오너가 되니까 정반대로 활력이 생겨.

사실상 소프트웨어 개발, 요구사항 엔지니어링, 프로세스 정의 및 최적화, 관리까지 여러 팀을 이끌었던 예전 직장으로 돌아간 셈이지.

이게 내 핵심 전제야. 나는 에이전트들을 팀장(오케스트레이터)이 이끄는 프로젝트 팀으로 다뤄. 그리고 이 전제는 생각보다 실제 업무 환경과 아주 비슷해. 팀장과 팀원들 사이에서 오가는 피드백까지 포함해서 말이야. 걔네들 일하는 거 보고 있으면 마치 사내 메신저 대화창을 보는 것 같아.

나는 각각 하나의 명확한 범위를 담당하는 여러 팀을 운영 중이야.

현재 팀 구성: 프로세스 템플릿, 리서치, 제품 빌드, 테스트 VM, 마케팅, 웹사이트 퍼블리싱.

이 모든 팀의 핵심은 프로세스 템플릿 팀이야. 모든 프로젝트가 사용하는 프로세스 템플릿을 관리하지. 새로운 프로젝트를 시작할 때 이 템플릿을 기반으로 빌드해. 버전 관리도 되고 설치 및 업그레이드 정의도 포함돼 있어. 내가 프로세스를 수정하면 다른 프로젝트들도 전부 업그레이드되는 방식이지.

특정 프로젝트의 프로세스를 수정할 때, 그 변경 사항이 일반화 가능하고 다른 프로젝트들과의 교차 검증 리서치를 통과하면 템플릿에 반영해. 이 작업은 프로세스 팀의 오케스트레이터가 수행해. 템플릿 변경은 오직 내 결정이 있어야만 가능해.

프로세스 템플릿은 뼈대 구조와 그걸 생성하는 도구, 에이전트 정의, 그리고 오케스트레이터와 에이전트 간의 프로세스 계약을 정의해. 새 프로젝트의 오케스트레이터는 이걸 가져와서 자기 프로젝트에 맞게 적용하는 거지.

가장 중요한 측면:

• 내가 소유함

  • new tasks for the orchestrator

  • todos/decisions for me

  • reviews for me

• 오케스트레이터가 소유함

  • kanban board - work tracking

    • work packages - details of the work to do by one agent

  • research - research done for this project

  • inbox - handover from other project teams -> starts a research and decision round

  • design document - one line high level summary

    • design docuemt - details and decision history

  • toolchain - tools needed for this project

  • cleanup - describes what needs to be cleaned up after each milestone

  • archiving - things that are done get heavily summarized and archived.