불친절한자수씨

지금까지 3년 4개월 동안 원치는 않았지만 기업용 솔루션 개발에 참여하면서 느낀 점들입니다.

(머 사실 기업용 솔루션이라고 하지만 거의 SI 에 가까운 생활이였지만...)

ㅁ 고객들은 프로그래머가 아니다.

 자기가 프로그래밍을 좀 한다고 해서 문의를 하는 고객에게 열심히 프로그래밍 지식으로 말하면서 이해 못하는 고객을 어이없어 한다면 참으로 웃긴일입니다. 현업들은 프로그래머가 아닙니다. 본인이 현업의 일들을 현업만큼 알지 못하는 것(혹시 알 수도 있으나) 처럼 각자의 맡은 업무가 다른 것입니다. 고객의 지식 수준에 맞게 응대하는 것도 분쟁을 줄이고 고객에게 좋은 인상을 심어줄 수 있습니다.

 허나... 고객들 중에서도 얕은 프로그래밍 지식으로 들이대시는 분들이 있습니다. 이런 분들을 위해 자근자근 씹어드릴수 있게 지식을 쌓아서 자근자근 밟아드리면 다음부터 그런일은 없겠죠...

ㅁ 고객들의 컴퓨터는 개발용 컴퓨터가 아니다.

 "멋진 UI 에 이런기능도 되고 저런기능도 되고...", 고객들이 원하는 것은 저런 기능들이 아닙니다. 내가 컴퓨터 앞에 앉아서 그 솔루션을 사용할 때 불편함이 없어야 하며 문제가 발생되지 않아야 하는 것입니다. "나는 당신들을 위해 이런 좋은 기능을 만들었는데 못쓰는 당신들이 멍청한거다" 라고 말 한다면 직접 현장에 나가서 현업들의 컴퓨터 사양을 확인하는게 좋지 않을까요? 아직도 공장에서는 586 PC 들이 어러사람 손에서 사용되고 있는 곳도 있습니다. 메모리도 256 MB 밖에 안되는 상태에서 화려한 플래시와 다양한 기능은 필요하지 않습니다. 저사양 시스템에서도 안정적으로 돌아갈 수 있는 환경이 마련되어야 합니다.

 사실 586 은 좀 심하긴 했습니다. 제발 공장도 어느정도까지는 맞쳐주시란 말입니다...

ㅁ 고객들의 입장에서 생각해보라.

 고객에 있어서 당장 급하게 처리할 일이 있는데 안된다면 그것만큼 크리티컬한 상황이 있을 수 있을까요? (권고사직.. 이런거 말고...) 하지만 응대를 하는 입장에서는 고객의 상황을 모르기 때문에 느긋하게 응대를 할 수도 있습니다. 만약 본인이 고객이라고 생각해본다면 생각이 틀려지겠죠. 급하게 지방에 내려가야 할 일이 생겨서 기차예매를 해야 하는데 표를 발권하시는 분이 느긋하게 처리하신다면 버럭하시겠죠? 고객이 무언가를 이야기한다면 그 상황에 자신이 처한상태라고 생각하면서 일처리를 진행합니다. 고객의 입장에서도 자신의 편이라고 느껴진다면 화가 조금은 누그러질 수도 있습니다 (예외는 항상 존재합니다). 고객들은 약하고 여린 존재입니다. 어르고 잘 달래드려야 합니다.

ㅁ 헬프데스크의 통로를 단일화하라.

 기업용 솔루션 개발에만 해당되는 것은 아니지만, 몇몇 중소 업체에서는 개발자가 직접 헬프데스크의 역할을 하면서 개발을 하는 경우가 있습니다. 사실 개발하시는 분들은 아시겠지만 개발이란 것은 흐름이 중요합니다. 중간에 누군가에 의해 중단이 된다면 자기가 어디까지 했는지 파악하는데 걸리는 시간도 아깝습니다. (기억을 바로 하신다면 당신은... 외계인!!!) 이런 것을 해소하기 위해서는 문의사항에 대해서 통로를 담당하는 인력이 필요하게 됩니다. 이런식으로 헬프데스크를 따로 두게 되면 헬프데스크 나름대로 노하우가 쌓이게되고 전문화가 되어가는 것입니다. 솔루션의 깊숙한 버그를 찾아 수정하는 정도는 아니더라도 전반적으로 처리되는 것을 이해하는 사람이라면 개발자들에게는 든든한 지원군이 됩니다.

 가끔 이런 헬프데스크 역할을 해주시는 분들을 무시하시는 분들도 계십니다. 일정을 잡고 일을 하는게 아니라 일이 없는 것 처럼 보여서 잡일같은 것도 많이 던져주시곤하시는데요, 실제로 한번 해보십시오. 절대로 다시는 하기 싫은 기억일 것입니다. 헬프데스크는 노예가 아닌 동반자입니다.

ㅁ 공통모듈에 의지하지 마라.

 슈퍼스타급 개발자가 팀내에 있어서 모든 공통들을 찍어내려주신다면 걱정할 필요가 없을 것입니다. 하지만 현실은 항상 그렇습니다 (다들 비슷한 처지이실듯...). 프로젝트 진행을 하게되면 PL 들이 공통모듈들을 개발을 하게됩니다. 과연 이렇게 나온 공통모듈들이 모든지 좋은 것일까요? 앞에서도 이야기 했지만 슈퍼스타급 개발자가 없는 경우라면 분명 무언가 헛점이 있곤합니다. 누가 만들어준걸로 그냥 쓰면 되지라는 생각으로 공통에 의지하게 된다면 발전할 생각을 접는게 나을 것입니다. 지금 주변에 계신분들은 프레임워크를 쭉쭉 뽑아내시거나 어떤 분야의 스펙을 뽑아내시는 분들이 아닙니다. 지금 이 글을 읽고 계신분들과 같은 개발자들입니다. PL 들이 만들어 놓은 공통을 통해서 먼저 의견을 제시하는 것은 어떨까요? 사실 PL 들도 공통모듈 뽑아내랴 자기 업무처리하랴 바쁜 것은 마찬가지 입니다. 이럴 때 점수라도 팍팍 쌓는 것이 도움이 많이 될 것입니다.

머 이것 저것 적다보니... 솔루션 개발이 아닌 고객응대와 프로젝트 진행에 대한 글이 되어 버렸네요..

시작은 장대하였으나 끝은 허접하리니... 다시 읽어보면서 고치기엔... 크윽.. -_ㅜ