@rkttu 님의 의견에 저도 첨언을 하나 더 드리자면, JD는 상당히 중요합니다.
그리고 동종업계여도 회사의 도메인 성숙도에 따라 JD가 달라집니다.
그래서 이제 막 시작하는 회사가 동종업계의 도메인이 성숙할 대로 성숙해버린 큰 회사의 JD를 참고하는 것이죠.
게임업계라면 블리자드, 스퀘어에닉스 같은 기업을 말하는 것입니다.
객체지향에서도 데이터 주도 설계를 하면 내가 필요한 데이터가 무엇인가를 먼저 질문함으로 시작하기 때문에 초반에 빠르게 개발 가능하지만 데이터에 집중했기 때문에 나중에 비지니스가 성숙하게 되면 데이터가 추가되거나 변경이 됩니다.
하지만 책임 주도 설계로 해놓는다면, 하는 역할이 바뀌지는 않습니다. 잘게 쪼개져서 분야가 확장되는 것이지요.
회사에서 일을 할 때도 개발자끼리만 모아두고 다른 비개발팀에서 개발팀에게 외주를 주는 형태로 “코딩은 너네가 다해” 라고 하는게 아니라 각 팀마다 적절하게 서비스 디자이너와 개발자와 PM등 함께 여러 직군이 하나의 분야를 구성하도록 해야 소통비용을 줄이고 팀이 할 일을 갖게 됩니다.
그리고 그 성과를 외부에 노티만 해주면 되죠. 객체지향으로 말한다면 이것이 곧 캡슐화라는 것입니다.
이런 식으로 하게 되면 JD도 책임 주도 설계처럼 여러 직군이 스킬을 공유하면서 하나의 일을 하게 되고 그게 곧 팀이 됩니다.
개발자만 코딩하는게 아니라, PM도 팀의 소통 비용을 줄이기 위해 노코드 로우코드 툴을 통해 자동화를 하는 일같은 업무도 하면서 스크립팅도 할 수 있게 되는 거죠. 서비스 디자이너도 본인의 업무에 코딩을 도입하는 거고…개발자만 코딩하지 않게 되는 것입니다.
그리고 개발자도 PM 업무를 이해하기 위해 애자일같은 방법론도 공부를 하게되고 서로가 서로의 직군을 이해하기위한 소통비용 최적화를 시작합니다.
이것처럼 막 시작할 때는 적은 사람에게 여러 책임과 여러 의존성이 걸려서 정해진 일을 하게 되지만, 서비스를 진행하면서 돈을 벌게 되고 사람들이 뭘 좋아하는지, 뭐가 돈이 되는지 파악하다보면, 사람을 충원하게 되고 돈이 되는 부분을 떼어내어서 TF를 소집하던지, 추가 채용을 통해 사세를 확장합니다.
프로그램으로 치면 모듈러 모놀리스가 MSA로 발전하는 과정으로 비유할 수 있겠습니다.
그러면서 기존에 회사에 없던 직군들이 생겨나기 시작합니다.
하지만 그 직군이 반드시 유명한 회사들의 JD와 동일하지는 않습니다.
동종업계이긴 그 회사만의 특징을 이해하는 직군일 것이고 도메인 성숙도에 맞는 직군의 JD 일 것입니다.
동일하다면 도메인 성숙도가 같거나, 밴치마킹하는 회사와 완전히 같은 일을 해서 경쟁력이 없거나, 아니면 JD를 잘못써놓는 경우일 것입니다.
JD에 대해서 나와서 그냥 관련없는 말 해봤습니다.
제 의견 참고만 해주세요~