[SI이야기] 업무 범위는 끊임없이 깎아야 한다

오랜만에 SI이야기를 해보려고 한다. 우연찮은 기회에 만난 사람이 자기의 특기이자 장기가 '일 늘리는 것'이라는 말을 듣고 놀란 기념으로 적게 되었다. 

 

깎는 이야기를 하기 전에, 일을 늘리는 사람과 일을 줄이는 사람이 누군지 설명해보겠다. 그리고 어떤 경우에 그 일이 좋은 일인지에 대해서 설명하겠다.

 

 

1) 일을 늘리는 사람

 

좋게 말하면 '사업을 만드는 사람'이다. 흔히들 구두 고치려고 맡기면 'A를 고쳐야 하는데, B랑 C도 문제가 있네요.'라고 하면서 더 많은 걸 고치게 권하는 사람이 이런 사람이다. 일을 만들어야 돈이 생기는 사람. 그래서 사업을 '만든다'라는 표현을 쓴다. 이런 사람들은 작은 건수 하나만 쥐어주면 서버 1대 교체에서 심하게 말하면 차세대 프로젝트까지 뻥튀기하는 능력을 가진 사람이다. 사업을 만드는 일을 하는 사람은 일을 늘리면 칭찬을 받는다. (단, 고객 예산 범위 내에서!)

 

 

2) 일을 줄이는 사람

 

일을 늘리는 사람과 반대로 일을 줄이는 사람은 실무자들이다. 실제로 시스템을 구축하고 프로젝트를 시간 안에 종료해야 하는 사람. 이런 사람들은 Yes Man이 리더인 경우 괴로워한다. 계약서 범위 밖의 요구를 하면 팍팍 잘라내고 튕겨내고 철벽 치는 사람을 좋아한다. 계약서에 있는 내용도 줄이는 사람이 실무자들이 가장 사랑하는 사람이다.

---

나요? 슈 과장은 '일을 줄이는 사람'이다. 그것도 아주 무섭게 줄이는 사람이다. 고객사에게 '네~ 네~ 그럼요~ 해야죠~'하면서 다 줄여버리는 사람이다. 오늘은 이 '일 줄이는 법'에 대해서 이야기해보려고 한다.

 

오늘 이야기하고 싶은 포인트부터 이야기하자면 프로젝트의 업무 범위는 프로젝트가 끝나는 그 순간까지 줄여야 한다. 계약서에 쓰여있더라도, 고객이 협박하더라도 줄여야 한다. 어떠한 변명도 통하지 않는다. 줄여야 한다. 비만인 사람이 살기 위해서 다이어트를 해야 하듯이, 프로젝트가 살려면 업무 범위를 줄여야 한다. 왜냐? 가만히 있으면 범위는 끊임없이 늘어나기 때문이다.

 

 

1. 일은 왜 늘어나는가?

 

신기한 일이라 생각할 수 있다. 분명히 계약서를 썼는데 왜 범위가 늘어날까? 그 이유는 간단하다. 계약서는 큰 말만 쓰여있기 때문이다. 계약서가 '놀이동산을 지어줘'라고 쓰여있고 그 말에 동의했다면 당신은 모호한 무언가를 만들기로 동의했을 뿐이지 명확하게 그게 어디까지인지 모르는 상황이다. (좋다, 오늘은 놀이공원 비유다!)

 

'아, 아니에요 난 무엇을 만들어줄지 썼어요'라고 주장한다면 그 계약서를 내가 보고 싶다.

 

CASE 1 : '놀이기구 5개'를 지어준다

모호하다. 놀이기구가 얼마나 범위가 천차만별인데! 당신이 생각하는 건 회전목마 5개 일지 모르지만, 고객이 생각하는 건 롤러코스터 5개일 수도 있다. 그것도 온갖 각도로 돌고 도는 엄청난 롤러코스터. (trust me. 고객은 꼭 그런다.)

 

CASE 2 : '놀이기구 5개' & 예산 범위

모호하다. SI라고 하면 결국 하드웨어 사양이 정해져 있고, 투입된 사람이 정해져 있을 뿐이다. 하드웨어 사양을 꽉꽉 채워서 쓰고, 9 to 18 일할 사람이 9 to 22 + 월화수목금금금 일한다고 하면 그 범위는 또 천차만별이 되는 것이다.

 

CASE 3 : '놀이기구 5개' & 예산 범위(9 to 18, 월-금)

위험하다. 왜냐? 언제나 문제가 생기기 때문이다. 개발하다가 막힐 수 있고, 유관부서가 협조가 늦을 수도 있고, 개발자가 아플 수도 있고 등등. 그런 와중에 개발자가 기계처럼 꾸준히 정해진 시간 동안 일을 할 거라 생각하는 건 위험하다. 고객이 마음이 변할 거라고 생각 안 하는 것도, 유관부서가 바로바로 협조해줄 거라 생각하는 것도 위험한 발상이다. 순진하지 말지어다.

 

 

2. 일은 어떻게 줄이는가?

 

고객이 일을 늘린 것과 같은 원리로 줄여야 한다. 계약서를 변경하지 않고 줄이는 방법을 터득해야 한다.

 

1) 모호한걸 정확하게 정의하자.

놀이기구 5개면 5개가 무엇인지 정의를 해야 한다. 크기, 길이, 구조, 색상, 설비, 가용 자원 모두 다 정의를 해야 한다. (이게 분석/설계다!) 어떤 서비스를 만든다면 사용자가 누군지를 확인해야 하고 (놀이기구 좌석 크기를 좌우하고, 안전성 요건을 좌우할 수 있음), 서비스에 따라 어떤 추가적인 조치가 필요할지 검토를 해야 한다. (보안이 더 필요한가? 암호화가 요구되는가? 접근 제어가 필요한가? 등등) 이 추가적인 조치 하나하나가 개발자의 개발 일정에 하나하나 추가된다고 봐야 한다. 하루에 짠하고 이루어지는 법은 없다.

 

2) 계약한 개발자 리소스의 80%로 배분을 하자.

동일한 범위를 개발해도 깊이, 정교함, 속도 등등 퀄리티의 차이를 내게 할 수가 있다. '당연히 A수준이겠지!'라고 생각하지 말고 '우리가 할 수 있는 수준이 어느 정도인가?'를 생각하자. 그리고 100%를 다 할 때를 감안하고 일을 받지 말고 80%를 감안하고 일을 받도록 하자. 그래야 개발자가 죽지 않고 살아서 개발을 완료할 수 있다. 그리고 그 80%를 완벽하게 끝낼 수 있다.

 

1)에서 정의를 그렇게 구체적으로 했는데 그게 어떻게 가능한가요!?라고 묻는다면 예를 들면 이런 거다. 회전목마를 만들어야 하면 다양한 모양과 자세의 말을 넣지 말고 동일한 말을 넣는 거다. SI로 치면 개별 화면을 기획/디자인 안 하고 하나의 화면을 최대한 재사용하는 것. 이렇게 한다고 요구사항에 틀린 건 하나도 없다. 개발도 훨씬 용이하다. 무엇도 모호하지 않다. 모든 요구사항을 충족한다.

 

여기서 중요한 건 내가 배분을 개발자 리소스의 100%로 했다는 사실을 고객이 알게 하는 것이다. 가끔 눈치가 백 단인 고객은 '그건 금방 해요.'라고 나를 이겨먹을 수도 있는데, 그럴 땐 '아 고객님이 맞습니다. 다시 조정할게요'라고 하지 말고 '제가 보기엔 그것보다 더 오래 걸릴 것 같은데 확인해보겠습니다'라고 대답하고 아주 조금 조정해주면 된다.

 

 

3) 새로운 일이 생기면 기존의 일과 협상을 하자.

위에서 말했지만 일은 늘어난다. 프로젝트하면서 일이 늘어나지 않았던 적은 단 한 번도 없었다. 고객이 계약서에 없던 걸 준 것도 아니었다. 심지어 뺄 수 없는 필수 조건들이 갑자기 튀어나와서 일이 늘어나기도 한다. 그럼 누구도 거절할 명분을 가지지 못한다. 싸울 수도 없는 그런 요건이 나오게 되어있다. (예: 정부 가이드라인이 바뀌었어요)

 

그럴 땐, 무조건 '아, 해야겠네요'하고 받아야 한다고 생각할 수 있다. 하지만 당신이 PM, PL이라면 명심해야 하는 게 있다. 당신은 계약서의 내용과 고객 요구사항을 알고 이미 요구사항명세서/정의서를 다 썼고, 그렇게 리소스를 배분해서 일을 하고 있다는 사실이다. '아, 해야겠네요'하고 일을 받는다는 건 애초에 여력이 된다는 걸 증명하는 것이다.

 

이럴 때는 '지금 리소스가 100% 쓰이고 있으니 그 추가분에 대해서 변경계약(추가 계약)을 해주셔야 합니다'라고 말하거나, 도저히 계약을 들먹이면서 서로 난감하게 하기 싫다면 '이걸 하는 대신 무엇 하나를 빼주세요'라고 말해야 한다. 그리고 이럴 때는 무조건 무조건 고객이 빼줄 수 있는 걸 꺼내야 한다. 그러면 이 싸움은 100% 이긴다.

---

내가 일을 줄였던 경험 몇 가지를 이야기해보겠다.

 

1. 계약서상 업무 범위가 많다는 걸 알고 기회를 노리다가 줄인 경험

계약서의 업무 범위가 말이 안 되는 프로젝트가 있었다. 그냥 뭐, 계약한 우리가 바보였달까? 그렇다고 거절할 수도 없었고, 고객도 양보를 안 하는 그런 계약이었다. 그래서 회의에서 빠른 대응, 요건 정의, 현업 상시 참여를 조건으로 걸었던 적이 있었다. 그리고 그 대응이 이루어지지 않고 있다는 사실을 가시적으로 드러냈고, 옐로우 카드 -> 레드카드가 되는 시점에 긴급회의 소집을 해서 업무 범위를 줄여버렸다. ('당신들이 빨리 도와준다고 해서 계약했는데 안 도와줬잖아. 내가 잃어버린 시간 어떻게 할 거야. 나 계약한 거 시간 안에 다 못하게 됐다고. 이건 너네가 약속을 안 지킨 거야')

 

2. 말도 안 되는 요구사항이 왔을 땐, 안 되는 실패 결과를 가져다줘서 줄인 경험

신기술이 들어가는 사업을 하면 때론 구현 불가능한 걸 만들어달라고 하는 경우가 발생한다. 그럴 때 개발자가 '안돼요'라고 잘라서 말하면 고객은 화가 나는 법이다. 기분이 상해서 사적인 감정으로 강요하기도 하고('해내!'), 태도 문제로 일을 확대해서 다른 업무에서까지 괴롭히기도 하고 다양한 방향으로 악영향을 주기도 한다.

 

이럴 때는 우선 요건을 듣고 '난감한 표정'을 짓고 -> '알아보겠다' 아니면 '한 번 해보겠다'라고 대답하고 -> 아주 단시간에 2-3가지 방법을 시도해서 다 실패한 이후 그 결과를 공유하면 된다. 이 짓을 하다가 귀한 개발 기간 1주일을 날려버리긴 했는데, 여러 가지 시도 + 한계점 + 해결방법을 설명했더니 아주 다정하게 포기해주셨다. ^^ 중요한 것은 아주 빨리 Quick Fail을 해야 한다는 것이다. 그걸 어설프게 들고 질질 끌다가 못해 내면 할 거라고 믿은 고객에게 미움만 받을 뿐이다. 왜냐? 그 시간 동안에 고객은 자기 상사에게 그렇게 할 거라고 보고했을 테니까.

 

 

3. 모호한 요건을 나에게 유리하게 해석해서 돌려준 경험

아주 단순하게 '놀이동산을 지어줘'라고 요구사항을 준 고객에게 자세한 요건을 알려달라고 했더니 '니가 전문가잖아요. 알아서 해주세요'라고 하길래 '디즈니랜드'를 기대했던 고객에게 '롯데월드'를 가져다주었다. 계약서, 요구사항정의서, 회의록 어디를 뜯어봐도 뭐 하나 어긴 게 없었다. 놀이동산에 놀이기구가 5개였고, 사용자도 요구한 사용자였고, 개발자도 계약한 개발자들이 열~심히 일해서 해냈다. 심지어 중간에 이상한 요구사항과 반드시 해야 하는 조건과 단순히 고객님이 '심미적으로 별로다'라고 해서 수정까지 해서 완성시켰다.

 

프로젝트 수행하러 들어갔을 때만 해도 '이 범위를 무슨 수로 이 기간에 이 개발자들 데리고 하지!?'라고 고민했었다. 근데 최소화하는 방법을 찾아내고, 계약서 외의 범위를 받지 않았고, 무리한 요구는 내가 아닌 고객을 걱정하는 마음으로 설득해서 줄였다.

---

SI 프로젝트를 하면 종종 '고객만족'이 최고라고 생각해서 고객이 해달라는 건 다 해주는 사람들이 종종 나타난다. 하지만 고객 만족은 결국 그 고객이 자기 상사에게 좋은 평가를 받는 것에서 나온다. 더 많이 해주는 게 아니라, 작더라도 잘하는 것이 중요할 때가 많다는 것이다. 그리고 화려한 것보단 단순한 걸 좋아할 수 있고, 그 어떤 기능보다 쉬운 유지보수를 좋아하기도 한다. 그러니 고객 만족이 하나라고만 생각하지 말고 내 고객이 만족하기 위해서 이 프로젝트의 결과물이 어떻게 나와야 할지를 생각해보자.

 

사용자 앱이면 예쁘고 빠른 게 최고일 수 있다. '오 예쁘다~!'라는 반응이 나오면 성공.

직원용 시스템이면 직관적이고 간편한 게 최고일 수 있다. '이것만 하면 된다고!?' 하면서 빨리 배우면 성공.

인공지능이 들어간 시스템이면 어떤 범위든 뭐든 다 필요 없고 인식률 높으면 성공.

 

그러니 만약 내 역할과 권한에 업무 범위에 대한 협상력이나 정의 능력이 있다면, 줄이자. 줄이고 줄이고 또 줄이자. 티 안 나게 줄이든 티 나게 줄이든 줄이자. 고객이랑 싸우지 말고 좋게 줄이는 방법을 찾아보자. 나중에 반드시 고객이 늘려달라고 하는 게 생긴다. 그때를 대비해서라도 일을 줄일 생각을 해야 한다. 그렇다고 필수로 개발해야 하는 건 빼선 안된다. 놀이동산 놀이기구가 5개라면 모든 안전성을 검증받은 놀이기구가 놀이동산 안에서 구동이 되어야 한다.

 

좋은 PM, PL은 자기 아래의 개발자들의 업무량을 내 일처럼 생각할 줄 알아야 한다. 돈 받고 만드는 시스템 결과보다 그들의 당장 오늘의 삶을 생각해야 하고 그들의 건강을 걱정해줄 줄 알아야 한다. 자신을 걱정해주는 PL 아래에 있는 개발자는 개발해주지 말라고 해도 개발을 해주고, PL이 고객한테 가서 떵떵거리고 싸우거나 협상할 수 있도록 무기를 쥐어준다. 싸우고 지고 와서 막바지에 업무량이 늘어서 미안하다고 부탁하는 PL에게 웃으면서 괜찮다고 말하고 야근과 주말 근무를 해서라도 개발해주려고 한다.

 

이상적인 이야기로 보일 수 있지만, 이런 마인드를 갖지 않는다면 힘든 SI의 일하는 방식은 영원히 바뀌지 않을 것이다.

 

 

* 글을 쓰다 보니 떠오르는 얼굴들이 있네요. 부족한 PL 아래에서 고생해준 개발자분들, 다시 한번 감사합니다. 여러분의 PL로 일할 수 있어서 너무 좋았네요.ㅎ

 

2022.03.16 23:25