이번 챕터에서는 저자의 안 좋은 프로젝트 경험을 이야기하면서 시작한다.
그 프로젝트는 내가 합류하기 10년도 더 전에 시작되었다...
프로젝트는 전형적인 폭포수 방식으로 진행되었다. 2년 반 동안 나는 고객을 한번도 만난 적이 없다. 나뿐만 아니라 개발자 중에서 고객과 이야기를 해본 사람은 없었을 것이다...
회사는 상파울루에 있었지만 100킬로미터 떨어져사는 개발자들까지 채용해서 통근 버스를 제공했다. 나는 새벽 5시 반에 오는 통근버스를 타기위해 새벽 5시 정각에 일어났다...
그 당시에는 야근이 흔해 퇴근 통근 버스를 놓쳐 대중 교통을 이용하면 자정이 훨씬 지나서야 집에 들어왔다.
상황은 점점 악화되었고, 어쩔 수 없이 자가용으로 운전하여 출퇴근했다...
회사는 통근버스를 이유로 출퇴근 비용을 보조해주지 않았다...
집에 돌아가봤자 몇시간 안되어 다시 출근해야 해서 그냥 주차장의 차에서 잠을 잤다...
회사에서는 여러 논이 끝에 회사 근처에 숙소를 마련해주었다...
차에서 잠을 자고, 야근수당도 없이 그렇게 오래 일하는 것은 정상이 아니었다. 친구들은 "도대체 요즘 뭘 하고 있는 건가? 왜 참고 있나?"라고 물었다.
나의 머릿속에는 그런 개념이 없었다...
돌이켜보면 정말 말도 안되는 일을 했다는 것을 깨닫는다. 우리는 프로페셔널하지 못했다. 고객이 실제로 무엇을 원하는지 이해하려 하지 않았고 다른 대안을 제시하지도 않았다...
우리는 그냥 주어진 환경을 있는 그대로 두고, 무작정 일을 밀어 붙였다...
결국 그 모든 노력은 헛고생으로 끝났다. 일정은 늦춰졌고...
그 누구도 우리가 얼마나 노력했는지 알아주지 않았다. 우리는 명예를 얻지도 못했고, 그저 값싸게 노예처럼 일하는 개발자들에 불과했다...
우리가 노예처럼 일할 때 영업, 비즈니스 부서 사람들은 항상 정시에 퇴근했다. 우리는 그들을 위해 헌신한다고 생각했지만 당사자들은 아무런 생각도 없었다...
우리를 공장 노동자처럼, 노예처럼 취급하도록 내버려 두었다.
나도 이런 경험을 여러번 겪어본적이 있다. SI 회사(단순 인력파견소)에서 파견 나간 플젝마다 저런 상황이였고, 그런 환경이 당연한걸로 착각했었다. 다른 개발자들도 그랬다.
SI 업계에서 중급,고급이라는 개발자들도 비정상적인 환경에서도 요구사항대로만 일정내로 화면을 뽑아내는 '공장 노동자' 취급에 아무런 불만도 없었고, 월급만 잘 입금되는것이 중요했다.
말도 일정대로 일을 못하는 개발자는 관리자에게 욕을 먹고 짤리거나 새로운 개발자로 대체되기 일수였고, 프로젝트 상황은 점점 안좋게 악순환이 반복되었다.
나도 막차를 놓쳐 집에 못가고 회사 근처 찜질방에 자주 갔다. 이런 환경에서 일하는게 개발자인줄 알았다. 당시엔 일정대로 어떻게든 화면을 쳐내는게 전문가라 생각했었다. 나도 그런 개념이 없었다.
'아니오'라고 말하는 방법 배우기
빠듯한 일정과 상급 관리자로부터의 많은 압박 속에서 상당수의 프로젝트가 진행된다. 이러한 일정들은 비현실적일 때가 대부분이다.
보통 상급 관리자들은 계약 기간 내에 프로젝트를 끝내려는 욕심에 의도적으로 무리하게 일정표를 만들어 개발자들을 밀어 붙인다...
이에 따른 결과는 참혹하다. 고객은 화를 내며 신뢰는 바닥으로 떨어진다...
정작 불가능한 것을 알면서도 그렇게 개발자들을 압박한 바로 그 상급 관리자는 집에 일찍 들어가고 주말을 가족들과 즐긴다. 그러고는 모든 책임을 개발자들에게 뒤집어 씌운다.
지금도 흔하게 접할 수 있는 이야기고 누구나 겪을 수 있는 사례다.
개발자를 단순 공장 노동자로 취급을 많이하다보니 아래의 짤도 탄생하게 되었다.
우리 개발자들은 그런 상황 전체를 피할 수 있었다. 우리들도 비난을 받아야 한다.
개발자들도 전혀 프로답지 않았다. 이미 불가능하다고 알고 있는 것에 대해 '해보겠다'라고 말하지 말았어야 했다
또 다른 원인이 우리 마음 속에 있었다. 마음 깊은 곳에서는 스스로가 얼마나 잘났는지 내보이고 싶었던 것이다
스스로 도박을 선택했다.
우리가 영웅이 될 수 있다는 망상에 사로잡혀 프로페셔널하게 행동하지 못했다. 우리는 '아니오'라고 말할 수 있어야 했다.
SI 환경에서 '아니오' 라고 말하기 힘들다. 플젝에서 '아니오'라고 말하면 짤리는게 일반적이였고, 당시 신입이였던 나는 짤리는게 무서웠다.
영웅이 되고 싶었다는 저자의 말처럼, 나도 무리한 일정인것을 알면서도 영웅이 되고싶은 생각도 있었다.
잘못되었다는 것을 깨닫기엔 1년의 시간이 필요했다.
불가능한 상황이라는 것을 알면서도 상사에게 "노력해보겠다."라는 말을 어떻게 할 수가 있나?
열심히만 하면 갑자기 불가능하던 일이 가능해지고 전부 완료할 수 있다는 것인가?
아니면 개인 생활과 가족을 모두 희생하고 야근과 휴일 근무를 밥먹듯이 하겠다는 뜻인가?
그렇지 않다면 평소 일을 대충하고 있다는 고백임과 동시에 거짓말을 하고 있다는 것이 된다
'안 된다', '할 수 없다'라는 부정적인 말을 하기 꺼린다. '아니다'라고 말할 때 우리는 무언가 실패한 듯한, 무언가 협조하길 거부한 기분, 좋은 팀원이 되지 못한 듯한 기분이 든다.
프로페셔널리즘은 나 자신과 팀 동료들 그리고 관리자들과 고객들에게 정직함을 의미한다.
관리자가 상사 또는 고객에게 실제 프로젝트의 상황을 투명하게 밝히지 않는다고 느낄 때가 있다...
우리가 직접 관리자의 상사가 포함된 미팅을 소집해서 문제 상황을 공유할 것이라고 말해야 한다.
개발자들은 협상 기술을 익혀야한다.
개발자도 잘못되고 비합리적인거에 대항할 줄 알아야한다.
대안 제시
항상 '아니오'라고만 얘기하는 것은 프로다운 태도가 아니다. 모든 '아니오'에는 반드시 하나 이상의 대안들이 따라와야 한다. '아니오'라고 대답하기 전에 문제를 분석해서 대안이 있어야 한다.
우리가 '아니오'라고 대답해야 하는 상황에서도 항상 '네'라고 말할 방안을 탐색해야 한다.
문제를 어떻게 풀어야 할지 방법을 모를 수도 있다. 최대한 이른 시점에 그 사실을 정직하게 알려야 한다.
무언가 약속은 할 수 없더라도 문제 대응이 어떻게 되고 있는지 진척 상황을 계속 공유해야 한다. 진척 상황을 가능한 자주 공유하는 것이 할 수 있는 최선의 방법이다.
대안을 제시할 수 있었던 적이 있던가? SI 플젝엔 없었다. 시키는 대로만 쉬지않고 일하는 부품이였다.
플랫폼을 만들고 운영을 하게 되면서 SI를 벗어나 사용자를 직접 만나고 비즈니스를 이해하기 시작하면서 대안을 제시하기 시작했다.
저자의 말처럼 대안을 제시하려면 문제를 분석해야 한다. 요구사항이 무엇이고 이를 통해 사용자는 무엇을 하고 얻으려 하는지 비즈니스를 이해해야한다.
그래야 대안을 제시할 수 있다. 요구사항이 적힌 글대로만 읽고 비즈니스를 모른다면 대안을 제시하지도 못하고 '아니오' 만 할 수 있다.
사용자보고 대안을 제시해달라 요청하는 꼴이다.
후기
이번 챕터의 주제는 영웅, 선의 그리고 프로페셔널리즘이다.
악독한 환경속에서 영웅이 되겠다는 욕심으로 더 안 좋은 결과가 기다린다.
선의로 남을 위해 희생하지만 알아주는 사람없이 안 좋은 결말과 헛고생이 될 수 있다.
이런 사례에서 '아니오' 라고 말할 수 있는 정직함과 대안을 제시할 수 있는 프로다운 태도를 가져야 한다는게 이번 챕터의 내용이다.
마지막에 저자는 이런 말을 남긴다.
프로답게 행동하고 고객을 만족시킨다는 것이 고객의 요구사항을 모두 받아들이라는 뜻이 아니다
다시한번 느끼지만, 이 책을 지금이 아니라
신입이나 취준생 때 읽었더라면 어땠을까?라는 아쉬움이 남는다.
잘못된 곳을 거르고 좀 더 나은 환경에서 시작하지 않았을까?
이미 지나간거 미련을 털어버리고 앞으로나 생각해야겠다.
* 직접 책을 읽는걸 추천합니다. 언급안한 좋은 내용이 많아요.
'서적 > 소프트웨어 장인' 카테고리의 다른 글
[CHAPTER 7] 기술적 실행 관례 (0) | 2021.05.06 |
---|---|
[CHAPTER 6] 동작하는 소프트웨어 (0) | 2021.05.06 |
[CHAPTER 4] 소프트웨어 장인의 태도 (0) | 2021.05.05 |
[CHAPTER 3] 소프트웨어 장인정신 (0) | 2021.05.04 |
[CHAPTER 2] 애자일 (0) | 2021.04.27 |