오늘 Linda Rising 아주머니에게 Fearless Change를 번역하고 있다고 말씀드렸습니다.  또한 저희 스터디 팀을 위해서 Comment를 남겨 달라고 했는데요. 남겨주셨네요 :).  제가 저희 스터디의 사진과 posting된 글을 공유해 드렸습니다.

다음과 같은 답변이 왔습니다.

Thank you for the information on your study group.
The pictures are great!
It looks like you are having fun and using the pattern “Do Food” :-)!

It’s exciting to hear that you are translating the book to Korean.
That will make the patterns available to others who don’t read English as well as you do!

I’m attaching two papers that Mary Lynn and I have written with some new patterns for change.
I hope you enjoy them.

All the best to you and the members of your study group!!!!

계속 읽기

어디서 부터 변화를 시작해야 할까요?

그건 바로 마음가짐일 것입니다.  내 자신이 변화를 전파하는 Evangelist가 되어야 하며,열정을 지속적으로 유지 할수 있는 Dedicated Campion되는 것입니다.

성공적인 Dedicated Champion이 되기 위해서는 변화를 주도하는 역할 역시 업무의 부분으로 인정받아야 되는데, 대부분의 기업들이 업무라면, 단순히 개발하거나, 어떠한 성과가 나오는 부분에 초점을 맞추고 있다는 것이 문제입니다.

기업이나 조직에서 변화를 주도하기 위해서는 변화를 이끄는 일, 역시 업무로 인정하는 분위기가 필요합니다. 안되면 Google 처럼 2/8 이라도 해주셨으면..

그리고 변화를 계속해서 잘 주도내 나가고 있다는 것을 보이기 위해서, 무언가 지속적으로 일이 진행된다는 것을 알려야 하며, 또한  잘 평가받기 위해서, 근거와 자료를 뒷 받침하는 자료를 꾸준히 만드는 작업이 필요합니다.

그렇다고  프로세스 대한 도입으로 차츰 차츰 반복되는 실수나, 문제점을 줄어나간다는 것 을 도표로 뽑아내어 예전보다 나아졌다고 평가를 하는 것 보다는,직원들이 변화를 인식하고, 이것이 긍정적으로 바뀌고 있다고 팀원들이 다 같이 느끼게 하는 것이 더 중요하곘죠.  하지만 변화를 지지 하는 Coporate Angel(높은 상관)에게 지속적인 지원을 받기 위해서는 이러한 평가자료도 매우 중요합니다.

자 그럼 Fearless Change 에서 언급하는 전략적으로  변화를 시작하는 방법에 대해서 공유해보죠.

계속 읽기

Fearless Change 두번째 장에서는  조직 변화를 위한 패턴들을 소개하지 않고, 원론적인 이야기인 패턴은 무엇인가? 그리고 어떻게 패턴을 보아야 하는지 설명를 하고 있습니다.

Pattern을 아시는 분이라면 뭐 이정도야 하고  말씀하실 수 있겠지만,   Linda의 Pattern에 대한 철학 ,노력, 패턴 Template의 발전 과정등을 설명해 놓아서, 흥미있게 읽었습니다. (저만 흥미로운 걸수도 있습니다… ). 특히 패턴을 읽는 것이 아닌 패턴을 만들어 본 경험이 있는 저에게는요. 읽으면서 PLoP BootCamp 때가 많이 생각나더군요.

Fearless change가  설명하고 있는 패턴은 소프트웨어 설계 패턴이 아니라, 조직 구조와 관련된 패턴이라는 점을 유의해서 읽어 주세요. 물론 비슷한 면도 많지만요.

계속 읽기

Fearless Change를 읽으면서 여러가지 생각할 거리를 많이 얻었습니다.  그리고 좋은 아키텍팅을 하기 위해선, 기술 못지않게,  다른 부분(조직 구조, 협력, 대화법등..)도 중요하다는 것을 더욱 알게해주며,  저의 예전과 현재의 모습을 바라볼 수 있는 서적이기 때문입니다.

세계에서 내놓아라는 유명 컨설턴트와 1년 같이 프로젝트도 진행해 보고, 국내의 유명 컨설턴트와도 차기 버젼을 개발했을때 느꼈던 점은  컨설턴트가 자신의 생각을 관철하려고 하지, 정작 우리 개발자의 이해나 생각을 많이 물어보지 않으려고 했다는 겁니다. 마치 자기가 새로 정립한 이론을 테스트하기에 급급하지 않았나 생각이 들더군요.

전 이해를 구하는 컨설턴트를 만나고 싶었습니다. 하지만 대부분이 그렇지 않더라구요.  그리고 이 책을 읽으면서, 왜 짧은 시간에는 위에서 아래로 변화를 내려찍는 방식을 취할 수 밖에 없었는지 알게되었습니다.  시간이 없다 보니 점진적이면서 모두를 변화시킬수 있는 Bottom-Up 보다는, 내려찍는 Top-Down 방식이 진행될 수 밖에 없고, 조직 구조도 상명 하복을 잘 받아들이수 있게 계층화되어 있다는 것이지요.  관리자 입장에서는 강점이지만, 아래있는 사람들이 주체적으로 변화의 주역이 되기는 힘든 구조라고 생각이 듭니다.

지하철에서 1장을 읽으면서 연습장에 쓱싹 쓱싹 정리해 봤습니다. Fearless Change 에서 조직를 어떻게 변화해야 하는지 큰 명분(motivation)을 내세우는 장이라고 할수 있습니다. 왜 변화가 어려운지 설명하는 장이지요. 하나 하나 세밀하게 다 설명 드리고 싶지만, 아무래도 제가 느낀 감동은  다 말로하긴 힘들듯 합니다. 전 큰 핵심만 전달해 드려야 될 듯 하네요.

계속 읽기

오늘  Rebecca의 강의를 들은 후, 아는 분과 설계와 구현간의 gap에 대한 이야기를 들었습니다.

아무리 좋은 설계라도, 개발자가 전혀 다르게 구현한다면. 어떻게 해야 할까요? 그리고 RTC와 같은 좋은 툴들이 보급된다고 해서 과연 이러한 문제가 해결될까요?  이러한 툴에 맞게 개발 문화가 정착된 회사가 한국에 몇이나 있을까요?  형식적인 것이 아닌, 진정한 개발 문화가..

솔직히 이런 문제는 한국에서개발자 대비 QE의 비율이 너무 빈약해서, 스펙에 맞게 잘 구축된 테스트 환경도 찾아보기 힘들고, 실제 현장과 동일한 환경 또한 만들기 쉽지가 않습니다. 이러한 것이 선행되어 강력히 제약을 가해야, 비로서 올바른 구조가 될듯 한데. 참으로 어려운 이야기인것 같습니다. 거기다 Requirement 변경이 빗발치는 SI에서는말이죠.  Owner의 말한마디로.. 되는 경우도 종종 있지만요.

이러한 하소연은 하루 이틀 나온 애기도 아니고, 정말 이땅의 많은 Manager와 Architect가 싸워서 합리적인 문화와 구조를 만들어야 가능하지 않을까요? 이런 현실과 부딪혀 이기기가 쉽지 않다고 생각이 들기도 합니다. 그래도 다 같이 머리를 맞대고 도전해 봐야죠.

계속 읽기