개발자와의 협업은 더 일반화되고 있습니다. 기술 기업이 아니어도 조직에 개발자는 속해있을 수 있고, 조직 구성원에 개발자가 없더라도 신사업 추진 등을 위해 외주 개발자와 쉽게 협업할 수 있는 환경이 되었기 때문에 개발자와의 협업 능력은 더 많은 사람들에게 중요하게 다가오고 있습니다.
특히 외주 개발은 기업의 자원과 시간을 절약할 수 있는 효과적인 방법입니다. 그러나 개발자와의 외주 개발 협업 과정에서 소통 부재, 비용 관리 실패, 기대치 불일치 등은 개발자와의 협업 프로젝트를 실패로 이끌 수 있습니다. 오늘은 국내 1위 IT 아웃소싱 플랫폼 위시켓과 함께 이러한 문제를 예방하고, 개발자 프로젝트를 효율적으로 관리하기 위한 전략을 알아보겠습니다.
✍️ 이 글의 순서
• 개발자, 어떻게 협업해야 하나요?
• 포트폴리오와 레퍼런스. 외주 개발자 관리의 정답 노트
개발자, 어떻게 협업해야 하나요?
1.개발자와 프로젝트 관리 원칙 논의하기
어떤 형태로든 개발자와 프로젝트를 시작하기 전에는 관리 원칙을 갖는 것이 중요합니다. 물론 관리 원칙대로 모든 일이 진행되지는 않습니다. 하지만, 상호 간에 어느 범위까지를 정상적인 수준으로 이해할 것인지를 이해하기 위해서라도 좋은 관리 원칙은 꼭 필요한 항목입니다.
특히 외주 프로젝트를 시작하기 전에는 관리 원칙에 전체 프로젝트의 목표와 과업 범위 설정을 꼭 포함시켜야 하며, 생각보다 상세하게 오버 커뮤니케이션 할 것을 권장드립니다. 초기 단계에서 충분히 논의해둔다면, 향후 생길 수 있는 문제 상황을 풀어가는데 있어서도 큰 도움이 될 것입니다.
2. 개발자와 커뮤니케이션 도구 협의하기
최소한의 커뮤니케이션으로 최대한의 효율을 내기 위해서는 어떤 커뮤니케이션 툴/프로젝트 툴로 관리할 것인지 논의하는 것도 중요합니다. 특히 개발은 방향성이 있는 작업이기 때문에, 중간 지점의 수정은 단순히 고쳤다가 아니라 방향을 틀어야 해 연쇄적인 문제나 과업을 만들어내기도 합니다.
이 지점을 이해한다면, 프로젝트 관리에 용이한 커뮤니케이션 도구를 사용하는 것을 추천드립니다. Slack의 경우, Thread 기능을 지원해 프로젝트의 하위 TASK를 묶음 단위로 커뮤니케이션할 수 있는 장점이 있습니다.
3. 개발자와 적극적으로 커뮤니케이션하기.
개발자와 자주 얘기하지 마라면서 적극적인 커뮤니케이션이라니. 모순되지만 이는 중요합니다. 개발은 방향성이 있다고 말씀드렸죠? 그 방향성에 앞서 선제적으로 발생할 수 있는 문제나 요구사항을 얘기할 수 있다면, 적극적인 커뮤니케이션이더라도 효율적으로 개발 프로젝트를 이끌어 가는 데 도움을 줄 것입니다.
회원가입 기능만 개발하면 될 줄 알았는데, 멤버십 기능까지 개발해야 한다면 “회원가입 개발 후에 얘기해야지”라기보단, 미리 얘기하는 것이 멤버십 기능까지 염두에 둔 회원가입 기능 개발에 도움을 줄 것입니다.
Q. 개발에 익숙하지 않은데 어떻게 선제적으로 커뮤니케이션할 수 있나요?
1) 개발자에게 원하는 걸 다 얘기하고 조율까지 요청해 보세요
2) 생각보다 간단합니다. 회원 관련 기능으로 묶거나, 결제 관련 기능으로 묶거나 하는 방식으로 실제 서비스를 이용할 때 경험하는 것을 기반으로 묶어보세요. 상당히 많은 부분을 교통정리할 수 있을 겁니다
3) 위시켓에 프로젝트 등록하고 프로젝트에 대해 무료 상담받아보세요. 다 수의 프로젝트를 매칭해 준 매니저님이 1)의 개발자 역할을 대신해 드릴 수 있습니다.
4. 개발자 레퍼런스 파악하기
앞서 얘기한 모든 것을 아주 간단하게 파악할 수 있는 방법이 있습니다. 그건 개발자의 레퍼런스를 체크해 보는 것입니다. 이전 프로젝트에서 사용했던 원칙을 그대로 또는 개선해서 사용할 수도 있고, 그건 커뮤니케이션 방식 또한 마찬가지입니다.
또한 적극적인 커뮤니케이션 수준에 대해서 합의하기에도 만들어진 결과물을 중심으로 얘기할 수 있기 때문에 레퍼런스를 서로 간에 맞춰보는 것은 매우 중요합니다. 비 개발자 입장에서도 완성된 결과물이 있다면, 개발자가 얘기하는 ‘수준’을 이해하기에도 쉽고요.
5. 개발자 협업 계약서 꼼꼼히 작성하기
마지막으로는 계약서 작성을 ‘꼼꼼히’ 할 것을 제안 드려요. 모든 외주 계약에는 상세한 작업 범위, 일정, 비용, 그리고 예상치 못한 상황에 대한 대응 계획이 포함되어야 합니다. 상호 간에 최선을 다했다는 말로는 일을 모두 처리하기에는 문제가 있으니까요.
결국 투명하게 책임과 권한을 분배해 가져가야 합니다. 법적 분쟁을 방지하기 위해 계약서에는 권리와 의무, 지적 재산권의 처리 방법 등을 명시하고, 양 당사자가 동의하는 내용을 정확히 반영해야 합니다.
포트폴리오와 레퍼런스. 외주 개발자 관리의 정답 노트
앞서 얘기드린 것처럼 포트폴리오와 레퍼런스는 단순히 같은 제품/같은 도메인의 프로덕트 경험해 봤다 이상의 가치를 가지고 있어요. 개발자가 수행할 수 있는 일부터 대응할 수 있는 업무의 퀄리티까지 볼 수 있는 장치니까요.
하지만 요청하는 회사에서 모두 포트폴리오를 체크하고 레퍼런스를 확인하는 것은 효율적인 방법은 아니에요. 매번 요청하기에는 무리가 있을뿐더러, 개인 프로젝트를 평가받는 것에 불편함을 토로하는 개발자분이 있을 수도 있어요. 설령 이렇게 레퍼런스 프로젝트를 건네받는다고 해도, 하나하나 체크하기도 어렵고 개발적인 부분은 비 개발자 중심의 조직에서는 사실을 모두 확인하기도 어렵기 때문입니다.
🔖 함께 보면 도움되는 글
