소프트웨어 개발에 발을 담그고 있는 많은 사람들은 경력이 오래되면 여러 프로젝트를 경험하게 됩니다.
그 프로젝트 중에는 성공하는 프로젝트(나름 자기 생각에 성공한 것 같은 프로젝트 포함해서)가 있는가 하면 다시는 기억하고 싶지 않을 정도로 끔찍했던 프로젝트도 있을 것이다.
이러한 성공과 실패라는 두가지 갈림길을 나누는 것은 과연 무엇일까요?
주변의 많은 정보로부터 우리는 프로젝트가 실패하는 많은 경우를 접해 볼 수 있습니다. 그러한 정보를 기초로 이러이러하게 하면 프로젝트가 성공할 수 있다고 가르쳐주는 많은 방법론도 있습니다.
하지만 그러한 수많은 방법론 중에서도 성공률 100%를 보장하는 방법론은 없습니다.
과연 무엇이 문제인것일까요?
우리가 프로젝트를 시작하게 되면 우리는 희망에 부풀어 있습니다. 프로젝트를 시작하기 위한 기획서와 같은 문서를 들여다 보면 모든 것이 희망적입니다. 물론리스크 분석 보고서와 같은 문서가 첨부되는 경우도 있지만 많은 경우에는 이러이러한 것을 개발하면 이러이러한 수익을 얻을 수 있다는 그리고 이러이러한 제품은 아직 누구도 개발해 보지 못한 것이고 사용자가 정말 원하는 제품이기 때문에 개발만 한다면 대박이라는 그런 핑크빛 희망으로만 가득차 있습니다.
실제로 기획 단계에서 최악의 상황을 고민하거나 정말로 우리가 개발하는 제품이 상품성이 있는 것인지에 대한 진지한 고민은 찾아보기 힘듭니다.
그렇게 모두들 커다란 꿈을 가지고 핑크빛 미래와 거대한 인센티브를 바라면서 개발에 착수합니다.
하지만 그러한 희망은 얼마 지나지 않아 무참히 삐그덕 거리기 시작합니다. 어디서부터 무엇이 잘못되었는지 알지도 못한채 프로젝트는 여기저기서 비명을 지르기 시작합니다.
예산 초과, 개발 기간 초과는 다반사요.. 어떤 경우는 핵심 개발자가 하루 아침에 사라지기도 합니다.
어제까지 멀쩡하던 개발 서버가 하루 아침에 모든 데이터를 맛있게 먹어버리고 복구조차 못하는 경우도 있습니다.
무엇인지 모르지만 잘못되어 가고 있고, 계속되는 야근과 철야에 프로젝트에 참여한 모든 사람은 지쳐갑니다.
미래에 대한 예측은 점점 불투명해지면서 사람들은 점점 공포에 휩싸입니다.
불확실성은 존재 그 자체가 우리의 판단력을 마비시킵니다. 프로젝트 전반에 걸쳐 불확실성이 커질 수록 사람들은 점점 더 큰 공포에 휩싸이고 점점 판단력을 잃어 갑니다.
그러한 감정은좌절, 포기와 같은 여러 유형으로 나타나기도 합니다.
예를 들어 어떤 경우에는 공포라는 감정을 넘어 분노라는 감정을 표출하기도 합니다. 일반적으로 우리는 화가 나면 우리 자신이 항상 옳다고 확신하는 경향이 있습니다. 즉, 분노는 판단을 더욱 확신하게 하는 부차적인 영향이 있습니다. 이러한 것은 불확정성이 큰 상황에서 유용할 수도 있지만 과연 그 판단이 옳은 판단인지 옳지 않은 판단인지에 대한 이성적인 판단을 내리는 경우는 많지 않습니다.
분노는 오히려 프로젝트가 자멸하는 원인이 될 확률이 더 높습니다.
다른 경우에는 자신들이 그러한 상황에 이르게 되었다는 사실에 대해 놀라움을 표출하기도 합니다. 놀라움은 우리의 추측 기제가 실패했을 때 그것을 다시 수리할 수 있도록 우리의 관심을 자극할 수 있습니다. 하지만 대부분의 경우는 얼마 지나지 않아 좌절하고 포기하는 경우가 많습니다.
그래서 우리 주변의 많은 사람들이 복지부동하거나, 그건 원래 그랬어.. 라는 말로 자책 하는 경우를 많이 볼 수 있습니다.
분명 감정은 중요한 상황에 대처할 수 있도록 도움을 줄 수 있습니다.
하지만 감정은 이성을 마비시키고 우리를 잘못된 길로 인도할 확률이 높습니다. 감정과 이성은 아주 잘 조화되어야 할 필요가 있습니다. 그렇지만 감정은 전염성이 매운 큰 바이러스와 같습니다. 프로젝트를 구성하는 누군가로부터 시작된 공포는 다른 구성원이 이성적인 판단을 내리기 전에 빠른 속도록 프로젝트 안에 퍼져나갑니다. 만약 그러한 공포가 팀장과 같은 위에서 시작된다면 이 전염은 막아내기 어려울정도록 빠른 속도로 퍼져나갑니다.
그렇다면 프로젝트에서 공포라는 감정이 생기는 이유는 무엇일까요? 과연 이 공포는 어디서 시작된것일까요?
여러가지 원인을 생각해 볼 수 있지만 가장 큰 원인은 바로 정보의 소통에 있습니다.
프로젝트에 소속된 구성원간의 정보의 흐름이 원할하지 못하거나 막혀 있다면 바로 그 부분에서 공포가 시작됩니다.
우리가 프로젝트 안에서 겪고 있는 공포는 사실 존재하지 않을 수도 있습니다. 아무런 근거 없는 소문 하나가 전체 프로젝트를 공포로 몰아넣을 수도 있습니다.
확인 할 수 없는 정보 하나가 전체 프로젝트를 공포로 몰아넣을 수도 있습니다.
아래사람들은 모르게 위에서 결정되는 많은 것들은 프로젝트를 근간부터 뒤흔들어버릴 수도 있습니다.
중요한 것은 흐름입니다. 프로젝트에서 생산되고 소비되는 모든 것들은 막힘없이 모든 구성원에게 흘러다닐 수 있어야 합니다.
예를 들어 갑작스럽게 출시 기한이 앞당겨진다면 왜 그러한 일이 발생되었는지 모든 사람이 알 수 있어야 합니다.
결함이 발생한다면 왜 그런 결함이 발생되었는지 모든 사람에게 공유되어야 합니다.
하지만 실패하는 많은 프로젝트는 대체로 투명하지가 않습니다. 바깥에서 바라본 실패하는 프로젝트는 그 안을 볼 수 없는 블랙박스와 같습니다. 그 안에서 무슨 일이 일어나는지 알 수 없고 언제나 결과만을 가지고 그 원인에 대해 추측해야 합니다. 그렇지만 이러한 유추, 반추는 각 구성원마다 다릅니다. 이러한 차이는 결국 신뢰를 손상하게 하고 그러한 것들은 공포를 일으킵니다.
그리고 그러한 공포는 전염되고 증폭됩니다.
애자일 개발 방법론의 가장 뛰어난 점을 꼽는다면 전 정보방열판이나 일일 미팅과 같은 정보의 흐름을 투명하게 하려는 노력으로 꼽고 싶습니다.
모든 사람이 모든 것을 잘할 수는 없습니다. 자기가 무엇이 부족하고 그 부족한 부분을 누가 채워줄 수 있는지 정확히 인식하고 그러한 정보가 막힘없이 소통될 수 있다면 성공하는 프로젝트는 더 많아질 것이라고 생각합니다.
그리고 만약 우리가 프로젝트 안에서 공포라는 감정을 느꼈다면 그것을 바로 공유해야 합니다. 자신의 그 감정이 주변에 퍼지고 모든 사람의 이성을 마비하기 전에 반드시 공유되어야 합니다.
위기, 불확실성은 공개되는 순간 더 이상 위기나 불확실한 문제가 되지 않습니다. 그것은 해결할 수 있는 도전 과제가 되는 것입니다.
결론적으로 우리는 공포의 시대에 살고 있습니다.
분명 우리의 주변에는 엄청나게 많은 정보가 유통되고 있는 것은 현실입니다. 하지만 그 정보가 투명하고 잘 흐르고 있는가는 별개의 문제입니다.
그리고 흘러다니는 정보의 신뢰도 문제입니다. 어떤 정보를 믿을 수 있는 정보인지 믿을 수 없는 정보인지에 대한 기준도 명확하지 않습니다.
투명하고 믿을 수 있는 정보의 흐름을 만드시기 바랍니다. 가장 중요한 것은 흐름입니다.
흐르지 않고 고인 물이나 공기는 썩어 버리듯이 흐르지 않는 정보 역시 썩게 되어 있습니다.
팀과 조직 안에 아무리 많은 정보를 가지고 있는 사람이 있더라도 그 정보가 흐르지 못하고 있다면 그 것은 아무런 소용이 없는 쓰레기나 마찬가지입니다.
흐름을 만드시기 바랍니다. 필요하다면 시스템적으로 강제적으로 만들 필요가 있습니다.
흐름을 만드셨다면 제약을 찾으시기 바랍니다.
잘 흐르지 못하는 곳이 있는지 막혀 있는 곳이 있는지 끊임없이 검토하고 또 검토해야 합니다.
일반적으로 우리는 전체를 바라볼때 선택과 집중에서 강점을 더 강하게 하라고 말합니다.
하지만 강한 곳이 더 강해질 수록 약한 곳은 더 약해집니다. 만약 그 약한 곳을 누군가 공격하게 된다면 아무리 멋있고 강하고 좋아 보이는 조직도 하루 아침에 사라질 수 있습니다.
다윗과 골리앗의 싸움이 우리에게 말해주고 있는 진실이며, 아이폰와 옴니아 2의 싸움이 우리에게 가르쳐 주고 있는 교훈입니다.
선택하고 집중해야 할 곳은 가장 약한 곳입니다. 가장 투명하지 못하고 가장 약한 정보의 흐름부터 강하게 해주어야 합니다.
허구헌날 생기지도 않은 매출이 생긴것처럼 뻥튀기하며 분식회계나 일삼는 회계팀이 될 수도 있고, 자기만 아는 개발 소스로 다른 사람을 괴롭히는 개발팀이 될 수도 있습니다. 엉터리 사용자 조사로 경영진을 기만하는 기획부서가 될 수도 있습니다.
어느 곳이 되었든 투명하지 못한 곳부터 투명하게 할 필요가 있습니다.
여러분은 어떠신가요?
그 프로젝트 중에는 성공하는 프로젝트(나름 자기 생각에 성공한 것 같은 프로젝트 포함해서)가 있는가 하면 다시는 기억하고 싶지 않을 정도로 끔찍했던 프로젝트도 있을 것이다.
이러한 성공과 실패라는 두가지 갈림길을 나누는 것은 과연 무엇일까요?
주변의 많은 정보로부터 우리는 프로젝트가 실패하는 많은 경우를 접해 볼 수 있습니다. 그러한 정보를 기초로 이러이러하게 하면 프로젝트가 성공할 수 있다고 가르쳐주는 많은 방법론도 있습니다.
하지만 그러한 수많은 방법론 중에서도 성공률 100%를 보장하는 방법론은 없습니다.
과연 무엇이 문제인것일까요?
우리가 프로젝트를 시작하게 되면 우리는 희망에 부풀어 있습니다. 프로젝트를 시작하기 위한 기획서와 같은 문서를 들여다 보면 모든 것이 희망적입니다. 물론리스크 분석 보고서와 같은 문서가 첨부되는 경우도 있지만 많은 경우에는 이러이러한 것을 개발하면 이러이러한 수익을 얻을 수 있다는 그리고 이러이러한 제품은 아직 누구도 개발해 보지 못한 것이고 사용자가 정말 원하는 제품이기 때문에 개발만 한다면 대박이라는 그런 핑크빛 희망으로만 가득차 있습니다.
실제로 기획 단계에서 최악의 상황을 고민하거나 정말로 우리가 개발하는 제품이 상품성이 있는 것인지에 대한 진지한 고민은 찾아보기 힘듭니다.
그렇게 모두들 커다란 꿈을 가지고 핑크빛 미래와 거대한 인센티브를 바라면서 개발에 착수합니다.
하지만 그러한 희망은 얼마 지나지 않아 무참히 삐그덕 거리기 시작합니다. 어디서부터 무엇이 잘못되었는지 알지도 못한채 프로젝트는 여기저기서 비명을 지르기 시작합니다.
예산 초과, 개발 기간 초과는 다반사요.. 어떤 경우는 핵심 개발자가 하루 아침에 사라지기도 합니다.
어제까지 멀쩡하던 개발 서버가 하루 아침에 모든 데이터를 맛있게 먹어버리고 복구조차 못하는 경우도 있습니다.
무엇인지 모르지만 잘못되어 가고 있고, 계속되는 야근과 철야에 프로젝트에 참여한 모든 사람은 지쳐갑니다.
미래에 대한 예측은 점점 불투명해지면서 사람들은 점점 공포에 휩싸입니다.
불확실성은 존재 그 자체가 우리의 판단력을 마비시킵니다. 프로젝트 전반에 걸쳐 불확실성이 커질 수록 사람들은 점점 더 큰 공포에 휩싸이고 점점 판단력을 잃어 갑니다.
그러한 감정은좌절, 포기와 같은 여러 유형으로 나타나기도 합니다.
예를 들어 어떤 경우에는 공포라는 감정을 넘어 분노라는 감정을 표출하기도 합니다. 일반적으로 우리는 화가 나면 우리 자신이 항상 옳다고 확신하는 경향이 있습니다. 즉, 분노는 판단을 더욱 확신하게 하는 부차적인 영향이 있습니다. 이러한 것은 불확정성이 큰 상황에서 유용할 수도 있지만 과연 그 판단이 옳은 판단인지 옳지 않은 판단인지에 대한 이성적인 판단을 내리는 경우는 많지 않습니다.
분노는 오히려 프로젝트가 자멸하는 원인이 될 확률이 더 높습니다.
다른 경우에는 자신들이 그러한 상황에 이르게 되었다는 사실에 대해 놀라움을 표출하기도 합니다. 놀라움은 우리의 추측 기제가 실패했을 때 그것을 다시 수리할 수 있도록 우리의 관심을 자극할 수 있습니다. 하지만 대부분의 경우는 얼마 지나지 않아 좌절하고 포기하는 경우가 많습니다.
그래서 우리 주변의 많은 사람들이 복지부동하거나, 그건 원래 그랬어.. 라는 말로 자책 하는 경우를 많이 볼 수 있습니다.
분명 감정은 중요한 상황에 대처할 수 있도록 도움을 줄 수 있습니다.
하지만 감정은 이성을 마비시키고 우리를 잘못된 길로 인도할 확률이 높습니다. 감정과 이성은 아주 잘 조화되어야 할 필요가 있습니다. 그렇지만 감정은 전염성이 매운 큰 바이러스와 같습니다. 프로젝트를 구성하는 누군가로부터 시작된 공포는 다른 구성원이 이성적인 판단을 내리기 전에 빠른 속도록 프로젝트 안에 퍼져나갑니다. 만약 그러한 공포가 팀장과 같은 위에서 시작된다면 이 전염은 막아내기 어려울정도록 빠른 속도로 퍼져나갑니다.
그렇다면 프로젝트에서 공포라는 감정이 생기는 이유는 무엇일까요? 과연 이 공포는 어디서 시작된것일까요?
여러가지 원인을 생각해 볼 수 있지만 가장 큰 원인은 바로 정보의 소통에 있습니다.
프로젝트에 소속된 구성원간의 정보의 흐름이 원할하지 못하거나 막혀 있다면 바로 그 부분에서 공포가 시작됩니다.
우리가 프로젝트 안에서 겪고 있는 공포는 사실 존재하지 않을 수도 있습니다. 아무런 근거 없는 소문 하나가 전체 프로젝트를 공포로 몰아넣을 수도 있습니다.
확인 할 수 없는 정보 하나가 전체 프로젝트를 공포로 몰아넣을 수도 있습니다.
아래사람들은 모르게 위에서 결정되는 많은 것들은 프로젝트를 근간부터 뒤흔들어버릴 수도 있습니다.
중요한 것은 흐름입니다. 프로젝트에서 생산되고 소비되는 모든 것들은 막힘없이 모든 구성원에게 흘러다닐 수 있어야 합니다.
예를 들어 갑작스럽게 출시 기한이 앞당겨진다면 왜 그러한 일이 발생되었는지 모든 사람이 알 수 있어야 합니다.
결함이 발생한다면 왜 그런 결함이 발생되었는지 모든 사람에게 공유되어야 합니다.
하지만 실패하는 많은 프로젝트는 대체로 투명하지가 않습니다. 바깥에서 바라본 실패하는 프로젝트는 그 안을 볼 수 없는 블랙박스와 같습니다. 그 안에서 무슨 일이 일어나는지 알 수 없고 언제나 결과만을 가지고 그 원인에 대해 추측해야 합니다. 그렇지만 이러한 유추, 반추는 각 구성원마다 다릅니다. 이러한 차이는 결국 신뢰를 손상하게 하고 그러한 것들은 공포를 일으킵니다.
그리고 그러한 공포는 전염되고 증폭됩니다.
애자일 개발 방법론의 가장 뛰어난 점을 꼽는다면 전 정보방열판이나 일일 미팅과 같은 정보의 흐름을 투명하게 하려는 노력으로 꼽고 싶습니다.
모든 사람이 모든 것을 잘할 수는 없습니다. 자기가 무엇이 부족하고 그 부족한 부분을 누가 채워줄 수 있는지 정확히 인식하고 그러한 정보가 막힘없이 소통될 수 있다면 성공하는 프로젝트는 더 많아질 것이라고 생각합니다.
그리고 만약 우리가 프로젝트 안에서 공포라는 감정을 느꼈다면 그것을 바로 공유해야 합니다. 자신의 그 감정이 주변에 퍼지고 모든 사람의 이성을 마비하기 전에 반드시 공유되어야 합니다.
위기, 불확실성은 공개되는 순간 더 이상 위기나 불확실한 문제가 되지 않습니다. 그것은 해결할 수 있는 도전 과제가 되는 것입니다.
결론적으로 우리는 공포의 시대에 살고 있습니다.
분명 우리의 주변에는 엄청나게 많은 정보가 유통되고 있는 것은 현실입니다. 하지만 그 정보가 투명하고 잘 흐르고 있는가는 별개의 문제입니다.
그리고 흘러다니는 정보의 신뢰도 문제입니다. 어떤 정보를 믿을 수 있는 정보인지 믿을 수 없는 정보인지에 대한 기준도 명확하지 않습니다.
투명하고 믿을 수 있는 정보의 흐름을 만드시기 바랍니다. 가장 중요한 것은 흐름입니다.
흐르지 않고 고인 물이나 공기는 썩어 버리듯이 흐르지 않는 정보 역시 썩게 되어 있습니다.
팀과 조직 안에 아무리 많은 정보를 가지고 있는 사람이 있더라도 그 정보가 흐르지 못하고 있다면 그 것은 아무런 소용이 없는 쓰레기나 마찬가지입니다.
흐름을 만드시기 바랍니다. 필요하다면 시스템적으로 강제적으로 만들 필요가 있습니다.
흐름을 만드셨다면 제약을 찾으시기 바랍니다.
잘 흐르지 못하는 곳이 있는지 막혀 있는 곳이 있는지 끊임없이 검토하고 또 검토해야 합니다.
일반적으로 우리는 전체를 바라볼때 선택과 집중에서 강점을 더 강하게 하라고 말합니다.
하지만 강한 곳이 더 강해질 수록 약한 곳은 더 약해집니다. 만약 그 약한 곳을 누군가 공격하게 된다면 아무리 멋있고 강하고 좋아 보이는 조직도 하루 아침에 사라질 수 있습니다.
다윗과 골리앗의 싸움이 우리에게 말해주고 있는 진실이며, 아이폰와 옴니아 2의 싸움이 우리에게 가르쳐 주고 있는 교훈입니다.
선택하고 집중해야 할 곳은 가장 약한 곳입니다. 가장 투명하지 못하고 가장 약한 정보의 흐름부터 강하게 해주어야 합니다.
허구헌날 생기지도 않은 매출이 생긴것처럼 뻥튀기하며 분식회계나 일삼는 회계팀이 될 수도 있고, 자기만 아는 개발 소스로 다른 사람을 괴롭히는 개발팀이 될 수도 있습니다. 엉터리 사용자 조사로 경영진을 기만하는 기획부서가 될 수도 있습니다.
어느 곳이 되었든 투명하지 못한 곳부터 투명하게 할 필요가 있습니다.
- 어느 곳도 막히지 않는 정보의 흐름을 구축한다.
- 정보의 흐름이 혼탁해지지 않도록 가장 불투명한 곳부터 가장 투명하게 만든다.
여러분은 어떠신가요?
댓글
댓글 쓰기