다양한 이해관계자 속에서 서비스 기획자가 동네북처럼 일하기 (feat. 서비스 기획자 되지 말아요)

얼마전에 개발자 기준 같이 일하기 싫은 기획자 이야기를 봤는데요.

안타깝기도 하면서 실제로 현업에서 많이 발생하는 충돌 유형으로 경험했던 케이스들입니다. 

 

 

예를 들어 초기 설계를 하기 위해, 요구사항을 경영진과 같이 논의해야하는 자리에 절대 참여하는 개발자들이라던지..

특히 다른 경영진과 실무진 (개발, 디자이너) 중간 다리 역할을 해야할 때, 한 쪽 설득이 어려워지는 경우입니다. 

회사 여러군데를ㄹ 다니면서 개발 직군과 기획 직군 사이에서 기른건 서열에 따른 눈치게임(?) 이였습니다. 

 

그 중 주니어 개발자와 개발 lead, 기획 lead 사이에 정치 관계에서 살아남아야 했던 후기를 독서 내용과 함께 정리하려구요.

 

 

 

---

 

 

 

 

 

 

1. 기획 N번 변경 

주니어 기획자와 기술 lead 보통 주니어 기획자가 기능 스펙이 나오면 점검차원에서 기술 검토를 요청합니다.

보통 스펙의 축소나 근간이 되는 방향성이 뒤집어지는게 흔한 현상이고, 커리어 초반에는 굉장히 힘들었었죠.

 

이유는

 

a. 기획문서 쓴 시간이 있는데 ㅠㅠ

b. 기획문서는 기획 lead 한테 이미 컨펌 떨어진 것인데, 

c. 문서 이걸 또 작성해? 일도 많은데? 가 있겠습니다.

 

기술 lead, 기획 lead 랑 이견이 좁혀지지 않으면 그 또한 피곤해지는데요.

서로 기획 방향을 이랬다 저랬다....

 

이걸 주니어 기획자 혼자 여기 갔다가 저기 갔다가 커뮤니케이션하는 것보다

모두를 회의 소집해서 동시에 이해관계자를 불러오는게 좋습니다. 업데이트의 최신버전을 최대한 많은 사람과 공유하자는 겁니다.

 

 

 

 

2. 시니어 개발자와의 협업

개발자의 원칙이라는 책에서 시니어 분들의 신규 합류는 기존 주니어 개발자에게 미지의 두려움을 준다고 하는데요,
 
게다가 어찌됐든 업계에서 상위레벨이기 때문에 항상 상대하는게 편안하지는 않죠. 주니어 개발자랑 머리 맞대고 있을 때 심플한 방법을 알려주시면 더 좋은데, 그런 역할을 수행한다기보다, 업무양을 축소하는 방향으로만 가는 것 같아 아쉬울 때도 있었습니다. 
사용자 및 기획의 근거에 대한 챌린지도 시도때도 없이 들어와서 항상 준비된 상태여야했습니다.
 

 

 

---

 

3. 그래서 어떻게? 지원군을 많이 만들자!

 
 
프로젝트와 기능 개선 중에 기획 업데이트가 많아지면서,
주니어 개발자/디자이너가 원하는 방향이 아닐 때 중간다리 역할은 참 어렵더라구요.
동시다발적으로 이뤄지는 업데이트를 공유하면서 개발 착수가 미뤄지는 것도 기획자가 원하는 건 아니랍니다.
 
이런 원치 않는 상황 속에서 부정적인 감정만 쌓이면 제 손해이고, 이런 감정에 내 커리어가 휘둘리지 말자고 생각했어요.
회의 때 참여안하는 인원을 소집하기 위해 이슈를 상위 레벨에 에스컬레이션한다던지, 나의 상위레벨을 활용하는 방향을 잡아보면서 살아남으려고 합니다
 
FYI : 도서 개발자의 원칙 / 인스파이드