레이블이 아이디어인 게시물을 표시합니다. 모든 게시물 표시
레이블이 아이디어인 게시물을 표시합니다. 모든 게시물 표시

2009년 11월 23일 월요일

아이디어 보상제의 함정

소프트웨어 회사에서 참신한 아이디어가 생존에 필수인 것은 당연합니다.
그래서 소프트웨어 회사는 좋은 아이디어를 뽑아 내기 위해 갖은 노력을 합니다.
하지만 이는 그렇게 쉬운 일이 아닙니다.
가끔 아이디어에 대해서 돈으로 보상하는 정책을 시행하는 회사를 보게 됩니다. 
그런데, 별로 큰 효과를 보지 못하는 경우가 많습니다. 오히려 역효과를 일으킬 수가 있습니다.

개발자는 원래 아이디어가 넘치는 사람들입니다. 또한 아이디어 내는 것을 좋아하죠.
이를 보상이라는 것으로 보답을 하기 시작하면 자칫 아이디어 내는 것을 더 방해할 수도 있습니다.
보상을 위해 아이디어를 내놓는다는 도덕적인 결함이 이를 가로막습니다.
아이디어에 대한 보상은 도덕적으로 상처가 되지 않을 만큼 작다면 문제가 되지 않습니다.
즉, 새로운 아이디어를 낸 직원에게 5,000원짜리 도서상품권은 별 문제가 되지 않습니다.
하지만, 아이디어 10개를 내면 백만원을 주고 상품화되면 매출의 몇%를 준다는 식의 보상은 그럴 듯 해 보여도 도적적인 압박이 개발자들의 두뇌를 억눌러서 아이디어가 나오지 못하도록 방해하기도 합니다. 

개발자에 대한 최대의 보상은 자신들이 낸 아이디어로 프로젝트를 할 수 있게 해주는 겁니다. 물론 기존의 업무는 그대로 하고 이것도 하라는 식으로는 곤란합니다. 또 나오는 아이디어마다 모두 만들어 보자는 식도 곤란합니다. 아이디어는 서로 활발히 의논하고 발전시킬 수 있는 분위기와 환경이 되어야 하면 회사의 지원도 필요합니다. 이렇게 도출된 아이디어는 아이디어 발의자의 이름이 따라다니고 개발자에게 이 프로젝트에서 활약할 기회를 주는 것으로 충분한 보상이 되기도 합니다. 
또한, 실제 대단한 성과에 대한 보상은 추후 감사의 의미로 지급할 수 있습니다. 하지만 보상을 유인책으로 쓰는 것은 부작용이 더 클 수도 있습니다. 따라서 진정한 감사 의미의 보상이 아니라면 서로에게 불편하며 큰 부작용 및 송사에 휘말릴 수도 있습니다.

정말 끝내주는 아이디어가 있어서 회사에 바치기 아까우면 아이디어를 가지고 퇴사를 하십시오. 그리고 직접 회사를 설립해서 개발을 해 보세요. 물론 실패할 가능성은 99%입니다. 하지만 성공하면 대박이겠죠.  물론 기존의 회사에서 시도하더라도 성공할 가능성은 10%가 안될 겁니다. 

지금의 회사에서 개발자가 가진 아이디어를 펼치는 것은 개발자에게는 좋은 기회가 될 것이고, 경력에도 긍정적인 영향을 끼칩니다. 수동적인 프로젝트 참여보다 본인의 아이디어를 기반으로 주도적으로 참여한 경력은 채용에서 훨씬 긍정적인 영향을 끼칩니다. 또한 개발자들은 이런 식으로 일을 즐기고 이렇게 일할 때 가장 퍼포먼스도 높습니다. 물론 매일 SI나 용역만 하는 회사는 이런 환경을 조성하기는 어렵겠죠. 그래서 저는 SI나 용역만 하는 회사에서 일하고 싶은 생각은 별로 없습니다.

소프트웨어 업계에서는 아이디어가 충만하고 현실화 할 수 있는 환경이 잘 되어 있는 회사가 성공할 가능성이 높습니다. 개발자에게는 돈으로 보상하는 것보다 기회와 업적으로 보상하는 것이 더 좋습니다. 또한 보상제보다는 아이디어가 샘솟을 수 있는 활기 넘치는 환경이 더 중요합니다. 

2009년 10월 30일 금요일

Google을 이끄는 힘

아이디어 내면 "네가 한번 만들어봐"


소프트웨어 업계만큼 아이디어가 넘치는 곳도 찾기 어렵습니다.

Google이 탄생하게 만든 힘도 아이디어이고, Google이 지속 성장하여 지금이 Google이 된 힘도 아이디어입니다. Google에서는 업무시간의 20%는 새로운 아이디어를 생각하거나 준비하는데 사용할 수 있고 좋은 아이디어만 있다면 얼마든지 시도해 볼 수 있습니다. Google이 풍족하기 때문에 그렇게 할 수 있다고 말하는 사람들도 있지만, 이는 닭이 먼저냐? 달걀이 먼저냐?의 이슈입니다.

소프트웨어 업계에 종사하고 있는 사람이라면 항상 새로운 아이디어에 대해서 고민하기 마련입니다.

하지만, 좋은 아이디어를 내면 "네가 한번 만들어봐"라고 하는 경우가 많습니다. 또는 "뜬구름 잡고 있네"라고 하는 경우도 있죠.


안 그래도 바쁜데 아이디어만 내며 그 책임이 나에게 돌아오고 지금 하고 있는 일에 지장을 초래할 수 있기 때문에 좋은 아이디어가 있어도 쉽사리 얘기하기도 힘들어 집니다..

그러다 보니 자연스럽게 지금 하고 있는 일이나 열심히 하지 "생각은 무슨 생각" 그냥 아무 생각 없이 일이나 하게 됩니다.

아이디어가 나오면 아이디어를 더 발전 시키는 일은 회사에서 할 일입니다.

물론 아이디어를 내놓은 사람이 아이디어를 Follow up하는 일을 맡을 수도 있지만, 이를 위한 배려는 해야 합니다. 안 그래도 바쁜데 언제 그러고 있냐고요? 그러다 보면 지금 하고 있는 업무에 지장이 있다고요? 그런 회사는 어차피 현재 일에만 치여서 미래는 준비 못하는 겁니다. 즉 R&D에 투자를 못하는 것이고 미래가 없는 것이죠.


SW 회사의 중요한 자산은 개발자의 시간이기 때문에 개발자의 시간을 사용하는 것은 중요한 투자 수단의 하나 입니다. 공짜가 아니죠.


아이디어가 나오면 일단 공론화 할 수 있는 창구가 필요합니다.

그래서 누구나 볼 수 있고 토론을 할 수 있어야 합니다. Wiki를 이용하는 것도 좋은 방법이고 주기적으로 아이디어를 발표하게 하는 것도 좋습니다. 사소한 아이디어 하나가 여러 사람의 머리를 거치면서 훨씬 더 멋진 아이디어로 발전하는 경우는 흔합니다.


아이디어를 많이 생각해 낼 수 있는 수단이 필요합니다. 간단한 포상을 해도 되고, 평가에 반영할 수도 있습니다. 또 아이디어가 실현되어서 수익을 내게 되면 그 수익의 일부를 지급하는 방법도 있습니다.


꾸준히 아이디어를 내지 않는 SW회사는 용역회사밖에 될 수 없을 겁니다. 


아이디어는 10개 나오면 그 중에 하나 쓸만하고, 그 쓸만한 아이디어 10개 수행하면 한 개 정도 성공하고 그 성공한 아이디어 10개 중에서 한 개 정도 대박이 터질까 말까 합니다.

즉, 아이디어가 1,000개는 나와야 대박이 나올까 말까 한다는 겁니다.


999개의 아이디어가 없으면 대박 아이디어 1개가 나오지 않습니다. 그래서 꾸준히 아이디어를 고민하지 않고 몇 명이 머리 맞대고 대박 아이디어 고민하는 것은 확률이 너무 낮습니다.


아이디어는 어느날 갑자기 계시를 받듯이 하늘에서 뚝 떨어지는 것이 아닙니다. 업계 동향도 꾸준히 살펴야 하고, 신기술도 열심히 익혀 놓고, 새롭고 창의적인 생각을 장려하는 기업 문화가 있지 않으면 아이디어가 생기지 않습니다. 좋은 아이디어라고 하더라도 시장의 상황과 맞지 않는 다면 별 효과를 발휘하지 못할 수도 있습니다. 이런 시기 적절하지 못한 아이디어라고 하더라도 잊혀지지 않도록 꾸준히 관리할 수 있는 도구도 필요합니다. 


아이디어를 먹고 살 수 밖에 없는 Software회사가 아이디어 발굴에 소홀히 한다면 지금은 그럭저럭 살아남을 수 있어도 지속적으로 성장하는 회사가 되기는 어려울 겁니다. 아이디어 없이 영업으로 성장한 회사의 개발자들은 참 고될 수 밖에 없습니다. 그런 회사에서 일하는 개발자를 흔히 "앵벌이"라고 하죠. 


끊임 없이 아이디어 발굴에 투자하는 기업문화가 개발자들을 더욱 즐겁게 일하고 건전하게 성장하는 소프트웨어 회사를 만들어 줍니다.




2009년 4월 17일 금요일

이거 팔면 돈 되겠는데!

오래 전 여러 기업을 거느린 그룹들이 기가 막힌 아이디어를 생각해 내게 됩니다.

여러 종류의 회사를 거느리고 있었고, 회사들의 전산시스템을 구축하였습니다. 

그 당시 여러 군소 회사들에 비하여 상당히 선진화된 MIS 시스템 등을 보유하게 되었고, 구축 과정을 통해서 경험 있는 소프트웨어 엔지니어들을 보유하게 됩니다.

물론 이를 구축하는데 돈을 많이 썼지요.

그러다가 문득 "이거 팔면 돈 되겠는데!"라는 생각을 하게 됩니다.

상당히 다양한 회사를 보유하고 있기 때문에 우리나라에 이와 비슷한 회사가 널렸다고 생각하고 이 소프트웨어를 조금씩 수정해서 팔면 큰 투자를 하지 않고 돈을 쉽게 벌 수 있을 것으로 생각합니다.

이러한 아이디어가 전세계 유래를 찾아보기 힘든 대형 SI회사를 탄생하게 만들었고, 우리나라의 비극적인 소프트웨어 산업구조를 초래한 시작이 됩니다.

일단 소프트웨어를 조금씩 수정하면 다른 회사도 쓸 수 있다고 생각한 것이 가장 결정적인 오류의 시작입니다. 애초에 그러한 확장성에 대한 개념도 없이 만들어진 소프트웨어가 그렇게 쉽게 다른 회사에서 사용될 수 있다고 생각한 것 자체가 그 당시 얼마나 소프트웨어에 대해서 무지했는가를 보여줍니다.

그 결과 소프트웨어 개발에 대한 전문성이 떨어지고 사업에 대한 전문성만 보유한 SI회사들이 대한민국 소프트웨어 산업계를 좌지우지 하면서 저가 수주의 온상이 되고 수많은 유망 소프트웨어업체를 사라지게 만든 장본인이 되었습니다. 다행히 SI회사와 시장이 겹치지 않는 회사들은 살아남았죠.

SI회사들이 이것이 돈이 안된 다는 것을 일찍이 깨달았지만, 특유의 생존력을 바탕으로 변화를 거듭해서 현재의 산업구조에서 살아남는 독특한 형태로 진화했지요.

지금은 소프트웨어 업계에 SI회사의 존재가 당연시 되는 기형적인 사고가 고착이 되어서 고객들도 SI회사가 없는 세상은 상상하지도 못할 겁니다. 이미 권력화된 SI회사의 파워는 이러한 기형적인 구조를 조금씩 개선해보고자 하는 법률의 개정도 가로막는 것이 문제가 됩니다. 실력으로 산업을 이끌어서 큰 회사나 작은 회사나 서로 Win-win을 해야지 힘을 이용해서 나만 살고자 하는 자세는 결국 대한민국의 소프트웨어 산업 자체를 고사시키고 말 겁니다. 

이대로 가다간 대한만국 소프트웨어 시장의 큰 파이는 외국업체에게 넘겨주고, 말 잘 듣는 공공기업의 치다꺼리나 하는 작은 파이만 먹게 되는 날이 오게 될 것입니다.

이미 소프트웨어 개발에 대한 Global 경쟁에서 뒤쳐진 대한민국 소프트웨어 산업의 미래는 암울하기만 합니다. 지금도 넘치는 아이디어와 혈기를 가진 똑똑한 소프트웨어 개발자들이 마구 배출되고 있는데, 그들을 받아들일 소프트웨어 산업은 척박하기만 하고, 그들에게 전해줄 알짜배기 경험을 전달해줄 선배 개발자들도 그리 많지 않습니다. 그 선배들도 그렇게 별로 배우지 못했으니까요. 이제는 유능한 인재들이 소프트웨어 업계로 오려고 하지도 않습니다. 나만 살자가 아니고 다같이 죽을 수도 있는 상황이 되었습니다.

SI회사의 변화를 기대하기에는 너무 늦은 것 같습니다. 그들은 그들 자체적으로 또 살아남기 위해서 진화를 거듭할 것입니다. 다만 다같이 공멸하지 않기 위해서는 Win-win도 좀 생각해달라는 겁니다. 

작은 회사들은 스스로의 활로를 모색해야 합니다. 시장을 피해 다니거나 외국으로 가거나 해야겠지요. 어느 하나 쉬운 것이 없지만, 어쩔 수 없죠. 이미 이렇게 되어 버린 걸요.
 

2009년 4월 8일 수요일

프로세스가 창의성을 저해한다고?

개발 프로세스가 창의성을 저해한다고 싫어하는 개발자, 관리자, 경영자를 종종 만나게 됩니다. 이들이 프로세스를 싫어하는 이유는 과거에 개발 프로세스 도입에 대한 실패의 경험이 있거나 그런 얘기를 종종 전해 듣기 때문입니다.

이렇게 개발 프로세스 도입에 실패하는 이유는 현실성이 없는 이론적인 프로세스를 도입하거나 회사의 역량 수준에 맞지 않는 프로세스를 시도한 경우가 많습니다. 또 인터넷이나 책을 통해서 배우게 된 프로세스를 따라 하다 보면 그 Context를 다 알지 못하고 형태만 비슷하게 흉내 내다가 실패하기도 합니다.

그럼, 그렇다고 프로세스가 없다면 창의성이 샘솟을까요?
개발프로세스가 제대로 갖춰지지 않은 회사는 대부분 각 개발자들의 개인 역량에 따라서 적절히 개발이 이루어지며 개발자들은 역할의 구분 없이 만물박사 식으로 온갖 업무를 처리합니다. 이러다 보면 항상 바쁘고 새로운 기술을 조사한다거나 참신한 생각을 할 틈이 별로 없습니다. 또, 멋진 아이디어가 떠올라도 마땅하게 Follow up할 방법이 없어서 아이디어를 떠올린 개발자가 북치고 장구치고, 경영층도 설득하고, 프로토타입도 만들어보고 시장 조사도 해보고 해야 합니다. 안 그래도 바쁜 마당에서 짬을 내서 또 새로운 아이디어를 Follow up하기는 정말 어렵습니다. 누가 무슨 일을 얼마나 하고 있는지 잘 파악이 안되므로 또 이런 일을 벌여서 괜히 성과도 없이 평가만 안 좋아 질까봐 포기하기 십상입니다. 또 아이디어 낸 사람이 총대를 매야 하기 때문에 그렇다고 기존의 업무가 줄어들지 않기 때문에 공식적으로 이런 활동을 안하려고 합니다.

하지만, 개발 프로세스를 잘 갖추고 있는 회사는 아이디어를 내기만 하면 일단 회사의 System이 이를 Follow up합니다. 일단 아이디어는 수면 위로 떠올라서 여러 사람과의 Review를 통해서 더욱 Refine되고 정식 절차를 통해서 Prototype을 만들고 마케터는 시장 조사를 하고 영업은 고객들의 의견을 수집해 옵니다. 관리자는 해당 개발자가 아이디어를 발전시킬 수 있도록 정식으로 업무를 할당해서 시간을 빼줍니다. 한마디로 개발자는 기술적인 것만 Follow up해도 됩니다. 물론 모든 아이디어가 제품화 되는 것은 아니지만, 이런 아이디어들이 10개 100개 모여서 성공하는 제품이 나옵니다.

결국 프로세스가 창의성을 저해한다는 생각은 무지의 산물이거나 잘못된 경험의 결과입니다.

문제는 회사의 몸에 딱 맞는 개발프로세스를 갖추는 것이 어렵다는 것입니다. 현재 개발을 어떻게 하고 있는지 조사를 해보면 제각각 일겁니다. 이것부터 통일해 나가면서 조금씩 바꿔가는 것이 스스로 해볼 수 있는 최선의 방법입니다.