서로의 Context를 파악하자

같은 프로덕트를 다루는 조직이라도 내부적으로는 서로 다른 성격의 이해관계자 그룹이 생기기 마련이다.

예를 들어 사업 부서에서는 많은 사용자가 사용할 수 있는 서비스를 만들고자 할 것이고,

개발 부서에서는 확장성 있는 설계 및 코드, 안정적인 서비스를 구축하는 것이 그들이 주로 원하는 바일 수 있다.

마케팅 부서라던가 보안 부서와 같이 부서가 여러 갈래로 더 나뉘어져 있다면 각 부서의 요구나 목표도 그 만큼 더 다양할 것이다.

(Cross Functional 한 소규모의 팀이어도 결국 여러 직군의 사람이 모이다보면 각자 원하는 바가 다를 수 있다고 생각한다)

또한 이해관계자는 내부에만 있는 것은 아니다. 서비스를 이용하고 이를 위해 금액을 지불하는 고객 또한 중요한 이해관계자 중 하나다.

 

 

하나의 프로덕트라는 공동의 목적을 갖지만 다양한 이해관계가 얽혀진 조직에서 협업을 할 때 어떤 것을 생각해야할까?

물론 협업을 할 때는 한, 두 가지만 따질 순 없지만 효율적으로 일을 처리하기 위해서 서로의 컨텍스트, 주어진 상황을 충분히 이해를 해야한다고 생각한다.

 

 

이러한 예시를 들어보자.

현재 서비스가 한 사람 당 여러 개의 계정을 가질 수 있는 시스템이라고 했을 때,

사업 부서에서 계정 단위가 아니라 사람을 단위로 묶어서 데이터를 볼 수 있다면 좋겠다라고 개발 부서에 요청이 들어왔다.

 

이 요청에 대해 개발 부서에서는

1. 현재 데이터로는 계정에 대해서 특정 사람임을 식별할 수 있는 값이 없어
   정확하게 계정들을 하나의 사람으로 묶을 수 있는 값을 고객으로부터 받을 수 있도록 추가 기능을 개발한다.
   (예를 들어 휴대폰 본인 확인 같은 기능을 더할 수 있을 것이다)
2. 정확하진 않지만 특정 데이터를 사용하면 계정들을 하나의 사람이라고 볼 수 있을 것이다 라고 전달을 한다.

라는 선택지가 있을 것이다.

 

요청에 대해서 정확한 처리는 2번 보다는 1번일 것이다. (2번은 '정확하진 않다' 라는 전제가 껴있다)

하지만 사업 부서에서 간단하게 지표를 확인하기 위해서 혹은, 중복 발급/발송되어도 상관없는 프로모션을 위해서 요청한 것이라 정확도는 크게 중요하지 않다라고 한다면 1번 보다는 2번이 부정확해도 오히려 적당한 선택지 일 것이다.

 

이러한 사업 부서의 컨텍스트를 파악하지 못한 채 개발 부서에서 밑도 끝도없이 1번에 대해 개발이 들어가게 된다면, 정말 배보다 배꼽이 큰 요청 처리이다.

(또 1번 선택지는 사업 부서에서 원하는 데이터를 당장 줄 수도 없다)

 

이런 식의 일 처리가 반복되다 보면 사업 부서에서는 무언가 요청을 하면 느리게 처리해주니 개발 부서의 느린 일처리에 불만을 느낄 수 있고,

개발 부서에서는 프로젝트 도중에 자꾸 손이 드는 요청만 하니 사업 부서를 안좋게 볼 수 있다.

(서로 고생하는 걸 아니 위와 같은 케이스는 드물겠지만 만약 그렇다면 정말 최악의 케이스다.)

 

우리가 원하는 건 조별과제 처럼 서로 견제하고 불신을 기반으로 일하는게 아니지 않나?

출처: https://www.instiz.net/pt/1187362

 

 

공은 공이고 사는 사라고 말하지만 결국 일은 사람이 하는 일이다.

Process Scheduling 처럼 기계적으로 정해진 알고리즘에 맞춰 딱딱 돌아가는 것이 아니다.

 

 

조직간 충분한 의사소통을 통해 서로 주어진 상황과 무엇을 하고자하는지에 대한 컨텍스트를 충분히 파악하여

분업이 아닌 협업으로 효율적이고 멋지게 일을 하도록 하자.

 

---

 

같이 보면 좋을 발표 자료: 중요한 건 인터페이스야 바보야