| |||||||||||
한권을 다 베끼고는 마음에 든다고 쓰게 될 것만 같아서.. 그런 내용은 좀 자제하고..
제가 가장 최근에 했던 고민 중 Use case를 업무에 적용하는 고민이 있었는데, 간단했지만 그 내용이 이 책에도 있어서 생각난 김에 풀어볼까 합니다.
UI문서를 효과적으로 커뮤니케이션 할 수 있는 도구로 만들기 위한 고민의 일환으로...
유스케이스(Use Case)를 적용해 보라는 지시를 받았었습니다.
제가 능동적으로 시작한 일은 아니었지만 좋은 취지라고 생각했고 기획자, 디자이너, 프로그래머까지 모두가 이해할 수 있는 언어로 풀어 쓴 문서를 만들어내는 것이 필요하다고 공감했었습니다.
Use case 작업은 프로그래머들에게 익숙한 언어로 flow를 만들어 공감대를 형성해보자는 취지인데요.
UI문서를 만들 때는 주로 사용자들이 보는 화면을 중심으로 작업을 하기 때문에 보이지 않는 곳에서 진행되는 시스템 처리는 UI문서를 받아본 프로그래머들에 의해서 시스템 구현설계가 이뤄집니다. 그 해석의 시간과 수고를 줄여보는 방법론으로 Use Case를 적용해 보는 것입니다.
(전체 개발자 간의 끊임없는 대화는 성공적인 프로젝트로 가는 지름길이죠.)
우선, 내부적으로 이런 작업이 필요하다는 공감대를 형성해야 했습니다. 그래서 간단히 조사를 해 봤는데요.
그런데 업무에 적용하려고 보니 제가 찾아 본 대부분의 유스케이스들로는 제가 하고 있는 업무에 어떻게 적용을 시켜야할지 막막했습니다. 과연 UI 업무에서 Use case를 녹여낼 수 있는지도 잘 모르겠구요. 물론 Use case가 어려운 작업은 분명 아닙니다. 전체적인 흐름을 파악할 수 있게 액터간의 반응만을 정리하면 되니까요.
UI작업을 하다보면 사용자 입장과 사용성을 우선 순위에 두고 Flow를 만들게 됩니다.
그런데 자칫 사용자의 입장이라면서 화면의 모습에만 집중을 하는 좁은 시각을 가지게 될 경우가 종종 있습니다.
많은 케이스와 예상 가능한 경로를 생각하려고 노력하지만 항상 놓치는 부분이 발생합니다.
그 때, Use case는 간단한 프로세스로 시스템의 반응까지도 체크할 수 있도록 생각의 범위를 넒혀주는데 도움을 줍니다.
다만 그 효과에 대해서 반신반의했던 것 같습니다. 제가 정리한 유스케이스로 모든 개발자들과 대화가 될지...
상세한 내용을 덧붙이고 싶은 욕심이 불쑥 불쑥 올라온다고나 할까요... 살을 붙이고 가지를 뻗게 해 더 크고 무거운 유스케이스를 만들어 버리고마는 욕심이 생깁니다.
다른 책에서 보니... 방법론에는 정답도 없고 단 한가지만 있는 것은 아니라고 합니다.
문서 형식이라는 것은 문서를 공유하는 사람들간에 커뮤니케이션이 가능하도록 구성되는 것이 가장 중요하고
그 형식은 끊임없이 변할 수 있다는 거죠.
정답이 있을거라는 생각으로 방법론에 접근한다면 삶이 고달파지겠죠.. ㅎㅎ
그러니 생글생글 능글맞게 웃으며... 오늘도 내일도 개발자들과 대화하려는 노력만 하려합니다.
PREV
