나는 생각하는 사람💁, 너는 만드는 사람👨‍💻

[나는 생각하는 사람(PM), 너는 만드는 사람(개발)이라는 인식을 버리고 모두가 제품에 책임감을 갖는게 당연한 팀을 만드는 방법]

PM/PO는 미니CEO라고 불려지며 책임과 권한을 갖고 분석도 해야 하고 어려운문제에 답도 내려야한다.
그러다보니 솔직히 너무 바빠서

“나는 생각하고 결정하는 사람, 당신은 만드는 사람”과 같은 마음이 자라나게 된다.

💁 PM: 시장분석, 고객인터뷰, 로드맵, 가설수립, 전략같이 깊게 고민하고 글 쓰는건 제가 할테니 여러분은 개발과 구현에 힘 써주세요!

👨‍💻👩‍💻🧑‍💻Dev: 넵 기획서나오면 개발하겠습니다.

분업이라는 것은 가장 효율적인 업무방식이고

이렇게 일하는 것이 결코 나쁘다는 것은 아니다.
서로 각자가 잘하는 것에 최선을 다해 업무에 임하고 있는 것이니 말이다.

그러나 개발자는 작업자(만드는 사람)입장이다 보니 무엇을 만들어야 할 지 input 되지 않으면 지금 당장은 할 것이 없는 것처럼 느껴진다. 그래서 의도하지는 않았지만 이런 사이클이 익숙해지면 점점 PM, 기획자와 이야기할 시간이 줄어들고, 결국 그들이 만들어 줄 산출물(최종본)이나 계획을 기다리게만 된다.

예컨대 이런 것이다.

• 우선순위와 백로그 선정해 주시면 만들게요.

• 스펙이 정해지면 만들게요.

• 기획서부터 주세요 그럼 검토할게요.

• 피드백주시면 그 때 수정할게요.

• 구체화 되지 않으면 공수 산정이 어렵습니다.

• 우리 다음 달에 뭐 해요? (….)

• 기획이 충분하지 않으니 다시 만들어오세요.

그 업계의 전문가이거나..고객과 동일선상에 있던 PM/PO라면 적절한 아웃풋을 내놓겠지만, 도메인이나 산업기술지식이 부족한 사람이라면.. 혹은 프로젝트 경험이 적거나 혼자 작업하는 것에 익숙했다면…무엇을 만들어야 하는지..무엇이 중요한지 사실 솔직히 "모른다.“ 혹은 업계에 대해 "어설프게" 알고 있다. 고객경험이 적다는 뜻이다.

사용자가 되어 본 적이 없거나 사용자에 대한 깊은 공감 없이 접근했다는 말이다. (늘 판매자 입장이었지)

잘 몰라도, 어차피 애자일은 답을 찾는 과정이니까. 몰라도 일단 실행이 중요하다고 배웠으니까…잘 모르겠지만 일단 뭐든 빠르게 만들고 결정하고 실행한다.

그리고 이걸 점차 반복하기 시작하면…이게 디폴트가 된다.

• 잘 모르겠지만 일단 결정해 준다.

• 잘 모르겠지만 일단 대답한다.

• 잘 모르겠지만 수정 요청이 들어오면 그 때 고민해 본다.

• 잘 모르겠지만 일단 피드백을 준다.

• 잘 모르겠지만 어디까지나 개인적인 "의견"을 준다.

그리고 의도치 않았지만 묘한 갑을관계가 되어간다.

이로서 보스형PM(리더), 노예개발자가 만들어졌다.

어쩌다 이렇게 되버린걸까? 누구 잘못인걸까?

사실 누구도 잘못하지 않았다. PM도 개발자도 각자의 R&R을 준수한 것 밖에 없다.

커뮤니케이션 방향이 어디에 있는가?

PM과 개발자의 커뮤니케이션은 서로를 바라보고 있다. (상대방이 요청하면 나는 준다. 내가 주면 상대방은 다시 요청한다)

우린 사실 바쁘다는 핑계로, 제품책임자로서

내가 못하는걸 상대방에게 " 지나치게 의존" 하고 있던건 아닐까? (나는 개발자도 제품책임의 의무가 어느정도 있어야한다고 생각하기에 여기서 말하는 제품책임자는 팀원 모두이다.)

우리 팀은 무엇을 바라보고 일하나요?보다 좋은 제품을 만들기 위해서는 PM도 개발자도 같은 방향을 바라보고 있어야 한다.

고객이나 프로덕트를 바라봐야 한다는거다.

우리가 타깃으로 잡은 고객이 원하는 것은 무엇인지. 우리에게 돈을 지불하게 하려면 어떤 프로덕트를 만들어야 하는지.
제품의 현 상태를 "같이" 바라보고 합을 맞춰야 한다.

개발자는 어떤 자세로 있어야 할까?

제품개발이나 사업기획에 함께 투입 되는 개발자는 흔치 않을 것이다. 하지만 산출물 자체에 의지하고 있다보면 PM,PO,기획자가 하고 싶은 것을 만들어 주는 손과 발 역할로밖에 있을 수 없다. 그래서 여건만 된다면

• 인셉션 덱, 린캔버스를 함께 만들어 간다.

• 제품백로그 아이템사양을 PO와 함께 생각하는 시간을 갖는다.

• 스프린트 플래닝에서 우선순위 백로그 아이템을 함께 생각한다.

• 유저 테스트 결과를 같이 보면서 대응방법을 같이 논의한다.

사실 (비개발자인)기획자인 내 입장에선 이게 되나? 싶은 것들이 많아서, 잘 모르겠지만 일단 기획을 진행하는 경우가 많았다. 그래서 개발자는 기획자가 잘 모르고 애매한 부분이 있을 때 가능한 같이 고민을 얘기하고, 대화해 나가주면 좋겠다.

"개발자는 코딩만 하면 되는거 아닌가요?" 라고 되묻는 사람도 있을 수 있다. 비즈니스에 참여하는 것이 싫은 개발자가 많다. 뜬구름 잡거나 아름다운 미래만 얘기하는거 같아보일테니 그럴 것이다. 왜 그러는지 아는가? 사실 PM도 제대로&잘 몰라서 그런거다. 고객과 미팅해도 알까말까인데 자기 생각만 고집하거나 자기가 만들고 싶은 것만 만들고자 하는 PM은 고객이 원하는게 뭔지 애매하고 몰라서 그런거니

잘 모르는 사람들끼리 설령 실패를 하더라도 가급적 팀원이 서로 모여 머리를 맞대고 고민해야 한다. 그래야 배울 것이 있는 실패를 한다. (매도 같이 맞는게 낫다)

PM의 “잘 모르는데 이 정도면 되겠지” 라는 마음으로 어설픈 역할 분담을 하게 되면...즉 제품메시지가 전달이 되지 않은 상태에서 기능이나 "만드는 것"에만 집중하다 보면
어느 순간 아무도 안 쓰는 제품을 만들고 있게 된다. (경험담)

본 내용은 Regional Scrum Gathering Tokyo2023 (RSGT 2023)에서 mori yuya씨가 발표한 “나는 생각하는 사람, 당신은 작업하는 사람 (중략) ”이라는 세션을 풀어 쓴 글이다. (원본) 발표 시간 40분, 300페이지가 넘는 방대한 내용에도 이해하기 쉬운 단어와 일러스트로 단숨에 빠져든 글이었다. (다만 너무 양이 많아 인쇄 해서 두고두고 봤음 좋겠다. 책으로 만들순 없나? 내가 번역해서 출간 의뢰해볼까?)

내용은 길지만 문장 자체는 초급과 중급 사이의 일본어 수준이니 일본어를 배우고 있는 사람이라면 읽어보는 것도 좋겠다.