스스로 ‘개방적‘이라 생각하는 조직은 대체로 자신들이...

스스로 ‘개방적‘이라 생각하는 조직은 대체로 자신들이개방적이라는 사실을 뿌듯하게 여긴다. "우리 조직은 아주 개방적입니다."라고 자랑하며 남들이 감명을 받으리라 믿는다. 하지만개방도 지나치면 해가 된다. 지능 분야에서 선구자인 허브 사이몬은이를 멋지게 표현한다. "정보 과잉은 주의 결핍을 초래한다." 주의를기울일 정보가 어느 수준을 넘어서면 우리는 더 이상 처리하지 못한다. 정보가 많다고 반드시 도움이 되지는 않는다.

우리가 스스로를 정보에 파묻는 일반적인 이유는 불안하기 때문이다. 혹시라도 남들이 아는 사실을 나만 모를까봐 두려워서다. 이런 두려움에 굴복한다면 난생 처음으로 뷔페에 참석한 아이가 된다. 맛볼기회를 놓치지 않으려고 맛있어 보이는 음식을 접시에 꾸역꾸역 쌓는다. 먼저 자신의 정보 접시가 어느 정도 크기인지 파악하는 편이 낫다.
이것이 커가는 과정이다.

"관리는 남이 친 홈런으로 월급 받는 직업이다."

팀이 감당할 수준을 넘어서 온갖 요청을 수락하는 관리...

팀이 감당할 수준을 넘어서 온갖 요청을 수락하는 관리자는 비겁하다. 개인적인 비판을 피하려고 팀이 성공하지 못하는 상황을 만든다.
궁극적으로 팀은 과도한 업무로 고통 받고 사기가 떨어진다. 단지 관리자가 처음부터 "아니오."라고 말할 용기가 없었다는 이유로.
이처럼 불행한 패턴을 방지하려면 어떻게 해야 할까? 업무에 우선순위를 매긴 후 최고 속력으로 처리가 가능한 만큼만 진행한다. 가치가 낮은 업무는 가치가 높은 업무를 다 끝낸 후로 연기한다.
실천하기 어려울지도 모르겠다. 가치를 빨리 내놓는 대신 권력을포기해야 하므로, 힘 있는 사람에게 "아니오."라고 말하면 팀 효율은높아질지 몰라도 자신의 정치력은 떨어진다. 별로 달가운 공식이 아니다. 잠재적인 정치력을 어느 정도 희생해야 필수적인 업무가 더 빨리끝난다.

[마이리뷰] 프로젝트가 서쪽으로 간 까닭은

프로젝트가 서쪽으로 간 까닭은 - 프로젝트 군상의 86가지 행동 패턴
톰 드마르코 외 지음, 박재호 외 옮김 / 인사이트 / 2009년 11월

34. 그릇된 품질 관문
35. 테스트 전에 하는 테스트

중간목표에 도달하거나 반복을 한 번 마치면 대다수 조직은 미리 정해놓은 절차로 결과물의 품질을 점검한다. 대개 품질 점검은 두 단계로 나누는데 하나는 결과물의 존재와 형식을확인하는 단계고, 다른 하나는 결과물의 내용을 확인하는 단계다. 첫번째 단계는 계획한 결과물을 계획한 형식으로 만들었는지 확인한다.
두 번째 단계는 각 결과물 내용이 프로젝트 목적에 비추어 유효하고,
정확하고, 충분한지 확인한다. 첫 번째 단계가 문법을 점검한다면, 두번째 단계는 의미를 점검한다.
하지만 의미가 부실하다면 문법을 점검해봤자 소용이 없다.

그릇된 품질 관문을 세워놓은 조직은 결과물의 문법과 형식만 확인할 뿐 내용은 무시한다. 조직이 이런 패턴을 보이는 이유는 대개 세가지다.
QA 업무를 맡은 사람이 프로젝트 팀에 속하지 않는다.

결과물을 자세히 읽고 분석할 의지가 전혀 없다. 따라서 손쉽게형식만 점검해서 결과를 넘긴다. 어떤 다국적 프로젝트에서 다음 주요 버전의 요구사항을 확정하려고 모든 파트너 사에게 명세서를 배포했는데, 파트너 사 한 곳에서 이런 피드백을 보내왔다.
"100쪽짜리 문서에 이중 공백이 너무 많아서 읽기가 어렵습니다. 고쳐서 다시 보내주십시오."
• QA 업무를 맡은 사람이 문서를 생성하는 방법이나 품질을 판단하는 방법을 배우지 못했거나 해당 분야 지식이 부족하다. 그래서 머리글이나 번호 체계를 따지거나 템플릿에 명시된 제목을 모두 채워야 한다며 고의로 비워놓아야 하는 단락을 지적한다.
회사가 선택한 프로세스 모델이나 조직 구조가 품질 보증 인력을프로젝트 실제 업무에서 분리시킴으로써 이런 패턴이 나타난다.

테스트 전에 하는 테스트는 1) 나중에 진행할 테스트의 효과를 크게높여주며 2) 그래서 충분히 피할 수 있는 오류를 고치느라 낭비하는시간을 크게 줄여준다는 측면에서 합리적이다. 초기 테스트를 수행하는 조직은 후반 테스트에서 ‘제품이 원하는 방식으로 동작하는지 여부만 확인해도 괜찮다는 사실을 깨닫는다. 대다수 조직은 이렇게 하기가 어렵다. "원하는 대로 동작한다."는 정의 자체가 올바른지 확신하지 못하기 때문이다. 요구사항 자체를 테스트하지 않았다면 테스터도요구사항을 신뢰하지 못한다. 초기 테스트는 후반 테스트에서 최종제품을 가져와 맞춰볼 정확한 잣대를 제공한다.
하지만 초기 테스트는 요구사항에만 국한하지 않는다. 어떤 프로젝트 결과물도 초기 테스트가 가능하다. 예를 들어, (제품 설계를 유형의 형식으로 기록한다면) 제품 설계도 초기 테스트가 가능하다. 프로젝트 계획서,
범위 문서 등과 같은 프로젝트 결과물도 마찬가지다. 테스트 가능한 형식으로 표현만 한다면 모두가 초기 테스트로 이익을 얻는다. 게다가 초기 테스트를 거치리라 예상하면 결과물을 만드는 사람이 더욱 주의를 가울인다.

[오늘의 한문장] 프로젝트가 서쪽으로 간 까닭은

일이 많고 복잡하다고 기죽는 대신, 프로젝트 팀이 작지만 일정한보폭을 유지하며 프로젝트 목표에 차근차근 다가간다. 그들은 일정한박자에 맞춰 프로젝트를 진행한다. 팀이 일하는 방식은 이렇다. 첫째,
정상을 바라보고 프로젝트 목표를 설정한다. 둘째, 적정한 기간 내에출시할 결과물을 계획한다. 일반적으로 한 달을 잡는다. 다음 한 달 동안 팀은 매일 모여서 진도를 살피고, 아이디어를 공유하고, 질문을지고, 다음 날 계획을 세운다. 프로젝트 목표, 그 달에 출시할 결과물,
매일 여는 회의로 프로젝트에 리듬이 생긴다.
팀이 주기를 리듬으로만 인식한다면 그 길이는 중요하지 않다. (일일빌드처럼) 매일도 괜찮고, (스크림처럼 매주나 매달도 괜찮다. 6개월이 넘으면 대다수 사람들이 위기감을 느끼기 어렵다(패턴 7 「내일」을 참조한다.
박자가 느릴수록 맞추기가 어려워진다. 사람들이 주기적이라 인식할정도의 기간이 적당하다.

관리자는 리듬을 맘대로 정하고픈 유혹에 빠지면 안 된다. 생산성을 높이려고 박자를 조정해서도 안 된다. 팀이 스스로 리듬을 찾아서꾸준히 결과물을 내도록 유도해야 한다. 어려운 업무나 따분한 업무도일정한 리듬으로 일하면 쉬워지기 마련이다. 등산을 떠올리며 한 걸음한 걸음씩 리듬을 따르자.

[오늘의 한문장] 프로젝트가 서쪽으로 간 까닭은

밀짚 인형

고객은 직접 보기 전까지 자신이 원하는 바를 알지 못한다.……….
보고 나서야 아니라고 말한다.

진짜 재미난 농담은 언제나 뼈가 있다. 위 농담도 예외는 아니다. 고객은 무엇이 가능한지 모른다. 그래서 무엇을 요구하면 좋을지도 모른다. 우수한 분석가는 처음부터 해법에 돌입하지 않는다. 최소한의 노력으로 간단한 해법을 (혹은 해법 일부를) 재빨리 구현하여 고객에게 보여준후 반응을 살핀다.
밀짚 인형 모델은 일종의 요구사항 미끼 Requirement Bait다. 스티브 맥메나민이 사용한 표현인데, 고객에게 제시하여 좋다 싫다 등) 감정적인반응을 끌어내는 미끼라는 의미다. 밀짚 인형 모델은 만들기 쉽다. 완벽할 필요가 없으므로 제작비도 저렴하다. 예를 들면, ‘선택한 지역에 나온 매물‘ 화면을) 모형 mock-up, 프로토타입, 스토리보드 등 어떤 형태로 만들어도 괜찮다. 나중에 세상에 보여질 모습을 적당히 흉내내면 충분하다.
그걸 보고 클라이언트가 진짜 요구사항을 내놓는다.
우수한 분석가는 "무엇을 원하십니까?"라고 묻지 않는다. 고객이불편함을 느끼기 때문이다. 사람들은 100% 주관식 질문을 싫어한다.

밀짚 인형 기법은 처음에 자주 틀린 답을 내어서 가능한 빨리 옳은답을 찾아내자는 철학에 기반한다. 오늘날 우리가 직면하는 문제와 우리가 고민하는 해법은 너무나도 복잡하다. 어느 한 개인이 완벽한 해법을 단번에 떠올리기란 거의 불가능하다. (자신의 생각이 완전히 틀렸더라도)얼굴에 철판을 깔고 고객에게 물어보라. "이건 어떻습니까?"