2013년 5월 28일 화요일

내가 없어도 회사가 잘 돌아가면 왠지 불안하다.

그동안 이래저래 바쁘다는 핑계로 블로그에 글을 못올리고 있다. 앞으로 짧막하게라도 글을 올리려고 한다.

내가 만약 일주일동안 회사를 안나오면 회사가 잘 돌아갈까?
그럼 한달동안 안나오면 어떻게 될까?

대부분의 소프트웨어 회사는 한달동안 심지어는 일주일만 직원 몇명이 안나오면 심각한 문제를 일으키곤 한다.

이러한 종속성은 회사에게는 큰 위험이고 개발자에게는 양날의 검이다.

개발자는 본인이 없으면 회사가 잘 안돌아가는 상황을 선호하곤 한다. 실제로 우리나라에서는 개발자들이 자리를 지키기 위한 좋은 수단이 되기도 한다.  하지만 개발자가 좀더 중요하고 새로운 일을 하는데 발목을 잡히곤 한다.
물론 내가 없어도 회사가 쌩쌩 잘 돌아가는 상황이 매우 불안한 사람도 있을 것이다. 또한 그렇게 합리적으로 돌아가지 않는 회사도 있으니 잘 판단해야 한다.

개발자 뿐만 아니라 Operating에서도 문제는 벌어진다. 특정 직원이 없으면, 빌드나 팩키징을 못하거나 라이센스 발급이 안되는 경우도 있다. 업무는 특정인만 아는 형태로 진행되어서는 안되고 메뉴얼이 필요하고 백업이 가능해야 한다.

회사 입장에서는 리스크일 뿐만 아니라 이런 현상이 벌어지고 있다는 것 하나만 봐도 소프트웨어 개발 전반에 많은 문제가 있다는 것을 짐작할 수 있다.

첫째, 많은 정보, 지식이 특정인 머리 속에 들어 있고 시스템화 되어 있지 않다는 것을 알 수 있다. 또한 리뷰를 통한 공유가 잘되어 있지 않은 것이다.

둘째, 스펙이 제대로 작성되어 있지 않은 것이다.

세째, 개발 프로세스가 제대로 구축되어 있지 않은 것이다. 그 외에도 문제가 많다.

회사는 어떠한 개발자라도 한달 동안 또는 영원히 사라져도 문제 없이 돌아가는 상황이 되어야 한다. 이렇게 하기 위해서 프로세스, 스펙/설계, 기반시스템, 개발 문화를 제대로 구축하는 것이 부담이 된다고 생각하는 경우도 있다. 이는 무조건 주먹구구가 더 빠르고 효율적이라고 주장하는 것과 같다. 초 단기적으로는 주먹구구가 더 나을 수는 있지만 이런 상황은 오래 지속되지 않는다.

특정 개발자가 없어도 잘 돌아가는 환경은 개발자에게도 유리하다. 그래야 개발자는 과거의 일에 발목을 잡히지 않고 합리적으로 일할 수 있는 환경이 된다.

이를 검증하기 위해서는 개발자에게 휴가를 한달씩 줘 보면 된다. 개발자에게 한달짜리 휴가를 줄 수 있는 회사가 되어보자.

2013년 5월 14일 화요일

넣는 것 보다 빼는 것이 더 어렵다.

초창기에 좋은 소프트웨어로 성공하는 업체들이 지속적으로 성장하지 못하고 고전을 면치 못하는 이유는 여러가지가 있다. 그중 하나가 제품이 점점 과도하게 비대해지는 것을 꼽을 수 있다.

성공하는 회사들의 초기 제품은 간략하고 핵심적인 기능으로 사용자들의 요구를 만족시켰다. 하지만 시간이 흐를 수록 경쟁상대가 많아지고 선두를 유지하거나 따라잡기 위해서 제품은 기능은 경쟁 제품들의 모든 기능을 다 포함하기 시작하곤 한다.

고객이 많아질수록 고객들의 요구사항도 다양해지고 하나의 고객도 놓치기 싫어서 가능하면 모든 요구사항을 신제품에 다 우겨 넣으려곤 하다.

이렇게 온갖 기능이 다 포함된 제품을 우리는 "Kitchen Sink"라고 한다. 설거지통에 닦아야 할 그릇들이 잔뜩 쌓여 있는 모습을 상상해보라.

기본적으로 영업은 한명의 고객도 놓치기 싫어서 무조건 고객의 요구사항을 다 들어달라고 요청을 한다.

이것을 조정해서 새로운 제품의 전략을 수립하는 부서는 마케팅부서이다. 하지만 내 경험에 의하면 우리나라의 많은 소프트웨어 회사들은 마케팅보다 영업에 가깝다. 소프트웨어 제품 전략에서 중요한 것은 많은 기능을 넣는 것보다 얼마나 적은 기능으로 최대한의 고객을 만족시키느냐이다. 경쟁제품을 모두 조사해서 슈퍼세트의 제품을 기획하는 일은 쉽다. 어려운 일은 기능을 빼는 것이다.

기능을 빼는 과정에서 기존의 고객을 잃을 수도 있다. 하지만 이것이 두려워서 "Kitchen Sink" Software를 만든다면 더 큰 것을 잃을 수도 있다.

하지만 많은 사람들이 기능을 빼는데는 익숙하지 않다. 영업, 마케팅은 물론이고 마음씨 좋은 개발자들이 기능을 빼는 것을 주저하기도 한다. 그러면 제품의 아키텍처는 점점 복잡해지고 회생 불가능한 상태가 되곤한다.

스펙을 적을 때도 지원할 기능 외에 뺄 기능도 잘 기술해야 한다. 스펙에 지원하지 않을 기능을 적는 것은 지원할 기능을 적는것보다 더 중요할 때가 많다. 물론 모든 미지원 기능을 적는 것이 아니고 기존에 있던 기능을 빼거나 누구나 능히 포함될 것으로 생각하는 기능을 뺄때는 꼼꼼히 적어줘야 한다.

그래서 마케팅팀의 역할이 더욱 중요하다고 할 수 있다.

1%의 사용자도 쓰지 않는 수많은 기능을 개발하느라고 개발 비용은 훨씬 많이 들어가고 프로젝트가 망가져가는 것을 흔히 볼 수 있다. 중요한 것은 넣은 것이 아니고 빼는 것이다.