강팀장의 Web E.Y.G(웹이야기)

얼마전 이런 쪽지를 받은 적이 있습니다.

"관리가 안되는 프로젝트 (대부분의 한국형 프로젝트)...."

어느 정도 경력도 갖추고 어느 정도 실력을 갖추었다고 자부하던 팀원에게 받은 쪽지는 강팀장에게 약간의 고민을 안겨 주었습니다.

한국형 프로젝트????

도대체 한국형 프로젝트란 무엇이지??
외국에는 다른 프로젝트를 수행하는 건가??? 아니면.. 다른 개발 언어로 개발하는 건가??? 무엇이 다른거지????

간혹 모임이나 동호회에서도 이런 부분에 대해서 토론을 하게 될때도 한국형 프로젝트와 비슷한 말들을 듣습니다.

"선진국의 프로젝트는 이렇게 되는데, 한국에서는 그렇지 못하기 때문에 실패 경우가 많은 거야...."

솔직히 강팀장은 그런 말들에 대해서 이해가 잘 가지 않습니다.
선진국이라고 말하는 부분... 한국형이라고 말하는 부분... 이런 말들은 너무나 상식적인 선에서 자주 나오기 때문에 강팀장 스스로도 혼란스러울때가 많습니다.

일전에... 블로그에 [프로젝트 실패의 원인] 이라는 글을 올린 적이 있습니다.

한국이라는 상황에 스스로 비관적 생각보다는, 어떻게 프로젝트를 효율적으로 진행할 것인가를 고민하는 것이 낫다~! 라는 것입니다.

선진국(?), 외국(?) 사례와 많은 연구 보고서를 보면 한국에서 프로젝트를 진행하면서 겪는 일들이 결코 한국이라는 상황때문에 일어나는 것이 아니라, 발전을 위해 한번은 경험해 보아야하는 과정 같은 것이라 쉽게 알 수 있습니다. - 물론 그런 과정자체를 겪어서는 안되겠지만...... -

이렇기 때문에..??... 결국 포기하는 것인가?? 당연히 실패?? 일정 지연....??  많은 문제점들을 정당화하고자 하는 것이 아니라...

지금 겪고 있는 현재의 상황을 너무 극단적으로 비판할 필요는 없을 것 같습니다.

실패를 최소화 하기 위한 많은 연구가 진행 중이고, 이런 부분에 대한 적용과 실무 진행등의 노력도 지속적으로 이뤄지고 있으니, 앞으로 더 좋아질거라 생각 됩니다.

굳이 "한국형" 이라는 굴레를 만들어 버린다면.. 그 또한 문제가 있지 않을까 생각합니다.

  소프트웨어 프로젝트에서의 리스크 관리  

톰 디마르코 외 지음, 김준식 옮김
2004년 졸트상(Jolt Winner) 수상작. 피플웨어의 저자 톰 디마르코와 티모시 리스터가 제안하는 소프트웨어 프로젝트 리스크 관리를 위한 가이드라인. 프로젝트의 불확정성을 반영한 리스크 계량화 방법을 제시한다.

  Rapid Development - 프로젝트 쾌속 개발 전략  

스티브 맥코넬 지음, 이해영 외 옮김
실제 최전방에서 싸우는 개발자와 관리자들에게 구체적인 사례와 문제 해결 방법을 제시하는 실탄을 제공한다. 풍부한 배경 자료, 다양한 사례 연구, 수백편의 논문과 책을 토대로 분석한 성공 사례를 바탕으로 프로젝트를 일정에 맞추는 동시에 고품질을 유지할 수 있는 방법을 소개한다. 1996년 JoltAward 수상작.

[search]프로젝트|10|date|desc|T[/search]

          1.고객이 프로젝트를 설명한것           2.프로젝트담당자가 이해한것      3.분석자가 설계하고 디자인
                                                                                                              한 컨셉



          4.프로그래머가 짠 결과물                  5.테스터가 받은 결과물             6.컨설턴트가 묘사한 결과물


          7. 프로젝트中 문서화된것                8.설치했을때 작동되는 결과              9. 고객이 결과물에 대해
                                                                                                                     지불한 금액의 크기



          10.결과물에대한 유지보수              11.마케팅담당자가 광고했을때        12.실제설치된 시기와 형태


           13.정말로 고객이 원했던것             14.추천사이트에 홍보한 결과        15.이러한 결과로 새계획을
                                                                                                                추진할때



쓴웃음이 나옵니다... 도대체 어디서 부터 잘못된건지.... (그걸 따지는 것 자체가 잘못일까요? ㅡ.ㅡ;;)

2007년도 12월 한달이 남았습니다.
올해 강팀장은 하나의 프로젝트를 수행하고 지금 하나의 프로젝트를 수행중에 있습니다. 사실 요즘들어 부쩍 고민이 많은 생활을 하고 있습니다.

11년을 넘도록 많은 프로젝트를 하면서 항상 죽음으로 가는 길을 많은 변명과 회사의 명분으로 떠 맡은 경우가 얼마나 있었나 싶더군요.
(물론 모든 프로젝트가 그런 것은 아니였습니다. 그리고 스스로 죽음으로 가는 프로젝트를 자청해 맡은 적도 여러번 있었습니다.)

많은 분들과 대화와 토론을 하다 보면 "아직도 우리나라에서는...."  라는 극단적 이야기를 많이 듣곤 합니다. 그럴땐 소주 몇잔으로 서로에게 위로를 하곤 하지만...

오늘 끝으로 읽은 『소프트웨어 프로젝트에서의 리스크 관리』를 보면서 두가지 생각이 들더군요. 하나는  어떻게 이들은 지금 내 처지를 정확하게 말하고 있을까? 둘째는 외국도 우리나라와 비슷한 고민들을 하고 있는 듯 하구나....

"아직도 우리나라에서는.... " 이라는 말보다... "IT 개발 일은... " 이라고 생각하면 소주 몇잔 가지고는 안될까요?

  소프트웨어 프로젝트에서의 리스크 관리  

톰 디마르코 외 지음, 김준식 옮김
2004년 졸트상(Jolt Winner) 수상작. 피플웨어의 저자 톰 디마르코와 티모시 리스터가 제안하는 소프트웨어 프로젝트 리스크 관리를 위한 가이드라인. 프로젝트의 불확정성을 반영한 리스크 계량화 방법을 제시한다.

Project Management 관련 책의 대부분이 그들의 방법론 중심을 책을 저술하는 것이 사실입니다. 읽다보면 자신이 알는 것과는 다른 내용과 이해하기 어려운 프로세스에 대한 이야기로 일괄하다 결국 반도 못보고 책을 덮어 버리는 경우가 많았습니다.

블로그에 담아두고 있다가... 이번 프로젝트를 수행하면 꼭 읽어야 겠구나 싶어 1년 가까이 북마크만 해 놓았던 책을 구매를 하고야 말았습니다. (강팀장의 책 수집 블로그 http://blog.yes24.com/hanjum)

프로젝트 관리자 또는 리더(매니저)라면 한번 읽어 시길 추천합니다. 기술적인 방법론을 익힌기 위한 분도 괜찮겠지만 요즘 들어 왠지 답답한 분이나... 변명이 필요한 분이라면 재미있게 읽을 수 있을 것 같습니다. (^^ 제 경험일까요?? )

불확실성과 관련된 보다 중요한 원인들은 다음과 같다.

 

모든 소프트웨어 프로젝트에 공통적인 리스크

 

우리에 대한 농담

우리 IT 사람들이 리스크 수용에 접근하는 방식이 다른 사람들과 다르다는 것에 대한 농담을 만든다면, 아마 이렇지 않을까?

IT 관리자와 보통 사람이 수요일 오후에 시카고에서 일을 하고 있고, 둘다 금요일 정오에 샌프란시스코에서 미팅에 참석해야 하며 시간을 지키는 것이 매우 중요한 것을 안다.
보통 사람은-다이안이라고 하자- 목요일 밤 비행기를 타고 샌프란시스코 사무실에서 한 블록 떨어진 조그만 호텔에 방을 잡는다.
허남이라는 식당에서 한가로이 식사를 하고 영화를 보고 유니온 스트리트 쪽으로 향한다. 다음날 여유 있는 아침식사를 하고 노트북 컴퓨터로 11시까지 작업을 한다.
11시 30분 체크아웃을 하고는 걸어서 10분 일찍 사무실에 도착한다.

반명 IT 관련자인 잭은 금요일 아침 8시 40분 비행기를 예약한다.
미드타운에서 7시 5분에 택시를 잡아타고 아이젠하워의 교통체증 속으로 들어간다. 오하라 공항까지 가는 내내 택시 운전사에게 화가 나서 불만을 토로한다.
멍청한 택시 운전사는 잭이 이 비행기를 타는 일이 얼마나 중요한지 이해하지 못하는 것 같다.
유나이티드 에어에 체크인을 하면서 직원에게 비행기가 정시에 출발해야 하고 변명은 통하지 않는다고 이야기한다.
그녀에게 어떤 이유로 인한 지연도 '매우, 매우 실망스러울 것'이라고 말한다. 탑승이 지연될 것이라는 말에 펄쩍 뛰며 반발한다.
조정된 시간이 방송되는 순간 그가 가지고 있는 관리도구들을 뒤져서 최후의 통첩을 전달한다.
"만약 내가 12시 미팅에 참석할 수 있도록 당신들이 샌프란시스코에 제때 데려다 주지 않는다면, 모자기자 날아갈 줄 아시오"

납기일자가 중요한 프로젝트는 일찍 시작하는 것이 진정한 리스크 완화다.
이는 아마도 거의 모든 프로젝트에서 지연이라는 리스크를 수용하는 가장 효과적인 방법일 것이다.
좋다. 프로젝트를 일찍 시작하기에는 너무 늦었다는 것을 알고 있다. 시작할 때 시작을 했고 이미 곤경에 빠져 있는 것이다. 그리고 어떻게 하면 곤경에 빠져 들지 않을 수 있었나를 알기 위해 이 책을 읽고 있지는 않을 것이다. 어떻게 하면 무사히 빠져 나올 수 있을지 알고 싶은 것이다. 모두 맞는 말이다. 그러나 아래에서 설명하는 것처럼 일찍 시작하는 선택은 어쨌든 가치 있는 일이다.

- 17장 궁극적인 리스크 완화 전략(202p)

  소프트웨어 프로젝트에서의 리스크 관리  

톰 디마르코 외 지음, 김준식 옮김
2004년 졸트상(Jolt Winner) 수상작. 피플웨어의 저자 톰 디마르코와 티모시 리스터가 제안하는 소프트웨어 프로젝트 리스크 관리를 위한 가이드라인. 프로젝트의 불확정성을 반영한 리스크 계량화 방법을 제시한다.

IT프로젝트 성공율은 30%도 체 도달하지 못하는 경우가 많습니다.
(CHAOSR보고서를 보면 시간이 지날수록 성공율은 올라가긴 하지만, 30%를 넘지 못하는 경우가 많다고 보고하고 있습니다.)

이런 현상은 프로젝트의 규모가 클수록  (성공률) 더 낮게 나오고 있습니다.




프로젝트 실패의 원인에 대해서 우리는 흔히 인력에 대한 부분이 가장 높다고 생각하는 경우가 많습니다.
인력관리는 프로젝트 성공을 위한 중요한 활동임에 틀림이 없습니다.
투입시기 및 일정, 외주관리, 스킬함양등등 인력활동이 중요한 요건이라고 생각하고 있으며 특히 인력 투입시기와 기술적 요건을 실패를 가져오는 직접적인 요인이라고 말하곤 합니다.

하지만 인력에 의한 프로젝트 실패는 큰 비율을 차지 하지 않습니다. 오히려 팀원보다 Manager의 역량에 의한 실패는 더 큰 이유입니다.


팀원이 제대로 움직이도록 하는 것은 매니저에 있습니다.

팀원의 숫자가 생산성에 비례한다는 것은 잘못된 생각 입니다.

어느 회사의 임원급 사람이 자신의 회사가 가지고 있는 힘은 직원이 많다는 것이라며 공공연하게 말하곤 했습니다. "수행하고 있는 많은 프로젝트중 문제가 발생하면 회사내 가용할 수 있는 인력을 많이 넣어 반드시 수행한다."

얼핏 듣기로는 맞는 말 같지만, 프로젝트 관리라는 차원으로 본다면 얼마나 위험한 생각을 가지고 있는지 금방 알 수 있습니다.
시간은 한정되어 있고, 프로젝트 일정에 따라 또는 팀원의 경험 혹 스킬 부족의 해석으로, 밀어 붙이면 된다는 판단은 어리석은 생각입니다.

일 정이 지연되는 것은 팀원의 스킬이나 경험 부족이 잘못된 것이 아니라, 잘못된 일정계획과 그런 상황에 대한 무감각한 결정권자들의 무능력함이 더 큰 이유일 것입니다. - 물론 팀원의 스킬이나, 경험부족이 원인이 될 수 있을지 모르나, 그런 팀원을 적정하게 배정하지 못하는 매니저의 능력부족이 더 큰 원인인 것입니다. -
일정의 지연은 팀원(능력이 되던 안되던, 경험이나 스킬이 부족하던 탁월하던)에 따란 제대로된 일정 계산과 계획의 문제가 원천적인 이유라고 봐야 할 것입니다.

그래도 아직 매니저는 할 말이 있습니다. 제대로 된 인력만 준다면 문제 없이 프로젝트를 순조롭게 할 수 있다.

로버트 바인더는 오히려 팀의 진화를 말하고 있습니다.



팀원과 기술적 구현은 프로젝트 실패의 큰 원인은 아니다.






freepower님께서 강팀장의 글을 읽고 "인력이 제때 들어오지 않으면 결국 프로젝트에는 큰 위험이 발생하게 되는 것 아닙니까? 그 자체가 인적자원의 문제인것 같습니다" 라는 글을 보내 주셨습니다.

맞습니다. 이 글은 한가지 전제를 두고 있어야 합니다. "회사에서 인력투입을 프로젝트 진행 계획대로 투입을 시켰을때"의 상황을 말하는 것입니다.

넓 은 의미의 프로젝트를 본다면 적절한 인력투입 시기와 투입여부 또한 프로젝트의 인적자원관리라고 볼 수 있습니다만, 더 중요한 것은 투입시기 산출과 투입여부 또한 매니저의 역활중 하나 입니다.  회사가 인력을 투입해 주던 안 해주던 매니저는 그 역활을 위해 최선 다해 활동을 해 주어야하고 그에 따른 책임을 가져야 할 것입니다. 반면 회사는 매니저가 그런 활동을 하도록 매니저로써 권한을 명확히 해야 합니다.



우리는 2가지 고질적인 문제점을 가지고 있습니다.

1. 거의 대부분의 회사에서는 인적자원이 확보 여부와 관계 없이 프로젝트를 진행하고자 한다.
회 사는 간혹 이후 프로젝트를 위한 프로젝트를 하는 경우가 많습니다. 이런 경우는 주로 정치적인 프로젝트가 될 가능성이 높습니다.정치적 프로젝트는 그 자체가 많은 위험요소를 지니고 있는데 그중 가장 고질적인 부분이 최소로 최대한 이라는 생각을 가지고 있다는 것 입니다. 

2. 매니저에게 정확한 권한과 책임이 주어지지 않는다.
프 로젝트를 진행할때 매니저의 역활은 굉장히 중요합니다. 하지만 그에 따른 권한과 책임을 주지 않고 이중적 잣대를 가지고 본다는 것입니다.  간혹 권한은 없고 책임만 묻는 것이 거의 대부분 회사의 행태인 것 같습니다. 전 이 또한 매니저를 관리하는 윗 사람들의 자질에 문제가 있다고 봅니다.

1번째를 어느정도 완화시킬 수 있는 대안은 2번에 있습니다만.... 여전히 회사도 매니저도 할말이 많을 것 같습니다.

그림에 대한 의견보기..






 

얼마전 M회사에 이력서를 제출한 바 있었다.



이력서를 낸뒤 일주일 정도 지나서 면접이 잡혔고, 면접을 봤다.

면접을 진행했던 담당 차장님의 질문이 지금 강팀장의 상황에서 머리속을 떠나지 않고 있다.

Q. 수주를 받은 Project의 일정이 왜 지켜지지 않을까요?
A. Project의 일정은 크게 2가지 원인이 있을 수 있겠습니다.
첫번째 무리한 Project 수주에 있습니다. 무리한 수주는 팀구성과 프로젝트 운영에 대한 부담을 주게 됩니다. 이런 부담은 팀 전체의 사기와도 밀접한 관계가 있고 이에 따른 발주처의 불만족이 여러가지 사고의 원인을 일으키게 됩니다.
두번째 팀원의 구성에 문제가 있습니다. 팀원은 해당 프로젝트에 대한 이해와 경험들이 동반되어야 ISSUE 발생에 대한 원활한 대처가 이뤄질 수 있습니다.

Q. 팀원 구성 문제가 있다고 하셨는데... 구체적으로 어떤 문제가 있다고 보십니까?
A. 개개인적인 문제를 모두 짚을 수는 없습니다만 제 경험을 말씀 드리자면 OOOO프로젝트에서 인력수급이 제대로 되지 않아 처음에 팀원 구성이 되지 않았습니다. 그리고 급하게 팀원을 맞출때 대부분을 프리랜서로 구성하게 되었습니다. 인력수급이 안되어 초기에 팀원들의 프로젝트의 전반적인 Study가 되지 않았고, 뒤에 투입된 프리랜서는 소속 직원 만큼 책임감 있게  프로젝트를 진행하지 못해 일정에 문제가 발생하는 ISSUE가 발생 하였습니다.

Q. 수주 회사의 사정이라는 것이 있을 수도 있지 않습니까?
A. Project에 문제가 생기는 근본적인 이유를 2가지로 말씀 드렸습니다만, 수주회사가 초기 Project 를 수주할때 그 사정을 스스로 정확히 판단하고 평가하여 수주를 받아야 한다고 생각합니다. 물론 이후의 Project를 생각할 수도 있겠지만 근본적으로는 먼저 수주를 받고 보자는 식의 진행은 지금에나 이후에도 회사에 큰 부담과 문제로 자리잡게 될 가능성이 높습니다.
하지만 사정에 의해 프로젝트를 수주 받았다면, 팀구성과 팀원의 구성, 팀운영에 대한 부분은 PM의 자질에 따라 문제를 최소화 시킬수도 있습니다.

.... 이하생략



블로그를 뒤지다 프로그래머에 대한 그림 몇장을 봤다. 비단 프로그래머뿐만 아니라, 디자이너도 기획자도, PM도 마찬가지가 아닐까 생각한다.

Project 수행에 있어서 가장 중요한 것은 역시 사람이다.
팀원간의 관계... 발주자와 수주자의 관계....
하지만 단지 사람과의 관계만으로 이 문제를 다 푼다는 것은 뭔가 빠진듯 하다. 아마 "회사"가 아닐까....??!!



출처 : http://blog.naver.com/imcjpark/10016181044


출처 : http://blog.naver.com/superxt/120035920668

(이번 출장이 길어져 장시간 사이트에 자리를 비웠습니다.)


책을 읽다 나름대로 생각 있어 책을 글을 인용해서 몇자 적습니다.


사실 얼마전 강팀장이 다니는 회사에 조직개편에 대한 바람이 불었습니다.

강팀장의 회사는 개발 1, 2팀, 고객지원팀(유지보수팀&서버관리팀), TFT 팀, DTP 팀, 멀티미디어 개발팀, ICT 팀, 인터넷 방송 팀, 관리팀, 신문팀 이렇게 구성되어 있습니다.


그중 4개팀 TFT 팀, 고객지원팀, 개발 1, 2팀의 개편에 대한 논의가 있었고 비슷한 업무에 따른 업무 효율성을 높이는 방안에 대해서 몇번의 회의가 있었습니다.


결국 팀을 업무영역별 팀으로 재개편하는 것으로 말이 있다가 결국 당장 직원의 사기 진작과 전반적인 업무 방식의 변동으로 인한 리스크를 최소화 할 수 있는 대책이 없다는 것으로 강팀장의 반대로 인해 차후 다시 재 검토하기로 결정을 보고 현재 유지되고 있는 팀체재로 진행하기로 했습니다.


팀의구성은 크게 업무 영역별 인력구성과 Shell 단위 인력 구성 방식 2가지가 있습니다.


첫번째 업무 영역별 팀구성은 디자인, 프로그램 등 각 영역별 구성으로 업무를 전문화 시킬 수 있고 큰 프로젝트에 대한 개발 지향적이라는 것과 세분화 되는 업무 영역을 전문화 시킬 수 있다는 장점을 가지고 있습니다.


반면 두번째 셀단위 인력 구성방식은 프로젝트를 빠르게 진행할 수 있고 회사의 실적과 이윤적 안정을 꾀할 수 있는 장점이 있습니다.


굳이 어느것이 좋다고 말한 순 없습니다.


어느 형태로 팀을 구성하고 진행하느냐에 따라 업무 방식이 다르고 프로젝트 진행방식이 다르다는 것입니다.


아래의 내용은 "성공하는 웹 기획 실패하는 웹기획" 이라는 책에서 인용한 내용입니다.



웹개발 인력 구성



>> 우리 나라의 웹 개발 인력 구성
우리나라 웹 개발 인력의 구성은 초기에는 웹 마스터에서 시작하여 웹 개발에 있어 꼭 필요하지만 이질적인 업무파트인 디자인 부분과 프로그램 부분에 대한 인력으로 세분화되기 시작하였다. 이러한 초기 웹 개발 인력 구성 형태의 영향으로 지금도 디자이너나 프로그래머 웹 개발 기획까지 담당하는 곳이 많다.
그러나 이러한 구성은 감각적이고 셈세한 능력을 소유하고 있는 디자이너나 논리적이고 집중적 사고력을 요구하는 프로그래머들과 비교하여 객관적이고 분석적인 마인드를 필요로 하는 웹 개발 기획에 있어 결코 좋은 인력 구성은 아니라고 생각된다.

현재, 일반적인 웹 사이트 개발 인력 구성은 계속적으로 세분화되어 각 업무영역의 전문화를 꾀하고 있다.

기획 Part : 웹 개발에 대한 전반적인 계획을 세우고 구체화시키며, 클라이언트와의 협상으로 업무를 조율한다.

컨텐츠 Part : 컨텐츠에 대한 자료를 수집하고, 가공, 제공까지 전담한다.

디자인 Part : 시안에서 부터 세부 디자인까지 디자인 전 영역을 담당하며, 코딩작업도 함께 하는 경우가 대부분이다.

프로그램 Part : 작게는 게시판에서부터 쇼핑몰 관리 및 운영, 데이터베이스 운용까지 프로그램이 들어가는 전 영역을 담당한다.

우리나라의 다수 웹 에이전시 회사들은 Shell 단위의 인력 구성으로 웹 개발을 진행하고 있다. 쉘단위 인력구성은 가장 핵심적인 인력인 기획자, 디자이너, 프로그래머등을 각 1명씩 묶음으로써 업무 협조나 업무 집중력을 높이고 신속히 개발할 수 있다.

상대적으로 작업량이 불규칙하거나 많지 않은 보안팀, 시스템팀, 전문 DB설계팀, 멀티미디어팀 등은 독자 팀으로 구성하여 각 쉘단위 팀에서 해당 업무가 발생할 때에 참여하게 된다.


>> 미국의 웹 개발 인력 구성

미국의 웹 개발 인력 구성과 우리나라의 웹 개발 인력 구성에는 상당한 차이를 보인다. 특히, 기획자의 역할 부분과 프로그래머의 역할 부분이 크게 다른 것을 알 수 있다.

미국의 웹 개발은 웹 전문 개발업자에 의하여 프로젝트 단위로 작업하기 때문에 필수 인력에는 클라이언트 대면 업무와 관련된 인력들이 상당수 포함되어 있다. Quality Assurance Director 나 어카운트 매니저 같은 인력이 그 대표적인 예이다.

또 하나 특이한 점은 우리 나라의 개발 인력상 필수 인력인 프로그래머가 확장 인력(필요에 따라 투입되는 인력)으로 구분되고 있다는 점이다. 그 이유는 웹 사이트의 구성상 Off Line 회사의 단순 소개 사이트나 소규모 사이트의 경우 게시판 기능을 제외하면 프로그램적 용소가 들어가지 않기 때문에 Technical Director&Web Production Spoecialist가 그 업무를 담당한다고 볼 수 있다.

우리나라에서 최근 등장한 Web PD의 업무영역은 웹 개발 전반에 걸쳐 있따.
미국의 웹 개발 회사의 업무형태는 진행상 극히 클라이언트 중심, 즉 의뢰 받은 사이트의 성격이나 특징, 규모에 따라 프로젝트 진행 최기에 인력이 조합되고 있기 때문에 기본 인력과 확장 인력으로 나누어 분류할 수 있다. 여기서 현재 일반적인 우리나라의 웹 기획자의 영역은 미국의 Web PD 일부 업무, Quality Assurance Director, Information Architect, 카피라이터의 업무영역에 상응될 수 잇다.


미국식 인력 구성과 우리 나라의 구성을 비고하여 어느 쪽이 더 효율적인가를 판단하려고 한다면, 그것은 웹 개발 환경에 가장 잘 적응되는 인력구조가 가장 효율적이라고 말할 수 있을 것이다.

미국은 철저희 의뢰된 사이트에 맞춘, 필요에 따라 인력을 조합하고 해체하기 쉬운 형태의 웹 전문개발업체(우리나라의 웹 에이전시) 인력 구조를 가지고 있지만, 우리나라의 웹 에이전시 회사를 제외한 웹 관련 기업의 경우 미국식 인력 구조가 표준으로 삼을 만큼 적합하다고 볼 수 없다.

인력의 조합과 해체가 용이하지 않은 우리나라에서 웹 기획자의 역할은 사업제안 또는 사업계획 수립에서부터 개발, 운영까지의 웹 전반적에 걸쳐 확대되어 있는 것이 사실이다.

출처 : 성공하는 웹 기획 실패하는 웹 기획

"웹 기획자"는 "웹 서비스 기획자"가 아니다. 고의적인 구분일 수 있지만 "웹 기획자"는 스토리보드를 만들고 UI를 기획하는 전문성을 가진 사람을 말한다. "웹 서비스 기획자"는 그런 기본적인 자질이 있는 상태에서 비지니스 기획과 사용자 관리 정책 및 운영 정책을 설립하고 실행하는 사람을 말한다. 다시 말해 "웹 기획자"를 웹 사이트의 설계자로 규정한다면 "웹 서비스 기획자"는 웹 사이트를 구성하는 웹 서비스를 기획하고 사용자에게 전달하고 피드백을 구현하는 경영자라고 할 수 있다.



무엇이 무엇의 상위 개념이 아니라 "웹 서비스 기획자"라는 개념이 "웹 기획자"를 포괄하고 있으며 보다 일반적인 개념이라는 것이다. "웹 기획자"는 스토리 보드를 통해 평가할 수 있지만 "웹 서비스 기획자"는 그것 이상의 무엇이 필요하다. "웹 기획자"에게 웹 서비스와 비지니스의 관계 이해는 옵션이다. 반면 "웹 서비스 기획자"에게 비지니스 관계 이해는 필수다. "웹 기획자"에게 사이트 UI의 이해와 적용은 필수지만 "웹 서비스 기획자"에게 사이트 UI는 다른 필수적인 요소에 의해 덜 중요한 요소가 될 수 있다. "웹 기획자"는 사이트 운영에 관여하지 않을 수 있지만 "웹 서비스 기획자"는 사이트 운영에 반드시 관여해야 한다.





작은 조직에서 "웹 기획자"는 "웹 서비스 기획자"의 역할을 부여 받는다. 본인이 원치 않더라도 그런 역할을 수행해야 하는 것이다. 그런데 이 두 가지 직종은 엄연히 서로 다른 지식적 경험적 기반을 요구한다. 설계를 잘 하는 사람이 운영을 잘 한다는 보장은 없다. 또한 운영을 잘 하는 사람이 설계를 잘 할 것이라는 믿음도 어설픈 것이다. 완벽한 사이트 맵이 완벽한 운영을 보장하지 않는다는 말이다. 또한 완성도 높은 UI가 완성도 높은 서비스를 보장하지도 않는다. 여기서 문제가 발생한다. "잘 할 수 없는 일을 강요받게"되는 것이다.



이러한 문제는 웹 사이트를 운영하는 회사 전반에 나타나는 매우 보편적인 문제다. 실제로 이런 문제에 처한 회사와 대상자는 문제의 핵심을 비켜난 논쟁을 벌인다. 회사는 더욱 다양한 요구를 하게 되고 대상자는 그 요구에 숨이 막힌다. 업무를 처리하지만 업무 처리 이상도 이하도 아닌 현상 유지에 급급하게 된다. 새로운 서비스의 기획은 정체되고 현재 업무 처리마저도 수준 이하가 되어 버린다. 이로 인해 사용자의 증가는 지연되고 웹 사이트를 생명력을 잃게 된다.



"기획"이라는 매우 보편적인 단어와 "웹(web)"의 결합은 "웹기획"이라는 신조어를 낳았다. "웹기획"은 새로운 웹 사이트와 운영 중인 웹 사이트에 대한 모든 업무를 처리하는 수퍼맨을 의미하는 단어가 되어 버렸다. 애니메이션인 "인크리터블"을 보면 수퍼히어로에 원한을 갖게 된 '신드룸'이 내 뱉는 한 마디가 있다,



"내 무기를 이용하여 모두가 영웅이 되어 버리면 이제 영웅이 평범해 지겠지"



영웅으로써 "웹기획자"는 찾기가 매우 어렵다. 그런 영웅은 거의 혼자서 하나의 웹 사이트를 만들고 운영하여 성공으로 이끌게 된다. 물론 영웅의 역할은 어느 지점에서 멈춘다. 한 명의 영웅이 전 세계를 구원할 수는 없듯 어떠한 시점이 되면 몇 명의 영웅과 많은 평범한 그러나 뛰어난 사람들이 필요하다. 조직의 확대 개편이 이루어지는 것이다.



그렇다면 "웹기획자"에게 주어진 엄청난 부담 - 소위 수퍼 영웅이 되어야만 하지만 그럴 역량이 없는 -을 해소할 수 있는 대안은 무엇인가? 이것에 대해 답하기 전에 우선 이런 고민을 하고 있다면 감사한 마음을 가져야 한다. 대부분의 웹 사이트들은 이런 고민을 할 수 있는 시기에 도달하지도 못하고 사라져 버린다.



이 문제는 고전적인 방법으로 풀 수 있다. 바로 "팀웍에 의존하는 것"이다. 잘 훈련된 팀웍(team-work)은 영웅이 할 수 없는 일을 해 낼 수 있다. 4 명의 평범한 인원들이 10의 역량을 가지고 있는데 현재 필요로 하는 요구량은 100이라고 생각해 보자. 그렇다면 -60 인 상태가 계속될 것이다. -60은 결국 웹 사이트를 망하게 만들 것이다. 우리는 그것을 잘 알기 때문에 이렇게 이야기한다,



"새로운 인원을 빨리 충원해 주세요!"



그러나 6 명의 새로운 인원이 충원된다고 상황이 예견했던대로 달라지지 않는다. 4 명을 위한 팀웍과 10 명을 위한 팀웍은 매우 다르기 때문이다. 또한 팀웍을 구성하는 전체 숫자의 2.5 배에 달하는 신규 인원이 충원되게 되면 조직의 붕괴 가능성이 매우 높아진다. 1년 이내에 전체 조직원의 30% 이상이 변동될 경우 해당 조직의 붕괴 가능성은 몇 배 이상 높아진다는 연구 보고가 있다. 따라서 새로운 인원의 충원은 거의 모든 경우에 문제를 해결하는 대안이 되지 못한다.





웹 사이트 사용자의 숫자는 더욱 빠른 속도로 늘어갈 것이며 그와 걸맞는 속도로 응대하는 피드백 시스템을 구현해야 한다. 속도전에서 사용자에게 뒤쳐지지기 시작하면 걷잡을 수 없는 파국으로 이어지는 상황이 점점 더 자주 발생하게 된다. 업무량은 더욱 늘어날 것이며, 잦은 야근과 철야로 인해 조직원은 지쳐갈 것이다.



이런 문제를 해결하기 위해 조직은 팀웍 중심으로 재편되어야 하며, 이슈(issue)는 집단적으로 해결되어야 한다. 더 이상 웹기획자 혼자서 감당할 수 없는 일이 더욱 많이 발생할 것이므로 그/그녀의 개인 역량에 의존해서는 안된다. 팀웍은 제안과 토론 그리고 실천의 프로세스를 집단적으로 처리할 수 있어야 한다. 한 사람 혹은 몇 몇 사람으로 구성된 팀으로 업무를 분산시켜서는 안된다. 따라서 이런 슬로건이 필요하다.



"우리는 모든 것을 알고 있으며 모든 것을 할 수 있으며 특별히 그것을 잘 한다"



팀웍 중심으로 개편된 조직에서 과거에 APM을 기반으로 한 웹 프로그래머(Apache-PHP-MySQL를 주요 기술로 하는 웹 프로그래머)는 과거와 다른 업무 역량을 요구받게 된다. 이 프로그래머는 과거에 APM과 관련된 일만 했다. 참가하는 회의는 웹 프로그램과 관련한 몇몇 회의 뿐이었으며 다른 업무에 대한 요구는 없었다. 만약 그런 요구가 주어지더라도 자신의 주요 업무가 아니기 때문에 실질적인 산출물 및 자기 발전과는 별 관계가 없었다. 그러나 새로운 팀웍을 위해 이 프로그래머는 매우 다양한 회의에 참가하여 자신의 의견을 제시하고 토론을 해야 한다. 즉 프로그래머도 UI나 스타일 가이드에 대해 이야기할 수 있어야 하며 이야기해야만 하는 것이다.



새로운 팀웍을 위해 이 프로그래머는 과거에 자신의 영역과 별 관련이 없던 다른 부서의 업무를 익혀야 한다. 새로운 책을 봐야하고 새로운 토론에 참가해야 한다. 그러나 여전히 그/그녀는 APM 기반의 웹 프로그래머다. '모든 것을 알고 있다' 그리고 '모든 것을 할 수 있다'는 것은 어떤 일에 대한 의존도를 분산시키기 위한 것이다. '특별히 그것을 잘 한다'는 것은 전문화된 영역의 중요성은 여전히 존재하며 그것으로 인해 평가받게 될 것임을 의미한다.



새로운 팀웍 하에서 "스토리보드 나오면 이야기 합시다" 따위의 이야기는 통하지 않는다. 스토리보드의 구성과 생성을 위한 필요조건을 모두가 알고 있다. 필요하다면 언제든 프로그래머나 디자이너도 스토리보드를 그릴 수 있다.(물론 생산성은 떨어질 것이다) 따라서 스토리보드가 나오기 전에 새로운 서비스나 웹 페이지에 대한 토론을 진행할 수 있다. 과거에 7 일이 걸렸던 작업을 3 일 안에 끝낼 수 있게 된다. 프로젝트 전체에서 웹기획에서 발생하는 병목현상도 극복할 수 있다. 서로 다른 업무에 대한 이해도는 높아지며 업무 개선의 속도도 빨라 진다.



잘 훈련된 팀웍은 평범한 사람들의 역량을 그 이상의 것으로 진화시키는 기폭제가 된다.



잘 훈련된 팀웍을 갖기 위해 무엇을 준비해야 할까? 수 많은 과제가 있겠으나 한 마디로 정리할 수 있다. 바로 "내부로부터의 변화"다. 자신이 변화하지 않으면 아무것도 변화하지 않는다. 운이 없다면 그 변화에 실패하여 조직에서 도태될 수도 있다. 변화는 바로 자신에서 시작해야 한다. 조직은 그 변화를 제시하며 지원하기 위해 노력할 것이다. 그러나 궁극적으로 자신이 변하지 않는다면 잘 훈련된 팀웍은 요식행위일 뿐이다. 자기 자신에게 의미있는 변화. 조직과 함께 하는 변화. 진화로써 변화를 받아 들이는 것. 그것이 핵심이다.





만약 '잘 훈련된 팀웍'을 만들 수 있다면 웹기획자의 수퍼 영웅 딜레마는 자연스럽게 해소될 것이며 새로운 조직 형태로 진화할 수 있는 근간을 마련하게 될 것이다. 이 변화에 성공하는 조직은 더 큰 규모의 웹 사이트를 꾸릴 수 있다. 십 만명을 꾸리는 웹 사이트의 조직과 백 만명을 꾸리는 웹 사이트의 조직은 비록 그 조직 편재가 같더라도 운영 방법은 전혀 다르다. 마찬가지로 천 만명을 꾸리는 웹 사이트는 또 다른 조직 운영 방법을 갖고 있다. 하나씩 해결해 나가려는 다짐이 있다면 이런 조직은 바로 우리가 있는 이 조직이 될 것이다.