마루날의 雜學辭典

아마도 이 날을 절대 잊지 못할 것 같은 지난 5월 23일 토요일에 구로디지털단지에 자리하고 있는 사이냅소프트를 방문했었다.

사이냅소프트는 MS처럼 일하고 IBM처럼 파는 것을 지향하는 아는 사람만 알고 있는 알짜배기 회사이다. 이 회사는 문서필터 솔루션부터 쇼핑검색이나 문서검색서비스까지 제공하면서도 직원들이 야근하지 않는 생산성과 효율성이 뛰어나면서도 인간적인 직장생활이 가능한 회사로 유명하다.(물론 아는 사람들만)

입사하기도 까다로워서(이번 회고때 토론주제로 알게되었지만, 정말 좋은 사람을 뽑기 위해서 노력을 많이 한다) 내가 만약 여전히 개발자였다면 입사를 희망하고 싶은 전도 유망한 회사이다.

사이냅소프트의 전경현 사장님의 도움으로 회고를 참석하게 되었다.

회고는 애자일때문에 유명해졌지만, 일정 기간후에(프로젝트 종료시 등) 지난 기간 동안의 좋았던 점과 개선해야 할 점을 팀원들이 함께 모여서 고민하고 토론해서 개선사항을 도출하고 결정하는 활동이다. 일반적으로 회고의 순서는 다음과 같다.

1. 사전 준비하기
2. 자료 모으기
3. 통찰 이끌어내기
4. 무엇을 할지 결정하기
5. 회고 마치기
   

애자일 회고 책에 보면 각 단계별로 오늘 소개하는 내용 말고도 다양한 도구(피쉬본 차트, 5Why 등등)가 있기에 현재 상황에 맞게 도구를 이용하면 될 것 같다.


사이냅소프트는 개별 팀단위부터 시작해서 회사전체까지 회고를 진행하고 있다고 하는데, 한달에 한번씩 이루어지는 회사 전체 회고를 참관하게 되었다.



이번 회고를 참관하면서 확신하게 된 것은 회고야 말로 회사에서 상하간 동료간 커뮤니케이션 방식으로 최고의 방식이라는 점이다.

평소에 느끼는 사소한 부분부터 중요한 사항까지 사람마다 다른 인식과 생각이 있을 수 있는데, 이를 효과적으로 소통하고 해소하는 것은 거의 불가능에 가까운 일이라고 생각했다.

그래서 그저 가끔 날을 잡아서 회식을 하면서 풀거나 워크샵을 가서 날려버리고 오는데, 근본적인 원인을 제거하지 못하고 구성원들 생각이 제각각이니까 회식이나 워크샵은 임시 방편일 뿐이라고 생각한다.

이번에 참관한 회고는 확실히 제대로된 소통과 토론을 통해서 팀원들이 공유된 생각이나 지향점을 갖을 수 있겠다는 확신이 들었다.

[이 자리를 빌어 어려운 자리를 마음껏 공객해주신 사이냅소프트 전경현 사장님 이하 임직원분들 모두에게 감사드립니다. 그날 사주셨던 수제비도 맛있었어요]

내가 학교에 다닐때 소프트웨어 개방방법론은 거의 관리기법/I 비슷한 얘기만 가득한 답답하고 지겨운 수업이었다. 이거를 어따쓰나 생각했는데, 나중에 직장생활하면서 SI 프로젝트를 하면서 지겹도록 사용하게 된다.

아마 왠만한 IT쪽 개발자들은 아직도 '분석 - 설계 - 구현 - 시험'으로 구성된 관리기업/I 프로세스를 경험하고 있을 것이다. 나중에 내가 PL을 거쳐서 PM이 되니까 아..이게 장난이 아닌 것이다.


내가 가끔 개발자들을 면접 볼 때 하는 질문이 뭐냐 하면, 'Due date와 Quality 중에 중요한 것이 무엇인가?'라는 질문이다. 내 생각에 이 질문은 별로 좋은 질문이 아니데, 왜냐하면 Due date를 맞추어 Quality가 보장된 결과물이 고객에게 전달되어야 하는 것이 정답이기 때문이다.

물론 SI 프로젝트도 위에서 언급한 위험요소를 안고 가지만, 정해진 기한과 협의된 스펙이라는 목적을 달성하기 위해서 어떻게든 처리를 하게 되는데, 문제는 회사 내에서 진행하는 개발에 대해서는 외부 프로젝트 만큼 긴장감이나 압력이 없어서 그런지 몰라도 쉽게 일정을 지연하게 된다. (Quality를 Due Date보다 중요하게 생각하는지 몰라도)

특히나 지금처럼 서비스를 하고 있는 사업부에서는 어떤 식으로 개발을 진행해야 할지가 골치아픈 문제이다. 대부분의 SI 프로젝트는 말 그대로 프로젝트이기 때문에 정해진 기한안에 처음에 협의된 스펙을 구현하면 된다.

그런데 서비스는 1) 기획의 변경, 2) 버그 픽스 등이 수시로 이루어지다보니 처음에 기획된 내용을 개발하다 보면 일정이라는 것이 쉽게 지연되게 된다.

또 하나는 팀원이 4명이면 최소한의 퍼포먼스는 1+1+1+1 = 4 즉, 4명분의 일을 해내는 것이다.(최소한의 퍼포먼스) 그런데 대부분의 개발팀은 1X1X1X1 = 1 이 되는 식으로 개발이 진행되는 경우가 많다. 왜냐하면 대부분의 개발자들이 혼자서는 잘 하는데 협업을 하는 것에 많은 사람들이 익숙하지 않다는 점이다.

수시로 변경되는 요구사항에 적절한 대응을 하고 버그가 거의 없는 안정된 서비스를 만들기 위해서는 어떻게 해야 할까?

삽질(rework)을 피하고 목표하는 품질을 계획하는 일정에 맞추어 만들어내고 싶다.

덧) 그래서 이번주에 사이냅소프트의 전경현 사장님의 배려로 사이냅소프트의 회고를 참관하러 간다. 다녀오면서 후기를 남기도록 하겠다.


 마루날의 雜學辭典|잡학사전을 RSS리더로 편하게 구독해서 보세요~