'프로젝트'에 해당되는 글 5건

  1. 2015/02/15 글뻥 Agile / Waterfall 보다 더 중요한것 (2)
  2. 2010/09/05 글뻥 내가 하고 싶은 사업은? (4)
  3. 2010/05/27 글뻥 애자일 경험담 18 (2)
  4. 2010/05/17 글뻥 프로젝트 팀 재건하는 첫발
  5. 2008/09/09 글뻥 프로젝트의 법칙
2007년정도부터 마음속 깊은 빡침을 느낀것이 있다면,
고객이 요구사항을 바꾼다는 것.

"인간 마음이 가지고 있는 메커니즘중 하나인 "식상함"이 가장 큰 원인이라 할 수 있는데..."
(물론 오류가 인지하지 못할 만큼 아주 작게 있다는 전제로... 오류가 있다면 이미 망한거임...)
라고 생각하고 "Agile"을 도입하기 시작하였다.

하지만, 점차적으로 발생하는 문제가 있었으니... 

첫째, CMMI Lv. 4 정도 되는 회사에서 어느 정도 트레이닝이 된 동료들과의 Agile은 그리 어렵지 않은 수준이었지만, 그럼에도 튕겨져 나가는 팀원들이 있었는데, 막상 CMMI Lv. 1정도 되는 조직에서는 Agile이 불가했다. 이는 직무 전문성이 현저히 낮음에 문제가 기인한다.
한명의 개발자를 개발자 다운 개발자로 트레이닝 하기 위한 비용을 무시했던 것이다.

둘째, Agile의 본질은 작지만 수 많은 Try / Fail을 겪으면서 체험적 학습을 기반으로 하고 있는데, 한가지 간과하고 있는 것이 있다면 "직관"이다.
직관이라는 것은 경헙과 학습에서 나온다.

셋째, Agile은 최종형상을 찍고 일하지는 않는다. 잘못하면 목적없이 표류해버리기 쉽다.
교육과 경험의 수준이 다른 사람들을 모아서 공통된 관심사를 끌어내는 것은 궁극적으로 비용이 매우 많이 드는 일이다.

Agile하게 일한다는 것은 커뮤니케이션 비용을 줄이려는 노력이고, 이러한 노력을 하려면 최종형상에 대한 상호이해가 필요하다.
팀으로 일한다는 것에 깊은 회의감이 드는 차에 최근에 모 크레이 애니메이션 회사의 일하는 방법을 보며 조금은 영감을 얻었다.

그 회사의 방침은 어떠한 일이든 "무엇을 만들지 최종형상"을 만들고 일을 시작한다.
이때 사용되는 방법이 Academy 즉, 워크샾이다.

이 회사에서는 약 2주간 어떤 일을 하게될지 모든 구성원들이 모여 워크샾을 진행한다.
구체적으로 형상이 나오면 그것을 다듬는 작업은 구성원들과 함께 모여서 모의 시뮬레이션을 2주간 빡시게 진행한다.
그리고나서 일정을 만든다.

이렇게 써놓고 보니, SK C&C 다니면서 Agile이 잘됐던 이유가 설명되기도 하는데...
그곳에서는 제안서 작업이 떨어지면 통상 1달전부터 작은 방에 모여서 PM과 PL들이 제안작업을 하는데,
이때 플랫폼을 쪼게고 쪼게서 아키텍쳐를 그려놓고 외부도입기술과 자체개발기술을 나열하고 어느 영역을 누가 맡을지 일정과 비용에 대한 견적까지 뽑아낸다.

이처럼 최종형상이 나온뒤에서야 업무에 투입되고 투입된 PL들을 중심으로 프로젝트는 돌아간다.

이때는 Waterfall이든 Agile이든 방법론이 중요해지지 않는다.
다시말해 프로세스자체가 스스로 진화하거나 체화되기 시작하기 때문에 CMMI Lv 4. 정도의 수준으로 일을 할 수 있었다.

중요한건 최종형상에 명확한 Big Picture이다.
그리고나서 어떻게 이걸 맞춰갈지에 대한 상호 협의다.
그 협의 방법이 방법론이라 일켰는 것일 뿐이다.
2015/02/15 15:19 2015/02/15 15:19

참 많은 일들이 있었다.
프로젝트 중간에 한 동료는 고객과 자신의 차이를 인정하지 못하고 떠나게 되었고
한명의 동료는 이제 더이상 같은 회사 직원이 아니게 되었고...
또 한명의 상사는 직장생활 최대의 위기 상태이다.

총 5명의 개발팀원중 메인 리더였던 나는 프로젝트가 끝나가려는 현재의 시점에서 모 애니메이션 회사에서 매일 밤을 세고 있다.

성과도 있다.
신규사업으로 우리만의 팀이 드디어 만들어진 것이다.

부회장님께 보고드리는 자리에서 트랜드 사업으로 앞으로 미래에 이 사업이 얼마나 커질지는 모르겠지만 맨몸으로 두들겨 맞지 않을 자신은 있다고 했다.

윗 상사중 한분은 이 보고후에 팀장으로 정식 발령 나셨다.

프로젝트라는 것은 참으로 무서운 면이 없지 않아 있다.
혹자는 조직에 회의를 느끼고 다른 일을 찾아보고자 했고 혹자는 조직에서 승승장구하기도 한다.

개발팀의 리더로써 처음 퇴사한 친구는 그렇다고 하더라도 인수시험까지만 함께 하기로했던 동료는 못내 아쉽다.

일전에 애자일 초보 강연에서 질문하였던 모 부장님의 말씀이 생각난다.
"애자일 팀은 목표를 달성하지 못했더라도 팀의 건재를 유지하는것이라 생각하는데 어떻게 생각하십니까?"라는 질문이다.

머리속에 다른 이야기가 있었지만 솔찍하게 말씀 못드렸다.
그때의 내 대답은 "우리 SI는 팀이 박살나도 목표를 달성해야 합니다. 그 질문은 나중에 고민해 보겠습니다."라는 것이다.

이 대답은 내가 샛빨간 거짓말이었음을 고백한다.
지금 누군가 다시 물어 본다면 그때의 심정으로 돌아가 이렇게 이야기했을 것이다.
"목표에 따라 다르다고 생각합니다. 그 목표가 전략적 목표라면 팀원을 희생하더라도 달성해야 합니다. 그러나 그 목표가 전략적 목표가 아닌 1term 목표라면 팀원이 가장 우선입니다."

또 옆길로 세서 한국군은 그러하지 않지만 훈련이 잘된 군대는 모름지기 "철수를 잘하는 군대"이다.
뛰어난 장교는 열세의 상황에서 군을 철수시킴에 있어 그 건재를 잘 유지하는 것이 첫번째 임무이다.

비록 공격 혹은 방어에 실패하더라도 다음 작전을 위해 최대한의 인적 자원을 유지하며 집결선에 모이는 것이 바로 훈련이 잘된 군대에서만 볼 수 있는 특징이다.

그 대표적인 예가 장진호 전투이다.
우리는 잘 모르는 "뒤로 공격"하기 작전에서 미 해병대 1사단은 철저한 준비로 만반의 후퇴준비를 하며 공격해나갔다.
미해병대 1사단과 미 육군 7사단 일부병력이 섞여서 북진하다가 중공군 12만에게 포위된 전투로 항공 퇴각을 하면 1개 중대의 경비 중대가 후방을 사수해야 한다는 결론에 다다르자 과감히 항공수송을 포기하고 중공군 12만의 포위를 뚫고 나가 흥남부두까지 도착 주변에서 모여든 타병력 10만과 민간인 10만을 193척의 전투함으로 탈출하였는데...
이때 중공군 7개 사단이 괴멸되고 전체 진공작전의 2주가 지연됨으로써 중부전선에서 미8군이 중공군의 진출을 저지하는데 성공하였다.

10배가 넘는 적병력에 포위당했음에도 그 건재를 유지하며 흥남까지 탈출한 미 해병대 스미스 장군이야말로 진정한 애자일 마스터가 아닐까?

이때 미군 전사 2,500명, 실종 219명, 부상 5,000명으로 미해병 1사단도 전멸에 가까운 피해를 입기는 했지만 그들의 희생으로 인해 중공군은 25,000명 전사, 부상 12,500명으로 미해병 사단 1개를 포위한 댓가치고는 거대한 댓가를 치뤘지만 종국에는 포위 섬멸이라는 전술목표마저 실패하기에 이른다.

전투결과만 놓고보면 누가 포위하고 누가 포위당했는지 모른 전쟁의 결과였다.

사용자 삽입 이미지

그런면에서 나는 이번 프로젝트 참상을 리더로써 겪고 있으며 가슴속 깊이 후회하고 있으며 한편으로는 전략적 목표를 위해 팀원를 희생시킨 나쁜 리더라는 자책도 든다.
어떤면에서 보면 프로젝트 팀원 뿐 아니라 나의 가족도 희생시킨 결과라는 생각도 든다.
그리고 협력업체도 무던히 많이 괴롭혔다.
그 뒤에서는 항상 전략적 목표니까. 전략의 목표만 달성하고 이것만 달성하자. 라는 생각으로 더욱 채찍질 한것도 있다. 그래서 드디어 3년을 꿈꾸던 목표(자기완결적 개발팀의 태동)를 달성하고 이제는 꿈틀 거려 볼수 있는 여건이 조성되었다.

하지만 문제는 산적해 있으며 앞으로 어떻게 나갈지도 막막하다.
목표가 눈에 보일때는 달려나가지만 막상 목표에 도달하고 주변을 둘러보니 방어할 병력이 절대 부족한 상황이랄까..
주변에 지원을 요청해야 하는상황인데 어떻게 해볼 수도 없는 상황이다.

회사에 많은 지원을 달라라는 것으로 시작된 것이 아닌만큼 그 고민이 크다.

그럼에도 패턴을 인식하는 Pattern Recognition Database Engine이 만들어지고 그것을 다른 업무에 적용하기 시작하면 내가 꿈꾸던 새로운 세상이 한페이지 완성될 수 있다는 생각에 더이상의 개발자로써의 꿈은 다 이루게 되리라.

그래서 모든 사람들이 개발자가 아니더라도 자신이 생각하는 이미지를 표현할 수 있는 그런 시대의 첫페이지 또는 첫 문장을 만드는 꿈이 되었으면 한다.

할 수 있을까?

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

그날 또는 전날 또는 그 이전에 고객 또는 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하게 한바퀴 돌아 보고자 한다.

2010/05/27 22:13 2010/05/27 22:13
최근 망가진 개발팀 분위기로 위기감(아마도 혼자만의 위기감?)이 들어 팀 재건을 위해 몇가지 프로세스를 고치고 있다.

가장 먼저 손을 댄것이 커뮤니케이션 활성화.
오늘 오랜만에 흩어져서 고군분투하던 프로젝트 개발팀원들을 소집하여 이런 저런 이야기를 나눴다.

그간에 현장 PM과 본사 사이트 관리자의 업무지시중에 혼란 스러웠던 이야기를 나누었다.
그리고 우리의 목표가 무엇이고 목표(Vision)에 대해 전체 윤곽은 아니지만 몇가지 Point로 커뮤니케이션 하였다.

한편으로는 바쁘다는 핑계로 2주동안 방치하였던 스스로를 반성하였으며
한편으로는 일으켜 세우는데 1달 망가지는데 1주라는 생각도 들었다.

아직까지 머리가 멍한 상태...
현장에서 고객의 요구불만과 채념도 큰일이지만 내부의 커뮤니케이션 갈등도 더 큰 문제로 다가온다.

의욕상실 상태인 팀원들에게 어떻게 하면 잘되는 프로젝트 팀으로 돌려 놓을까?라는 생각도 들고...
일단 순쉬운 것부터 하자.
2010/05/17 11:57 2010/05/17 11:57
한 7~8년 개발하면서 수많은 프로젝트를 수행하며 겪은 나름대로의 법칙이랄까?
뭐 암튼 정리해보자면 이렇다.

1. 내가 안하면 다른 사람이 한다.
2. 내가 안하고 다른 사람도 안하면 결국에는 내가 하게 되어 있다.
3. 이빨로 안할려고 버텨봤자 결국에는 내가 하게 되어 있다.
4. 평소 착하디 착한 PM 화한번 내고 인간 말종 된다.
5. 평소 절라 못되먹은 PM 술한번 사고 신이 된다.
6. 이것만 하면 된다라고 하지만 결국에는 이것만의 몇배를 해야 한다.
7. 아무리 프로젝트 준비를 잘해도 망할 프로젝트는 망한다.
8. 프로젝트 중간에 인력이 왕창 늘어나는 프로젝트는 망하기 직전이다.
9. 얌전한 고객 책상위에 먼저 올라간다.
10. 평소 욕많은 고객 욕심채워주면 얌전해진다.
11. 일정과 범위가 정해진 프로젝트 치고 잘되는 프로젝트 못봤다.
12. 신개념과 이론으로 무장한 PM 프로젝트 산으로 끌고 올라 간다.
13. 고객만 만나면 하악하악 되는 PM 팀원 다 죽인다.
14. 고객에게 뻣뻣한 PM 조만간 갈릴 징조이다.
15. 똑똑한 PL 하나 열 PM 안부럽다.
16. 제시간에 일을 못마치는 팀원은 야근에 지쳐 쓰러지면서도 웹툰을 눈에서 떼질 못한다.
17. 일 빨리 마치면 빨리 집에 보내주는 PM이야 말로 진정한 리더이다.
18. PM이 일안하면 팀원이 야근하고 PM이 일을 하면 PM이 야근한다.
19. "그걸 말로 해야 하나?", "알아서 해"를 난발하는 PM의 프로젝트는 망한다.
20. PM을 바보로 아는 팀원이 있는 팀은 성공해도 팀원을 바보로 아는 PM이 있는 팀은 망한다.
21. 윽박질러 진행한 프로젝트 3개월을 못간다.
22. 개발자는 적응에 2주는 필수로 걸린다. 디자이너는 적응하는데 반나절이면 다른 여자팀원과
     화장실 같이 간다.
23. 점심은 최대한 싸게 빨리 먹고 저녁을 푸짐하게 먹으면 결국은 야근후 집에 가는 시간과
     같다.
24. 파견 인력 머릿수로 프로젝트 하겠다는 발주사 지네 인력 1명 파견 안한다.
25. 이번건 잘되면 다음건도 난발하는 발주사 담당자 프로젝트 후에 얼굴보기 힘들다.
26. 급하게 떨어지는 프로젝트 수주확률 100%! 철저하게 준비한 프로젝트 수주확률 50%!
27. 실컷 돌아가는거 만들어놓고 일정 남으면 DB갈아 엎는다.
28. 아무리 잘못된 설계와 구현일지라도 일정 안남아 있으면 무조건 OK!이다.
29. 사립학교와 종교단체 프로젝트 수주는 회사 말아 먹자는 소리다.
30. 사람과 사람간의 커뮤니케이션은 처음에는 저음으로 시작했다가 고음이 되고 그리고 정적만
     흐르다가 망한다.
31. 항상 개발자는 영업에서 사고친거 뒷수습하다 프로젝트는 끝난다. 따라서, 프로젝트 기간은
     영업에서 사고친것을 뒷수습하는 기간으로 잡아야 안전하다.
32. 이 바닥에서 단골은 없다.
33. 이 바닥에서는 한다리 건너면 아는 사람이다.
34. 이력따위보다는 전직장 주변인의 이야기가 더 정확하다.
35. SI의 전공은 불문과다. (전공불문) 그러나 이왕이면 수학과 출신으로 구해라.
36. 자격증 10개 보유자보다 착실하고 똑똑한 개발자가 훨씬 이롭다.
37. 개발자를 구할때는 오타쿠를 선택하라. 최소한 업무시간 웹서핑은 몇몇으로 국한된다.
38. 개발자를 구할때 가장 피해야할 첫번째는 쇼핑중독자이고 그 다음은 MMO중독자이다.
39. 개발하기전에 1주간은 필요한 자료 공부하고 필요한 컴포넌트 구할 시간을 줘라.
40. 개발자가 안된다고 우기면 바로 잘라 버려라. 그러나 목표를 위해 준비사항을 나열하는
     개발자는 중용하라.
41. 능력과 인간성은 비례하지 않고 오히려 반비례관계인 경우가 더 많다.
42. Knowhow 어쩌구 입에 달고 다니는 팀원은 즉시 짤라야 한다. 최소한 Google보다 많은 정보
     를 얻지 못하기 때문이다.
43. 영업의 Knowhow는 반드시 인정해야 한다. 최소한 Google을 가지고 영업할 수 없기 때문
     이다.
44. 30살 넘으면 슬슬 프렌차이즈 점을 알아 보고 모아야 할 돈의 액수를 가늠해야 한다.
45. 35살 넘으면 프렌차이즈 계약금을 현금/대출로 준비해야 한다.
46. 35살 넘어서 프렌차이즈 계약금 마련못하면 당근 프리랜서해야 하고 분야는 왠만하면
     자바/Oracle/UNIX 3개가 잘팔린다. 나머지는 걍 신입들의 시장으로 보자.
47. 왜 한국은 40넘은 개발자가 없냐고 한탄하지 말고 부지런히 일어나 영어를 공부해서
     호주 또는 일본으로 기술 이민가라.
48. 정통부 단가가 보이면 그때 SI를 논하라.
49. 아무리 훌륭한 방법론도 대한민국 정통부 단가 앞에서는 한낫 종이 쪼가리에 불과하다.
50. 스카웃 제의가 왔다고 좋아 날뛰지 말라. 알아보지 않고 옮긴회사 3개월을 못간다.

더 생각나면 쓰자.
2008/09/09 16:42 2008/09/09 16:42