랜턴의 서비스 기획 야이기 9

분석단계에서의 기획에 대한 무지 -> 소통이라도..  

나는 당초부터 기존의 개발 업체를 유지하는 방향으로 업무를 추진했다. 
사유는 아래와 같았다, 

-  이 웹이 달성하고자 하는 비즈니스 목적을 설명하고 이해시키는 것이 가장 어렵고 
- 컨센서스를 만드는 데 소요되는 시간 비용이 적지 않을 것이라는 생각이 있었으며
- 기존 매터리얼을 참조하여 구조를 유지하는 데도 이 편이 편했기 때문이었다 

 

사용자 분석과 비즈니스 분석을 명징하게 하지는 않았지만,
이전의 기획서와 비슷한 몇 가지 아이템들로 
감각적인 컨센서는 확보할 수 있었다.

그럼에도 불구하고, 나의 개선에 대한 의지 + 대대적인 디자인 개편이 있었기 때문에
개발 그룹은 어디서부터 요건을 정리해 나갈지 감을 잘 못잡는 편이었다
이는 당시 지식적 경험적으로 불완전한 나로서도 마찬가지였다. 
화면에 대한 초안이 나온시점에서
기존 상황을 참조해서 만들면 되는 일이 아닌가하는 
막연한 생각이 있었기 때문이었다 

그럼에도, 개발그룹과 최대한 수평적으로 소통하려고 노력했다.

- 많은 나의 선배들이 그러했듯, '아, 이전 거 보고 하세요!'식의 무책임한 개발 리딩이 
 어떤 무책임한 결과물을 만들 수 있는지 알고 있었고 
- 개발 막바지에 대공사를 필연적으로 불러일으킨다는 점을 알고 있었고  
- 그것이, 발주업체가 뻔뻔함과 권력으로 찍어내리는 결과를 만들거나 
  혹은 추가 비용을 투자하게 만드는 원인이 됨을 알고 있었기 때문이었다. 
- 한편으로, 협력업체와 발주사간의 수직적 구조가 커뮤니케이션 경색을 불러일으킴도 나는 보았다
- 이는 이들의 자발성을 삭제시키는 원인이 되었다. 
  찰리 멍거는, 경제학도들이 선의와 악의에 대한 관심이 부족하다고 평하였는데
  이는 비즈니스맨도 마찬가지라고 생각했다.  
- 나보다는 현장에 노출된 업체의 전문성과 창의성을 가져오는 게 나의 목표기도 했다.
  그러려면, 수직구조의 관계를 벗어나서 수평적 소통 구조를 형성하는 게 반드시 필요했다
- 무엇보다, 나는 나의 지식적인 역량에 대해 겸손했다. 매우 겸손했다.

 

하여간 그렇게 IA를 비롯한, 권한 구조 등을 삐그덕거리며 결정해나갈 수는 있었다.

---

기획 자체에 대한 공부 시작

이맘때 쯤, 나는 기획이라는 행위 자체에 대한 공부 역시 필요함을 깨달았다.
그리고 프로젝트 매니징, PM, 기획 등 키워드를 공부하며, 막 공부를 시작했다.
가장 도움이 됬던 책은 도그냥님이 쓴 서비스 기획 책이었다.
2-3달에 한 번꼴로 서점에 가는 편인데, 
디자인에 대한 고민들로 책을 둘러보다가 눈에 띄어서 사서 읽게 된 책이었다. 

인하우스 기획자이면서, 개발자는 아니라는 점에서 
나와 매우 유사한 시작점을 가진 분이셨다
반면, 전문 기획 조직에서 빠르게 움직이고 진화하는 것처럼 
책에서 보였는데, 그런 부분이 나와 나의 팀에는 없었기 때문에 특히 도움이 되었다. 

만약, 기획을 한창 고민하던 때에, 미준맵이라는 걸 그렸다면 
훨씬 쉽게 업무가 풀렸을 텐데 아쉬운 마음이 나중에야 들었다 .

---

화면을 구체화하자

 

분석 단계에 대한 태스크를 스스로 도출하기에 나의 경험과 역량이 역부족이라는 진단이 나왔다.

마냥, 나의 공부로 역량이 올가는 것을 기다리고만 있을  수는 없었다

(어째, 디자인할 때와 똑같은 상황...)

 

프로젝트를 리딩하고 드라이빙하기 위해서, 나 스스로 태스크를 만들어야만 했다. 

개발 파트가 어떻게든 본인들끼리 질문을 구체화해서 물어보는 것 이외에도 말이다.

물론, 나름대로 사용자 권한 체계와 기본적인 IA는 작성해서 백엔드 개발에

시동은 급한대로 걸기는 했다. 

하지만, 그것만으로는 부족하다는 것은, 

누가 나를 보채지 않아도 스스로 느낄 수 있었다. 

돌이켜보면, 각 데이터 엔터티별로 정책적인 부분들을 먼저 결정했어야 했다.

하지만, 당시에는 지금처럼 뭘 해야 할지 결정할 수 있는 상황이 아녔다. 

 

어떤 고민의 과정이 있었는지는 이제와서 기억나지 않는다.

어찌되었던, 나는 앞으로 나갈 수 있는 방법을 찾아내긴 했다. 

나의 실력에 맞게, 기존에 만들어 두었던 화면과, 기존 시스템의 화면을 비교하는 방법이었다.

달라진 점, 달라져야 하는 점을 찾고

비즈니스 관점의 논리적 이유를 만들고 

운영 방식과 화면 설계를 추가로 진행하는 방식이었다. 

공부 중이던 UIUX 지식들과 맞물려 이런 방식은 예상치 못한 시너지를 가져다 주었다. 

 

더불어, 사내 디자인 가이드에 대한,

개발파트의 내부 이해도와 컨센서스를 높이는 작업도 실시했다.

디자인 가이드 유관팀과 협의를 통해, 가이드에 대한 웨비나를 갖기도 했으며,

디자인파트와 꾸준한 미팅을 통해, 우리에게 필요한 디자인이 어떤 식인지 

비즈니스 관점에서 계속 반복 언급했다.