서비스 기업의 개발자로 업무를 하다 보면 기획자와 협업할 기회가 생기게 된다. 기술 검토를 할 때 주로 기획서를 참고하여 구현 가능 여부와 기존에 어떻게 구현되어 있고 어떤 방법으로 해결이 가능한지를 공유하고 기획자가 원하는 정보를 취합하여 구두로 논의하거나 문서 작성을 통해 공유하게 된다. 이 과정에서 기획자를 이해시켜야 하는 경우가 생기다 보니 개발하는 시간보다 기획자와 논의하는 시간이 더 긴 경우가 발생한다. 물론 좋은 서비스 개발을 위해 꼭 필요한 과정이지만 가끔은 입장 차이를 좁히지 못해 답답한 경우도 있다.
신규 입사자인 기획자와 일할 경우에는 더욱 어려움이 따르는 경우가 잦다. 서비스의 복잡도가 높을수록 이해하기가 어려워 서비스를 이해하는 시간을 주었더라도 완벽한 파악이 되기는 어렵기 때문에 기술 검토 과정에서 기획자가 제대로 기획하였는지 검토를 꼼꼼히 해야 한다.
가끔은 기획자가 기획을 제대로 했는지 검토하는 게 개발자의 역할이 맞는지 고민이 들었지만 지나가면서 들었던 개발자는 실제 개발 시간보다 논의하는 데 들어가는 시간이 더 길다는 말이 떠올라 내가 맞는 방향으로 일하고 있다고 느꼈다 개발자는 큰 틀에서 보면 사회에서 해결하지 못한 문제를 IT 기술을 통해 해결해주는 사람이고 그 문제를 겪고 있는 사람이 기획자라면 당연히 문제를 함께 해결해 나가기 위해 노력하는 게 맞기 때문이다.
최근 들어서는 개발자 출신 기획자가 늘고 있다고 들었다. 아마 그들도 나처럼 개발자로서 기술 검토를 하며 내가 직접 기획하면 어떨까? 라는 생각이 강하게 들어 진로를 기획자로 변경한 게 아닐까 싶다.
나는 그들과는 다르게 문서를 작성하고 유저가 원하는 무언가를 생각해 내는 것보다 직접 결과물을 구현하는 개발이 더 재미있고 보람있게 느껴져 개발을 계속하고 있지만 나중에 사이드 프로젝트로 기획해보고 싶은 마음도 조금은 생기고 있는 것 같다.
기술 검토는 결과적으로 기획에 관여할 수밖에 없는 단계이고 이에 따라 기획자와 개발자 모두 성장하는 계기가 되니 기획자에게 기술 검토해주는 것을 긍정적으로 생각하고 본인의 성장에도 도움이 되는 과정 중 하나이니 조금 귀찮은 일이 생기더라도 긍정적으로 수행하는 자세를 가지자.
'IT' 카테고리의 다른 글
| 코드 품질, 기술 부채 (0) | 2024.03.07 |
|---|---|
| [HTML] a 태그를 이용한 다운로드 기능 (0) | 2023.01.05 |
| OSI 7계층 모델 (0) | 2022.08.13 |
| 프로젝트 시작시 해야할것들 (0) | 2021.10.05 |
| ASCII Code, Unicode, encode, decode (2편) (0) | 2021.10.01 |
댓글