프로젝트를 수습하러 들어간다.
초보자는 남의 소스코드 까기에 여념이 없다.
"나는 잘못을 많이 알아."
"나는 그 문제를 풀만큼 훌륭한 사람이야."
이 두가지를 어필하고 싶어한다.
팀장이나 고용주에게 말이다.
프로는 그렇지 않다.
거지꼴이 된 소스를 보고 깊은 생각에 잠긴다.
"이놈이 바보가 아니라면 해답을 이렇게 쓰진 않았겠지."
"이런 답을 만든 범인은 아직 이 안에 있겠지?"
이렇게 생각한다.
'아, 나는 여기에 있을건가 말것인가?'
쓰레기 개발자가 없는 건 아니다.
피치 못하게 그 역할을 하는 사람도 있다.
그런 사람들이 쓰레기 소스를 만들기도 한다.
하지만 오늘주제는 아니니까 여기선 제껴두자.
존중, 왜 하는가?
"왜 다른 사람을 존중해야 하는가?"
몸에 베여있는 사람에게 던지는 질문은 아니다.
스탠스를 못정한 사람에게 던지는 질문이다.
대답을 먼저 한다면,
"존중"은 "시행착오"를 피하기 위해 한다.
"시행착오"를 회피함으로써,
내 시간과 돈을 줄이고,
더 효과적인 곳에 내 자원을 투자하려는
"생존본능"이 "존중"의 태도를 낳는거다.
시행착오를 해도 시간이 펑펑 남고,
돈을 헤프게 써도 지갑이 두툼하다면,
그냥 내맘대로 살아도 된다.
꼴 사납다고 욕은 좀 먹겠지만 사는데 지장은 없다.
삶의 밀도는 똑같다.
왜 다른 사람의 경험과 생각에 귀를 기울이는가?
그건 "시간의 평등성", "삶의 등질성" 때문이다.
"등질성"
어려운 말인데, 품질이 동일하다는 뜻이다.
조금 쉬운 말로 하면,
"삶의 농도,밀도가 똑같다"는 뜻이다.
조금 더 쉬운 말로 하면,
"니가 열심히 한 만큼, 저 사람도 열심히 무언가를 한다."
조금 더더 쉬운 말로 한다면,
"내가 열심히 하지 않은 것에 대해서는, 저 사람에게서 배울 게 있다."
누구나 하루 24시간을 겪는다.
무엇을 겪을진 모르지만, 주어진 시간의 농도는 동일하다.
어떤 걸로 바꿀지는 내가 선택해야 한다.
다만 허투루 살지 않았다면,
이 시간을 무언가로 바꾼 삶의 밀도는 일정하다.
누군가 시간을 Java 에 꾸준히 투자했다면
그 사람은 Java 능력이 뛰어날 것이고,
Python 에 꾸준히 시간을 투자했다면,
그 사람은 Phyton 이 뛰어날 것이다.
만일 놀았다면 그 사람은 놀이에 대해서는 뛰어날 것이다.
종목은 달라도, 밀도는 크게 차이가 나지 않는다.
기억하자.
"누구나 자신의 전문분야에서 동일한 밀도, 농도의 삶을 살고 있다."
겸손, 수용
"누구를 믿을것인가 말것인가."
이걸 효과적으로 이용하는 사람이 있다.
바로 사기꾼이다.
사기꾼들은 위험을 피하기 위해
본능적으로 타인의 정보에 민감하다.
그래서 겸손하다.
사기꾼인지 모를 정도로 겸손하다.
그들은 비슷한 일이
자신에게도 일어날수 있다고 생각한다.
그 정보를 얻기 위해 겸손해한다.
내 경험만 훌륭하다고 주장하지 않고,
타인의 이야기를 잘 듣는다.
전혀 이상한 태도가 아니다.
이거 꽤 중요한 생존팁이다.
잘난척에 시간 쓰면서,
자신의 자원을 불태우는 사람이 많다.
"다른 사람의 이야기를 수용할 것이냐 말것이냐."
이건 개인의 선택이다.
"난 그 말에 동의하지 못하겠어."
이렇게 말해도 좋다.
하지만, 적어도 정보가 오는 길은 막지말자.
그걸 열어둬야 한걸음 더 나간다.
이 태도가 협업태도다.
손쉬운 말로 이렇게 말한다.
"태도가 좋다."
협업능력
개발팀에게 협업능력은 매우 중요하다.
협업능력의 기본은 듣기다.
상대방을 인정하는 거다.
사고 치고 떠나간 선임자도 인정하는 거다.
욕은 해도 좋다.
다만 100점짜리 답이 아니라고 해서,
작동하지 않는다고 예단하면 안된다.
60점짜리 답도 작동한다면,
개선해서 100점짜리로 만들수 있는지
살펴보는게 맞다.
"첫술에 배부를 수 없다."
협업능력은 이 전제에서 시작한다.
시스템은 덩치가 커질수록 한번에 만들어지지 않는다.
그리고, 한번에 완벽하게 만들수도 없다.
서비스는 고객과 소통하면서 점점 더 완성된다.
고객의 마음이 갈대같기 때문에
따라잡으려면 자꾸 뜯어고쳐야 한다.
모든 시나리오에 대응한
서비스를 만들겠다고 한다면,
그 희망은 "뇌피셜"에 가깝다.
아무리 서비스를 합리적으로 만들어도,
고객이 합리적이지 않을 수 있다.
생각보다 진상고객이 많다.
전혀 합리적이지 않다.
그래서 합리적인 예측으론 대응할 수 없다.
협업능력으로 사후대응해야 한다.
이걸 잘해야 서비스가 진화한다.
"서비스가 진화한다."
이 사실은 기업이 성장한다는 것과 같은 의미다.
그래서 저크버그가 "기업문화" 운운한것이다.
어떻게 채용할까?
정답이 없다.
겪어보는 수 밖에.
그래서 많은 기업들이 겪어 본다.
아니면 아는 사람을 통해 검증된 인력들만 뽑는다.
물론, 여기에도 정답은 없다.
CEO의 철학마다 차이가 있다.
사업성격에 따라 시각이 다를 수도 있다.
다만 아직 IT사업에 초보자라면,
어떤 사람을 뽑아야 할지 결정하지 못했다면,
우선 "협업능력"에 대해 고민해보길 바란다.
"우리 일에는 협업능력이 얼마나 중요한가?"
고민을 해야 기준이 생긴다.
절대 사람을 막 채용하지 마라.
훌륭한 Java 개발자를 뽑았다고 해서,
좋은 시스템이 나올거라고 기대하는 건,
생각보다 많이 앞서가는거다.
끝.
'멘토링 > 개발팀' 카테고리의 다른 글
개발자들이 맥북을 쓰는 이유 (4) | 2020.02.10 |
---|---|
소프트웨어 프로젝트, 코드네임 정하는 법 (0) | 2020.02.07 |
서버개발 기본기, "데이터 다루기" :: 알고 넘어가자. (0) | 2019.09.11 |
불난 프로젝트, 불끄러 가보기 (0) | 2019.08.23 |
레거시 운영개발팀을 수습하다. (6) | 2019.08.19 |
댓글