어느 날 저는 은행 점장에게 자신이 운영하는 지점을 성공할 수 있게 하기 위해, 그가 무엇을 했는지 물어보았습니다.
“글쎄” 점장이 대답하길. “나는 나의 주업무가 직원들을 지원하는 것이라고 믿습니다. 직원들이 일을 할 때 직원들을 방해하는 모든 장애물을 제거하고 대처 수단을 발견하는 것이지요.”
가장 가까운 일선 경영층에 도움을 요청하십시오. 만약 여러분의 상사가 새로운 아이디어를 도입 할려는 당신의 작업을 지원한다면, 당신은 훨씬 효율적으로 조직에 아이디어를 도입할 수 있을 겁니다.
여러분이 조직에 새로운 아이디어를 도입하려고 노력하는 Evangelist(144)라고 합시다.
여러분은 새로운 아이디어를 위해 관심과 노력이 필요합니다.
경영층은 일터에서 합법적인 것들을 지원합니다. 몇몇 사람들은 새로운 아이디어를 수용하는 작업 뒤에 경영층이 숨어있다고 생각되지 않는 한, 새로운 아이디어에 열중하지 않습니다. 스폰서 쉽(지원을 하는 여러 행위)은 중요합니다.
어디서 부터 변화를 시작해야 할까요?
그건 바로 마음가짐일 것입니다. 내 자신이 변화를 전파하는 Evangelist가 되어야 하며,열정을 지속적으로 유지 할수 있는 Dedicated Campion되는 것입니다.
성공적인 Dedicated Champion이 되기 위해서는 변화를 주도하는 역할 역시 업무의 부분으로 인정받아야 되는데, 대부분의 기업들이 업무라면, 단순히 개발하거나, 어떠한 성과가 나오는 부분에 초점을 맞추고 있다는 것이 문제입니다.
기업이나 조직에서 변화를 주도하기 위해서는 변화를 이끄는 일, 역시 업무로 인정하는 분위기가 필요합니다. 안되면 Google 처럼 2/8 이라도 해주셨으면..
그리고 변화를 계속해서 잘 주도내 나가고 있다는 것을 보이기 위해서, 무언가 지속적으로 일이 진행된다는 것을 알려야 하며, 또한 잘 평가받기 위해서, 근거와 자료를 뒷 받침하는 자료를 꾸준히 만드는 작업이 필요합니다.
그렇다고 프로세스 대한 도입으로 차츰 차츰 반복되는 실수나, 문제점을 줄어나간다는 것 을 도표로 뽑아내어 예전보다 나아졌다고 평가를 하는 것 보다는, 조직원들이 변화를 인식하고, 이것이 긍정적으로 바뀌고 있다고 팀원들이 다 같이 느끼게 하는 것이 더 중요하곘죠. 하지만 변화를 지지 하는 Coporate Angel(높은 상관)에게 지속적인 지원을 받기 위해서는 이러한 평가자료도 매우 중요합니다.
자 그럼 Fearless Change 에서 언급하는 전략적으로 변화를 시작하는 방법에 대해서 공유해보죠.
Fearless Change 두번째 장에서는 조직 변화를 위한 패턴들을 소개하지 않고, 원론적인 이야기인 패턴은 무엇인가? 그리고 어떻게 패턴을 보아야 하는지 설명를 하고 있습니다.
Pattern을 아시는 분이라면 뭐 이정도야 하고 말씀하실 수 있겠지만, Linda의 Pattern에 대한 철학 ,노력, 패턴 Template의 발전 과정등을 설명해 놓아서, 흥미있게 읽었습니다. (저만 흥미로운 걸수도 있습니다… ). 특히 패턴을 읽는 것이 아닌 패턴을 만들어 본 경험이 있는 저에게는요. 읽으면서 PLoP BootCamp 때가 많이 생각나더군요.
Fearless change가 설명하고 있는 패턴은 소프트웨어 설계 패턴이 아니라, 조직 구조와 관련된 패턴이라는 점을 유의해서 읽어 주세요. 물론 비슷한 면도 많지만요.
저희 Eva팀이 드디어 두 번째 프로젝트인 “97 things every software architect should know (가제 – 모든 아키텍트라면 알아야 할 97가지 이야기)” 에 대한 1차 번역을 마쳤습니다.
2 달만에 번역하기 프로젝트를 시도했지만, 예상외로 아키텍트 특유의 고급적인 문체, 시와 같이 운율을 살리는 비유, 해당 도메인의 지식 부재등으로 약간의 난전을 겪었습니다.
그래서 3달 만에 1차 번역이 마치게 되었네요. 내부적으로 1차 리뷰를 마치고 출판사에 맡겼지만 아직 손봐야 할 것이 여러군 데 있는 건 사실입니다. 어느정도 책의 형태가 나오면 베타리더를 모아 더 다듬어야 겠죠.
범위는 프로젝트의 크기를 언급합니다.
얼마나 많은 시간, 노력, 자원들이 필요한가?. 어떤 수준의 품질에서 어떤 기능성을 가지는지? 얼마나 많은 위험이 있는지? 어떠한 제약이 존재하는지? 이에 대한 대답들이 프로젝트의 범위를 정의합니다.
소프트웨어 아키텍트들은 크고, 복잡한 프로젝트에 도전하는 것을 사랑합니다. 잠재적인 보상은 사람들이 인위적으로 프로젝트 외관상의 중요성을 증가시키기 위해 프로젝트의 범위를 인위적으로 확장하게 유혹할 수 있습니다.
범위를 확장하는 것은 성공의 적입니다, 왜냐하면 실패할 가능성이 예상했던 것보다 더 빨리 증가하기 때문입니다.
프로젝트의 범위를 2배로 증가시키는 것은 종종 실패의 가능성을 10배로 높입니다. 왜 이렇게 실패 가능성이 높아질까요? 몇 가지 예 들을 살펴봅시다.
직감은 일을 두 배로 일을 하기 위해 우리의 시간이나 자원을 두 배로 늘리라고 말합니다.
역사[1]는 ,직관이 제안했던 것처럼, 미치는 영향이 선형적으로 증가(두배로 일하기 위해 미치는 영향이 단시 시간과 자원을 두배로늘리는 것)하지 않는다고 말합니다. 예를 들어나 네 명의 팀은 두 명의 팀이 커뮤니케이션 하는 것보다 2배 이상의 커뮤니케이션 비용이 들것입니다.
Fearless Change 2장에 나와있는 Innovator 패턴을 설명드리고자 합니다. 1장 요약 포스트에 언급했던 변화를 수용하는 5 그룹중 가장 변화를 잘 수용하는 사람들에 대한 이야기 입니다. Innovator를 발견하고, 그사람의 나의 의견에 동조하는지 살짝 발을 물에 담구어 보는 (Test the water) 패턴을 이용해서 나의 사람을 찾은 다음, 여러 동료들을 만들어 같이 변화를 시작하는 것이 좋겠죠. 🙂 (미실이 말하는 사람을 얻는자가 천하를 얻는다라는 말이 정말 와닿군요..)
한번 쭉 읽어보세요. 번역이 틀리수도 있으니 가능하다면, 원서를 사 읽어 보시길 권해드립니다.
Pattern Name
Innovator
Opening story
Roger는 옆집에 살고 있습니다. 항상 그는 가장최신의, 멋진 gadget들을 가져옵니다. 나는 이 gadget에 들에 대한 이야기를 듣습니다. Roger가 구입한 것들에 대해 너무 흥분한 나머지, 심지어 너무 비싼 가격으로 gadget을 구입하기도 합니다. Roger가 어떤 gadget들이 너무 유용하다는 확신을 주면, Roger가 지불한 가격의 절반 이하가 될때까지 기다리가다 이후에 구입합니다.
Summary
만약 당신이 변화를 일으키고 싶다면, 새로운 아이디어를 좋아하는 동료들에게 도움을 요청하십시오.
둘 중 하나를 선택해야 한다면. 대부분의 사람들은 해야 될 가장 중요한 것을 선택합니다. 하지만,설계(소프트웨어 또는 다른 것들)에서는 그렇지 않습니다. 두 가지 선택사항의 존재는 당신이 설계 시 불확실성을 고려할 필요가 있다는 것은 알려주는 지표(indicator)입니다.
불확실성을 가능한 마지막 순간에 설계에 자세한 부분(defer commitment[1])을 결정할지, 설계 결정들의 중요성을 감소시키기 위해 분할하고 추상화할지 결정하는 기준으로 이용하십시오. 만약 당신의 마음을 첫 번째(가능한 나중에 결정하는 것 – defer commitment)에 고정시킨다면 이 첫 번째 원칙에 갇히고 종속될 수 있습니다. 그 결과 부수적인 결정이 굉장히 중요해 지고 소프트웨어의 유연성이 줄어듭니다..
아키텍쳐에 있어서 가장 간단하고 구조적인 정의중 하나는 Grady Booch의 말에서 인용됩니다.
“모든 아키텍쳐는 설계지만 모든 설계가 아키텍쳐는 아니다. 아키텍쳐는 시스템을 구체화하는 중요한 설계 결정들을 나타낸다. 여기서 중요한 것은 변화의 비용에 의해서 측정된다.”
이 정의에 따르면 효과적인 아키텍쳐는 일반적으로 설계 결정의 중요성을 감소시키는 것입니다. 비효율적인 아키텍쳐는 설계 결정의 중요성을 확대시킵니다. 설계 결정이 합리적으로 두 가지 방법 중 하나로 진행될 수 있다면, 아키텍트는 한 걸음 물러설 필요가 있습니다.
Fearless Change를 읽으면서 여러가지 생각할 거리를 많이 얻었습니다. 그리고 좋은 아키텍팅을 하기 위해선, 기술 못지않게, 다른 부분(조직 구조, 협력, 대화법등..)도 중요하다는 것을 더욱 알게해주며, 저의 예전과 현재의 모습을 바라볼 수 있는 서적이기 때문입니다.
세계에서 내놓아라는 유명 컨설턴트와 1년 같이 프로젝트도 진행해 보고, 국내의 유명 컨설턴트와도 차기 버젼을 개발했을때 느꼈던 점은 컨설턴트가 자신의 생각을 관철하려고 하지, 정작 우리 개발자의 이해나 생각을 많이 물어보지 않으려고 했다는 겁니다. 마치 자기가 새로 정립한 이론을 테스트하기에 급급하지 않았나 생각이 들더군요.
전 이해를 구하는 컨설턴트를 만나고 싶었습니다. 하지만 대부분이 그렇지 않더라구요. 그리고 이 책을 읽으면서, 왜 짧은 시간에는 위에서 아래로 변화를 내려찍는 방식을 취할 수 밖에 없었는지 알게되었습니다. 시간이 없다 보니 점진적이면서 모두를 변화시킬수 있는 Bottom-Up 보다는, 내려찍는 Top-Down 방식이 진행될 수 밖에 없고, 조직 구조도 상명 하복을 잘 받아들이수 있게 계층화되어 있다는 것이지요. 관리자 입장에서는 강점이지만, 아래있는 사람들이 주체적으로 변화의 주역이 되기는 힘든 구조라고 생각이 듭니다.
지하철에서 1장을 읽으면서 연습장에 쓱싹 쓱싹 정리해 봤습니다. Fearless Change 에서 조직를 어떻게 변화해야 하는지 큰 명분(motivation)을 내세우는 장이라고 할수 있습니다. 왜 변화가 어려운지 설명하는 장이지요. 하나 하나 세밀하게 다 설명 드리고 싶지만, 아무래도 제가 느낀 감동은 다 말로하긴 힘들듯 합니다. 전 큰 핵심만 전달해 드려야 될 듯 하네요.
오늘 Rebecca의 강의를 들은 후, 아는 분과 설계와 구현간의 gap에 대한 이야기를 들었습니다.
아무리 좋은 설계라도, 개발자가 전혀 다르게 구현한다면. 어떻게 해야 할까요? 그리고 RTC와 같은 좋은 툴들이 보급된다고 해서 과연 이러한 문제가 해결될까요? 이러한 툴에 맞게 개발 문화가 정착된 회사가 한국에 몇이나 있을까요? 형식적인 것이 아닌, 진정한 개발 문화가..
솔직히 이런 문제는 한국에서개발자 대비 QE의 비율이 너무 빈약해서, 스펙에 맞게 잘 구축된 테스트 환경도 찾아보기 힘들고, 실제 현장과 동일한 환경 또한 만들기 쉽지가 않습니다. 이러한 것이 선행되어 강력히 제약을 가해야, 비로서 올바른 구조가 될듯 한데. 참으로 어려운 이야기인것 같습니다. 거기다 Requirement 변경이 빗발치는 SI에서는말이죠. Owner의 말한마디로.. 되는 경우도 종종 있지만요.
이러한 하소연은 하루 이틀 나온 애기도 아니고, 정말 이땅의 많은 Manager와 Architect가 싸워서 합리적인 문화와 구조를 만들어야 가능하지 않을까요? 이런 현실과 부딪혀 이기기가 쉽지 않다고 생각이 들기도 합니다. 그래도 다 같이 머리를 맞대고 도전해 봐야죠.
PLoP 첫번째 날인 오늘은 매우 재미나고 신나는 하루였습니다.
오늘 말로만 듣던 Writer’s Workshop을 직접 체험한 날이였습니다. 하나는 참가자의 역할로 또 하나는 저자의 역할로 진행을 했습니다. 행사가 시작하기 이전에, PLoP의 대표자들이 모여 진행한 Writer’s Workshop 을 어떻게 진행하는지 설명하는 데모 사진을 찍어보았습니다. 김창준 님이 이미 공개한 내용이지만, 그래도 직접 사진과 보시는게 좋을듯 해서 올려드리도록 하겠습니다.
PLoP에서 참가자는 크게 세 부분으로 나뉩니다. 저자, 참가자, 그리고 행사를 진행하며 조정하는 조정자입니다.
Architecture 101 