필자가 컨설팅을 진행했던 수많은 회사들 중에서 80% 이상은 불난 호떡집처럼 매일 불끄느라고 정신이 없습니다.
- 너무 바빠서 새로운 기술을 연구할 시간도 없다고 한다.
- 프로젝트를 진행할 때도 가장 빠른 방법으로 문서도 작성하지 않고 가장 뛰어난 개발자가 바로 코딩부터 한다고 한다.
- 고객들은 기다려주지 않기 때문에 요구하자마자 바로 며칠 안에 제품에 기능을 반영해야 한다고 한다.
- 제품에 버그가 발견되면 하루 이틀 안에 버그를 수정해줘야 한다. 그렇지 않으면 고객들이 엄청나게 컴플레인을 한다.
- 사소한 버그 수정도 빨리 해야 하기 때문에 신입 개발자들에게는 시킬 수가 없다. 고참 개발자가 2시간이면 고칠 것을 신입 개발자를 시키면 2일이 걸릴 뿐더러 고참 개발자가 신입 개발자에게 일을 시키고 검토해주는데 2시간이 넘게 걸린다.
- 제품의 아키텍처가 취약해서 기능을 추가할 때 아주 애를 먹는다. 언제 시간을 내서 아키텍처를 깨끗하게 새로 만들고 싶지만, 유지보수에 바빠서 도저히 그럴 시간이 나지 않는다.
- 이러다 보니 수시로 야근이다.
- 운동할 시간도 없어서 몸이 점점 망가진다.
- 영어공부도 하고 싶은데 시간이 없다.
이런 회사의 미래는 누구나 짐작할 수 있습니다.
설령 제품이 고객들 입맛에 맞고 영업도 잘되어서 큰 성공을 이뤘다고 하더라도 시간이 흐를 수록 채산성은 악화되고 개발자들의 사기는 떨어지고 있을 겁니다. 자꾸 옛날에 개발이 더 잘되었다고 회상할 것입니다.
매일 불끄기 모드로는 회사가 성장할 수 없습니다.
회사에서 해야 할 일은 4가지로 구분할 수 있습니다.
구분 | 중요한 일 | 중요하지 않은 일 |
시급한 일 | A | B |
시급하지 않은 일 | C | D |
A. 중요하고 시급한 일
중요한 계약을 따기 위해서 급하게 해결해야 하는 일
B. 중요하지 않으나 시급한 일
일상적으로 제품에 버그를 잡는 일
고객들의 기능 추가 요청을 들어주는 일
C. 시급하지는 않으나 중요한 일
새로운 기술을 연구하는 일
회사의 개발 프로세스를 꾸준히 발전시켜 나가는 일
새로운 아키텍처를 연구하는 일
차세대 제품을 개발하는 일
회사의 개발 문화를 발전시키는 일
D. 중요하지도 않고 시급하지도 않은 일
이런 일은 영원히 미뤄도 된다. 나중에 중요해지거나 시급해질 때 해도 된다.
이 중에서 회사의 미래를 결정짓는 일들은 "C. 시급하지는 않으나 중요한 일"들입니다.
어치파 "A중요하고 시급한 일"은 누구나 열심히 하게 되어 있습니다. 하지만 "B. 중요하지 않으나 시급한 일"을 처리하느라 "C. 시급하지는 않으나 중요한 일"을 처리 하지 않으면 미래는 없습니다.
제가 만난 수많은 회사들 중 대부분은 C에는 거의 신경을 못쓰고 있습니다. B를 조금이라도 소홀히 하면 회사가 당장 망할 것 같은 생각을 하면서 C는 전혀 손을 못댑니다. 거의 99:1인 경우도 많습니다. 하지만 회사를 망하게 하는 것은 C를 소홀히 하는 것이 장기간 지속되는 경우입니다. 평상시에 B와 C에 균형을 가지고 투자를 해야 합니다. 20%~30%는 C에 꾸준히 투자를 해야 합니다. 꾸준히 투자를 하지 않으면 어느날 갑자기 투자를 할 수 없습니다. 지금은 너무 바빠서 중요한 것을 알지만 지금은 투자를 할 수 없다고 말한다면 영원히 중요한 일에 투자를 할 시간은 생기지 않을 겁니다.
"C. 시급하지는 않으나 중요한 일"에 투자를 하는 방법은 여러가지가 있지만 가장 좋은 방법 중에 하나는 조직을 나누는 것입니다. 일부 조직은 항상 중요한 일을 할 수 있도록 하는 겁니다. 또한 개발자들에게도 중요한 일을 소홀히 하지 않도록 항상 상기를 시켜주는 것이 좋습니다.
당장 어렵다면 해야할 일들을 A, B, C, D로 나누기를 먼저 해보시기 바랍니다.
회사를 개인(나)로 바꾸니....
답글삭제저의 조급한 같은 문제도 어느정도 답이 나오는거 같아요..
잘 읽었습니다~
레알님 안녕하세요.
답글삭제세상사 원리는 다 비슷한가 봅니다.
"성공하는 사람들의 7가지 습관" 인가요. :D
답글삭제문제는 기업을 경영하는 사람들에게 있어서 C는 사원들이 알아서 해야할일 ... 이라고 생각하죠.
답글삭제애초에 A가 얼마나 로드가 걸리는지 모르는 경영진이 태반입니다.
저 4개를 나눠봤자 A는 역시 바쁘기 때문에 C를 알아서 해라.. 라고 하고 하부에 로드를 더 걸어버리는 수가 생기죠.
그래서 애초에 경영자의 마인드가 글러먹으면 아무리 좋은 방법론이 나와도 결국은 사용하지 않게 되버립니다. 안타까운 현실이죠.
우울한 딱다구리님 오랫만입니다.
답글삭제제가 그 책을 못읽어봐서... 기본적으로 사람이나 회사나 비슷한 측면이 많아 보입니다.
저는 실제로 컨설팅 현장에서 직접적으로 많이 겪는 내용을 통해서 현상들을 파악하고 있습니다.
black_H님 안녕하세요.
답글삭제C는 당장 수익이 보이지 않는 투자이기 때문에 경영자의 지원이 없이는 직원들이 알아서 하기 매우 어렵습니다.
즉, 소프트웨어 회사가 장기적으로 성장하는데 가장 중요한 키는 경영자가 가지고 있다는 것입니다. 뛰어난 개발자가 있어도 경영자가 환경을 조성해줘야 하죠.
전규현님께서도 말씀하셨지만 이런 회사들이 대부분이죠. 그런데 그런 회사들로 소프트웨어 산업이 계속 굴러가는 걸 보면 참 신기합니다.
답글삭제안녕하세요. Jake님
답글삭제그래서 어느 한계를 넘어서는 회사가 별로 없다고 생각합니다.
Global 소프트웨어 회사와 어깨를 나란히 하기는 어렵죠.
생기고 없어지고, 반복을 하고 잘 망하지 않는 큰 회사들도 소프트웨어 경쟁력보다는 영업력이나 또는 직원들을 쥐어 짜서 내부적으로 엉망인 경쟁력으로 버티는 회사들도 많습니다.
이 굴레를 벗어나야 할텐데 말입니다.
그런데 과연 우리나라 개발환경이 C를 위해 A와 B를 희생할 수 있는 환경인가요..? 우리나라 중소기업들의 대부분이 2~3명인분의 일을 한명이서 처리하고 있지요.. 이는 대표자가 돈좀 아낄려고 그러는 회사 뿐만아니라 사원들을에게 베풀고 경쟁력을 키워주고 싶어하는 회사에서도 마찬가지라고 생각합니다.. 대부분의 경우에 경제적으로 여유가 부족한 경우가 많기 때문에 그럴 수 밖에 없는 경우가 아닌가 생각됩니다.. 대부분의 회사들이 제살깎아내기 식으로 경쟁하고 있는데.. 어떻게 A와 B를 줄이고 C에 투자를 할 수 있을지.. 혹시 알려주실 분 없나요..?
답글삭제안녕하세요. thankee님
답글삭제B:C의 비율을 99:1이 아닌 80:20 정도는 해야 합니다.
당장 B를 99만큼 하지 않으면 큰일 날 것처럼 생각하는 경우가 있는데 그렇지 않은 경우가 많습니다. 99를 80으로 내리기 위해서는 해야 할 것들이 몇가지 있습니다.
개발 프로세스와 기반시스템이 잘 갖춰져 있어야 줄일 수 있습니다. 모든 개발자들이 일당백으로 으쌰으쌰 하는 것 만으로는 어렵습니다.
구체적인 방법은 한마디로 설명하기 어려우니 제가 쓴 책과 블로그의 여러가지 글들을 참조하시는 것이 좋겠습니다.
그렇다고 하더라도 여전히 어려운 문제인 것은 동감합니다.
확실히 오래가는 회사일수록 유지보수(버그잡고 고객대응하고) 비용이 많이 들어가는게 보이는것 같아요.
답글삭제그런 이유로 새로운 라인업으로 갈아태우면서 단종시키는게 아닐까 싶긴 하지만 말이죠 ^^;
구차니님
답글삭제저도 동감합니다. 그래서 여전히 팔리는 제품도 유지보수 비용을 감안해서 적절할 때 단종시키기도 합니다.
제품 라인업을 단순하게 가져가려고 노력하는 것도 중요합니다.
제품을 개발하기 이전에 향후 유지보수를 고려하는 것이 필요합니다.