이 시리즈는 24년 상반기 Delta 활동 중
강의를 진행한 내용을 정리한 내용입니다
'기획'
나는 단어의 뜻부터 분명히 하는 습관이 있다.
마찬가지로, 기획이라는 단어부터 분명히 하면서 시작하고자 한다.
'기획'이라는 말이 특별하다는 걸 알게 된건,외국인 임원에게 보고 자료를 만들면서부터였다.
웹 기획이라는 단어에 대응할 만한 마땅한 영문 표현이 없다는 걸 알게 된 것이었다.
Plan? Design? 둘 다 통상적으로 한국 직장에서 쓰는 표현으로 비적합했다
'기획'이라는 단어와 용례는 일본에서 건너온 것이라고 한다.
본디 일본에서 기획이란, IT 프로젝트 개발을 SI업체에게 턴키로 맡기고,
스케줄과 자원 관리를 원청에서 하는 것을 '기획'이라고 부른다고 한다.
00년대 한국의 SI업체들도 초기에는 역시 위의 방식대로 일을 했고,
물론 여전히 이렇게 일하는 곳도 있다.
'기획'을 어떻게 정의할 수 있을까?
오늘날 한국에서 '기획'이란 단어는 통상 위의 내용보다는 정의가 포괄적이다
스케줄 관리, 자본 관리가 포함되는 것은 물론이거니와, 추가로 더 많은 일들을 수행해야 한다
이에 더불어, 장단기 전략이 검토 되어 중복투자 방지 및 생태계와 연계되야 할 것이다
비즈니스 온보딩 전략도 고려되야 원활하게 비즈니스를 활성화시킬 수 있다.
그러려면 개발 요구사항에 직접 개입해야 한다
매끄러운 온보딩에는 사용성 검토가 필요하므로 QC 과정도 참여해야 한다
대개, 개발 완료 이후 운영까지 맡게 되는 경우도 허다하다
서양권 국가에서는 이런 일을 하는 잡 포지션에 대한 명칭은 있다.
Project Mananger / Product Manager /Project Owner / Product Owner가 그들이다.
대개 PM/PO로 줄여서 불린다.
몇 년전부터는 한국 테크 기업들도 채용 공고에서 PM/PO로 공고를 내고 있다.
하지만 잡 포지션이 정의되었음에도, 잡 디스크립션에서는
여전히 '기획'이라는 단어를 쓰고 있으므로, 여전히 미궁 속이다.
위의 모든 활동을 한 줄로 명료하게 정의내릴 수 있을까?
나 역시, 그런 정의가 필요했기 때문에,
여러 기획자 선배님들의 글과 책을 찾아봤지만 이거다 싶은 건 없었다.
그래서 내가 정의내리기로 했다.
'개발 프로세스 간 총체적 사고를 통한 시계열적 의사결정 활동'
한국에서 기획 업무란, 결국 개발 프로세스 전반에
(어쩌면, 그 이후에도) 의견을 내는 업무가 된다.
따라서, 자연스럽게 프로세스와 자원관리를 겸하는 사람이 된다
기획자는 전체를 모두 아우르는 총체적 사고가 가능해야 한다.
왜냐하면, 나머지 개발 프로젝트 구성원들에게 총체적 사고를 요구하는 일이 비교적 어렵기 때문이다
특정 분야에 몰두하면 할 수록, 거시적 관점을 겸비하는 것이 어려워진다.
최근에 한국 테크 기업에서 종사하는 팀장급 UX 디자이너의 글을 읽은 적이 있는데,
'UIUX 디자이너가 굳이 디자인학과여야 할 이유가 점점 사라지고 있다.
예쁜 디자인을 하기 보다, 실용적 디자인을 설명하는 법을 알아야 한다' 라는 내용이었다.
예컨데, 디자이너가 개발 언어와 환경을 모르면 다른 관계자를 설득하는 것이 어렵고
사용자 여정과 비즈니스 환경을 모르면 뜬구름 잡기에 그칠 수 있다.
상대적으로 기획자는 거시적 관점을 겸비하기에 가장 유리하다.
프로젝트 내부에서는 왜 이런 디자인을 개발해야하는지 설명하는 역할을 맡아야 하며
프로젝트 외부에서는 불특정 사용자를 설득할 수 있게 의견을 첨언할 수 있다.
이처럼 외부와 내부의 의도를 어떻게 동시 만족할 지가 기획자의 역할이 된다
따라서, 기획자는 넓고 얇게 디자인/개발 도메인의 지식을 겸비할 필요가 있다.
더불어, 기획자는 비즈니스 환경과 사용자에 대해서는 이해도가 매우 높은 수준을 유지해야한다.
기획자는 프로젝트 참여자 중에, 유일하게 이를 이해할 수 있는 사람일 가능성이 높기 때문이다
제프 베조스는 채용에 있어서, 이런 말을 남겼다고 한다.
'우리는 선교사를 원합니다. 용병이 아니라요'
나는 기획자는 선교사가 되야 한다고 생각한다.
지금 추진하고 있는 이 프로젝트가 비즈니스 환경에 노출됬을 때
어떻게 시장과 사용자와 반응하길 원하는지를 끊임 없이 개발자/디자이너에게 주지시켜야 한다.
경험 상, 이런 노력은 프로젝트가 진행될수록 빛을 발한다.
바빠지거나 변수가 발생했을때, 개발자나 디자이너가 기획자의 오판이나 놓친 부분을
되잡아줄 때가 그렇다.
모든 일이 그렇듯, 프로젝트란 시간이 지나면서 바뀌는 부분이 생긴다.
윗선의 지시로 큰 틀의 전략이 바뀔 수도 있으며
비즈니스 환경이 바뀌어 새로운 요구사항이 중간에 들어올 수 있다
이미 진척된 개발 상황과 바뀐 니즈를 조율해야 한다.
우선순위를 둘 수도 있고, 혹은 일부 요구사항을 배제할 수도 있다.
'기획 > PM&PO' 카테고리의 다른 글
XXX 기획 : 사용자 분석 방법론 6 (9) | 2024.09.29 |
---|---|
XXX 기획 : 비즈니스 해석 5 (2) | 2024.09.28 |
XXX 기획 : Product Manager가 되자 4 (1) | 2024.09.28 |
XXX 기획 : 내가 생각하는 좋은 기획자의 조건 3 (1) | 2024.09.25 |
XXX 기획 : 기획에 대한 생각 2 (2) | 2024.09.19 |