개발자가 조직에 기여하는 법 (1-2) - 조직 관점 중 조직 프로세스

(기존 조직 과점 글이 길어 2개로 나누었습니다)

 

이전 글에서 개발자가 조직에 기여하는 법의 조직 관점 중 조직 문화에 대해 생각을 공유했습니다.

• 개발자가 조직에 기여하는 법 (1-1) - 조직 관점 중 조직 문화

이번 글에서는 조직 관점 중 조직 프로세스에 대한 생각을 공유합니다.

조직 프로세스

조직 프로세스에 대해 고민하고 기여해야 하는 이유는 조직 문화에서 설명했던 것과 동일합니다.

그래서 무엇을 어떻게 고민해야 하고 개인 적용 사례는 무엇인지만 간단히 살펴보겠습니다.

무엇을 어떻게 고민해야 하는가  - Git 전략, CI & CD + 타부서 협업

조직이 일하는 프로세스는 개발팀 관점과 다른 팀, 직군(기획, 디자인, 사업 등)과 협업 관점에서 생각해 볼 수 있습니다.

 

# 개발팀 관점

개발자들이 일하는 방식 전반에 대해 고민해야 하지만

개발자들이 일하는 방식에 영향이 가장 큰 Git 전략, CI & CD에 높은 우선순위를 두고 고민하면 좋다고 생각합니다.

 

Git Flow, TBD(Trunk Based Development), Ship Show Ask 전략 등 여러가지 Git 전략, 개발 방법론을 관심을 가지고 팀 상황에 맞는 것들을 적용해 갈 수 있습니다.

 

한번에 모든 것을 할 수 없기 때문에 단계적인 계획을 세워 점진적으로 개선하는 것이 중요하다고 생각합니다.

또 이런 부분은 팀 상황에 따라 적절한 형태가 바뀌고 팀 전체의 노력이 필요하기 때문에 정기적인 점검 미팅을 가지고 개선해 갈 수 있게 하면 좋습니다.

 

# 다른 팀, 직군(기획, 디자인, 사업 등)과 협업 관점

기획, 디자이너, 사업 등 다른 팀과 일하는 방식에 대해서도 고민하고 기여해야 합니다.

 

먼저 문의하는 방법에 대해 점검해 볼 수 있습니다. 서로에게 어떤 방식으로 문의(슬랙 DM으로, 공개 채널로, JIRA 티켓으로 ...) 하는지 파악하고 비효율적인 부분은 없는가, 어떠한 형태로 협업하는 것이 좋은지 고민할 수 있습니다. 담당자를 쉽게 찾을 수 있고, 관련자들에게 효과적으로 공유될 수 있는 방향으로 개선해가야 합니다.

 

그 다음으로는 각 팀 작업의 결과물(e.g. 기획서, 화면 디자인, 개발된 화면)에 대한 소통 방법을 점검해 볼 수 있습니다.

예를 들어 기획의 결과에 대해 검토하는 자리는 언제 해야 하고 누가 참여해야 하는가(개발자가 들어가야 하는가) 등이 있을 수 있습니다.

스크럼을 적용한다면 매 스프린트 마지막 리뷰 시간을 통해 결과물을 공유하는 자리를 마련할 수도 있습니다.

 

회사의 규모에 따라 많이 달라지는 부분이기 때문에 상황에 맞추어 지속적인 점검과 고민이 필요합니다.

개인 적용 사례 - Ship Show Ask 전략으로 10배 빨라진 사이드 프로젝트

사이드 프로젝트를 진행하고 있는데요.

한가지 문제가 있었습니다. 바로 PR 승인 되는 속도가 너무 느리다는 것입니다.

 

회사의 경우 매일 함께 일을 하고 PR을 자주 확인하기 때문에 PR 속도가 심각하게 느려지지는 않았습니다.

하지만 사이드 프로젝트의 경우 각자 일하는 타이밍도 다르고 개인이 실제 투입하는 시간이 일주일에 4-8시간밖에 되지 않습니.

그래서.. PR 승인까지 10일 넘게.. 걸리는 경우가 허다했고 이로 인해 머지 시점에 Conflict가 나는 경우가 많았습니다.

 

그렇다고 PR을 아예 없애자고 하니 그것도 주니어 분들이 많은 상황을 생각하면 좋은 선택지는 아니었습니다.

고민을 하던 중 PR의 성격에 맞추어 구분하고 그에 따라 다른 전략을 사용하는 Ship Show Ask 전략을 알게 되었습니다.

Ship / Show / Ask

 

리뷰가 필요없는 것은 Ship으로 바로 머지, 리뷰가 있으면 좋지만 바로 머지해도 문제가 없는 것은 Show, 리뷰가 필요해서 승인을 기다려야 하는 것은 ASK 로 구분하는 것인데요.

 

적용 후에 정말 10배는 빨라 졌습니다. 저희 상황에 맞는 전략이었던 것입니다.

PR 프로세스에 대한 고민이 있었기 때문에 Ship Show Ask 전략을 보았을 때 그 가치를 알아보고 적용해 볼 수 있었다고 생각합니다.

 

다음글

개발자가 조직에 기여하는 법 (2) - 프로덕트 관점