»
S
I
D
E
B
A
R
«
Regarding Incremental Delay Policy (Bad Team Culture)
Jan 16th, 2010 by Wegra Lee

어제는 오랫만에 깨어 있는 SE 전공자를 만났다. 여러 화두들 중 일전에 포스팅한 Bad Team Culture – Incremental Delay [1] 에 관한 이야기가 나왔고, 그분은 재미난 해결책 하나를 말씀해 주셨다.

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

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

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

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

해결책?

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

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

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

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

글을 적으면 생각이 나서 Leader vs. Manager [2] 도 업데이트 하였다.


References

  1. Bad Team Culture – Incremental Delay (wegra.org)
  2. Leader vs. Manager (wegra.org)
Bad Team Culture – As Many Tasks As Possible in Parallel (Part II)
Jan 15th, 2010 by Wegra Lee

2009년 10월에 같은 제목으로 포스팅 한 글[1]의 연장선에서 몇 마디 더 적어보고자 한다.

제목만으로도 충분히 짐작할 수 있듯, 우리 팀의 일하는 방식은 가능한 많은 일들을 가능한 한꺼번에 진행하는 것이다. 그런데 최근 상황을 보면 문제가 더욱 심각해지고 있는 것 같다.

어딘가에서 요청이 들어오면, 차후 뒷감당에 대해 충분히 고려하지 않고 일을 진행시키는 경향이 엿보인다. 얼핏 생각해도, 그리고 경험상으로도 그 일 하나의 파급는 너무 막대하여, 추후 기능 개선이나 유지보수에 심각한 영향을 미친다. 하나만 예로 들면, 지금껏 별로 신경쓰지 않았던 내부 모듈들을 우리 통제권 밖의 팀에서 사용하라고 공개하는 것이다. 앞으로는 내부 모듈에 대해서도 하위 호환성을 고려해야 한다. 이런 우려들을 이야기해도 마땅한 안은 제시지 못한다. 요즘은 과제 진행에 집요하게 관여하지 않아서이기도 하겠지만, 상대방이 원한다는 정도의 답변 정도만 받았던 것 같다.

지금껏 관련 기능을 전혀 사용해보지 않은 사람에게 단독으로 그 기능을 제공하는 모듈을 개발하게 시키기도 한다. 더 정통한 사람이 있어도 다른 일로 바쁘므로(여유가 있는 사람은 찾을 수 없다. 팀원 중 누군가가 여유가 생기면 메니저가 관리를 제대로 못하는 것이란 강박관념이 있는 것 같다. [2] – ‘쉬어가기.. 혁신을 이끌어내는 방법’ 참조) 함께 하지 못한다. 물론 둘이 하나의 태스크를 공유하는 것은 ‘가능한 많이 한꺼번에’ 정책에 위배된다. 궁금하면 물어보면 된다는 입장인데, 알아야 제대로 된 질문을 할 수 있다. 질문을 받은 측도 질문자가 어느 방향으로 가다가 어떤 관점에서 이런 질문을 하는지 그 문맥을 알지 못하면 제대로된 답변을 줄 수 없다. 우문현답을 기대하지 말자. 질문하는 측도 이 모든 걸 상대가 한 번에 이해할 수 있게 설명할 수 없다. 충분한 이해를 위해 이런저런 사족을 다 얘기하다보면 상대는 오히려 짜증을 낼 수도 있다. 자신도 다른 일로 정신 없는 입장이기 때문이고, 질문한 사람의 일이 잘 안되는 건 자신과 큰 상관이 없기 때문이기도 하다.

혼자 하느라 갑갑하고 진도도 더딘데, 주어진 시간은 항상 촉박하다. 결국 유사한 기능의 타 제품을 몇개 참고해서 비슷하게 흉내내는 수준의 작품이 나올 수 밖에 없다. 제품 전체 중 일부는 어쩔 수 없이 그럴 수 있다 치지만, 내가 보기엔 그 정도가 심하다.

우선.. 아무리 흉내를 낸다 해도, 이해할 수 있는 만큼만 구현할 수 있다. 문외한이었던 사람이 혼자 짧은 시간동안 이해할 수 있는 범위는 가장 기초적이고 정석적인 부분뿐일 것이다. 고급 기능이나 색다른 (경험이 많은 사람이라면 ‘아! 이런 방법도 있었군!’ 이라 생각할만한, 때로는 혁신적인) 형태는 쉽게 이해할 수 없다.

뿐만 아니라, 우리 제품에 가장 적합한 방식이 무엇인지도 판단하기 힘들다. 특정 기능에 대해 이견이 있을 때 우리 팀에서 가장 힘있는 근거는 ‘제네도 이렇게 해요’ 이다. 정통한 노하우나 깊은 고민 없이 이곳 저곳 유사 플랫폼, 유사 기능의 제품을을 흉내내고 있음을 잘 보여주는 대목이다. 이것마저 각 모듈마다 별다른 커뮤니케이션 없이 독자적으로 진행하니, 제품 전체를 꽤뚫는 우리만의 색깔과 혼을 찾을 수 없다. 타 제품에서의 멋진 디자인도 우리 제품에 가져오면 효과가 반감된다. 특정 모듈에서만 효과가 있을 뿐, 다른 모듈에서는 그 특성을 십분 활용하도록 고민되지 않았기 때문이다. 전혀 필요 없는 기능을 멋모르고 집어 넣는 경우도 종종 있다. 플랑켄슈타인 같다고 해야할까. 동작은 하지만 조화롭지 못하고 보기 흉한 제품. 영화에서처럼 힘이라도 세지면 좋겠으나, 현실에선 과연 어찌될지……

p.s. 요즘은 포스팅 의욕이 많이 저하되었다. 대충 쓰고 올린다. ;;;


References

  1. Bad Team Culture – As Many Tasks As Possible in Parallel (wegra.org)
  2. 쉬어가기.. 혁신을 이끌어내는 방법 (wegra.org)
iTunes U: iPhone Application Development by Stanford
Jan 14th, 2010 by Wegra Lee

작년에 iPhone Application Programming 이라는 제목의 강의를 iTunes U 를 통해 공개해 화제가 되었던 미 Stanford 대학에서 새로운 업그레이드 버전의 강의[1]를 다시 시작했다. 물론 이번에도 iTunes U 를 통해 강의 동영상[2]을 볼 수 있다.

iPhone Application Development. 시작 부분은 작년 강의와 비슷하지만, 후반부로 가면서 최신 iPhone OS 3.1 을 포함하여 작년에 다루지 않았던 내용들을 제법 커버하고 있다. 또한 타 언어 청강자들을 위한 배려로 자막을 포함시켰다. 대략적인 강의 계획[3]은 아래 정도..

This is our preliminary syllabus. Details may change as we go along.

1/5 – Intro to Mac OS X, Cocoa Touch, Objective-C and Tools
1/7 – Using Objective-C, Foundation objects

1/12 – Custom classes, memory management, properties
1/14 – MVC, Interface Builder, Controls & target-action

1/19 – Views, Animation, Open GL
1/21 – View Controllers

1/26 – Navigation Controllers, Tab Bar Controllers, Searching
1/28 – Table Views

2/2 – Dealing with Data: User defaults/Settings, CoreData, JSON & XML, Push
2/4 – Threading, Notifications, KVC

2/9 – Text, Responders, Modal Views
2/11 – Address Book

2/16 – WebViews, MapKit
2/18 – Multitouch, Gestures

2/23 – Device APIs: Location, Accelerometer, Compass, Battery life
2/25 – Audio playback, Video playback, Image/Video Picker, iPod Media Access

3/2 – Bonjour, streams, networking, GameKit
3/4 – Unit testing, Objective-C fun, localization

3/9 – TBD
3/11 – TBD

빠르면 이달 말, 늦어도 강의가 끝날 즈음엔 iPhone OS 4.0 API SDK 가 공개될 것이다. 이 강의를 통해 3.x 까지 기본 개념들을 익혀둔 후 4.0으로 넘어가는 것도 괜찮을 듯 싶다.

작년 강의 때는 진도에 맞춰 숙제도 해보면서 많은 것을 배웠다. 회사에서 비슷한 과제를 진행하는데.. 우리의 것보다 너무도 우월하여 다른 팀원들도 시간내서 꼭 봐주길 촉구했으나 관심도 보이지 않던 씁씁한 기억이.. -_-

p.s.  Stanford 강의만큼 녹화/편집이 깔끔하진 못하지만, 독일의 RWTH Aachen 대학에서도 iPhone Application Programming 강의를 진행중이다[4].


References

  1. iPhone Application Development – Web (Stanford Univ.)
  2. iPhone Application Development – iTunes U (Stanford Univ.)
  3. iPhone Application Development – Syllabus (Stanford Univ.)
  4. Yet Another iPhone Application Programming Lecture (wegra.org)
쉬어가기.. 혁신을 이끌어내는 방법
Jan 11th, 2010 by Wegra Lee

우리는 창의력과 혁신을 강조하는 시대에 살고 있다. 소프트웨어 개발도 당연히 그 중심에 서 있다. 하지만 우리의 소프트웨어 개발 문화는 창의력을 심히 제한하는 방식으로 굳어져 있다.

일반적으로 우수한 편에 속하는 지적 능력을 가지고 있고, 새로운 것을 만들어내는 것을 즐기는 소프트웨어 개발자들. 그들은 회사에서 어떤 대우를 받고 있나. 조직이 조금만 커져도 기획은 별도의 부서에서 진행하고, 소프트웨어 개발은 몇몇 관리자들이 이끌게 된다. 소프트웨어 개발자들은 창의력을 발휘하기 보다는 시키는 일만 열심히 해야 하는 위치에 놓이게 된다. 코드를 찍어내고 타의에의해 변경된 요구사항들 때문에 수정/테스트를 반복하는 나날을 보내며 발언권은 점점 작아진다.

기술 개발을 중시하는 몇몇 소수 기업을 제외하고는 대부분(대기업)의 윗사람들은 아직까지 소프트웨어 개발자들을 단순 노동자 취급하고 있다. 이를 빗대어 나는 ‘소프트웨어 제조업’ 에 종사하고 있다고 얘기하곤 한다.

반면, 개발자들의 능력을 믿고 그들에게 스스로 혁신을 일으킬 수 있도록 지원해주는 대표적인 기업들로 Google, Apple, Rally Software 등을 들 수 있다.

Google 은 20% 제도로 유명하다[1]. 자신에게 주어진 시간 중 20% 정도를 주업무가 아닌 다른 일에 할애하도록 권장하는 제도로, 다양한 형태로 응용 가능하다. 매일매일 20%의 시간을 다른 일에 투자하는 것은 대부분의 경우는 현실적이지 않다. 프로젝트 마감이 코앞인데 다른 일에 정신 팔기도 힘들고, 하루 1~2시간씩 해서는 진도도 나가지 않기 때문이다. 대신 그들은 1주일에 하루, 1달에 1주, 혹은 6개월에 1달, workaholic 이라면 주말을 이용 등등.. 자유롭게 변형해서 일한다. 과제가 바쁠때는 열심히 그 일에 매달렸다가 한가할 타임에 그동안 못 쓴 20%를 쓰는 식이다.

20%의 시간에는 어떤 일을 할까? 이것도 아주 자유롭다. 전혀 새로운 과제를 수행할 수도 있고, 관심있는 다른 팀 과제를 지원할 수도 있고, 자신의 주 과제를 진행하면서 불편했던 부분을 자동화하거나 유용한 유틸리티를 만들거나, 최적화/리펙토링을 할 수도 있고, gmail/chrome browser 등에 유용한 플러그인을 만들어넣을 수도 있다. 공부를 할 수도 있다.

이렇게 해서 나온 결과들은 팀의 개발 생산성을 향상시키고, 제품의 품질을 좋게하고, 새로운 것을 배우게 만들고, 운이 좋으면 구글의 미래를 이끌어갈 제품으로 거듭날 수도 있다. Gmail, Google News, Google Talk, Orkut, Google Sky [2], Go programming language [3] 등은 모두 20% 시간에 시작된 프로젝트들이다.

Apple 의 경우 1년에 1달 가량 자신이 원하는 일을 할 수 있게 해준다지만.. 자세한 내용은 잘 알려지지 않았다[4].

마지막으로 Rally 의 경우 8주의 개발 사이클 중 마지막 1주는 회사의 미션과 관련된 일이라면 어떤 것이든 할 수 있는 권한이 주어진다[5]. 기간이 일정하게 주어져 있기 때문에 융통성이 조금 부족하지 않을까 우려되긴 하지만 한 숨을 돌리며 자신들의 과거를 뒤돌아볼 수 있다는 점만으로도 확실한 장점이 될 것이다.

다시 암울한 우리의 이야기로 돌아와보자.

나는 현 회사의 윗사람으로부터 ‘관지자가 할 일은 개발자가 놀지 않게 하는 것’ 이란 얘기를 들었다. 여기서 논다는 것은 ‘주업무와 직접적으로 관련 없는 모든 일’을 지칭한다. 내게는 ‘공장 가동을 멈추지 말 것’ 정도로 들렸다. 공식적인 주업무 외에는 회사에 기여하지 못하는 것으로 여겨기기 때문에 일거리를 만들어서라도 주지 않으면 능력 없는 관리자가 되는 것이다.

개발자 입장에서도 마찬가지다. 좋은 아이디어가 있더라도 side job 은 업적으로 인정받기 어렵다. 놀고 있는 것으로 받아들여지므로 드러내놓고 할 수도 없다. 결국 몰래 하거나 개인 시간을 희생해서 짬짬이 하게 되고, 인정받지 못하기 때문에 의욕이 생길리 만무하다.

고급 인력인 개발자들의 좋은 두뇌를 활용하지 못하고, 반대로 창의성을 저하시키는 이런 문화는 하루 빨리 고쳐져야 한다. 말로만 소프트웨어가 중요하다고 하지 말고, 소프트웨어 개발의 특성과 개발자들을 이해하려는 노력이 절실하다.

두서 없지만 이 글은 이쯤에서 마무리하기로 하고, 유사 주제로 작성하고 있는 글이 있으니 그 쪽에서 정리를 시도해보기로 하겠다. ^^


References

  1. Pros and Cons of Google’s 20 percent time concept? (Ask MetaFilter)
  2. Top 20 Percent Projects at Google (eWeek.com)
  3. The Go Programming Language (Google, golang.org)
  4. 애플 “한국을 모바일 테스트베드로 활용” (아시아 경제)
  5. Principles of Agile Architecture (wegra.org)
Bad Team Culture – Anti-transparency
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. Project transparency (프로젝트 투명성) (wegra.org)
  2. Rational Team Concert (IBM Rational)
  3. Bad Team Culture – Incremental Delay (wegra.org)
  4. Burndown chart (wikipedia)
»  Substance: WordPress   »  Style: Ahren Ahimsa