프로젝트 설계자

책상에서 책장으로 옮겨져 있기만 하던 책이었는데, 우연이 손이 가서 읽기 시작했는데 무척 재미있게 읽었다. 사실 사람 때문에 읽고 싶지 않았지만, 책이 문제는 아니라는 생각에 읽기 시작했는데, 매우 재미있는 책이다. 특히 사례 중심으로 이야기가 전계되는 책이 사실감이 뛰어나기 때문에 착착 감기는 맛도 있다.

책의 대규모 프로젝트가 실패하는 이유와 극복 방안을 이야기한다. 사실 개발 프로젝트도 다르지 않은게 대부분 프로젝트가 실제와는 다른 형국으로 벌어져 100% 만족하며 끝내는 경우가 많지 않다. 책에서도 망하는 프로젝트의 유형으로 대규모 IT 프로젝트도 한 축에 포함된다. 책에서 이야기한 극복 방안이 현실, 특히 국내 현실에서 대입 가능한가? 라는 질문을 해보면 국내 환경을 고려하면 쉽지 않지만 시도해볼만한 가치는 있다. 누구도 몇백억 자금이 투입될(된) 프로젝트가 망하길 원하지는 않으니 말이다. 아래 글들은 책의 문구 가운데 새길만하다라는 내용들을 발췌한 내용이다.

건축은 냉동보관된 음악, 기술은 냉동보관된 경험

전반에서 경험의 중요성을 강조한다. 특히 프로젝트를 진행하는 입장에서 각각의 프로젝트는 “다른” 프로젝트이지만, 다른 프로젝트를 같은 유형으로 묶을 수 있는 기술은 “경험”이라는 점이다. 유형화를 할 수 있다면 예측과 실패 혹은 리스크를 사전에 진단하고 이를 예방할 수 있기 때문이다.

엑스페리리 = 실험 + 경험, 아리스토텔리스의 실천적 지혜 -> 경험으로 얻는 지식이고 느낌으로만 알 수 있는. 실험이 큰 효과를 발휘하는 순간은 “드물고 희귀한 유형의 프로젝트를 진행할 때”이다. 끝없는 실험을 통해 경험의 적자를 흑자로 전환시켜야 성공 가능성을 높일 수 있다.

프로젝트를 기획과 실행 두가지 측면에서 다룬다. 실행 단계에서 문제가 인지되면 만회 비용이 상상 이상으로 커지기 때문에 기획 단계에서 리스크를 인지하고 이를 감안한 예측을 수립하는 것의 중요성에 대해 이야기한다. 나름 맞는 예측을 하기 위해 반드시 필요한 것이 실험과 경험임을 강조한다. 경험이 통찰이라고 할 때, 실험은 부족한 경험을 메울 수 있는 최선안이 될 수 밖에 없다. 실행을 예측할 수 없는데 비용을 예측하는 것도 어불성설임에도 최저가 입찰을 하는 국내 SI 프로젝트의 현실이 대비된다.

앵커링(Anchoring)과 조정, 심리적으로 고정된 판단. 실행 지연 상황에서 실행 과정에서만 문제를 찾으려 해봐야 소용없다. 실제 문제의 근원은 기획과 예측에 있는 상황임에도 실행 단계에서 해결책을 찾으면 문제 자체를 “과소 평가”하는 상황에 직면한다. 일정이 지연되고 비용이 초과했다는 것은 “특정한 기준점”과 비교했을 때인데, 과연 그 기준점은 합리적으로 설정됐을까?

유사한 프로젝트 경험이 없거나 유사 프로젝트들에 대한 데이터가 없는 상황에서 단순히 우리 프로젝트는 달라! 라는 “다르다는 경험”에 따라 의사 결정이 이뤄지는 경우가 허다하다. 돌이켜보면 개인적으로도 이런 경우가 많았다. 그리고 다르기 때문에 이런 경우가 발생할 수 있다라는 일정의 자기 항변을 하면서 일정 지연, 예산 초과에 대한 당위성을 이야기하기도 하고. “마일스톤”을 수립하라는 이야기를 하고 있지만, 앞서 이야기한 이런 전제가 깔렸을 때 마일스톤 자체가 합당한지 교차 검증을 했는지… 반성하게 된다.

One of those, 특수성 편향, Unknown unknowns(도널드 럼스펠드)

내 프로젝트가 특별한게(다른게) 아니라 다른 유형의 프로젝트와 유사한 것 가운데 하나로 설정할 수 있어야 한다. 그래야 프로젝트를 외부적 혹은 객관점 관점에서 바라볼 수 있다. One of those가 동작하지 않으면 내부적 관점에 의해 의사 결정이 이뤄지는, 즉 “이 프로젝트는 달라!” 라는 특수성 편향에 빠진다.

“천천히 생각하고 빠르게 행동하기“는 시간이라는 이름의 창문으로 블랙스완이 날아들 여지를 줄이는 것. 수행 단계 초반부의 지연은 전체 수행 과정에 대한 Chain Reaction을 유발시킨다. 대수롭지 않게 생각한 수행 초반의 지연이 결국 블랙스완으로 돌아온다.

MVP 중심의 Iteration을 돌린다고 하더라도 초반부에 쉽게 생각해서 미루는 경우가 종종 있었다. 물론 사전에 명확한 MVP 및 Milestones 수립이 필요하지만 앞으로 시간이 많이 남았으니 이건 뒤로 미뤄도 돼! 같은 안이한 생각은 버려야 한다.

특수성 편향의 극복 -> 확신이 아니라 확률의 문제, 즉 데이터 관점으로 전환. 생존자 편향의 오류, 낙관주의적 편향, 모든 사람들은 영웅의 이야기를 좋아한다.

사람이 갖는 가장 일반적인 편향이 낙관주의적 편향이 아닐까 싶다. 잘 될거야… 세상은 그렇게 쉽지 않다.

프로젝트의 기획이 부실하면 관련된 삶과 일을 포함한 수많은 요소가 위기에 처한다. 기회 비용의 상실

진행 프로젝트의 다음 프로젝트가 제대로 진행되기 위해서도. 프로젝트를 진행하는 사람들이 야근하지 않고, 주말에 근무하지 않도록. 일과 삶의 균형보다도 아빠 노릇, 엄마 노릇을 못함으로써 발생하는 손실은 정말 크다. 이런 기회들을 날리지 않도록 정밀한 기획이 필요하다. 정밀한 기획이 말도 안되는 PPT 몇백장을 이야기하는게 아니라 데이터와 실험에 근거한 정밀도여야 한다.

스트레스가 창의력을 죽이는 경우 – 1) 상황이 나의 통제를 벗어난다. 2) 남들이 내 능력을 평가한다.

문제가 되는 프로젝트가 복마전으로 가는 경우는 스트레스가 일상적으로 만연하게 경우다. 불구덩이에 몸을 던지는 모습은 영화에서는 보기 좋을지 모르겠지만, 그렇게 해서 불을 잡는 영웅은 0.000001% 이다. 이미 통제를 벗어난 불길이 어디로 번질지 모르는 상황이 되버리면 상황을 알리고 도움을 요청해 재정비해야 한다. 솔직히 인정할 줄 아는 리더가 제대로 된 리더다.

적절한 사람들을 버스에 태우고, 그 사람들을 적절한 자리에 앉히기

“적절함”에 대한 상황 판단이 먼저다. 그리고 태우고 앉힌 사람들이 정말 One Team인지 확인해야 한다. 앉히고 알아서 하겠지? 설마 그런 일은 없다. 결국 상황을 대응하는 건 조직이고 그 조직의 일원으로 누군가를 태웠다면 각자가 아니라 우리가 되야 한다. One Team은 구호로 되는게 아니라 리더의 행동으로 만들어진다.

주변을 둘러보면 세상의 모든 것이 모듈화를 기반으로 한다는 사실을 알 수 있다. 우리는 무엇을 프로젝트의 기본 구성 요소, 즉 한 레고 블럭으로 정의해야 할까? 반복적으로 쌓아올려 같은 작업을 되풀이 학습하면 더 나은 결과를 거둘 수 있다.

컨테이너라는 모듈화를 통해 물류 혁신이 이뤄졌고, 엠파이어스테이트 빌딩 건설도 모듈 개념이 적용되어 기간/예산을 맞출 수 있었다. 개발도 마찬가지라고 생각한다. AI가 뜨면서 Monolithic 방식이 다시 두각하고 있지만,… 한덩어리로 모든걸 해결할 수 있다는 믿음은 버려야 한다. 모듈을 어떻게 정의할 것인가를 정말 잘 고민해야 한다. 그리고 공장과 현장을 구분해야하고 공장에서 만들것과 현장에서 조립해 할 것들이 뭔지를 명확히 봐야 제대로 효과를 얻을 수 있다.

책은 내용은 요즘 상황에서도 유효하다. 간만에 재미있게 책 읽었다.