박세호

성장이 느려졌던 스타트업들의 공통점

 컨텍스트(맥락)를 알지 못한 상태인 사람들에게 잘못된 방향으로 비전을 강조할수록, 강조는 "세뇌"의 형태로 변질됩니다. 이로 인해 같은 방향으로 가지 않거나 본인의 생각과 다른 방향으로 가는 팀원들을 "잘못된 사람"이나 "능력이 없는 사람"으로 치부하게 됩니다. 그리고 이는 팀의 균형을 망치게 되고 성장은 더뎌지는 환경을 만들게 되죠.

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

MVP는 산출물이 아닌 과정입니다.

https://brunch.co.kr/@tsp/42

MVP라는 개념은

• “요기서 이 버튼이 이렇게 돼야 이쁘지 않을까?”

• "지금 좀 더 기술적으로 새로운 것들을 마구 시도해 봐야 좋지 않을까?”

• "특정한 정책이 조금 더 유저 친화적으로 바꿔야 하지 않을까?”

• 같은 우리가 가지고 있는 일반적인 가정들에 대한 부분을 최대한 줄이는 것 뿐만 아니라,
  "이런 기능은 출시 후에도 작업해도 되니 MVP에서는 뺍시다."

처럼 최소 공수로 만들어지느 제품이라는 말도 아니다.
프로덕트가 제공하고 싶은 가치를 입증할 수 있는 컨셉을 확인하는 과정이라는 것이다.

이를 위해선,

• “우리가 이 서비스를 만들면서 가장 위험하다고 생각한 요소는 무엇일까?”

• “우리가 이 서비스를 잘 지속하지 못하게 된다면, 가장 큰 이유는 뭐가 있을까?”

• “사용자들의 정보를 처리하는데, 문제가 생길 때에는 어떻게 정리해야 할까?”

등에 대한 Risk Accessment를 시작으로

• 어떤 프로덕트를 만들어가는지,

• 왜 사용자들이 프로덕트를 사용할 것인지,

• 사용자들의 니즈가 명확하게 존재하는지,

• 우리가 너무나 많은 시간을 우리의 가정들을 충족시키기 위해 쓰는 것은 아닌지 

확인을해 나가는 과정이라고 생각해야 한다.