'2009/04'에 해당되는 글 11건

  1. 2009.04.30 의사와 컨설턴트의 4가지 공통점 (3)
  2. 2009.04.28 (배치 고도화) 2. 명확한 목표 설정 (2)
  3. 2009.04.27 여의도 출근 (8)
  4. 2009.04.25 (EA/ISP) 3. 정보 기술 동향 파악하기 (4)
  5. 2009.04.25 (EA/ISP) 2. 환경 분석 과정에서 고려해야 할 것들

몇 가지 실수를 통해 느낀 바가 조금 있어, 그것을 의사란 직업에 빗대어 정리해봅니다.

1. 진단 없이 섣부른 판단이 담긴 내용을 함부로 발설해선 안된다.

예전에 얼굴색이 어두운 환자의 간을 수술해서 그 환자의 병을 고친 경험이 있는 의사가 있다고 치자.  마침 어느날 그 전과 유사한 얼굴색이 어두운 환자가 찾아왔다. 그 의사가 자기를 찾아온 새로운 환자에게 낯빛이 안좋으니 배를 째야 겠다. 예전에도 그런 경험이 있기 때문에 뻔하다. 라고 진단을 내린다면 그게 과연 옳은 행동일까?

설사 그 환자가 빠른 조언을 원한다고 하더라도, 진단을 한 다음 처방을 말씀드리겠다고 전해야 한다. 어쩔 수 없이 빠른 판단을 내려야 하는 경우라면, 진단을 해보지 않아 정확하지 않다는 단서를 달고, 이럴 가능성도 있다는 수준의 정보임을 정확히 주지시켜야 한다.

2. 환자를 이롭게 하기 위해 최선을 다하며, 필요하다면 하기 싫어하는 일도 하도록 설득해야 한다. 단, 요령이 필요하다.

날씬하다는 말을 듣고 싶어하는 뚱뚱한 환자가 찾아왔다고 해서, 환자가 원하는 대로 당신은 날씬하고, 아무 문제가 없다고 말해버리는 사람은 의사가 될 수 없다. 설사 듣기 싫어하는 말이라고 하더라도 당신은 체지방이 초과되었으니, 반드시 체중을 10kg 이상 줄여야 한다고 말할 수 있어야 한다. 

그러나 그 사람이 그런 말을 바로 듣고도 수용할 수 있는 성격인지, 아니면 설득해야 되는 사람인지, 설득한다면 어떤 장소에서 어떤 방법으로 전달하는 것이 효과적인지, 그 일을 하는 방법을 운동으로 하도록 권유해야 하는 상황인지, 지방흡입수술까지 취해야 하는 상황인지 등은 개인의 성향과 상황에 따라 다를 수 밖에 없다. 그런 상황을 신중히 고려해서 결국 그 환자가 건강해도록 만드는는 것이 환자로써 의사를 찾은 사람에 대한 최소한의 책임이다.

3. 고객과의 관계에서 알게 된 모든 내용은 어떤 사소한 것이라도 절대 새어나가도록 해선 안된다.

환자가 SI에 걸렸다. 그 원인을 살펴보니 미국 출장 중에 몰래 멕시코에 잠깐 휴양차 들린 것이 드러났다. 그 환자 왜 SI에 걸린 줄 알아? 세상에 출장가서 놀고 온거 있지?라는 식의 정보를 친구와의 술자리에서 조차 외부에 발설해선 안된다. 고객과의 정보보호서약을 맺은 의사에게는, 술자리에서 내뱉는 사소한 그런 말 실수 조차 범죄가 될 수 있다.

4. 새로운 치료법에 지속적으로 관심을 가지되, 임상실험을 마치지 않은 치료법을 환자에게 함부로 처방해서는 안된다.

임상실험을 마친 더 안전하고 효과적인 치료법이 개발된 상황에서, 단지 내가 아는 방법이 그것 뿐이라고 아는 방법으로만 치료하는 의사가 되어선 안된다. 그런 상황을 방지하기 위해서는 설사 결국 그게 그거라는 결론에 도달하더라도 더 나은 치료법에 대한 조사와 공부, 훈련을 게을리 해서는 안된다.

하지만 그렇게 알게된 새로운 치료법에 논리적으로 타당하고 아주 효과적일 수도 있다고 생각 되더라도, 이제 갓 학회에 보고되어 임상실험 조차 거치지 않은 치료법을 최신 기법이니 더 효과적일거라는 생각만으로 환자에게 함부로 처방내리는 것은 지극히 위험함 행동이다. 검증되지 않은 치료법은, 설사 일견 효과적일 것 같은 판단이 들더라도, 그 환자의 체질과 맞지 않을 수도 있고, 설사 치료된다고 하더라도 또 다른 부작용을 야기할 수 있는 가능성이 얼마든지 있기 때문이다.

저작자 표시 비영리 변경 금지
신고

주의 : 쓰다보니 너무 길어졌습니다. 정성들여 쓴 글이나 지루하실 수 있는 글이므로 섣불리 관심을 두고 읽지 말아주십시오. 후회해도 모릅니다. ^^

비전 정의란?

일단 가벼운 퀴즈 하나. 인터넷에서 자주 보이는 아래 그림에서 명확한 목표를 설정한다는 것, 다른 말로 비전을 정의하는 것(Visioning)은 어떤 모습을 찾아내기 위한 걸까요?


비전 정의가 고객이 설명한 요건을 그대로 받아 적는 것 또는 영업이 약속한 그 비용과 일정, 인력으로는 도저히 불가능한 휘황찬란한 약속을 최대한 방어적으로 만드는 것 등으로 곡해하기 쉽지만, 제대로 된 비전 정의고객이 정말 필요한 것을 찾아내는 과정과 그 결과물, 그리고 목표한 그것을 고객과 개발팀이 함께 바라보고 추구하도록 만들도록 변화시키는 것이라고 생각합니다.

일반적으로 어플리케이션 개발 LifeCycle은 Metrozen이라는 외국의개발 업체 홈페이지에 떡~하니 올려둔 그림에서 보듯 Definition, 그러니까 해결하고자 하는 Problem에 대한 정의 [What] 에서 부터 출발합니다. 지금껏 교육이나 수 많은 서적들을 통해 이미 확고하게 결정되어 있는 문제들을 어떻게 기술하는지, 그걸 어떻게 분석하고 설계하는지, 또 어떤 기술들을 써서 구현하고, 테스트하는지 등을 훈련해온 (저를 포함한 ㅠㅠ)엔지니어들은 어떻게 하면 그 문제를 잘 풀어낼 것인가 [How]를 두고 경쟁하듯 그 기술의 깊이와 넓이를 확장해 나가는데만 집중하는 경향이 있습니다.  애당초 그 일을 왜 시작하게 된 것인지는 생각조차 하지 않은채, 때론 자존심을 걸고 열띤 토론을 펼치는 그들만의 리그(?)를 개최하기도 하면서요.


흔히들 프로그래밍을 문제 해결(Problem Solving)이라고 표현합니다. 즉 Problem + Solution이 합쳐진 것이죠. 프로그래밍이 소프트웨어 공학의 수준으로 발돋움하기 위해서는 Right Problem + Right Solution이 필요합니다. Any Problem + Same Solution(어떤 문제는 내가 아는 방식으로 풀어주마~)도, Wrong Problem + Right Solution(문제가 무엇이든 최선의 해결책을 찾아주마~)도 모두 답이 아닌 것이죠.

그런 점에서 딜로이트의 EVD(Enterprise Value Delievery) Methodology는 그 구성과 이름이 무척 마음에 듭니다. 보통 방법론은 xxCBD와 같이 반복 개발이니, 컴포넌트 기반 개발 기법을 채용해 트렌드를 따른다느니 하는 기술적인 느낌을 드러내죠. 고객 입장에서는 Enterprise Value를 Delievery하겠다는 EVD란 이름이 더 마음에 들지 않을까요? 그리고 비전 정의와 Planning이 제일 앞에 위치한 점도 바람직합니다. 사실 비전을 명확히 하면, 제안 단계에서 제출했던 계획을 새롭게 뜯어 고쳐야 하는 경우가 많으니까요. 그런 이유로 일정을 뒤틀어버리면 고객이 두고만 보지는 않을거라구요? 그게 정말 필요한 것이라면 방법은 찾기 나름이겠죠. 안되는 이유를 찾아 정리하고 남 핑계대며 뒷다마 깔 시간을 아끼면, 가능한 방법을 찾을 수 있을지도..



배치 개발에 있어서의 경험 사례

쓰다 보니 서두가 길어졌는데요, 시간을 절약하기 위해 실제 경험은 느낌 위주로 간추려 얘기하겠습니다. 고객 정보가 담긴 프로젝트 상황을 공개할 수는 없기 때문에 공감하기 힘드실 수도 있구요.

(1) 니나 내나~ 모르는 건 마찬가지다.
전체 프로젝트의 1/7을 비전을 정의하는데 사용했습니다. 결국, 초반에는 서로가 서로의 입장과 말을 이해하지 못하고 있는 상태인거죠. 안될 줄 뻔한 이상적인 모습으로? NO! 구현 기술만 바뀌었지 이전과 별 차이없는 형태로? NO! 개발팀만 편한대로도 당연히.. NO!

다 옳은 말이고, 또한 다 자신의 시각과 바람대로만 주장하는 것이기도 하죠. 수 많은 이해 관계자들이 공감할 수 있는 비전, 각자의 의견을 받아들이고 검토하는 과정에서 서로의 입장 차이를 좁혀나가는 것. 그리하여 결정된 비전이 설계 과정을 빗대어 말하자면 4+1 View에서 UseCase View 역할을 하도록 만드는 것이 중요했습니다.

(2) 비전은 구체적일 수록 효과적이다.
그런 과정을 통해 도출된 비전은 뜬 구름 잡는 소리가 아니라 보다 구체적이고, 측정가능하며, 확인가능한 형태를 띄게 됩니다. 예를 들면 "월 마감을 기존보다 X일 줄이자"라거나, "기존 배치 프로그램을 최적화 해서, 실제로 운영될 전체 본수를 X0% 없애자"라는 형태가 되겠죠. 그렇게 구체화된 비전은 자연스럽게, 실제로 그렇게 될 수 있는 수준으로 구체화되고 프로젝트의 목표로 자리 잡습니다.

(3) 일정이 문제가 된다면, 병행해서 추진하라.
그 비전을 만드는 시점은 이미 제출했던 프로젝트 수행 계획서 상, 문제를 정의하고 분석하는 단계일 확률이 높습니다. 모두 다 비전을 정의한다고 손 놓고 있으면 고객이 불안해 할 수도 있겠죠. 그러나, 다행스럽게도 비전 정의에 전체 프로젝트 팀이 투입될 필요는 없습니다. 일정은 계획한 대로 진행하면서, 얼마든지 비전 정의를 병행으로 수행할 수 있죠. 폭포수로 짜여진 일정 계획 내에서 UP의 반복 개발을 성공적으로 적용하는 사례가 수 없이 존재하 듯 말이죠. 정말 소중하고 가치가 있다고 믿는다면, 방법은 얼마든지 있습니다.

(4) 조직이 복잡할 수록, 비전은 위력을 발휘한다.
미리 결정된 듯한 문제를 잘~ 푸는 것 만으로도 월화수목 금금금.. 이라고 생각할 수도 있습니다.  그런 생각이 드신다면 자신의 경험을 잘 되살려 보시길 바랍니다. 정말 힘든 것이 야근이였을까요? 저는 사람에 치이고, 서로 협조가 안되고, 이 일을 왜 해야 하는지 모르겠고.. 그런 상황을 만나는 것이 몇 일 야근하는 것보다 훨씬 더 힘들었습니다. 잘 정의되고, 조직에 전파된 비전은 항상 일정하게 가야할 길을 가르키고 있는 나침반과 같은 역할을 합니다. 업무와 기술이 다르고, 개발과 운영의 입장이 다르고, 서로 갑/을/병/정의 복잡한 계약 관계로 얽혀있을 때, 비전은 위력을 발휘했습니다. 기술적인 위험이 높아 자기 회사의 책임으로 떠 맡기 싫어 붕 떠버린 애매한 경계의 일거리가 있을 때, 새로운 것을 익히기 싫어 공격적인 반응을 보일 때.. 그들이 원하는 TO-BE 모습이 골고루 반영된 현실적인 비전은, 그런 장벽을 넘어설 수 있게 해주는 가장 큰 힘이 되어 주었습니다.


가슴아픈 실패담

(아침에 다시 읽고, 내용이 지나치게 상세해서 수정함)
기술적으로는 더 없이 훌륭했으나, 전체 프로젝트 측면에서는 실패했던 경험이 있습니다. 잘 만들었다고 잘난척하며 자부했던 그 시스템은 결국 세상에 빛을 보지 못했습니다. 흔히 얘기하는 정치에 희생된 경우라고 볼 수도 있지만, 돌이켜 생각해보면 제 잘못도 큽니다. 프로젝트 리더로써 고객이 정말 필요한 것을 좀 더 고민하고, 그 비전을 고객과 개발팀에 전파함으로써 같은 목표를 향해 달려가도록 만드는 가장 중요한 비전 정의 과정을 너무나 소홀했고, 구현의 완성도에 개인적인 욕심을 가졌던 그런 시건방짐이 그 시스템을 묻어 버리게 만든 근본적인 원흉 중의 하나일 수 있음을 깨달았기 때문입니다. 

우리가 사는 것도 마찬가지 아닐까요?

때 마침 이웃 블로그들에서 비슷한 주제로 글이 올라왔습니다. 자기 계발을 넘어서란 글이나, 사실을 행동으로 바꿔라는 글은 모두 Why를 깊게 고민함으로써 진정한 What을 찾아내는 전략적 사고와 비전 정의의 중요성을 다루고 있습니다. 아름다운 기부 청년으로 유명한 고영 컨설턴트의 인터뷰는 이런 비전 정의가 삶과 어떻게 이어지는 지를 보다 적나라하게 드러내고 있습니다.

“비전이라는 것을 무엇으로 정의하는가가 중요합니다. 많은 사람들이 who to become으로 비전을 정의해요. 내가 어떤 존재가 되겠다라는 생각을 합니다. 그러면 계속 포지션을 중요하게 생각하게 됩니다. 가령 대통령이 되고 싶다든가, CEO가 되고 싶다는 식이죠. 물론 이런 것도 좋지만, 대통령이 되려고 하는가에 대한 고민이 먼저 이루어져야 합니다. 대통령이라면 만들고 싶은 국가의 모습, 조직의 모습을 그려보는 것이 선행되어야 합니다.”

저는 도전하고 싶은 꿈을 찾는데 오랜 시간동안 많은 고민을 해야 했습니다. 처음 꿈을 찾았을 때, 꿈의 형태는 특정한 포지션이였습니다. 그 꿈을 품에 담고 있는 시간이 길어지면서, 자연스럽게 그 꿈을 이뤄내기 위한 원칙과 확신이 하나씩 늘어났습니다. 지금은 오히려 그 원칙과 확신이 지켜지는 모습을 만들어 낼 수만 있다면 처음 생각했던 그 포지션은 중요하지 않게 느껴집니다. 전 그것을 요즘 유행하는 Buzz를 본 따 물개의 Dream 2.0이라고 부릅니다. 일을 통해 하나씩 깨달음을 얻어 갈 때 마다, 그 만큼 삶도 풍요해지는 것이 느껴집니다. 우린 정말 매트릭스에 갇혀 있는 건 아닐까요? ^^

저작자 표시 비영리 변경 금지
신고

여의도 출근

이전글/2009 2009.04.27 08:11
오랜만에 여의도로 출근했습니다. 정확히 1년하고도 2개월만이네요. 본사에서 일하는 걸로 알고, 술 한잔하자고 청하는 분들이 있을 것 같아 블로그로 근황을 올립니다.

어제는 미용실에서 머리도 단정하게 하고, 활기차고 단정한 인상을 주기 위해 옷에도 신경을 좀 썼습니다. 첫 인상을 무시하지 못하니까요. 좀 서둘러 출근했더니 시간이 많이 남아 근처 PC 방에 들러 어떤 가치들을 어떻게 전달할 것인지를 고민했는데 그러고도 시간이 남네요. 이번 프로젝트는 규모가 작아 명확한 롤이 정의되지 않았고, 투입 기간도 짧습니다. 짧은 기간 내에 많은 일들을 만족할만한 수준으로 진행하기 위해서는 현재 프로젝트 상황에서 어떤 것들이 정말 가치 있는 일인지를 빨리 파악해야 할텐데, 걱정이네요. 문득 8~9년 전쯤에 대학에서 보따리 장수하던 시절이 떠오릅니다. 새로 맡은 과목에 대한 준비를 하면서, 어떤 학생들을 만나게 될까 궁금하고 설레기도 했던.. 처음 서울에 와서 일한 곳이 여의도여서 그런 걸까요? 왜 이렇게 설레고 빨리 일하고 싶어 몸이 근질거리는지 모르겠네요. 이제 잠깐동안 함께 같은 문제를 고민할 분들을 만나기까지.. 20분 남았습니다.

아침에 보니 날씨가 정말 좋더군요. 이 좋은 봄날에 다른 분들도 힘차게 한 주를 시작하시길 바랍니다.
저작자 표시 비영리 변경 금지
신고
환경 분석 단계에서 TA는 정보 기술 동향을 파악하는 작업을 합니다. (가끔 AA와 함께 진행하기도 합니다.) 정보 기술 동향 파악의 핵심은 단기간에 집중할 영역을 분명히 해서 작업하는 것입니다. 앞선 글에서 밝혔듯이 환경 분석 단계에서 고려해야 할 것들이 많을 뿐 아니라, 정보 기술 동향을 빠르게 마무리 짓고 보다 더 중요한 현황 분석 단계를 서둘러 진행하기 위해서입니다. 정보 기술 동향을 빠르게 파악하기 위해 제가 사용한 몇 가지 팁을 얘기해 보겠습니다.

1. 정보 기술 동향 분석 단계의 진행 절차
정보 기술 동향 분석은 일반적으로 4개의 세부 단계를 거쳐 진행됩니다. 
  1. 거시적 IT 동향 분석
    큰 관점에서 정보화 동향을 분석하는 단계입니다. 차세대 시스템 구축을 포함한 금융 정보화 동향을 분석하는 일과, Gartner의 HypeCycle이나 Forrester Wave등의 통계 자료를 이용해 기술 자체의 동향을 파악하는 일로 나눌 수 있습니다. Emerging Technology들은 어떤 것들이 있는지, 주요 기술 별로 어떤 것들이 성숙 단계에 있고, 어떤 것들이 아직 캐즘을 벗어나지 못하고 있는지, 어떤 업체의 어떤 솔루션이 시장을 선도하고 있는지 등을 정리한다고 보면 됩니다.
  2. 핵심 요소 기술 선정
    거시적 IT 동향 분석을 끝낼 때 쯤이면, 장표화되지는 못했더라도 다른 파트에서 진행하고 있는 내.외부 환경 분석 자료를 전해 들을 수 있습니다. 2가지 자료를 종합해서 영역 별로 깊이 조사할 필요가 있는 핵심 요소 기술을 선정합니다. 이때 선정될 요소 기술들은 해당 기업의 비전을 달성할 Enabler 역할을 수행해야 합니다.
  3. 핵심 요소 기술별 상세 동향 분석
    핵심 요소 기술을 선정했다면, 각 요소 기술 별로 개요/발전 방향/도입 배경/기대 효과 등을 정리합니다. 템플릿에 지나치게 의존하지 않고 실질적인 자료 중심으로 내용을 구성하고, 조사 대상이 지나치게 많지 않도록 20개 내외로 결정하는 것이 좋은 것 같습니다. 
  4. 적용 가능성 평가 및 종합
    기술의 성숙도나 적용 용이성, 도입 및 유지에 소요되는 비용, 전략적 중요도 등을 고려해 각 요소 기술을 평가하고, 향후 적용을 고려할 우선 순위를 판단합니다.

2. 평소에 준비하라
금융권에서 시스템을 운영하시는 분들은 자부심이 높고, 그만큼 크리티컬한 시스템을 십 여년간 운영해 오며 쌓인 특정 분야에 대한 노하우가 많기 때문에, 그 분들이 자신하는 특정 영역에서는 책에 나오는 뻔한 얘기 정도는 우습게 보는 구루들이 포진해 있습니다. 또한 아주 일부이긴 하나 제대로 실천하지 못했던 경험으로 인해 특정 기술이나 기법에 대한 지나친 불신을 갖고 계신 경우도 있구요. 특히 컨설팅을 많이 받아본 업체들은 컨설턴트에 대해 공격적인 경향을 보이는 경우도 많습니다. 프로젝트 초반에 그 분들로 부터 인정을 받지 못한다면, 프로젝트를 진행하는 내내 늑대들에 둘러 쌓인 불쌍한 양의 신세로 전락해 버릴 수도 있는 것이죠. 정보 기술 동향을 정리해서 제출하는 것은 말로만 떠들던 것을 실천해 낼 수 있다는 것을 보여줄 수 있는 기회임과 동시에, 거꾸로 어디서 줏어들은 몇 마디 말로 아는 척 떠드는 가짜 컨설턴트인지를 밝혀내려는 고객들 틈에서 무사히 살아남아야 하는 엄청난 위기이기도 합니다.

그런 일을 2주 정도의 기간 내에 신뢰를 얻을 수 있는 수준으로 해내기 위해서는 평소에 열심히 준비하는 수 밖에 다른 방법이 없습니다. 또한 모든 자료를 직접 처음부터 끝까지 직접 다 만들어야 직성이 풀린다는 엔지니어로서의 집착에서 벗어나야만 합니다. 사실, 다른 사람이 만든 자료를 활용할 수 있는 유일한 단계가 정도 기술 동향 뿐이긴 하지만요. 구체적인 준비 방법은 각자 다르겠지만 제 경우는 필요성을 느낀 뒤부터 2년 동안 특정 주기 별로 9개의 카테고리로 분류한 관련 자료를 찾아서 읽고, 쓸만한 자료들은 정리하는 일을 계속해오고 있습니다. 아래 그림은 제 하드디스크 속에 있는 기술자료 정리 폴더의 구성과 일부 내용입니다.

  • 세미나 : ITSM, BPM, KM_EDMS, SW산업전망, ERP, 아키텍처, 개발 등 주요 업체나 주제별 세미나 자료를 모아둡니다. 3~4개 정도는 직접 참석하구요, 직접 참석하지 못한 세미나는 기억해두고 있다가 홈페이지 등에 자료가 공개되는 시점에 자료를 수집해 읽어둡니다. 업체 홍보성 자료는 별 쓸모가 없으니 삭제하고, 대가들의 자료를 중심으로 다시 참조할 것들만 선별해 모아두는 것이 요령입니다.
  • 기술이슈 : 기술 이슈는 특별히 정해진 규칙 없이 관심있는 우수 자료들을 선별해 모아두고 있습니다. 처음에는 TRM 형식으로 세분화해서 관리했는데, 디렉토리가 너무 많으니 오히려 번거롭더군요. 그래서 그냥 제가 알아볼 수 있는 형태로 디렉토리를 단순화하고, 해당 주제 내에 자료량이 많아지면 서브 디렉토리를 두는 방식으로 관리하고 있습니다.
  • 금융정보화 디지털타임즈대한금융신문 등에서 금융 정보화와 관련된 기사를 수집해 정리합니다. 디지털타임즈를 효과적으로 이용하는 방법은 "금융 IT 혁신과 도전"이란 매년 발간되는 책을 이용해서 주요 주제를 파악하고, 해당 주제에 대해 주기적으로 몰아서 검색하는 방법입니다. 보험개발원이나 은행연합회, 증권업 협회 등에서 주기적으로 발간하는 금융정보화 동향 자료 등을 구독하시는 것도 도움이 됩니다.
     

  • TRM/SP : 자신만의 기술 참조 모델을 만들어 업데이트하고, 가상의 금융 그룹이 있다고 가정하고 자신이 CIO라면 어떤 표준 프로파일을 갖도록 하고 싶은지를 고민한 최상의 표준 프로파일을 만들어 보는 것도 좋습니다. 게으름과 능력 부족으로 이 폴더는 아직도 절반도 채 완성되지 못한채 진행 중인 상태입니다. 쩝..
  • 글로벌통계 : 전 포레스터와 가트너의 자료를 중심으로 보고 있습니다.


3. 집중할 영역을 찾고, 적용 가능성을 평가하라.
파레토의 법칙(80-20 Rule)은 정보 기술 동향 파악에 딱 들어 맞는 말입니다. 평소에 준비해둔 내용으로 대부분의 정보 동향에 대한 문서화 작업을 최대한 빠른 시간 안에 마무리 짓고, 고객이 특히 관심있어하는 특정 분야에 대해 진지한 고민을 해야 합니다. 어떤 기업은 차세대 전반에 걸쳐 SOA를 적용하는 것이 과연 현실적인가를 고민할 것이고, 어떤 기업은 잘못 도입된 채널 통합 솔루션을 걷어내고, 그 자리를 대체하는 새로운 MCI 제품과 ESB의 관계를 궁금해 할 수도 있습니다. 혹자는 상품 팩토리가 자통법으로 인해 우후죽순 늘어나는 파생 상품을 얼마만큼 커버할 수 있는 지를 궁금해할 수 있고, IFRS를 준비하는 기업에서는 공정가치평가 솔루션이나, 새로 도입될 연결회계시스템 등에 대해 지대한 관심이 있을 수 있겠죠. 그런 고객의 Needs를 파악해서 해당 영역에 대해 보다 구체적이고, 깊은 자료 조사와 동향 파악이 필요합니다. 

정보 동향 파악의 목적은 기술이 어떻게 발전해 가고 있고, 다른 회사들은 어떤 기술이나 솔루션을 이용해서 구축하고 있는지를 알아보기 위한 세미나를 하자는 것이 아닙니다. ISP에서 정보 동향을 파악하는 목적은 딱 한가지 입니다. 그 기술이 과연 현 시점에서 적용을 고려해야 할 가치가 있는 것인가? 가치가 있다면 어떤 것들이 제대로된 레퍼런스를 확보한 기술인가? 하는 것이죠. 이 시점에서는 해당 조직의 투자 성향을 이해하는 것도 중요합니다. 국내에 레퍼런스가 없더라도 해외 레퍼런스가 있고 기술의 성숙도가 높다면 경쟁력 강화를 위해 위험을 감수하는 조직인지, 아니면 반드시 동종 업계에 레퍼런스가 있어야 해당 기술을 받아들이는 안정성을 추구하는 조직인지와 같은 것들 말이죠. 선두에 선 업체 일수록, 기대 수준이 매우 높기 때문에 국내 레퍼런스가 없어도 기술 성숙도가 충분하다는 것만 인정되면, 조직 역량을 믿고 신기술을 수용하는 경우가 많습니다.

차세대 시스템 구축을 목적으로 ISP가 발주된 경우라면, 유사 업종의 시스템 구축 사례를 정리해 줄 필요도 있습니다. 이 때 주변의 인맥을 활용해서 Best Practice로 삼을 만한 사례를 정리해서, 향후 사례 연구 등으로 인터뷰할 대상을 미리 선정해 두는 것도 발표 시 고객의 질문에 쉽게 대응할 수 있는 요령입니다. 안좋은 일에 대해서는 잘 밝히려 들지 않지만, 자랑하고 싶은 내용을 궁금해 하면 의외로 쉽게 고급 정보를 얻을 수 있고 덤으로 시간 낭비를 줄일 수 있는 귀중한 주의 사항 등을 전해 들을 수도 있습니다.

그리고, On-time, On-budget, High-quality 중에서, On-time 즉 제때 마무리하겠다는 결심이 중요합니다. 중간에 기술적인 탐구 욕구가 지나쳐 시간을 어기는 일이 있어서는 안됩니다. 이어지는 현황 분석이 더욱 중요하기도 하거니와, 정말 중요한 영역에 대해서는 현황 분석 뿐 아니라, 목표 시스템 설계 단계에서도 몇 번이고 반복해서 더 깊이 조사할 필요가 흔히 발생하기 때문입니다.





저작자 표시 비영리 변경 금지
신고

환경 분석은 중.장기 정보화 전략을 수립하기 위한 사전 이해 단계로써, 시장에서 어떤 변화 들이 일어나고 있는지를 분석하는 외부 환경 분석과, 고객사 내부에서 어떠한 변화 방향을 설계하고 있는지를 이해하는 내부 환경 분석, 정보 기술의 주요 변화 동향과 구체적인 기업들의 도입 현황을 파악하는 정보 기술 동향 분석 등을 수행합니다.

환경 분석 단계에서 고려되어야 하는 것
보통 4개월 동안 ISP가 진행된다고 했을 때 2~3주 정도 환경 분석을 진행하게 되는데요, 첫 단계이기 때문에, 환경 분석이라는 본래의 일 외에 동시에 고려되어야 하는 것들이 몇 가지 있습니다.

1. 프로젝트 범위와 방법론에 대한 합의
제안팀과 프로젝트 팀이 다른 경우가 많기 때문에, 전체 프로젝트에 대한 범위와 방법론, 구체적인 일정을 확정짓고, 고객과 합의할 필요가 있습니다. 가끔 제안 단계에서 불필요한 산출물을 잔뜩 써놓거나 정작 중요한 것들은 빼먹는 경우가 있기 때문입니다. 최대한 빨리 전체에 대한 밑그림을 그리고, 고객이 기대하는 것과 일치시키도록 각 파트 담당자들과 깊이 있게 소통해야 합니다.

2. 팀웍 다지기와 R&R 정의
ISP 팀은 다양한 전문 지식을 필요로 하기 때문에 여러 회사로 구성된 연합군일 때가 많고, 그렇지 않더라도 계속 함께 일해오던 사람들이 아니기 때문에 초반에 팀웍을 다질 필요가 있습니다. 보고서 양식을 통일하는 자잘한 것에서 부터, 그 사람의 업무 스타일을 파악하는 것까지 세심하게 서로를 이해하려 노력해야 합니다. 또한, EA 기반의 ISP에서는 특정 분석이 2개 이상의 영역에 묘하게 겹쳐 있는 경우가 자주 발생합니다. 이때 타인의 업무 영역을 무뢰하게 침범하지 않으면서도 시너지 효과를 내기 위해서는 본인의 역할을 분명히하고, 누구와 어떤 얘기들을 나눠야 할지를 미리 고민해둘 필요가 있습니다. 이 때 문맥도(Context Diagram)를 그려보는 것이 무척 효과적이었습니다. (Younghoe.info에서 문맥도 샘플을 가져와 올립니다.)


실수. 세심한 배려가 뒷받침 되지 않은 도움은 오히려 해가 된다. 
커뮤니케이션에서 특히 중요한 것이 상대방에 대한 진심어린 배려인 것 같습니다. 모 프로젝트에서 저는 거버넌스 체계를 설계하던 어떤 분과 다툰 적이 있는데요, 그 분이 설계하신 인력 활용 방안이 너무 현실과 맞지 않다고 판단해서 생긴 의견 충돌이였습니다. 그런 일은 프로젝트 기간 내에서 비일비재한데요, 문제는 함께 상주하던 TF 조직 앞에서 제 의견을 너무 강하게 내세운 것이 실수였습니다. TF 조직과 오래 함께 있다보니 너무 친해져서 그 분들이 같은 자리에 있다는 것을 잠시 의식하지 못했었는데, 해당 영역에 대한 고객의 신뢰가 흔들릴 수 있는 위험을 미처 생각하지 못한 것이죠. 그 분이 먼저 자신이 만든 방안에 대해 의견을 물어오셔서 시작된 토론이였지만, 정말 그 분의 작업을 도와주고 싶은 생각이였다면 고객이 없는 자리에 가서 제 의견을 전달하는 세심함이 필요했던 것입니다. 

느낌. 책임감도 등급이 있다.
함께 한 PM 중에서 팀과의 대화 때도 항상 고객을 "우리 회사"라고 표현하는 분이 계셨습니다. 모질고 터프하게 일하기로 유명한 분이셨는데요, 프로젝트가 끝나고 생각해보면 "상사가 귀신 같아야 부하가 움직인다"라는 책[각주:1]을 그대로 옮겨 놓은 듯한 분이였습니다. 전 처음 접하는 타입이였는데요, 전 영역의 산출물을 꼼꼼하게 다 읽어보고 논리의 오류를 짚어내고, 시너지 효과가 필요한 영역을 찾아서 협업을 요구하는 분이였죠. 처음에는 일 중독이신지 의심될 정도였는데, 돌이켜 생각하면 책임감이 크셨기 때문인 듯 합니다. 함께 들어온 인턴에게 마치 삼촌처럼 기초부터 하나 하나 자상하게 가르쳐주시는 모습을 보고, 그 분의 원래 성격이 그렇지 않다는 걸 알았죠. 그 책임감이 자연스럽게 고객을 우리 회사라고 말하도록 만드는 게 아닐까 하는 생각이 들었습니다. 4개월을 함께 있다보면, 그게 가식인지 아닌지 드러나쟎아요? 일하는 동안은 요구하시는 것이 많아 참 불편했지만, 끝나고 나서는 가장 기억에 남는 분이기도 합니다. 모 회사 CIO 분과의 회식 자리에서 들었던 말이 기억나네요. 그 분이 자주하는 면접 수법이 있는데, 조직도를 그려보라고 해서 맨 위에 CEO가 나오면 무조건 탈락시킨다는. 맨 위에 고객을 그리고, CEO를 맨 밑에 지원 조직으로 그리는 놈이 진짜라는.

  1. 개인적으로 느낀 바가 많았던 책인데, 의외로 인기가 없더라구요. 동료나 직원들에게 좋은게 좋은거지라는 심정으로 무책임하게 좋은 말만 늘어놓고 싶은 욕심이 생길 때 읽어보면 도움이 됩니다. [본문으로]
저작자 표시 비영리 변경 금지
신고
1 2 3 

글 보관함

카운터

Total : 249,260 / Today : 0 / Yesterday : 14
get rsstistory!