회사 블로그를 안쓰다보니.. -_-;; 쩝... (걍 폭파시켜 버릴까?)

뭐 암튼 전체 일정들입니다.

1. 문제정의(끝!)
2. 사람(관찰과판단분리, 비폭력대화, 사람관찰하기, 클린랭귀지, 코칭방법, 화내기 등 끝!)
3. 커뮤니케이션 일반 (Wiki, Jira, SVN, Email 등 회사시스템 사용법 교육, 1일)
4. 기획 (시장분석, 고객정의 1일)
5. 설계와 계획 (OOP, UML, 추정계획 등 2주)
6. 개발 (Unity3D 일반, Physics, Partical, Animation 등 2주)
7. 릴리즈 (IIS, PHP, MySQL, 1주)
8. 개발관리 (형상관리, 진척관리 2주)

헐.. 언제 이걸 다 갈키나.. T_T

어제부터 소비자에게 무엇을 만들어 드릴까요? 라고 Facebook에다가 물어보았습니다.
"무엇을 만들어 드릴까요?"는 소비자들에게 너는 이런게 필요해!라고 하는 생각을 무엇을 원합니까?로 바꿔생각해본 겁니다.

제가 개발하면서 고통스러워 하던 수많은 것 중에 하나는 "윗 상사의 고집이나 아집으로 만들어진" 혹은 "고객의 고집이나 아집으로 만들어진" 수 많은 날밤을 새면서 기껏 만들어 놨는데 안쓰는 기능에 대한 반성이기도 합니다.

만 하루만에 3건의 Feedback을 받았네요.

젠가, 블루마블같은 모노폴리, 푸에르리코 등 제가 모르는 게임도 있었습니다.

블로그 방문자분들께도 여쭙고 싶어요.

"재미있게 하신 보드게임이 있으신가요? iPhone용 App으로 만들어 드립니다. ^^"

* 물론 저희 자원이 허락하는 순으로 우선순위 두고 만들겁니다. ^^;
 

미국이나 한국이나, 개발은 Dog's feet으로 하는 듯...

이후 안되는 영어 동원 제럴드 와인버그 님께 댓글을 달자...

이하는 Gloridea 님이 번역해주신 글입니다. (만쉐~)
어느 국가, 어느 문화를 막론하고 개발자나 테스터에게
가장 귀한 자산은 현명한 고객이다.
그 다음은 무식하고, 그 무식을 숨기려 하지 않는 고객이다.
가장 나쁜 자산은 어리석고 무식하면서도 모든 걸 아는 체 하는 고객이다.
그런 사람은 무슨 수를 써서라도 피해라.
규칙은 그에게서 당신을 보호하지 못한다.

-_-;;; 넹!!!

요즘 회사를 하나 만들고 (아직 개인사업자입니다. 세율이 유리해서.. ㅋ) 컨설팅과 개발, 게임 기획, 목업디자인, AC2수강에, 교정보고 있던 요구사항 탐험은 드디어 1단원이 컨펌났구요. 일나가시는 사모님대신 딸아이 등원과 하원을 책임지고 있지요.

혼자서 이일 저일하다보니 놓치는 일이 많습니다.
오늘만 해도 AC2 1:1 코칭을 놓쳤죠.

그런데, 일이 재미 있습니다. -_-;; 미치도록 하고 싶었던 일이었기 때문일겁니다.
아마도...

초기에 사업을 할건지 장사를 할건지 많은 고민이 있었는데, 네트워크를 통한 사업은 내 물건 만들어 파는 장사와는 다른 역량과 조직이 필요해 결국은 장사하기로 하고 그럼 뭘할까? 고민했었는데, 결국 SI를 빼고 제일 잘하는 게임만들기에 미친듯이 달려 오늘까지 1주 정도의 시간끝에 드디어 누군가 오면 작동하는 게임으로 이런거예요~! 할 수 있는 수준이 되었습니다. ㅋㅋ

아마도 작년쯤 필라델피아에서 본 1인 모바일폰 게임 개발자를 보면서 저도 모르게 그분과 같은 길을 걷고 싶다고 생각했나봅니다.
그런데, 일을 하고나니 개발일은 이리저리 공부하면서 혜쳐나갈 수 있는데, 디자인이 문제더군요.
글타고 디자인만 붙잡고 되지도 않는 센스를 발휘할 수도 없는 일이고...

아무튼, 겨우 겨우 우케 우케 해서 디자이너 이슈는 어느정도 해결될 기미가 보이고, 음악감독 섭외하고 암튼 종종걸음치면서 겨우 한발짝씩 나아가고 있습니다.

하지만, 가장 어려운게 주변의 시선입니다.
솔찍히 저는 나름 큰 조직에서 인정받던 PM이었습니다.
기술을 알고 있었고, 영업도 됐으며, 딜리버리에 대한 무한 책임감을 가지고 일했지요.
그런데, 갑작이 작은 회사를 차려서는 레드오션인 게임만들겠다고 하니까 주변에서는 난리도 아닌 이야기가 오고 갔습니다.
그걸 왜하냐?라는 분부터, 작게나마 모마일 게임사의 지인들을 만나서 이렇게 저렇게 알아봐주시는 분까지...
그럼에도, 주변에서는 이해를 할 수 없다는 뉴앙스를 풍기시더군요.

그게 가장 힘들었습니다. (현재까지는...)

하지만, 생각해보면 대기업에서 인정받고 잘 사는길만이 있는 걸까요?
대기업에서 잘 사는 길과 작은 벤쳐부터 천천히 성장해가는 길 중에 무엇이 더 어려울까요?

아직까지의 제 경험상 대기업에서 살아남아 팀장달고, 상무달고, 사장되는게 더 어렵다고 말씀드리고 싶어요.

제가 속해 있던 팀은 많을때는 60명 가까이, 작을때는 10여명이 되었는데 지금까지 모신 팀장님만 5분 정도였습니다.
임기가 약 2~3년 정도 되셨으니 근 10년의 세월을 보낸 훈장 정도되지요.
그런데, 팀장되기가 정말 어렵습니다. 비슷한 또래에서 뽑는 장교진급시험이 오히려 쉬울 정도지요.
능력이 출중하면 대리도 팀장하는 시절이 있었지만, 인원이 많아지고 처음보시는 분이 회사로 오셔서 팀장하시기도 하고 오히려 그 속에서 아둥바둥 팀장달려고 온갖 방법을 다 피는 사람이 쫒겨가는 걸 몇번이나 보았습니다.
팀장이 되면 상무다는건 또 쉬울까요? 외부 영입이라는 아주 좋은 수단이 있는데...
결국, 청춘 다 받치고 남은건 퇴직금 몇푼 쥐고 40대 중후반쯤 쫒겨나가거나 다른 회사 일자리를 알아보는게 "대기업인"의 모습이었습니다.

대기업이란 처음에는 안락한 요람이 되어 주지만, 그 요람에 있는 누군가를 위해 결국 자기 몫이상의 돈을 벌어와야 하는 구조입니다.
하지만, 벤쳐는 아니지요. 사장도 요람에 있을 수 없습니다. 계속 뛰어다녀야 하고 개발도 합니다.
다시말해 요람이 없으니 자기 월급 정도벌면 쉬엄쉬엄 다닐수 있다는 이야기가 되지요.

더 신기한건 지금까지 경험으로는 이 바닥에서 벤쳐로 시작해 망하는 회사는 극히 드물었습니다.
오히려 회사가 커져서 망하지요.
회사가 커지면 요람이 자연적으로 생깁니다.
직접적인 생산업무를 하지 않는 사람을 위해 더 많은 돈을 벌어야 하는데, 그게 쉬운일이 아닙니다.
결국 투자라고 하지만, 한 방 투자가 회사를 문 닫게 하던가, 아니면 천천히 고사되어 죽어갑니다.
경영적 판단 미스는 이래서 위험합니다.

이러한 경영적 판단 미스를 제외하고는 무리한 투자금 유치 또는 차입금으로 망하는 사례를 보았지요.
결국 욕심부리다 망합니다.

제가 게임업계에 뛰어든 이유는 간단합니다.
게임업계의 지각이 서서히 변하고 있다는 현상을 피부로 느끼고 있었기 때문입니다.
닌텐도나 소니와 같은 사업모델은 앞으로 살아 남기 힘들거라 생각했습니다. 예를 들어 몇 년전 고객사에서 SD-CARD로 게임을 유통하는 시스템을 구축한다는 이야기를 듣고는 다른 분께 그 프로젝트를 그대로 넘기기도 했습니다.

유통의 채널이 더이상 오프라인이 아니기 때문입니다.

앵그리버드를 만든 게임사도 52개의 모바일 게임을 만든끝에 대박을 터트렸지요.
하지만, 이게 더 쉬울까요? 아니면 대기업에서 사장되는게 더 쉬울까요?

지금 대기업에 입사하기위해 열심히 노력중인 다른 분들께 이런 이야기를 해드리고 싶습니다.
"자신있으시면 글로벌에서 한판 뜨자"라고...

저희는 올해 3종의 게임을 출시할 예정입니다. 그리고 내년 6종을 더 출시해서 총 9개의 라인업을 만들려고 합니다.
9개 중 하나라도 수익이 안나면 모를까 굉장히 매력적인 시장이 눈앞에 있음에도 모두가 애써 눈감고 귀 닫고 있는 현실이 너무 애석하고 안타까워서 몇 글자 적어봅니다.


참고 : http://www.231games.com/tag/%ec%a0%84% ··· 5aa%25a8

지난 시간에 USE CASE를 Activity Diagram으로 전개시키고 이를 다시 세분화하여 추정견적을 냈었다.
그러면서 다음과 같이 규모산정을 하였다.

우리가 산정한 안내를 받는다는 기능은 총 110.9 FP이다.

여기서 잠깐, 위의 챠트는 잠시 잊도록 하자. 먼저 생각해봐야 할 것은 "이 일은 몇명이서 얼마간 일해야 생각했던 기능을 모두 구현할 수 있을까?" 이다.

마치 밥이 한공기 있는데 몇 숟가락 떠먹어야 다 먹을수 있냐?라는 질문과 본질적으로 같은 질문인것 같다.
이를 공식화하면 간단하다

먼저 밥숫갈횟수 = 밥한공기용량/밥숫갈용량, 따라서, 전체 시간은 = 밥숫갈횟수*한숫갈당 씹는시간
물론 소화시간까지 계산한다면 "밥숫갈횟수*한숫갈당씹는시간+소화시간" (이건 잘 기억하자. 다음은 이 단순한 원리로 우리가 알고 있는 상식을 한번 깨보겠다.)

나는 WBS(Work Breakdown Structer)를 협오하는데 그 이유는 바로 Activity와 Due Date, 담당자로만 설정하기 때문이다.
거기다가 2Weeks이상 어떤 Activity 가 길어지면 안된다고 강제하고 있다.
물론 더 쪼게라고 이야기하고 있기는 한데 이거 하나 마음에 든다.
하지만 WBS는 다음과 같은 치명적인 오류가 있다.

첫째, 업무의 규모는 안보인다. 단지 보이는건 업무와 할당된 개발자, 종료일이다. 그게 어렵든, 쉽든 일단 2Weeks이내로 일정을 잡으면 소프트웨어 공학론자 눈에는 합리적으로 일정을 배분한것이 된다.
다시말해 위에서 계산한 "밥한공기의 용량"은 배제되는 것이다. 거기다가 SI 업계는 급하게 모인 개발자의 생산성을 모른다. 따라서, 밥 한숟갈의 용량도 알수가 없다. 즉, 밥한공기의 용량도 모르고 밥한숟갈의 용량도 모르는데 일단 밥먹는 시간은 설정된다.

둘째, WBS는 통제도구이다. "Critical Path"라는게 있다. WBS를 제대로 사용하려면 이 "Critical Path"라는 큰 줄기가 제대로 진척되고 있는지를 살펴야 한다. 그러나, 수 많은 고객을 포함한 감시/감독자들은 WBS의 모든 부분을 가지고 트집잡는다. 논쟁은 논쟁을 낳고 책임은 변명을 낳는 상황이 반복된다. 이말이 사실인지 아닌지를 보려면 WBS를 누가 원하는지를 보거나 기억해 내면 된다. WBS는 고객 또는 PM, 감리가 요청하는 문서이다.

셋째, 몇 개월에 달하는 WBS에 따른 일정 및 업무량을 100% 맞출수 있다면 그 사람에게 1억을 주라. 왜냐하면 그 사람은 로또 번호를 눈감고도 맞출 사람이다. 이말이 와닿지 않다면 이글을 읽는 걸 멈추고 당장 앞으로 10분이후 혹은 1시간 이후 혹은 4시간 이후에 자신이 뭘하고 있을지 상상해보자. 결코 일반 범인들은 10분뒤를 알 수가 없다. 이 포스팅을 시작한게 약 2시간이 흘렀는데 나는 30분 정도 쓰고 말겠다는 생각으로 시작했지만 중간 중간 이벤트가 발생하고 불려다니면서 이미 계획된 일정의 4배를 소모하고도 글을 다 쓰지 못했다. 그런데 몇 개월간의 2Weeks로 쪼게진 업무를 예측하고 계획하라고?

결론적으로 이러한 정형화되고 고정된 형태의 계획은 인간을 못살게 구는 압제의 수단이다.
따라서, 계획은 이렇게 세우는 것이 합리적이다.

1. 가장 먼저 해야할 일은 개발팀의 생산성을 측정해야 한다. 만약 이게 안된다면 연구자료를 참조하자.

물론 다른 자료도 만들 수 있겠지만 개발시 Prototype을 만들어 봄으로써 팀의 평균 생산성을 측정기록할 수도 있다.
여기서 중요한것은 최소한 한숟같의 용량을 측정해야 한다는 주장이다.
((절대 개인이 아닌 개발팀이어야 한다. 개인을 측정하고자하면 그건 또하나의 압제의 수단을 만들 뿐이고 팀웤에 도움이 안된다. 예를 축구 선수는 골로만 평가 받지 않는다. 팀의 기여도 등의 평가 기준이 있는 것이고 아무리 골을 잘 넣어도 혼자 11명을 상대로 할 수 있는건 없다. 개발도 마찬가지다. 고객의 숫자는 항상 개발팀의 숫자보다 많다. 급조한 개발팀이 단시간내에 으쌰으쌰해서 고객을 압도할 수 없기 때문이다.)

2. 정보공학에서 이야기하는 2Weeks는 지켜주자. 왜냐? 근거없는 관습이지만 2Weeks가 넘어가면 관리 한계가 드러나는것 또한 사실이다. (물론 내 경우는 1일이 넘어가면 관리한계가 발생한다.)

3. Critical Path를 먼저 설정하자. 흔히 마일스톤이라는 것으로 표현하면 된다.

암튼 다시 원점으로 돌아가 전체 규모는 110.9이므로 첨부된 파일에 있는 2003년 이후의 개인 생산성인 18FP로 나누자.
그러면 총 6.16 이나온다. 즉, 6.16 M/M가 투입되어야 구현이 가능하다는 이야기이다.
물론 사전 공부가 필요없는 전문가에 대한 이야기이다.
프로토타잎도 만들필요가 없는 전문가에 대한 이야기이다.
암튼 왠지 모르겠지만 어디서나 통용되는 2:8법칙을 적용하여 6.16은 개발 최소기간의 80%로 설정하면 6.16의 25%인 1.23을 버퍼로 추가해서 총 개발기간은 7.29가 되고 학습기간을 고려하면 고정 투자비용 1개월+7.29M/M가 투입되어야 개발이 가능하다. (물론 지도데이터나 음성 데이터등 관련 데이터가 모두 존재한다는 가정이다.)

따라서, 계획은 "Activity Diagram을 보며 업무를 Breakdown할 수있다. + 개발계획은 교육 1개월 + 7.29M/M의 투입이 필요하다."는 간단한 진실로 마일스톤을 그릴수 있는 것이다.
* 다음 그림을 다시한번 상기해보자.

기능 구현업무는 다음과 같이 나열하였었다. (3부에서)

- 초기화는 단순 입력만 이니 EI/ILF
- 목적지이름조회, 목적지주소조회는 EQ/ILF
- 주소목록선택, 목적지목록선택은 EI/ILF
- GPS좌표를 획득하는건 외부 시스템 연동으로 EIF
- 경로획득은 ILF
- 현재좌표획득은 EIF
- 음성안내는 EQ/ILF
- 현재지도갱신 EQ/ILF
- 안내종료는 EQ/ILF

이를 다시 정리하면 다음과 같다.

1. Milestone (예제)
- 개발자교육 (1M)
- Prototype (0.5M)
- 개발구현 (7.29/개발자수)
- 배포 (개발구현완료후)

2. 상세일정
- 개발자 교육 내용 및 추정기간
- Prototype 내용 및 추정기간
- 개발구현 내용 및 추정기간
- 배포 내용 및 추정기간

* 개발구현 상세일정 예제

다시말해 추정기간은 시간이라는 자원을 얼마정도 쓸지 예측한다는 의미이다.
이러게 자원소요계획을 수립하고나면 Milestone을 더 짧게 쪼게서 Iteration을 적용할 수 있다.
예를 들어 개발자 교육이 1개월 걸린다면 짧게 1주일씩 나눠서 4번 반복 할 수 있다.

Iteration1 - GPS시스템이해
Iteration2 - 앞 교육과정 요약 및 네비게이션의 이해
Iteration3 - 앞 교육과정 요약 및 경로추출
Iteration4 - 앞 교육과정 요약 및 음성안내

이처럼 가장 중요하다고 생각하는 내용을 앞에 배치하면 전체 교육기간동안 총 4번의 반복을 통해 피교육자의 이해도를 높일수 있는 장점이 있다. 개발도 마찬가지이다. 가장 중요하다고 생각되고 광범위하게 참조되는 부분부터 Iteration1에 넣어두면 Iteration2를 통해 확장할때 Iteration1에서 개발한 핵심 엔진은 기능확장과 안정화를 거치게 된다. 그리고 또 한번 열게됨으로써 개발자가 코드를 더 친숙하게 여길 수 있는 기회를 준다.

아무튼 이렇게까지 Milestone과 시간사용계획을 짜놓았다면 이제 할 일은 각각의 조직의 역할을 정의하는 일만 남았다.
반드시 CASE by CASE로 짜놓자.
예를 들면 다음과 같이 짜놓는 것이 중요하다.

1. 요구사항 수행절차
 가. 요구사항을 JIRA에 등록한다.
 나. 요구사항은 고객과 개발팀의 협의체에서 우선순위를 조정하여 XX기준(일정 또는 범위 또는 업무량 등등) 으로 상위 OO개를 수행한다.

이렇게 개발공정에서 발생할 수 있는 CASE를 예상하고 각각의 조직과 개인이 해야할 일을 명시해놓고 개발 프로세스에 적용하자. 그래야만 혼란을 미리 막을 수 있으며 Prototype 개발 기간동안 의미있는 데이터를 획득할 수 있다.

암튼, 가장중요한 것은 계획은 계획일 뿐이라는 거다.
계획을 함으로써 앞으로 발생할 일에 대한 자원(인력, 돈, 시간 등)의 소모와 만약(if)에 대한 시나리오를 검토할 수 있는 기회를 준다.

마지막으로 각각의 Iteration에 대한 계획은 나중에 다룰 기회가 있으면 또 한번 다뤄보자.

어쩌다 규모산정을 한 김에 달리다보니 계획까지 와버렸다. -_-;;
어쩐지 진도를 다 못나간 느낌이다. 다음에는 다른 영역으로 진도를 나가보자. -_-;;

일주일쯤 됐나? 암튼 UML 개발강좌 2편이다.
먼저 다음의 그림에 주목하자.
요구사항은 인수테스트로 검토/테스트 되어야 하며, 고수준의 설계는 통합테스트로, 세밀한 스팩정의는 유닛테스트로 검토/테스트되어야 한다.
UML이 아무리 용빼는 재주가 있다고하더라도 이러한 Software Development Life Cycle을 빗겨갈수는 없다.

왜 그럴까?
우선 요구사항이라는 녀석의 존재 때문이다. 요구사항은 어디서 오는가? 너무 당연한 대답이지만 요구사항은 고객에게서 온다.
우선 고객의 특징을 살펴보면,

1. 고객은 단위업무전문가일 경우가 많다. 물론 예외는 존재한다.
2. 고객은 기술적으로는 문외한 일경우가 많다. 아무리 과거에 기술에 몸담았다고 해도 "지금"이라는 시점으로 짜르면 문외한 인건 똑같다.
3. 고객은 자기가 원하는 것을 표현하기 어려워 한다. 특히, 한국은 체면때문에 더 힘들어 한다.
4. 고객은 결국은 돈주는 사람이다.

즉, 고객은 요구사항을 내고 개발이 끝난뒤에 요구사항 대로 개발했는지 검토한후에 그 댓가를 지불하는 사람이다.
그런데, 여기서 문제가 발생한다. 결론부터 말하자면 우리의 좌뇌가 문제이다.
좌뇌는 논리와 언어를 담당하고 우뇌는 감성과 직관을 담당한다.
우리가 누군가에게 말을 하는 이상 좌뇌를 통할 수 밖에 없으며 좌뇌는 다음과 같이 "자동차를 만들어주세요."라고 하지만 우뇌는 어떤 그림을 상상하고 있을 것이다. 아마도 다음의 그림과 같지 않을까?
1. 고객
좌뇌 - 차를 만들어 주세요.
우뇌 - 2. 개발자
좌뇌 - 차를 만들어 달라고 하는구나.
우뇌 -
좌뇌는 똑같은 이야기를 하고 있지만 우뇌는 서로 다른 이야기를 하고 있는것이다.
그러나 우리는 우뇌에서 그린 이미지를 물질세계로 끌어내어 형상화한다.
그래서 우리에게는 말이 아닌 그림이 필요하며 그림을 간략하게 그리기위해 Diagram이라는 도구를 사용하는 것이다.
따라서, UML은 다음과 같이 정의할 수 있다.
"UML은 의사소통의 도구!"
따라서, UML을 자세히 그릴 필요성이 없다는 결론에 도달한다.
자세히 선이 어쩌구요, 뭐가 어떻고 따진다고 한들 그것이 코드로 그대로 반영되는것도 아니지 않는가?
그냥 문자로 되어 있는 요구사항을 Diagram으로 표현한것이 UML의 첫번째 "Use Case"이다.

USE CASE의 정체를 떠들다가 보니 벌써 이렇게 길어지고 말았는데 그 정체를 이렇게 장황하게 설명하는 이유가 바로 정체를 제대로 알아야만 정확한 선이 어쩌고하는 논쟁으로부터 벗어날 수 있으며 어느 정도의 수준으로 Use Case를 나눠야 하는지 기준이 서기 때문이다.
결론부터 이야기하자면

첫째, USE CASE는 요구사항의 집합이다.
둘째, USE CASE는 인수시험으로 검증될 수 있어야 한다.

위의 2개의 기준은 매우 중요한 개념이다. 밑줄 쫙쫙 긋고 머리속에 박아넣고 있어야 하는 개념이다.

이제 우리가 그리기로 했었던 "3D Navigation"의 USE CASE를 그려보도록 하자.

1. StarUML을 실행하고 "Default Approach"를 클릭

2. 이제 USE CASE를 그릴차례 우측 탐색창에서 <<USE CASE MODEL>>을 더블클릭하자
좌측에 도구함에는 Use Case에 사용되는 도구가 뜬다.

우리가 사용할 도구는 UseCase와 Actor, Association, System Boundary 정도이다.
붉은 박스외에 다른 모델들은 나중에 기회가 되면 설명하던가 자습을 하던가... -_-;; 뭐 암튼 그리 중요한건 아니다.
(정말로...)

3. 암튼 제한된 도구로 배치해보니 다음과 같다.
Use CASE 하나 하나는 "인수시험 케이스"라는 생각을 가지고 그리게 되면 위와 같이 된다.
물론 다른 생각을 할 수도 있다. 그러나 나는 이렇게 생각한다. 몇가지 설명을 덧붙이면
사람모양인 Actor는 사용자, 관리자, 외부시스템등을 표현한다. 즉, 현재 네비게이션을 제외한 모든 시스템, 사람을 Actor로 표현하는 것이다.
그리고 화살표와 선이 보이는데 이건 관계를 표현한다. "-->" 하든 "--"하든 둘중 아무거나 상관없이 써도 된다.
단지 나는 사용자의 입력을 표현하는 선은 "-->"로 했을 뿐이다.
그리고 설명이 부족한 부분은 Annotaion을 클릭해서 Note와 Notelink를 사용해 추가적인 설명을 붙여 둔다.
이까지 그리는데 5~10분 정도 걸린것 같다. 자랑이 아니라 대충 그렸다는 이야기다.
왜 대충그렸을까?
이 문서는 끊임없이 살아 있는 생명체와 같기 때문이다. 무슨 이야기냐면 "UML은 개정되어야 하기 때문이다."
매번 개정할텐데 힘들게 그릴 필요가 없다는 의미이다.

아무튼 요구사항이 도출되면 이정도까지 그려두자.
다음에는 기능점수(Function Point) 기준 견적에 관한 이야기를 할 것이다.

엥... 윈모7에서는 Winform이 아니라 Silverlight가 기본임? -_-???
암튼 각종 예제 동영상 강의 풍부 : http://msdn.microsoft.com/ko-kr/gg415576

그리고 페이졸드 할아부지의 WM7 개발 가이드 (무료 PDF)
직접 다운로드 : http://www.microsoft.com/downloads/en/ ··· 314a74eb
MS Press의 블로그 : http://blogs.msdn.com/b/microsoft_pres ··· old.aspx

안철수 교수님이 11월 16일 서울 프라자 호텔에서 '2010 대한민국 모바일앱 개발자 컨퍼런스' 기조연설중에 한마디 하신 말씀이 가슴에 와 닿는다.
(Source : blog.naver.com/ckddmlgurtls/40117931167 )

"지난 30년동안 창업회사 중 매출 1조원 이상의 대기업으로 성장한 회사는 웅진과 NHN뿐이고 대기업에 납품한 기업 중에서는 하나도 없다"

대기업에 납품하면 성장에 한계를 겪게 마련이다.
이유는 간단하다 인력 장사의 원가 및 매출액이 유리알처럼 투명하기 때문이다.
그럼에도 SI라는 미명하에 인력장사는 계속 된다. Function Point에 기대를 걸었지만 최근의 업계는 가격에 FP를 때려 맞추는 일이 일어나고 있다. (뜨어...)

이래서 이 바닥이 싫다는 것이다.

MS도 최초에는 MITS, Apple, IBM 등에 S/W를 납품하던 회사로 출발하였지만 스스로의 왕국을 건설하고 이를 바탕으로 비즈니스를 계속 해나갔다.
그러나 MS가 MITS, Apple에 안주했다면 어떻게 되었을까?

그들은 거기에 안주하지 않았고 더 어려운 길을 선택하게 된다.
스스로의 OS를 만들고 개량해갔고 스스로 고객을 만들었으며 일반 대중에게 물건을 팔아 치웠다.
즉, 스스로 물고기 잡는 법을 터득하고 스스로 물고기를 잡았지 누구에게 물고기를 잡아 달라고 하지 않았던 것이다.

이는 어느 정도 시장이 성장함에 따라 나타나는 현상중 하나이다.
일례로 최근 통신사에 BP로 있던 회사들의 행보만 보아도 알 수 있다.
더 이상 통신사의 Sida 생활을 하기를 거부하고 스스로 이제는 먹고 살수 있다는 생각을 한다.
COM2US 만 보더라도 이제는 더이상 통신사 쫒아 다니며 영업하지 않는다.
그들 스스로 선택한 플랫폼에 그들 스스로 선택한 이통망위에서 비즈니스를 하는 것이다.
물론 그들이 가지고 있는 약점은 분명하다.

모바일 케쥬얼에만 집착하고 있기 때문에 조만간 모바일에 메이저 플레이어 들이 들어오면 경쟁력이 약화될 것이 분명하기 때문이다.
(어차피 인생자체가 자전거 타고 오르막 내리막 해야 할 상황이라면 저런 준비를 해야 하는 입장에서 여러가지의 사고 나 케이스 스타디는 분명 도움이 된다.)

결론은 어려운 길을 선택하는 것이 정답일 수 있다는 생각이 든다.

어렵지만 스스로 영업망을 넓히면서 스스로 무엇인가 만들어 팔아야 제대로 된 장사이며 사업이다.
일부 SI회사들이 욕먹는 부분이 바로 이 부분일 것이다.
영업망은 있으되 스스로 무엇인가 만들어 파는 부분이 없다.
이 부분도 분명히 국가 정책 및 회사의 정책과 밀접한 관련이 있다.
몇 백종이나 되는 산출물을 만들라고 하는 것 부터 가격 제한 정책을 쓰는 것까지 온갖 규제는 다 갖다 붙이니 개발자를 유지할 능력이 공룡에게는 없다. 그야말로 1차 산출물인 프로그램이 아닌 2차 산출물인 문서만 양산하는 조직이 된지 오래다.
즉, 머리만 큰 뚱뚱한 공룡에 불과하여 근육이 붙어 있는 것이 없어  뛸 수 있을 때 뛰지 못하고 있는 현실이다.
마치 인간이 자신의 팔과 다리를 사용하지 않고 기계에 의존함에 따라 점차 머리만 발달하고 손과 발은 퇴화되고 몸은 점점 비대해지는 모양이라고 할까?

* Wall-E에서 우리는 익숙한 장면을 보게된다.
결국 살아 남은 머리는 계속 회전하면서 불사의 세포가 되는데 이게 바로 암이라는 존재다.
현재 대한민국의 SI업계는 바로 암에 걸려 있는 상태이다.

건강하게 다시 살아나기 위해서는 위의 이미지에서 저 뚱뚱한 인간이 앉아 있는 "병"이라는 의자를 걷어 차야 한다.
그리고 무한의 에너지를 공급하는 저 시스템 자체가 파괴되어야 한다.

즉, 국가에서 제한하는 가격 정책 자체와 합리화 방안등이 사라져야 한다는 이야기이다.
그래서 시장에 맡겨 버려서 죽을 업체는 죽고 살 업체는 살아야 한다.
억지로 키워진 공룡이 결국 주변의 모든 것을 다 빨아 들이고 나면 그것은 질량의 가중만 거듭하다가 어떤 충격을 받으면 곧 중력에 영향을 주고 주변 사물의 모든 것을 빨아 당겨서 같이 공멸하는 블랙홀이 될 뿐이기 때문이다.

대신 국가는 가격 또는 품질에 대한 제한을 풀고 시장 경쟁을 시키면서 해줘야 할 것이 있다.
바로 지적권에 대한 감시 및 처벌 강화와 더불어 해외에 나가는 SI업계에 대한 지원이다.
이를 통해 비정상적으로 비대해진 SI업계를 다이어트 시키고 건강하게 해외나가서 붙어볼 만한 대표선수를 만들 수 있는 것이다.

이상 몇개월뒤 30대의 도전을 시작하려는 나에게는 이런 환경이 얼마나 좋을까 하는 생각 빡에 없지만.. ㅋㅋㅋ

월요일 새벽 4시.
현재 월요일 오후 고객사 사업팀장님 시연때문에 금욜 오후부터 토욜, 일욜 (특히 오늘은 철야모드) 버닝중이다.
문득 버닝중에 과연 철야 또는 야근이 절대악인지를 묻고 싶어 졌다.

예전의 내 포스팅을 보면 야근에 관련된 이야기가 많이 나온다.
애자일 용어로 Sprint 즉, 스스로 치열하게 일하는 것에 대한 이야기가 많이 나오고 있다.

그럼 꺼꾸로 한번 스스로에게 되물어 보도록 하자.
철야 또는 야근은 절대 악인가?
그리고 프로젝트 기간동안 제일 기억남았던 좋던가 싫은 기억은 무엇인가?

대부분의 개발자는 야근, 철야, 주말근무를 떠올릴 것이다.

그럼 우리가 알고 있는 야근, 철야, 주말근무는 왜 나쁜것일까?

첫째, 개발자 스스로의 건강을 깨트린다. 나역시 아침에 일어나기 힘들고 주말에는 퍼지기 일수이다.
거기다 고칼로리 야식으로 인해 살이 비둥비둥 쪄간다.
둘째, 능률 저하가 발생한다. 어차피 야근하는 문화라면 뭐하러 근무시간내에 일을 마치려 바둥바둥 하겠는가?
어차피 야근이라면 근무시간에 일에 집중하기보다 놀기바빠지기 마련이다. 그리고 이런게 습관화 되면 습관으로 인해 스스로의 인생조차 장담 할 수 없게 된다.

즉, 상시 야근 및 철야, 주말근무는 결국 개발자 나아가 개발팀 더나아가 회사의 장기적 손해를 끼친다.
그래서 나쁜것이 바로 야근, 철야, 주말근무인 것이다.

그럼 왜 이런 좋게 말해 필요악이 발생하는가?
가장 큰 이유는 일정이다.
일정 계획이 무계획, 무기준으로 짜여져서 결국 프로젝트를 지옥으로 빠트리는 상황이 가장 많을 것이다.
그다음이 원가 절감이다.
갑또는 을의 원가 절감으로 인해 절대적 업무량이 많은 경우이다.

그런데 야근, 철야, 주말근무가 반드시 나쁜것일까?
내 생각에는 리더인 PM이 직접 하는 야근, 철야, 주말근무는 필요악이다. 스스로 희생양으로 삼아 고객에게 좋은 점수를 딴다면 그가 이끌고 있는 팀은 어찌됐건 차기 프로젝트를 수주할 확률이 올라간다.
문제는 무능력한 PM이 이끌고 있는 팀은 PM스스로 업무를 처리할 수 없기에 물귀신 처럼 밑에 팀원들 데리고 자폭하는데 그 문제의 심각성이 있다.

이제 야근의 장점을 이야기해보자.
야근을 함으로써 얻을 수 있는 것은 팀원간의 친밀도와 팀웤이다.
짧고 강렬한 경험을 공유하면 그 경험으로 인해 팀원의 팀웤을 일시적으로 상승시킬수 있다.
군에서 고생을 같이 하고나면 전우애가 생기듯이 사회도 똑같은 원리로 이러한 효과를 기대할 수 있는 것이다.

현명한 PM이라면 이를 적절하게 활용해야만 한다.
모든 품질은 정량화에서 부터 시작된다는 이야기를 많이 하였다. 업무가 70% 정량화되어 팀원들에게 할당되면 70% 예측이 가능할 것이다. 즉, 업무를 세부적인 메소드 수준까지 정량화시키고 이를 팀원들에게 할당하면 업무의 우선순위를 정하고 일정기간 그것을 완성하기위해 Sprint하고 그 보상으로 1~2일의 휴가 또는 오후 3시 이전에 조기 퇴근할 수 있는 권한을 준다면 업무의 효율성을 재고할 수 있다.
이건 경험적인 것으로 이러한 보상을 통해 팀웤을 끌어올리면서 업무 효율성을 재고하는 2마리의 토끼를 다 잡을 수 있는 기회이기도 하다.

따라서, 무조건 절대 악이라는 것도 절대 선이라는 것도 없다는 것이다.
최선은 그 사이에 있기 마련인 것이다.

정리하자면
1. 야근, 철야, 주말근무해야 한다면 PM이 직접하라. (리더일수록 팀원에 비해 근무시간이 더 늘어나는것은 당연하다)
2. Sprint 기간을 설정하고 Sprint한 후 그 몇배의 시간 만큼은 정시 출퇴근 혹은 쉴 수 있는 시간을 부여하라.
3. 현재 팀원이라면 자신의 환경적, 신체적, 가정 컨디션을 팀 리더에게 수시로 알려라. (최소한 이메일정도는 남겨야 한다)
4. 이유없는 야근은 하더라도 2주 혹은 3주에 한번 정도로 제한하고 어쩔수 없이 야근하는 경우는 그 자체를 즐겨라.
5. 왠만하면 퇴근할 시간에는 집으로가서 재택을 하자.
가 되겠다.

이번주부터 팀 재건 차원에서 몇가지 일들을 수행하고 있는데 이를 소개 할까 한다.
먼저 오전에 일일 이슈회의를 진행하고 있다.

그날 또는 전날 또는 그 이전에 고객 또는 Risk 를 나열하고 토론하며 팀원들과 업무우선순위를 재조정하는 일들을 진행하는 것이 그 첫단계이다.

나의 일은 서두에 몇가지 생각하고 있는 구두상 요청사항이나 프로젝트 범위나 변경에 영향을 미칠 만한 것들을 찾아 키워드로 화두를 던지면 나머지 팀원들의 이야기를 들어주는 것이 전부이다.

몇주간 방치되었던 팀에서 이런 저런 이야기가 나오고 고객에 대한 불만 등이 쏟아져 나오면 가만히 듣고만 있는 상황이다.
속으로는 "참 내가 못났다"라는 생각과 함께 "내가 지금 잘 듣고 있는가?"와 "팀원들의 감정이 어떠할까?"라는 생각을 한다.

거의 모든 서비스업이 마찬가지겠지만 사람과 사람사이에서 받는 스트레스와 에너지 소모가 생각보다 매우 크다는 생각을 다시하게 되는 계기가 되고 있다.

마지막으로 하는 일은 모든것을 조합해서 오늘저녁 퇴근전까지는 이런일 이런일을 해야 한다라는 합의를 거치고는 다 함께 밖으로 나가서 못다한 이야기 등을 하고 있는데 한 4일정도 지속적인 의견을 교환하면서 팀원들의 생각과 나의 생각을 서로 맞추는 일을 하다보니 근무 의욕이 소폭 상승한 느낌이다.

그리고 또하나 하고 있는것은 USE CASE로만 정의되어 있었던 요구사항의 정의를 User Story라는 이름의 Chart로 재작성하고 있는 일이다.

처음에는 UX관점에서 조금더 Customer Value를 어떻게 올릴까 고민하다가 챠트를 만들었는데 생각지도 못했던 추가 업무들이 나타나고 있다.
차기 프로젝트에서는 초기부터 도입해야 할 듯 싶다.
간단히 예를 들면 이렇게 진행중이다.

Step	User Experience	System Message	Exception/Caution	Exception Message
제품수령	철수는 X폰을 수령하였습니다. 거금 80만원이나 준 최신 스마트 폰입니다. 제품을 수령하고 기쁜 마음으로 포장을 해체합니다.	n/a	포장 해체가 잘안된다. 매뉴얼, 충전기, 소켓 중 하나가 빠져 있다.	n/a 매뉴얼에 고객상담실 연락처를 적어놓는다.
중간생략
앱스다운로드	철수는 앱을 다운로드 받기위해 XXX 버튼을 누릅니다.	환영합니다. 철수님	네트워크가 연결되어 있지 않다. 서버가 죽어있다.	네트워크가 연결되어 있지 않습니다. CDMA통신망으로 연결할까요? 서버가 연결되지 않습니다. 계속 연결되지 않으면 고객상담센터 555-5555번으로 전화주십시오.

* 위의 챠트는 현재 제가 하는 업무와 관계가 없습니다.


먼저 최종소비자의 행동을 묘사하는 순서가 Step 항목이다.
최종 소비자가 제품을 인수받고 설치하고 사용하고 전원을 끄는 등의 시나리오를 주루루룩 기재한다.
그리고 고객의 상황을 소설을 쓴다. 즉, 고객이 경험할 일을 기재하는 것이다.
그리고 정상적인 고객경험에서의 반응을 기록하고
예외사항 또는 에러사항 등의 부정적인 상황을 기록한다.
이후에 어떻게 부정적인 상황에 반응할지를 기록한다.

이렇게 단순한 Chart인데 여러 팀원들과 같이 작성해 나가면서 생각지도 못했던 업무들이 발견되었다.

그리고 이번주의 하일라이트는 시계를 켜놓고 알람을 설정한 일이다.
짧고 퀵하게 하기위해 중간 중간에 몇분 남았다고 주지시키고 완벽하지 않더라고 일단 끝까지 가보자라고 독려하였다.

그결과 합의 과정이 굉장히 빨라졌다.
총 49개의 Step을 점검하는데 4:20분경부터 시작해서 5:10까지 약 50분만에 한바퀴 도는데 성공한 것이다.
내일 또 오늘의 기록을 바탕으로 2차 브레인 스토밍을 진행할 생각인데 내일도 알람 시계를 맞춰놓고 Quick하게 한바퀴 돌아 보고자 한다.