2016.07.25

글로벌 칼럼 | 실패하는 소프트웨어 프로젝트의 7가지 단계

Andrew C. Oliver | InfoWorld
필자는 실패를 피하거나 성공을 추구하는 방법에 관해 지금까지 많은 글을 썼다. 또한 프로젝트를 성공으로 이끄는 요소에 대해서도 많은 글을 썼다. 그러나 이번 기사의 주제는 조금 다르다.
이 기사는 실패로 치닫는 프로젝트에 참여해서, 그 실패를 만회할 방법이 없음을 인식할 때 우리가 받는 느낌에 대한 것이다

1. 낙관
얼마 전 NPR이 우울증에 관한 연구 보고서를 발표했는데, 이 보고서에 따르면 낙관주의가 우울증의 핵심 요소라고 한다. 희망과 꿈이 무너지려면 먼저 희망을 가져야 한다. 힘든 일을 계속 해나가기 위해서는 현실이 정 반대라고 해도 '앞으로 나아질 것'이라고 믿어야 한다.

실패하는 프로젝트의 시작도 거의 비슷하다. 실패하는 프로젝트의 시작은 희망과 낙관주의다. 사실 실패하는 프로젝트는 성공적인 프로젝트보다 더 큰 낙관을 바탕으로 시작된다.

과거 한 프로젝트에서 필자는 환경적 요인을 감안하여 프로젝트가 제 시간에 완료될 가능성에 대해 비관적으로 전망한 적이 있다. 그러자 프로젝트 관리자가 찾아와 마이크로소프트 프로젝트의 기술적 분석을 근거로 필자가 예측한 시간을 대폭 줄였다. 프로젝트는 거의 정확히 이 관리자가 줄인 시간 만큼의 날짜를 초과했다. 프로젝트 관리자는 낙관주의를 바탕으로 프로젝트가 다른 환경에서 진행되었을 때와 동일한 시간 내에 완료될 수 있다고 믿었던 것이다.

2. 비난
실패하는 프로젝트에서 어느 시점이 되면 뭔가 잘못 돌아간다는 점이 명확히 드러나게 된다. 이 경우 타당한 대처는 문제를 파악하고 교정 방안을 고안하는 것이다. 그러나 대부분의 실패하는 프로젝트에서 사람들은 누군가를 비난하는 쓸모 없는 행위에 더 많은 에너지를 소비한다.

사람이 문제가 아니라는 뜻이 아니다. 사실 많은 경우 사람이 문제다. 그러나 사람들의 잘못보다 그 사람들에게 책임을 전가하는 과정이 더 중요하다. 무엇을 교정하려는 것이고, 어떤 방법으로 교정할 것인가?

비난과 관련하여 생각해볼 점은 아주 작은 규모의 프로젝트를 제외하면 모두가 실수를 저지른다는 것이다. 누군가가 만든 버그성 쿼리가 열흘 동안 네트워크 또는 장비가 중단된 것보다 더 많은 문제를 야기했다고 비난하지만, 그 근거에 대한 논리적 분석은 없다. "그건 그렇고, 작업할 개발 환경이 필요하다는 말은 왜 안했습니까? 그걸 분명히 말씀하셨어야죠."

3. 코딩 혹사
실패하는 프로젝트에는 항상 영웅이 있다. 업무 능력 성숙도 모델 방식으로 표현하자면 저렴한 노동력 대신 숙련된 인력에 의존하도록 만드는 프로세스의 부재이고, 마블 코믹스 방식으로 표현하자면 특별한 능력과 엄청난 인내심을 가진 사람을 혹사시켜 모두 함께 해야 할 일을 이들에게 맡기는 것이다. 하루에 12시간~16시간씩 영웅적으로 일하지만 실수는 필연적이다. 실패하는 프로젝트에서는 이러한 영웅들 역시 비난의 대상이다.

4. 무관심과 체념
실패하는 프로젝트에서 어느 시점이 되면 어떻게 해도 실패로 치닫는 상황을 되돌릴 수 없음을 인지하게 된다. 이는 권한의 부족, 신뢰의 부족, 리소스의 부족 또는 여러분 스스로의 부족함 때문일 수 있다.

이 시점이 되면 문제 해결을 위한 노력을 포기하고 시키는 대로만 하게 된다. 배가 거대한 빙산을 향해 가고 있음이 보이지만 더 이상 신경 쓰지 않는다. 회의, 질책, 비난, 암시, 압력, 책임 전가에 진력이 났다. 누구의 잘못이든 그게 무슨 상관인가? 함께 해결 방법을 찾자. 하지만 그 지점을 지났다. 너무 늦었다. 이 대화는 이미 했다. 그 때도 듣지 않았는데 지금이라고 들을까? 이제 배는 침몰할 일만 남았다.

5. 인도와 실패
오바마케어 웹사이트를 기억하는가? 제대로 되지 않을 것임을 알고도 사이트를 출범해야 했던 사람들을 기억하는가? 필자는 어떻게 될지 궁금하지 않았다. 필자는 모든 사람이 실패할 것임을 알고도 시키는 대로 할 수밖에 없었던 프로젝트에 여러 번 참여했었다.

다행히도 대부분의 실패하는 프로젝트는 실패한 상태로 인도되기보다는 중간에 자금이 끊기거나 취소되거나 우선 순위에서 뒤로 밀리게 된다.

6. 안도
실패한 프로젝트 이후 대부분의 사람들은 당초 자신이 예상했던 것만큼 심한 우울함을 느끼지는 않는다. 웬만한 규모의 프로젝트에서는 프로젝트 진행 과정에서 우울함과 근심, 걱정을 이미 경험하므로, 실제로 프로젝트가 실패해서 거기서 벗어난 상태에서는 더 이상 그런 감정을 느끼지 않게 되는 것이다. 이상하지만 이 때의 느낌은 일종의 안도감이다.

7. 인식
프로젝트 실패는 대체로 하향식으로 발생한다. 근본적인 원인을 보면 거의 항상 소통의 부재, 그리고 팀원들의 기본적인 존중심 결여가 뒤섞여 있다. 경영진으로서는 또 다른 재앙을 방지하기 위해서는 이러한 징후를 인식하는 것이 중요하지만, 프로젝트에 참여하는 사람들이 경영진에게 (대화를 위해) 다가갈 수 없다고 느끼면 실패는 다시 반복된다. 차이를 이끌어낼 수 있는 위치에 있는 사람들 중에서는 무엇을 고쳐야 하는지 아는 사람이 없기 때문이다. editor@itworld.co.kr


2016.07.25

글로벌 칼럼 | 실패하는 소프트웨어 프로젝트의 7가지 단계

Andrew C. Oliver | InfoWorld
필자는 실패를 피하거나 성공을 추구하는 방법에 관해 지금까지 많은 글을 썼다. 또한 프로젝트를 성공으로 이끄는 요소에 대해서도 많은 글을 썼다. 그러나 이번 기사의 주제는 조금 다르다.
이 기사는 실패로 치닫는 프로젝트에 참여해서, 그 실패를 만회할 방법이 없음을 인식할 때 우리가 받는 느낌에 대한 것이다

1. 낙관
얼마 전 NPR이 우울증에 관한 연구 보고서를 발표했는데, 이 보고서에 따르면 낙관주의가 우울증의 핵심 요소라고 한다. 희망과 꿈이 무너지려면 먼저 희망을 가져야 한다. 힘든 일을 계속 해나가기 위해서는 현실이 정 반대라고 해도 '앞으로 나아질 것'이라고 믿어야 한다.

실패하는 프로젝트의 시작도 거의 비슷하다. 실패하는 프로젝트의 시작은 희망과 낙관주의다. 사실 실패하는 프로젝트는 성공적인 프로젝트보다 더 큰 낙관을 바탕으로 시작된다.

과거 한 프로젝트에서 필자는 환경적 요인을 감안하여 프로젝트가 제 시간에 완료될 가능성에 대해 비관적으로 전망한 적이 있다. 그러자 프로젝트 관리자가 찾아와 마이크로소프트 프로젝트의 기술적 분석을 근거로 필자가 예측한 시간을 대폭 줄였다. 프로젝트는 거의 정확히 이 관리자가 줄인 시간 만큼의 날짜를 초과했다. 프로젝트 관리자는 낙관주의를 바탕으로 프로젝트가 다른 환경에서 진행되었을 때와 동일한 시간 내에 완료될 수 있다고 믿었던 것이다.

2. 비난
실패하는 프로젝트에서 어느 시점이 되면 뭔가 잘못 돌아간다는 점이 명확히 드러나게 된다. 이 경우 타당한 대처는 문제를 파악하고 교정 방안을 고안하는 것이다. 그러나 대부분의 실패하는 프로젝트에서 사람들은 누군가를 비난하는 쓸모 없는 행위에 더 많은 에너지를 소비한다.

사람이 문제가 아니라는 뜻이 아니다. 사실 많은 경우 사람이 문제다. 그러나 사람들의 잘못보다 그 사람들에게 책임을 전가하는 과정이 더 중요하다. 무엇을 교정하려는 것이고, 어떤 방법으로 교정할 것인가?

비난과 관련하여 생각해볼 점은 아주 작은 규모의 프로젝트를 제외하면 모두가 실수를 저지른다는 것이다. 누군가가 만든 버그성 쿼리가 열흘 동안 네트워크 또는 장비가 중단된 것보다 더 많은 문제를 야기했다고 비난하지만, 그 근거에 대한 논리적 분석은 없다. "그건 그렇고, 작업할 개발 환경이 필요하다는 말은 왜 안했습니까? 그걸 분명히 말씀하셨어야죠."

3. 코딩 혹사
실패하는 프로젝트에는 항상 영웅이 있다. 업무 능력 성숙도 모델 방식으로 표현하자면 저렴한 노동력 대신 숙련된 인력에 의존하도록 만드는 프로세스의 부재이고, 마블 코믹스 방식으로 표현하자면 특별한 능력과 엄청난 인내심을 가진 사람을 혹사시켜 모두 함께 해야 할 일을 이들에게 맡기는 것이다. 하루에 12시간~16시간씩 영웅적으로 일하지만 실수는 필연적이다. 실패하는 프로젝트에서는 이러한 영웅들 역시 비난의 대상이다.

4. 무관심과 체념
실패하는 프로젝트에서 어느 시점이 되면 어떻게 해도 실패로 치닫는 상황을 되돌릴 수 없음을 인지하게 된다. 이는 권한의 부족, 신뢰의 부족, 리소스의 부족 또는 여러분 스스로의 부족함 때문일 수 있다.

이 시점이 되면 문제 해결을 위한 노력을 포기하고 시키는 대로만 하게 된다. 배가 거대한 빙산을 향해 가고 있음이 보이지만 더 이상 신경 쓰지 않는다. 회의, 질책, 비난, 암시, 압력, 책임 전가에 진력이 났다. 누구의 잘못이든 그게 무슨 상관인가? 함께 해결 방법을 찾자. 하지만 그 지점을 지났다. 너무 늦었다. 이 대화는 이미 했다. 그 때도 듣지 않았는데 지금이라고 들을까? 이제 배는 침몰할 일만 남았다.

5. 인도와 실패
오바마케어 웹사이트를 기억하는가? 제대로 되지 않을 것임을 알고도 사이트를 출범해야 했던 사람들을 기억하는가? 필자는 어떻게 될지 궁금하지 않았다. 필자는 모든 사람이 실패할 것임을 알고도 시키는 대로 할 수밖에 없었던 프로젝트에 여러 번 참여했었다.

다행히도 대부분의 실패하는 프로젝트는 실패한 상태로 인도되기보다는 중간에 자금이 끊기거나 취소되거나 우선 순위에서 뒤로 밀리게 된다.

6. 안도
실패한 프로젝트 이후 대부분의 사람들은 당초 자신이 예상했던 것만큼 심한 우울함을 느끼지는 않는다. 웬만한 규모의 프로젝트에서는 프로젝트 진행 과정에서 우울함과 근심, 걱정을 이미 경험하므로, 실제로 프로젝트가 실패해서 거기서 벗어난 상태에서는 더 이상 그런 감정을 느끼지 않게 되는 것이다. 이상하지만 이 때의 느낌은 일종의 안도감이다.

7. 인식
프로젝트 실패는 대체로 하향식으로 발생한다. 근본적인 원인을 보면 거의 항상 소통의 부재, 그리고 팀원들의 기본적인 존중심 결여가 뒤섞여 있다. 경영진으로서는 또 다른 재앙을 방지하기 위해서는 이러한 징후를 인식하는 것이 중요하지만, 프로젝트에 참여하는 사람들이 경영진에게 (대화를 위해) 다가갈 수 없다고 느끼면 실패는 다시 반복된다. 차이를 이끌어낼 수 있는 위치에 있는 사람들 중에서는 무엇을 고쳐야 하는지 아는 사람이 없기 때문이다. editor@itworld.co.kr


X