소프트웨어 개발자의 딜레마

 

 

시장을 돌아다니면서 자주 보게 되는 현상이다.

현상을 기록하기 위해 정리한다.

 

"개발자의 딜레마" Dilemma of Software Developer

법칙 : "대부분의 개발자는 의사결정권자에게 시스템의 문제를 이해시키는 데 실패한다."
* 의사결정권자 Stakeholder = CEO, 담당이사 등

 

대부분의 개발자는 자신이 처한 문제를 보고하기 위해,

그 문제가 회사의 큰 부담이 될거라고 예상하기 때문에,

또는 미래에 새로운 문제가 될 거라고 믿기 때문에

경영진에게 매우 심각하다고 보고하려한다.

 

그러나 그 심각성에도 불구하고,

보고는 매우 자주 실패하고 만다.

오히려 상황이 악화되기도 한다.

 

그래서, 개발자는 문제가 생겼을 때 보고할 것인가 말것인가를 놓고 고민하게 된다.

 

관찰되는 현상

개발자는 의견을 전달하려고 하기보다,

사실을 설명하고 이해시키려고 노력한다.

설명이 장황해지고 우선순위, 중요도가 헷갈린다.

그래서 경영진에게 전달되어야 할 메시지가 사라진다.

CEO 는 이해하지 못한채 잘못된 의사결정을 내린다.

악순환이 반복된다.

 

아주 자주 반복 관찰되는 현상이다.

CEO가 소프트웨어 개발에 이해가 없거나,

어설프게 이해를 하고 있는 경우에

거의 100% 발생한다.

 

CEO의 수용모습

초보사장을 만나면 종종 이런 이야기를 한다.

소프트웨어를 잘 모르는 경우 대개 이런 공통된 반응이 나타난다.

 

유형1. 만난지 얼마 안된 팀의 경우

 

개발팀장이 뭔가 심각하게 이야기를 했는데 무슨 말인지 못알아 듣겠어.

알아들기 쉽게 설명해달라고 했는데, 더 못알아듣겠어.

음, 겨우 이해하긴 했는데, 정말 그게 중요한건지 잘 모르겠어.

개발팀이랑 이야기하기 정말 어려워.

 

유형2. 신뢰관계가 깨어진 경우

 

우리 개발팀장은 항상 헛소리만 해.

사업이 어떻게 되는지는 전혀 관심이 없어.

 

어쨌든 둘다 커뮤니케이션에 실패한거다.

하지만, 이 현상이 개선되지 않으면,

개발팀의 "기술력"은 "사업자산"으로 바뀌지 않는다.

뭘 만들어야할지 모르니, 이상한게 만들어질 가능성이 높다.

 

인식

경험상 개발자의 소통스킬이 좋아지는 건 매우 드물다.

분석적이고 모듈화된 사고체계는

소프트웨어 개발에는 매우 적합한 도구이지만,

5분이내 필요한 딱 한가지만 전달해야 하는,

경영환경에선 잘 작동하지 않기 때문이다.

 

문제를 방치하고 중요한 것 하나만 선택하는 건

시스템 장애, 사업적 손실에 직결된다.

그래서 개발자에겐 기대할 수 없는 태도이다.

 

그래서, 소통이 잘 되는 조직을 보면,

CEO가 요령을 발휘하는 경우가 많다.

 

말하는 쪽을 변화시키기 보다.

듣는 쪽에 번역기를 달아주는게 좋다.

 

훌륭한 사장님들

IT사업을 하려면 개발자와 소통이 가능해야 한다.

소통이 잘될수록 진도가 잘 빠진다.

 

그냥 노가리난 깐다는 게 아니다.

진행중인 사업상황과 자원투입, 문제현상 식별 등.

실무에 대해 소통할 수 있어야 한다는 뜻이다.

 

개발자한테 네네 하라는 이야기도 아니다.

듣고 자기 생각도 잘 전달해줄 수 있어야 한다.

주거니 받거니가 해야 진도가 빠진다.

"개발자 소통학".

이런게 있으면 좋겠다는 생각이 든다.

 

소통이 잘 되는 개발팀장은 비싸다.

파트타임으로 빌려쓰는 게 IT컨설팅이다.

돈 없는 스타트업이라면 둘 다 어렵다.

그냥 사장이 열심히 대화하자.

조금만 노력하면 익숙해질 수 있다.

또는 좋은 개발자 친구를 많이 사귀자.

의리로 도와줄 수도 있다.

 

기타

개발자도 아닌데 개발자와 비슷한 방식으로 소통하는 사람들이 있다.

좀 신기하긴 하다.

 

그런 걸 보면 저런 현상이 개발자에게 많이 나타나긴 하지만,

개발자라서 나타나는 현상은 아닌 것 같다.

 

끝.