개발자와 비개발자의 대화는 역시 어렵다.
마치, 연애시절 남자와 여자의 관점 차이랄까?
개발자와 비개발자와의 소통은 정말 어려운 행위다. 서로 다르지만 같은 것을 이야기하는 경우보다는 미묘하지만, 관점의 차이 때문에 결과물의 최종 상태에 대해서는 서로 불신과 오해가 만들어질 수 있다.
물론, 엄청 강화된 프로세스를 도입하고, 회의와 결재, 체크리스트 등의 방법으로 그 결과물들을 정하면서 만들 수 있지만, 이런 관점으로 돌입하는 순간, 스타트업의 속도는 무뎌지고, 기업의 속도에 영향을 줄 가능성이 있다.
하지만, 정말 중요한 사항이고, 비즈니스에 영향을 주는 부분이라면, 조금은 딱딱한 과정의 프로세스를 도입하고, 그것을 기준으로 작업을 진행하는 것도 꼭 틀린 것은 아니다.
아무리 작은 조직이라고 해도 딱딱한 프로세스를 도입하지 말라는 불문율이 있는 것도 아니고,
아무리 큰 조직이라고 하더라도 기민하게 협의만 하고 넘어가지 말라는 법도 없는 것이다.
다만...
의사소통에 문제가 있다고 생각한다면, 장점은 최대한 살리면서 필요한 것들을 챙겨야 한다.
어제도 내부 비즈니스 조직과 개발 조직 간의 의사소통의 문제가 있었다.
디자인 가이드라인에 대한 의사결정과 시안 내용들이 슬랙을 통해서 주고받으면서 기획자, 디자이나, 개발자는 관련 디자인 작업의 승인이 이루어진 것으로 판단하고 업무가 진행되었다. 매우 당연하게, 시안 작업이 3회 이상 반복되었기 때문에 비즈니스 조직의 동의가 구해진 것이라고 판단하였지만...
결론적으로는 해당 디자인 시안은 시안이었을 뿐, 실제 서비스에 론칭되는 의사결정 과정에서는 동의하지 않았다는 것이 작업이 진행된 이후에 발견된 것이었고, 관련 비즈니스 조직과 서비스 운영조직의 의사소통에 문제가 있다는 것이 발견되었다.
비즈니스 조직은 정말 중요한 요소였다면, 관련 내용은 변화하면 안 된다는 이야기를 한마디만 했었으면 이런 미스가 발생하지는 않았을 것이다.
또한, 이 의사결정 과정에서의 시안 논의는 할 수 있지만, 변경하려면 별도의 기준으로 진행해야 한다는 내부의 암묵적인 규정에 대한 이야기나 규정에 대한 협의가 없었다는 것도 발견되었다.
작은 스타트업 조직에서 조금씩 성장하고 있었던 조직에서 조금은 딱딱한 프로세스의 도입이 필요한 시기가 된 것으로 보이는 현상이 나타난 것이다.
업무를 진하고 빠르게 대응하기 위해서 더 많은 변화와 시도를 추구하려고 했던 서비스 조직의 행위나 작업에 대해서는 칭찬을 해야 하는 것이 맞고, 정말 중요한 의사결정 과정의 단계는 별도로 구분해야 한다는 비즈니스 조직의 행위 판단에 대해서도 칭찬을 해야 하지만, 아이러니하게도 서로 잘하려다가 발생된 문제이기 때문에 이 부분에 대해서는 개발 총책임자로서 심각한 고민을 하게 했다.
개인적으로 결론을 내리고, 의사결정을 다음과 같이 하게 되었다.
하나. 비즈니스 조직의 중요 의사결정 과정에 대해서 인지하였기 때문에 해당 작업에 대해서는 별도의 요청이 있기 전에는 동작하지 않는다.
둘. 중요한 의사결정 과정에 영향을 줄만한 부분이 발견되면 이에 대해서 비즈니스 조직이 서비스 개발 조직에게 관련 의견에 대해서는 빠르게 전달하도록 노력한다.
셋. 기민하게 움직이려고 했던 두 조직의 업무 행동에 대해서는 칭찬을 하고, 이에 대해서 더 장점을 가지도록 프로세스를 강화하도록 한다.
물론, 이런 문제들은 계속 나올 것이고, 그 과정 속에서 서로 진부한 결론을 내리기보다는, 진보적인 결정과 실수를 줄이는 과정은 계속 반복될 것이다. 그것이, 진하게 업무를 대하는 스타트업의 기본 모습이니까.
