설득하는 일이 가장 어렵다
남들이 하면 나도 해야 할 것 같은 '사회적 규범' 분위기를 만들어라.
프로젝트가 가장 힘들 때는 언제일까?
- 만들어야 할 제품의 기술적 요구사항이 너무 많을 때일까?
- 일정은 촉박한데 동작하는 소프트웨어는 30%도 준비되어있지 않을 때일까?
- 이해관계자가 너무 많아서 과제의 우선순위가 프로젝트 중반인데도 명확하지 않을 때일까?
모든 케이스가 힘들지만, 대부분 "사람" 문제가 얽히면 가장 힘들지 않을까 싶다.
프로젝트가 성공하려면 긍정적 변화가 계속 함께 해야 한다. 그런데 '사람'이 허들이 되는 경우가 있다. 관성의 법칙대로 기존의 편한 방식을 원하기 때문이다. 이 온도가 높을 때 '변화' '개선'을 주장하는 PM 말은 무시하고 불편한 기색을 드러내기도 한다. (이때 레벨이 낮은 PM은 깨갱하고 그들의 주장에 휘둘리기도 한다)
한 가지 예시.
과거 User Story 방법론을 개발 문화에 적용시켜야 할 때가 있었다.
고객 지향적인 소프트웨어 개발이 필요한 상황이었고, User Story를 통해 고객이 지닌 문제를 발견하고 거기서부터 개발을 시작해야만 했다. 몇 명은 꽤 거친 반대를 했다. "이게 문제야! 나 이 문제를 풀고 싶어! 이게 우리가 개발해야 할 내용이야! 나 이거 연구해보고 싶어!" 등.. 객관적 근거보다는 직관에 따라 '하고 싶은 일'을 개발하고 싶다고 주장했다.
이들을 설득하기 위해, User Story 효과성을 입증하는 논문을 찾고, 직접 가이드 문서를 만들고, 2주에 걸친 오프라인 워크숍까지 진행했다. 가까스로 그 팀에 User Story 도입을 시작할 수 있었다. 코치로서의 노력이 많이 들어간 만큼 좋은 성공사례로 남길 바랬으나 아쉽게도, 잠시 다른 팀을 코칭하는 사이 그 팀은 빠르게 예전의 모습으로 돌아가고 말았다. (ex. 나 그냥 이거 개발할래!)
비관적이고 방어적인 태도로 새로운 방식을 제대로 받아들이지 못한 것이다.
아쉽지만, 어찌하랴.. 코치는 제안할 뿐 강요할 순 없다. 일단 타 팀에 User Story 도입하는 것에 우선 집중했다.
그렇게 3개월이 흘렀다.
재밌게도 그 한 팀을 제외한 모든 개발팀이 User Story를 제대로 활용할 수 있게 되었다. 그리고 더 이상 내가 직접 효용성을 설파할 필요가 없었다. 구성원들이 User Story로 Planning 하는 것의 장점을 체득한 것이다.
딱 하나 남은 그 팀은 그때부터 슬슬 User Story 가이드 북을 클릭하기 시작했다. 그리고 어설프지만 자체적으로 User Story 방식대로 Planning을 시작하게 되었다. 덕분에 (?) 내가 중간에 들어와서 제대로 코칭할 수 있게 되었고, 꽤 괜찮은 모습의 레퍼런스가 되어주었다 (6개월 넘게 걸리긴 했지만....)
여기서 한 가지 중요한 깨달음을 얻었다.
프로젝트 관리에서 가장 중요한 것은 '타인을 내가 원하는 변화의 방향으로 설득하는 일'인데,
아무리 가이드 문서를 잘 쓰고, 워크숍으로 촉직시 킨다 해도 그 효과는 미미할 수 있다는 것이다 (시니컬함이 앞서는 팀이 항상 있다) 이런 상황에서는 '사회적 규범'이 효과적이다.
사회적 규범은 집단적 흐름을 만드는 것이다. 문화일 수도 있고, 어떤 분위기일 수도 있다. 사람들은 내 옆의 동료가 취하는 행동, 사고방식, 말투를 따라 하려 하는 본능이 있다. 그러니 설득이 안 되는 팀/사람에게 너무 에너지를 쓸 필요가 없다.
노력하면 변화할 것들에 더 집중하고, 큰 흐름 (사회적 규범, 약속, 습관)을 만들어 따라 하고 싶게 분위기를 만드는 것이 중요하다. 즉 단순히 방법론을 많이 알고 발표를 잘하는 것으론 변화가 쉽게 오지 않는다. 더 오랜 시간 공들여 분위기를 만들고, 해보고 싶게 끔 긍정의 시그널로 조직을 가득 채워야 한다.
그래서 Change Management를 업무로 삼는다면 속단해서도 안되고 쉽게 좌절해서도 안된다.
오래 걸리면 오래 걸리는 대로, 쉽게 따라오지 않으면 이유가 있겠지.. 인정할 것은 인정하되 포기하지만 않으면 된다. 그러면 점차 사회적 규범이 되고 (매니저가 시키지 않아도) 자연스럽게 '우리가 함께 만든' 일하는 문화가 된다.
