2013년 11월 2일

감정은 거리에 비례하여 전이된다.

지하철을 타다 보면 젊은 사람과 나이 든 사람이 실랑이를 하는 광경을 목격하기도 한다.
그러다 보면 서로 감정적인 말들이 오가고 한쪽에서는 예의가 없는 듯한 태도를 목격하기도 하고, 다른 한쪽에서는 권위가 들어간 목소리로 훈계를 하는 듯한 모습을 만들어내기도 한다.

지하철이라는 공간은 현대인에게 있어서 누구나 한번은 겪어야 하는 공유 공간으로 되어버렸다. 그 지하철이라는 것은 서로의 공간을 같이 점유하고 듣기 싫어도 보기 싫어도 어쩔 수 없이 상대의 목소리를 듣거나 모습을 보아야 하는 공유 공간이 되었다.

그러다 보니, 지하철 내에서 어느 한사람의 감정은 곧 그 지하철 한칸의 모든 사람의 감정으로 전이가 빨리 된다. 어느 한 노인이 젊은 사람 앞에 두고 역정을 내는 감정은 바로 옆 사람들에게 전달되고 이를 바라보는 사람들은 젊은이에게 잘못을 했다라고 느끼는 측과 나이든 사람이 좀 더 부드럽게 타이르는게 어땠을까라는 공공 공간에서의 과도한 감정 도출에 대한 분노를 느끼는 측으로 나뉠 수도 있다.

복잡한 지하철

지하철이라는 좁은 공간에서 이루어지는 감정 전이는 너무나도 빠르다. 서로의 숨소리를 듣거나 말소리마저 들을 수 있고, 심지어 자는 모습도 고스란히 전달될 수 있는 공간이다. 즉, 어느 한편의 감정은 바로 전달되고, 그러한 감정을 받아들이는 측은 다양한 반응과 태도를 가지게 된다.

얼마전 프로젝트에서도 이와 비슷한 상황이 발생되기도 했다. 프로젝트시 어떠한 내부 구조를 가지고 작업을 수행하는지가 서로의 감정을 쉽게 전달되거나 혹은 감정을 차단할 수도 있다. 서로 독립적인 사무실이나 책상의 구조를 지닌 형태에서는 감정을 그때 그때 전달하기가 쉽지 않기에 다소 생각할 수 있는 시간이나 감정을 추스를 수 있는 여유를 가지게 된다. 하지만, 바로 옆이나 앞에서 숨소리를 들을 만큼 지근 거리에 위치한 프로젝트 구조에서는 감정이 빨리 전달되고 이입된다.

물론, 감정이입이 빠른 지근 거리에 위치한 형태가 나쁜 것만은 아니다. 기쁘거나 좋은 일들의 전이는 바로 프로젝트 전체에 영향을 주어서 좀 더 일을 하는데 활력소를 주기도 한다. 이런 경우에는 아무리 어려운 일이라도 해낼 수 있는 자신감과 일을 완성하는 기쁨을 공유할 수도 있다.

타인과 자신이 해당 공간을 어떻게 점유하느냐가 감정 전달에 영향을 미치며 이는 곧 일을 하는 데에 영향을 미치게 마련이다. 신경질적인 타자 소리는 누군가에는 귀에 거슬리는 소리로 변해 프로그래밍하는데 즐거운 감정을 유지해야 함에도 불구하고 집중을 하지 못하는 상태가 될 수도 있다.

감정이 거리에 비례하여 전이되고 전이된 감정은 모든 사람들에게 공통된 분위기를 만들어낸다. 또한, 감정을 전달하는 사람이 충분히 그러한 감정을 만드는 원인에 대해 이해를 시키지 못한 상태에서 잔달되는 감정은 오해나 잘못된 감정을 낳을 수도 있으며 공유 공간에서 전이되는 감정으로 인해서 작업에 미치는 영향은 커질 수도 있다.

현대인에게 발생되는 스트레스나 감정의 기복은 어찌보면 이러한 공유된 공간에서 서로의 감정 전달을 어떻게 이해하고 받아들이느냐에 따라 달라진다고 볼 수 있다. SW 개발 프로젝트에서 이러한 감정을 전달하는 사람들과 같이 어떠한 방식으로 일을 하느냐에 따라 그 결과가 달라진다고 보면 감정을 전달하는 거리를 적절하게 유지하는 것도 하나의 기법일 것이다. 혹은 전달되는 감정을 어떻게 대응할 것인가 역시 하니의 기법이 될 수 있다.

Advertisements
2013년 9월 5일

완벽한 설계 – 영화와 같은 이야기

영화 전문가가 아니더라도 볼 만한 영화들은 스토리 구성이 나름대로 탄탄하다는 공통점이 있다. 특히, 반전에 반전을 거듭하며 손에 땀을 쥐게 만드는 요소들이 적절한 시점에 들어가준다면 더 볼 만하다. 게다가, 영화의 대부분의 줄거리를 차지하는 내용들이 이미 주인공이 짜놓은 미리 계획된 내용이라는 반전은 주인공의 매력과 같이 영화에서 한동안 빠져나올 수 없는 여운을 주기도 한다.

나우 유 시미

영화에서는 반전이라는 요소를 넣으려다 보니, 남을 속이는 내용으로 구성된 도둑이나 사기꾼 이야기가 적절한 소재가 되기도 한다. ‘나우 유 씨 미(Now you see me)’ 와 같은 영화는 얼마전에 많은 관객을 모았던 ‘도둑들’이나 더 오래전의 ‘이탈리안 잡(The Italian Job)’과 같이 잘 만들어진(짜여진) 각본에 각 분야의 전문가들이 제 역할을 제대로 수행하고 최고의 결과를 얻는 도둑들에 대한 이야기들이다.

이러한 영화들은 늘 마지막에 모든 계획과 설계를 주도했던 인물에 의해서 다시 한번 반전을 거듭하기도 하는데, 중간에 그러한 의도나 설계에 대한 설명을 누군가의 입이나 혹은 그렇게 되었을 수 밖에 없다는 인과 관계를 다시 한번 리마인드 시켜주기도 한다.

주인공이 만들어 놓은 계획이나 설계는 실제로 실행될 때 한치의 오차도 없이 (물론, 중간 중간에 약간의 어긋나는 긴장감을 주기도 하지만 대부분이 또 다른 계획 변경이나 수정으로 인해 결국 최초에 의도(설계)했던 지점으로 다시 되돌아 오기는 한다) 그대로 진행이 된다.

SW를 만들면서 수많은 계획과 설계들을 했지만, 그리고 매번 그러한 계획과 설계들을 하면서 고객으로 요구받은 내용들은 마치 이러한 영화와 같이 잘 짜여진 것들을 원했지만 결국 그러한 내용들은 모두 영화같은 이야기에 너무나 빠져있는 것은 아닌가 하는 회의를 느끼게도 만든다.

그렇다고 계획이나 설계가 필요없다라는 것은 아니다. 계획이나 설계는 하나의 과정으로써 의미가 있는 것이며 그러한 과정을 거쳐서 체득된 경험이야 말로 상당히 중요한 지식이기도 하다. 현실에서 이러한 영화와 같은 일들을 계획하려고 한다면 그러한 계획이나 설계를 하는 사람은 분명 수많은 관찰과 측정을 시도했으리라 본다. 예를 들어, 여러명의 전문적인 사람들이 은행을 터는 계획을 만든다면, 그 사람은 그 은행의 모든 시설물들의 위치와 규격에서부터 사소한 것까지 관찰과 탐구를 시도했을 것이다. 그리고 결코 그러한 시간이 짧은 시간은 아니었을 것이다. 거기에다가 팀원들의 특성들까지 파악해서 어느 시점에 어떤 일을 하라는 것까지 계획하려면 이는 한 사람의 머리에 의존하기란 불가능하지 않을까.

결국 영화이기 때문에 이러한 일이 가능한 것이고, 현실에서는 이러한 것을 기대하기는 힘들 것이다. 만일 그러한 것을 기대한다면 이는 그 사람이 수년 혹은 수십년 동안의 수많은 시행착오를 겪어오면서 쌓여진 경험과 지식의 결과일 것이리라. 현실은 매번의 프로젝트에서 영화와 같은 이야기들을 원한다는 느낌을 지울 수 없다. 어쩌면 나 자신도 그러한 환경에서 영화와 같은 이야기가 현실이 될 수 있다는 환상을 가지고 있는지도 모른다.

소프트웨어로 만드는데 있어서 완벽한 계획이나 설계는 영화와 같은 이야기라고 생각이 든다. 완벽함을 추구하면 추구할수록 오히려 더 잘못된 계획이나 설계가 나타날 가능성이 많을 것이다. 늘 가정이란 수많은 생략과 추상성을 내포하고 있기 때문이다. 완벽하지 못하기 때문에 결과가 잘못되었다는 것은 너무나 많은 인과관계를 생략해버린 성급한 결론이기도 하다. 어찌보면 소프트웨어에 사람을 맞출 수 있다는 가정에서부터 출발했기 때문일 수도 있다. 사람에 맞는 소프트웨어를 만드는게 제일이어야 하며, 이는 사람의 행위를 예측할 수 있어야 하지만 이러한 예측은 늘 빗나가고 계획이나 설계를 하기 힘들기 때문이다.

결국 가장 손쉬운 방법인 만들어진 소프트웨어에 사람을 맞추는 방식을 택함으로써 그러한 힘든 노력을 최대한 줄일 수 있는 방법을 택했을 수도 있다. 사람을 중심으로 생각한다면 늘 계획과 설계는 완벽하지 못한 채로 출발하고 소프트웨어가 보이는 시점에 완성이 같이 되어가는 모습일 것이다.

설계를 할 수 있는 개발자를 구하기 힘들기 보다는 설계하는 방법을 아는 개발자를 구하기 힘들다는 표현이 더욱 맞을 것이다. 그리고, 설계하는 방법을 안다는 것은 사람 중심의 소프트웨어를 만들 수 있는 능력을 갖추었다라는 것을 의미할 것이다. 애자일의 원리 중에 제일 우선순위가 높은 가치있는 결과물로 고객을 만족시킨다는 내용이 이러한 의미에서 소프트웨어를 만드는 입장에서 가장 고려해봐야 하는 가치이기도 하다.

2013년 3월 17일

품질이 문제있는 작업일수록 오래 걸린다.

대기(queue) 이론에서 Little의 법칙에서 ‘일정 시스템에 오랜 시간 동안 머물러 있는 고객의 평균적인 수치는 오랜 시간 동안에 걸친 평균 실제 도착율과 시스템에서 고객이 머문 평균 시간을 곱한 값과 동일하다’라는 내용을 말하고 있다. 직관적인 이론이기는 하지만, SW 개발시에 이러한 법칙은 여러 형태로 실제 나타나기도 한다. 이 법칙에서는 해당 시스템에 도달하는 과정이 어떠한지에 상관없이 이러한 법칙은 적용된다는 의미이다.

출처 : http://operationsroom.files.wordpress.com/2011/12/pj-be136_lines_g_20111207183320.jpg

 (출처 : http://operationsroom.files.wordpress.com/2011/12/pj-be136_lines_g_20111207183320.jpg)

예를 들어, 요구사항 – 분석 – 설계 – 구현 – 테스트 – 릴리즈의 일련의 과정을 거치는 SW 개발 프로세스에서 각 단계는 그 단계 내에서 별도의 활동으로 수행된다고 하면 (즉, 요구사항 단계에서는 고객의 요구사항을 듣고, 다양한 이해관계자들과의 협업을 통해 시스템이 가지는 제약 내에서 시스템이 제공하는 서비스를 정의하는 형태로 개별 활동을 수행한다고 볼 수 있다.) 요구사항 단계에 머무는 작업들의 수는 요구사항 단계로 접어드는 작업의 도착율과 해당 작업이 요구사항 단계를 통해 완료라는 상태로 전이하는 동안의 시간에 비례한다고 볼 수 있다.

다시 정리하자면, 해당 단계에서 머무는 작업의 갯수는 요구사항을 통해서 수행해야 하는 작업의 식별 시간과 그 작업을 완료하는데 드는 시간에 비례한다. SW 개발에서 생산성을 나타내는 가장 좋은 방법은 수행해야 하는 작업들을 나누고 그 작업이 완료하는데 얼마나 많은 비용(혹은 공수)를 투여했는지를 계산하는 것이다.

SW 개발 생산성을 높이는 방법은 수행해야 하는 기간이 고정되어있다고 보면 각 단계들의 활동을 통해 수행하는 작업의 양을 늘려야 한다. 통상 기간이나 비용이 고정되어 있는 SW 개발에서 작업의 양을 늘리는 방법을 찾는 것은 생산성을 높이는 방법을 찾는 것과 동일하며, 이는 SW 개발시에 늘 해결해야 하는 문제이기도 하다.

Little의 법칙을 이러한 과정에 적용해보면, 특정 단계 내에 머무는 작업의 기간을 줄이는 방식을 취한다면 전체적으로 생산성은 높일 수 있다. 좀 더 자세히 살펴보면, 각 단계에서 수행해야 하는 작업의 양은 시간이 흐름에 따라서 다소 다르다. 개발 초반에는 요구사항을 식별하거나 분석 활동이 주로 많이 발생되며, 여기에 많은 노력을 투여한다. 즉, 노력을 투여하는 만큼 많은 작업들이 식별되며 각 단계에 도달하는 작업의 도착율은 상당히 짧은 편이다. 이러한 작업들은 요구사항을 분석하는 작업자가 해당 작업들에 대해 상세히 분석하는 활동을 수행하게 되며, 그러한 활동은 또 다른 활동을 필요로 한다. 예를 들어, 요구사항을 분석하여 시스템이 제공할 서비스 식별하는 작업을 완료하려면 해당 서비스가 고객이 원하는 서비스인지를 검증하는 활동을 필요로 한다. 즉, 사용자 인수 시험이나 검사가 필요한 것이다. 통상, 전통적인 개발 프로세스에서는 이러한 시험이나 검사가 테스트 단계에 발생되기 때문에 요구사항을 식별하는 작업은 테스트 단계까지 그대로 이어지게 되며, 해당 작업은 종료되지 않은 상태로 남아있게 된다.

만일, 요구사항 단계에서 구현 및 테스트, 릴리즈까지의 기간을 단축시킨다면, 해당 작업은 그만큼 머무는 시간이 줄어들게 되며, 이는 결국 SW 개발 생산성을 높이는 방법이 된다. 하나의 요구사항을 식별하여 SW로 구현까지 걸리는 시간을 줄어들게 만들수록 전체적인 개발 생산성을 높이는 효과가 나타나는 것이다.

SW개발에서 이러한 Little의 법칙을 적용한다고 하면, 개발 생산성은 요구사항에서 릴리즈까지의 걸리는 시간(반복 시간)과 품질에 비례한다고 볼 수 있다. 즉, 반복시간이 짧고 품질이 높을수록 생산성은 높아진다는 의미이다.

TDD나 A-TDD에서 테스트에 대한 강조를 하는 이유 역시 요구사항 분석을 수행하는 시점에 품질을 높이려는 활동이며 이는 궁극적으로 전체 반복 시간을 줄이려는 기법으로 볼 수 있다. 애자일이나 Scrum에서 2~4주의 반복(sprint)를 이야기하는 이유 역시 짧은 반복을 통해서 개발 생산성을 높이려는 이유이며, 4주보다 2주, 2주보다 1주의 반복이 더 나은 생산성을 기대할 수 있을 것이다.

작업이 해당 작업자에게 머무는 시간을 최소화하도록 집중한다면, SW 개발에서 더 많은 작업과 더 효과적인 생산성의 결과를 가져올 수 있다. 또한, 작업을 식별하는 시간의 간격 역시 줄어들수록 더 좋은 생산성을 기대할 수 있을 것이다. (때로는 고객의 요구사항을 정확하게 식별하지 못해서 해당 작업의 지연이 상당히 오래되는 경우가 있으며, 이는 결국 생산성에 영향을 미친다)

SW 개발에서 전반적인 생산성을 조사하려면, 얼마나 많은 작업들을 했는지와 해당 활동에서 수행한 작업들이 얼마나 걸려서 완료되었는지를 계산해야 한다. 많은 작업들을 수행했다고 하더라도 대부분이 긴 개발 기간 동안에 수행했다고 하면 품질을 다루는 활동에 대해 효과적이었는지를 살펴보아야 한다.

Little의 법칙은 한가지 조건이 있는데, 해당 활동을 수행하는 프로세스가 안정적일 때 이러한 내용들이 적용된다는 것이다. 예를 들어, 처음 조직을 세팅하거나 프로젝트 막바지와 같은 상황은 해당 개발 프로세스를 처리하는데 안정적이라고 볼 수 없기 때문에 이러한 법칙을 적용하기에는 무리이다. 즉, 일정한 생산성을 나타내는 조직에 대해서는 좀더 생산성을 높이는 방법으로 이러한 내용을 모니터링할 필요가 있다.

2012년 12월 24일

Delphi 의사결정 방식

의견을 다루는 과정은 상당히 시간이 많이 걸리는 일이다. 특히, 어떤 합의에 이르는 과정은 그 과정이 어떠한 형태를 띠는가에 따라서 의견 충돌이 발생하는 양측에게는 서로의 이점만을 생각하여 그 과정 자체에도 불신을 키울 수도 있다. 이와 같이 의견에 대한 합의를 이루는 것이 복잡한 이유는 의견의 중심에는 행동에 관한 자유라는 영역이 있기 때문이다. 즉, 어떤 개인은 의견의 문제에 관해서 자신의 마음을 정할 수 있는 자유를 갖고 있을 뿐만 아니라, 의견이 행동에 관한 것일 경우에는 ‘어떤 정책을 채택할 것인가’ 혹은 ‘어떤 행동 노선을 추구할 것인가?’에 대해 서로 의견을 달리할 권리도 갖고 있는 것이다.

의견이 합의를 이루어야 한다는 전제는 서로 다른 의견을 가진 구성원이 평화롭고 조화롭게 살기 원한다면, 그리고 특정 집단의 공통의 목표를 위해 서로 협력하기 원한다면 이성적인 의견 차이들을 해소하고 해결할 수 있는 방법이 있어야 한다는 것이다. 이러한 의견에 대한 합의를 이루는 과정 중에 민주적인 방식을 채택한 것이 다수결의 원칙인 투표가 대표적이라고 할 수 있다. 물론, 힘이나 무력을 통해서 의견을 합의할 수도 있겠지만, 인간의 존엄성을 중시한다면 이러한 방식은 고려 대상이 아니다.

이러한 의사결정 방식 중에 델파이(Delphi) 의사결정 방식을 소개하려고 한다. 특히, 애자일(agile) 진영에서는 추정(estimation)을 통해 작업을 식별할 때에 이러한 방식을 사용한다.

Delphi 방식은 1950년대 초에 RAND사에 근무하는 Olaf Helmer와 Norman Dalkey가 국방과 관련된 전문가로부터 체계적인 식견을 얻기 위해 고안한 방식이다. 그 이후에 논쟁의 여지가 있는 사회 정치적인 담론의 영역으로 확장된다. (참고 : http://scholar.lib.vt.edu/ejournals/JVTE/v15n2/custer.html)

Delphi 라는 단어는 그리스 신화에서 기인한다. Delphi는 고대 그리스 시대에서 가장 중요한 신탁이었던 델포이 신탁(Delphic Oracle) 장소였다. (아래 그림 참고)

이미지

즉, Delphi 방식은 전문가들의 브레인스토밍이라고 볼 수 있다. Delphi 의사결정 그룹에서 일련의 질문들과 설문 등이 선정된 응답자(Delphi 그룹)들에게 전문가들의 의견을 감시하는 퍼실리테이터를 통해 전달된다. 그룹은 얼굴을 맞대고 보지 못하며, 모든 의사소통은 통상 (편지나 이메일과 같은) 작성된 문서를 통해서 이루어진다. 그룹의 구성원들은 그들이 전문가이거나 관련 정보를 가지고 있기 때문에 선택된다.

각각의 전문가들의 견해의 충돌을 산정하기 위해 전문가들의 답변들이 수집되고 분석된다. 그러한 과정은 종합적인 결과를 위해 합의를 이루기 위해 계속된다.

주요 과정은 다음과 같다.

  • 멤버들이 전문적인 지식에 의해 Delphi 패널로 선정된다.
  • 이들은 각각 독립적인 장소에서 어떤 주제나 내용에 대한 특정 정보를 도출하기 위해 오픈된 질문지와 설문 등을 통해 답변을 한다. 이들을 독립적인 공간에 두는 것은 얼굴을 맞대는 토론을 통해 부정적인 영향을 피하고 집단 역학(group dynamics)와 관련된 문제를 피하려는 목적이다.
  • 멤버들은 자신들의 평가와 문제에 대한 해설을 공유하거나 해당 사안의 미래 상태를 예측하도록 요청을 받는다.
  • 퍼실리테이터(패널 사회자)는 정보를 처리하고 관련없는 내용을 필터링함으로써 참여자들 사이의 상호작용을 통제한다.
  • 응답을 수집하고, 정리한 다음에 모든 그룹 멤버들에게 다시 피드백을 준다.
  • 멤버들은 새로운 정보를 토대로 또 다른 결정을 수행한다.
  • 이러한 과정은 응답이 만족에 수렴할 때까지 (즉, 합의에 도출할 때까지) 반복된다.

이러한 과정의 성공은 멤버들의 전문지식과 커뮤니케이션 숙련도에 달려있다. 또한, 각각의 응답은 반영하고 분석하는데 적절한 시간을 요한다. Delphi 방식의 주요 장점은 다음과 같다.

  • 중간에 개입하는 문제를 없애줌
  • 전문가의 시간을 충분히 사용함
  • 아이디어에 대한 다양성 확보
  • 해결책과 예측의 정확성

애자일에서는 이러한 Delphi 방식을 추정하는데에 도입하였다. Delphi 방식이 해결책을 찾거나 예측을 하는데 있어서 합의를 이루어가는 과정이 포함하고 있기 때문에 작업을 추정하는 방식에 있어서 보다 많은 사람들과 합의를 이루는 일정을 만들 수 있다라는 아주 큰 장점을 가지게 된다.

IT 프로젝트를 수행하면서 수학이나 과학처럼 증명되어 정확한 수치를 통한 답을 내는 경우는 특수한 경우를 제외하고는 그리 많지 않다. 늘 기준이나 잣대가 변하면서 거기에 따라 프로젝트 수행 방식도 많이 바뀌게 되어 있다. Delphi 방식이 그러한 프로젝트 수행 방식에 또 다른 답을 줄 수도 있을 것이다.

플래닝포커 – 아이폰앱 (https://itunes.apple.com/kr/app/peullaeningpokeo/id487451972?mt=8)
이미지

플래닝포커 사용법 – http://methoda.vizend.com

2012년 12월 14일

나는 못생기지 않았습니다!!!

한 개그 프로그램에서 ‘나는 못생기지 않았습니다’ 라고 말을 시작하는 개그맨에서 사람들은 그의 말을 개그로 받아들인다. 사람의 얼굴을 가지고 평가하는 것은 그리 좋은 것은 아니지만, 그리 잘나지도 호감형이 아닌 얼굴을 가진 사람이 못생긴 것이 아니라, 매력이 있다든지, 새초롬하다든지와 같은 그 다음의 말을 듣고 그가 가진 얼굴의 기준에 때로는 공감과 격려를 보내기도 한다.

박지선

대부분의 프로젝트에서는 투입된 사람 만큼이나 수많은 말들이 오고 간다. 그리고, 그러한 사람의 수 만큼이나 사건이나 이벤트도 발생되기도 한다. 우리는 같은 단어로 의사소통을 하더라도 이를 전달하는 사람과 받아들이는 사람 사이에서 차이가 있는 경험을 하기도 한다. 프로젝트를 진행하는 과정은 이러한 사건과 사고들이 외부로 흘러들어가면서 어떠한 모습으로 비춰지냐에 따라서 그 프로젝트에 대한 전반적인 평가가 이루어진다.

위의 개그 프로그램처럼 ‘우리 프로젝트는 잘 진행되고 있습니다’라고 말할 때 이를 듣는 입장에서 속으로 웃는다고 생각한다면 듣는 사람은 어떠한 경로를 통해서든 그 프로젝트의 안좋은 면을 이미 알고 있다라는 것이다. 프로젝트를 경험해 본 사람들은 모든 프로젝트에서 문제가 이미 존재하고 있다라는 것을 알 것이며, 그 프로젝트의 문제를 관여된 사람들이 어떻게 풀어나가는지에 모든 눈이 보고 있다는 것을 느낄 것이다. 고객은 물론이고, 세간의 관심을 끄는 대형 프로젝트라면 관련 업계에서도 귀를 세우고 있을 것이고, 해당 사업자 내부에서는 말할 것도 없다.

프로젝트를 성공했다, 안했다의 관점이 아니라 그 프로젝트는 문제가 많다, 잘못 가고 있다라는 관점으로 보면 모든 프로젝트의 내용은 수많은 이야깃거리가 될 것이다. 그리고, 그러한 이야깃거리들을 사람들은 보이지 않게 즐긴다. 그렇다면 이러한 이야깃거리들이 어떻게 프로젝트에 참여하지도 않고 전혀 관여하지 않은 사람들의 귀에까지 흘러들어갈까? 인정하지 않을 수 없는 사실이 바로 내부의 눈과 입이 바로 그 원인이 되는 경우가 많다. 프로젝트를 수행하는 사람들이나 혹은 프로젝트에 관여된 사람들은 어떠한 경로든지 프로젝트의 상황을 외부에 전달하게 된다. 회사의 친한 관계에 있는 동료나 선후배에게 프로젝트의 일상적인 사소한 것들을 이야기하는 것은 바로 그러한 상황을 이해하고 받아줄 수 있는 공감이 형성되기 때문인 것도 있으며, 혹은 무용담처럼 들려주고 싶은 욕망일 수도 있다.

공식화된 경로가 아닌 비공식화된 경로를 통해서 전달되는 프로젝트의 상황은 여러 사람들의 입과 귀를 통해서 첨삭되거나 추가되기도 하면서 그 프로젝트의 전반적인 판단을 하게 만든다. 즉, 실제 그 프로젝트에서 경험하지도 않은 문제를 마치 자신의 입장에서 재해석하여 문제를 해결했던 방식이나 모습들을 나름의 결론으로 이끄는 모습을 보인다. 이러한 현상은 어려운 프로젝트에 참여했던 사람들에게 다시 되돌아와서 프로젝트를 참여하는 신념이나 활기를 떨어뜨리기도 한다. 혹은, 프로젝트 참여에 대한 회의까지도 느끼게 한다. 결국 자신이 전달했던 프로젝트 상황들이 하나 둘씩 되돌아와서 프로젝트 전체에 악영향을 미치게 되는 안좋은 상황을 부딪히게 된다.

프로젝트를 수행하는 경험이 쌓이다보면 이런 저런 이야기들이 외부로부터 들리는 경우가 많다. 때로는 그러한 의견들에 대해 상처와 분노를 느끼며 강력하게 대응하기도 하지만, 그러면 그럴수록 점점 더 프로젝트 분위기만 안좋아지는 경우가 많다. ‘어디어디 프로젝트는 어떤가요?’ 라는 질문을 받으면 이러한 질문에서 보이지 않는 어감은 ‘그 프로젝트는 문제가 많은지, 아니면 잘 진행되고 있는지’를 의도하고 말하는 경우가 많다. 즉, 프로젝트를 사찰하는 느낌을 받는다. 경험이 없는 사람들은 자신이 경험했던 내용 중에 인상이 깊었던 사건이나 사고들을 하나 둘씩 이야기하기도 한다. 혹은 직접 경험하지 못했다고 하더라도 누구한테서 들은 이야기를 자신의 관점에서 편집하여 들려주기도 한다. 이 과정에서 주어와 목적어는 생략된 채 ‘문제가 많다’, ‘사고가 많다’ 식의 단편적인 의견만이 전달된다.

프로젝트를 진행하는데 있어서 문제와 사고가 많은 것은 당연하다. 그리고, 그러한 문제와 사고를 해결하려고 참여자들이 협업하여 일을 하는 것이 아닌가. 사람들은 자극적인 이야기를 더 좋아하고 오래 기억하게 된다. 포탈이나 언론사의 제목들이 그러한 형식을 띠는 것이 우연이 아닌 것과 같이 주변 사람들에게 나의 이야기를 귀기울이게 하려면 제목부터가 자극적이어야 한다. ‘얼마 전에 우리 직원 중에 한명이 고객과 큰 다툼이 있었다’로 시작되는 이야기는 그 프로젝트는 고객과 싸운다, 고객과 불협화음이 있다 등의 웃지 못할 큰 문제로 탈바꿈되어 다시 그 프로젝트의 상황을 안좋게 만들기도 한다. 프로젝트 내부에서는 참여한 사람들의 의견의 조율과 협상은 얼마든지 진행할 수 있다. 그 과정에서 고성이 오갈 수도 있지만 결국 특정 목적을 이루는 과정의 일부인 것이다. 차, 포를 떼이고 전달된 메시지가 프로젝트의 전반적인 상황을 특정 프레임에 갇히게 만들고, 결국 그 프로젝트에 대한 혹은 참여 인력에 대한 평가의 잣대를 드리우게 된다.

프로젝트의 힘든 점이나 어려운 점을 이야기하지 말자라는 것이 아니다. 그렇다고 문제가 있는 부분을 숨기고 잘 진행되는 것과 같은 위장을 말하려는 것은 더욱 아니다. 위의 개그 프로그램에서 못생기지 않았다라는 말에 위로와 격려를 보내는 것에서 한번 생각해보자. 프로젝트가 어렵다라고 말하는 것은 극히 자연스러우며 그렇기 때문에 프로젝트를 진행하는 것이다. 어렵지만, 도전적이고, 점점 더 재미있는 문제들이 나타나고 그로 인해서 해결할 수 있는 자신감이 생긴다라고 말한다면 그 프로젝트는 문제가 있지만, 참여하는 사람들의 노력과 의지로 잘 해결해나갈 수 있을 것이라고 위로와 격려를 받을 수 있지 않을까. 고객의 취향이 독특하고 도전적인 과제를 던져주어서 너무나도 많은 실력 향상을 꾀할 수 있다라고 말한다면 그러한 문제를 해결하는데 도움을 준다든지 조언을 얻을 수 있지 않을까. 그 개그맨은 자신의 입장에서 솔직하게 경험담을 진지한 단어를 사용함으로써 공감을 일으키고 있다.

물론, 이러한 경우들은 순진하게 생각하는 프로젝트 관리자의 입장일 수도 있다. 사적이 자리에서까지 이렇게 말하기를 원하는 관리자는 없을 것이다. 하지만, 말 한마디가 천냥 빚을 갚는다고 너무 극단적인 단어가 아닌 좀 더 순화되고 중립적인 단어들을 선택한다면 그 프로젝트를 바라보는 눈이 한결 가벼워질 것이고, 그게 좋은 평가를 받을 수 있는 방법이 될 수도 있다. 또한, 프로젝트를 바라보는 관점 역시 비관적인 형태가 아닌 도전적이고 낙관적인 형태의 자세를 가질 수도 있을 것이다. 모든 프로젝트 참여자들은 성공하기를 원한다고 믿고 싶고, 그리고 정말 성공하기를 원한다면 우리는 우리가 스스로 말하는 말들이 다시 되돌아온다는 사실을 한번쯤 생각해보았으면 한다. 즉, 우리에 대한 평가는 바로 우리가 하게 된다는 것이다.

문제보다는 문제 해결에 초점을 이동한다면 우리는 좀 더 나은 평가의 프로젝트를 진행할 수 있지 않을까.