5. 프로젝트 생산성

프로젝트 생산성

---

생산성과 근무시간

소프트웨어 개발에 참여했던 사람들이 모여서 하는 얘기 중 하나가, 자기가 참여했던 프로젝트가 얼마나 힘들었었는지, 휴일 없이 얼마나 오랜 시간 쉼 없이 일했는지를 자랑스럽게 얘기하곤 하는 것이다.

그러나 이것은 그들이 참여했던 프로젝트가, 대부분의 불운한 프로젝트와 마찬가지로 프로젝트 크기에 대한 일정과 비용 추정이 잘못되었던지, 그들 고객의 마음이 갈대와 같았던지 혹은 그들의 역량이 보통 이하의 수준이었음을 증명할 뿐 그 이상 그 무엇도 아니다.

우리 모두가 알 듯 하루 18시간 이상 일하며 1년 혹은 2년 이상을 줄곧 같은 패턴으로 일할 수는 없다. 장시간의 긴 노동은 사람의 몸과 마음을 지치게 하며, 이는 집중력 저하와 잦은 실수로 이어져 프로젝트를 엉망으로 만들고 만다.

젊고 프로젝트에 대한 열정이 넘치는 프로젝트팀에게 2~3개월 동안의 소규모 프로젝트라면 잔업이 큰 문제가 되지 않을 수 있다. 그러나 잔업이 장기화 되고, 개발 초반의 열정이 식게 될 무렵엔, 잔업은 프로젝트에 오히려 독이 될 수 있다.

 

그림 17 생산성과 근무시간 (Yourdon, Death March, 2004, p. 179), 생산성과 근무시간에 대한 예시일 뿐 결코 연구결과에 의한 일반화된 그래프가 아니다.

그림 17에서 처럼 잔업에 의한 생산성은 60~80시간까지는 증가할 지 모르지만 그 이상은 한계상황에 도달하며 더 이상의 작업은 아무것도 안하니만 못한 상황이 될 수 있다.

사막지역에서 현대식 집을 지을 때는 40~60Kg짜리 벽돌을 쓰는 데, 모래 위에 집을 짓는 것이라 무거운 벽돌을 이용해 집을 짓는다. 벽돌이 너무 무거운지라 그것을 쌓는 데도 상당한 시간이 걸렸다. 
하루는 건축기간을 단축시키고자 하루에 벽돌을 쌓는 수만큼 인센티브를 주기로 하였다. 인센티브 소식에 하루에 체 2단을 쌓기도 어렵던 일이 4단, 5단씩 쌓였다.
다음 날 아침, 건설현장엔 허리 부상을 이유로 아무도 출근치 못 했다. 부상이 모두 회복되기까지 2주간의 시간이 필요했다. 
                                                                                                                         - 건축과 수업 중에서

잔업이 일시적으로 생산성을 향상 시키는 요인이 될 수는 있으나, 이러한 잔업이 장기화되면 프로젝트팀의 사기를 극도로 낮추는 요인이 될 수 있다.

전쟁은 군인의 사기로 하는 것이지, 무기의 양으로 하는 게 아니다. 만약 무기의 양으로 전쟁을 한다면, 전쟁초기에 국경에 모여 전차 개수와 핵 폭탄의 개수 등을 헤아려 인명 피해 없이 승부를 가늠할 수 있을 것이다.

마찬가지로 소프트웨어 개발 프로젝트 또한 상당부분을 프로젝트팀의 사기에 의존하게 되는 데, Yourdon은 프로젝트팀의 사기에 가장 큰 영향을 끼치는 요인으로 프로젝트 관리자의 통제하에 있는 잔업과 보상을 꼽았다. (Yourdon, 죽음의 행진, 2004)

프로젝트의 수행을 위해서 잔업이 필수불가결 하다면, 잔업에 따른 보상 또한 필수불가결한 요소이다.

"프로젝트 분석, 설계 때부터 하루 12~13시간씩 일해왔어요. 6개월 동안의 분석, 설계가 끝나고막상 개발을 시작했을 땐 몸과 마음이 많이 지쳤어요. 그리고 또다시 8개월이 흘렀어요. 지난 수개월 동안은 토요일, 일요일도 없었구요. 이젠 이 프로젝트를 어서 빨리 끝내야겠단 마음보단어떻게 하면 이 프로젝트를 빠져 나갈까를 궁리해요.
"이 프로젝트가 1주일, 1개월이 빨리 끝난다고 해서 제게 무슨 이득이 있나요?" 
                                                            - 프로젝트 오픈이 2개월 지연된 날 새벽, 개발팀원과의 대화 중에서 

개인별 업무 능력

개인별 생산성을 조사했던 Tom DeMarco에 따르면, 개인의 능력차가 10배에 다 달았으며, 중간 이상의 업무능력을 가진 사람과의 차이도 2.5배의 차이를 보였다. (그림 18)

특이할 만한 사실중의 하나는 프로그래밍 언어, 경력등과 생산성이 관련성이 없다는 사실이었으며, 더욱 놀라운 사실 중의 하나는, 같은 회사 사람들이 갖는 편차가 21%밖에 되지 않는다는 사실이었다.

이는 업무 능력이 뛰어난 사람들이 모여 있는 회사가 있고, 그렇지 않는 회사가 있을 수 있음을 나타내며 이들 회사간의 능력차도 10배에 이를 수 있음을 보여준다.

회사의 업무환경과 기업문화의 영향으로 인해 뛰어난 사람들을 유치하거나 혹은 뛰어난 사람들을 이직하게 함으로써 회사간의 생산성의 차이를 유발한다.

 

그림 18 개인별 생산성 편차 (DeMarco & Lister, Peopleware, 1999, p. 79)

프로그래밍 언어와 경력이 생산성과 무관했던 사실은 이 조사가 수행되었던 시기가 80년대 중반이었음에 기인했던 것으로 추정된다. 당시는 3GL / 4GL 언어 등의 구분이 없었던 시기였으며 프로그램 언어의 성숙도 또한 현재보단 낮았다.

4GL 언어는 3GL 언어보다 구현노력을 75%까지 줄일 수 있다는 연구결과가 있으며 (Jones, Software Productivity Research Programming Language Table, 1995) 이는 3GL 언어에서 프로그래머가 직접 구현해야 했던 많은 부분을 4GL 언어 자체가 제공하고, 보다 직관적인 비쥬얼 프로그래밍이 가능함으로써 가능하게 되었다. DeMarco에 의해 개인별 생산성 편차에 대한 연구가 이뤄졌던 당시에도 어셈블리어로 개발하는 경우는 포트란이나, 코볼 등의 언어보다 생산성이 낮았다.

4GL언어가 3GL 언어보다 많은 부분을 제공하였지만, 이를 제대로 사용하기 위해서는 과거보다 더 많은 학습이 필요해 졌으며, 고객의 눈높이 또한 높아져 이 눈높이를 맞추기 위해서는 더욱 많은 노력이 필요하게 되었다. 과거 프로그램 언어를 배우는 과정이 문법만을 배우면 되던 시기였다면, 현재는 그와 관련된 수많은 라이브러리와 프로젝트의 프레임워크를 익혀야 되는 시기가 되었으며, 프로그램의 복잡도 또한 몇 배나 증가되어, 과거보다 높은 숙련도를 요구하는 시기가 되었다.

단적인 예로 예전엔 개발 툴을 1.2MB 짜리 디스켓 몇 장으로 설치하던 시기였으나 현재에는 4GB 짜리 DVD로 설치해야 하는 시기가 된 것이다.

프로젝트 도구와 생산성

새로운 도구를 적용하게 되면 마치 모든 것이 다 해결될 것인 양 벤더에서 광고를 하지만 이제 우리는 그런 광고에 너무도 익숙해져서 그러한 얘기에 현혹된 정도로 순진하진 않다.

물론 새로운 도구가 프로젝트의 생산성에 도움을 준다. 하지만 그림 18에서 처럼 새로운 도구를 프로젝트에 도입하게 되면 학습곡선으로 인해 일시적으로 프로젝트의 생산성은 낮춰지며, 만약 그 프로젝트가 이러한 손실을 만회할 정도로 크지 않다면 새로운 도구의 도입은 프로젝트 전체를 지연의 늪으로 빠뜨릴 우려가 있다.

 

그림 19 학습 곡선이 생산성에 미치는 영향 (McConnel, Rapid Development: Taming Wild Software Schedules, 1996, p. 356)

따라서 프로젝트의 수행 시 새로운 도구의 도입은 신중해야 하며 되도록 검증된 것으로 그리고 프로젝트 팀원이 익숙한 도구로써 시작하는 것이 바람직하다.

개발자의 동기와 일정압력

프로젝트가 지연되면 고객이나 관리자가 제일 먼저 보이는 반응은 프로젝트 팀에 일정에 대한 압력을 가하고 초과근무를 종용하는 것이다.

프로젝트 팀에 가해진 일정 압력이 평균을 상회하는 경우, 프로젝트 팀의 사기를 극도로 저하시키는 데 이는 생산성에 지대한 영향을 줌으로써 전체 진척율을 떨어뜨리는 효과를 낳는다. 또한 타의에 의해 종용된 초과 근무는 초과 근무에서 오는 생산성의 증가보다 동기저하로 이뤄지는 생산성의 저하가 크다(그림 20)

 

그림 20 일정압력/근무시간, 전체결과, 개발자 동기 사이의 관계 (McConnel, Rapid Development: Taming Wild Software Schedules, 1996, p. 608)

주당 60시간 이상의 근무가 장시간 지속되는 경우, 사람들은 동호회 일을 보거나 개인 블로그를 관리하는 등 개인적인 일을 근무시간에 하게 된다. 이로 인해 사무실에 남아있는 시간은 길지만 실제로 일하는 시간은 이보다 훨씬 적게 되며, 생산성은 저하되고 육체적 피로만 가중되는 상황이 벌어진다.

결국 개발자의 동기에 의한 자발적 초과근무만이 생산성 향상을 이끌어 낼 수 있다.

관리팀의 辯 

사람들이 초과 근무를 하는 이유는 과제를 주어진 시간 안에 끝마치기 위해서라기보다는, 일을정해진 기간까지 끝마치지 못했을 때 비난 받게 될 것을 우려해 자신을 보호하기 위함이다 – 제리 와인버그 

알고 있었다.
프로젝트가 망가진 이 마당에 개발자를 추가로 투입한다는 것이 그다지 소용이 없으며, 개발자들이 밤늦게까지 앉아 있는다고 해서 그다지 진척이 없다는 것을. 
프로젝트가 망가졌음이 공공연한 사실로써 받아들여졌을 무렵부터 개발자들이 일에 전념을 하지 않고, 인터넷을 뒤지거나, 전엔 잘 가지도 않던 은행을 자주 가고 있었다. 
시력을 잃으면 다른 감각이 발달한다고, 개발 쪽 일을 하다가 관리라는 것을 하게 되면 평소엔관심도 없었던 주변 사람들의 전화 소리가 더 잘 들려오게 되고, 개발자 모니터에 떠있는 화면들 또한 더 눈에 잘 들어온다. 
현재에서 최선의 방법은 일단 모두가 1주일 정도 쉬고, 개발량에 맞춰서 개발일정을 한참 뒤로늦추거나, 개발일정에 맞춰서 개발량을 줄이는 방법밖에 없음 또한 알고 있었다. 
프로젝트가 망가진 뒤부터, 평소엔 관심도 없던 회사 분들이 이걸 조사해서 보내달라, 프로젝트복구 방안을 만들어서 달라, 온갖 리포트를 만들어 줄 것을 요청해 왔다. 그리고 대책 회의는 왜그리도 많이 잡히는 지. 정신이 없었다.
회의 내용은 한결 같았다. 도와줄 테니 방안을 제시해라. 방안? 이 방안이란 것에도 항상 수식어구가 따랐다. 비용 안 들이고, 프로젝트의 일정과 품질을 준수하는 방안. 그런 게 있었다면 우리가 벌써 했을 것이다. 회의에 참석한 이 많은 사람들이 도와주려고 온 건지, 일을 방해하려고 온건지 구분조차 안 되는 장시간의 마라톤 회의. 답은 뻔한 데도 누구 하나 제대로 말을 못하는 그런 회의가 계속 되었다. 
프로젝트가 망가질 수 있음은 이미 분석, 설계를 끝마치고 예견했던 사실이었다. 그러나 이 사실을 회사 관리팀에 보고했을 때, 돌아오는 답변이라곤 프로젝트 기간이 아직 남았지 않느냐? 그 동안 생산성을 향상할 수 있는 방안을 마련해서 적용하면 되지 않겠냐는 답변뿐이었다. 
생산성 향상? 마치 전쟁터에 나가 적들과 싸우면서, 총의 성능을 개량해 보란 얘기랑 똑같았다. 
결국 개발에 대한 중간보고 시점이 되었을 때, 프로젝트 복구방안이라고 낼 수 있는 것이라는게, 고작 초과근무와 추가 인력투입이었다. 
어렵사리 승인을 받아 추가된 인력이 왔을 때, 개발자들이 난감해 함을 알고 있었다. 일은 잘라줘야 하는 데 어디서 어떻게 잘라야 할지? 또 업무를 어떻게 가르쳐야 할 지? 대략 난감. 그러나우린 "우리가 이 어려운 프로젝트를 제 날짜에 끝내기 위해 이렇게 투자하고 있습니다." 라고 고객에게 말할 것이 필요했다. 
고객과의 정기 회의가 다가올 때면 가슴이 두근거리고, 오늘은 또 어떤 얘기를 하려나? 걱정이되었다. 이건 되었느니, 저게 안 되었느니. 정말 그 사람 눈에 우리 시스템은 왜 그리도 맘에 안드는지. 일정은 어떻게 되냐고 다그치고. 그러다가 웃으며 툭 던지는 말. 
"추가 사업 더 안 하실 거예요?"
 개발자들에게 프로젝트에 대한 동기를 부여하고 싶었다. 그러나, 갑을 제외한 을, 병, 정, 무까지 있는 프로젝트 팀원에게 동기를 부여할 방안이란 게 마땅치 않았다. 휴가? 오픈 일자가 한참지난 이 시점에? 하루에 물고 있는 지체 보상금이 계속 누적되어 가고 있는 이 시점에 휴가를 간다고? 얘기를 꺼냈다간 사장이 당장 목을 칠 눈빛인데? 결국 개발자들에게 그간의 인간적인 정으로 호소하는 것 외에는 딱히 해 볼 도리가 없었다.

이미 사기는 바닥을 쳤고 프로젝트는 망가질 대로 망가지고, 하루하루가 살 얼음 판을 걷고 있었던 그 때. 
우리는 과연 무엇을 할 수 있었을까?
개발자들에게 술을 좀 더 먹였어야 했나? ^^;

 

 

[원문주소] : http://swarchi.tistory.com/5