Thinking, Writing, and.

이전 글 "R&R을 따지는 놈이 범인?" 편에서 조직 문화를 해치는 썩은 사과를 한 번 찾아봤습니다. 여러 분들의 의견은 어땠는지 궁금합니다. 범인 맞나요? 🧐오늘은 조직 문화를 해치는 범인을 또 한 번 찾아보려고 합니다. 조직을 보면 자신의 의견을 (그것이 부정적인 것일수록 더욱 크고) 당당하게 제시하고, 이 의견에 대해 사람들에게 동조를 구하면서 분위기를 만들어가는 사람들이 있습니다. 저는 이런 사람들을 "빅 마우스"라고 부릅니다. 이 빅 마우스들의 주변에는 대부분 조직의 방향에 불만이 좀 있더라도 순응하는 어린양들이 주로 존재하죠. 그래서 빅 마우스는 이들의 의견을 조직의 상부에 대리 표출해 주는 역할을 맡으면서, 어린양들로부터는 지지를 받고 조직의 리더 계층으로부터는 신임을 얻게 됩니다. 조직 ..

개발 프로젝트를 진행하다보면, 항상 (유연성이 요구되는) 잡음이 발생하는 문제들을 겪습니다. 보통 이런 문제들입니다. "개발 언어는 무엇으로 할 것인가?" "어떤 아키텍처로 할 것인가?""우리의 workflow는 어떻게 할 것인가?" 사실 이런 문제는 유연성과 큰 관련이 없어야 하는 질문들 같습니다. 명확한 답이 있어야 할 것만 같거든요. 이 문제를 해결하기 위한 최적의 시스템 아키텍처가 무엇인가? 우리 팀의 최고 효율을 낼 수 있는 workflow가 무엇인가? 우리 시스템에서 가장 빠른 속도를 낼 수 있는 개발 언어로 어떤 것을 선택할 것인가? 등등이요. 정답이 있을 것 같아서 그걸 찾아내고 싶지 않나요? 그래서 각 candidate의 비교를 통해 장단점을 파악하고, 점수화하여 합리적으로 선택을 할 수..

얼마 전 “R&R을 따지는 놈이 범인이다”라는 주제와 관련된 글을 몇 편 읽었습니다.관련된 글들을 보면 다양한 이야기가 있었습니다. • 조직 간의 협업 문제, • 팀장과 개발자 간의 명확한 R&R 정립, • R&R이 부족할 때 발생하는 갈등 등이 주된 내용이었습니다.저는 이 주제에 대해 개발 조직 관점에서 제 생각을 한 스푼 얹어 보고자 합니다.개발을 하면서 경험했던 다양한 개발자 유형을 R&R을 기준으로 분류해 보면, 크게 다음의 세 가지로 나눌 수 있었습니다.1. R&R에 따라서 일한다.내 R&R이 아니더라도, 긴급한 업무일 경우 적극적으로 협업한다.2. 철저하게 R&R에 따라서만 일한다.내 역할이 아닌 업무는 명확히 선을 긋는다.3. R&R에 따라서 일한다. 하지만 내 R&R에 제약을 두지 않는다...