박세호
컨텍스트(맥락)를 알지 못한 상태인 사람들에게 잘못된 방향으로 비전을 강조할수록, 강조는 "세뇌"의 형태로 변질됩니다. 이로 인해 같은 방향으로 가지 않거나 본인의 생각과 다른 방향으로 가는 팀원들을 "잘못된 사람"이나 "능력이 없는 사람"으로 치부하게 됩니다. 그리고 이는 팀의 균형을 망치게 되고 성장은 더뎌지는 환경을 만들게 되죠.
https://brunch.co.kr/@tsp/74
박세호님의 아티클
박세호
애자일은 도구가 아닌 이해를 바탕으로 일할 수 있도록 돕는 철학이다.
애자일 "방법론"이라는 것은 생각해 보면 오히려 비즈니스 사이드에서 요청하기 더 좋은, 또 적용하고 싶은 개발 방법론일 수 있다고 생각한다. 뭔가 좋은 회사라면 당연히 이렇게 일할 것 같다는 느낌이 나기도 하고, 독특할 것 같아서도 있지만, "그래서 언제까지 되는데?"를 잘못된 스토리 포인트 산정 방법을 통해서 통제를 하려 하고, 그때까지 수행하지 못한 팀에 책임을 전가하고 비난할 수 있는 도구가 될 수 있기 때문에.
IT, Product Management, Agile, Scrum, Kanban, Waterfall, 등등등 방법론과 수행과정에 대한 수많은 도서들과 글들이 생산되고 소비되는 이유는, 그만큼 다양한 IT 프로덕트/ 프로젝트들이 생겨나고 있다는 뜻이고, 많은 사람들이 시작할 때 생각한 만큼 원하는 것들을 달성하지 못하고 있다고 생각하고 있다는 뜻이라고 생각한다.
하지만, 방법론과 적용방법에 관한 도서들이 많아지고 글들이 많아질수록, "본질"을 찾아가기보단 "누군 이렇게만 했는데 안 밀리고 잘되었다고 하더라"에 집중하게 되는 것 같아 마치 미취학 아동들에게 전기톱을 쥐어준 것 같은 불안감을 느끼기도 한다.
https://brunch.co.kr/@tsp/41
박세호
스타트업에서 심리적 안정감이 중요한 이유(feat. 애자일)
회사라는 이익집단, 특히 많은 이익을 바라고 능력 있는 사람들의 조직인 스타트업에서 가장 필요한 건, "왜 이곳에 있어야 하는가"에 대해 조직원이 스스로 설명할 수 있도록 답을 만들어 갈 수 있어야 하는 것이고, 이를 위해선 단지 내가 조직에서 군림하는 것이 아닌, 같이 가는 팀원으로서 그리고 같이 성장하는 팀원으로서 방법을 같이 찾고자 하고 발전시켜나가고자 하는 마음가짐입니다.
Agile manifesto에는 4가지 Key value와 12가지의 Principles가 존재합니다.
애자일 방법론은 빠르게 사용자들을 만족시키는 제품을 만들고 성장하는 것에 대한 원칙을 만들었던 것으로 유명하지만, Principles에서는 제품을 만드는 사람들 간의 신뢰와 안정적인 커뮤니케이션이 제품을 만들 때 얼마나 중요한지에 대한 이야기가 많습니다. 그만큼 빠르게 성장하는 팀에서 좋은 제품을 만들기 위해선 안정감이 얼마나 중요한 요소인가도 이야기 하는것이죠. (브런치 링크에 내용이 있어요!)
우리는 왜 팀 안에서 일하고 있는가. 이 팀은 내가 어떤 것들을 할 수 있도록 해주는 팀인가. 그런 팀을 나는 어떻게 대해야 하는가 같은, 진정한 팀의 가치를 다시 한번 생각해 보고, 더 좋은 가치를 지속적으로 만들어 낼 수 있기를 이 글을 읽어보시면서 생각해 보셨으면 좋겠습니다. :)
박세호
완벽한 해결안은 없고, 템플릿만으로 끝낼 수 있는건 아무것도 없다
우리는 우리가 처한 상황에 대한 결정을 굉장히 이분법적으로 나눌 수 없는 상황임에도 불구하고, "그래서 지금 당장 어떤걸 찾아서 해야 하는데?" 에 집착하고, 지금 당장에 결정에 집착한다.
예를 들자면,
"개발자가 한두 시간만 개발해 주면 될 것 같은 기능인데, 이런저런 사정이 있어 개발하지 못해 고객들에게 너무나 많은 민원이 들어와 운영팀에서 주말 내내 고초를 겪었다. 이런 문제를 해결할 방법은 무엇인가?"
라는 질문을 받은 적이 있다.
내가 할 수 있는 대답은 "저도 잘 몰라요."라고 할 수밖에 없다. 컨텍스트가 부족하기 때문이다.
그리고 여기서 가장 중요하게 해결하고자 하는 문제 역시 모호하다.
개발자가 할 수 있었음에도 불구하고 하지 못한게(또는 안한게) 문제인가?
운영팀이 주말 내내 고초를 겪어 오랫동안 근무해 업무에 영향이 생긴게 문제인가?
그리고 솔직하게 이야기하기엔, 내가 느낀 문제는 둘 다 아니다.
내가 느낀 문제는, 제품을 만들면서 나온 결정들이 팀 또는 개인이 이해할 수 없는 상황들로 이어진 것이 문제의 근원이다. 하지만 근본적인 문제를 풀지 않고, 상황상의 해결만을 급급하게 처리하게 되면 우리는 다시 적용해 볼 수 있는 기준을 찾을 수 없고 수습에만 급급하게된다.
https://brunch.co.kr/@tsp/64
박세호
https://brunch.co.kr/@tsp/42
MVP라는 개념은
“요기서 이 버튼이 이렇게 돼야 이쁘지 않을까?”
"지금 좀 더 기술적으로 새로운 것들을 마구 시도해 봐야 좋지 않을까?”
"특정한 정책이 조금 더 유저 친화적으로 바꿔야 하지 않을까?”
같은 우리가 가지고 있는 일반적인 가정들에 대한 부분을 최대한 줄이는 것 뿐만 아니라,
"이런 기능은 출시 후에도 작업해도 되니 MVP에서는 뺍시다."
처럼 최소 공수로 만들어지느 제품이라는 말도 아니다.
프로덕트가 제공하고 싶은 가치를 입증할 수 있는 컨셉을 확인하는 과정이라는 것이다.
이를 위해선,
“우리가 이 서비스를 만들면서 가장 위험하다고 생각한 요소는 무엇일까?”
“우리가 이 서비스를 잘 지속하지 못하게 된다면, 가장 큰 이유는 뭐가 있을까?”
“사용자들의 정보를 처리하는데, 문제가 생길 때에는 어떻게 정리해야 할까?”
등에 대한 Risk Accessment를 시작으로
어떤 프로덕트를 만들어가는지,
왜 사용자들이 프로덕트를 사용할 것인지,
사용자들의 니즈가 명확하게 존재하는지,
우리가 너무나 많은 시간을 우리의 가정들을 충족시키기 위해 쓰는 것은 아닌지
확인을해 나가는 과정이라고 생각해야 한다.
박세호
사용자 가치를 파악하지 않는 애자일한 업무 방식은 상상할 수 없다.
많은 PM/PO 또는 서비스 기획자 분들과 이야기 할때, 제품을 개선하고 만들어 가는 팀의 방법에 대해서 물어보면, "우리는 애자일한 방법으로 일하고 있어요."라고 이야기 하지만,
실제로 만드는 과정을 확인해 보았을땐 실제로 어떤 목적을 가지고 무엇을 위한 제품을 왜 만들어야 하는지 보다는
단일화된 개발 프로세스: 2주 안에 뭐라도 배포해야 한다 라는 압박감을 기반으로 작업하고
무언가는 열심히 만드는데, 어떤 결과를 얻기 위해서의 결과가 모호하고
왜 무언가를 만드는지에 대해서 근거가 모호해지는
등 목적에서 벗어난 상황을 많이 목격하게 됩니다.
그리고 이런 상황들을 "우리는 워터폴이 애자일 하게 돌아가고 있다."라는 신기한 업무방식을 구경한 적이 많았던것 같습니다.
"계약의 달성"보다 "고객과의 조화"를 중시하고 "이미 정해진 계획"을 따르기보다 "변화에 대응"을 더 강조하는 Agile Menifesto의 관점에서, 왜 제품을 사용하며 사용자가 느끼는 가치가 다른것들보다 우선이 되어야 하는 이유는 사실 굉장히 단순합니다. 세상을 바꾸려면 그 세상을 사는 사람이 어떤 문제를 가지고 있는지를 알아야 하기 때문입니다.
https://brunch.co.kr/@tsp/44
박세호
https://brunch.co.kr/@tsp/54
제품을 만드는 과정에서 제품관리자들은 상상도 할 수없을 만큼 많은 결정을 해야 하고, 어떤 결정은 가치판단을 쉽고 빠르게 할 수 없어 많은 결정사항에 매몰되는 상황들이 생기기 마련입니다. 그리고 어떤 경우는 모두가 이해하는 결정을할 때에도 또 어떤 때에는 모두가 동의하지 않는 형태로 의사결정이 진행될 때도 있습니다.
의사결정에서 프레임워크를 사용하게 되면 단지 방법을 통해서 결정함을 통해 "빨라진다." 라는 의미에서 끝날 수도 있다고 생각하시겠지만, 오히려 의사결정에서 프레임워크를 사용하는 가장 큰 이유는
첫째, 원팀의 마인드셋으로 업무를 진행할 수 있고
둘째, 의사소통에서 혼선이 적게 빠르게 협의가 가능
하기 때문에 더 자주 또 많이 사용하게 됩니다.
박세호
지난글에서는 "문서화"를 하는 사람은 아니다 라고 했지만,
정말로 그렇다면 이 일을하는 사람들의 본질은 무엇일까요?
우선, 저는 이전에 면접을 보거나, 강의를 할 때 그리고 컨설팅을 할 때
"어떻게 일하세요?"라는 질문을 들으면
"사용자를 중심으로 문제를 파악하는 데 시간을 씁니다."
"정성적인 분석(저는 주로 인터뷰를 진행합니다.)을 기반으로 본질적인 문제사항과 니즈를 확인하고, 사용자가 이야기하신 부분이 진짜 문제인지를 파악하고 가장 싸고 가장 빠르게 제공할 방법을 찾아요."
라고 말을 합니다.
다만 이렇게 말을 하게 되면 돌아오는 대답은 "교과서 같은이야기 말고, 그래서 뭘 하시는건가요?"
라는 이야기를 많이 들을때가 많습니다.
제가 생각하는 제품 관리자는
"진짜 사용자의 문제를 이해하고, 작은 성공과 실패의 실험을 기반으로 큰 가치를 찾는 사람"이 제품 관리자라고 생각하고, 그렇기 때문에 저 교과서 같은 일들을 지금도 하고 있습니다. 그리고 어떻게라는건 언제든 바뀔수 있어요. 저 핵심만 벗어나지 않는다면 어떤 Practice를 해도 문제는 없다고 생각합니다.
Dave Wascha 라는 이 제품 관리자 아저씨도 20년간의 Product Management 에서 가장 중요했었던 이야기를 같은 컨텍스트로 이야기 합니다.
https://brunch.co.kr/@tsp/62
박세호
저는 프로덕트를 만들기 위해서 가장 필요한 것은 “지금 이게 사용자에게 왜 필요한 거지?”에 대한 고민과 제품을 만드는 사람들과 사용자와의 지속적인 인터렉션이지, 종일 기획서를 작성하는 일을 하는 것이 진짜 실무라고 생각하진 않습니다.
오히려, 지금 나의 제품이 어떻게 구현되어 있어서 어떤 것을 개발하는 데 시간이 걸리니 개선할 수 있는 방법을 찾아보거나 진짜 우리가 필요한 기능이 언제 나와야 하는지를 같이 고민하는 것이 진짜 PM과 PO들이 생각해야 하는 일이라고 생각합니다.
기획서, UML, 플로우 차트는 실제로 그것들이 제품으로 만들어지지 않는다면, 그건 그냥 문서를 만드는 일만 한 것이죠. Agile Manifesto에서 “Working software over comprehensive documentation”로 이야기 한 것처럼 문서만 보고 있는데 어떻게 제품으로 그리고 가치로 사용자에게 전달될 수 있을까요?
그리고 문서화의 목적이 실무자들의 퇴사로 인한 정보의 유실과 백그라운드 보완을 위해서나 뉴비 개발자나 제품 관리자들이 지금 프로덕트가 어떤 구조로 되어있는지 감을 알려주는 것에 목적이라면, 같은 일을 하는 조직원들과 Pairing을 통해 업무방식과 서비스의 구조를 확인하고 업무하는것, 그리고 지금 일하고 있는 조직원들이 이탈하지 않도록 같이 성장하고 서로 신뢰하는 조직을 만드는 것이 더 훨씬 더 싸고 지속가능한 방식이라고 생각합니다.
https://brunch.co.kr/@tsp/63
박세호
Forbes에 실린 "The End of Agile"이란 글은 애자일이라는 "무기"로 진행되던 다양한 프로젝트들 때문에 애자일 차제에 대해 환멸과 공포를 가진 사람들이 생겨나고, 왜 그리고 어떻게 이런 상황이 발생했는지에 대해 이야기합니다. 그리고 그 중심엔 사용자가 얻는 가치가 아닌, 기능 개발과 달성 여부에만 집중하게 되는 경향에 있어서 라고 이야기 하죠.
이 글에서는 프로세스 자체가 사용자가 얻는 효용보다는 특정한 기능에 대해서 집중하고, 기능을 개발하기 위한 환경과 상황을 자신이 아는 배경을 가지고 "추측" 후 규정짓기 쉬운, 또는 익숙한 도구를 사용해 진행하고, 달성의 조건을 "완료해야만 하는 시간"으로 설정하고, 완료해야 하는 시간 안에 기능을 만들지 못한다는 것은 프로젝트 실패를 의미한다는 강박에서 업무를 하다 보니 많은 팀들은 애자일에 환멸을 느끼고 떠나게 됨을 이야기하고 있습니다.
그리고 이는 처음 애자일이라는 소프트웨어 개발에 도입하고, 다양한 방법과 구현 방법을 만들고자 하는 사람들이 생각한 개념에서 방법론을 도입하는 것이 아니라, 만들어져 있는 템플릿과 달성의 조건을 프로덕트 라이프 사이클에 대한 집중이 아닌, 단기적인 프로젝트의 달성 조건에서만 집중하는데서 비롯된다고 생각합니다.
https://brunch.co.kr/@tsp/41