주니어 기획자로 살기 #개발자랑 일 하기전에 생각했나요?

기획자로 살면 개발자랑 의사소통은 필수다. 하지만 사람마다 업무 성향은 천차만별! 개발자 성향도 천차만별!

개발자랑 일을 잘하기 위해서는 성향 파악이 필요하고, 업무에 잘만 적용하면 원활하고 즐겁게 일할 수 있다.

그동안 만난 개발자들 스타일을 기준으로 한번 정리해봤다. 각각 내가 소통하는 방식을 정리했고 이게 무조건 답은 아니다. 바뀔 수도 있다😀

1. 기획서 안보고 개발하는 개발자

긴장해야 된다... 검수도 배로 꼼꼼히 해야 된다. 어딜 어떻게 해놨는지 모르기 때문이다. 이 성향은 기획 의도를 더욱 견고하게할 필요가 있다. 기획서를 수정하지 않기 위해서 기획한 내용의 정확한 이유를 확보해야 설득에 힘이 생긴다. 그렇지 않으면 당연히? 기획서를 수정하게된다. 이유를 도저히 모르겠으면 상사에게 물어보는 것도 방법이 될 수 있다.

 

2. 검수할 때 개발하는 개발자

개발기간에 개발을 하길 기다리지 않아야 한다. 그리고 검수 때 확인한다는 생각으로 방치하는 것도 좋지 않다. 나는 기획단계에서 개발자에게 확인 요청하는 방법으로 기획과 개발을 은근슬쩍 같이 진행하는 방법을 사용한다. 확인하는 과정에서 다른 이슈가 발생하면 해결할 수 있는 시간을 확보할 수 있어서 개인적으로 매우 선호하는 방법이다.

 

3. 새로운 길을 개척하는 개발자

같은 개발자에게도 영향을 줄 수 있는 성향이다. 새로운 길을 개척하는 개발자의 아이디어는 대체로 더 나은 방법일 가능성이 높다. 그럼에도 불구하고 새로운 길을 갈 수 없는 상황이기 때문에 기존 방식을 유지하는 이유라던지. 특히 영향범위에 대해서 꼭 체크해서 공유하는 것이 중요하다. 이후 API가 수정될 경우 이 방식이 해가 될 수 있다거나.. 새로운 길을 갈 경우 발생하는 미지의 예외사항들이 있을 수 있다던지. 새로운 길이 더 좋은 방법이지만 진행하지 못하는 이유는 꼭 존재하기 마련이다.

 

4. 코드 보여주는 개발자

설명할 때 코드를 보여주는 개발자가 종종 있다. (선생님 저는 개발자가 아닙니다. 전 기획자입니다....) 사실 개인적으로 제일 당황한다...ㅋㅋㅋㅋ 코드가 이렇게 돼 있다 블라블라 일 경우.. "보여주시는 부분이 이런 내용을 말씀하시는 건가요?(대화 주제)" 식으로 코드 없이 대화가 가능한 수면으로 끌어서 천천히 다시 짚어나가는 식으로 진행한다.

"보여주신 부분이 더하기 빼기에 대한 내용인가요? 더하기를 하려면 보여주신 부분을 사용하면 된다는 말씀이신가요?" 이런 식의 대화다. 아니면 단순하게 "제가 코드는 몰라서요. 말로 설명해주실 수 있나요?"를 시도해 보는 것도 괜찮다.

 

5. 일단 안된다고 하는 개발자

선례를 찾아본다. 물론 선례를 얘기할 때 조심스럽게 말하는 것이 중요하다. "이건 되는데요?" 이러면 안된다.. 😅 나는 "진행할 내용이 이 부분과 유사해 보이는데 진행하는 내용과 어떤 부분이 다른지 설명해주시겠어요?"라고 말해보는 편이다. 진행이 불가능한 방어적인 의사소통이 연속될 경우 해결 가능한 다른 방법을 물어본다. 별다른 해결방법을 제안받지 못했을 경우에는 높은 사람을 부르는 것도 방법이다.😉

 

공통적으로 요구되는 의사소통 방식  

원하는 결과가 안 나왔어도 원망하는 말을 하지 않는다. 탓하는 건 해결되는 것이 아무것도 없다.

왜 이렇게 했나요?

이건 이렇게 돼야 해요 

이거 아닌데요?

이런 직설적인 말도 아끼는 것이 좋다. (안 하는 것이 맞다.) 누구나 질책하는 언행을 사용하면 감정에 골이 생겨서 이후 업무에도 영향이 있을 수 있다. 즉 서로에게 좋을게 하나도 없다는 말이다.

일하면서 제일 먼저 버려야 될 생각은

왜 이렇게밖에 못하지? 이렇게 해결하면 되는데 왜 안된다고 하지?라는 생각과 

내 말과 내 생각이 무조건 맞다고 생각하고 행동하는 것이다.