일은 자꾸 커질 수 있어요.

 

기능을 만들다 보면 최초에 생각했던 것보다 큰일이 되는 경우들이 발생하곤 해요. 특히 제품의 복잡성이 커질수록 이렇게 일이 커지는 경우가 많아질 수 있어요. 간단한 기능의 추가 정도라고 생각했던 것이 다른 제품이나 기능에 영향을 준다거나, 제품의 기존 정책에 수정이 필요하게 될 수도 있어요. 결국 최초에 구현하고자 했던 범위에 더해 영향을 주는 범위까지 해결하다 보니 시간과 인력이 더 많이 필요하게 되어 버려요.

이렇게 일이 진행되면 제품을 만드는 구성원들이 지치게 되어 동기부여가 잘 되지 않고, 정말 힘든 경우 부정적인 생각들이 차올라 기능에 의구심을 가지게 되어버릴 수도 있어요. 한편 PM으로서 이런 일을 마주하면 개인적으로는 내가 일을 예측하는 능력이 부족하다고 느껴지고, 충분히 고민하지 못했던 것 같아 우울해지곤 했어요. 미안한 마음도 커지고요.

이번 글은 점점 커지는 일의 범위, 완벽하지 못하다는 생각에 힘들어할 때 어떻게 일을 하면 좋을지에 대해서 작성해 본 글이에요. 글의 순서는 아래와 같아요.

 

1. 괜찮아요. 우리는 완벽하지 않고, 함께 나아가는 과정이에요.
2. Chunk가 커지면 그냥 쪼개어 나누어 가보는 건 어때요?

 

 


 

 

괜찮아요. 우리는 완벽하지 않고, 함께 나아가는 과정이에요.

 

우리가 이미 해보았던 경험이면, 아니 모든 경험들을 다 해보았다면 이런 일은 생기지 않았을 거예요. 과거에 해봤던 경험에 비추어 일의 크기를 예측할 수 있을 테고, 일의 영향 범위를 파악하여 일정을 수립할 수 있을 거예요. 하지만 대부분의 우리는 그러지 못해요. 아니, 과거의 경험들이 아니라 우리는 계속해서 새로운 경험들을 만들어가고 있기 때문에 예측은 쉽지 않아요.

또한 우리는 우리는 완전하지 않고, 완벽하지 않은 존재예요. 때때로 완벽하지 않으면 못하는 것 같고, 무의미해질 수 있다는 생각에 완벽해지려고 노력하지만, 사실 쉽지 않아요. 하지만 괜찮아요. 비록, 조금은 부족하더라도 우리는 우리와 함께하는 팀이 있어요. 팀으로서 모인 각자는 부족함이 많아 완벽하지 못한 존재일 수 있지만, 우리가 팀으로 만나 제품과 기능을 만들고, 이를 토대로 사용자가 가지고 있는 어떠한 문제를 해결해 주고 가치를 제공할 수 있도록 만들 수 있어요. 부족한 우리가 팀으로서 만나 서로를 도우면서, 그렇게 제품을 만들어가고 나아갈 수 있어요. 더욱이 PM으로서 우리는 홀로 존재하여 가치를 만들 수 없지만, 함께 함으로써 가치를 만들 수 있는 존재잖아요?

그렇게 우리는 리더가 절대적인 역량을 가지고 무언가를 만들자고 내려가는 탑다운 방식이 아니라, 서로가 부족함이 많더라도 바로 내 옆에 있는 동료와 함께 최선을 다해 제품을 만들어가도 괜찮다는 걸 점차 느끼고, 배우면서 나아가면 돼요.

 

 

 

 

Chunk가 커지면 그냥 쪼개어 나누어 가보는 건 어때요?

 

처음부터 전체를 보고 갈 수 없다면 하나하나 부수면서 가보는 건 어떨까요? 물론 너무 당연한 이야기일 수 있어요. 큰 에픽 덩어리의 일들을 작은 스토리 덩어리로 쪼개고, 각각의 스토리를 구현하는 과정을 완전히 분리해서 병렬적으로 진행해자는 이런 이야기는요. 하지만 앞서 이야기했듯 이 과정에서 계속 일이 커질 수 있어요. 각각의 스토리에서 영향을 받는 범위가 늘어나고, 해결해야 할 것들이 늘어날 수 있어요.

이때 우리는 중간에 변경되는 지점이 있더라도, 새로 영향을 받는 범위가 발견되더라도 우리가 기존에 구현하기로 했던 스토리와 분리해서 기존의 것들을 완성하는 경험을 해야 해요. 대부분의 경우 우리는 이렇게 영향이 받는 범위를 계속해서 구현 일정에 포함해서 완벽하게 만들고 싶어 하잖아요? 그렇지만 새로 해결할 일이 나오더라도, 심지어는 지금 구현하고 있는 것에서 변경이 필요한 지점이 있더라도 일단 기존에 하던 걸 마무리하는 게 필요할 수 있어요. 지금까지 구현한 스토리가 사용자에게 가치를 줄 수 있을지 확인하는 과정을 거쳐보아요. 그렇게 우리 제품의 각각을 실제로 만들고 완료하는 경험들을 해보아야 해요. 아까 문제가 되었던 부분들은 새로운 이터레이션 때, 변경이 필요한 부분을 구현하고, 수정해서 완성도를 높이면 돼요.

이렇게 하는 이유는 당장의 작은 성공 경험, 구현 경험들을 쌓아 제품이나 기능 자체를 가시적으로 확인하고, 사용자에게 가치를 주는지 계속 확인해 나가기 위함이에요. 이런 작은 경험들을 계속 넓혀가면서 비록 우리의 시작은 완벽하지 못했지만 우리의 제품은 완벽하게 구현해 나갈 수 있어요.

 

 


 

 

결론

 

어쩌면 이렇게 하나하나 쪼개어 작업을 진행하고, 점차 완성도를 높여가는 과정은 당장에는 더뎌 보일 수 있어요. 하지만 이런 경험을 꾸준히 하다 보면 장기적 관점에서는 우리가 보다 완벽해질 수 있도록 만드는 현실적인 방법일 수 있어요. 이런 경험들이 쌓이다 보면 어느 시점에서 터닝 포인트가 올 수도 있거든요.

경험들이 모여 우리는 결국 어느 시점에는 제품 구현 과정에서 일의 예측을 보다 정교하게 할 수 있게 돼요. 여러 경험들을 토대로 일의 본질을 찾아낼 수 있고 이렇게 찾은 본질적인 내용으로 다음에 새로운 제품과 기능을 만들 때 어떤 것들을 해야 하는 지를 파악할 수 있을 거예요.

 

 

June님의 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.