회의 때문에 일할 시간이 없다.

경영자들은 "우리는 업무 공유가 안돼. 커뮤니케이션이 안돼" 라고 하면서 물리적으로 소통을 증가시키는 방법을 찾곤 합니다.

억지로 회의를 가지게 하고, 영업팀과 개발팀을 옆에 붙여 놓거나, 회사의 파티션의 높이를 낮추는 등의 조치를 취하기도 합니다.

회의시간을 늘인다고, 옆에 있다고 커뮤니케이션이 잘되지는 않습니다. 오히려 잦은 회의는 업무시간만 줄어들고 성격이 다른 부서들이 서로 뭉쳐 있으면 소음 때문에 개발에 방해만 됩니다. 

커뮤니케이션은 적절한 프로세스와 시스템을 통해서 해결해야 합니다. 스펙을 작성하고 리뷰할 줄도 모르는데 제품이 어떻게 만들어지고 있는지 공유가 안된다고 한탄할 수는 없습니다. 프로젝트 관리 시스템이 있다면 회사의 모든 사람들이 프로젝트 진행과정을 물어보지 않아도 훤히 알 수 있습니다. 

대화는 커뮤니케이션에서 가장 중요한 수단이기도 하지만, 가장 비싸면서 오류도 많고 휘발성입니다. 따라서 커뮤니케이션을 강화하려면 대화의 수단은 줄이고 시스템과 기록을 강화해야 합니다.

체계를 제대로 갖추고 있는 소프트웨어 회사라면 대부분의 업무가 몇 가지의 핵심 시스템을 통해서 이루어지며 대화는 꼭 필요한 경우에만 사용됩니다.

물론 당사자들이 모두 모여서 한번이면 해결 가능한 이슈를 메일이나 다른 수단을 이용해서 여러차례 반복해서 소통을 하는 것은 비효율적이죠. 하지만 반대로 시스템으로 간단히 공유하고 의견을 전달할 수 있는 것들을 만나서 해결하는 것은 더 비효율적입니다.

아직도 문제가 생기면 매일 모여서 회의하고 또 결론이 없어서 다음에 또 회의를 반복하고 정보를 공유하기 위해서 또 회의하고 개발 시간은 점점 줄어들고 이런 상황인가요? 프로세스와 시스템이 필요할 때가 된 겁니다.

왜 이리 버그가 많아요?

소프트웨어 릴리즈는 그 성격에 따라서 몇 가지 형태로 구분이 됩니다.

소프트웨어는 그 종류가 셀 수 없이 많아서 획일적으로 얘기할 수는 없어도, 릴리즈를 구분하여 부르는 것은 필요합니다. 릴리즈를 구분하다는 것은 현재 릴리즈가 어떠한 것이고, 그에 따라서 어떠한 프로세스를 따라야 하고, 어떠한 기대값을 가져야 하는지 그 이름만 들어도 알 수 있게 합니다.

하지만, 팩키지를 개발하는 소프트웨어 회사는 나름대로 릴리즈 구분에 익숙해져 있지만, SI회사, 게임회사, 포탈 등의 서비스 회사, 금융회사들은 릴리즈는 그냥 릴리즈라는 생각을 하고 합니다. 따라서 수많은 릴리즈를 함에도 불구하고 각 릴리즈를 부르는 버전도 없는 경우가 허다하고, 개발자가 임의대로 릴리즈를 하는 경우도 많습니다.

그럼 릴리즈를 어떻게 구분하여 부르면 의사 소통에 도움이 될지 알아보죠.

업그레이드 릴리즈 (Upgrade release)

계획된 일정에 따라서 제품의 주요한 기능이 바뀌어서 릴리즈 되는 것을 일컫습니다. 그 규모와 성격에 따라서 메이져 또는 마이너 업그레이드라고 하고 정상적인 개발 프로세스를 거치며 테스트로 전 기능에 걸쳐서 철저하게 이루어 지는 것이 보통입니다.

패치 릴리즈 (Patch release)

특정 기능에서 발생한 버그나 작은 기능을 개선한 것들을 모아서 릴리즈 하는 것을 말합니다. 보통 계획적으로 일정을 잡거나 업그레이드 릴리즈 후 고객들의 반응을 보고 패리 릴리즈 일정을 잡기도 합니다. 보통 유지보수 개발자들이 개발을 담당하고 테스트로 업그레이드 릴리즈 때보다는 간소화 하기도 합니다.

핫픽스 (Hotfix)

심각한 버그가 발견되어서 긴급하게 특정 고객을 대상으로 또는 전체 고객에게 버그를 수정한 버전을 전달하는 것을 말합니다. 이 경우 사안이 긴급하여 개발 및 테스트 프로세스가 상당부분 생략되며, 이로 이한 위험부담을 어느 정도 감수하는 릴리즈를 말합니다.

또 제품의 완성도에 따라서 알파, 베타, RC 릴리즈로 나뉠 수 있습니다.

알파 릴리즈는 제품의 기능은 구현이 다 되었으나 버그는 좀 있을 수 있습니다. 하지만, 제품을 더이상 써 볼 수 있는 정도의 심각한 버그는 없어야 합니다.

베타 릴리즈는 제품의 심각한 버그는 거의 없어서 기능을 거의다 정상적으로 사용할 수 있는 상태를 말합니다.

RC 릴리즈는 제품을 출시할 수 있는 정도로 사소한 버그가 몇개만 포함된 버전을 말합니다.

이렇게 릴리즈를 나누는 이유는 각 릴리즈에 따라서 들어가는 비용과 개발 프로세스가 다르고, 리스크가 다르기 때문입니다. 이러한 구분이 없이 그냥 개발자가 소프트웨어를 수정하는 대로 릴리즈를 하고 있다면, 테스트 등 릴리즈에 들어가는 비용을 들이지 않는 주먹구구식 개발일 가능성이 높습니다. 하지만 이러한 마구잡이식 릴리즈가 결국 더 많인 비용을 이미 지불하고 있다는 것을 알아야 합니다.

커뮤니케이션 오류

소프트웨어 프로젝트를 진행하다 보면 수많은 커뮤니케이션의 오류를 발견하게 됩니다.

문서화 되지 않은 수많은 의견과 결정들에 대한 오해와 대화를 하면서 발생하는 표현의 오류는 한 두개가 아닙니다. 이는 비단 프로젝트에서 뿐만 아니라 일상생활에서도 벌어지는 현상이지만, 일상생활에서의 커뮤니케이션 오류는 그렇게 심각하지 않을 수 있지만, 프로젝트에서의 커뮤니케이션 오류는 심각한 손실을 초래하기 때문에 조심할 필요가 있습니다.

따라서 프로젝트를 진행하면서 오가는 대화나 기록은 명확해야 합니다. 미사여구보다는 직설적인 화법으로 핵심을 정확하게 말해야 합니다. 또 하나의 문장은 사실, 의견, 추축, 가정, 결정 또는 정보일 수 있습니다. 그런데, 현재 하고 있는 말이 사실인지 의견이지 명확하게 하지 않으면 수많은 오해가 발생합니다.

특히, 의견이나 추측을 사실처럼 얘기하면 다른 사람들은 이를 바탕으로 계획을 세울 수도 있습니다. 또 경영진은 잘못된 결정을 내려서 큰 손해를 보게 될 수도 있습니다. 그리고 가정으로 이미 확인된 사실처럼 얘기하면 프로젝트는 큰 리스크를 안게 됩니다. 

따라서 프로젝트에서는 구체적으로 가정과 종속관계를 파악하는 활동을 하게 됩니다. 프로젝트를 진행하면서 확인되지 않은 사실이나 결정해야 할 것들 및 종속되어 있는 항목을 찾아서 리스크관리를 해야 하기 때문입니다. 이러한 하나하나가 프로젝트의 리스크라는 것을 생각하지 못하면 지뢰밭을 걷는 것과 같습니다.

이러한 커뮤니케이션 오류를 제거하려면 이 문장이 사실인지 의견인지를 정확하게 구분하여 적는 것이 좋습니다. 특히 누구의 의견이라고 적을 수도 있고, 누구의 결정이라고 표현할 수도 있습니다. 그리고 가정은 언제 확인하고 해결이 될지 계획까지 적는다면 누구나 해당 내용이 확인이 필요한 가정사항이고 상황에 따라서 프로젝트의 위험 요소라는 것을 쉽게 파악할 수 있습니다. 이렇게 직설적이고 확실한 표현이 삭막하게 들릴 수는 있지만, 프로젝트를 진행하는데 있어서는 더 좋은 표현법입니다.

연인에게 이러한 표현법은 안되겠지요? 

당신을 사랑하는데 이 표현이 사실, 의견, 추측, 가정 또는 결정일까요? 이를 구분해서 말한다면 따귀맞기 십상이겠네요.