'UML추진사례'에 해당되는 글 1건

  1. 2011/09/30 글뻥 누군가에게 지식을 전달하고 나서의 보람 (2)
AC2 선배님중 한분인 이상님께 일전에 약 8시간정도의 시간을 함께 UML에 대한 지식을 공유했다.
물론 무료로 진행했고, 드디어 실무에 적용하시면서 커다란 기쁨을 맛보고 계시다는 소식에 나도 모르게 박수를 보내드렸다.

사용자 삽입 이미지


UML은 어려운 기술이 아니다. 단지, 어떻게 쓰느냐가 문제다.
예를 들어 UML은 UML만 가지고는 어떤 효과를 맛보기 어렵지만, UML을 통해 업무를 가시화하고, 성과를 측정하고, 각종 문서를 주루루룩 만들어 낼 정도만 된다면, UML의 효율은 극대화 된다.

위의 이상님의 사례는 업무를 가시화하시는데 성공한 사례로 "갑"인 고객과 "을"인 대기업 PM이 굉장히 좋아했다고 한다. 문제를 해결하는 과정에서 이처럼 우뇌의 사용은 굉장한 효율을 발휘하고 이 효과가 매우 크다.

하지만, 더 기쁜건 이런 기법이 하나 둘씩 퍼져나가서, 개발자 스스로 무언가에 만족감을 느끼고, 리딩해갈 수 있다는 자신감을 회복하고, 그래서 문제를 조기에 발견해 궁극적으로 문제 해결비용을 절감하는 과정을 보고 있으면, 지식 전달자로 뿌듯한 자부심을 느끼게 된다.

덧붙여, 개발팀이 갑에게 갈굼 당할 수 밖에 없는 유형을 나열해보았다.
- 개발팀이 개발초기에 기술적인 빚이 있는 경우
- 개발팀이 개발초기에 납품일정에 빚이 있는 경우
- 개발팀이 개발초기에 투입원가에 대한 빚이 있는 경우

이보다 경우는 더 많지만, 프로젝트 초기부터 이러한 빚을 지게 되면 개발팀은 정치적으로 고객에게 개갈굼당할 수 밖에 없고, 개갈굼속에 고객과의 관계는 멀어지게 된다.

예를 들어, 투입인력을 언제부터 언제까지 어떤 스팩을 투입하기로 했는데, 투입이 지연되거나 스팩이 떨어진다면, 고객에게 PM은 빚을 지게되고 처음부터 기가 꺽인체로 이리저리 휘둘리게 된다. 기술적인 리딩은 커녕, 문제만 계속 누적하게 되어 결국 고객과 미치는 상태로 발전하게 된다.

반대의 경우 개발팀이 고객을 빚지게 하는 경우도 있다.
바로 저러한 경우다.
기술적으로 고객보다 우위에 올라 고객을 잘 리딩하게되면, 고객이 개발팀을 신뢰하게되고, 오히려 고객이 외부의 공격으로 부터 개발팀을 감싸고 돈다.

납품일정에 관해서도 마찬가지다.
납품일정을 조기에 마치면, 고객은 더 붙잡아 두기 위해 고객이 스스로 개발팀에게 매우 잘해주게 된다.

투입원가도 마찬가지이다. 고객이 원가산정을 잘못하여 예산이 없는 경우, PM이 사소한 원자재이지만, 고객에게 몰래 찔러 줄때, 고객은 감동하게 된다.

그럴때, 고객은 개발팀을 파트너로 생각하게 된다.
왜냐하면, 고객은 이걸 빚이라고 생각하기 보다는 자기가 힘들때 도와줬다고 생각하기 때문이다.

이 경우 대부분의 고객의 땡깡으로부터 벗어날 수 있게 된다.

위의 이상님의 사례는 고객이 개발팀에게 기술적인 빚을 지게 만들었다. 어찌 기쁘지 않을까?

좋은 고객, 나쁜 고객은 멀리있지 않다.
고객을 빚쟁이로 만들라. 그것도 고객이 난감해 하고 어려울 때, 비용이 가장 적게 든다. 
2011/09/30 16:01 2011/09/30 16:01