brunch

You can make anything
by writing

C.S.Lewis

by 김선혜 Jun 12. 2024

디자인 프레임웍보다 중한게 뭔데?

사람들이 모여 일을 시작하다 어느 시점이 되면 으례 나오는 이야기가 있다. “방법론이 필요하지 않아? 방법론을 만들어야 하지 않아?” 그 어느 시점이란 걸 정의해 보면 어느 정도 조직에 사람이 많아지고 모양새를 갖추게 되면서 사람마다 일하는 방법의 차이에서 나오는 이견들과 결과물의 차이가 나타나게 되고, 이로 인해 사람들이 들락날락거리게 되는 시점이다. 그나마 구전 문화라도 있으면 명맥이라도 이어가는데 특정 사람에 의지해서 조직이 흘러가다 보니 그 특정 사람이 없으면 바퀴 하나 빠진 마차를 운전해야 하는 것과 비슷한 상황이 발생하게 되는 것이다. 그 정도 능력을 가진 다른 사람을 다행히도 빨리 찾으면 프로젝트가 또는 조직이 빨리 정상화가 되는데 그러지 못할 경우에는 삐그덕거리며 힘겹게 마차를 끌고 갈 수 밖에 없고, 이러한 상황이 오랜 기간 지속되어 다른 바퀴 마져 빠져게 되면 돌이킬 수 없는 상황으로 치닫게 되는 것이다.

식스 시그마를 시작으로 다양한 산업 혁명의 양상에 따라 다양한 방법론들이 쏟아져 나왔고, 마치 트렌드처럼 전 세계를 휩쓸고 지나갔다. 그리고, 그 방법론을 도입해야 일을 잘 하는 조직인 것 처럼 포장이 되어 회사의 조직과 업태에 맞지도 않는 방법론을 끼워 맞추려고 무진장 노력들을 해 왔다. 물론 지금도 크게 다르진 않지만 그나마 다행인 건 요즘은 취사 선택할 방법론들이 많고 커스터마이징을 할 수 있는 노하우가 생겼다는 것이다. 나의 업이 기획자로 시작하여 서비스 디자이너를 거쳐서 유엑스 디자이너로까지 흘러왔으니 대략 이 업 안에서의 방법론도 상당히 다채로웠음을 짐작할 수 있을 것이다. 그리고, 회사 안에서 나름의 방법론을 만들어 요즘은 제안도 하고 있으니 이 업도 참 많이 발전을 했다고 볼 수 있다. 하지만, 20년을 훌쩍 넘긴 역사에도 불구하고 발전하지 않는 것이 딱 하나 있는데 방법론을 바라보는 사람들의 관점이다.

방법론은 말 그대로 일을 하기 위한 기준인데, 마치 반드시 지켜야 하는 법처럼 생각한다는 것. 하지만 더 재미난 것은 회사 안에 범법자가 넘쳐난다는 것. 말인 즉은 아직도 방법론을 제대로 이해하고 일에 제대로 활용을 하고 있지 않다는 것이다. 나름 회사에서 생각하고 고민해서 만든 방법론이 번거롭고 쓸데없는 것이라고 치부하고, 일이 잘못되면 그 놈의 방법론 탓을 하고 일이 잘 안 굴러가면 그 놈의 방법론이 없어서라고 이야기한다. 그럼 뭐가 문제냐고? 문제는 바로 “당신”입니다.

우리 업은 팀이 함께 일하는 구조이므로 일의 틀(framework)이 필요하다. 그것이 서비스 디자인 방법론이든, IDEO의 디자인 씽킹이든, 브리티시 카운실에서 만든 더블 다이아몬드든 어떤 틀을 도입하든 큰 문제가 되지 않는다. 일의 틀(framework)이 결정되면 각각의 단계마다 구체적인 업무들(tasks)과 R&R을 정의해야 디자인 프레임웍이 완성되는 것이다. 물론 프로젝트의 특성에 따라 프레임웍의 바꿔야 할 수도 있고, 단계마다 정의된 업무들을 조정해야 할 수도 있다. 프레임웍이 필요한 이유는 꽉 짜여진 틀에 맞추어 일을 하기 위함이 아니라 일에 맞게 바꾸고 조정하기 위해 기본틀이 필요한 것이다. 그래서 기본 프레임웍은 이러한 유연함을 대처할 수 있는 유니버셜한 형태가 오히려 현실적일 수 있다. 그리고, 내가 맡은 프로젝트와 구성원에 맞게 프레임웍을 응용해서 쓸 수 있어야 하고, 함께 일을 하는 구성원들은 프로젝트의 프레임웍을 이해하고 본인들이 맡은 역할과 책임을 해 나가면 되는 것이다. 하지만 이렇게 단순한 것이 잘 실행이 안되는 이유는 프레임웍이 무엇인지 왜 필요한지에 대한 이해가 부족하고, 이를 응용해서 프로젝트에 최적화된 프로젝트만의 프레임웍을 만드는 응용 능력이 부족하고, 마지막으로 제대로 정의된 프레임웍이 없다보니 업무와 R&R 또한 제대로 정의되지 않아 이게 내 일이니 네 일이니 싸우게 되고, 그러는 와중에 프로젝트는 이미 저 산으로 가고 있는 상황이 벌어지는 것이다. 이 즈음이면 디자인 프레임웍보다 중한게 뭔지 이해가 되셨을까?

내가 다니고 있는 회사에도 더블 다이어몬드를 도입한 디자인 프레임웍이 있다. 그동안 일을 하면서 많은 고충을 겪다 보니 기본틀을 커스터마이징해야 겠다는 생각이 들었고, 나름의 생각으로 방법론과 업무들과 R&R을 정의해 보았다. 앞서 이야기한 PA, PL, PM의 R&R과 내용상 이어지는 부분이 있으니 이전의 게시물 또한 참고로 같이 보면 이해하는 데 도움이 되지 않을까 싶다.

일반적으로 더블 다이아몬드는 Discover, Define, Develop, Deliver의 4단계로 구성되지만, 실제 프로젝트 진행에서는 착수 전 준비해야 하는 과정들이 있으므로 그 과정까지 포함에서 Discover 앞에 Initiate 단계를 하나 더 추가했다. 그리고, 각 단계에서 정의하는 업무 태스크의 범주도 나름의 해석으로 조금 다시 정의를 해 보았다.

Initiate (준비/착수)

프로젝트 진행 확정 후 계약 ~ 착수 보고까지의 단계

Discover (조사/분석)

프로젝트에 대한 이해 단계로 요구사항을 포함하여 다양한 자료와 분석을 통해 인사이트를 도출하는 단계

전략 단계를 Discover 단계에 넣기도 하는데 전략은 방향을 확정하고 이후의 과정을 추진하는 영역에 포함된다고 생각하여 Define 단계로 정의했다.

Define (전략/설계)

Discover 단계에서 한 조사/분석을 기반으로 전략을 수립하고, 설계를 진행하는 단계

설계를 Develop 단계에 넣기도 하는데, 설계 정의 후 이후 단계가 진행되고, 설계 정의가 명확하면 명확할 수록 이후 진행되는 단계의 리스크를 줄일 수 있기 때문에 Define 단계로 정의했다.

Develop (디자인 ~ 테스트)

Define 단계어서 정의된 전략과 설계를 기반으로 디자인/퍼블리싱/개발/테스트를 진행하는 단계

Deliver (이행/종료)

테스트 완료한 서비스를 오픈하고 산출물 정리 및 인수인계 진행 후 프로젝트를 종료하는 단계