Tap to restart

코드 리뷰를 하다보면 같은 얘기를 반복해서 적게 된다. 리뷰어 입장같은 얘기를 약간씩 다른 코드에 적게 된다. 리뷰를 하는 리뷰어 입장에서는 처음에는 길게 친절히 적더라도 시간이 지날수록 간략하게 또는 대충 적게 된다. 이미 자신은 다 알고 있는 상황을 적는 것이고, 상대방도 같은 팀 구성원이라면 당연히 알아야 한다고 가정하고 적기 때문이다(참조: 지식의 저주). 예를 들면 "n+1 이슈 있는지 확인 부탁드려요."라는 리뷰가 있다. 리뷰어 입장에서는 꽤 친절하게 적었다고 생각할 수도 있다. 어느 부분이 문제인지 코드 영역을 표시했고, 핵심만 간단히 적었으며, 어떠한 감정도 실지 않았으니까. 하지만 코드 작성자가 n+1 이슈가 무엇인지 모른다면 어떻게 될까. 코드 작성자 입장코드 작성자는 당혹스러운 경우가..

팀원 수와 피자 두 판Jeff Bezos instituted a rule: every internal team should be small enough that it can be fed with two pizzas. 번역: 제프 베조스는 규칙을 제정했다: 모든 내부 팀은 두 개의 피자로 충분히 먹을 수 있을 정도로 작아야 한다. 출처: The two-pizza rule and the secret of Amazon's success, Alex Hern, TheGuardian.com, 2018. 4. 24.제프 베조스의 규칙은 한 사람이 보통 2조각 정도 먹는다면 결국 한 팀은 8명 이내여야 한다는 뜻이다. 8명을 넘어서면 토론이 쉽지 않아 의사소통 시간과 비용이 급격히 커지기 때문이다. 8명을 넘어선 큰 ..

내 느낌인지 모르겠지만 보통 CEO, CTO, COO 등 C레벨은 기업 내 구성원인 직원들의 잡담을 그렇게 좋아하지 않는 거 같다. 하라는 일은 안 하고 쓸데없는 이야기나 한다고 생각하기 쉬운 거 같다. 잡담은 권장할만한 일일까? 권장하는 수준을 넘어서 꼭 필요한 일이다. 잡담이 없는 회사라면? 정말 일만 하는 회사라면 역설적으로 일이 잘 안 되는 현상이 발생한다. 잡담은 윤활유 기업을 자동차라고 친다면 잡담은 윤활유 같은 기능을 한다. 각 부속(서로 다른 팀)끼리 마찰을 줄여주고 더 부드럽게 나갈 수 있게 해준다. 밥도 먹고, 별 거 아닌 얘기도 잡담 시간에 한다면 서로 오해할 일도 줄어든다. 자주 안 만날수록 오해가 생기기 쉽다. 또 서로에 대해서 어느 정도 알고 친해져야 서로 쉽게 의견도 낼 수 있..

대부분 IT 회사들은 서비스는 멈추면 안 되니 꼭 서버 헬스 체크를 한다. 서비스가 멈출 경우 바로 알림이 오도록 해놓는다. 그런데 왜 구성원의 헬스 체크는 그런 시스템을 구축하지 않을까. 팀구성원의 헬스 체크 당연한 말이지만 서비스보다 팀구성원이 더 중요하다고 생각한다. 서비스를 만드는 건 결국 사람이니까. 팀구성원들이 건강하지 않다면? 서비스도 건강할 수 없다. 번아웃 등 어려움을 겪고 있는 팀원이 있을 때 방치하면 팀 전체에 안 좋은 영향을 미친다. 쉬게 해주거나 조치를 취해야 한다. 그렇지 않으면 주변 다른 팀원들도 함께 어려움을 겪게 될 수도 있다. 헬스 체크 어떻게 할 수 있을까 주기적인 설문으로 헬스 체크를 할 수 있지 않을까. 개발팀 내에서 매주 미팅을 가졌다. 그때 몇가지 질문에 대해서 ..

이제 갓 시작한 스타트업 개발팀 시작한 지 얼마 안 된 스타트업이라면, 개발자가 많지 않다. 당연히 신입 위주고 시니어는 많지 않다. 그러다보면 쉽게 성장 한계에 맞딱뜨린다. 자극이 없기 때문이다. 신입 위주에 비슷한 연차의 개발자들이 모였을 때 서로 아는 수준이 비슷하다. 더 좋은 기술, 더 좋은 아키텍처에 대한 관심은 있지만 뭘 어떻게 해야 하는지 모른다. 훔쳐오기! 스타 개발자, 유명한 CTO가 있다면 굳이 훔쳐올 필요가 없다. 내부 안에도 성장을 이끌어 줄 리더가 있으니. 하지만 그렇지 못하다면 훔쳐오는 것도 하나의 대안이다. 어떻게 해야 개발팀 전체가 모두 잘 훔쳐올 수 있도록 자극을 줄 수 있을까에 대한 고민이 필요하다. 게이미케이션. 훔쳐오는 것을 장려하기 게임과 비슷해야 한다. 적절한 자극..