»
S
I
D
E
B
A
R
«
명시적 공정 제어 모델과 경험주의적 공정 제어 모델
Mar 8th, 2010 by Wegra Lee

거의 아무런 정보도 없이 이제 시작하는 프로젝트에 대해 일정을 내놓으라는 이야기를 너무 많이 들어왔고, 그 때마다 신뢰 구간 -50% ~ + 300% 의 일정이 그렇게 중요하냐고 묻으며 항의해보았다. 돌아오는 답변은, ‘그래도 일정은 필요하지 않느냐?’ 정도.. -_-a 결국 ‘일정을 위한 일정’ 만들기를 하게 된다.

어쩔 수 없이 일정을 내어주며, ‘이것은 신뢰성 10% 에요’ 라고 강조해보지만 절대 귀담아 듣지 않는다. 그 일정을 기준으로 종속된 모듈/기능 등을 고려한 전체 일정이 산출되고 임원들에게까지 보고된다. 그리고 기획과 마케팅 부서 역시 이를 기준으로 상품화 일정과 마케팅 일정을 등을 잡아 놓는다.

조금만 지나면 ‘신뢰성 10%’ 일정은 부메랑이 되어 개발자들을 옭아매기 시작한다. 진행중 (예외 없이) 예상치 못했던 문제들이 붉어져 나와도 ‘이미 윗선에 보고가 되어 있고 다른 부서들이 그에 맞춰 움직이고 있기 때문에 어쩔 수 없다. 무슨 수를 써서라도 이 때 끝내야 한다’는 식이다.

중간 관리자 몇 명만 설득해서 될 일은 아니다. 그들 대부분도 스스로를 피해자라 생각하고 있다. (틀린 말은 아니지만, 그들 중 윗사람들의 인식을 바꿔보려고 노력하는 사람은 단 한 명도 만나보지 못했다. 아쉽다.) 그래서 적어도 임원들까지는 제대로된 소프트웨어 개발 모델을 이해시킬 필요가 있다.

하지만 권위도 없고 직급도 낮은 사람들이 아무리 떠들어봐야 먹힐리 만무하다 (당장 바로 윗사람도 귀담아 듣지 않는데 -_-a). 책 좀 보라고 던져 주는 것도 아닌 듯 싶고.. 이런저런 생각을 해보다 우선 참조하기 좋은 블로그에 괜찮은 글을 하나 발췌해 놓기로 했다.

이 글은 스크럼 : 팀의 생산성을 극대화시키는 애자일 방법론 [1] (원서: Agile Software Development with Scrum [2]) 에서 발췌한 내용이다. 2장 ‘스크럼 준비 – 스크럼은 다르다’ 중 프로세스 제어 모델에 대한 블록으로, 저자가 왜 전통적인 프로세스들이 계속 실패하는지에 대한 통찰을 얻게된 계기를 이야기한 부분이다.

나는 1990년대 초반에 MATE라고 불리는 프로세스 관리 제품을 개발하고 라이선스하던 소프트웨어 업체를 운영했다. 우리의 최대 고객은 쿠퍼스 & 라이브랜드와 IBM 이었는데, 그들은 우리가 그들의 방법론을 사용해서 MATE를 개발하기를 원했다. 몇 차례 시도하긴 했으나 그 결과는 전적으로 불만족스러웠다. 당시, 우리 회사의 요구사항은 끊임없이 변하고 있었고 우리는 계속 신기술들을 도입하로 있었는데, 그 방법론은 우리를 도와주기는커녕 오히려 장애물을 만들고 유연성을 떨어뜨리는 등 마치 우리의 발목을 잡는 것과 같았다.

나는 왜 우리 고객들의 방법론이 우리 회사에는 효과가 없는지를 알고 싶었다. 그래서 1995년, 듀폰 연구소의 공정 제어 이론 전문가에게 시스템 개발 방법론에 대한 자문을 구했다. 바바툰데 ‘툰데’ 오거나이케(Babatunde ‘Tunde’ Ogannaike) 박사가 이끄는 전문가들은 산업 공정 제어 분야(industrial process control)에서 가장 존경 받는 이론가들이었다. 그들은 공정 제어에 대해 속속들이 알고 있었다. 심지어 연구자들의 일부는 유명 대학들에서 해당 주제에 대한 강연을 하기도 했다. 그들 모두가 시장 예측에서부터 제품 주문과 배달에 이르기까지 듀폰의 제품 생산 전 공정을 자동화하는데 관여하고 있었다.

듀폰의 연구자들에게 우리의 시스템 개발 프로세들을 살펴보도록 한 것은 듀폰의 연구자들에게 엄청난 우스갯거리를 선사한 거나 마찬가지였다. 그들은 우리 시스템 개발 산업이 전적으로 부적절한 공정 제어 모델에 따라 개발을 하고 있다는 사실에 깜짝 놀랐고 매우 의아해 했다. 듀폰의 연구자들은 시스템 개발이 너무 복잡하고 예측하기 힘들기 때문에, ‘경험주의적’이라고 부르는 다른 공정 제어 모델을 사용해야 한다고 말했다. 그들은 내가 왜 올바르지 못한 길로 가고 있는지를 이해시키기 위해서, “프로세스 역학, 모델링과 제어(Process Dynamics, Modeling and Control)” 라는 산업 공정 제어 이론의 필독서를 권했다.

간단히 말하자면 공정 제어에는 두 가지 주요 접근법이 있다. 하나는 ‘명시적인(defined)’ 공정 제어 모델로서 작업자들이 작업의 모든 부분을 완전히 이해해야 하는 것이다. 사전에 잘 정의된 일련의 입력들이 주어지면 매번 동일한 결과물이 산출된다. 명시적인 프로세는 완료 시점마다 매번 동일한 결과물을 내놓는 경우에 적용 가능하다. 툰데 박사는 내가 그에게 보여준 방법론들이 앞서 설명한 명시적인 프로세스를 사용하려고 했지만, 어느 프로세스나 태스크도 반복 가능하며 예측 가능할 정도로 충분히 명시되어 있지 않다고 말했다. 또한 그는 우리 산업이 명시적인 접근법을 쓰기에는 너무 많은 사고와 창조성을 요구하는 지식 집약적인 사업이라고 했다 툰데 박사는 우리 산업이 명시적인 방법론을 사용할 경우, 통제력 상실과 불완전한(혹은 잘못된) 제품 생산을 초래할 것이라는 사실을 이론적으로 증명해 보였다. 그럼에도 우리 분야의 여러 태스크들이 마치 시작과 종료가 예측 가능하기라도 한 듯이 명시적인 공법 프로세스처럼 서로 종속적으로 연결되어 있다는 점을 놀라워했다.

한편, 툰데 박사는 불확실성을 기반으로 하는 경험주의적인 공정 제어 모델에 대해서도 설명해 주었다. 경험주의 모델은 불완전하게 정의되어 예상 못한 결과를 만들어내는 프로세스를 빈번하게 검사하고 적응하는 방식을 통해 프로젝트를 제어하는 방법을 제공한다. 그는 내게 이 모델을 연구해서 시스템 개발 프로세스에 적용해볼 것을 권유했다.

듀폰 연구소 방문 기간 동안 나는 이 문제에 대한 진정한 통찰을 얻었다. 갑자기 내 안의 무엇인가가 번뜩이더니, 왜 우리 산업의 모든 사람이 시스템을 구축하는 데 그런 문제를 겪는지를 알게 되었다. 즉, 왜 우리 산업이 그런 곤경에 처했고, 형편없는 명성을 갖게 되었는지를 깨달은 것이다. 우리에게 필요한 것은 빈번하고 직접적인 테스트와 그에 뒤이은 즉각적인 수정임에도 불구하고 우리는 마치 조립 라인에서 일하는 것처럼 업무를 처리하는데 시간을 낭비하고 있었던 것이다.

경험주의적 공정 제어 모델은 애자일 측에서 목에 핏대가 서도록 강조하는 것들이다. 빈번한 검사와 즉각적인 적응 과정. 이를 위해 항시 동작 가능한 제품을 만들고 고객과 직접 ‘이것이 원하는 것이 맞는가?’를 확인하고 조정하는 것이다.

전통적인 프로세스에서도 이를 간과하고 있지는 않다. 다만 그 중요성을 제대로 인지하지 못하고 충분히 강조하지 못하고 있었다고 말할 수 있겠다. 그리고 안타깝게도 내가 만나본 SE 전공자들 대부분은 스스로도 깨닫지 못하고 있어 잘못된 사상과 프로세스를 전파하고 강요하고 있었다.


References

  1. 스크럼: 팀의 생산성을 극대화시키는 애자일 방법론 (켄 슈와버, 바이클 비들 | 박일, 김기웅 | 인사이트)
  2. Agile Software Development with Scrum (Ken Schwaber, Mike Beedle | Pearson Education, Inc)
수용하기.. 혁신을 이끌어 내는 방법
Feb 9th, 2010 by Wegra Lee

쉬어가기[1]는 창의력을 끌어내는데 주안점을 두고 있고, 직접보기[2]는 생각을 현실화시켜 진정 원하는 것을 찾아가는데 초점을 맞추고 있다.

그리고 이제부터 살펴볼 수용하기는 변화를 권하고 받아들임으로써 개발자들에게 능동적 에너지를 불어 넣으려는 자세이다. 따라서 조직에서 권한을 쥐고 있는 윗사람들에게 크게 요구되는 자세이다.

조직에 변화를 불러 일으키려 할 때, 윗사람이 주도하는 하향식(top-down) 시도는 좋은 결과를 낳기 어렵다[3][4]. 특히나 한국처럼 수직적 위계질서가 철저한 문화에서는 윗사람의 지나가는 말 한 마디가 수십, 수백명을 고생하게 만들 만큼 파급이 크다. 심지어 조직 운명이 뒤바뀌기도 한다. 때문에 설사 올바른 말을 하더라도 확대 해석되고 준비도 없이 무조건적으로 즉시 수행하려해서 한 바탕 소동이 벌어지곤 한다.

효과적이고 지속적인 변화를 위해 윗사람에게 필요한 자세는, 변화를 겸허히 수용하고, 그런 분위기를 조성하고 문화를 만들어가는 것이다.

잠시 아쉬운 경험담을 하나 떠올려보겠다. 얼마전 수백명에 달하는 조직 구성원 전체가 모여 이것 저것을 공유하는 자리가 있었다. 그 중 임원들에게 궁금한 것을 여쭐 수 있는 시간이 주어졌고, 이런저런 이야기를 하다가 한 임원께서 조직의 변화에 대해 잠시 언급하셨다.

“조직은 쉽게 변하지 않는다. 조직이 변하길 기대하기보단 각자의 위치에서 스스로 변화시킬 수 있는 것을 찾아보아라.”

다소 차이가 있을 수 있으나 내가 이해한 의미는 이렇다. 현실의 모습을 있는 그대로 솔직히 이야기한 것이고, 남에게 바라기 앞서 스스로 변화를 시도하라는 좋은 이야기였다.

하지만 난 이 말에 적잖이 실망할 수 밖에 없었다. 왜일까? 만약 이렇게 이야기했다면 어땠을까?

“조직은 쉽게 변하지 않는다. 하지만 좋은 의견을 주면 내가 힘이 닿는데까지 그렇게 변화시킬 수 있도록 도와주겠다. 중간층에 있는 분들도 팀원들이 좋은 아이디어를 주면 최대한 반영할 수 있도록 힘써달라. 만약 내 힘이 필요하다면 누구든 도움을 요청하라. 다함께 힘이 닿는데까지 일할 맛 나는 팀을 만들어보자.”

조직은 쉽게 변하지 않는다는 사실엔 변함이 없다. 하지만 전자는 개인의 변화 의지를 크게 억누르는데 반해, 후자는 의욕을 한층 불살라줄 것이다.

중요한 것은.. 말과 격려에서 끝나면 안된다는 것이다. 불편사항을 누구든 편하게 개진할 수 있고, 개선 방법을 논의할 수 있는 장을 마련해 주어야 한다. 사람들이 쉽게 나서지 못한다면, 익명이 보장되는 토론장을 만들어주는 것이 큰 도움이 될 것이다. 애자일 회고(Retrospective) 제도[5]를 도입해 보는 것도 적극 권장한다. 그리고 이렇게해서 나온 좋은 아이디어들을 작은 것부터라도 하나씩 수용해가며 차근차근 개선되는 모습을 보여줘야 한다.

그럼 윗사람들이 주의해야할 점 몇 가지 집어보자.

‘이봐들! 개선 아이디어를 가져와봐!’ 라고 강압하는 것은 좋지 않다. 이런 명령은 실무자들이 스스로 불편사항을 찾고 자율적으로 개선해나가는 분위기에 찬물을 끼얻을 우려가 있다. 단, 익명 보장 등 조치를 취해 주었는데도 아무도 의견 개진 없이 시간만 흐른다면 한 번쯤 발동을 걸어주는 것은 필요할 수 있다.

‘얼마나 개선되었는지 보고해봐!’ 와 같은 요청은 더 큰 위험을 안고 있다. CMMI 나 SPICE 등 개발 역량 평가 모델의 더 높은 등급을 받기 위해 벌어지는 상황이 재현될 가능성이 높다. 다시 말해 수치적으로 측정 가능하고, 형식적인 변화에 치중될 우려가 생긴다. 심할 경우, 개발자들은 변화에 회의를 느끼고 더 이상 적극적으로 참여하지 않게 될 것이다.

가만히 놓아 두어도 개발자들은 알아서 쓸데 없는 일과 꼭 필요하지만 귀찮은 일 그리고 수작업 등을 줄이고 생산성을 높이는 방향으로 변화시킨다. 더 효율적인 솔루션을 찾아 시도해보고 적용한다. 물론 시행착오를 거친다. 그래서 더 안좋아지는 부분이 생기면 되돌아가거나 다른 안을 시도해보며 결국 생각할 수 있는 최선의 방식으로 수렴해간다. 제도와 권위로 가둬놓지만 않으면 팀은 좋은 방향으로 진화해 나갈 수 있다.

정리해보자.

  • 윗사람은 변화를 주도하기 보다는, 변화 에너지를 불어 넣고 변화를 돕고 그 모습을 수용하자.
  • 아랫사람은 능동적으로 변화에 참여하고 장단점을 몸소 체험하며 배우자.
  • 상향식도 하향식도 아니다. 함께 만들어가는 변화이다.

References

  1. 쉬어가기.. 혁신을 이끌어 내는 방법 (wegra.org)
  2. 직접보기.. 혁신을 이끌어 내는 방법 (wegra.org)
  3. 하향식 변화 도입에 대한 환상 (김창준, 애자일 컨설팅)
  4. Bad Team Culture – 변화의 시작.. 상향식? 하향식? (wegra.org)
  5. Bad Team Culture – Lessons Learned as a Last Will (wegra.org)
애자일 도입 실패 이유?
Feb 3rd, 2010 by Wegra Lee

STEN [1] 에서 재미난 설문을 하고 있다. 아직 진행중이지만 상황을 대략 파악할 정도는 나온 듯 싶다.

“국내 프로젝트에서 애자일을 도입했다가 실패했다면 그 이유는 무엇인가?”

1. 국내의 전반적인 소프트웨어 개발 프로세스 성숙도가 낮기 때문 (19.0%)
2. 과도한 애자일 프랙티스를 경험이 부족한 상태에서 여러가지를 동시에 적용하려 하기 때문 (25.4%)
3. 애자일한 개바 프로젝트에서 테스팅을 어떻게 해야할지 잘 모르기 때문 (9.5%)
4. 애자일 개발의 사상이나 이의 도입에 따른 개발 문화의 변화에 대한 고려없이 테크닉만으로 접근하기 때문 (44.4%)
5. 기타 (1.6%)

나는 4번을 찍었다. 물론 다른 이유들도 많다. 예를 들어 팀원 & 조직 전체가 변화의 필요성에 대해 공감한 상태에서 진행하느냐도 포함될 수 있다. 그리고 어느 하나의 이유보다는 여러 가지가 복합적이다.

나도 애자일 도입을 외치지만, 수많은 경험을 통해 아주 신중하게 접근해야 함은 뼈저리게 느끼고 있다. 어설프게 접근했다가는 ‘해봤는데.. 별 효과 없더라.’라는 부정적 인식만 남기기 쉽기 때문이다. 그리고 이는 소위 heavyweight 개발 프로세스 등 SE 가 지금껏 저질러왔던 과오이다. 애자일에서도 똑같은 일이 반복된다면 개발 문화를 개선할 수 있는 기회가 언제 다시 올 지 예측하기 어렵다.


References

  1. STEN (Software Test Engineer Network)
[updated] 직접보기.. 혁신을 이끌어내는 방법
Feb 2nd, 2010 by Wegra Lee

쉬어가기.. 혁신을 이끌어내는 방법 [1]‘ 에서는 개발자들에게 쉬어갈 수 있는 시간을 제공함으로써 창의와 혁신을 이끌어는내는 이야기를 해보았다. 이번에는 ‘직접보기’라는 주제로 비슷한 이야기를 해보려 한다.

‘직접보기’ 가 필요한 이유는 아래의 그림을 보고 생각해보자. 이 그림이 말하고자 하는 원목적은 완전히 동일하진 않지만, 실물을 보지 않고 커뮤니케이션 했을 때의 문제를 효과적으로 말해주고 있다.

정리하면 고객이 원하는 것을 각 사람/조직마다 다르게 이해하고 있으며 심지어 고객 스스로도 자신이 무엇을 필요로 하는지 알지 못한다 것이다.

시장 조사를 토대로 고객의 needs 를 모두 만족시킨 제품의 출시 후 반응이 그리 좋지 않은 수많은 사례들을 잘 설명할 수 있는 논리이기도 하다.

혁신적인 제품을 잘 만들어내기로 유명한 애플(Apple)사의 경우, 신제품을 만들 때 시장 조사를 아얘 하지 않는 것으로도 유명하다(You Can’t Innovate Like Apple [2]). 시장에 존재하지 않는 제품에 대해 물어봐야 가치 있는 대답을 구하기 어렵기 때문이다. 대신 스스로 계속해서 실제품 수준의 프로토타입을 수없이 만들어보면서 직접 만져보고 써보며 자신들이 정말 이 제품을 원하는가를 판단한다. 그 결과 애플의 제품들은 종종 시장에서 당연히 필요하다고 생각하는 기능이 빠지기도 하고 이미 더 나은 제품들이 수두룩한데~ 라고 평가절하되곤 한다.

이미 만들어진 제품에 대해서는 다르다. 직접 사용해본 사용자들의 피드백은 소중하다. 애플 리테일 스토어가 중요한 역할을 수행하는데, 리테일 스토어의 직원들은 고객이 와서 들려준 이야기들을 놓치지 않고 본사로 보고하게 되어 있다. 그래서 스티브 잡스는 아이디어 도둑(유명 마케터 이해선 대표의 메시지 [3])이라는 말이 나오기까지 했다.

고객의 소리를 듣는 방식에 있어 두 경우가 다르다고 이야기했지만, 사실 그 원리는 동일하다. 바로 제품을 직접 만져보고 사용해본 사람들의 소리를 듣는다는 것이다.

이는 사실 애자일, 전통 할 것 없이 거의 모든 소프트웨어 개발 방법론에 중요하게 다루는 주제이고, 결론 또한 항시 동일하다. 짧은 반복 주기로 매 주기마다 동작 가능한 제품을 내놓고, 이를 고객에게 보여주고 피드백을 받는다. ‘당신이 말한 것을 우리는 이렇게 이해했는데, 이것이 정말 당신이 원했던 것이오?’ 를 확인하는 가장 중요한 절차인 것이다. 진정 공존을 원한다면 이 과정에서 쓸데없는 과장과 화려한 프리젠테이션은 없어져야 한다. 그리고 프로젝트 진행에 관련된 주요 인력들이 다 참석하는 것이 좋다. 고객, 프로젝트 리더, 영업 담당자, 주요 개발자들 등이 포함된다. 이들이 자주 모여 현실을 냉정하게 보고 허물없는 이야기를 하다보면 다음과 같은 반응들을 심심치 않게 목격할 수 있을 것이다.

  1. 내가 말했던 건 이게 아니었어요. 이러저런 모습을 상상했었는데요. 다음 릴리즈땐 이렇게 고쳐봐주세요.
  2. 내가 의도했던게 이게 맞긴 한데.. 직접 써보니 좀 이상하군요. 다른 아이디어가 있을까요?
  3. 이 부분은 제 생각과 다르긴 하지만.. 솔직히 지금이 더 좋아 보이는군요. 이대로 갑시다.

직접 보기는 서로의 생각을 확인하고 공유할 수 있는 가장 좋은 방법이며, 다음 방향을 결정짓기 위한 논의를 시작하기 위한 믿음직한 베이스가 되어준다.

또한 개발자들에게는 자신들의 창의력과 열정을 어필할 수 있는 절호의 기회가 되기도 한다. 직접 구현하면서 가장 먼저 써보게 되는 개발자들은 가장 빠르게 피드백을 줄 수 있는 훌륭한 고객인 셈이다. 이해한 요구사항대로 구현했을 시 불편한 부분이 있거나 더 나은 안이 떠오르면 릴리즈 전에 그 아이디어를 정리해두자. 가능하다면 직접 구현해서 보여주는 것이 가장 좋다. 직접 사용해본 고객과 말이나 문서 정도로만 본 고객은 확연히 다른 반응을 보인다.

이런식으로 개발자들의 능력을 인정받고 발언권을 강화해두는 것이 조직 전체의 커뮤니케이션과 생산성 향상, 제품 혁신에 긍정적인 영향을 줄 것이다. 개발자들은 기본적으로 창의적인 인력들이며, 이에 더해 현실적이다. Sci-fi 영화에나 나올 법한 허무 맹랑한 꿈을 꾸지도 않고, 일부러 과장하려는 경향도 적다. 먼 과거와 달리 골방의 괴짜들이 모여 있는 집단도 아니다. 윗사람들보다 신세대이며 소비의 주체라는 장점도 있다.

결론?

조직은 제품을 직접 보고 함께 이야기하는 문화를 정착시킴으로써 많은 것을 얻을 수 있다. 단, 어설프게 릴리즈 압박용으로만 오용하지 않도록 주의하자. 상향식 변화는 실패할 것이며, 하향식 변화는 성공한 것 처럼 보일 것이다. ^^ [4]

[updated]

사례를 몇 가지 추가해보기로 하였다.

  • Developing Torchlight [5] – Runic Games 사에서 Torchlight 라는 게임을 제작하는 방식을 이야기한다. 그들은 짧은 주기로 항시 play 가능한 게임을 만들어 개발자, QA 팀, 심지어 그드의 가족, 친구들까지 초대해서 게임을 즐기게 했다고 한다. 시장에서의 성공 여부는 아직 판가름하기 이르지만 기대를 가지고 지켜보고 있다.
  • 와우 성공 요인은? [6] – 초창기 와우 개발을 이끌었던 블리자드의 수석 PD 인 셰인 다비리 를 인터뷰한 내용이다. 초창기 가장 어려웠던 점 중 하나는 블라지드로써는 낯선 장르였던 MMORPG 의 비전을 경영진에 설득하는 것이었다고 한다. 직접 만들어 알파 버전을 보여주니, 절대 성공할 수 없다고 말하던 사람마저 하루 아침에 자신의 편이 되었다 한다.
  • Eclipse [7] 와 Jazz/RTC [8] – 오픈소스 개발 환경 프로젝트 중 역사상 가장 성공적인 프로젝트 중 하나인 Eclipse 와 그 개발 과정에서 얻은 노하우까지 툴에 녹이고 있는 Jazz/RTC 프로젝트도 좋은 예가 될 수 있다. 이들은 1년 주기의 정식 릴리스 사이에 6주 정도의 간격으로 다수의 안정적인 Milestone 버전을 내놓는다. 그리고 이전 릴리스 대비 어떤 기능이 개선되었는지 알기 쉽게 보여주는 New & Noteworthy 를 함께 알려주어서 사용자들이 정식 릴리스를 기다리지 않고도 새로운 기능들을 빠르게 접해볼 수 있다. Milestone 버전은 충분히 안정적이기 때문에 critical 한 프로젝트가 아니면 큰 부담 없이 새 milestone 을 테스트해본다. 이런 방식으로 사용자 커뮤니트의 빠른 피드백을 유도해 지속적으로 다음 릴리스에 반영해나간다.
  • Mobile SecondLife [9] – 내가 참여해 진행하다 중단된 프로젝트다. 과제 초창기부터 개발진에서는 도저히 성공 가능성이 없다고, 이걸 누가 쓰겠냐며 과제의 의미를 찾지 못하고 있었다. 링크의 데모는 연구 성격의 개념적 시연이어서 상당히 제한적인 환경에서만 동작 가능했다. 이를 바로 상품화하려 하니 현실적인 제약들 때문에 흥미로운 개념들의 거의 모두를 다 들어낼 수 밖에 없었다. 남은 것만으로는 정말 시도할 가치가 없는 과제였다. 하지만 그 목소리가 경영진에까지 전파되지는 못했다. 수개월간의 고생 끝에 만들어진 베타 버전을 임원에게 시연한 바로 다음날 과제는 바로 중단되었다.

References

  1. 쉬어가기.. 혁신을 이끌어내는 방법 (wegra.org)
  2. You Can’t Innovate Like Apple (Pragmatic Marketing)
  3. 유명 마케터 이해선 대표의 메시지 (제레미의 TV 2.0 이야기기)
  4. Bad Team Culture – 변화의 시작.. 상향식? 하향식? (wegra.org)
  5. Agile Approach in Game Development (wegra.org)
  6. 와우 성공 요인은? 전 수석 PD 셰인 다비리 인터뷰 (Inven Communications)
  7. Eclipse (Eclipse Foundation)
  8. Jazz/RTC (IBM Rational)
  9. Mobile SecondLife (Samsung)
[나쁜 팀 문화] 변화의 시작.. 상향식? 하향식?
Feb 1st, 2010 by Wegra Lee

조직의 변화에 대해 이야기할 때, 상향식(bottom-up), 하향식(top-down) 운운하면서 서로 책임을 회피하는 경향이 심하다는 느낌이다.

상향식은 조직의 아랫사람들부터 변화의 물결이 일어 결국 윗사람들까지 동참시키는 경우이고, 하향식은 반대로 윗사람의 의지에 의해 아래까지 변화를 일으키는 방식이다.  어느 방식이 더 나은 선택이 될 것인가? 만약 어느 한쪽을 운운하는 사람은 변화도입에 대한 전문성이 부족하거나(하향식 변화 도입에 대한 환상[1] – 김창준), 혹은 자신의 책임을 회피해보려는 시도를 하고 있다고 볼 수 있을 것이다.

하향식 변화 도입에 대해선 위 김창준씨의 글을, 상향식 변화 도입에 대해서는 일전에 내가 작성해둔 글 – Show Me The Magic[2]을 참고하면 좋을 것이다. 그리고 그 둘의 결론 역시 Show Me The Magic 에 잘 나타나 있다.

그럼에도 이 글을 적는 목적은, 조직에서 자신의 위치, 자신의 역할에 대한 자각의 필요성을 느껴서이다.

내가 변화시켜보려 했던 팀에서 가장 큰 문제들은 바로 하급 관리자가 조직의 머리에 해당하는 사람들의 논리를 대변한다는 것이었다. 대략 8 단계로 이루어진 조직 피라미드의 밑에서 3번째에 위치한 사람들에 해당하는 이야기이다.

아래에서 3번째이면 말단 관리자, 즉 아래에서부터 올라가 최초로 ‘관리자’라는 타이들을 달아볼 수 있는 직급이다. 이 계층의 구성원들이 ‘먼저 다른 사람들을 다 설득시키고 나한테 오라’, ‘정말 좋으면 내가 참여 안해도 다들 하겠지’ 라는 말을 하고, 뒷짐진채 ‘자! 재주껏 나를 설득해봐!’ 라는 자세를 취한다. 그러면서 ‘역시 상향식 변화는 안되’라고 말하는 모습을 보며 ‘당신이 현 조직에서 윗사람에 해당한다고 생각합니까?’라는 말이 목구멍까지 올라왔지만 참은 적도 몇 번 있다. ^^

그 계층에서부터 공감대를 형성하고 의지를 다져 변화를 이야기해야 비로서 ‘상향식 변화의 첫 발을 내딛었다’ 라고 할 수 있다. 아랫 사람들의 목소리를 전파해줄 수 가장 낮은 위치의 사람들이 그 위치에 올라서자마자 이런 마음자세로 돌변한다면, 그 조직은 절대 변화할 수 없다. 그렇다면 하향식 변화를 기대해야 할까? 그것 역시 환상이다[1].

이 글을 읽는 분들은 자신이 조직에서 어느 위치에 있는지, 그 위치에서 어떤 역할을 해주어야 더 나은 조직으로 변화할 수 있을지 찬찬히 생각해보았으면 한다.


References

  1. 하향식 변화 도입에 대한 환상 (애자일 이야기, 김창준)
  2. Bad Team Culture – Show Me The Magic (wegra.org)
[나쁜 팀 문화] 점진적 지연 정책에 관하여
Jan 16th, 2010 by Wegra Lee

어제는 오랫만에 깨어 있는 SE 전공자를 만났다. 여러 화두들 중 일전에 포스팅한 [나쁜 팀 문화] 점진적 지연 [1] 에 관한 이야기가 나왔고, 그분은 재미난 해결책 하나를 말씀해 주셨다.

먼저.. ‘점진적 지연’이란 현상적으로 보면 주요 마일스톤 일정을 막바지에 조금씩’만’ 뒤로 미루며 결국 긴 기간동안 지연되는 것이다. 어쩔 수 없이 나타나는 현상이라면, 그리고 이를 문제로 인식하고 해결하려고 하는 조직이라면 미래가 있다. 하지만 내가 보아온 많은 조직에서는 관리자들이 의도적으로 이런 정책을 편다.

그들은 ‘9월에 끝날 거 같은 과제라면 6월에 끝내라고 해야 그나마 9월에 끝이 난다’라고 말한다. 그들 믿음의 기반은 ‘개발자는 일정으로 쪼지 않으면 일을 열심히 하지 않는 게으른 존재’ 라는 것이다. 그러면서 이게 노하우이고 자신이 팀을 잘 이끌고 있다고 믿는다.

노동 집약적 산업 시대의 잔재인 듯한 이런 시도는 신입사원처럼 아직 조직에 적응하지 못한 사람이나 선천적인 워커홀릭 정도에게나 효과를 보인다. 워커홀릭은 몸이 부서지거나 삶의 전환이 될만한 계기가 찾아오지 않는한 열심히 일하지만, 신입사원들은 기껏해야 한 두 해면 유효기간 만료이다. 결국 9월이 지나고 10월, 11월이 지나도 끝나지 않는다.

왜 그럴까? 관리자들은 종종 ‘내가 6월이라고 말했지만 사실 난 9월로 예상하고 있어’라는 것을 자신만 알고 있다고 ‘착각’하기 때문이다. ‘당신만 아냐? 나도 안다.’ – 개발자들의 마음속이다. 물론 9월이라고 똑같이 예측하는 사람은 일부, 대부분은 자기 나름의 예상치를 잡거나 아예 관심 없어 한다. 즉, 명목상 한 팀임에도 불구하고 멤버들이 목표에 관심이 없거나 제각각의 기준으로 일에 임하는 것이다. 이런 콩가루 팀과 원래부터 9월을 목표로 하여 멤버들 대다수가 ‘어! 잘하면 될 거 같은데, 한 번 해보자!’라고 뭉쳐진 팀, 둘 중 어느 팀이 빠른 시간 안에 높은 품질의 제품을 내놓을 수 있을까?

해결책?

스스로 제시한 목표치에 훨씬 못미치는 관리자 한 두 명만 본보기로 잘라 버리는 것이다. 마음대로 자를 수 없다면 다른 팀에 전배를 보내거나, 다른 일로 전형시켜버리면 된다. 위화감을 느낀 관리자들은 현실적인 목표를 잡기 위해 혈안이 될 것이다.

배우려는 마음과 변화해보겠다는 의지 없어서 그렇지, 현실적인 목표를 잡는 것은 그리 어려운 일도 아니고, 관리자 혼자 머리 싸매고 미래를 예측해야 하는 일도 아니다. 위의 충격요법은 절박함을 심어주어 마음과 의지를 북돋아줄 것이다. ^^

그럴 일은 없겠지만, 현 팀에서도 한 번쯤 이런 일이 일어났으면 좋겠다. 모두에게 공감대가 형성되고 내게 그만한 권한만 주어진다면 크나큰 변화를 이끌 자신이 있는데 말이다. ^^

참고로, 연구 성격의 과제라 누구도 앞을 예측하기 어려운 경우에는 짧은 iteration 을 돌며 그때 그때의 성취를 공유하는 방법이 가장 좋다.

글을 적으면 생각이 나서 리더 vs. 매니저 [2] 도 업데이트 하였다.


References

  1. [나쁜 팀 문화] 점진적 지연 (wegra.org)
  2. 리더 vs. 매니저 (wegra.org)
[나쁜 팀 문화] 안티 투명성
Jan 7th, 2010 by Wegra Lee

몇달 전에 프로젝트 투명성(Project Transparency)에 대한 글[1]을 올린 적이 있다. 당시에는 프로젝트에 투명성을 부여함으로써 얻을 수 있는 장점을 중심으로 설명하면서, 이를 읽은 프로젝트 팀들에서 투명성 확보를 위해 노력해주길 바라며 글을 적었다. 하지만 최근에 들어서는 관리자들이 일부러 과제를 불투명하게 만들고 있는 것이 아닌가 하는 의구심이 들기 시작했다. 아니! 감시 받는게 아니냐는 느낌을 떨치기 어려운 실무자들도 아니고, 오히려 현 상황을 정확히 알고 싶어할 듯한 관리자들이 도대체 왜? 지금부터 천천히 이야기 해보기로 하자.

나는 Rational Team Concert (RTC) [2] 라는 Application Lifecycle Management 시스템은 팀 내에 소개/교육/운영하고, 몇 차례에 걸처 그 결과를 공유한 적이 있다. 당시 (지금까지도) 우리 팀은  과제 시작 후 크고 작은 릴리스 중 단 한 번도 목표일을 지켜본 적이 없었고, 지연 기간도 들쑥날쑥 예측이 어려웠다.  릴리스가 끝나고 나서야 비로서 ‘아! 이번엔 이만큼 지연됐구나’를 알 정도였다[3].

수 개월 동안 몇 차례의 릴리스 기간을 거치면서 RTC 가 보여주는 정보는 항시 일관적이고 명확했다. ‘현 상태로는 일정을 맞출  확률은 0% 이다.’ ‘당신의 팀은 task를 끝내기도 전에 끊임없이 새로운 task들을 더 추가한다.’ ‘당신 팀의 업무 수행 능력은 이 정도이다.’ ‘따라서 목표를 다 이루려면 x 일 정도 지연될 것이다.’ ‘일정에 맞추려면 a, b, c 등의 task 를 뒤로 미뤄야 한다.’ 이런 정보들을 한 눈에 확인할 수 있는 실시간으로 그래프를 제시해준다. 대표적인 그래프인 burndown chart 의 예[4]는 아래와 같다.그림과 같이 프로젝트의 현 상황과 진행 추이, 예상 완료 시점 등을 바로 확인할 수 있는 그래프를 전체 팀은 물론 서브팀별로 만들어주고, 누구나 보고 싶으면 언제든 웹을 통해 접근할 수 있다.

(Note: 위 그림은 우리 과제에서 얻은 실제 데이터 도, RTC 가 생성한 그래프도 아니다. 이해를 돕기 위한 단순 참고용이다. 또한 burndown chart 의 개념은 RTC 라는 특정 툴에 종속적이지 않다. Agile/Scrum 쪽에서 널리 활용하는 프로젝트 관리 기법으로 툴 없이도 쉽게 만들어 활용할 수 있다. RTC는 단지 이를 지원할 뿐..)

자! 어떤 결과가 예상되는가? 실무자들 중에는 사용해보고 싶다는 사람들이 조금씩 늘어났다. 반면 관리자들 중에서 관심을 가지는 사람은  거의 전무했다(그나마 계정만 만들고 실제 사용은 안함). RTC 라는 새로운 환경에 적응하기 위해 가장 많은 변화와 노력을 기울여야 하는 실무자들이 관심을 더 보이는 이유는 무엇일까? 역으로, 프로젝트의 목표와 일정을 세우고, 우선 순위를 조정하고, 업무 부하를 관리해야 하는 관리자들은 도데체 무엇 때문에 관심 자체를 보이지 않았던 것일까?

실무자들이 쓰는 이유는 주로 이러했다.

  • 자신에게 할당된 task 들을 효율적으로 관리/진행/보고하기 위해
  • 상사의 말도 안되는 업무 요청에 대한 방어/협상 자료로 활용키 위해
    • 내가 놀고 있나요? 그 일을 하길 원한다면, 여기 쌓여 있는 현 일들 중 어떤 것을 미룰까요?

관리자들이 쓰는 이유는 알 수 없다. 쓰는 사람이 없으니 -_-a

그렇다면 관리자들이 외면하는 이유는? 물론 수많은 요인들이 복합적으로 작용했고, 사람들마나 차이도 많다. (Note: 설문조사를 한 것은 아니고.. 대부분은 이런저런 주변 정황과 평소의 대화들을 토대로 유추해본 것 뿐이다.)

  • 현 상태에 만족해서 (여러 사람과 이야기해보았는데, 우리팀에는 해당되지 않는다. 모두가 불만이다.)
  • 단지, 새로운 것을 익힐 심적/시간적 여유가 없어서 (제법 많다. 위에서 시키지 않은 일에 에너지를 할애하길 꺼려한다.)
  • 다년간 체득한 ‘나서서 좋을 것 없다’ 는 경험 때문에 (조금 있다. 정말 좋으면 남들이 써보고 전파해주겠지 하는 생각.)
  • 귀찮아서 (역시 제법 되어 보인다. 새로운 것은 익히기 보단 다소 불편하더라도 익숙한 것에 머무르려 한다. 시도조차 안해본다.)
  • 투명해지면 안된다고 생각한다. (조금 있어 보인다. 이 글의 주제이므로 바로 뒤에 별도로 설명하겠다.)
  • 기타.. (여러가지 더 떠오르지만 주제와 큰 관련이 없으므로 생략)

투명해지면 안된다고 생각하는 사람들은 상위 지배층과 외부 사람들(stakeholder, customer 등)을 대하는 사람들일 경우가 많다. 이들에게 투명한 과제가 장점을 발휘하려면, 그 과제가 정말 잘 진행되고 있어야 한다는 전제가 깔린다. 이러저러한 문제들이 산적한 상태에서 잘못 공개되면 지원이 줄어들고 대기 수요가 빠져나간다. 이들에게는 안좋은 것을 숨기고 희망찬 메시지만 전달해주어야 한다. 단번에 ‘3달쯤 지연될 겁니다’라고 얘기하면 ‘그렇게까지는 못 기다립니다’라고 하지만, ‘1주일만 더 기다려주세요’를 여러차례 반복하면 ‘이왕 기다린 거, 이번엔 꼭 된다니깐 조금만 더 기다려보지.  등 돌리기도 늦은 것 같고..’ 하는 반응을 이끌어낼 수 있다.

위와 같은 이유로 의도적으로 투명성을 제한하려는 사람들이 있다고 믿는 근거는.. ‘팀 리더로써 가장 중요한 것은 프로젝트를 부러뜨리지 않는 것’ 이라거나, ‘이런 건 누구누구가 알면 안되는데’ 라며 정보 공개를 불편해하는 발언 등을 하는 윗 사람들을 종종 보았기 때문이다. 프로젝트를 계속 유지하는 것은 물론 중요하다. 하지만 외부에 알려진 것 대비 심각하게 안좋은 상황에서도 무리하게 정보를 숨기는 것은 과연 어떨까? 상황을 만회하기 위해 뒤에서 열심히 고생하는 개발자들과 이를 믿고 투자하는 사람, 제품을 기다리는 고객 모두에게 악영향을 미치게 된다. 투자자가 개발팀이 속한 회사 자체라면(내부 프로젝트), 그 팀은 프로젝트를 유지할 수록 회사의 경쟁력을 떨어뜨리게 된다.

다른 관점에서도 불투명한 과제가 (부정적인 의미에서) 도움이 될 때가 있다. 우리 팀의 모습을 앞서의 그림에 맞춰 비유해보면, 윗사람은 day 10 에 ‘자! 내일이 드디어 릴리스 날입니다. 오늘 저녁까지 남은 일들을 모두 완료해 주시고, 검증이 완료될 때까지 자리를 지켜주세요.’ 라고 당당히 요구하고, 또 그것이 개발자들에게 먹힌다. ‘얼마나 걸릴까요?’ 라는 질문은 없다. ‘반드시 끝내세요.’ 라는 요청이 전부이다. 실무자들은 불만이 있어도 드러내놓고 표출하지도 못하고, 밤 늦게나 자정을 넘어서까지 일을 한다. 당연히 기적은 일어나지 않는다. 만약 위와 같은 정보가 다 공개되어 있다면? 윗사람이 앞서와 같은 요구 자체도 할 수 없겠지만, 만약 그런 요구를 한다면 ‘당신은 눈이 없소?’ 라고 반박해도 할 말이 없을 것이다. 즉 과제가 투명해지면 지금까지와 같은 무리한 명령을 내릴 수 없다.

이상의 이유들로, 수단 방법을 가리지 않고 과제를 살리려 한다거나 전통적(?) 지배체제를 유지하고자 한다면, 프로젝트가 투명해지는 것은 커다란 위험요소가 될 수 있다. 이에 해당하는 사람들은 의도적으로 진행상태를 숨길 수 있다.

만약 이런 현상이 정말로 의도적으로 이루어진 것이라면 개선하기란 정말 쉽지 않다. 앞서 언급했듯, 팀을 이렇게 만든 사람들은 대부분 프로젝트 방향을 좌지우지할 수 있는 힘있는 사람들이기 때문이다. 자료를 아무리 제시해도, 개선의 움직임이 보이긴 커녕 거들떠도 보지 않는다면 실무자들도 제풀에 지쳐 변화를 포기한다. 힘있는 자들의 마인드가 바뀌지 않으면 조직의 문화를 바꾸는 것은 거의 불가능하다.

정리: 관리자들 대부분이 이와 같다는 의미는 절대 아니지만, 그 중 일부가 이런 생각을 어느 정도 가지고 있는 것은 분명한 것 같다. 따지고 보면 비단 특정 팀이나 회사, 소프트웨어 개발에만 국한된 현상도 아니다. 정보를 통제하는 언론, 기업의 홍보 부서, 조직의 대변인, 심지어 모든 사람 개개인이 외부로부터 자신을 지키기 위해 어느 정도는 이런 성향을 가지고 있다. 하지만 숨기는 대상에 외부 경쟁자들뿐 아니라 자신들을 믿고 따르는 조직원들까지 포함시켜 그들에게까지 희생을 강요하는 상황에 이른다면 문제는 심각하다. 이런 조직에서 과연 얼마나 많은 사람들이 진심으로 자신의 역량을 모두 쏟아 부어줄까? 하나의 팀이라고 말하기조차 부끄럽다.


References

  1. 프로젝트 투명성 (wegra.org)
  2. Rational Team Concert (IBM Rational)
  3. [나쁜 팀 문화] 점진적 지연 (wegra.org)
  4. Burndown chart (wikipedia)
[나쁜 팀 문화] 유언이 되어 버리는 Lessons Learned
Nov 20th, 2009 by Wegra Lee

Lessons Learned

그간 이 팀 저 팀에서 발간(?)한 수많은 소위 Lessons Learned 라는 것을 봐온바 있다. 과제를 진행하면서 느끼고 배운 것을 정리하여 다음 과제 진행시 참고하거나 진행중인 다른 과제에서 참고할 만한 좋은 정보들이 적혀 있다. 자신이 걸어온 길을 되돌아보는 것은 좋은 경험이고, 그 결과를 정리해 놓는 것 역시 권장할 만한 일이다.

문제는 그 시점이 항상 과제가 뿌러지는 등 완전히 종료되는 시점에 일어난다는 것이다. 많은 경우 팀 자체가 뿔뿔이 흩어지거나 축소된다. 다음에 진행할 과제도 이전 과제와 성격이 달라지기 쉽다. 얻은 것이 있어도 그것을 적용해볼 상황이 못되는 것이다.

과연 이전 과제에서 깨우친 것들이 새로운 과제 새로운 팀에서 제대로 먹혀들 수 있을까? 시행착오를 거쳐보지 않은 새 팀 멤버들이 가슴 깊이 공감하고 따라줄 것인가? 배경이 다른 사람들에게도 똑같은 처방이 여전히 유효할까? 내가 얻은 결론은 정말 더 나은 개선책인가? 아니면 단지 ‘다음엔 이렇게 해봐야지’ 정도인가? 검증되지 않았고 경험해보지도 못한 방법을 새 팀 새 과제에서 시험해볼 용기는 있는가?

위와 같은 고민들도 어느 정도 영향력이 있는 윗사람들에게 해당하는 것이지, 중간 이하의 힘없는 관리자나 실무자들은 새로운 리더가 시키는데로 그냥 따를 수 밖에 없는 것이 또 현실이다.

결국 이런 식의 Lessons Learned 는 읽을 거리나 유언장 이상의 실질적 가치를 갖지 못한다.

Retrospective

Retrospective 는 Lessons Learned 의 Agile 식 표현 정도로 생각하면 좋을 것이다. 하지만 많은 차이를 안고 있음을 잊어서는 안된다. Agile 이 강조하는 iterative, responsive, incremental 같은 속성을 Lessons Learned 에 부여해보자. 짧은 간격으로 주기적으로 회고하며(iterative), 현 시점에 필요한 이슈에 대한 개선안 만들어 다음 개발 주기에 적용해보아 좋은 것을 취하고 잘못된 것은 버리거나 다른 안을 찾아본다(responsive). 팀은 과제가 진행될 수록 조금씩 조금씩 더 나은 방향으로 발전해 간다(incremental).

이미 끝나버린 과거에 대한 무책임한 회상록이 아닌, 지금 살아서 꿈틀대는 과제에 대한 진중한 고민을 경험해볼 수 있다. 바로 그 시점에 팀원들 스스로가 개선이 필요하다고 느끼는 이슈들이 다뤄지고 합의된 개선책을 시행한다는 점에서 참여율이 높아지고, 높은 성공 확률은 덤으로 얻게된다. 혹 실패한다면 바로 다음 회고 때 그 원인과 또 다른 개선안을 찾게될 것이다. 시행착오를 통해 더 많은 경험을 얻게되고, 미처 고려하지 못했던 요소들이 있음을 깨닫게 된다. 넓고 세심해진 시야는 다른 문제에 직면했을 때도 좀 더 빠르게 더 효과적인 개선안을 찾게 도와준다. 반면 Lessons Learned 방식에서는 실패한 처음 안만이 남겨질 가능성이 농후하다. 회고가 거듭될 수록 팀의 생산성이 향상됨을 느낄 수 있을 것이다.

Barriers and Ways to Overcome

다 좋고 완벽해 보이는 회고도 무턱대고 적용하려 하면 말처럼 쉽지 않음을 깨닫게 된다. 내가 지금까지 발견한 중요 요인은 3 가지 이다.

첫째, 일정에 쫓겨서 회고에 할애할 시간적 여유가 없다.

이런 답변을 많이 들었는데, 시간적 여유가 없는 것이 아니라 회고의 효과에 대한 믿음이 부족하거나 새로운 것을 시도하는 것을 꺼리는 보수적 마인드의 팀일 가능성이 높다. 이런 경우엔 분위기 조성을 위한 물밑 작업부터 시작해야 한다. 말이 통하고 깨어있는 사람들이라면 직접적인 대화로 돌파할 수 있겠다. 뜻이 맞는 팀원이 소수라도 존재한다면 솔선수범해서 더 나아지는 모습을 직접 보여줄 수도 있을 것이다. 상황이 다양한 만큼 방법도 다양할 터이니 숙고해서 도전해보자. 단, 상대를 공격하는 것은 확실한 실패 방법이니 절대 피하길 바란다.

참고로 회고에 필요한 시간은 보통 2~4주에 1시간 정도면 충분하다. 물론 처음 시작할 때는 좀 더 많은 시간이 필요할 것이지만 두세번만 해보면 익숙해지고 소요 시간도 줄어든다.

둘째, 팀원들의 참여가 저조하다.

기껏 회고를 해보자는 허락을 받았는데, 정작 모인 사람들이 꿀먹은 벙어리 마냥 침묵으로 일관한다. 회고를 처음 시도하는 조직에서는 대부분 겪게 되는 인기 코스일 것이다. 그들이 침묵하는데에는 여러 가지 이유가 있을 것이다. 무슨 얘길 하면 되는거지? 예제 같은 거 없나? 얘기한다고 정말 개선해 주나? 말 꺼내면 나보고 꺼낸 사람이 하라고 하겠지? 불평하면 괜시리 밉보일 거야.. 등등.

이런 우려를 해소하고 적극적인 참여를 유도하려면 맛을 보여줘야 한다. 사소한 것부터라도 정말 개선되는 모습을 보여주는 것이다. 첫 회의에서 아무런 아이디어가 없을 것을 대비해 문제점과 개선안까지 몇 가지를 준비해둔다. 뜻이 맞는 사람이 한 명이라도 있다면 역할극을 해보는 것도 좋다. 혼자 북치고 장구치는 것보다 훨씬 효과적으로 분위기를 이끌어 갈 수 있을 것이다. 그리고 개선안이 없더라도 불편한 사항을 자유롭게 이야기하도록 하고, 그에 대해 반박을 하거나 방어적인 모습을 보여서는 안된다. Brain storming 방식으로  문제들을 나열하고 중요도와 시급성, 파급 효과 등을 생각해 이슈를 선별해서 개선안을 모색해보자.

셋째, 팀에 부여된 권한이 너무 작다.

열심히 분위기 잡고 멋진 개선안들도 마련했다. 그런데 그 개선안들이 우리힘으로 할 수 있는 일들이 아니라면? 운영부서는 돈 들어가는 일은 절대 허락을 안해주고, 보안 부서는 개발자 편의성은 절대악으로 규정짓고, 프로세스 팀은 표준 프로세스에 어긋난 어떠한 시도도 용납하지 않고, 기획/마케팅 부서는 자신들이 바라는 모든 기능을 역시 자신들이 정한 시한까지 완수해야 한다고 못박고, 책상 앞에 앉아 있는 시간과 개발진도는 정비례한다고 철석같이 믿고 있는 임원이 군림하고 있다면?

회고는 불평불만을 토로하고 남들 뒷담화가 남무하는 장이 되던가, 소꼽장난하듯 사소한 문제들만 다뤄지는 비중없는 시간으로 전락할 것이다. 물론 작은 개선들이 차곡히 쌓여 큰 도움을 줄 수도 있을 것이고, 공동의 적을 향한 불평불만과 뒷담화는 팀원들을 단합시켜주는 효과도 있기는 하다. ^^

모든 것을 통틀어 가장 큰 장벽으로, 딱히 뾰족한 해결책도 없다. 때마침 임원 인사가 단행되어 깨어 있는 사람으로 교체되던가, 무슨 바람이 불어서 아주 권위 있는 컨설턴트의 도움을 받을 수 있다면 큰 힘이 될 것이다. 하지만 모두 다 운에 기대는 것이고.. 리더나 팀원들이 몸소 나서서 설득하고 싸우는 적극적 쟁취 방법도 물론 있다. 하지만 생태계에서 식물 급으로 취급되는 힘없는 개발팀이 얻어낼 수 있는 것은 많지 않을 것이다.


References

  1. Retrospectives by RTC dev. teams
  2. Agile Retrospective – Lessons Learned
[나쁜 팀 문화] 점진적 지연
Nov 19th, 2009 by Wegra Lee

점진적 지연이란 아주 짧은 간격으로 릴리스 날짜를 조금씩 미루는 행태를 뜻한다. 일단 릴리스를 시도해보고, 안되면 조금  (보통 1~3일) 미룬 후 다시 시도한다. 역시 잘 안되면 또 다시 미룬 후 시도한다. 이렇게 릴리스가 될 때까지 무한 반복하는 릴리스 관리 방식이다.

사례

내가 경험해본 최악의 상황은 이러했다. 원래의 릴리스 목표일은 금요일이다. 금요일이 되어서 시도를 해보았으나, 도저히 릴리스할 만큼의 품질이 나오지 않는다. 그래서 월요일로 목표를 바꾼다. 월요일에도 역시 원하는 품질에 도달하지 못했다. 다음날 다시 한 번 시도해보기로 한다. 마찬가지로 실패했다. 이와 늦은거 금요일로 다시 미룬다. 금요일도 여전히 실패.. 토요일.. 월요일.. 수요일.. 금요일.. 월요일.. 화요일.. 토요일.. ..

이런 식으로 가장 길게는 6주간 계속 릴리스만 한 경우도 있었다. 릴리스가 이렇게 한달 가량 지연되면 당연히 다음 릴리스에 일정에 지장을 주게 된다. 새로운 기능을 추가하는데 필요한 최소 시간이 있으므로 차례차례로 전체 일정이 연기된다. 하지만 다음 릴리스 시점에 와서도 크게 다르지 않다. 역시 또 몇 주의 지연이 발생한다. 그래서 ‘릴리스가 끝나면 (다음) 릴리스 일정이 바뀐다’, ‘릴리스가 되는 날이 릴리스 날이다 (역: 릴리스 날에 릴리스를 한다)’ 라는 말까지 하게 되었다.

위의 경우는 continuous integration (CI) 도 도입되지 않은 열악한 환경에서의 상황이었고(도입을 요구했지만 관심 갖는 사람이 없었음), 그 후 CI 가 도입되면서 상황은 많이 호전되었다. 하지만 여전히 제 때 릴리스 되는 경우는 전무했고.. 심한 경우 3주가 밀리기도 했다. 금요일 릴리스를 (주말을 열심히 일해서) 그 다음주 월요일 저녁에 할 수 있다면 대단히 이례적인 성공이 케이스가 될 정도였다.

악효과

Incremental Delay 가 팀 문화처럼 정착되면서 다음과 같은 부작용들이 나타나기 시작했다.

팀원들은 윗선에서 정한 릴리스 날짜(deadline)에 큰 의미를 부여하지 않게 되었다. 한 차례도 성공적으로 릴리스한 경험이 없으며, 릴리스가 연기되어도 아무 일도 발생하지 않음이 학습되었기 때문이다. 꼭 지켜져야하는 중요한 릴리스라 강조해도 마음속으론 ‘어짜피 안될걸..’이란 생각을 자연스레 하게된다.

서브팀별 개발 일정이 꼬이기 시작한다. 팀별로 이터레이션(iteration) 주어진 일의 양이나 생산성, 예측 정확성 등의 차이가 생겨 발생하는 현상으로.. 일부 팀은 일정에 맞춰 일을 끝내놓고 다음 릴리스를 위해 할 일을 준비하고 있다. 하지만 곧 될 듯 말 듯 하면서 릴리스는 기약없이 지연된다. 처음엔 2~3일 후면 될 거라 기대하고 잠시 쉬던 것이 하루 이틀씩 밀리면서 결국 이 주 삼 주 동안 제대로 진행할 수 없게 된다. 이런 경험이 잦아지면서 일부에선 중간중간에 변경된 코드를 밀어 넣는다. 다음 릴리스를 위한 개발 코드 브랜치와 (지연중인) 릴리스 브랜치 간에 코드 격차가 심해져, 개발 브랜치에서 해결된 문제를 릴리스 브랜치에 반영하는데 한참을 씨름하기도 한다.

윗선도 계속되는 릴리스 관련회의로 시간을 낭비하기는 마찬가지다. 현황을 파악하고, 얼마나 더 지연시킬 지 정하고, 지연이 미치는 영향을 분석하고, 이왕 지연된 것 미리 구현된 간단한 기능을 포함시킬 지 논의하고.. 자료를 준비해 더 윗선이나 마케팅, 기획, 운영(예산) 팀 등과도 계속 조율을 해야 한다.
야근과 주말 근무가 늘어난다. 일주일 단위로만 지연시켜도 호흡 조절과 재충전이 가능하겠으나, 지연 단위가 보통 1~3일 정도이고, 특히나 금요일 일정은 반드시 토/일/월로 지연된다.

고찰

무엇하나 좋을 게 없는 이런 비합리적 문화가 왜 개선되지 않는 것일까?

이런 현상이 반복되고 있음은 윗선에서 과제가 어떻게 돌아가고 있는지 전혀 파악하지 못하고 있다는 확실한 반증이다. 릴리스를 하기 위해 해야할 일이 얼마만큼 남아 있는지 도통 감이 없다. 개발자들의 생산성과 문제 해결능력에 대한 어떠한 정량적/경험적 데이터도 갖춰져 있지 못하다. 개발자 각각이 지금 무슨 일들로 얼만큼의 로드가 걸려있는지도 잘 파악이 안되고 있다. 해결해야할 문제들이 얼마만큼의 노력이 들어가야 하는지도 역시 감이 없다. 아직 드러나지 않은 문제들은 또 얼마나 될 지 역시 예상하기 어렵다. 결국 위에서 할 수 있는 말은 보통 ‘언제까지 이 문제들을 해결해라’ 정도에서 그친다.

제품의 설계나 코드의 품질이 크게 떨어지거나, 다뤄야할 대상을 개발자들의 완벽하게 이해하지 못하고 있을 경우 사태는 더 심각해진다. 분석하고 수정하는데 필요한 시간을 예측하기 힘들고, 수정시 부작용(side-effect)이 따를 가능성이 높다. 동작 여부만이 아니라 코드의 품질을 챙기는 개발 문화를 조성해야 하고, 서로 간의 잦은 리뷰를 통해 다른 팀원들과 개발 패턴, 노하우 등을 공유해야 한다.

관련 개발팀간 커뮤니케이션 효율성도 큰 영향을 미친다. 심한 경우는 핵심 모듈을 전혀 다른 팀에서 관리하고 있고, 우리 과제를 지원하는 것은 그 팀의 최우선 역할이 아닐 때이다(실제로 자주 접해보았다). 유관 팀들이 지리적으로 멀리 떨어져 있고, 원격지에선 문제를 재현하기 어려울 때도 마찬가지.. 어떠한 경우건 커뮤니케이션 지연은 일의 진행 속도를 현저히 떨어뜨리는 주요 원인이 된다. 과제를 기획하고 팀을 조직할 때 그 과제와 팀이 적시에 충분한 지원을 받을 수 있도록 고려해야 한다. 필요하다면 조직 구성을 바꿔 같은 명령 계통 내로 흡수할 필요도 있다.

미흡한 인프라에 의한 불확실성도 크다. 기본적인 테스트 자동화 시스템도 갖추지 못해 매번 개발자들이 수동으로 테스트하는 것도 많이 보아왔다. 나름 도입한 continuous integration 이 기껏 빌드만 해주고 기본적인 unit test 도 수행하지 못한는 경우를 상상해보자. 내가 경험한 어떤 팀은 unit test 를 CI 에 통합해달라는 요청을 한 지 1년이 넘도록 반영하지 못했다. 다른 자동화는 물론 말할 것도 없었다. 과제 규모가 커질 수록 그에 걸맞게 인프라 효율성에도 투자를 해야한다. 발등에 떨어진 일정에만 쫒겨 제때 투자를 못하면 일을 해야할 정작 개발자들의 시간을 어먼 곳에 낭비하게 만든다.

개발 문화와 생산성 향상, 효율성, 팀웍에 대한 인식이 부족하다. 위에서 가장 중요시 하는 것은 언제 릴리스 되는가이다. 어떤 때는 그것 외에는 전혀 관심이 없는 것 같다는 인상을 받곤 한다. 일벌레인 사람들이 지배하는 조직에서 더 심한 경향이 있는 것 같다. 종종 일찍 퇴근하고 싶어하는 사람을 이해하지 못하는 듯한 발언을 듣기도 한다. 아무래도 사람은 자신의 기준에서 남을 이해하는 성향이 있으니, 어찌보면 당연한 것일 수 있다. 하지만 사람(뿐 아니라 모든 생물)은 기계와 달리 충분한 휴식 없이는 높은 집중력과 생산성을 유지할 수 없음을 주지시켜야 한다.

[나쁜 팀 문화] 마법을 보여줘
Nov 5th, 2009 by Wegra Lee

[나쁜 팀 문화] 시리즈를 더 진행하기 앞서 이 주제를 짚고 넘어가야 할 것 같다. ‘너라고 뾰족한 수 있어?’, ‘그게 말처럼 쉽냐?’ 와 같은 공격에 대한 내 나름의 답변이 될 것이다.

팀의 문제점을 지적하고 개선안을 제시했을 때 우리가 기대할 수 있는 가장 흔한 반응들은 이렇다.

  • 그게 아니라 말이지.. (뜨끔하여 방어적 태도를 보임.)
  • 이런 경우엔 그 개선안도 단점이 있잖아? (꼬투리 잡기.)
  • 미안하지만 상황이 어쩔 수 없네. (내 권한 밖 & 나도 피해자.)
  • 좋은 의견이지만 더 급한 이슈들이 많아. 나중에 생각해보자. (과제가 종료되기 전에는 절대 시간이 나지 않음.)
  • 괜찮은 거 같군. 자네가 인프라 세팅부터 이것저것 시도해본 후 가이드를 주게. (난 아무것도 하지 않겠네.) 단, 하던 일에 지장을 주면 안되겠지? (야근을 하건 밤을 새건, 자네 개인 시간을 활용해서 하게나.)
  • 그래도 xxx 보다는 낫잖아(혹은, 남들도 다 그렇게 해). 긍적적으로 생각해. (자기 위안. 현실 안주.)
  • 우리만 바꾼다고 되는게 아니야. 남들도 다 한다고 하면 나도 동참하자. (내가 총대 멜 필요는 없겠지.)
  • 무관심. (신경쓸 겨를 없음. Or 제 또 저러네. 일이나 열심히 해라.)

너무 자주, 그리고 공격적인 어투로 문제를 제기하면 이런 반응도 얻을 수 있다.

  • 자넨 매사에 너무 부정적이야.
  • 팀내 위화감 조성하지 말자. 팀웍을 깨는 짓이야.

위 답변들의 공통점은 무엇일까? 그렇다!! 하나하나 나름의 일리가 있다는 것이다. 이렇게 갖가지 저마다의 견고한 방어책들로 무장한 사람들 모두를 단숨에 사로잡을 수 있는 화려하고 강력한 마법을 부리지 못하는한 팀은 복지부동.. 똑같은 불합리함과 불만들을 그대로 간직한 체 그냥저냥 또 시간이 흘러간다.

종종 제안이 받아들여지는 경우가 있다. 대부분 아래와 같은 케이스들이다.

  • 해결하려는 문제가 국지적이다. (일부 사람만 적응하면 되고, 변경량이 적다.)
  • 기존의 형태를 그대로 유지한 체 효율성만 높인다. (여전히 기존 틀 안에 있다.)
  • 일부 프로세스를 자동화한다. (난 가만히 있고, 할 일은 줄어든다.)
  • 정말 개인 시간 희생해서 인프라부터 친절한 가이드까지 다 해주었다. (난 가만히 있어도 된다.)

종합해보면, 수동적이고 변화를 싫어하는 사람들도 쉽게 받아들일 수 있는 개선들이다. 이나마도 개선되는 것이 다행이긴 한데.. 문제는 이렇게 해결할 수 있는 이슈들은 제한적이며, 개선 속도도 느리고, 무엇보다 근본적이고 혁신적인 변화는 이끌어낼 수 없다. 그리고 근본적인 변화가 수반되지 않은 지협적 개선은 오히려 비효율을 증가시킬 수 있다. 예를 들어, 갱신된 문서 내용이 잘 공유되지 않는 문제를 해결하기 위해 Wiki 를 도입하면서 기존의 문서 관리 체제는 그대로 유지하고 있다면, 팀원들은 이중으로 정보를 업데이트하고 또 싱크를 맞춰줘야 한다. 개선의 효과를 잘 보지 못하고, 그런 경험이 쌓여갈 수록 사람들은 개선에 대한 신뢰를 잃고, 변화를 거부하게 된다.

서론이 길었는데.. 그럼 말하고자 하는 바는 무엇인가? 팀 문화를 개선하고 팀웍을 향상시키고 생산성을 높이는.. 하루 아침에 짠! 하고 모든 걸 바꿔줄 수 있는 마법 같은 것은 없다는 것이다. 긴 기간에 걸쳐 희생을 감내하고 열심히 노력해서 이겨내야 한다.

팀은 항시 더 나은 내일을 만들기 위해 공부하고 주변을 살피고 서로 논의해야 한다.

물론 리더의 역할이 가장 중요하다. 오픈된 마인드를 가지고 팀원들의 의견을 경청하고, 스스로 솔선수범해야 한다. 변화가 요구되면 장기간에 걸쳐 분위기를 조성하고, 필요하면 컨설팅이나 교육을 병행한다. 팀원들이 눈앞의 업무에만 목매에 시야가 갖혀 있지 않은지 살피자. 그리고 서로 간의 지식과 정보를 공유할 수 있는 문화를 만들고 새로운 것을 배우는 즐거움을 잃지 않도록 힘써야 한다. 업무적으로도 협력하여 개발하는 문화를 조성하자. 코드 리뷰, 페어 프로그래밍, 일일 스크럼, 서로의 테스트 케이스 제작.. 방법은 수없이 많다. 또한 잘하고 있는 것과 개선이 필요한 것은 무엇이 있는지 주기적으로 되돌아보자.

이런 일련의 작업들은 팀을 ‘주변의 자극에 능동적으로 반응하는 유기체‘로 만들어준다. 변화의 필요성이 감지되면 전체가 똘똘 뭉쳐서 함께 헤쳐나간다. 누군가 변화의 방향이 잘못되었음을 감지하면 즉시 공유되어 괘도를 바로 잡는다. 모두가 서로의 상황을 잘 파악하고 있으므로, 상대적으로 더 많은 노력과 희생이 요구되는 사람들을 충분히 배려해주고 그 결과를 보상해준다. 팀은 어떠한 환경에서도 적응하고 진화해나갈 수 있는 생명체가 된 것이다.

마법을 보여달라면, 난 이것을 마법이라 얘기하겠다. 너 따로 나 따로.. 울타리만 둘러둔 콩가루 팀에서는 상상조차 할 수 없던 변화와 활기를 몸소 체험할 수 있을 것이다.

»  Substance: WordPress   »  Style: Ahren Ahimsa