brunch

You can make anything
by writing

C.S.Lewis

by 문정현 Jun 12. 2018

불행한 팀원이 되는 효과적인 방법

디자인인가 싶은 이야기

❝
2017년 상반기를 돌아보면 나는 불행한 팀원이 되기 위해 부단히 노력했던 것 같다. (그렇다, 이 글은 2017년 하반기에 쓰던 글이다.) 한 명의 팀원으로서의 내가 스스로 경계해야 할 마인드를 발견할 때마다 기록했다.

1. 수렴 없이 발산하는 사고하기

한 중요 플로우를 바꾸는 프로젝트였다. 그 중요도 때문에 시간을 비교적 많이 할애했다. 그렇게 Ideation을 하다가 정신을 차려보니 발산왕이 된 나를 발견했다. 양질의 안들을 고민했다고 생각했지만 팀원들과 공유하려 정리하다 보니 지금까지 시간과 노력을 들여 만든 것은 A, B, C, D.. 안이 아닌 A-1, A-2, A-3, B-1, B-2, B-3 안이었다는 사실을 깨달았다. 결국 다시 A, B 정도로 1차 수렴을 할 수 있었다.

◇◇◇◇◇◇◇..... / source : ideo.com

내가 했던 것은 Ideation이 아닌 Variation이었다. 팀 회의는 다양한 아이디어들을 발산하고 중심점을 찾기 위한 커뮤니케이션 과정이라는 알 것이다. 마찬가지로 내 개인의 사고 흐름에도 중심점을 잃지 않고 중간중간 수렴하는 과정이 필요하다는 것을 느꼈다.

2. 합의되지 않은 시스템에서 분노하기

공동의 목표를 위해 일하고 있지만 조금 다른 관점으로 접근했던 팀과의 협업에 의문이 들었다. 여기서 성격이 완전히 다른 업무가 수시로 들어오자 그것이 Interrupt로 느껴지기 시작했다. 또한 두 팀의 기획 의도 사이에 유격이 생겼다고 느낄 때도 있었다.

source : Atlassian

당시 이 것이 가장 큰 스트레스였는데 해결책으로 두 팀의 방향과 일정을 조율하는 미팅을 매주 가지기로 했다. 시스템을 만들어 생산성도 높아졌고 가끔 발생했던 두 팀 사이의 유격도 사전에 방지할 수 있었다. 이렇게 시스템이 자리 잡자 수시로 들어온다고 생각되었던 업무는 정기적인 업무로 자리 잡았고 커뮤니케이션이 잘못되었을 때 바로잡는 비용도 줄일 수 있었다.

그래서 협업에서 문제가 발견되었을 때 그것은 시스템의 부재에서 나온 문제일 수 있다는 것을 알게 되었다. 그리고 조율하지 않고 벌어진 유격은 바로 잡을 수 있다는 것도.

3. 정의되지 않은 문제 해결하기

디자인으로 의사결정을 하고 싶다면 먼저 문제를 정의해야 한다. 그리고 다양한 솔루션과 이슈를 체크하고, 팀원들에게 중복되지 않으며 유효한 선택지를 제안해야 한다. 그 후 의견을 종합하고 반영할 수 있는 것.

하지만 가끔 어떤 개선 프로젝트를 진행했으나 어떤 것이 개선됐는지 말하기 힘들 때가 있었다. 해결할 문제가 정의되지 않았던 것이었다. 다시 말해 무엇을 개선할지 알 수 없었기 때문에 무엇이 개선되었는지 알기 위해 결과를 얘기할 수도 없었던 것이다. 생각해보니 역시나 시행 단계에서 팀원들을 설득할 때도 에너지가 더 들었던 것 같다.

물론 모든 일들이 볼륨 있고 확실한 당위성을 가진 문제로 시작해 드라마틱한 결과를 내놓는 형태로 끝나지는 않을 것이다(예를 들자면 컴포넌트 스타일에 관한 것이 있을 수 있다). 하지만 그러지 못하다고 해서 불필요한 일이라고 말할 수는 없다. 단기간에 가시적인 성과를 보이지 못하더라도 누적되어 전체적인 제품의 경험이 되기 때문이다. 본인의 만족도에도 중요하다고 생각한다. 하지만 그 조직의 분위기나 한정된 리소스 등의 이유로 우선순위에서 밀릴 수 있다는 점을 염두에 두는 것이 중요하다.

4. 이상을 높이고 완벽을 추구하기

완성도를 20%에서 80%로 올리는 것은 쉽다. 하지만 더 높은 수준에서는 얘기가 달라진다. 예를 들어 90%에서 95%로 올리는 것은 시간과 노력이 훨씬 많이 든다. 하지만 이게 나의 능력을 증명하는 것 같아서 95%의 노력을 하곤 했다. 결과적으로 시간이 더 오래 걸렸다.

source : jamesclear.com

하지만 Agile 방식에서 더 효율적인 프로세스는 90%에서 실제에 적용, 테스트를 하고 피드백을 받아 95%로 올리는 것이 아닐까 싶다. 우리가 완성도를 높이고 있던 방향이 사용자가 생각하는 그것과 같은지는 실제로 적용해봐야 알 수 있기 때문이다. 그리고 시간도 비용이니까.

5. 일회성 솔루션 내놓기

누적될수록 위험한 것이 바로 일회성 솔루션을 내놓는 것이다. 어떤 이슈에 대응할 때 당장의 일정에 지장을 주지 않기 위해 장기적으로 적용하기에는 신중하지 못한 솔루션을 내놓을 수도 있다. 또한 이 커뮤니케이션을 멋지게 끝내기 위해 바로 솔루션을 내놓고 자리에 돌아왔으나 나중에 허점을 발견할 수도 있다.

그 땐 몰랐네..

이는 말할 필요도 없이 일을 다시 해야 한다는 점에서 비효율적이며 하나의 시스템을 만드는 과정에서 모두가 싫어하는 '예외'가 될 수 있다. 더 오싹한 사실은 솔루션을 내놓을 당시에는 이 것이 일회성인지 알 수 없을 수도 있다는 것이다. 그래서 우리가 해야 할 일은 이를 항상 경계하는 것과 발견 시 바로잡기를 두려워하지 않는 것이다.

6. '그러면 너가 해봐!' 마인드 가지기

협업을 하다 보면 서로에게 수많은 요구들이 오고 간다. 그래서 너무 많은, 혹은 도저히 감이 안 잡히는 요구를 받을 때 '그러면 너가 해봐!'라는 말을 하는(혹은 생각하는) 유머 자료들을 가끔 볼 수 있다. 하지만 나는 나를 위해서라도 이런 생각을 하지 않으려 한다. 너가 할 수 있으면 나는 없어도 된다고 생각하기 때문이다.

?! 너가 해보는 건 어때?

물론 슬프지만 다른 사람이 내 일을 대체할 수 있을 것이다. 하지만 내 '일'과 '역할'은 다르다. 나의 일에 대해 저런 마인드를 가지는 순간 내 역할에 대한 의심이 시작된다. 외부에서도, 내부에서도. 나의 격을 낮추는 이런 위험한 생각을 밖으로 꺼낼 필요는 없지 않을까? 내가 그 일을 하기에 나는 한 역할을 수행한다.

작성하고 나니, 나의 실수들을 적나라하게 쓴 것 같다는 생각이 든다. 하지만 괜찮다. 기록이 가지는 의미가 있다. 내가 어떤 생각을 했었는지 내가 안다는 것이다. 경계해야 하는 포인트를 안다는 것은 좋은 일이다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari