'인문'에 해당하는 글 3건

망하는 사업, 망할만한 사업, 망한 서비스 , 망해가는 서비스..

모두 공통점은 거의 대부분 한가지 이다.


오만함.


대표적인 오만한 서비스인 싸이월드.

한때는 대한민국의 제 1 소셜서비스로 도토리라는 획기적인 싸이버머니 붐을 일으켰었다.

지금은? 근근히 숨만 깔딱대고, 해외로 진출하려던 시도는 모두 먹혔고, 간간이 사용자가 있긴 하지만 이탈하는 중이다.


싸이월드의 오만함은 

대한민국 1위라는 자부심, 선점효과에 의한 무한한 캐시카우 하지만.. 

"Open" 이라는 글자에 뜯기고 잘리고 이탈해 갔다.

나는 싸이월드의 필패가 "주인장만 보는 방명록"에 있다고 본다.

대다수 90%의 사용자가 보기엔 싸이월드는 소통공간이라기 보단 썩어문들어진 샘물 같은 느낌일 수 밖에 없으리라..

아무튼 지금은 망해가고 있는 서비스다..


두번째의 오만한 서비스 네이버 검색 서비스

네이버는 지식인으로 떳고, 검색으로 질거다.

그래서 여전히 서비스를 기획하고 만들지만 네이버만의 폐쇠성은 정말 지독하리만큼 오만하다.

집단지성을 이용한것은 영리한 것 이었으나 , 집단지성의 폐단 (정보의 정확성)은 사라지지 않았고, 

지금은 대한민국 제 1의 검색업체로써 비싼 검색료를 받고 있지만.

실 사용자들은 진실 혹은 정확한 검색에 더 목말라한다.

개발자가 네이버에서 1차로 검색하면 일단 개발자는 아닌거다.

이건 개발자 스스로 자신의 위치를 아느냐 모르느냐 문제이겠지만.

아무튼 네이버의 오만함은 사람들을 돈벌이 수단으로만 보는데 있다.


내가 왜 오만한 서비스를 탓하는 이유는 

우리나라 기획자 풀이 너무 낮아서 그런 것 이기도 하지만 기획을 너무 못한다.

될만한 서비스도 뿌리부터 잘라가 버리는 ( 이 서비스는 무조건 잘 될거야 라는 마인드에서 출발하는 ) 오만함에 진절머리가 나서 그렇다.


좀더 고객친화적인, 펀하고 편한 서비스를 기획하지 못하는 걸까?

갑자기 하나은행의 병맛같은 입력을 하다보니 

하나은행 고객이지만 참 싸이트 오만하게 만들었네 라는 말이 절로 나온다.

특수키 사용은 못하게 막는건 이해가 가나..

계좌번호까지 마우스 키로 입력하는건 너무 오버아닌가?


정말 실망한 사용자는 말을 하지 않는다. 

대안을 찾아 떠나버리지..


하나은행이 월급계좌만 아니면 사용도 하지 않는데.

이번년을 마지막으로 빠빠이 했으면 좋겠다..


오만한 서비스는 망하게 되어있어.. ㅉㅉ



WRITTEN BY
Peter Ryu
Crazy Programmer's World

,

유대인과 화교, 우리가 생각하는 돈을 가장 많이 가지고 있는 민족(혹은 집단)들 중 하나이다.

유대인과 화교가 돈에 집착하게 된 계기 자체가 신뢰 할 수 있는 대상이 없었기 때문이 아닐까 생각하게 된다.

무릇 인간이 가장 발전하게 되는 계기가 환경이 혼란스럽고 변화무쌍할 때 이라고 생각한다.

여러 과학 문명이 꽃피우게 된 계기도 전쟁으로 인한 불안감 때문에 발달하게 되었고, 서양의 경제가 발달하게 된 계기도

식민지 전쟁을 통한 자원확보 전쟁으로 인하여 발달하게 되었다고 생각한다. 흐르지 않았단 시기엔 과학도 경제도 문화도

발달의 속도가 더디게 흐른다, 하지만 유대인과 화교들은 태생적으로 한곳에 정착하는 것이 굉장히 어려웠었다.

둘 다 거처할 곳 없이 방랑하여 영원한 이방인의 느낌이지 않을까 생각한다.

그러기 때문에 발전해야 하고 또 발달해야만 낯선 곳에서 살아남게 된다.

그 상황에서 그네들이 살아 남을 수 있었던 방법 자체가 다음과 같은 공통적은 특성이 있었기 때문이라고 본다.

 

첫째로 그들은 가치에 대한 척도에 대해서 다른 민족과 구분된 동일한 시각이 있다.

다이아몬드를 예로 들자면 유대인들은 항상 보석을 가지고 다녔다. 즉 현금화 할 수 있는 자산에 특별한 집착을 하는 것 이다.

현금화를 하려면 거래가능성을 알아야 한다. 그래서 그네들은 보석감정에 특화된 모습을 보여준다.

각 보석에 등급을 부여 하고 등급의 가치를 매기고 '가치 매기는 법'으로 또 다른 가치를 창출하는 모습을 보고 있노라면

그 특별한 시스템에 나지막한 감탄을 하게 된다.

또한 예전부터 그들은 인적 네트워크 자체도 하나의 가치로 판단하는 법을 배우고 본능적으로 깨우치게 된다.

어렸을 때부터 그네들만의 특별한 교육을 하고 잘 발달되어있는 시스템에 자연스럽게 밀어 넣음으로써 다음 세대를 위한 기반을 만들어 주는 것이다.

가치를 정확하게 보는 시각을 본능에 새기는 작업을 하는 것이다.

 

둘째로 그들은 언제나 몸을 가볍게 하는 방법을 터득했다.

유대인의 경우 언제 어디서 살해당할 위협이 있고, 전쟁이 발생할 위험이 있기 때문에 위에서 보는 바와 같이 현금화 할 수 있는 보석들을 항상

보유하고 있었으며 실제로 전쟁이 발발하였을 때 그것들 만을 가지고 전쟁을 피했다.

마치 "누가 내 치즈를 옮겼을까?" 에 나오는 것처럼 변화에 대응할 준비를 항상 하는 것이다.

몸을 가볍게 하여 어떠한 변화에도 대응 할 수 있는 조건을 갖추는 것이다.

당장 누구라도 전쟁이 났을 때 몸을 피한다고 한다면 준비할 수 있을까?

아마도 유대인과 화교라면 돈이 될 수 있는 것들을 모아놓는 준비가 되어있기 때문에 바로 피할 수 있다고 답할 것이다.

하지만 일반적으론 허둥지둥 하다가 중요한 자신의 자산들도 준비하지 못하고 몸만 피하는데 급급 할 것이다.

이러한 차이로 인하여 변화에 반응하는 속도차이가 엄청나게 나는 것이다.

 

셋째로 그들은 그들만의 인맥 네트워크를 만든다.

유대인과 화교의 공통된 특성이 위에 언급된 바와 같이 어렸을 때부터 그들만의 네트워크를 만든다는 것에 있다.

유대인 다큐를 자세히 보면 알겠지만, 어렸을 때 어린아이들끼리의 모임을 지속적으로 하게 만든다.

세계 각국에 살고 있는 유대인들이 모여서 하나의 캠프를 조성하여 서로의 생각을 공유하고 인맥을 형성하며 성인이 된 후에도 서로간의

연대를 끈끈이 만들어 놓는다. 그리하여 필요한 시점에서 적당한 사람들이 필요할 때 그들의 네트워크를 활용하여 문제를 타계해 나간다.

이것들은 다른 민족들이 쉽게 넘볼 수 없는 중요한 자산이다. 오랜 시간에 걸쳐서 지속적으로 만들어진 그네들의 특별한 연대감은

자칫 잘못하면 시기심을 불러일으킬 수 있으나 그네들은 그네들만의 노력으로 이러한 네트워크를 만들어 시기 적절하게 활용할 줄 안다.

 

넷째로 그들은 문화를 지키고 타 문화를 배제하는 습성이 있다.

다른 문화와 융합하지 않는 다는 것은 다른 문화의 사람들이 봤을 때 탐탁지 않은 행동으로 보일 수 있다.

하지만 그들은 그들의 문화를 지키고 계승함으로써 위의 모든 것들에 대한 기반을 만들어 놓는다.

탈무드와 화교의 종교, 가족문화를 소중히 함으로써 연대감과 소속감을 고취시키고 자신의 위치를 자각하게 만든다.

 

내 생각을 옮기는데 그리 익숙하지 않아. 충분치 않을지라도 내가 생각하는 화교와 유대인의 성공학적인 측면에서 봤을 때 공통점은 위와 같다.

함부로 범접할 수 없는 자신만의 리그에 집단의 공동의식을 공유함으로써 더 단단해 지고 더 거대해지는 특성이 있다.

그들에게서 배워야 할 점들은 익히고 실행해야 그들의 리그보다 더 큰 위대함을 발 위 할 수 있을 것이다.


WRITTEN BY
Peter Ryu
Crazy Programmer's World

,

작은 게임 개발 업체의 팀장입니다.

약 5년간 지금의 회사를 다니면서 작년부터 야근을 거의 없애다 시피 했습니다.

물론 저 혼자의 노력은 아니고 사장님부터 전 직원이 모두 합심해서 이뤄낸 결과지요.

그 과정을 잠깐 설명 드리겠습니다.

 

우리 회사의 경영진은 개발 업무에 대해서는 전혀 모릅니다.

그래서 개발 담당 이사를 빼곤 개발에 관한한 전혀 간섭하지 않습니다.

그런데 사장님이 어느날 그러시더군요.

"다들 죽어라 일을 하는데 왜 우린 예정일도 못 지키고 만드는 것 마다 버그 투성이에

결과물에 대한 평가도 만족스럽지 못할까?"

다시 말해서 대체 열심히 일을 하는건 알겠는데 왜 성과가 없는거야?라는 거겠죠.

각 팀 팀장들이 이런 저런 이야기를 합니다.

그래서 사장님이 지시를 내렸습니다.

예정일을 지킬 수 있는 작업 프로세스 먼저 제시해봐라.

팀장들이 모여서 논의를 한 결과 다음과 같은 분석이 나왔습니다.

 

첫째,

개발 계획이 바뀌면 바뀐 순간부터 전체 예정일은 다시 산출해야 한다.

 

개발 담당 이사가 주로 일정을 잡는데 이사의 판단에 따라 개발 순서가 바뀌는 경우가 종종 있었습니다.

이 과정에서 많이들 헷갈리시는데 예를 들어서 A라는 3개월짜리 컨텐츠 개발 진행 중 2개월이 지나서 중단하고 B 컨텐츠를 만들면 다시 A컨텐츠를 개발하는데 1개월이 걸릴거라고 생각합니다.

천만의 말씀입니다.

B 컨텐츠로 인하여 게임 구조가 얼마만큼 바뀌었는가에 따라서 A는 개발 기간이 달라집니다.

그리고 처음부터 다시 만든다고 생각하지 않으면 어느 부분에서 버그가 나올지 아무도 예측 못합니다.

즉, 뭔가를 추가하거나 변경하고자 한다면 계획을 끝내고 다시 계획을 잡아서 진행해야 합니다.

그런데 게임 뿐 아니라 대부분의 IT 업계에서는 그렇게 안 합니다.

이 부분을 사장님께 이야기 드렸더니 앞으로는 무조건 승인된 것 먼저 완료 한 이후에 다시 계획 잡아서 진행하는 것으로 결정하셨습니다.

 

둘째,

개발과 테스트, 그리고 디버깅에 대하여 각각 일정을 별도로 잡아야한다.

 

아주 단순하게 스킬 하나를 만드는걸 예로 들어 보죠.

기획이 나오고 기획팀은 완료 보고 합니다.

기획서를 보고 프로그래밍 하는 동안에 그래픽 리소스 나오고 그래픽팀도 완료 보고 합니다.

그래서 다 얹어서 구동합니다.

구동 완료 되는 것을 보고 프로그램팀은 완료 보고 합니다.

전 팀이 다 완료 보고 했지만 업데이트는 못합니다.

왜? 그래픽 싱크가 안 맞고 밸런스 수치도 이상한데다가 가끔 클라이언트가 튕깁니다.

사장님은 묻습니다.

다 작업 끝나다면서 왜 업데이트 안돼?

그래서 다음부터는 개발과 테스트와 디버깅은 모두 각각의 일정을 잡기로 했습니다.

 

셋째,

일정은 개발자가 잡되, 일정내에 못 마칠 경우 야근을 하든지 집에서 하든지 개발자 스스로 잡은 일정에 대하여서는 책임진다.

 

마케팅팀에서 기획서가 나오면 한마디 합니다. 이거 3주면 만들지? 테스트 1주 하고 디버깅 1주하면 5주니까 넉넉잡고 1달 반 뒤에는 업데이트 할수 있겠지? 그럼 2주후부터 마케팅 준비하면 되지?

기획서도 제대로 검토 안해보고 답할수 없죠.

당연히 검토 해보고 대답하겠다고 합니다.

그러면 팀장회의에서 지랄합니다. 능력없는 팀장 되는거 한순간이죠. 울며 겨자먹기로 알겠다고 합니다.

팀원 모아놓고 기획서 검토 들어가면 택도 없는 일정입니다.

방법 없죠. 팀장 권한으로 야근 지시합니다.

이런 악순환을 끊어야 된다고 이야기 했습니다.

사장님께선 테스트 끝나고 업데이트 준비되면 그때부터 마케팅 계획 잡는걸로 하라고 하십니다.

 

넷째,

기획은 기획자가 하고 기획서 검토는 실무진이 한다.

 

어느날 이사 중 한명이 팀장회의에서 이야기 합니다.

어느 게임에서 어떤 컨텐츠 업데이트 했더니 대박 났댄다 우리도 만들자.

기획은 그냥 갖다 배끼랍니다.

기획팀은 별 고민 없이 기획 합니다.

개발팀도 별 고민 없이 개발 합니다.

그래픽팀은 죽어납니다. 세계관도 없고 배경 설명도 없이 그냥 만들라고 하니 만듭니다.

테스트 해봤더니 재미 하나도 없습니다.

재미있게 하려면 다른 컨턴츠와 연계 방안을 찾아야 되고 몇가지 보조 시스템도 만들어야 됩니다.

배보다 배꼽이 더 크게 생겼습니다.

개발까지 끝냈는데 업데이트는 언제할지 모릅니다.

게임을 제일 잘 아는것은 기획자입니다.

게임이 어떻게 되어야 하는지는 그래서 기획자가 결정해야 됩니다.

사장님께서 이야기 들으시더니 기획단계를 두단계로 나눠서 컨텐츠 설명위주의 기획서 초안을 만들어 브리핑 하고 팀장회의에서 충분히 가치가 평가되면 그 다음에 개발에 들어가도록 하자고 하십니다.

 

마지막,

일정 중 테스트와 디버깅은 무한정 할 수 없으니 최대 기간을 정한다.

 

사장님이 위의 이야기를 다 결정하시더니 한마디 하십니다.

개발 한달하고 테스트 석달에 디버깅 반년 이렇게 잡으면 다른 부서에서는 아무것도 계획할 수 없게 되니까 테스트 및 디버깅의 최대 기간은 반드시 고정해야 된다고 하십니다.

그 이내에 끝내지 못하면 귀책 사유를 찾아서 그 팀에 불이익을 주겠다고 하십니다.

최종적으로 조율된 것은 개발기간의 절반을 추가로 테스트와 디버깅에 사용하는 것으로 확정 지었습니다.

즉 6개월 개발하면 3개월 이내에 테스트와 디버깅을 마치는 것이죠.

 

위와 같이 결정된 이후 3개월간은 야근이 더 늘어났습니다.

팀간 업무 협의 과정이 원활하지 않은것도 있었고 개발자들이 개발 기간 산출을 잘못한 경우도 많았습니다.

그리고 다음 3개월간은 야근이 점차 줄더군요.

그러더니 올초 들어서는 평시 야근은 완전히 사라졌습니다.

 

물론 사안에 따라 야근을 하거나 주말 출근을 하는 경우는 종종 있습니다.

그러나 한 개인으로 놓고 보면 야근은 한달에 1일 이내 정도이고 주말 출근은 5개월 동안 두번 있었습니다.

 

 

-----------------------------

 

야근을 해야 하는 원인은 아마 회사마다 다를겁니다.

그러나 그 원인을 찾아서 해소하는데에 전 직원이 다같이 노력해야 되는 것은 모든 회사가 같을 겁니다.

 

야근을 없애는 과정에서 개발이 무척 더디게 진행되는 것 처럼 보여서 6개월간은 정말 답답했습니다.

그 답답함 때문에 혹시 회사가 망하는 것은 아닐까 불안하기도 했습니다.

그러나 그 과정을 겪고 나니까 정말 잘 했다고 생각됩니다.

 

야근을 바꾸고 나서 얻은 것은 다음과 같습니다.

 

1. 일정을 잡을 수 있게 되었다.

2. 자신의 작업 결과물을 다시 분석해 볼 여유가 생겼다.

3. 왜 작업을 해야 하는지에 대한 분명한 이유를 공유하게 되었다.

4. 회사에 대한 애착이 생겼다.

5. 연애를 시작하는 사람들이 늘었다.

 

회사를 아끼고 사랑하신다면, 그리고 그만한 위치에 있으시다면,

야근을 없애는 것에 대하여 깊은 고민을 해보시기 바랍니다.

 

리더쉽에 관한 강의를 받던 중 다음과 같은 말이 깊이 와 닿더군요.

 

"문제가 생겼을 때 그 문제를 해결하는 방법은 문제가 생긴 사람이 가장 잘 알고 있다."

 

"리더쉽이란 가르치거나 이끄는 것이 아니라 앞으로 나아갈 방법을 찾을 수 있게 해 주는 것이다."


출처 : http://bbs4.agora.media.daum.net/gaia/do/agora/participant/read?bbsId=C001&articleId=9247&issueBbsId=I001&issueArticleId=32&RIGHT_DEBATE=R9



WRITTEN BY
Peter Ryu
Crazy Programmer's World

,