협의한 개발 목표와 개발의 결과는 같을까?

안녕하세요. yeTi입니다.
오늘은 개발의 결과가 예상한 결과와 같을까? 에 대한 생각을 공유해보고자 합니다.

전에 재밌는 현상을 먼저 소개하고자 합니다. 아래 인용구는 안영회 대표님의 브런치의 현장과 의사소통을 돕는 협업도구 두레이 에서 발췌했습니다.

한국에서 일할 때와 달리 중국에서는 서로 대화가 어려우니 내 말을 이해했는지 거듭해서 확인하고 기록도 하며, 화면이나 코드로 재차 확인하니 도리어 결과가 빨리 나왔던 것이다.

결과는 다르다

현업에서 지속적으로 코드기반 대화하기 를 수행하고 있고 최근에 사내 사이드 프로젝트를 진행해보면서 우리가 협의한 개발 목표와 실제 개발된 결과는 각자가 예상한 결과와 다를 수 있다는 것을 느꼈습니다.

코드리뷰차 상대방의 코드를 보다보면 협의를 진행하면서 내가 예측한 로직과 실제 구현한 로직이 상이한 부분을 보고 해당 개발자와 대화를 하다보면 서로간 이해의 폭이 달랐던 경우가 종종 있습니다.

또한 이번 사내 사이드 프로젝트를 진행하면서 간략하게 정의한 스토리를 보고도 각 개발자가 다르게 인식하여 다른 결과가 나온것을 보고

이렇게 간단한 기능조차 서로의 생각이 다를 수 있구나

라고 생각이 들면서 작지않은 충격을 받았습니다.

그러면서 이전에 안영회 대표님께서 하신 말씀이 떠올랐습니다.

대화할때 내 의도가 상대에게 전달되는 수준이 어느정도일거 같으세요? 저는 20%도 안될거라고 생각합니다.

당시에 저는 그래도 80%이상 이라는 답변을 했지만 요즘엔 진짜 80%나 전달이 될까? 라는 생각이 들기도 합니다.

오해의 제거

위에서 언급한 결과는 다르다 라는 문구가 개발 자체를 잘못하고 있다는 오해를 만들 수 있어 이는 언급하고 넘어가고자 합니다.

해당 글의 전제는 대화나 텍스트로만 협의한 내용은 각자의 예상과 다를 수 있다는 부분을 언급하고 싶은 것이 글의 의도입니다.

생각 맞추기

그렇다면 어떻게 서로가 예상한대로 서비스를 개발할 수 있을까요?

저는 지속적이고 잦은 피드백 + 시각화라고 생각합니다.

대화나 텍스트로 생각을 전달하는것에는 한계가 존재합니다. 왜냐하면 이를 받아들이는 개인에 따라 다르게 인지할 수 있기 때문입니다.

서로 다른 개인들이 협업을 위해서는 생각의 차이를 좁혀나가야 하는데요.

이를 가장 직접적으로 할 수 있는 것이 시각화이고 이를 기반으로 생각을 구체화할 수 있는 것은 지속적인 피드백입니다.

그리고 XP 에서 추구하는 아기발걸음 처럼 서로의 생각의 차이가 작게 나올 수 있는 수준으로 개발을 진행하며 피드백을 통해서 그 차이를 좁혀 나가는 것이 필요하다고 생각합니다.

다름을 인정하기

또 하나 중요한 것은 수용입니다.

안영회 대표님의 성공적 대화를 돕는 그림 을 보면 그림이 있습니다.

해당 그림이 나타내는 중요한 의미는 내가 주장하는 100%가 수용될 수 없음을 인정하는 것입니다.

협업이란, 다름속에서 서로 공감을 가지는 일부분을 수용하는 과정이기 때문에 서로가 100% 만족할 만한 협의가 나오면 좋겠지만 그러지 않을 가능성도 높습니다.

만일 나는 100% 만족할만한 협의를 했다 고 생각한다면 스스로 주장만 하다 본인의 결론으로 유도했는지에 대해 돌이켜볼 필요가 있다고 생각합니다.

가치기반 의사결정하기

결국 서비스를 만들어 나감에 있어서 가치가 성장하느냐 가치를 훼손하느냐로 판단을 하면 의외로 쉽게 결정할 수 있습니다.

간혹 서비스의 가치에는 중요하기 않는 문제로 감정소비를 할 때도 있기 때문입니다.

앞서 언급한 사내 사이드 프로젝트를 예시를 들어보겠습니다.

서비스 UX 가 저의 예상과 다르게 나와 불편했습니다. 하지만 해당 UX가 서비스 가치를 훼손하는가? 혹은 내가 예상한 UX가 서비스 가치를 높이는가? 로 질문을 바꾸면 그렇다로 말할 수 없기 때문에 추가적으로 주장하지 않았습니다.

추천 로직이 저의 예상과 다르게 동작하여 불편했습니다. 해당 로직이 서비스 가치를 훼손하는가? 로 질문을 바꿨더니 그렇다 로 말할 수 있었기 때문에 주장을 하여 로직을 변경했습니다.

데이터 정제 작업이 저의 예상과 다르게 진행되어 불편했습니다. 해당 데이터가 서비스 가치를 훼손하는가? 로 질문을 바꿨더니 그렇다 로 말할 수 있었기 때문에 주장을 하여 데이터 필터를 위한 개념을 변경했습니다.

애자일

문득 이러한 활동이 애자일 인가? 라는 생각이 들었습니다.

의도와 다른 방향으로 개발이 될 수 있기 때문에 짧은 주기를 반복적으로 실질적인 서비스를 보며 피드백을 주고 받는것이 애자일의 가치라는 생각이 들었습니다.

결국 예상과 달랐던 부분은 당연하게 다를 수 있는 부분이고 이를 확인하고 보정하는 과정이 너무나도 당연한 활동이 아니었나 라는 생각이 들었습니다.

결론

다시 서두에서 언급한 인용구를 보겠습니다.

한국에서 일할 때와 달리 중국에서는 서로 대화가 어려우니 내 말을 이해했는지 거듭해서 확인하고 기록도 하며, 화면이나 코드로 재차 확인하니 도리어 결과가 빨리 나왔던 것이다.

동일한 언어를 사용함에도 불구하고 다수의 사람의 모여 동일한 목표를 가지고 일을 한다는 것은 쉽지 않은 일이라고 생각합니다.

그렇기 때문에 우리는 현업에서 협업툴도 사용하고 기획서나 개발문서등 다양한 방식으로 생각을 공유하는 시도를 합니다.

결국 서로 다른 개인이 동일한 결과를 만들기 위해서는 서로에 대한 관심으로 잦은 피드백을 주며 확인하는 과정을 통해 생각을 일치시켜나가는 과정이 중요하고 생각합니다.