윤경구의 Log on Java

개발자들은 '일단 안돼'라고 말한다 보통 이런 얘기를 들을 일이 없는데 개발자가 아닌 분들과 얘기하면 이런 얘기를 듣는다. '무조건 안돼' 족이 있고 '무조건 돼' 족이 있다고... (둘 다 말이 안되는 건데 ^^) 실제 개발자들은 자신이 개발하고 있는 모듈의 변화를 좋아하지 않는다. 부담스러워 한다. 해야 할 일이 갑자기 생기는 것에 대해 부담스러워 하는 것도 있고 업무 자체가 좀더 깊은 집중을 요구하는 성향이 있어 일련의 인터럽트에 즉자적으로 반응하는 성향도 학습된다. 그럼에도 함께 제기된 문제에 대해 문제 해결을 위해 토론하고 분석하는 시간을 들이는 것은 마다하지 않는다. 두 가지 허들을 풀어야 한다. 하나는 갑자기 던지면 숙고를 거친 반응이 나올 수 없다는 것 또 하나는 중요한 자신의 업무인 이해 당사자이기 때문에 이해 관계를 내려놓고 판단하기 쉽지 않다는 것 첫번째는 좀더 시간을 주고 문제를 여러번 remind하여 enough thinking 후에 답을 구하는 게 방법이라고 볼 수 있는데 두번째는 좀더 까다롭다. (그런데 이 이해 관계란 이 개발자의 업무 로드가 증가하는 부분이므로 이 의사결정의 주제 관점에서만 보면 크게 중요하지 않은 요소일 수 있다.) 많은 한국의 소프트웨어 개발 회사는 개발 조직이 계층 구조를 이루고 있다. 가장 잘 아는 사람이 개발자인 매니저이고 심지어 핵심 모듈을 개발하기도 한다. 의사 결정에 주요한 권한을 행사하는 사람이 직접적인 이해당사자인 개발자인 경우가 많다는 것이다. 물론 훈련을 통해 개선된다. 업무 로드에 대한 관점, R&R에 대한 관점은 내려놓고 의사 결정 후에 별도 주제로 다루는 게 일반적으로 가능하다 그런데 한 가지 요소를 더 생각해보자면, 풀고자 하는 문제가 무엇인가에 따라 좀더 많은 전문 정보를 공유하고 의사결정의 원칙을 잘 찾는 것이 좋은 의사 결정의 핵심 요소일 텐데 과연 개발자가 문제를 해결하는 전문 정보를 충분히 갖고 있는가, 의사결정의 원칙을 학습을...

신입 코칭을 굉장히 중요하게 생각하고 장시간 직접 챙기는 편이지만 생각해보면 매니지먼트에 대한 코칭이 훨씬 더 중요할 수 있다. 경험적으로 매니저들에 대해서는 코칭보다는 기대치만 부여해서 전체 조직이 비효율적이 되거나 중요한 문화적 자산을 단절시키거나 하는 경우가 많았다. 기술 조직에서 코칭은 기술에 대한 측면이 강하고 기술에 관한 협업적 의사결정의 사례 경험의 성격도 강하다. 곰곰 생각해보면 기술 축면의 코칭이란 전공 요소들을 반영하는 것이라 개인의 상당한 학습 노력과 결합하거나 기반 지식을 갖추고 있을 것을 요구한다. 매니지먼트에 대한 코칭은 그런 전제 조건이 약하기 때문에 훨씬 쉽고 효과도 클 가능성이 있다. 매니지먼트는 의사결정의 원칙에 대한 것이고 이 원칙이 무엇이어야 할지를 세워보도록 경험을 쌓는 게 코칭의 핵심일 수 있다. 의사결정이 계속 관행이나 주어와 목적 없는 프로세스에 의한 것이라면 누구도 새로운 상황에서 혹은 새로운 인적, 환경적 조건에서 의사결정 기준을 정리하고 이에 따라 판단하려고 하지 않을 것이다. 기준을 명시적으로 세워보지 않으면 친소 관계나 관행이 중요한 기준이 될수밖에 없다. 의사결정을 원칙을 세우고 판단하는 과정은 대부분 2,3회면 충분히 학습할 수 있다. 사람을 특별히 싫어해서 독단적 의사결정에 의존하는 경우나 의사결정 자체를 못하는 특수하게 적성에 맞지 않는 경우가 있긴 하지만 수년에 걸친 노력을 축적해야 하는 기술 관련 학습에 비해 정말 효율이 높다고 볼 수 있다. 물론 좋은 의사결정은 각 문맥별로 요구하는 사항이 다르고 그 적응력은 개인차가 있겠지만 많은 경우 충분히 가치있는 의사결정을 할수 있을 것이다.