아내 친구들의 집 방문으로, 오랜만에 자유(?)가 주어졌습니다.
그래서 스터디 맴버 한 분 (C님)과 오랜 만에 만나 여러 얘기들을 나누었습니다. EVA 스터디를 시작한지도 이미 8년째가 되어 가네요. 세월 참 빠른거 같습니다.
이런 저런 회상에 빠져 얘기를 나누어습니다.. 스터디를 통해 좋은 사람들과 만나 서로 성장한 우리들의 모습이 대견 스럽기도 하고, 그때 정말 좋은 선택을 했다며 자화 자찬을 했죠. 그리고 가장 중요한 자산은 바로 저희 스터디 팀 맴버들이라는 얘기도요 . (동네 꼬마들이 말하는 민망스러운 얘기지만요 🙂 )
그리고 자연스레 요즘 스터디 주제인 Fearless Change 스터디에 대한 얘기들이 나왔습니다. C님은 이러 저런 밴처기업에서 좌충 우돌 많은 상처를 많이 받았고, Fearless Change 스터디를 시작할 때, 팀장과의 거리가 좋지 않아 많은 마음 고생을 했다고 하더라구요. 그 팀장분이 좋아하는 주제에 대해서 공부를 할까? 좋아하는 게임도 같이 할까? 하고 친해져 볼려고 노력했지만, 잘 안되었다고 합니다.
한동한 블로깅이 뜸했던 이유들이 많이 있었습니다. 그중 하나가 바로 책 번역 다듬기 작업이었습니다. 거의 3주간 아무것도 못하고, 새벽과 틈틈이 시간을 쪼개며, “모든 소프트웨어 아키텍트가 알아야할 97가지”(가제)의 1차 역자 교정을 마쳤습니다. 정말 홀가분 하네요 🙂
저의 체력이 예전만큼은 안되구나.. 라는 것도 깨닫고, 번역투보다는 부드럽게 전달하기 위해 의역도 많이 넣었습니다. EVA 식구 분들이 자발적으로 너무 많은 도움을 주셔서 가능한 일이였습니다. 너무나 감사합니다. EVA 분들 감사합니다!!
이 책을 다듬고, 다시 씹고 씹어 읽으니 너무나 와 닿는 글 들이 많았습니다.
Half-Push/Half-Polling의 최종본을 공유합니다. 올해 정말 저에게 값진 선물은 PLoP에 참가해 여러가지 문화를 배울수 있었다는 점입니다. 또한 많은 유명 Architect를 만남으로써, 앞으로의 가야할 길과 협력의 중요성을 크게 깨닫게 되었습니다.
제가 패턴 저자가 되었다는 기쁨은 이루 말할수 없습니다. 다른 학회와 달리 논문만 발표하면 끝이 아닌 학회라, 저자 워크샾때 받았던 피드백으로 논문의 내용을 개선해야 했고, 겨우 겨우 최종본이 나왔습니다. TPLoP이라는 PLoP 저널에 실릴지는 모르겠지만, 최종본을 제출했습니다.
Home Networking이 아파트에 들어가는 것을 이해하지 못하는 서구권 문화 때문에 Office Automtation 으로 예를 바꾸고, 패턴의 Context를 좀더 이해하기 쉽게 하기 위해서 배경지식(Backgroud)과 Context를 좀더 명시적으로 적었습니다.
이 논문이 나오기 까지 많은 분의 노력에 감사드립니다. 결코 저 혼자만의 노력으로 나올 수 없는 논문이었습니다.
오늘 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!!!!
변화를 시작할 수 있다는 열정, 마음가짐을 가졌다면, 이제 조직에 변화를 가져올 수 있는 작업을 해야 합니다. 바로 사람을 얻는 것이지요.
나의 사람을 만들고, 같이 생각을 나누어 점진적으로 혁신의 생각을 전파해 나가는 것입니다. 큰 전략은 다음과 같습니다. 인맥이 넓은 Connector를 통해 Guru를 만나 나의 아이디어와 생각을 다듬어 신뢰성을 확보하고, 나의 상사인 Local Sponsor, 높게는 고위층인 Coporate Angel에 지지를 얻습니다. 그리고 Connector를 통해서 Innovator 성격의 사람을 찾아 내어 변화를 만들어 내자는 것이 목적입니다.
어느 날 저는 은행 점장에게 자신이 운영하는 지점을 성공할 수 있게 하기 위해, 그가 무엇을 했는지 물어보았습니다.
“글쎄” 점장이 대답하길. “나는 나의 주업무가 직원들을 지원하는 것이라고 믿습니다. 직원들이 일을 할 때 직원들을 방해하는 모든 장애물을 제거하고 대처 수단을 발견하는 것이지요.”
가장 가까운 일선 경영층에 도움을 요청하십시오. 만약 여러분의 상사가 새로운 아이디어를 도입 할려는 당신의 작업을 지원한다면, 당신은 훨씬 효율적으로 조직에 아이디어를 도입할 수 있을 겁니다.
여러분이 조직에 새로운 아이디어를 도입하려고 노력하는 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”의 내용을 약식 정리한 것입니다.
이번주 금요일 저녁에 강남에서 패턴 세미나를 엽니다.
이광춘 님과 친한 태호형이 힘을 다해 운영하고 있는 미래의 소프트웨어 품질 연구회라는 커뮤니티로, 좋은 강사들을 섭외해서 매 달마다 세미나를 진행하고 있네요. 좋은 강사의 자격(?)은 의심되지만, 부족하나마 저의 지식을 공유할려고 합니다.
- 주최 : 미래의 소프트웨어품질 연구회(미소연), DigiEco
- 일시 : 2009년 10월 23일(금), 오후 7시30분- (세미나는 1시간 30분 예정)
- 장소 : 토즈 강남대로점 (교보사거리 위치)
- 주제 : 미워도 다시 보는 패턴 이야기 / PLOP 학회 참석 후기
이번 행사는 Pattern에 대한 올바른 시선과 학습법을 제공해 드리고, PLoP에 대한 공유도 약간 할 생각입니다. 그리고 Do Food 패턴의 일환으로 약간의 음식(도넛 or 김밥) 도 무료로 제공되니, 금요일 약속이 없으시다면 방문해 주세요 🙂
Architecture 101 