- etc
목적조직 Squad
많은 회사가 목적 조직 체제인 Sqaud라는 이름으로 운영되고 있습니다.
각 스쿼드에 속해있는 개발자는 개발자라는 공통점이 있지만, 우리는 스쿼드라는 조직 안에서 각자 일하며 사용하는 언어도 다르고, 기술도 다르고 업무방식도 다릅니다.
Squad로 일하면 본인 도메인에 대해 깊이 고민하고 개선하며 전문성이 깊어질 수 있지만 자칫 시야가 좁아질 수 있어요.
다른 도메인에 대해서는 상대적으로 신경을 덜 쓰기 마련입니다.
우리는 모두 계속해서 성장해야합니다.
개인이 성장해서 더 역량이 커졌을 때 회사에 기여할 수 있는 게 많아집니다. 그리고 그 기여를 통해 회사는 더 큰 회사로 성장할 수 있어요.
또 회사가 성장해서 더 큰 회사가 되면 그 소속 직원은 회사가 작을 때 대비에 해볼 수 있는 게 더 많아집니다. 또 역량을 키울 수 있는 기회가 생깁니다.
즉, 개인은 성장은 곧 회사의 성장이고 그 성장은 다시 개인의 성장으로 돌아오는 구조입니다.
어떻게 하면 개발자 개개인이 더 큰 성장을 이뤄낼 수 있을까요?
같은 직군끼리 모이는 Chapter
제일 위 사진에 이미 힌트는 나와있습니다. Squad 조직을 운영하는 회사의 대부분은 역시 Chapter 조직도 운영하고 있습니다.
각 Squad에서 같은 직군끼리 모은 것을 Chapter라고 합니다.
Squad는 다르지만 같은 직군이라는 것을 활용해 보면 어떨까요?
Chapter 모임에서 몇 가지 시도를 해보려고 하고 있어요.
새로운 기술의 제안
전사적으로 도입해 보고 싶은 기술에 대해 제안해 볼 수 있어요.
우리 로그시스템을 ㅇㅇㅇ 사용해보면 어때요?요즘 ㅇㅇㅇ가 뜨고있던데 우리도 적용해볼 수 있지 않을까요?
Sqaud 에서 막히는 문제들
스쿼드에서 고민중이거나 잘 해결되지 않는 기술들에 대해 질문을 던져볼 수 있어요.
나 혼자 고민하는 것 보다 다같이 고민하면 더 빠르고 대부분의 확률도 더 좋은 결과물이 나옵니다.
기술 전파
화면이 부족해 다 담지 못했지만 Backend 개발자가 공부해야 할 Roadmap입니다.
본인이 어떤 Squad에 속해있는지에 상관없이 백엔드 개발자라면 이 많은 걸 모두 공부해야 합니다.
이런 기술들에 대해 얘기를 나눠보고 소통해 보면 어떨까?라는 생각도 많이 했어요.
`github 에서 본인의 코드를 병합하는 방법에는 위 사진처럼 3가지가 있어요.
3가지 중에 어떤게 가장 좋은 방법이고 어떤게 가장 나쁜 방법일까 라고 생각해보면 정답은 없습니다.
같은 방법에 대해서도 누군가는 회의적이고 누군가는 긍정적일 수 있어요. 이유도 각자 달라요.
이런 토론을 통해 우리는 내가 생각하던 당연한 기능을 상대방의 시야에서 다르게 생각해볼 수 있어요.`
기술발표 방법은
Chapter 모임에서는 한 시간 동안 한 가지 기술에 대해 깊은 부분까지 얘기를 꺼낼 수 있습니다. 시간이 충분하죠.
물론 발표자에게는 부담이 될 수 있습니다. 한번 모임에 최소 20~30명이 모이는 Chapter 모임에서 한 시간 동안 기술 주제로 발표하는 건 막상 쉽지만은 않습니다.
하지만 한 시간 분량의 기술 자료를 준비하는 동안 발표자는 매우 많은 학습을 했을 것이고, 발표를 듣는 사람들 입장에서는 새로운 정보를 빠르게 습득할 수 있는 기회가 됩니다.
구글에서 일하는 방식
최근 Google Developer Group이라는 GDG 컨퍼런스에서 구글이 일하는 방식에 대해 들은 적이 있어요.
Google Korea Search 팀에서 들려준 이야기입니다.
Google Search 팀에서 개발되어 배포하는 새로운 기능은 한국 접속자에게만 노출되지 않아요. 전 세계 구글 사용자에게 모두 노출됩니다.
그럼 전 세계로 배포되는 기능을 개발하는 Search 팀은 한국에만 있을까요?
그렇지 않습니다. 전 세계 약 50여 개 나라에 구글 지사가 있고 그중 Search 팀은 7군데 있다고 합니다.
Google Search 팀은 새로운 프로젝트를 시작하기 전에 관련 프로젝트를 진행했던 팀이 어디 있는지 문서부터 찾아봅니다.
전 세계 수많은 동료들 중에 이미 비슷한 프로젝트를 해본 경험이 있는 팀이 있을 것이고, 메일을 보내 왜 실패했는지 어떤 게 문제였는지에 대한 조언을 들을 수 있습니다.
새로운 프로젝트를 시작하기 전에 위험 요소들을 더 줄일 수 있는 방법이에요.
Chapter 모임에서도 이런 대화가 더 활성화되어야 합니다.
우리 Squad 새로운 기술을 도입해 보려고 하는데, 이 기술을 써보신 분이 있나요? 왜 도입에 실패했나요?
와 같은 대화가 많아져야 합니다.
결론
한 달에 최소 한 번 Chapter 모임을 진행하면 좋습니다.
Chapter 모임에서 기술 전파하는 것도 물론 좋지만 서로가 가진 고민거리를 가볍게 꺼낼 수 있는 자리가 되어야 합니다.
일주일 고민하던 게 한 시간 만에 해결될지도 몰라요.
그리고 회사에서 Chapter 모임을 진행하며 기술 발표를 하게 된다면 좋은 내용들에 대해서는 회사 기술 블로그에 올려보세요.
그 글을 보고 회사에 지원하는 좋은 인재들이 더 많아질 겁니다.
개발자인 우리가 하는 모든 활동은 서로 윈윈하는 행동들이 많습니다.