11. 조직 운영과 성과

고객의 요청을 모두 FDE에게 맡길 수는 없다. 새로 적용 방법을 찾아야 하는 프로젝트와 이미 정해진 기능을 설정하는 작업은 필요한 경험이 다르다. 기존 고객의 지원과 공통 도구 개발에도 시간이 든다. FDE 조직의 운영은 이 일을 나누고 한정된 인력을 어디에 배치할지 결정하는 데서 시작한다.

인력 배치와 제품 개선

두 고객이 같은 기능을 어려워하더라도 원인은 다를 수 있다. 한 고객은 여러 부서의 데이터 정의가 달라 적용 방법부터 정해야 한다. 다른 고객은 설정 화면이 복잡해 연결 정보를 입력하지 못한다. 앞의 문제에는 현장 조사와 개발이 필요할 수 있지만 뒤의 문제는 제품의 사용성을 개선하면 여러 고객에게 한꺼번에 도움이 된다.

FDE가 두 문제를 모두 해결할 수 있다는 이유로 계속 배정하면 제품이 고칠 일을 인력이 대신하게 된다. 고객 수에 비례해 지원 인력이 늘고, 제품의 복잡함은 그대로 남는다. FDE 조직은 현장에서 문제를 해결하는 동시에 어떤 작업을 반복하지 않아도 될지 제품팀에 알려줄 수 있어야 한다.

반대로 고객별 차이가 크고 해결할 가치가 높다면 일정한 수준의 맞춤 개발을 지속하는 선택도 가능하다. 모든 프로젝트를 셀프서브 제품으로 바꿀 수 있다고 기대할 필요는 없다. 사업이 감당할 수 있는 비용과 고객에게 제공하는 가치를 함께 봐야 한다.

업무 배분

고객 프로젝트에 인력을 배정할 때는 새로 개발할 일과 기존 고객에게 약속한 지원을 함께 보아야 한다. 일정표에 신규 개발만 잡으면 운영 문의가 들어올 때마다 계획이 밀린다. 지원 요청이 계속 늘어난다면 담당자를 바꾸거나 프로젝트 범위를 줄이는 결정도 필요하다.

공통 도구의 개선과 동료의 코드 리뷰에도 시간을 배정해야 한다. 이 작업을 고객 납품 이후에 남는 시간으로만 처리하면 다음 프로젝트 역시 같은 문제를 반복하게 된다. 공통 기반의 비용과 유지 방식은 7장에서 다뤘다. 조직 운영에서는 그 일을 누가 언제 맡을지 구체적으로 정해야 한다.

고객별 긴급 요청이 겹쳤을 때는 매출 규모뿐 아니라 업무의 중단 여부, 우회 방법, 기술적 의존성을 함께 검토한다. 우선순위를 정할 책임자가 없으면 담당 엔지니어가 각 고객에게 받은 압력에 따라 일하게 되고, 팀 전체의 계획은 유지하기 어려워진다.

성과 평가

가상의 두 프로젝트를 비교해 보자. 한 팀은 약속한 날짜에 배포했지만 이후 작은 변경마다 원래 개발자가 지원해야 한다. 다른 팀은 운영 절차를 마련하는 데 시간이 더 들었지만 고객이 일상적인 변경을 직접 처리한다. 첫 배포일만 보면 앞의 팀이 빠르지만 전체 지원 비용까지 포함하면 평가는 달라질 수 있다.

고객의 사용량도 해석이 필요하다. 접속이 늘어도 실제 업무 시간이 줄지 않을 수 있다. 문의가 줄어든 이유가 사용자가 익숙해졌기 때문인지, 기능을 포기했기 때문인지도 다르다. 하나의 지표만으로 프로젝트의 성공을 설명하기 어려운 이유다.

평가 지표

팀마다 강조하는 결과는 달라질 수 있다. 새로운 문제를 탐색하는 팀과 안정된 구현을 반복하는 팀을 같은 납품 속도로 비교하면 역할의 차이가 사라진다. 먼저 맡은 문제를 설명하고 그다음 결과를 평가해야 한다.

도입 효과 측정

고객이 업무가 빨라졌다고 말하면 어느 과정이 달라졌는지 살펴볼 수 있다. 문서를 찾는 시간이 줄었는지, 승인 대기가 줄었는지, 전체 처리량이 늘었는지는 다른 결과다. 업무량이나 담당 인원이 함께 바뀌었다면 도입 효과와 분리해 설명해야 한다.

절감된 시간을 곧바로 비용 절감액으로 바꾸는 것도 주의가 필요하다. 남은 시간을 다른 업무에 사용했다면 생산 능력의 변화로 설명할 수 있지만, 같은 금액의 현금 지출이 줄었다고 단정할 수는 없다. 고객의 만족, 업무 개선, 공급사의 계약 성과는 연결될 수 있으나 각각의 근거를 갖고 기록하는 편이 낫다.

업무 이관

처음에는 FDE가 깊게 참여해야 했던 업무도 적용 방법이 정해지면 구현 지원팀이나 고객 운영팀이 맡을 수 있다. 자주 반복되는 기능이 제품에 들어가면 FDE의 개입이 필요 없어진다. 그만큼 다음의 불확실한 문제에 시간을 쓸 수 있다.

고객이 계속 원래 엔지니어만 찾는 상태를 관계가 좋다는 이유로만 해석해서는 안 된다. 지식이 이전되지 않았거나 제품이 지나치게 복잡할 수 있다. FDE 조직을 평가할 때는 얼마나 많은 요청을 처리했는지와 함께 어떤 요청을 더 이상 직접 처리하지 않아도 되는지 살펴볼 필요가 있다.

핵심 요약

FDE 배치는 고객별 불확실성과 해결 가치가 충분할 때 검토할 수 있다. 성과는 첫 배포의 속도뿐 아니라 실제 업무의 변화, 후속 지원 비용, 재사용과 고객의 운영 능력을 함께 봐야 한다. 반복 작업을 제품과 운영 조직으로 옮기는 일도 FDE 조직의 중요한 성과가 될 수 있다.