[CHAPTER 12] 낮은 사기의 대가

개발자들의 낮은 사기는 소프트웨어 프로젝트 실패이 주된 이유 중 하나다.

애자일 절차들과 애자일 실행 원칙들을 기반으로 개발하고 있다고 전제한다.

이번에는 애자일이 실행되고 있는 상황에서 낮은 사기로 발생하는 사례를 다룬다.

 

 

애자일 행오버 : 낮은 사기

거의 대부분의 회사들이 나름대로 애자일 전환을 경험했다. 애자일로 전환하고 몇 년 후, 예외 없이 제품 개발 역량이 여전히 뒤떨어져 있다는 것을 깨닫고 있다. 이 깨달음을 애자일 행오버라고 부른다.

애자일로 전환되었고 몇년이 지났으면 구성원 모두가 변화에 발 빠르게 대응하지 않을까? 왜 개발 역량이 떨어진다고 할까...

 

애자일 행오버에 빠진 회사들의 흔한 문제는 사기가 낮다는 것이다. 개발자들이 불평할 때가 많아지고...
관리자들이 실제로 뭘 해야하는지 정확히 아는 사람은 없다...
다른 부서의 서로 다른사람들이 상충되는 요구사항들을 마구 던진다...

다른 부서들이 서로 상충되는 요구사항을 주는 거부터가 난감하게 만드는 이야기다.

어떤 요구사항을 들어줘야할지 선택할 수도 없고, 다른 부서가 서로 협의해야 할 사항이기도 하다.

그런 상황에서 관리자들이 뭘해야하는지 모른다면 프로젝트는 이상하게 흘려가고 있다고 생각해 볼 수 있다.

개발자들이 불만을 표출할 수 밖에 없는 안 좋은 상태다.

 

이러한 상황에 처한 개발자들은 자신들이 그저 코딩 기계일 뿐...
프로페셔널로서 대우받지 있지 못하다고 느낀다...

제대로 된 애자일 조직이라면 지식 노동자들이 일을 즐겁게 할 수 있게 자율성과 목적의식을 제공할 수 있어야 한다.

애자일 방법론을 실천하고 있지만 여전히 개발자를 공장 노동자처럼 취급하는 분위기가 문제다.

 

현실은 애자일 도입을 새로운 전찰 정도로 이해하는 회사들이 많다...
개발자들이 새로운 절차를 기계적으로 따르기만 하면 일이 되는 줄로만 안다...
개발자들은 여전히 과거와 똑같은 방식으로 개발한다...
동기 부여가 되어 있지 않았다면 애자일 도입 이후에도 마찬가지다.

애자일을 도입했지만 기술적인 측면을 전혀 고려하지 않은 잘못된 도입에 대한 나쁜 사례이다.

 

 

그저 '출퇴근'만 하는 개발자들로 인한 대가

열정적인 개발자들에게 '출퇴근'만 하는 개발자들을 어떻게 해야 할지 물어보면 회사에서 모두 쫓아내는 것을 떠올린다...
'해고'가 상당수 옮기는 하지만 항상 그렇지는 않다.

열정적인 개발자들 사이에서 열정 없이 출퇴근만 하는 개발자가 있을 수가 있을까 생각해본다. 보통 같이 하자는 분위기에 으쌰으쌰할텐데 얼마나 열정이 없으면 이런 소주제가 나왔을지 궁금하다.

 

열정의 부재 자체가 열정적인 개발자들을 화나게 한 것은 아니다.
열정적인 개발자들을 화나게 하는 것은 온갖 노력을 쏟는 동안 다른 개발자들이 그저 구경하거나 심지어 방해하는 것이 화가 날 뿐이다.

열심히 문제를 해결하고 노력하고 있는데 옆에서 구경만 하고 알짱거리다가 뜬금없이, "그거 아닌데 ㅋㅋㅋㅋ" 비웃는 소리를 들어본 적이 있는가?

개인적으로 구경은 그나마 양호하다. 방해하거나 흐름을 끊는 행위를 하는 방해꾼이 문제다. 문제 해결에 다른 방안을 제시하지도 않고 해결하려고 노력하는 사람의 열정을 끊어버리는 행위는 누구나 화가 날만하다.

 

다음은 저자가 겪은 파견 이야기다.

어느 다국적 미디어 회사가 내가 일하던 컨설팅 회사를 찾아온 적이 있다. 그들의 팀을 도울 개발자를 찾고 있었고 내가 그 개발자가 되었다...
14년이나 된 레거시 시스템을 대체할 새로운 시스템 개발이 내 역할이었다...
그 레거시 시스템을 만들었던 외주 업체는 사라지고 없었고 서투른 개발자 몇 명만 유지보수하고 있었다.
항상 그렇지만 상황이 안 좋아지면 제일 먼저 가장 능력 있는 개발자들이 떠나간다...
그 프로젝트는 3년 전부터 진행되고 있었다...
프로젝트를 책임지던 IT 부서장은 자기 컴퓨터를 어떻게 켜는지 겨우 알고 있는 수준이었다.

3년전부터 진행이 되던 프로젝트의 책임자는 IT를 전혀 모르는 사람이다.

책임자가 개발자가 아니어도 IT를 어느 정도 알고 관리라도 잘했으면 그럭저럭 잘 진행되었을 수도 있다.

 

그 프로젝트의 사람들은 서로 이야기하는 일도 드물었고...
몇 달이 지나도록 회식 한번 하지 않았다...
최악인 것은 그 프로젝트는 비즈니스적으로 우선순위가 높지 않았다...

3년간 진행된 프로젝트의 구성원들이 서로 대화가 없고 회식도 안하다니... 얼마나 문제가 있는지 예상할 수 있는 대목이다.

 

나는 에너지가 넘쳤고 프로젝트가 제 궤도를 찾을 수 있도록 영향력을 발휘할 준비가 되어 있었다...
그런데 미팅 때 팀원들이 모두 참석하는 일이 드물었다...
일정 추산이나 우선순위 정의는 없었다... 결과가 나오든 말든 아무도 신경을 쓰지 않았다...

요구사항에 대한 결과가 나오는지 아무도 신경을 안쓰다니...

그 누구도 얼마나 관심이 없으면 이런 상황이 되었을지 궁금하다. 프로젝트 관리자는 무엇을 하고 있었을까?

 

몇 달 동안은 일부분이라도 질서를 부여하려 노력했다...
각 개발자들에게 동기 부여하기 위해 페어 프로그래밍을 했다. 그들에게는 낯설기만 한 TDD를 가르쳐주려 했다.
"그런걸 하는 이유가 뭐죠? 바보같습니다."
"사실 저는 별 관심이 없습니다... 그런 것들에 왜 스트레스 받아야하죠?.." 라는 답만 따라왔다.

모든 노력을 부정당한 저자는 얼마나 감정 소모가 많았을지 상상도 안간다.

 

8개월 동안 이런저런 방법으로... 노력했다...
그것도 생각대로 되지 않았다... 팀 구성원들과의 언쟁만 더 늘었다.

최후의 수단으로, IT 부서장에게 직접 이야기했다. 그런데 그 역시 크게 신경 쓰지 않았다.
".. 소프트웨어란게 그래요. 복잡하고 오래 걸립니다... 어쩔 수 업습니다. 일이 원래 그렇습니다."

프로젝트 상황은 전혀 신경 쓰지도 않고, 다른 사람의 말을 무시하는 태도를 보니 프로젝트가 요지경으로 만든 원인은 책임자가 아닐까 생각해본다.

 

문제를 고객사의 고위직까지 이슈화시켰고 결국 팀원 전체가 교체되었다...
IT 부서장은 사라졌다. 그가 해고되었다는 이야기도 들었다.

책임자와 구성원이 교체되고 정상적으로 진행되었다는 저자의 사례다.

 

 

낮은 수준의 동기가 만드는 제약

어떤 구성원이든지 간에, 회사가 좀 더 나아졌으면 하는 항목들을 생각할 수 있다. 그렇다면 왜 노력들을 하지 않을까?
다음은 그 이유에 대한 몇 가지 목록이다.

- 자신에게 아무런 권한이 없다고 생각한다.
- 이끌어가야 할 당사자가 되고 싶지 않다.
- 복잡한 장애요인이 많다.
- 바뀌는 것이 가능하다고 믿지 않는다.
- 사람들의 동의를 받기 힘들다.
- 상관없이 출퇴근만 하면 된다.

개선하지 못하는 이유는 동기가 낮기 때문이다.

저자가 나열한 이유를 보면 누구나 동감이 될만한 내용이다. 일반적인 직원이 변화를 시도하겠다면 같이 동참하겠다는 동료가 얼마나 있을까?

대부분의 사람은 마지막의 이유 출퇴근만 하면 된다처럼 현재 상태를 계속 유지하고 싶지 않을까 생각이 된다.

그런 상황속에서 변화를 시도하려고 노력하는 사람은 얼마나 높은 동기를 가지고 리더쉽을 가진걸까?

 

 

개발자들에게 열정을 불어넣기

동기를 부여하는데 가장 효과적인 방법은 외부로부터 소프트웨어 장인을 수혈받는 것이다.

저자같이 뛰어나고 열정을 쏟는 사람이 동료로 들어온다면 어떻게 될지 궁금하다.

 

보통의 개발자와 소프트웨어 장인의 차이점 중 하나는 장인의 경우 스스로 설정한 임무가 있다는 점이다.
장인은 가치를 전달하고 사람들에게 영감을 불어넣기 위해 모든 노력을 아끼지 않는다. 변화를 이끄는 데 두려움이 없다.

변화를 주도하는 건 누구나 할 수가 없다. 실패하면 그 책임감부터 시작하여 위에서 언급한 제약 요소들이 많기 때문이다.

소프트웨어 장인은 그러한 요소에 대해 두려움 없이 시도한다는 게 얼마나 열정이 뛰어난지 알 수가 있다.

 

소프트웨어 장인은 명령하는 대신 지식과 경험 열정을 나눈다.
항상 멘토로서 행동하는데 주의를 기울인다. 자기계발 활동을 다른 사람들과 공유하려 한다.

일반적인 사람이라면 노하우를 함부로 알려주지 않는다. 그게 본인의 경쟁력이고 몸값이며, 밥줄이기 때문이다.

하지만 소프트웨어 장인은 업계의 발전을 위해 지식을 공유하려 한다.

 

---

후기

이번 챕터는 동기에 대한 주제였다.

동기는 프로젝트에서 가장 중요한 핵심이다.

구성원들이 모두 높은 동기가 있고 열정이 있다면 프로젝트는 목적지까지 순항할 것이고 좋은 결과를 얻을 수 있다.

하지만 낮은 동기와 열정이 없다면 프로젝트는 망망대해에서 사방에서 불어오는 바람과 흐르는 물길에 따라 하염없이 떠돌아다닐 수도 있다.   

그리고 개인적으로 더 중요한 건 구성원들을 목적지에 갈 수 있도록 올바르게 지휘할 관리자라 생각된다.