어느 날 저는 은행 점장에게 자신이 운영하는 지점을 성공할 수 있게 하기 위해, 그가 무엇을 했는지 물어보았습니다.
“글쎄” 점장이 대답하길. “나는 나의 주업무가 직원들을 지원하는 것이라고 믿습니다. 직원들이 일을 할 때 직원들을 방해하는 모든 장애물을 제거하고 대처 수단을 발견하는 것이지요.”
가장 가까운 일선 경영층에 도움을 요청하십시오. 만약 여러분의 상사가 새로운 아이디어를 도입 할려는 당신의 작업을 지원한다면, 당신은 훨씬 효율적으로 조직에 아이디어를 도입할 수 있을 겁니다.
여러분이 조직에 새로운 아이디어를 도입하려고 노력하는 Evangelist(144)라고 합시다.
여러분은 새로운 아이디어를 위해 관심과 노력이 필요합니다.
경영층은 일터에서 합법적인 것들을 지원합니다. 몇몇 사람들은 새로운 아이디어를 수용하는 작업 뒤에 경영층이 숨어있다고 생각되지 않는 한, 새로운 아이디어에 열중하지 않습니다. 스폰서 쉽(지원을 하는 여러 행위)은 중요합니다.
Linda Rising 아주머니께서 AsianPLoP 2010이 열린다는 멜을 보내주셨습니다.
아시아권에 유일한 PLoP 행사인 Mensore PLoP이 한동안 진행되지 않았는데. 드디어 새롭게 AsianPLoP 이라는 이름으로 처음 진행됩니다.
어디서 부터 변화를 시작해야 할까요?
그건 바로 마음가짐일 것입니다. 내 자신이 변화를 전파하는 Evangelist가 되어야 하며,열정을 지속적으로 유지 할수 있는 Dedicated Campion되는 것입니다.
성공적인 Dedicated Champion이 되기 위해서는 변화를 주도하는 역할 역시 업무의 부분으로 인정받아야 되는데, 대부분의 기업들이 업무라면, 단순히 개발하거나, 어떠한 성과가 나오는 부분에 초점을 맞추고 있다는 것이 문제입니다.
기업이나 조직에서 변화를 주도하기 위해서는 변화를 이끄는 일, 역시 업무로 인정하는 분위기가 필요합니다. 안되면 Google 처럼 2/8 이라도 해주셨으면..
그리고 변화를 계속해서 잘 주도내 나가고 있다는 것을 보이기 위해서, 무언가 지속적으로 일이 진행된다는 것을 알려야 하며, 또한 잘 평가받기 위해서, 근거와 자료를 뒷 받침하는 자료를 꾸준히 만드는 작업이 필요합니다.
그렇다고 프로세스 대한 도입으로 차츰 차츰 반복되는 실수나, 문제점을 줄어나간다는 것 을 도표로 뽑아내어 예전보다 나아졌다고 평가를 하는 것 보다는, 조직원들이 변화를 인식하고, 이것이 긍정적으로 바뀌고 있다고 팀원들이 다 같이 느끼게 하는 것이 더 중요하곘죠. 하지만 변화를 지지 하는 Coporate Angel(높은 상관)에게 지속적인 지원을 받기 위해서는 이러한 평가자료도 매우 중요합니다.
자 그럼 Fearless Change 에서 언급하는 전략적으로 변화를 시작하는 방법에 대해서 공유해보죠.
내가 설계한 시스템을 과연 개발자가 잘 만들고 있을까? 제대로 된 방향으로 가고 있을까? 우리 시스템이 어디가 꾜여있진 않을까? 진척율을 짝짝 올라가 양은잘 맞추는거 같은데..?
만약 이런 질문을 하고 있는 Architect나 Senior Software Engineer라면, 중간 상황을 어떻게 파악하시나요? 완벽한 대답은 아니지만 최소한 제대로 Architecting의 흐름이 흘러가는지 파악하는 좋은 툴중 하나인 DSM (Dependency Structure Matrix) 을 소개드리고자 합니다.
일전에 Dependency의 종류를 설명한 Dependency 대한 고찰 과 Dependency를 해결하는 방법을 소개한 Dependency 를 관리하는 방법 사이에 있는 포스트로, 바로 Dependency가 어디에 있는지 분석하자는얘기입니다. 문제 제기와 해결책은 제시했는데, 사실 Dependency를 파악하는 방법에 대한 이야기를 전해드리지 못했습니다. 이제서야 이야기를 꺼내게 되네요.
이 포스트는 2005년 OOPSLA에서 발표된 Paper인 “Using Dependency Models to Manage Complex Software Architecture”의 내용을 약식 정리한 것입니다.
Architecture 101 