죽음의 행진
올해 강팀장은 하나의 프로젝트를 수행하고 지금 하나의 프로젝트를 수행중에 있습니다. 사실 요즘들어 부쩍 고민이 많은 생활을 하고 있습니다.
11년을 넘도록 많은 프로젝트를 하면서 항상 죽음으로 가는 길을 많은 변명과 회사의 명분으로 떠 맡은 경우가 얼마나 있었나 싶더군요.
(물론 모든 프로젝트가 그런 것은 아니였습니다. 그리고 스스로 죽음으로 가는 프로젝트를 자청해 맡은 적도 여러번 있었습니다.)
많은 분들과 대화와 토론을 하다 보면 "아직도 우리나라에서는...." 라는 극단적 이야기를 많이 듣곤 합니다. 그럴땐 소주 몇잔으로 서로에게 위로를 하곤 하지만...
오늘 끝으로 읽은 『소프트웨어 프로젝트에서의 리스크 관리』를 보면서 두가지 생각이 들더군요. 하나는 어떻게 이들은 지금 내 처지를 정확하게 말하고 있을까? 둘째는 외국도 우리나라와 비슷한 고민들을 하고 있는 듯 하구나....
"아직도 우리나라에서는.... " 이라는 말보다... "IT 개발 일은... " 이라고 생각하면 소주 몇잔 가지고는 안될까요?
- 톰 디마르코, 티모시 리스터 지음
Project Management 관련 책의 대부분이 그들의 방법론 중심을 책을 저술하는 것이 사실입니다. 읽다보면 자신이 알는 것과는 다른 내용과 이해하기 어려운 프로세스에 대한 이야기로 일괄하다 결국 반도 못보고 책을 덮어 버리는 경우가 많았습니다.
블로그에 담아두고 있다가... 이번 프로젝트를 수행하면 꼭 읽어야 겠구나 싶어 1년 가까이 북마크만 해 놓았던 책을 구매를 하고야 말았습니다. (강팀장의 책 수집 블로그 http://blog.yes24.com/hanjum)
프로젝트 관리자 또는 리더(매니저)라면 한번 읽어 시길 추천합니다. 기술적인 방법론을 익힌기 위한 분도 괜찮겠지만 요즘 들어 왠지 답답한 분이나... 변명이 필요한 분이라면 재미있게 읽을 수 있을 것 같습니다. (^^ 제 경험일까요?? )
1. 요구사항(requirment) : 정확히 무엇을 하기 위한 시스템인가?
2. 정합성(match) : 사용자 및 다른 관련 시스템과 어떻게 연계할 것인가?
3. 환경 변경(chainging environment) : 개발 기간 중에 요구와 목표들이 얼마나 변경되는가?
4. 자원(resources) : 프로젝트를 위해 필요한 핵심 기술을 가진 사람을 확보할 수 있는가?
5. 관리(managerment) : 관리 조직에게 생산성이 높은 팀을 구성하며 사기를 유지하고, 인원 변경을 최소화하면서 관련 업무간의 복잡한 관계들을 풀어 나갈 능력이 충분히 있는가?
6. 공급망(supply chain) : 다른 관련 조직들이 기대대로 대응해 줄 것인가?
7. 정치(politics) : 현실을 호도하여 프로젝트의 궁극적 성공과는 상충되는 제약들을 부과하는 경우 어떤 영향이 있을까?
8. 상충(conflict) : 다양한 이해 조직 간의 상호 양립할 수 없는 목적들을 어떻게 다룰 것인가?
9. 혁신(innovation) : 이 프로젝트에만 적용된 기술이나 접근 방식이 최종 결과에 어떤 영향을 미칠 것인가?
10. 규모(scale) : 과거에 경험하지 못한 큰 규모가 프로젝트 성과에 어떤 영향을 미칠 것인가?
"내 생각에는 4월까지는 매우 어려워 보이네. 그래서 자네에게 이 일을 맡기는 것일세"
중간에 특별한 행운이 없이는 4월까지 도저히 할 수 없다는 것을 인식하고, 그러한 행운을 잡는 것이 프로젝트의 아주 중요한 부분이 되어 버린다. 이는 리스크 관리와는 정확히 상반되는 것으로, 프로젝트 계획의 초점이 만약 행운이 따르지 않는다면 어떻게 할지에 맞추어진다.
개인적인 도전으로 시작된 프로젝트에서는 리스크를 합리적으로 관리하기 어렵다. 대신 행운에 의존하게 된다. 프로젝트가 그런식으로 주어진다면 할 수 있는 일은 많지 않을 것이다. 그러나 미래를 생각하면 배울 것이 없는 것도 아니다. 당신이 프로젝트를 직접 지시할 위치에 올랐을 때, 절대로 운에 의해 지배되도록 프로젝트를 포장하지 말라. 합리적이고 신축적인 목표를 제시하되, 실제 기대치는 행운이 일어나지 않으리라는 것을 고려하여 조금 여유를 두도록 하라
여기저기 도처에서 발생하는 문제들이 꽤 있기 때문에, 모든 프로젝트에 대해, 정도는 다르겠지만, 발생하리라 예상되는 20~30개 정도의 문제에 대한 리스트를 만드는 것은 그다지 어려운 일이 아니다. 여기서는 그 중 다섯개만을 선택하여 다루었다. 그 이유는 이들을 통해 현실이 계획을 벗어나는 대부분의 상황을 설명할 수 있으며, 또 이 리스크와 업계의 유용한 데이터를 이미 확보하고 있기 때문이다. 핵심 리스크는 다음과 같다.
1. 원래 일정의 결함
2. 요구사항의 확대(시간에 따라 요구사항이 조금씩 늘어나는 것)
3. 인원의 교체
4. 설계 명세 붕괴(specification breakdown)
5. 낮은 수행능력(under-performance)
이 중 맨 마지막 것만이 수행능력과 관련된 것이다. 나머지 네 개는 당신이 얼마나 열심히 일하는가, 그리고 얼마나 경쟁력이 있고 능숙한가와는 거의 무관하다. 이를 강조하는 이유는 많은 관리자들이 리스크 관리를 수행능력의 저하에 대한 변명으로 삼기도 한다는 점을 우려하기 때문이다. 리스크 관리의 핵심은 제어불가 항목들에 대해서 합리적인 준비를 하는 것이다.
그런 중비를 통해 실패를 미연에 방지할 수 있다. 다시 말해 앞서 말한 제어불가 항목들이 당신을 문제에 빠뜨리는 경우에 대한 대비책을 마련하도록 해 주는 것이다.
우리 IT 사람들이 리스크 수용에 접근하는 방식이 다른 사람들과 다르다는 것에 대한 농담을 만든다면, 아마 이렇지 않을까?
IT 관리자와 보통 사람이 수요일 오후에 시카고에서 일을 하고 있고, 둘다 금요일 정오에 샌프란시스코에서 미팅에 참석해야 하며 시간을 지키는 것이 매우 중요한 것을 안다.
보통 사람은-다이안이라고 하자- 목요일 밤 비행기를 타고 샌프란시스코 사무실에서 한 블록 떨어진 조그만 호텔에 방을 잡는다.
허남이라는 식당에서 한가로이 식사를 하고 영화를 보고 유니온 스트리트 쪽으로 향한다. 다음날 여유 있는 아침식사를 하고 노트북 컴퓨터로 11시까지 작업을 한다.
11시 30분 체크아웃을 하고는 걸어서 10분 일찍 사무실에 도착한다.
반명 IT 관련자인 잭은 금요일 아침 8시 40분 비행기를 예약한다.
미드타운에서 7시 5분에 택시를 잡아타고 아이젠하워의 교통체증 속으로 들어간다. 오하라 공항까지 가는 내내 택시 운전사에게 화가 나서 불만을 토로한다.
멍청한 택시 운전사는 잭이 이 비행기를 타는 일이 얼마나 중요한지 이해하지 못하는 것 같다.
유나이티드 에어에 체크인을 하면서 직원에게 비행기가 정시에 출발해야 하고 변명은 통하지 않는다고 이야기한다.
그녀에게 어떤 이유로 인한 지연도 '매우, 매우 실망스러울 것'이라고 말한다. 탑승이 지연될 것이라는 말에 펄쩍 뛰며 반발한다.
조정된 시간이 방송되는 순간 그가 가지고 있는 관리도구들을 뒤져서 최후의 통첩을 전달한다.
"만약 내가 12시 미팅에 참석할 수 있도록 당신들이 샌프란시스코에 제때 데려다 주지 않는다면, 모자기자 날아갈 줄 아시오"
납기일자가 중요한 프로젝트는 일찍 시작하는 것이 진정한 리스크 완화다.
이는 아마도 거의 모든 프로젝트에서 지연이라는 리스크를 수용하는 가장 효과적인 방법일 것이다.
좋다. 프로젝트를 일찍 시작하기에는 너무 늦었다는 것을 알고 있다. 시작할 때 시작을 했고 이미 곤경에 빠져 있는 것이다. 그리고 어떻게 하면 곤경에 빠져 들지 않을 수 있었나를 알기 위해 이 책을 읽고 있지는 않을 것이다. 어떻게 하면 무사히 빠져 나올 수 있을지 알고 싶은 것이다. 모두 맞는 말이다. 그러나 아래에서 설명하는 것처럼 일찍 시작하는 선택은 어쨌든 가치 있는 일이다.
- 17장 궁극적인 리스크 완화 전략(202p)
- T 는 동작을 완수하는 데 필요한 평균 시간이다. 전통적으로 연구자들 사이에서는 MT(Movement Time)이라고도 한다.
- a 와 b 는 실험 상수로서 데이타를 측정하기 위해 직선을 측정하여 얻어진 실험치로 결정한다.
- D 는 대상 물체의 중심으로 부터 측정한 거리이다. 전통적으로 연구자들 사이에서는 A (Amplitude)라고도 한다.
- W 는 움직이는 방향을 축으로 하였을때 측정되는 목표물의 폭이다. 또한 W는 최종 목표치에 다다를때 허용되는 오차치이기도 하다. 그래서 목표중심의 ± W/2 이다.
목표물의 크기가 작을 수록 목표에 도달하는데 속도와 정확도가 떨어지고, 거리가 멀수록 시간이 오래 걸린다. 라는 법칙입니다.
피츠 법칙은 웹개발(특히 기획, UI, 웹디자인)에서 중요한 법칙입니다.
(폴 피츠에 의해 1954년에 발표되었던 피츠의 법칙은 행동법칙에 대한 연구뿐만 아니라, 많은 부분에서 적용됨을 알 수 있습니다.)
피츠의 법칙이 웹개발에서 어떻게 적용되는지 몇가지 항목에 대해서 한번 고민해 보도록 하겠습니다.
1. 마우스를 굴려라~~~ 어려운 클릭
IT 직종에 2~3년차를 넘어가는 사람이라면 한번쯤은 잡포털을 이용해 보았을 것입니다.
강팀장도 꼭 직장을 구하기 위한 목적외에 이력서를 관리하기 위해 잡코리아에 이력서를 등록해 놓고 사용을 합니다.
간혹 이력서 업데이트도 할 겸... (요즘은 비슷한 프로젝트를 수행하고 있어, 더욱 자주 들어가 보게 됩니다. ) 잡코리아에 들어가 봅니다.
로그인을 하게 되면 개인화페이지로 넘어가는데... 이때 가장 눈에 띄는 박스가 있습니다. 로그인을 하게 되면 오른쪽 하단에 스스륵 올라오는 박스 그 덕에 눈에는 정말 잘 뜁니다.
프로모션을 위해 사용하는 박스이기도 하지만, 그곳에 재미 있는 정보가 있습니다.
2줄로 된 간단한 정보..... 솔직히 강팀장 입장에서는 간혹 들어가 볼때마다 스스르륵 올라오는 박스가 재미 있기도 하고, 바로 간단한 통계가 보여서 그대로 두고 보는 경우가 많습니다.
어느날 부터... 호기심이 생기더군요.
"어~ ?? 내 이력서를 열람한 기업이 17개(???) 언더바가 있는 것 보니깐.. 클릭하는 곳인가?"
물론... 왼쪽에 "내 이력서를 열람기업" 이라는 메뉴가 있긴 있습니다. 그런데... 그곳은 눈에 잘 띄지 않고.. 오히려 17 이라는 숫자에 더 호기심이 가더군요.
호기심이 생긴 17의 정보를 보기 위해 (강팀장 노트북 해상도는 1680 X 1050으로 사용하는데....) 넓고 긴 거리를 마우스를 굴려 클릭을 합니다.
아차... 정작 궁긍했던 17 은 클릭을 못하고... 넓은 공간을 이동하여 마우스를 옮겨와서는 애꿋은 "온라인 입사지원 1개 " 에 1 을 클릭하고 말았습니다. (17보다 1이 클릭할 수 있는 범위가 더 작은데... 그만 실수를....)
그 뒤에 강팀장은 오른쪽의 스스륵 Box 는 단순히 몇개 기업이?? 라는 호기심을 풀기위한 영역으로 생각하게 되었습니다.
일반 사용자(적어도 강팀장보다 많이 사용해보지 않은 수미여사-강팀장 어머니)라면 아마... "저거 클릭해 보세요" 했다간... 이 강팀장을 두들겨 팼을 지도 모릅니다.
2. 다음 페이지는 없다. ~~
사실 옥션도 인연이 있었던지라... 인터넷에서 물건을 구매할때 꼭 옥션에 들러서 검색을 해 보곤 합니다. 요즘에는 겨울 조끼라도 하나 살까 하고 검색을 하고 리스트를 쭈~욱 훌터 보는데... 디자인이 이쁜것이 별로 없더군요..
화면을 한참 아래로 내려 다음 페이지로 이동할려고 했더니.... 1 과 2 사이에 마우스가 끼여 2~3번 클릭 포인터를 맞춰 겨우 다음 페이지로 넘겼는데.... 헉... 다음 페이지에는 남자용 조끼가 없더군요.
이렇게 몇번 익히고 나니... 옥션, G마켓에서 다음페이지를 넘기는 확률이 줄어들더군요.
3. 친절한 Number 씨~!!
특히 페이지 넘김에서 번호로 숫자를 표기하는 것은 거의 관례가 되어 있는 듯 합니다.
페이지 넘김을 다른 방법으로 표시할 수는 없는가? 꼭 하단이 아니라 다른 곳에 둘 수는 없는 가? 그런 고민은 기획자가 잘 고민해야 보아야 할 문제 인것 같습니다.
여기에.... 불친절한 Number씨와 친절한 Number 들이 있습니다. 강팀장은 갈수록 친절해져가는 번호들을 보면... 아~ 싶을때가 있습니다. 한편으로 참 꼼꼼하게 기획을 했구나...
피츠의 법칙이 적용되는 3가지의 경우를 보았습니다. 그런데 강팀장이 소개한 것들은 모두 숫자와 관련이 있습니다. 하지만, 숫자만 그런 것이 아닙니다. 디자인을 위해 갈수록 작아지는 버튼들, 각종 TEXT 클릭(12PT 보다 더 작아지고 있습니다.), Office를 업그레이드하면서 고맙게 사용하는 MS 리본메뉴... 등등....
피츠 법칙은 디자인 보다 사용자 중심의 법칙 입니다.
기존에는 디자인 기술이 웹의 다른 기술보다 회선이라는 제약 때문에 느리게 진화를 했습니다. 그렇다 보니 다양한 효과와 이미지를 쓰지 못한것에 비해 지금은 더욱 넓어진 선택의 폭을 가지고 있는 것은 웹개발자(기획, 디자인, 개발) 모두에게 행복한 고민이 되었습니다.
잘 다듬을수록 좋은 아이디어와 좋은 방법이 나올 것 같습니다.
그런 의미에서 피츠의 법칙은 개발자에게 제한이라 여기기 보다... 내가 만든 작품에 사용자가 더 친숙하고, 쉽게 다가 오도록 도와주는 법칙입니다.
Prev
Rss Feed