레이블이 포상인 게시물을 표시합니다. 모든 게시물 표시
레이블이 포상인 게시물을 표시합니다. 모든 게시물 표시

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월 1일 수요일

Peer Review의 치명적인 유혹

Peer Review는 익히 언급했다시피 가장 중요한 소프트웨어 개발 문화 중에 하나입니다.

그런데, Peer Review를 시행하다보면 경영층에서는 Peer Review를 평가에 이용하고 싶은 생각이 들게 마련입니다. Peer Review 시행자체를 권장하기 위해서 Peer Review 시행 여부를 관리자들의 평가 기준에 포함하는 것은 일리가 있지만, Peer Review의 내용을 평가에 반영하는 것은 자칫 부작용이 더 클 수도 있습니다.

평가에 반영 가능한 Peer Review 결과
  • Peer Review 실시가 잘 진행되고 있는지 관리자를 평가
  • 얼마나 많은 Peer Review에 참석해서 Peer Review에 기여를 했는지 개발자를 평가

평가에 반영하기 부적절한 Peer Review 결과
  • Peer Review에서 누가 결함을 많이 찾았나 평가에 긍정적으로 반영
  • Peer Review에서 발견된 결함의 수를 해당 산출물 작성자에게 부정적으로 반영
  • Peer Review 통계 데이터를 이용하여 포상 또는 제재

이처럼 Peer Review를 정착시키기 위한 활동은 좋으나, Peer Review 내용 및 그 통계를 관리의 목적이 아니고 평가와 상벌에 이용하면 통계는 왜곡되기 시작할 것이며 그 때부터는 통계도 의미가 없어지고, 직원들은 Peer Review를 피하게 될 것입니다.

Peer Review는 동료들간에 서로 같이 검토를 해 주는 것에 의의가 있습니다.