한눈에 알 수 있는 악성 프로젝트의 15가지 징후

악성 프로젝트는 프로젝트 초기에 이미 결정되어 있다.

당신이 지금 시작하려는 프로젝트는 안녕한가 ?

다음의 체크 리스트를 통해 확인해 보자.

• 팀에 관한 부분, 팀이 가장 중요하다.

1. 프로젝트의 책임자가 "머릿수를 채우면 프로젝트는 돌아간다."라고 생각하고 있다. 프로젝트 수행에 적절한 인력으로 팀을 구성하는 것이 아니고, 그때 그때 어디선가 나오는 남는 인력으로 팀원을 구성한다. 심한 경우 한두달 씩 돌아가며 땜빵시킨다.

comment : 겉으로는 아니라고 말하지만 하는 행동을 보면 의외로 이렇게 생각하는 책임자가 많다. "상황이 어쩔수 없다. 이래야 돈을 번다"고 주장 하지만 잘 관찰해보면 근본 마인드 자체가 이래도 된다고 생각하고 있다. 어쨋든 돈만 벌면 된다는 책임자 밑에서 당신은 부품일 뿐이다. 이런 책임자와는 가급적 빨리 결별하자.

1. 핵심 인력이 프로젝트 초반부터 팀에 합류하지 못한다. " 2달 뒤에 합류한다" 라고 말한다면, 3달 뒤에 합류하거나 아예 못한다. 즉 자기팀이 누구로 구성될지 알 수 없으며, 언제 올지도 모른채 프로젝트가 시작된다.

comment : 담당 임원의 말은 대부분 믿을 수 없다. 그들이 잘 쓰는 말은 "2달 뒤에는 어떤 일이 있어도" 이다. 수도 없이 지키지 않은 약속을 뻔번하게 반복한다. 노련한 PM 은 2달을 3달로 알아서 고쳐듣는다. 끝날 때까지 안오는 경우도 태반이라는 것도 알고 있다. 프로젝트에 합류는 했는데, 전에 하던 프로젝트의 문제로 여전히 절반 이상의 시간을 빼앗기고 있는 경우도 많다. 몸만 온것이다.

1. PM 또는 팀이 전반적으로 프로젝트 수행에 필요한 지식를 충분히 가지고 있지 못하거나 해당 분야의 경험이 전혀 없는 사람으로 구성된다.

comment : 대개 1)번과 관련이 있다. 적임자를 넣은게 아니라 시간이 되는 사람을 넣다보니, 충분한 지식을 가지고 있지 못하다.

1. 팀 내부에 불화가 있거나 팀이 "원거리"에 흩어져 있다.

comment : "원거리에서도 잘만 하더라" 라는 말을 믿지 말라. 잘하는 팀은 잘할 수 있도록 도와주는 시스템의 도움을 받는다. 여기서 시스템은 원격화상회의 시스템 이상의 문화적, 인적 베이스를 말한다.

1. 팀의 핵심인력들이 2개 이상의 "연관성이 희박한" 프로젝트를 동시에 수행하고 있다.

comment : "연관성이 희박한" 이 핵심

1. 팀의 PL 급들이 "책임감이 없는" 외주(프리랜서)로 채워져 있다.

comment : 일정과 핵심 기술이 프로젝트가 끝나면 사라져버릴 프리랜서에 달려있다. ("책임감이 없는" 이 핵심)

• 일정에 관한 부분, 품질은 일정에 민감하다.

1. 살인적 일정, 요구사항에 비해서 일정이 절대적으로 짧다.

comment : 프로젝트 수행중에 "일단은.." 이라는 말이 자주 사용되게 된다. 시간이 없으니 일단, 이렇게 하고..나중에 어떻게든 되겠지 하는 것이다. 엔지니어 들도 살고 봐야 하기 때문이다. 하지만 안드로메다에 가 있는 품질은 언젠가 뒤통수를 치러 반드시 다시 온다.

1. 마감일은 고정 불변이나 시작일은 끝없이 늘어진다.

comment : 마감일은 최고위층이 정한다. 불변이다. 그러나 시작일은 최대한 늦춘다. 할지 말지 갈팡질팡하기 때문이다. 판단을 최대한 늦추어야 변화하는 환경 속에서 리스크를 줄일 수 있기 때문이다. 이 와중에 엔지니어의 사생활이 희생되는 것이다.

-- 요구사항에 관한 부분, 많을 수록 좋은 줄 안다.

1. 기간이 짧은 대신 기능 요구사항을 줄여주겠다고 말하지만 실제로 줄어드는 것은 별로 없다.

comment : 마감 시간이 촉박한 대신 요구 사항을 줄여주겠다는 것은 가장 흔히 나오는 거짓말이다. "이것은 기본이지 않냐", "이건 고객이 꼭 요구해" 등등의 판에 박힌 이유로 결국 대부분 하게 된다. 꼭 필요한 것만 만들자고 하지만, 4바퀴에 엔진만 달린 차를 만들 수는 없다. "에어콘도 있어야 하고, 오디오도 있어야지..그런거 없는 차가 요새 어디있나.." 하다보면 후방 감시 카메라와 전자식 스마트 키가 들어가야 프로젝트가 끝이난다. 줄인것은 결국 뒷좌석 자동안마기와 어댑티브 헤드램프 정도에 불과하다.

1. 요구된 기능이 소요되는 공수에 비해서 실효성이 없다. 실제로는 들어가는 돈 만큼의 실효성이 없는데, 고객이나 제품 담당자가 INPUT 대비 OUTPUT 개념이 없고, OUTPUT 의 절대가치만 생각한다.

comment : 대표적인 예가 진시황제의 만리장성과 이명박의 4대강이다. 만리장성 어쨌든 멋지지 않은가? 4대강 어쨋든 안한거 보다 좋잖아? 이런 사고방식이다. 이런 경우 10원의 가치라도 계속 더 더하고 싶어하기 때문에 위험하다. INPUT 대비 OUTPUT 의 효율이 낮은 기능이 많아지면 많아질 수록 프로젝트 수행은 점점 어려워지고 산으로 간다.

1. 고객이나 제품 담당자 또는 PM 을 비롯한 기술진 모두가 실제로 무엇이 필요한 것인지 잘 모르고 있다. 그러나 잘안다고 생각하고 있다.

comment : 이런 경우 핵심에서 벗어난 기능에 집착하거나 나중에 안쓸 기능을 많이 만들게 된다. 고객의 요구사항이 변하는 경우 역시 더 많아질 수 밖에 없다. 사실 비지니스 프로그램은 오픈하기 전에 무엇이 필요한지 정확히 모르는 것이 당연하다. 문제는 이 당연함을 기반으로 프로젝트를 수행하는 것이 아니라, 다 안다고 생각하고, 프로젝트를 수행한다는 것이다. 조금씩 시장의 반응을 피드백하면서 증분 제작하는 방식으로 수행해야 하는데, 프로젝트 대부분이 전지전능한 누군가의 폭풍같은 요구사항을 모두 끝낸뒤에 시장의 반응을 살핀다.

1. 고객이나 제품 담당자가 기술진의 충고를 무시하고 시스템의 복잡도를 기하급수적으로 증가시킨다.

comment : 겉보기에는 작은 요구사항이 사실은 시스템의 복잡도를 크게 증가시키는 경우가 많다. 대개 기술진이 이를 미리 알지만, 때로는 기술진도 그 사실을 모르다가 나중에 알게되는 경우도 많다. 복잡도가 통제력의 범위를 벗어나면, 문제가 폭포처럼 쏟아지기 시작한다.

-- 기술에 관한 부분, 기술의 선택이 승패를 가르는 경우가 많다.

1. 해당 비지니스 요소에 꼭 맞는 기술요소를 선택한 것이 아니라 자신이 편한 것을 선택했거나,현재 인력 구성에 맞추었다.

comment : 기술요소는 우선적으로 사용자의 특성과 비지니스 목적 및 환경에 따라 선택되어야하고, 기술에 대한 친숙도는 그 다음 선택 기준이 되어야 한다. 현재 인원이 기술에 친숙하지 않다면, 친숙한 인력으로 팀을 대체 구성하는 것이 바람직하다. 그러나 대부분의 경우, 인력 수급이 불가능하기 때문에, 고객의 비지니스 특성 보다는 우리 팀의 기술적 특성에 맞추어 프로젝트는 진행된다.

1. 해당 비지니스 요소에 꼭 맞는 기술요소를 선택한 것이 아니라 유행을 따랐다.

comment : 사용자의 특성과 비지니스 목적 및 환경보다는 최신 유행을 따르는 경우가 의외로 많다. 고객을 현혹시키기 좋기 때문이다. 그러나, 당신은 왜 최신 유행하는 스키니진을 입지 않는가? "그렇다, 당신은 배도 나왔고, 사회적 지위도 있다." 이 간단한 원리을 프로젝트에서도 곰곰히 생각해 보는 사람은 의외로 적다.

1. 너무 많은 이종 기술요소를 접목했다.

comment : 프로젝트에서는 WEB, Java, C++ 를 모두 사용하는 것은 기본일 정도로 많은 기술요소가 사용된다. 많은 요소를 사용하면 나중에 유지보수 인력 역시 대규모로 가져가야 한다.

당신의 프로젝트는 몇점인가요?

10점 이상이면 누구나 다 싫어하는 프로젝트일 것입니다.

이때에 우리의 책임자가 하는 말이 있다.

"인생에 모든 조건이 다 갖추어지는 경우는 없습니다. 불비한 요건 만큼 노력으로 돌파하는 자가 승리자가 되지요. 그렇니까 프로젝트 환경 불평 말고 노력하세요..."

음..무척 옳은 말이지만, 책임자로서 위의 악조건 16개중에 한개라도 더 줄여보겠다는 말이 더 도움이 될것이다.