더 빠르면서 더 싸게는 힘들다.
품질을 낮추거나 업무가 줄어들면 가능하다.
소프트웨어 개발의 공정한 대가 산정은 이 업계의 오랜 숙제이다. 게임, 넷플릭스로 대표되는 OTT와 같은 B2C용 소프트웨어 서비스는 정찰제로 제공하기 때문에 고객은 구매여부만 결정하면 된다. 반면 B2B 소프트웨어 개발 또는 내부개발 소프트웨어는 계약 또는 협상을 통해 가격과 개발기간을 결정한다. 이러한 계약 또는 협상이 공정하기 어려운 이유는 개발규모에 대해 프로젝트 팀과 고객의 생각이 다르고, 프로젝트 팀이 약자의 위치에 있기 때문이다. 이 두 가지를 자세하게 설명하면 다음과 같다.
① 개발규모에 대한 생각이 다르다.
고객이 요청한 기능을 구현하기 위해 수행해야 하는 작업의 크기를 고객이 알 수 없다. 프로젝트 개발팀도 알기 힘든 것을 고객이 어떻게 알겠는가? 고객이 요청한 기능도 구현을 완료한 뒤에야 정확하게 파악할 수 있다. 따라서 그 기능을 개발하기 위해 필요한 분석, UX, 개발, 테스트 투입공수는 더욱 파악하기 어렵다. 그러다 보니 고객은 기능구현을 위한 작업을 단순하고 간단하게 생각하기 쉽다. 뿐만 아니라 기능변경, 의사소통 오류 등으로 인한 재작업을 얼마나 할지도 모른다. 어찌 보면 프로젝트 팀도 모르고 고객도 정확하게 모르는 업무규모를 계약하고 협상하는지 모른다.
② 프로젝트 팀이 약자의 입장에서 협상한다.
B2B 소프트웨어 또는 내부 소프트웨어 개발은 ‘살까, 말까’를 결정하는 것이 아니라 ‘얼마에, 언제’를 협상한다. 프로젝트 팀이 ‘얼마에, 언제’를 객관적이고 논리적으로 입증하기 힘든 상황에서 협상의 약자가 되면 곤혹스러운 상황에 빠지기 쉽다. 카리스마 강하고, 높은 권력을 가진 (내부) 고객이 강압적이지만 조용한 목소리로 ‘프로젝트 팀이 제안한 가격과 기간을 20% 단축해서 합시다. 최근 경영상황이 좋지 않아요’라고 말할 때 안된다고 맞서기 힘들다면 약자의 함정에 빠진 것이다.
‘더 싸게’에 대한 대응
소프트웨어 개발대가는 ‘직무별 투입 MM * MM 단가’로 계산할 수 있다. 직무별 MM 단가는 한국소프트웨어 산업협회에서 매년 공시하기 때문에 다툼이 있다면 그 기준을 따르면 된다. 문제는 직무별 투입 MM를 어떻게 결정할 것인가이다. 직무별 투입 MM를 결정하는 직관적인 변수는 업무규모와 생산성이다.
직무별 투입 MM = f(개발규모, 개발생산성)
고객도 MM 단가를 깎자고 하지는 않는다. 개발규모를 부풀리지 말고 개발생산성을 높여서 비용을 줄여 달라는 것이다. 그러나 개발규모는 정확하게 산정했고 개발생산성은 최선을 다한 것이라는 것을 고객에게 입증하기가 쉽지 않다. 프로젝트 팀이 최선을 다한 산정을 했다는 신뢰를 (내부)고객에게 제공할 수 있다면 (내부)고객도 ‘더 싸게’를 주장하지 않을 것이다. 만일 예산이 부족하다면 범위를 조정할 것이다. 프로젝트 팀이 (내부)고객과 업무를 같이 해본 경험이 있다면 이러한 신뢰를 얻을 수도 있지만, 처음 만나는 (내부)고객에게 이러한 신뢰를 제공하기란 쉽지 않다. 최선을 다해 산정했다면 상대방이 그것을 느낄 수 있도록 노력해야 한다.
만일 이러한 신뢰를 확보하지 못했다면 협상의 파워에 따라 투입 MM가 확정된 체로 프로젝트는 시작된다. 이제 ‘더 싸게’는 계획이 아니라 실행의 영역이 된다.
프로젝트를 진행하면서 프로젝트가 계획보다 지연되는 시점이 온다. 그것은 주어진 업무를 완성하기 위해서는 비용이 초과하고 납기가 지연될 수 있다는 신호이기도 하다. ‘더 싸게’의 계획을 준수하기 위해 프로젝트 팀이 취할 수 있는 대안은 다음과 같다.
- 더 많이 일한다(잔업).
- 더 집중해서 일한다.
- 품질수준을 문제가 되지 않을 최소한으로 낮춘다.
팀원이 더 많이 일하고, 프로젝트에 더 집중하게 만들기는 힘들다. 팀원이 가장 쉽게 대응할 수 있는 것은 품질수준을 허용 가능한 최소한으로 낮추는 것이다. 품질은 개발자에게만 있는 것이 아니다. 분석, UX, 개발, 테스트 모두 나름의 품질기준이 있다. 따라서 업무부하가 큰 업무부터 품질수준은 낮아지고 다른 업무에 영향을 미친다. 이러한 행위를 모서리 자르기(corner cutting)이라고 한다. ‘모서리 자르기’는 ‘기술부채’라고도 하는데 부채에 따른 이자를 감당하기 힘든 시점이 오기도 한다. ‘더 싸게’가 힘들어진 상황이 오면 고객에게 추가비용 분담을 요구할지 말지를 결정해야 한다.
‘더 빨리’에 대한 대응
‘더 싸게’는 마음만 먹으면 아주 싸게 제공할 수 있다. 공급자가 비용을 부담하면 되기 때문이다. 그러나 ‘더 빨리’는 다르다. 특정 업무를 완성하기 위한 최소한의 기간이 필요하다. 업무에 따라 10개월이 적당한 프로젝트를 아무리 단축해도 5개월보다 빨리 끝내는 것은 불가능할 수 있다. 고객도 그런 수준의 빨리를 요청하는 것은 아니다. 10개월이 적당한 프로젝트를 1~2개월 단축시켜 달라는 것이다. 주어진 업무를 더 빨리 끝내는 방법은 더 우수한 인력을 더 많이 투입하는 것이다. 즉, 비용을 추가하여 일정을 단축하는 것이다. 그러나 고객이 ‘더 빨리’를 요구할 때 비용추가를 요청하기가 쉽지 않다. 예를 들어 10명/10개월이나 12.5명/8개월은 같은 100MM라는 고객의 주장은 합리적인 것처럼 들린다.
주어진 업무를 끝내는 방법은 하나만 있는 것이 아니다. 그러나 기간을 단축할수록 총 MM는 증가한다. 기간을 단축하기 위해서는 팀원을 추가로 투입해야 하고, 팀원이 증가할수록 의사소통 비용과 재작업 비용이 증가하기 때문이다. 예를 들어 5명이 10개월 동안 끝낼 수 있는 업무를 10명이 수행하면 몇 개월이 걸릴까? 각자의 작업이 독립적인 벽돌 쌓기와 같은 일이라면 5개월에 끝낼 수도 있지만, 상호 협업을 해야 하는 일이라면 7개월, 8개월이 걸릴 수도 있다. ‘더 빨리’를 요청하는 고객에게는 ‘더 빨리’의 부작용과 비용추가를 논리적으로 설명해야 한다. 만일 반드시 준수해야 하는 일정제약(예:MWC 와 같이 일정이 정해진 국제 박람회에 신상품 출시)이 있다면 요구사항의 우선순위를 조정하는 것이 일정지연의 위험을 줄이는 방법이다.
‘더 싸게’와 ‘더 빨리’에 대한 대응
예를 들어 10개 기능을 개발하는 ‘시간’과 ‘비용’의 조합은 아래 왼쪽 그림과 같이 기간을 줄일수록 비용이 증가하는 반비례 모양의 곡선이 될 것이다. 6개의 기능을 개발하는 시간과 비용의 조합은 오른쪽 그림과 같이 10개의 기능을 개발할 때 보다(A~B) 왼쪽 아래로 이동할 것이다(C~D).
동일한 기능개발을 위한 비용과 기간의 조합위의 그래프는 경제학의 무차별 곡선(indifferent curve)와 유사하다. 무차별 곡선이란 같은 효용을 제공하는 다양한 조합의 소비를 의미한다. 예를 들어 위의 그래프에서 기간과 비용을 육류와 해산물로 대체하면 특정 소비자에게 같은 효용을 제공하는 육류와 해산물의 다양한 조합이 존재할 것이다.
음식점에서 남과 같은 돈을 지불하고 남보다 더 많은 육류와 해산물을 달라고 주장하는 사람이 있을까? 특별한 경우가 아니라면 그런 주장을 하는 사람은 없을 것이다. 그러나 프로젝트팀이 제안한 비용과 일정을 (내부)고객이 둘 다 줄여 달라고 요청하는 이유는 무엇일까? 그건 앞서 설명했듯이 업무규모를 잘 모르는 상태에서 협상으로 가격과 기간을 결정하기 때문이다. 마치 시골의 5일 장터에서 보다 싸게 물건을 구매하기 위해 흥정을 하는 것과 유사하다.
위의 그래프에서 A는 B보다 느리지만 싸다. 반대로 B는 A보다 빠르지만 비싸다. 그러나 C는 A보다 싸고 빠르다. 즉 A나 B는 같은 결과물을 얻기 위한 선택지가 되지만 C와 A는 결과물이 다르기 때문에 선택지가 될 수 없다. 같은 돈으로 더 많은 해산물과 더 많은 고기를 먹을 수는 없다. 해산물을 더 먹기 위해서는 고기를 포기해야 한다. 해산물과 고기를 동시에 더 많이 먹으려면 돈을 더 많이 내야 한다. 이 간단한 경제학의 원리가 프로젝트 관리에도 적용된다. 같은 규모의 일을 하려면 ‘빠르고, 싸게’ 중 하나를 선택해야 한다. 싸게 하려면 기간을 늘리고, 기간을 당기려면 비싸야 한다. 더 싸고 더 빠르게 하려면 업무를 줄여야 한다. 당초 계획이 버퍼 없이 최선의 제안이었는데, 고객의 주장으로 더 작은 비용으로 더 빨리 끝내는 계획으로 프로젝트를 수행하게 되었다면 요행을 바라거나 출구전략을 수립해야 한다.
https://brunch.co.kr/@kbhpmp/160
