어제는 오랫만에 깨어 있는 SE 전공자를 만났다. 여러 화두들 중 일전에 포스팅한 [나쁜 팀 문화] 점진적 지연 [1] 에 관한 이야기가 나왔고, 그분은 재미난 해결책 하나를 말씀해 주셨다.
먼저.. ‘점진적 지연’이란 현상적으로 보면 주요 마일스톤 일정을 막바지에 조금씩’만’ 뒤로 미루며 결국 긴 기간동안 지연되는 것이다. 어쩔 수 없이 나타나는 현상이라면, 그리고 이를 문제로 인식하고 해결하려고 하는 조직이라면 미래가 있다. 하지만 내가 보아온 많은 조직에서는 관리자들이 의도적으로 이런 정책을 편다.
그들은 ‘9월에 끝날 거 같은 과제라면 6월에 끝내라고 해야 그나마 9월에 끝이 난다’라고 말한다. 그들 믿음의 기반은 ‘개발자는 일정으로 쪼지 않으면 일을 열심히 하지 않는 게으른 존재’ 라는 것이다. 그러면서 이게 노하우이고 자신이 팀을 잘 이끌고 있다고 믿는다.
노동 집약적 산업 시대의 잔재인 듯한 이런 시도는 신입사원처럼 아직 조직에 적응하지 못한 사람이나 선천적인 워커홀릭 정도에게나 효과를 보인다. 워커홀릭은 몸이 부서지거나 삶의 전환이 될만한 계기가 찾아오지 않는한 열심히 일하지만, 신입사원들은 기껏해야 한 두 해면 유효기간 만료이다. 결국 9월이 지나고 10월, 11월이 지나도 끝나지 않는다.
왜 그럴까? 관리자들은 종종 ‘내가 6월이라고 말했지만 사실 난 9월로 예상하고 있어’라는 것을 자신만 알고 있다고 ‘착각’하기 때문이다. ‘당신만 아냐? 나도 안다.’ – 개발자들의 마음속이다. 물론 9월이라고 똑같이 예측하는 사람은 일부, 대부분은 자기 나름의 예상치를 잡거나 아예 관심 없어 한다. 즉, 명목상 한 팀임에도 불구하고 멤버들이 목표에 관심이 없거나 제각각의 기준으로 일에 임하는 것이다. 이런 콩가루 팀과 원래부터 9월을 목표로 하여 멤버들 대다수가 ‘어! 잘하면 될 거 같은데, 한 번 해보자!’라고 뭉쳐진 팀, 둘 중 어느 팀이 빠른 시간 안에 높은 품질의 제품을 내놓을 수 있을까?
해결책?
스스로 제시한 목표치에 훨씬 못미치는 관리자 한 두 명만 본보기로 잘라 버리는 것이다. 마음대로 자를 수 없다면 다른 팀에 전배를 보내거나, 다른 일로 전형시켜버리면 된다. 위화감을 느낀 관리자들은 현실적인 목표를 잡기 위해 혈안이 될 것이다.
배우려는 마음과 변화해보겠다는 의지 없어서 그렇지, 현실적인 목표를 잡는 것은 그리 어려운 일도 아니고, 관리자 혼자 머리 싸매고 미래를 예측해야 하는 일도 아니다. 위의 충격요법은 절박함을 심어주어 마음과 의지를 북돋아줄 것이다. ^^
그럴 일은 없겠지만, 현 팀에서도 한 번쯤 이런 일이 일어났으면 좋겠다. 모두에게 공감대가 형성되고 내게 그만한 권한만 주어진다면 크나큰 변화를 이끌 자신이 있는데 말이다. ^^
참고로, 연구 성격의 과제라 누구도 앞을 예측하기 어려운 경우에는 짧은 iteration 을 돌며 그때 그때의 성취를 공유하는 방법이 가장 좋다.
글을 적으면 생각이 나서 리더 vs. 매니저 [2] 도 업데이트 하였다.
몇달 전에 프로젝트 투명성(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 라는 새로운 환경에 적응하기 위해 가장 많은 변화와 노력을 기울여야 하는 실무자들이 관심을 더 보이는 이유는 무엇일까? 역으로, 프로젝트의 목표와 일정을 세우고, 우선 순위를 조정하고, 업무 부하를 관리해야 하는 관리자들은 도데체 무엇 때문에 관심 자체를 보이지 않았던 것일까?
실무자들이 쓰는 이유는 주로 이러했다.
관리자들이 쓰는 이유는 알 수 없다. 쓰는 사람이 없으니 -_-a
그렇다면 관리자들이 외면하는 이유는? 물론 수많은 요인들이 복합적으로 작용했고, 사람들마나 차이도 많다. (Note: 설문조사를 한 것은 아니고.. 대부분은 이런저런 주변 정황과 평소의 대화들을 토대로 유추해본 것 뿐이다.)
투명해지면 안된다고 생각하는 사람들은 상위 지배층과 외부 사람들(stakeholder, customer 등)을 대하는 사람들일 경우가 많다. 이들에게 투명한 과제가 장점을 발휘하려면, 그 과제가 정말 잘 진행되고 있어야 한다는 전제가 깔린다. 이러저러한 문제들이 산적한 상태에서 잘못 공개되면 지원이 줄어들고 대기 수요가 빠져나간다. 이들에게는 안좋은 것을 숨기고 희망찬 메시지만 전달해주어야 한다. 단번에 ‘3달쯤 지연될 겁니다’라고 얘기하면 ‘그렇게까지는 못 기다립니다’라고 하지만, ‘1주일만 더 기다려주세요’를 여러차례 반복하면 ‘이왕 기다린 거, 이번엔 꼭 된다니깐 조금만 더 기다려보지. 등 돌리기도 늦은 것 같고..’ 하는 반응을 이끌어낼 수 있다.
위와 같은 이유로 의도적으로 투명성을 제한하려는 사람들이 있다고 믿는 근거는.. ‘팀 리더로써 가장 중요한 것은 프로젝트를 부러뜨리지 않는 것’ 이라거나, ‘이런 건 누구누구가 알면 안되는데’ 라며 정보 공개를 불편해하는 발언 등을 하는 윗 사람들을 종종 보았기 때문이다. 프로젝트를 계속 유지하는 것은 물론 중요하다. 하지만 외부에 알려진 것 대비 심각하게 안좋은 상황에서도 무리하게 정보를 숨기는 것은 과연 어떨까? 상황을 만회하기 위해 뒤에서 열심히 고생하는 개발자들과 이를 믿고 투자하는 사람, 제품을 기다리는 고객 모두에게 악영향을 미치게 된다. 투자자가 개발팀이 속한 회사 자체라면(내부 프로젝트), 그 팀은 프로젝트를 유지할 수록 회사의 경쟁력을 떨어뜨리게 된다.
다른 관점에서도 불투명한 과제가 (부정적인 의미에서) 도움이 될 때가 있다. 우리 팀의 모습을 앞서의 그림에 맞춰 비유해보면, 윗사람은 day 10 에 ‘자! 내일이 드디어 릴리스 날입니다. 오늘 저녁까지 남은 일들을 모두 완료해 주시고, 검증이 완료될 때까지 자리를 지켜주세요.’ 라고 당당히 요구하고, 또 그것이 개발자들에게 먹힌다. ‘얼마나 걸릴까요?’ 라는 질문은 없다. ‘반드시 끝내세요.’ 라는 요청이 전부이다. 실무자들은 불만이 있어도 드러내놓고 표출하지도 못하고, 밤 늦게나 자정을 넘어서까지 일을 한다. 당연히 기적은 일어나지 않는다. 만약 위와 같은 정보가 다 공개되어 있다면? 윗사람이 앞서와 같은 요구 자체도 할 수 없겠지만, 만약 그런 요구를 한다면 ‘당신은 눈이 없소?’ 라고 반박해도 할 말이 없을 것이다. 즉 과제가 투명해지면 지금까지와 같은 무리한 명령을 내릴 수 없다.
이상의 이유들로, 수단 방법을 가리지 않고 과제를 살리려 한다거나 전통적(?) 지배체제를 유지하고자 한다면, 프로젝트가 투명해지는 것은 커다란 위험요소가 될 수 있다. 이에 해당하는 사람들은 의도적으로 진행상태를 숨길 수 있다.
만약 이런 현상이 정말로 의도적으로 이루어진 것이라면 개선하기란 정말 쉽지 않다. 앞서 언급했듯, 팀을 이렇게 만든 사람들은 대부분 프로젝트 방향을 좌지우지할 수 있는 힘있는 사람들이기 때문이다. 자료를 아무리 제시해도, 개선의 움직임이 보이긴 커녕 거들떠도 보지 않는다면 실무자들도 제풀에 지쳐 변화를 포기한다. 힘있는 자들의 마인드가 바뀌지 않으면 조직의 문화를 바꾸는 것은 거의 불가능하다.
정리: 관리자들 대부분이 이와 같다는 의미는 절대 아니지만, 그 중 일부가 이런 생각을 어느 정도 가지고 있는 것은 분명한 것 같다. 따지고 보면 비단 특정 팀이나 회사, 소프트웨어 개발에만 국한된 현상도 아니다. 정보를 통제하는 언론, 기업의 홍보 부서, 조직의 대변인, 심지어 모든 사람 개개인이 외부로부터 자신을 지키기 위해 어느 정도는 이런 성향을 가지고 있다. 하지만 숨기는 대상에 외부 경쟁자들뿐 아니라 자신들을 믿고 따르는 조직원들까지 포함시켜 그들에게까지 희생을 강요하는 상황에 이른다면 문제는 심각하다. 이런 조직에서 과연 얼마나 많은 사람들이 진심으로 자신의 역량을 모두 쏟아 부어줄까? 하나의 팀이라고 말하기조차 부끄럽다.
그간 이 팀 저 팀에서 발간(?)한 수많은 소위 Lessons Learned 라는 것을 봐온바 있다. 과제를 진행하면서 느끼고 배운 것을 정리하여 다음 과제 진행시 참고하거나 진행중인 다른 과제에서 참고할 만한 좋은 정보들이 적혀 있다. 자신이 걸어온 길을 되돌아보는 것은 좋은 경험이고, 그 결과를 정리해 놓는 것 역시 권장할 만한 일이다.
문제는 그 시점이 항상 과제가 뿌러지는 등 완전히 종료되는 시점에 일어난다는 것이다. 많은 경우 팀 자체가 뿔뿔이 흩어지거나 축소된다. 다음에 진행할 과제도 이전 과제와 성격이 달라지기 쉽다. 얻은 것이 있어도 그것을 적용해볼 상황이 못되는 것이다.
과연 이전 과제에서 깨우친 것들이 새로운 과제 새로운 팀에서 제대로 먹혀들 수 있을까? 시행착오를 거쳐보지 않은 새 팀 멤버들이 가슴 깊이 공감하고 따라줄 것인가? 배경이 다른 사람들에게도 똑같은 처방이 여전히 유효할까? 내가 얻은 결론은 정말 더 나은 개선책인가? 아니면 단지 ‘다음엔 이렇게 해봐야지’ 정도인가? 검증되지 않았고 경험해보지도 못한 방법을 새 팀 새 과제에서 시험해볼 용기는 있는가?
위와 같은 고민들도 어느 정도 영향력이 있는 윗사람들에게 해당하는 것이지, 중간 이하의 힘없는 관리자나 실무자들은 새로운 리더가 시키는데로 그냥 따를 수 밖에 없는 것이 또 현실이다.
결국 이런 식의 Lessons Learned 는 읽을 거리나 유언장 이상의 실질적 가치를 갖지 못한다.
Retrospective 는 Lessons Learned 의 Agile 식 표현 정도로 생각하면 좋을 것이다. 하지만 많은 차이를 안고 있음을 잊어서는 안된다. Agile 이 강조하는 iterative, responsive, incremental 같은 속성을 Lessons Learned 에 부여해보자. 짧은 간격으로 주기적으로 회고하며(iterative), 현 시점에 필요한 이슈에 대한 개선안 만들어 다음 개발 주기에 적용해보아 좋은 것을 취하고 잘못된 것은 버리거나 다른 안을 찾아본다(responsive). 팀은 과제가 진행될 수록 조금씩 조금씩 더 나은 방향으로 발전해 간다(incremental).
이미 끝나버린 과거에 대한 무책임한 회상록이 아닌, 지금 살아서 꿈틀대는 과제에 대한 진중한 고민을 경험해볼 수 있다. 바로 그 시점에 팀원들 스스로가 개선이 필요하다고 느끼는 이슈들이 다뤄지고 합의된 개선책을 시행한다는 점에서 참여율이 높아지고, 높은 성공 확률은 덤으로 얻게된다. 혹 실패한다면 바로 다음 회고 때 그 원인과 또 다른 개선안을 찾게될 것이다. 시행착오를 통해 더 많은 경험을 얻게되고, 미처 고려하지 못했던 요소들이 있음을 깨닫게 된다. 넓고 세심해진 시야는 다른 문제에 직면했을 때도 좀 더 빠르게 더 효과적인 개선안을 찾게 도와준다. 반면 Lessons Learned 방식에서는 실패한 처음 안만이 남겨질 가능성이 농후하다. 회고가 거듭될 수록 팀의 생산성이 향상됨을 느낄 수 있을 것이다.
다 좋고 완벽해 보이는 회고도 무턱대고 적용하려 하면 말처럼 쉽지 않음을 깨닫게 된다. 내가 지금까지 발견한 중요 요인은 3 가지 이다.
첫째, 일정에 쫓겨서 회고에 할애할 시간적 여유가 없다.
이런 답변을 많이 들었는데, 시간적 여유가 없는 것이 아니라 회고의 효과에 대한 믿음이 부족하거나 새로운 것을 시도하는 것을 꺼리는 보수적 마인드의 팀일 가능성이 높다. 이런 경우엔 분위기 조성을 위한 물밑 작업부터 시작해야 한다. 말이 통하고 깨어있는 사람들이라면 직접적인 대화로 돌파할 수 있겠다. 뜻이 맞는 팀원이 소수라도 존재한다면 솔선수범해서 더 나아지는 모습을 직접 보여줄 수도 있을 것이다. 상황이 다양한 만큼 방법도 다양할 터이니 숙고해서 도전해보자. 단, 상대를 공격하는 것은 확실한 실패 방법이니 절대 피하길 바란다.
참고로 회고에 필요한 시간은 보통 2~4주에 1시간 정도면 충분하다. 물론 처음 시작할 때는 좀 더 많은 시간이 필요할 것이지만 두세번만 해보면 익숙해지고 소요 시간도 줄어든다.
둘째, 팀원들의 참여가 저조하다.
기껏 회고를 해보자는 허락을 받았는데, 정작 모인 사람들이 꿀먹은 벙어리 마냥 침묵으로 일관한다. 회고를 처음 시도하는 조직에서는 대부분 겪게 되는 인기 코스일 것이다. 그들이 침묵하는데에는 여러 가지 이유가 있을 것이다. 무슨 얘길 하면 되는거지? 예제 같은 거 없나? 얘기한다고 정말 개선해 주나? 말 꺼내면 나보고 꺼낸 사람이 하라고 하겠지? 불평하면 괜시리 밉보일 거야.. 등등.
이런 우려를 해소하고 적극적인 참여를 유도하려면 맛을 보여줘야 한다. 사소한 것부터라도 정말 개선되는 모습을 보여주는 것이다. 첫 회의에서 아무런 아이디어가 없을 것을 대비해 문제점과 개선안까지 몇 가지를 준비해둔다. 뜻이 맞는 사람이 한 명이라도 있다면 역할극을 해보는 것도 좋다. 혼자 북치고 장구치는 것보다 훨씬 효과적으로 분위기를 이끌어 갈 수 있을 것이다. 그리고 개선안이 없더라도 불편한 사항을 자유롭게 이야기하도록 하고, 그에 대해 반박을 하거나 방어적인 모습을 보여서는 안된다. Brain storming 방식으로 문제들을 나열하고 중요도와 시급성, 파급 효과 등을 생각해 이슈를 선별해서 개선안을 모색해보자.
셋째, 팀에 부여된 권한이 너무 작다.
열심히 분위기 잡고 멋진 개선안들도 마련했다. 그런데 그 개선안들이 우리힘으로 할 수 있는 일들이 아니라면? 운영부서는 돈 들어가는 일은 절대 허락을 안해주고, 보안 부서는 개발자 편의성은 절대악으로 규정짓고, 프로세스 팀은 표준 프로세스에 어긋난 어떠한 시도도 용납하지 않고, 기획/마케팅 부서는 자신들이 바라는 모든 기능을 역시 자신들이 정한 시한까지 완수해야 한다고 못박고, 책상 앞에 앉아 있는 시간과 개발진도는 정비례한다고 철석같이 믿고 있는 임원이 군림하고 있다면?
회고는 불평불만을 토로하고 남들 뒷담화가 남무하는 장이 되던가, 소꼽장난하듯 사소한 문제들만 다뤄지는 비중없는 시간으로 전락할 것이다. 물론 작은 개선들이 차곡히 쌓여 큰 도움을 줄 수도 있을 것이고, 공동의 적을 향한 불평불만과 뒷담화는 팀원들을 단합시켜주는 효과도 있기는 하다. ^^
모든 것을 통틀어 가장 큰 장벽으로, 딱히 뾰족한 해결책도 없다. 때마침 임원 인사가 단행되어 깨어 있는 사람으로 교체되던가, 무슨 바람이 불어서 아주 권위 있는 컨설턴트의 도움을 받을 수 있다면 큰 힘이 될 것이다. 하지만 모두 다 운에 기대는 것이고.. 리더나 팀원들이 몸소 나서서 설득하고 싸우는 적극적 쟁취 방법도 물론 있다. 하지만 생태계에서 식물 급으로 취급되는 힘없는 개발팀이 얻어낼 수 있는 것은 많지 않을 것이다.
[나쁜 팀 문화] 시리즈.. 두 번째..
As Many Tasks As Possible in Parallel (AMTAPP) 는 문장 그대로 가능한 많은 태스크들을 동시에 진행시키는 프로젝트 관리 방식을 말한다. 훌륭한 프로젝트 관리 가이드와는 전면으로 배치되는 정책으로, 특히 Kanban [1][2] 에서는 철저히 경계하고 있다.
이 방식은 현재 내가 속한 팀뿐 아니라 우리 회사의 전형적인 프로젝트 관리 방식이다. 프로젝트가 이렇게 진행될 수 밖에 없는 원인을 몇 년간의 경험을 토대로 유추해 보았다.
그 외에도 나열하면 끝이 없겠으나.. 간략히 두 가지로 요약해보면.. 역량 이상의 일을 따냈고, 그래도 다 하고 있음을 강조해야 해야 한다. 결과적으로, 일할 사람 수보다 당장 해야할 태스크 수가 더 많은 상황에 처한다. 하나의 태스크에 둘 이상이 달라붙는 것은 사치스러운 짓이다.
그럼 AMTAPP 방식의 폐단은 무엇일까?
가장 큰 문제로 개발자 간의 의사소통이 단절을 뽑겠다. 내가 하는 일과 옆의 팀원이 하는 일은 관계가 거의 없다. 풀어야할 문제가 다르고 서로 코드를 봐줄 일도 없다. 어려움에 봉착해도 상의할 사람도 없고, 일부러건 몰라서건 대충 만들어 놓아도 당작 동작만 하면 아무도 알지 못한다. 겉으로 잘 드러나지 않는 품질이야 어떻든, 동작만 하면 관리자는 만족해한다. 또한 노하우가 공유되지 않아, 못하는 사람은 계속 못하고, 잘하는 사람의 발전도 더디다.
다음으로는 집중력 저하를 들겠다. 소프트웨어는 순전히 개발자의 사고에 의해 만들어지는지라, 소프트웨어 개발직은 다른 무엇과 비교해서도 고도의 집중력을 가장 요하는 직업 중 하나이다. 불행히도 신은 사람의 두뇌를 멀티 태스킹용으로 설계하지 않았다. 동시에 두 가지 이상을 생각하는 것은 어림도 없고, 심지어 하나 하나 번갈아 처리하는 능력 역시 상당히 떨어진다. 일을 바꿔 집중력 끌어 올리기까지는 수분에서 십수분 이상이 필요하다 – 정확한 수치를 Peopleware [4] 에서 본 듯 하나, 지금은찾아보기 귀찮다
하이라이트는 다른 사람들의 태스크를 만들어내는 태스크를 할당받은 사람들이다. 이들이 일을 열심히 할 수록 다른 팀원들 수십명의 일거리가 눈더미 처럼 불어나 버린다. 코딩하고 결함 잡기도 벅찬 와중에, 문서 고쳐라, 새로운 툴체인 적용해라, 디렉토리 구조 바꿔라, 여기 새 이디엄이 있으니 적용해라, 방금 나온 따끈따끈한 바이너리 당장 테스트해서 보고해라, 보고용 자료 좀 준비해와라, 이것 보고 커맨트 좀 달라 등등 수많은 요청이 쏟아진다. 프로젝트를 이런 식으로 이끌면서 품질은 개발자의 자존심이니 하는 이야기가 나오면 울컥하지 않을 수 없다.
꾀 오래 전부터 재미삼아 정리해보던 주제인데.. 오늘은 실사례를 하나 들어보려 한다.
최근 팀 내에 돌아다니는 메일을 보면 모든 일정이 deadline 부터 역으로 만들어진다.
위로부터 하달되는 메일들의 전형적인 흐름은 ‘릴리즈 날짜가 언제이고, A/B/C 를 포함시키기로 하였는데, B 를 하려면 최소 n 일은 필요하니 오늘중으로 x, y, z 를 꼭!!! 끝내라’ 이다. ‘할 수 있겠나?’ 라는 질문은 한 마디도 없다. 무조건 하지 않으면 deadline 을 맞출 수 없게되고.. 그건은 절대 용납할 수 없기 때문이다. 지금까지 단 한 번도 deadline 을 제대로 지켜본 적은 없다는 사실은 철저히 무시되고 있다.
물론 이것이 팀의 생산성과 개발자들의 현재 업무 부하량이 잘 반영된 합리적인 요청이라면 아무 문제가 없다. 이런 요청이 한 사람으로부터 일괄되게 하달된다면 역시 양호한 편이라 생각한다. 지금 자판을 두드리는 이유는? 당연히 우리 팀은 이와 거리가 멀음을 의미한다. 멀어도 너무 멀다.
정량적인 생산성 측정은 전혀 시도조차 해본 적 없고, 개발자들의 현 업무량도 전혀 알 수 없다. 요청도 여러 사람에 의해 산발적으로 하달된다. 최우선으로 처리해달라는 요청이 심할 땐 하루에도 몇 번씩 날아오니, 개발자들은 자신의 하루 일과를 스케줄링하는 것 조차 쉽지 않다.
또한 ‘이번 릴리즈는 목표는 토요일 저녁이다’, ’릴리즈가 저녁 x 시쯤 될 예정이니 개발자들은 퇴근하지 말고 대기하라’와 같은 메일도 자주 접하고 있다. ‘늦은 저녁(혹은 주말)까지 일을 시켜서 미안하다’ 라는 사과의 말은 전혀 없다. 야근과 주말 근무를 당연하게 생각하는 것인지, 모두 똑같이 일하고 있으니 미안할 게 없다는 뜻인지, 프로젝트 성공을 위해선 개인 생활을 희생하는 것이 프로답다고 생각하는 것인지.. 이심전심으로 다 통할 거라고 생각하는지.. 도통 알 수가 없다.
그간 여러 차례에 걸쳐 검증된 프로세스와 툴 등을 소개하고 마인드 변화를 촉구해보기도 하였으나 이러저런 이유들도 팀의 이런 개발 문화는 꿈쩍도 안하고 있다. 새로운 것을 시도하기엔 deadline 이 너무 촉박해서일지.. 단순히 게을러서인지.. 배우는 재미를 잊어버렸을 만큼 심신이 지쳐버린 것인지.. 개개인의 속내야 알 수 없지만, 이들이 모여 실패를 거듭하면서도 뒤는 커녕 옆도 돌아보지 않고 코앞의 목표만 향해 달리는 보수적인 집단을 만들어 냈다.
Deadline-Driven Development (DDD) 의 전형적인 모습을 내가 속한 팀에서 보고 있으니 답답한 마음이 이루 말할 수 없다.
아름프로님의 블로그 (Click Here) 를 통해 알게되었는데.. 원본 링크는 여기 (Click Here).
Kanban (Click Here) 에 대한 설명이지만, 평소 agile/scrum 등에 관심이 있었던 사람이면 누구나 쉽게 이해할 수 있을 것이다. Kanban 에 의해 추가된 것은 아래 taskboard 의 각 칼럼에 있는 숫자들인데.. 이는 각 칼럼에 동시에 올 수 있는 최대 task 수를 의미한다. 예를 들어, Selected 에는 최대 2개까지 옮겨 놓을 수 있고, 동시 개발이 허용되는 최대 task 수도 역시 2, Deploy 검수는 1개씩만 허용된다. 이 숫자는 경험에 기반해 최적화가 가능하며, 마지막 그림에 보면 Develop 최대 개수를 3으로 늘렸음을 알 수 있다.
볼만한 아티클이 있어서 소개한다. 사이트 가입이 필요하지만 좋은 글들을 소개해주는 메일이 종종 날아오는 것 정도라 관심있는 사람이라면 오히려 도움이 될 거다.
Principles of Agile Architecture (Click Here)
주제는 제목이 잘 설명해주고 있다. 애자일 방법론이 엔터프라이즈 시장까지 급속히 번져감에 따라 대규모 프로젝트에 적합한 애자일 아키텍쳐링에 대한 노하우를 공유하는 글이다. 내용을 자세히 다루고 싶지만, 해당 사이트의 라이선스 정책을 정확히 몰라 간략히 소개만 하겠다. (읽어보았는데 번역에 대한 명시적 언급은 없고, 승인을 위한 컨텍 주소가 있지만 귀찮다 ㅎ)
이 글에서 제시하는 원칙은 아래의 7가지이다. 자세한 설명은 직접 글을 읽어보자. ^^ (주변인 중 사이트 가입이 내키지 않는 사람에게는 프린트해서 드리죠. ㅎ)
맛을 보여 드리기 위해 일부만 발췌해 보았다.
1. The teams that code the system design the system.
Scrum 에서 이야기하는 Self Organization(자기 조직화) 와 연관해서 생각해봐도 좋을 것이다. 왜 애자일 팀이 기존 팀 대비 훨씬 능동적이고 활기 넘치고, 또 발전할 수 밖에 없는가에 대한 이유를 잘 정리해놓은 표이다.
6. System architecture is a role collaboration.
1번 원칙에서 이야기한 것 처럼 설계에 대한 기본적인 권한과 책임은 이를 구현하는 팀에게 있지만, 엔터프라이즈 레벨의 대규모 프로젝트에서 각각의 팀에게 모든 것을 맡겨 놓는 것도 그리 이상적이진 않다. 그래서 능력있는 전문 아키텍트나 멀리서 조망하며 큰 그림을 그려나가는 팀도 필요해진다. 그렇지만 여전히 어느 한 팀이나 특정인에게 모든 권한이 위임되지는 않는다. 아래 그림에서 묘사한 것처럼 조직의 여러 팀과 전문가들의 협력에 의해 전체 시스템 아키텍쳐가 발전해나가야 한다.
7. There is no monopoly on innovation.
혁신은 한 번에 일어나지 않는다는 정도로 이해하면 되는데.. 아래는 Rally Software Development 에서 수행해온 방식이라는데 마지막의 hackathon 이 아주 흥미롭다.
Hackathon 의 개념과 기원은 Wikipedia 에 잘 설명되어 있으니 참조하길 바라고 (Click Here), 위의 그림과 연관하여 간략히 설명하면 이렇다. 마지막 한 주 간은, 회사의 미션과 연관된 것이라면, 개발팀 누구나 자신이 관심있는 어떤 주제에 대해서도 자유롭게 탐구할 권한이 주어진다. 이런 기회를 통해 새로운 것을 배우고 사고의 폭을 넓혀가면서 차곡차곡 혁신을 이끌어낼 기반을 다지는 것이다. 구글의 20% 원칙도 같은 맥락에서 바라볼 수 있겠다.
나는 대기업에서도 상당히 큰 규모의 과제에 몸담고 있다. 연관된 내/외부 팀원만 하더라도 족히 5백은 넘을 듯 하고, 그 중 직간접적으로 내 영향력이 미치는 범위는 백여명 정도 될 듯 싶다. 이런 규모의 과제를 진행하다보니 프로젝트 투명성의 중요성이 더욱 크게 느껴진다.
여기서의 프로젝트 투명성이란 프로젝트 계획, 세부 태스크, 진척도, 히스토리, 위험 요소, 가용 자원 현황 등 프로젝트 진행과 관련된 중요 정보들에 관련자들이 실시간으로 얼마나 쉽고 정확하게 접근할 수 있는가를 말한다.
우리팀의 수직적 계층을 대략적으로 구분해보면 ‘개발자, 중간 관리자, 상위 관리자, 경영진’ 정도로 나뉘는 듯 하다. 수평적으로는 협력 팀과 경쟁 팀이 있고, 경쟁 팀들의 수직적 구조는 우리 팀과 대동소이하다. 이러한 거대 조직에서 프로젝트 투명성을 제대로 지원해주는 어떠한 인프라도 갖춰져 있지 않다면 어떤 현상이 벌어질까? 우리의 예를 일반화시켜 적어보겠다.
실시간 정보 공유가 어려우므로, 개발자는 중간 관리자에게 한 주 정도 간격으로 진행 상황을 보고한다. 하지만 이 때 기입되는 태스크들의 의미를 전체 프로젝트의 관점과 연관시켜주는 인프라가 없다. 무언가 많은 일들이 진행되고 있는 것은 같으나 그것의 의미는 잡아내기 쉽지 않다. 중요하지 않거나 계획에도 없던 일에 과도한 시간을 투자하거나, 반대로 아주 시급한 일과 직결된 이슈 사항이 주목 받지 못하고 묻혀버리는 일이 허다하다. 진도가 계획 대비 얼마나 충실히 나아가고 있는지, 그래서 예정된 마일스톤에 납기가 가능할 지와 같은 정작 중요한 정보는 거의 포함되지 못한다.
중간 관리자와 상위 관리자도 보통 주 단위의 미팅을 갖는다. 개발자들로부터 받은 보고를 정리해서 공유하고 전체 일정 대비 점검하거나 큰 이슈들에 대한 논의가 주로 이루어진다. 개발자의 보고 내용이 필터링 되는 것은 오히려 작은 문제이고.. 더 큰 우려 사항은 앞서 이야기한 ‘중요한 정보를 얼마나 잘 캐취해 냈는가’이다. 중간 관리자가 이 일을 제대로 처리하지 못한다면, 중요치 않은 일이 부각되고 그 후속 조치로써 더 중요한 일에 투입할 시간마져 갉아먹게 된다.
이 단계에서의 또 하나의 심각한 문제는, 가용 리소스와 각 태스크별 요구되는 리소스량에 대한 신뢰할 만한 데이터 없이 매니저들의 감과 욕심(혹은 바람)에 의존해 일이 계획된다는 점이다. 실무자가 보기엔 현재 할당된 일만으로도 일정 지연이 뻔한 상황에서도 새로운 태스크들이 추가된다. 요구 일정에 맞추려면 실무자는 결국 대충 진행할 수 밖에 없다. 그 때 그 때 지뢰를 하나씩 매설해놓고, 제품은 점차 건드리기조처 겁이 나는 지뢰밭이 되어 간다. 심지어 기존 기능을 변경할 시에도 감히 현 코드를 수정하지 못하고 편접적인 방법으로 살짝 덧씌운다.
상위 관리자는 협력 팀이나 경영진들과 미팅을 갖고, 그 주기나 형태는 어떤 주제로 누구와 맞나느냐에 따라 달라진다. 이전까지의 논의가 주로 기술과 일정에 대한 것이었다면, 이제부터는 기술은 쏙 빠지고 비즈니스 임팩트와 내/외부 경쟁에 대한 것들에 초점이 맞춰진다. 빠르게 변하는 시장 상황에 따라 과제 방향이 확 틀어질 수도 있고, 경쟁에서 너무 밀릴 것 같으면 생존 자체가 위협을 받는다. 이런 상황이 상급 관리자들을 방어적으로 만든다. 거짓말이 되지 않도록 신경쓰면서 문제를 최대한 숨기고, 작은 장점을 크게 부풀리고, 묘한 가정을 설정하거나 자신들에게 유리한 데이터를 추려 인용한다. 예를 들면, 여러가지 임시 방편과 제한된 시나리오로 간신히 데모 정도 돌리는 수준에서 마치 다 마무리 되어가는 듯 보고가 되고, 그 결과 추가적인 일거리가 생기고 과제 규모도 커져버리는 식이다. 추가된 업무에 허락된 리소스는 당연히 지금까지 잘 된(것처럼 보고된) 생산성에 맞춰져 있다. 일을 받는 입장에서 현실적인 리소스를 요구할 수 없는 것이, 앞으로는 자신의 팀원들의 생산성이 훨씬 떨어질 것이라는 납득하기 어려운 주장을 펴거나 현재의 상황을 인실직고해야하기 때문이다. 더욱이 현 문제에 대해 상급 관리자가 파악하고 있는 수준 역시 현실과는 꾀 거리가 있게 마련이다.
결과적으로 부정확한 데이터에 기반해 엄청난 예산을 낭비하고 기회를 놓치게 된다. 그리고 이런 체제에서는 개발자들의 실력도 늘지 않아 경쟁에서 점차 뒤쳐질 수 밖에 없다. 좋은 개발자들은 기회가 되면 조직에서 벗어나려 할 것이다. 그 외의 악순환 얘기까지는 굳이 꺼내지 않아도 될 것 같다.
투명한 프로젝트의 장점 중 가장 중요한 것은 다음 두 가지라고 생각된다.
첫 째, 여러 단계에 걸친 보고 과정에서 낭비되는 고급 인력의 시간을 실무적인 문제 해결로 돌릴 수 있다. 어떤 정보를 공개할 지, 어느 정도로 포장을 해야할 지, 유리한 데이터는 무엇이 있을 지, 경쟁자보다 우월해 보이려면 다소 무리해서라도 어떤 기능을 더 넣어야 할 지 등을 찾고 고심하는대는 생각보다 많은 시간과 노력이 필요하다. 한 구글 직원의 블로그에서는 자신들의 리더는 약 20% 의 리소스만을 관리에 쓰고 나머지는 같이 개발을 한다고 하였다. 반면 비효율적인 기업은 상위 20%의 인력은 관리만 하고 있는 것이 아닌가 싶을 정도이다. 고급 인력 한 사람의 적극적인 참여는 저급 인력 몇 명을 투입하는 것보다 훨씬 나은 효과를 낳는 경우가 많다. 이런 효과는 팀 규모가 커지고 과제가 장기화될 수록 더욱 뚜렷해진다. 과제가 진행되면서 노하우가 전파되고 개발인력들의 역량이 향상된다. 이 문제는 굉장히 심각한 것이.. 실무에서 몇 년을 일한 프로 개발자들 중 아직껏 대학생 수준의 코드를 작성하고 있는 경우가 너무 많이 목격되기 때문이다. 투명성 부여 하나만으로 해결될 일은 아니지만 문제를 부각시키는데 분명 큰 효과를 발휘한다.
둘 째, 조직이 스스로의 역량을 정확히 파악함으로써, 현실성 있는 비전과 전략을 수립하여 그에 집중할 수 있게 해준다. 어느 시점에 어떤 역량을 더 키워야 하는지도 판단할 수 있고, 이는 조직이 경쟁에서 살아남기 위해 꼭 필요한 정보 중 하나이다.
하지만 위와 같은 경직된 조직에서 과제에 투명성을 부여하기란 결코 쉽지 않다. 깨어 있는 사람에 의해 위에서부터 도입되는 시나리오가 가장 현실적이나, 정보가 차단된 문화에서 그럴 필요성을 느낄 수나 있는가가 첫 난관이다. 반대로 아래로부터의 개선은 변화를 시도하는 팀에게 상당한 모험이 될 것이다. 모든 정보를 투명하게 공개한 과제는 여러 겹 포장된 과제에 비해 생산성이 떨어지고 각종 문제들로 정신이 없는 것처럼 비춰지기 쉽다. 이런 현상의 진실을 경영진들에게 잘 납득시켜 결과가 나올 때까지 과제를 유지해 나가는 것이 가장 큰 난관이 될 것이다.
개발자들에게 오픈 마인드를 심어주는 것 역시 큰 장애가 될 수 있다. 자신들이 하는 일이 실시간으로 공개가 된다는 것은 자칫 일거수 일투족이 감시받는다는 오해를 불러 일으키기 쉽다. 실제 비공식적으로 도입해본 결과도 아랫사람들이 훨씬 적극적이며, 주로 위로부터의 말도 안되는 압박에 대한 방어효과 때문으로 보인다. 그리고 윗사람들이 하는 일도 다 같이 공개된다는 점을 잊지 말자.
마지막으로 그리고 절대 간과해서는 안되는 것이 있다. 정보 공개를 위해 귀찮은 추가 작업을 수행해야 한다면 업무 집중도가 떨어지고 정보 누락이 발생한다. 부정확한 정보를 얻기 위해 생상성을 떨어뜨리는 것은 바보짓이다. 따라서 충분한 논의와 교육으로 가능한 많은 이들과 공감대를 형성하고, 좋은 자동화 인프라를 갖춘 후에 시행에 옮겨야 한다. 의욕만 앞서 무리하게 추진하면 부정적 인식만 남겨 도입 시기를 더 늦춰버리는 역효과가 나기 쉽다. 지금까지 자칭 SE 라는 조직에서 수없이 반복해온 실수들이 아닌가!
하루라도 빨리 제대로된 개발을 해볼 수 있는 날이 오기를 바라며, 답답한 마음에 두서 없이 적어본 프로젝트 투명성에 대한 이야기를 마친다.
참고로, 인프라 관점에서는 본격적으로 제품이 나오기 시작한지는 아직 몇 년 되지 않아 제대로된 솔루션 중에는 선택의 폭이 넓지 않다. 현 시점에서는 IBM Rational 의 Jazz/RTC 와 MS 의 Visual Studio Team System 2010 정도가 눈에 들어온다. 통합 환경에 비해 사용법을 익히고 관리하는데 더욱 많은 노력이 드는 것은 어쩔 수 없지만, 별개의 여러 툴들을 조합해 사용할 수도 있다. 조직의 규모가 커질수록 투자할 만한 가치가 있을 것이다. 나라면 개발 인력 5명에 3개월 과제만 되어도 이런 류의 인프라를 도입할 것이다.
