"프로젝트가 서쪽으로 간 까닭은?"이라는 책에, "프로젝트 매춘부"라는 챕터가 나온다. 아래와 같은 문단들이 나오는데..

21세기는 어찌 된 영문인지 "모든 일이 어제 끝났어야 한다."는 급박한 분위기가 만연하다. 속력이 그렇게 중요하다면 부하를 줄여 속력을 높이는 방법이 가장 간단한 해결책이다. 하지만 이처럼 뻔하고 상식적인 해결책은 암묵적이고 정치적인 현실에 부딪힌다. 기능을 쳐내면 누군가, 자칫하면 권력 있는 누군가에게 찍힐지도 모른다는 현실이다.

..(생략)..

사실상 새로운 기능을 요청할 만한 사람은 모두가 당신보다 높은 직책이다. 비판을 피하려고 당신은 요청이 들어올 때마다 어쩔 수 없이 "예."라고 답한다. 당신이 "예."라고 답할 때마다 프로젝트 속력은 느려진다.

..(생략)..

팀이 감당할 수준을 넘어서 온갖 요청을 수락하는 관리자는 비겁하다. 개인적인 비판을 피하려고 팀이 성공하지 못하는 상황을 만든다. 궁극적으로 팀은 과도한 업무로 고통 받고 사기가 떨어진다. 단지 관리자가 처음부터 "아니오."라고 말할 용기가 없었다는 이유로.

..(생략)..

이처럼 불행한 패턴을 방지하려면 어떻게 해야 할까? 업무에 우선 순위를 매긴 후 최고 속력으로 처리가 가능한 만큼만 진행한다. 가치가 낮은 업무는 가치가 높은 업무를 다 끝낸 후로 연기한다.

실천하기 어려울지도 모르겠다. 가치를 빨리 내놓는 대신 권력을 포기해야 하므로. 힘 있는 사람에게 "아니오."라고 말하면 팀 효율은 높아질 지 몰라도 자신의 정치력은 떨어진다. 별로 달가운 공식이 아니다. 잠재적인 정치력을 어느 정도 희생해야 필수적인 업무가 더 빨리 끝난다.

정치만이 팀에 부하가 걸리는 이유는 아니다. 유사하게, 팀원 개개인도 과중한 업무를 떠맡는다. "아니오."라고 말하지 못해서다. "적을수록 낫다."는 이야기는 들었지만 속으로는 "많을수록 낫다."고 믿는 탓이다.

- "프로젝트가 서쪽으로 간 까닭은?"의 "프로젝트 매춘부" 챕터 중에서..

빨간색으로 강조한 부분이 이 챕터의 핵심인 것 같다. 사람들은 본능적으로, 다른 사람들보다 뒤쳐지지 않게 보이고 싶어하고, 회사 또는 팀 내에서, 정치적으로 밀리지 않으려 한다. 그런 요소가 스스로에게 과중한 업무를 부여하게 된다. 회사의 결정권자들은 이러한 문화를 당연시 생각하고, 관리자나 팀원이 많은 일을 하겠다고 하면, 열심히 일한다면서 좋아한다. 하지만, 프로젝트는 안드로메다로 간다. 모두가 알고 있지만, 대부분의 사람들은 "아니오"라고 말하지 못한다. 프로젝트가 연기되거나 망하더라도, 자신의 정치력은 어느 정도 지킬 수 있을테니깐. 프로젝트가 망하더라도, 자신은 열심히 일했다는 모습을 보여줄 수 있을테니깐. 프로젝트가 망하더라도, 자신의 밥그릇은 지킬 수 있을테니깐. 이것은, 프로젝트와 밥그릇 사이에 직접적인 연관관계가 없을 때에 더 심해진다.

-- 이상한 나라의 종텐.

(플래닝 포커 카드 때문에 구입했던) 스크럼과 XP를 읽고 있다. (김창준님의 추천사 참고). 내적 품질과 외적 품질에 대한 이야기가 나오는데, 지난주까지 했던 아르바이트가 떠올랐다. VBA와 관련된 일이었는데, 그 코드의 내적 품질은 안드로메다였다. 하지만, 고객은 내적 품질이 중요하다는 것을 잘 이해하지 못한다. 이 책에는 내적 품질에 대한 이야기가 나온다.

< 왜 품질은 협상의 대상이 아닌가? >

앞의 삼각형에서 나는 의도적으로 네 번째 변수라 할 수 있는 품질을 포함시키지 않았다.

외적 품질은 시스템을 사용하는 사람들이 인식하는 품질이다. 느리고 직관적이지 않은 사용자 인터페이스는 낮은 외적 품질의 예라고 할 수 있다.

내적 품질은 대개 사용자들에게는 직접 드러나지 않지만 시스템을 유지보수하는 데 지대한 영향을 미칠 수 있는 것을 지칭한다. 시스템 설계의 일관성, 테스트 커버리지, 코드의 가독성, 리팩터링 같은 것과 관련이 있다.

일반적으로 내적 품질이 높은 시스템이라 하더라도 외적 품질이 낮을 수 있다. 하지만 내적 품질이 낮은 시스템에서 높은 외적 품질을 기대하기란 힘들다. 부실한 기초 위에 멋진 건물을 짓기란 어려운 법이다.

나는 외적 품질을 범위(scope)의 한 부분이라고 본다. 예를 들자면, 우선은 다소 불편하면서 느린 사용자 인터페이스라 하더라도 시스템을 출시한 다음 나중에 깔끔한 버전을 출시하는 것이, 경우에 따라서는 비즈니스 관점에서 보았을 때 전혀 문제가 없는 결정일 수 있기 때문이다. 나는 이와 같은 트레이드오프를 제품 책임자에게 맡겨둔다. 범위를 결정하는 것이 바로 그의 책임이기 때문이다.

반면, 내적 품질은 논의의 대상이 될 수 없다. 어떠한 상황에서도 시스템의 품질을 유지하는 것이야말로 팀이 책임져야 할 사항이며, 이것은 두말할 필요 없이 그냥 협상의 대상이 아니다. 절대로.

자, 그럼 어떤 것이 내적 품질에 관한 문제인지 혹은 외적 품질에 관한 문제인지 어떻게 구분할 수 있을까?

제품 책임자가 이렇게 말한다 치자. “여러분, 좋습니다. 저는 여러분이 스토리 점수를 6점이라고 추정한 것을 존중합니다. 하지만, 제 생각에는 여러분이 마음만 먹는다면 분명히 절반의 시간을 쓰면서 임시방편이라도 해결책을 내놓을 수 있을 것 같은데요.”

아하! 지금 제품 책임자는 내적 품질을 변수로 사용할 생각이다. 내가 그걸 어떻게 알았을까? 그는 지금 범위를 줄이는 ‘비용을 치를’ 의사는 없으면서, 우리에게는 스토리의 추정치를 낮춰 잡으라고 얘기하고 있기 때문이다. ‘임시방편’이라는 말을 들으면 여러분 머리 속에는 경고 장치가 울려야 한다.

그럼 우리가 이것을 허락하지 않는 이유는 무얼까?

개인적인 경험에 비추어봤을 때, 내적 품질을 희생하는 것은 거의 언제나 최악의 발상이었다. 시간을 잠시 버는 것은 단기적, 장기적으로 발생하게 되는 비용에 비하면 보잘것 없는 것이다. 코드 베이스가 오염되는 걸 허락하게 되면 나중에 품질을 되돌려 놓기란 매우 어렵다.

대신에 나는 범위 쪽으로 논의를 전개시킨다. “이 기능을 일찍 마무리하는 것이 중요하다고 하니, 좀 더 빠르게 구현할 수 있도록 범위를 줄이면 어떨까요? 오류 처리를 단순화하고, ‘고급 오류 처리’라는 별개의 스토리를 만들어 나중에 구현하도록 할 수 있겠군요. 혹은 이 스토리 구현에 집중할 수 있도록 다른 스토리의 우선순위를 낮추는 것은 어떤가요?”

제품 책임자가 내적 품질은 협상의 대상이 아니라는 점을 이해하고 나면, 보통은 그 대신에 다른 변수들을 조작하는 데 능숙해진다.

- 스크럼과 XP 中에서…

다시 돌아와서, 대부분의 비 기술자가 그렇듯이, 그 아르바이트의 사장님은 내적 품질의 중요성을 피부로 느끼지는 못하고 있었다. “응. 중요한 것 같긴 한데, 다음에”라는 대답은 대부분의 고객의 답변과 같지 않을까 싶다. 내게 코드 전체를 rewriting할 시간이 있었다면, 당연히, 훨씬 더 적극적으로 설득을 해보았겠지만.

고객들은 그렇다 치고, 정말로 놀라운 것은, “일단 돌아만 가면 되지 뭘”이라고 생각하는 프로그래머들도 굉장히 많다는 사실이다. 무너질 것을 뻔히 알면서 모래 위에 성을 쌓는다. 고객을 설득하는 것은 개발자가 인지한 후에나 가능하다. 제발 좀 인식했으면 좋겠다. 학교 과제처럼, 한번 실행하고 두번 다시 유지보수 하지 않는 소프트웨어가 아니라면, 내적 품질은 논의의 대상이 될 수 없다. 협상의 대상이 아니다. 절대로.

-- 이상한 나라의 종텐.

한 학기짜리 팀프로젝트가 시작되었다. 약 2주전부터, 무엇을 만들것인지에 대한 회의를 하고 있다. 팀장을 포함한 팀원은 모두 3명이고, 나는 이번엔 팀장이 아니다. 프로젝트의 규모는 처음엔 나름 간단(?)했으나, 점점 우주를 정복할듯한 기세로 커지다가, 우리가 제안한 5~6가지의 아이디어가 교수님에게 모두 기각되었다. 우리가 생각하기엔 정말 기똥찼는데, 구현 불가능 하단다. 제안서의 기안일이 오늘인데, 우리팀은 아직도 무엇을 만들지 정하지 못했다. 오늘도 대체 몇 시간을 여기에 매달렸는지 모르겠다. 다들 조금씩 날카로워지는 것이 느껴지고, 나도 짜증이 밖으로 새어나온다. 팀원들은 책임을 회피하고 있다. 프로젝트의 중요성 때문에, 몇개월 후에 원망을 들을까봐 선뜻 의견을 주장하질 못한다. 모두가 이 곳에 매달려 있지만, 아무도 책임을 지려고 하지 않는다.

문제는 하나였다. 지난 2주동안, 우린 기획자가 3명이었다. 모두의 목소리가 크기도 했고, 모두의 목소리가 작기도 했다. 수평적 관계? 모두가 동의하는 방향의 기획? 다 좋다. 하지만, 팀에는 의견이 수렴되지 않을 경우의 결정권자가 있어야 한다. 3명 모두 프로그래머이고, 모두 개발에 참여하지만, 그 중에서도 기획이면 기획, 설계면 설계와 같은 식으로, 파트별 결정권자가 별도로 있거나, 팀장이 결정권을 가져야 한다. 팀플레이에선 책임을 질 사람이 필요하다. 아무도 원망을 듣지 않으려 하면, 아무도 강한 제안을 하지 못한다. 정말 아니라면 반대를 해야겠지만, 팀이라면 결정권자의 의견을 존중해야 한다. 반면, 결정권자의 의견에 따르기로 했으면, 나중에 프로젝트가 망했다고 뒤에서 욕하는건 반칙이다. 당신도 망할줄 몰랐잖아?

-- 이상한 나라의 종텐.

몇일전에, 지난 몇주간 진행했던 프로젝트에 대한 회고를 처음으로 진행해봤다. 프로젝트 시작부터, 새로운 시도(모르는게 아는거보다 많았다는 의미)를 많이 했었는데, 그 결말도 새로운 시도를 해보고 싶었다. 애자일 회고라는 책을 참고했다. 사실, 이 책은 이터레이션에 대한 회고법이라서, 프로젝트 마무리에 대한 회고로는 부적합한 면이 조금 있어, 약간 수정하여 적용 해봤다.

원래는, 팀에 대한 회고와, 개인에 대한 회고를 구분하여 진행하려고 했지만, 여러 사정상 시간이 많지 않아, 회고 진행과정은 간단하게 다음과 같이 했다.

1. 회고 목적 설명 (회고를 하는 이유를 납득시킴) (5분)
2. 회고 진행간 집중할 것과 집중하지 말아야 하는 부분을 공지. (1분)
3. 다들 기억이 가물가물하기 때문에, 다같이 뭘 했었는지 회상함. (10분 가량)
4. 좋았던 점 / 개선할 점을 포스트잍에 작성 (10분간)
5. 그룹핑. (화이트보드나 전지가 없어서 A4용지 2장으로 대체) (10분)
6. 테이핑, 인기투표. 팀원이 3명밖에 없고, 점 테이프가 없어서 생략했음.
7. 나온 항목들에 대한 토론. (50분 가량)
8. 회고에 대한 회고. (5분)

처음 예상 시간은 1시간 이내였는데, 1시간 30분 정도 걸렸다. 첫 회고는 연습이 필요하다고 했었는데, 연습 없이 했더니 시간이 늘어난 것 같다. 좀 편안한 곳에서 느긋하게 맛있는 것을 먹으며 하고 싶었는데 좀 아쉬웠다. 좋았던 점과 개선할 점을 붙이는데, 포스트잍을 빨간색으로 하나 더 준비했으면 좋았겠다 싶었다. 색깔을 보고 알 수 있으면 더 좋을텐데. 아니면, 포스트잍색상을 이터레이션(마일스톤)별로 정해도 좋았을 것 같다. 전체 기간에 대한 회고였으므로.

팀원이 3명밖에 안되니깐, 분량이 적겠지 싶어서 점 테이핑을 안했었는데, 덕분에 토론 시간이 생각보다 꽤 길어졌다. 쉬는 시간이 없었는데, “좀만 더 하면 끝나겠지.. 좀만 더 하면 끝나겠지..” 하다가, 쉬질 못했다. 1시간 30분이나 걸릴줄 알았으면, 중간에 쉬었어야 했다. 한 명이 몇분 이상 말을 하지 못하는 규칙도 필요할 듯 싶다. 주로, 진행자인 내가 많이 떠들긴 했지만, 진행 이외의 상황에서도 화자(話者)의 말이 길어지면서 노이즈가 섞이는 경우가 많았다. 모래시계나 스탑왓치와 같은 도구를 사용한 시각적인 압박이 필요했다. 회고 진행시에, 랩탑이 있다면 Online Stop Watch도 괜찮은 선택인데, 우린 랩탑이 없었다. 모니터를 가득 메우는 숫자가 파닥파닥 하고 움직이면, 심리적 압박이 느껴지면서, 화자의 노이즈가 줄어들기에 효과가 좋다. 사람이 아무리 적어도, 말하는 내용의 주제는 3~4개 정도로 제한하는 것이 시간과 집중을 관리하는데에 좋다는 생각이 든다. 그래서, 점 테이핑을 하나보다. 그래. 점 테이핑이 필요했었다.

가장 우려했던 부분인데, 3명밖에 되질 않아서 그런지 모르겠지만, 다행이도 방관자는 없었다. 따로 Facilitater(촉진제 역할을 하는 사람)를 정하지 않았는데, 적당히 잘 진행되었다. 회고에 대한 회고에서, 팀원들은 회고 자체에 대해서 긍정이 섞인 신기하다는 반응이었으며, 그동안 무슨 작업을 했었는지 잘 기억이 안나서, Ticket을 확인했으면 좋았겠다는 의견이 있었다. (이제는 서버가 날아가서 티켓도 못 보지만 뭐…)

아, 마지막으로 정말 아쉬웠던 것은, 회고를 기록하지 못했다. 3명중 한명이 기록을 하면, 기록이 커뮤니케이션의 과정을 따라가지 못하기 때문에, 굉장히 늦어질 것 같았고, 말하는 사람이 적는 사람을 보며 천천히 말하며, 말하는 사람의 사고 과정도 느려질 것 같았다. 회고를 통한 느낌, 감정, 교훈의 공유가 기록보다 더 중요하다고 생각했다. 그래도, 단계들 사이사이에 딜레이 타임을 가지면서, 간단하게라도 기록을 하거나, 녹음을 했으면 조금 더 좋았을 듯 싶다.

이건 잘한건지 잘못한 건지 모르겠는데, 원래 회고는 감정보다는 이성에 맞추어서 진행하는게 원칙이다. SMART원칙도 이성에 대한 것을 이야기한다. 그런데, 이번 회고는 프로젝트를 끝내는 시점에서의 회고였고, 진행하는 동안 서로간에 쌓였던 불만사항 같은 항목들을 서로간에 풀어내기도 했다. 이런 이야기들을 회고자리에서 한 것이 맞는지는 모르겠으나, 서로 섭섭했던 것, 서운했던 것을 언급한 것이 괜찮았다고 생각한다(다른 팀원들의 생각은 잘 모르겠다.). 사실, 회고가 아닌, 회식 자리에서 하는게 맞지 않나 싶은 생각도 있다.

이번 회고로 인해 팀원들 모두가, 다음번 프로젝트는 언제 어디서 누구와 하든지간에, 더 즐겁게 할 수 있고, 더 많은 만족감을 남기길 희망한다. 더불어, 다음번에는 좀 더 좋은 회고를 하고 싶다.

-- 이상한 나라의 종텐.

xper 그룹스에서, 재밌는 쓰레드를 발견했다. 개발자의 개발량의 편차가 매우 큰 경우라는 쓰레드인데, 질문 글을 대략 요약하면,

Scrum 방식으로 개발팀을 운영하다 궁금한 점이 있어 Xper 그룹에 글을 적습니다.
11명(고객 포함)이 참여하는 SI 프로젝트에 재미난 상황이 하나 발생했습니다.

1. 코드의 공동 소유
2. Story Point 추정시 고객 포함 전원 참여

위와 같은 기법을 사용하고 있는 상황에, 각자의 스토리를 가져가서 한개의 Sprint 동안 계획을 짜도록 했습니다. 4차례에 Sprint 를 이미 진행 했고요.
문제는 속도가 빠른 팀이 불만을 터뜨린 것에서 시작되었습니다.
함께 추정한 포인트들에 대해 Pair Programming을 할 수 없는 상황에서,
특정 개발자가 50 정도의 속도로 작업을 수행하고,
대부분의 팀은 20 정도의 일을 수행하고,
한 명은 10 정도의 속도를 가지고 있습니다.

쉽게 말해 속도가 느린 개발자와 빠른 개발자의 개발 량이 거의 5배의 차이가 나는거죠.
이슈는 두 가지인데요

1. 어떻게 50의 속도를 가진 개발자를 '스스로 손해보고 있다' 라는 느낌을 적게 줄 수 있을지
2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지

에 대해 의견을 듣고 싶습니다.
감사합니다.

현 시대에는 혼자서 하는 프로젝트란 거의 없다고 봐도 과언이 아니다. 개발자들의 능력이 같은 팀 또한 있을 수 없다. 그런 능력차가 불만이 아니면 괜찮지만, 이렇게 불만으로 제시되어버리면, 굉장히 곤란할 듯 하다. 이런 사람과 관련된 이슈들이 프로젝트 진행에 있어서 가장 어렵고 힘든 부분이 아닐까 싶다.

http://groups.google.com/group/xper/browse_thread/thread/7358b9c36a13a97f
답변들은 위 링크에서 볼 수 있다. 좋은 답변들이 많다. 김창준님의 글도 볼 수 있다. :-)
답변들을 읽다보면, 프로젝트 관리는 누구에게나 쉬운 일은 아닌 것 같다. 리더라는 역할도.

지금까지, 내가 안드로메다로 보내버린 소프트웨어 프로젝트는 많았다. 학부생의 입장에서, 체계화된 개발 프로세스 관리를 직접 경험하지 못했기 때문이라 생각하는데, 비슷한 문제를 겪는 다른 학생들도 많으리라 생각된다. 그래서, 내가 말아먹은것에 결정적인 공헌을 했던 요소들을 정리하고자 한다. 어려움을 겪는 다른 사람들에게도 도움이 된다면 좋겠고, 결정적으로는, 앞으로 내 자신의 프로젝트 성공률이 성장한다면 정말 좋겠다.

프로젝트를 안드로메다로 보내는 방법, 그 첫번째.
프로젝트 리더가 모든 일을 하려고 하면, 프로젝트가 망한다.

이 항목은 특히, 학생들에게서 흔히 볼 수 있는 모습이다. 그 이유는 3가지가 있는데, 첫째, 학교에서 내주는 프로젝트 과제는 무보수이기 때문이다. 그 동기가 (억지로라도 하게 되는) 월급이 아니다. 해당 프로젝트를 열심히 하지 않는다고 학교에서 짤리진 않을 뿐더러, 점수는 같은 팀에겐 같은 점수가 주어진다. 둘째, 그나마 코딩 좀 하는 사람이 팀장을 맡기 때문이다. 코딩과 개발 프로세스 관리는 당연히 다른 부분이지만, 학생들의 경험은 대체적으로 비슷하기 때문에, 해당 분야에 대한 경험이 좀 더 많은 사람이 팀장을 맡는다. 그 기준은 코딩 경험이 되기 마련이다. 셋째로, 최악의 경우인데, 가위바위보로 팀원이 정해졌을 경우. 게다가 처음보는 사람이 팀원일 경우이다. 누가 얼마만큼의 능력이 있는지도 모르고, 어느 분야가 그 사람의 도메인인지도 모른다. 거기에, 묻어가야겠다는 사람들이 섞여있으면 첩첩산중. 이런 경우들이면, 다음과 같은 일이 일어난다.

1. 팀장이 팀원A에게 작업을 할당한다.
2. 팀원A가 작업을 하다가, 코딩을 쪼끔 더 잘 하는 팀장에게 물어본다.
3. 팀장이 팀원A의 코드를 보면서 수정할 부분을 알려주다가,
4. 정신을 차려보니, 팀장이 직접 코드를 짜고 있다!!
5. 1번부터 4번까지 반복.

이런 프로젝트는 십중팔구 안드로메다로 간다. 특히, 이런 부분이 많을수록 망한다. “팀장이 팀원에게 작업을 할당한다”라는 과정에는, “팀장이 팀원에게 책임과 권한을 위임한다”는 내용이 포함되어 있다. 좋은 리더의 역할은, 방법을 알려주는 것이 아니다. 팀원의 역량을 파악하고, 그 팀원을 믿으며, 팀원이 해낼 수 있는 분량의 책임과 권한을 위임하는 것이다. 그렇지 않고, 위와 같은 일이 발생하게 되면, 해당 팀원은 프로젝트 진행시에 “기여했다”는 느낌을 얻지 못하게 된다. 아무리 커다란 프로젝트의 아무리 작은 부분이라도, “훗~ 이 부분은 내가 했지!!”란 황홀한 기분을 느낄 수 있는 기회를 제공해줘야 한다. 그렇지 않으면, 이 프로젝트에서 자신이 짐만 되는 것 같다고 생각하게 되고, 점점 소극적이 되며, 자신감이 없어지고, 더욱 실적이 떨어지는 악영향의 무한루프가 시작된다. 프로젝트는 결국 안드로메다로 간다.

즉, 안드로메다로 보내지 않으려면, 팀원에게 책임과 권한을 위임해야 한다. 객체의 책임을 다른 객체에 위임하는 Strategy 패턴과도 같다. 아무리, 능력이 부족한 팀원이더라도, 그 사람이 해낼 수 있는 작업이 반드시 존재한다. 그 팀원에게 적합한 작업을 찾아서 연결하는 것은 팀장의 몫이다. 일종의 Load Balancing이라고도 할 수 있다. 그러면, 해당 팀원이 그 이슈를 해결하기 위한 충분한 지식을 갖추지 못했을 경우는 어찌해야 하는가? 그 이슈를 해결하기 위한 떡밥을 던져줘야 한다. 어찌 되었든간에, “내가 해결했어!”라는 만족감을 제공해줘야 한다. 그래야, 팀원들이 계속 노를 젓고, 배가 앞으로 나아간다.

이 항목은, 프로젝트의 마감이 다가올수록 점점 더 지키기 어려워지는 부분이다. (나처럼) 성격이 급한 사람이 팀장이 되어버리면, 더더욱 지키기 어려운 항목이다. 하지만, 안드로메다로 보내지 않으려면, 이 항목을 반드시 기억해야 한다. 팀장은, 팀원에게 책임과 권한을 위임해야 한다. 그 권한을 다시 뺐는 것은 도와주는 것이 아니다. 한두번은 도움이라 느낄지 모르지만, 그 행위가 계속되면 해당 팀원은 의욕을 잃는다.

-- 이상한 나라의 종텐.