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

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

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

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

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

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

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

식사와 함께 살짝 떠 보기.

먼저 Do Food 패턴과 Brown Bag 패턴을 이용해 회의라는 무거운 형태의 모임이 아닌 가벼운 모임의 형태로 대화를 시작해서 나의 의견에 동조하는 사람을 찾아야 합니다.

Do Food는 음식을 나누면서 애기하는 패턴으로, 음식이 상당히 분위기를 부드럽게 해준다는 것입니다. 여기서 주의 할것은 특정인이 먹지 못하는 음식이 있을수도 있으니 몇몇 종류의 음식을 준비하는 것이 팁이겠죠.

그리고 Brown Bag은 우리가 샌드위치 집에서 보는 갈색의 종이 백을 기억하시면 됩니다. 바로 이러한 가벼운 음식을 먹으면서 식사시간에 대화를 나누라는 것입니다. 회의의 무거운 형태가 아닌 식사시간에 가벼운 대화만으로도 나의 의견(변화 내용)에 동조하는 사람을 찾을수 잇다는 것이죠.

이때 사용되는 패턴이 Test the water로 나의 의견에 동조하는지 보고, 물에 발을 담군다는 의미로 보시면 될듯 합니다. (나의얘기에 동조하는 사람을 찾아내는 패턴이죠)
가벼운 주제로. 이러한 변화에 대해서 어떻게 생각하느냐 애기를 나누는 것 만으로 충분합니다.  또한 변화가 어려운 조직은 너무 처음부터 큰 변화를 주도하기 보다는 조금씩 변화를 주는 것이 필요합니다. Small Success의 또 다른 애기겠지만.  S군이나, H님(EVA 스터디 맴버)을 비롯한 몇몇 분의 조언처럼, 사내 메일을 통해서 새롭고도 유익한 정보를 계속해서 공유해 나갑니다.
그래서 자신의 애기나 메세지를 숨겨서 계속 전달하면 유용하게 전파될수 있다고 합니다.

그 효과를 알기 위해서는 잠시간 메일링 리스트를 중지해 보면 바로 알수 있었다고 압니다.  누가 이런 유익한 정보를 전달하는 것을 그만두었냐며, 바로 피드백이 온 사례들을 많이 보았다고 합니다. 그리고 아예 이러한 것을 업무로 나중에 할당한 사례도 있다고 하더라구요.

또한 H님 같은 경우는 지금은 보험을 탈퇴했지만, 그 보험사는 끊임없이 유용한 소식이나 정보를 멜로 보낸다고 합니다.  그래서 호감도 아직 남아 있구요. 아마 다음에 보험을 들면 이분한테 들어야 겠다는 생각도 있다고 하십니다.   이러한 정보 메일이 원인이 된지 모르겠지만, 보험사는 연봉이 1억이 넘는다고 하는군요 🙂

여기서 중요한 얘기는 변화의 적용에 대한 이야기 입니다.
변화를 받아 들이는 사람이 상식의 선을 넘지 않는 변화로 부터 시작을 해야 된다는 것입니다.  너무나 처음부터 급격한 변화는 누구나 받아들이기 힘들다는 점을 기억할 필요가 있습니다.

또 다른 변화의 애기로 사실 저 같은 경우는 어떠한 변화를 다수결이 동의했음에도 불구하고, 소수의 높은 직급을 가진 사람의 반대로 좌절된 경우를 보았습니다.
그 변화에 대한 책임을 니가 지겠나며, 책임을 전가시킴으로써, 실패한 경우도 있고, 또한 그것이 좋음에도 알고 귀찮은 작업이므로, 실패한 경우도 있었습니다. 직급 체계라는 구조때문에 변화가 전파되기 힘들다는 애기도 있는거죠. 그러니 변화를 주도하기 이전에 조직의 문화등을 알 필요가 있습니다.

또한 많은 분들이 회사의 상사의 말도 안되는 명령 하달에 의한 변화에 의한 이야기를 해주셨습니다. 개발이 완료되가는 프로젝트의 갑작스러운 개발 플랫폼의 변경이라거나. C로 개발되면 별 고생없이 모든 플랫폼에 다 돌아갈거라는 윗사람의 잘못된 지식으로 고생한 경우도 있다고 합니다. 다행히 팀장분의 지혜로 아웃소싱으로 돌림으로써, 해결되었다고 하네요.

변화를 전파하기 이전에 과연 이 변화를 수용할 수 있을건지 미리 설명하고 검토해야 된다는 거이고, 또한 변화로 인해 불이익을 받는 사람들을 파악해서 도움이나, 다른 보상을 주는 것이 중요합니다.

변화는 시간이 필요하다. (Time for reflection)

그 다음 우리가 가져야 하는 마음 가짐은  변화하기 위해 시간이 필요(Time for reflection)하다는 것을 알아야 합니다.
온고 지신처럼. 옛 것을 기반으로 더 나은 것을 차츰 차츰 개선해 나가는 것이 중요합니다. 회고를 통해서 더 나은 것을 만든다는 것이죠. 기존 시스템의 문제를 파악해서 원인을 찾아내고 개선해 나가라.

다만 급격한 변화가 아닌 조금씩 바꾸어 나가는 것이 중요합니다. 처음부터 확 변화하는 것은 많은 저항과 지속적인 변화를 힘들게 합니다.  그렇기 때문에 변화에 대한 조그만 평가를 하게 되고,이 성공(small success)을 서로 공유해야 합니다.  작은 성공을 팀원들과 공유함으로써 지속성을 유지하는 것이 중요합니다.  작은 성공이 모여서 큰 성공을 이룬다는 절대 조언에 기반을 두고있습니다. XP, Scrum에서 말하듯이 짧은 주기의 데모시간을 주어서, 중간 중간 성공을 공유하고,잘못된 것을 바로 잡는 시간이 필요합니다.

이렇게 하면 팀원들은 Lesson Learn 하면서, 올바른 형태로 프로젝트의 방향을 잡아갈 수 있습니다.  또한 중간 중간 이를 회고(retrospective), 검시(postmortem)[1], 산후(postpartum) 또는 프로젝트 리뷰(Project review)를 통해서계속해서 Lesson Learn하는 자세 역시 중요합니다.

중간 중간 성공을 공유하고 변화를 쉽게 받아들이기 위해서 조직간의 정치나 저항이 덜 발생할 수 있게 구조를 잡는 것이 매우 중요합니다.

대부분의 변화는 시나리오로 오거나, Feature로 오게 됩니다. 그럼 팀 역시 시나리오나 Feature별로 구성되어야 합니다.
이 이야기는 땅꽁버터와 마천루 (https://arload.wordpress.com/2008/05/20/peanutbutter/ )를 읽으면 이해가 되실겁니다.
Feature Creep 이라는 스물 스물 추가되는 변화를 받아 들이기 위해서는 이러한 변화를 잘 받아들일 수 있는 구조로 팀이 만들어 지는 것이 중요합니다.

이러한 예로 Feature Crew를 예를 들수 있습니다. 우리가 아는 팀구조의 대부분은  Architect 팀, 개발 팀, QA 팀 따로 따로 팀을 두었기 때문에 이 팀간의 정치나 서로간의 불신이 매우 크며, 그로 인해 변화를 받아 들이는 속도도 매우 낮습니다. 그래서 Microsoft는 새로운 시도를 하는데, 바로  Feature 별로 팀을 나누는 구조를 가지고 있습니다.  Architect와 PM은 전체 Feature를 서로 조율하는 역할을 하고, 개발자 3 : QA 7의 비율로 하나의 Feature를 아주 빨리 개발합니다. 그렇기 때문에 이들 팀원간에 의사 소통도 매우 잘 되었으며, 한 Featue를 불과 3~4주 만에 끝내고 빨리 다음 Feature를 개발하는 형태입니다.  개인적으로 이것이 시나리오로 바뀌어도 별 차이가 없다고 생각하고 있습니다.

대부분의 컨설턴트, PM이 실패하는 이유는 조직의 문화를 이해하지 안하고, 자신의 철학이나 아이디어를 전파할려는 것입니다.  이러면 저항이 발생하는 것은 당연한 일입니다.
이러한 저항을 줄이기 위해서는 PM이나 컨설턴트는 주기적으로 30분 마다 하루에 몇명씩 커피나 차를 마시면서, 애기를 나누고, 걱정거리, 근심거리를 나누어 해결해 주고, 또한 개발자의 취향이나 역량들을 파악해서 그들이원하는 일을 할수 있게 해주자 저항이 줄어든 경우를 현종님이 목격했다고 합니다.

다른이에게 도움을 요청하십시오. Ask for Help

황우와 유방의 애기에서 알수 있듯이 또한 미실의 말처럼, 사람을 적절하게 활용하는 것이 중요합니다.사람들에게 도움을 요청하십시오. 거절을 당할순 있지만, 그래도 거절을 통해서 다양한 사람의 여러가지 조언을 들을 수 있다는 것이 중요합니다. 이러한 도움을 요청하기 위해서는 끊임없이 Stay in touch 지속적으로 만나고 애기를 나누어야 하며, 업무가 아닌 개인적인 애기들도 공유할수 있어야 합니다. (1분씩 돌아가면서 서로에게 일어났던 이야기나, 애기들을 나누는 것입니다.)

문제는 이러한 미팅에 절대 강제성을 부여해서는 안됩니다.  누군가가 돌아가면서 발표를 해야 한다거나, 아침에 하는 것은 반대입니다. 이것때문에 준비를 해야 된다는 부담감으로 다들 힘들게 준비한 경우도 있고, 또한 아침 출석 체크와 동시에 상사의 명령 하달의 시간으로 변해서,  오히려 자유로운 팀원의 분위기를 망칠 수도 있습니다.  Brown Bag 패턴을 꼭 이용하세요.

다른이에 게 도움을 청함으로써 Local Sponsor 나 Coporate Angel (수호 천사)를 만들수 있습니다. 자신의 의견에 동조하고 지원해주는 든든한 지원자를 만들게 됩니다. 이렇게 함으로써 업무시 방해가 되는 벽을 위 사람이 제거해 주고, 더 쉽게 더 수월하게 일을 진행할 수 있게 됩니다.  물론 Local Sponsor나 Coporate Angel에게 나의 변화가 옳다는 정보를 끊임없이 만들어서 공유하는 것이 중요합니다.  Small Success로 이것을 해결해야 합니다.

또한  다른이에게 무조건적인 도움 요청으로 보일 정도로 요청해서는 안됩니다. 잘 정돈된 형태로 질문을 해야 하는 것이 중요합니다. 가는 질문이 명확해야 오는 답변 또한 명확 할겁니다. 무엇에 도움을 받아야 할지 정작 모르면서 요청하는 경우 반감을 불러 일으킬수 있습니다.  도움을 받기 위해선 중요한 건 요청 하는것 과 도와주는것은 서로서로 발전 하는 과정으로도 볼수있습니다. 충분한 검토와 생각을 해보고 요청하는 것이 중요합니다.  그리고 보너스로 손정민 님이 공개한 Ask for help 패턴의 원본 요약버젼도 읽어보세요.

Thanks to EVA

이번 Post는 저희 EVA 스터디 팀원들과 같이 스터디하면서 나온 내용들을 정리한 내용입니다.

현재 Fearless Change의 번역과 같이 진행을 하고 있으며, 스터디에 참여하시면 여기서 공개하지 못하는 개별적인 패턴에 대한 자세한 정보들을 더 접할 기회가 생깁니다.

---

[1] Z군의 재미난 postmortem의 이야기로, 프로젝트가 끝난시점에  설문지를 통해, 개발자들의 만족도, 무엇이 잘못 되었는지, PM은 잘 했는지 이러한 애기를 설문지로 돌리는 방식을 사용했다고 합니다.  공공연하게 아랫사람이 불만을 애기할 수 있는 것이 장점이라고 하더군요.  흔히 정작 PM은 바빠서 개발자 회의에 들어오지 못해서 제대로 된 방향 설정이나, 개발자간에 상충되는 의견 조율을 해주지 못했다고 하더라구요.