달력

06

« 2009/06 »

  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  •  
  •  
  •  
  •  

개발자로 일하다보면 직간접적으로 고객의 요구를 직접 수용하게 되는 상황이 자주 발생하게 됩니다.
큰프로젝트에서는 업무를 나눠 진행할 때 PM이나 중간 관리자가 요구를 수용해서 전달해 주기도 하지만 작은 조직이나 소규모 프로젝트에서는 개발자가 직접 고객의 요구를 듣고 파악해서 작업을 하기도 합니다.

아무튼 어떤 형태로든 이렇게 전달된 고객의 요구를 정확히 파악해서 결과물이 만족스럽게 나왔다면  별다른 문제가 없겠지만 반대의 경우라면 어떨까요? 아마 시간을 들여서 다시 작업하거나 개발자 탓이네 고객 탓이네하며 분쟁을 일으키게 될 수도 있을 겁니다.

이런 분쟁 그리고 리스크를 최소화 하는 방법이 매우 많겠지만 제가 주목하고 싶은 부분은 바로 비판적 사고라는 부분입니다. 특히 소규모 프로젝트에서는 더더욱 필요한 부분이라고 생각됩니다.

비판적 사고에 의해 프로젝트 하부단에서 발생된 문제가 위쪽으로 번지는 것을 일차적으로 막아주기 때문이라고 생각되기 때문입니다. 프로젝트 하부단에서 리스크가 일차적으로 잘 처리된다면 그만큼 프로젝트의 성공 가능성이 높아지기 때문입니다.

프로젝트에서 고객은 대부분 자신이 하고 싶은 것을 머릿속에 의식적이든 무의식적이든 마인드 맵을 그려가면서 마구마구 말합니다. 고객이라면 당연히 그렇겠지요. 제가 고객이라도 그럴 거 같습니다. 신나잖아요? ^^

고객과 회의를 하면서 그들의 요구를 듣고 나의 머리 속에 주입되는 과정을 한번 생각해 보겠습니다.
하나의 테이블에 고객과 내가 마주보고 있습니다.
고객은 원하는 결과물의 이미지를 머릿속에서 추상화 시켜 나에게 필요한 것들을 쏟아 냅니다.
개발자인 나는 고객의 머릿속에 떠오르는 이미지의 결과를 그 고객의 입을 통해 음파로써 내 귀에 전달할 것이고, 귀에 도달한 그 음파는 달팽이 관을 통해 신호로 변경되어 나의 뇌에 전달된 신호를 이미지화 하고 난 그런 이미지를 추상해서 요구를 파악하게 됩니다.

그런데 위에 언급한 과정 중 단 한곳에서라도 문제가 발생한다면 어떻게 될까요?
예상 되는 문제를 생각되는 대로 모두 나열해 보겠습니다.

(고객 - 개발자 간의 커뮤니케이션 과정)

  • 고객 머릿속에 떠오른 추상적 이미지에 대한 표현이 올바르지 못한 경우
  • 고객 또는 개발자 어느 한쪽이든 발음이 어눌해서 요구 음파가 제대로 전달되지 못한 경우
  • 스스로의 귀가 안좋아서 제대로 요구를 듣지 못한 경우(또는 외부 소음에 의해 방해받은 경우)
  • 개발자 머리속에서 이미지 추상화 과정 중 발생한 에러(경험의 부재, 집중력의 문제 등)

이 외에도 여러가지 문제점들이 있겠지만 우선 생각나는 것이 이 정도 입니다.
문제가 발생하게 되면 고객과 내 머릿속에 그려진 추상적 이미지는 동일한 것이 아닌 서로 다른 형태의 이미지가 될 것입니다.

이런 올바르지 못한 것을 바로 잡기 위해 끊임없이 회의를 하고 비판을 통해 고객이 요구하는 참이 무엇인지를 가려내게 됩니다.

아래는 비판적 사고(Critical Thinking)의 정의를 보여줍니다.
다음백과사전 : http://enc.daum.net/dic100/contents.do?query1=10XXX45342

개발자가 프로그램을 아무리 잘 개발해도 요구를 정확하게 파악하지 못했다면 아무 쓸모 없는 프로그램이 됩니다. 역으로 고객이 자신이 믿는 바를 너무 과신한 나머지 비판적 사고를 할 생각은 하지도 못한채 밀어붙여도 마찬가지의 결과가 발생하게 됩니다.

커뮤니케이션 에러에서 오는 프로젝트의 여러가지 리스크를 비판적 사고를 통해 줄여본다면 어떨까요?
비판적 사고력.... 한번 키워볼만한 능력인 것 같습니다.

저작자 표시 비영리 변경 금지
Posted by -세티-
전 어렸을 적 꿈이 밤하늘을 마음껏 볼 수 있는 천문학자가 되는것 이었습니다. 
하지만 개인의 능력 부족으로 인해 원하는 곳을 갈 수 없었고 현실에 적응하게 되면서 이루고자 했던 꿈은 영영 저멀리 가버리고 말았습니다.

현실에 순응하며 하루하루를 살다가 시간이 흘러 잊었던 꿈을 조금씩 꺼내어 봅니다.
밤하늘을 보고자 했던 그 소망이 꼭 천문학자가 되어야만 이룰 수 있는 것도 아니라는 것을 오랜 시간이 흐르고 나서 알게 되었습니다.

그 업계의 전문가가 된 것은 아니지만 좋은 사람들과 함께 밤 하늘의 별을 찾아가는 작은 기쁨만으로도 충분했습니다. 시간을 쪼개어 밤하늘을 보는 건 쉽지 않습니다.
별을 보기 위해 밤에 잠이 없어야 하고 또 먼거리를 이동해야 하며 무엇보다 맑은 하늘이 늘 곁에 있는 것도 아니기 때문입니다.

그렇게 띄엄띄엄 별을 보다보니 익히고 잊어먹고를 수없이 반복하게 됩니다.
그래도 다행히 함께하는 사람들이 좋은 사람들이라 매번 잘 가르쳐 줍니다.
밤하늘을 조금더 쉽게 이해하면서 부담없이 읽을만한 책이 없을까 고민하던 중 한 권의 책을 소개 받았습니다.

그 책은 쳇 레이모가 쓴 '아름다운 밤하늘' 이었습니다.

아름다운 밤하늘 


이 책의 저자 쳇 레이모는 스톤힐 대학에서 40년간 물리학과 천문학을 강의 했다고 합니다. 과학저술가로 유명하다고 합니다.

이 책은 우리가 주변에서 흔하게 접하는 아주 유명한 별자리들을 어렵고 딱딱한 교과서적인 이야기가 아닌 매우 이해하기 쉽고  편하게 별자리를 찾을 수 있는 방법과 아름다운 밤하늘의 이야기를 들려줍니다.

별 보기를 소망하거나, 별자리에 대해 조금더 알고 싶어한다거나 저 처럼 별을 띄엄띄엄 볼 수 밖에 없는 분들을 위한 레퍼런스 서적으로 최적인 것 같습니다.

밤하늘에 관심이 많은 저와 같은 초심자에게 매우 추천합니다.^^
저작자 표시 비영리 변경 금지
Posted by -세티-

올해 초 까지 개발자 였다가 지금은 관리자로서의 길을 조금씩 걸어가고 있다.
내가 개발자였을 땐 맡은 일만 충실하게 마무리 하면 되었고, 기술적인 이슈만 챙기면 그만이었는데 관리라는 것을 하게 되면서 내가 보고 있던 시야와 가치를 조금은 변경해야 했다.

관리에는 기술, 사람, 도구 3가지가 포함된다고 생각하며, 이 3가지를 어떻게 해야 잘 조화롭게 만들 수 있을까 하는 고민을 늘상 하고 있다.
그 중 가장 고민이 되는 것은 기술도 아니고 도구도 아닌 사람이다.
사람은 이성보다 감정이 앞서는 감성적 동물이고, 모든 행위가 감정을 기반으로 하기 때문에 그 감정을 잘 다스리지 않으면 관리하기 매우 까다로운 대상이라고 생각한다.

서로 다른 경험, 서로 다른 업무 능력과 이해를 조화롭게 잘 엮어서 시너지를 만들어 가는게 관리자로서의 역할이자 의무라는 생각을 한다.
과거 내가 바라보던 관리자의 모습은 그리 긍정적이지 않았다. 기술자들은 스스로를 위해 많은 공부를 했지만 경험한 대다수의 관리자는 공부와는 거리가 멀어 보였고, 공부를 했다하더라도 단순히 지식을 축적한 수준에서 그것을 끝내곤 했던 것이다. 머리로 알고 있는 것과 실천이 서로 상이했었다.

과거의 경험을 바탕으로 내가 경험했던 관리자와 달라질려고 노력하면서도 한편으로는 이제서야 관리자들의 마음이 조금은 이해가 되기도 한다.

가장 먼저 변화된 점은 나보단 전체를 보게 되었다는 점이다.
내가 엔지니어로 일할 땐 나와 결과물이 우선이었지만 관리를 하게 되면서 그보다 더 넓은 시야로 위에 언급한 3가지 요소를 전체적으로 조화롭게 만들어나가야 한다는 것을 알게되었다는 것이다.

서로 다른 경험을 가진 사람들을 큰 틀에서 조화롭게 만드는 일은 너무나 어렵다.
어떤 사람은 부족한 것을 집에서 채우는가 하면 어떤 사람들은 집에서 채우지 않기 때문이다.
또 어떤 사람은 열심히 일하지만 어떤 사람들은 대충 일하기도 한다.

이런 서로 다른 성향과 가치관을 가진 사람들을 적절하게 하나로 묶어주는 것에 대한 고민이 많은 요즘이다.

저작자 표시 비영리 변경 금지
Posted by -세티-

회사에서 2006년도에 도입된 TEAMS라는 솔루션을 사용하고 있다.
요즘 이 TEAMS 라는 솔루션 때문에 상당히 골치가 아프다.

문항 관련 데이터가 모두 파일로 되어 있어서 사용자의 접속이 많으면 Disk I/O가 엄청나다.
그 이유는 이 제품에서 사용되는 정보 일부가 파일 데이터베이스로 되어 있기 때문이다.
대략 난감한 상황이다.

그렇기 때문에 시스템 증설시 데이터를 옮기는 것도 쉽지 않다.
RDB 기반 이었더라면 데이터 이관에 대해 덜 고민 해도 될 부분을 이 부분 때문에 고민한다는 것이 좀 황당할 뿐이다.

또한 이 시스템을 유지보수 해야 하는데 제공된 테이블 명세서가 매우 부정확하다.
구축된 시점의 명세를 포함하고 있지도 않고 오히려 내부에서 정리한 명세서가 양도 많고, 비교적 최신의 정보를 가지고 있더라는... 쩝.

그것도 그렇지만 사용중인 테이블을 열어보고 깜짝 놀랐다.
난 DBA가 아니어서 아주 전문적이지는 않지만 그래도 가장 기본적인 것이 무엇인지는 잘 알고 있다.
이 솔루션에서 명명한 테이블 명이 너무나 추상적이서 개발할 때 짜증이 좀 난다.
이런 식의 네이밍은 2000년도 이후로는 처음 구경해봤다.

또한 테이블의 정규화도 잘 되어 있지 않아서 많은 양의 중복 정보가 저장되고 있고 사용자가 많아지게 되면 불필요한 정보축적으로 인해 시스템 유지보수 비용이 증가하게 된다.

아무튼 이 녀석을 유지보수 하기 위해 업체에 문의도 해보고, 메신저로 쪽지도 남겨보지만 연락도 없고 느낌상 꽤나 비협조적이다. 스스로 테스트 조차 하지 않은 모듈을 고객에 넘기고선 문제가 발생하자 고객보고 '그것도 테스트 하지 않고 업로드 하냐'는 이해 못할 말도 하고 바로 3년전에 도입한 이 솔루션에 대한 이해를 도울 자료를 요청해도 없다고 하고 한마디로 내부 관리도 엉망인 듯한 느낌이 들었다.
굳이 큰 것을 보지 않아도 작은 것을 무시하고 소홀히 하는 이 업체를 보고 있으면 같이 제휴 맺어 일하는 모든 것들이 매우 불안하다.

나 역시  컨설팅, SI업체에 몸 담았던 적이 있는데 당시 내 경험에 의하면 제품에 대한 퀄리티 보장은 물론이고, 꾸준한 유지보수를 위해 고객이 의뢰한 제품의 라이프 사이클 연장을 위해 회사차원에서 노력했던 기억이 있다.
바쁘고 여유가 없어도 고객한테 이렇게 비협조적이지는 않았다.

그런데 이건...뭐...
상황이 이럴진데 이번에 해당 업체와 맞춤형 교재 사업을 벌이는 것 같다.
현재 운용중인 시스템에 그다지 신뢰가 가지 않는 상황에서 손잡고 무언가를 시작하게 될 것 같은데...이건 시작하기도 전에 먹구름이 보인다.(물론 그래도 난 먹구름을 걷어내기 위해 최선을 다하겠지만...)

오늘도 프로젝트 진행을 협의하기 위해 해당 팀장에게 문자를 넣었지만 여전히 응답이 없다.
일을 하겠다는 건지 말겠다는 건지 성의도 없고, 정말 화가 난다.

해당 업체와 거래를 해야하고, 그곳에 있는 일부 성의 없는 개발자들과 협업해야 하는 내 처지가 안타까울 뿐이다.
사람과 사람 사이에서 비즈니스의 세계에서도 가장 중요한 것이 약속이고, 신뢰이고 정성이다.

이런 기본이 지켜지지 않는 것을 보면 꽤나 씁쓸하다.
저작자 표시 비영리 변경 금지
Posted by -세티-