10 Customer-Oriented Development #1509
Description
10장 고객중심 개발
고객이 개발 속력을 어떻게 인지하는지가 결국 가장 중요하다는 사실을 깨닫는다면, 고객에게 주의를 기울여야 할 이유는 명백하다.
잘못된 제품을 빨리 개발해도 잘못된 제품을 개발한 것이다.
고객이 누구인지는 프로젝트마다 크게 다르다.
소프트웨어 비용을 지불하는 대상과 무관하게 최종 사용자를 고객으로 보는 게 좋다.
어떤 경우든 고객 관계 개선을 통해서 개발 속력을 향상하는 원리는 동일하다.
10.1 쾌속 개발에서 고객의 중요성
스탠디쉬 그룹은 8천개가 넘는 프로젝트를 조사한 결과 프로젝트 성공 비결이 사용자 참여임을 발견했다.(Standish Group 1994)
프로젝트 핵심 요소 세 가지 중 하나로 최종 사용자에게 쉽게 접근할 수 있는 프로젝트 환경을 꼽기도 한다. (Millington and Stapleton 1995)
이런 환경을 사용자 참여라고 해도 무방하다.
쾌속 개발 프로젝트에서 고객을 중시하는 근본적인 이유 두 가지는 다음과 같다.
- 원만한 고객 관계는 실제 개발 속력을 향상시킨다. 고객 관계가 서로 협조적이고 의사 소통이 원활하면 개발 오류와 비효율성이 크게 줄어든다.
- 원만한 고객 관계는 개발 속력에 대한 인식을 향상시킨다. 고객은 프로젝트가 지연될지 모른다는 두려움이 있으므로 진행상황을 쉽게 파악할 수 있는 방식으로 프로젝트를 진행하면, 고객은 개발자를 신뢰하고 개발 속력을 덜 걱정하게 된다. 주요 관심사는 기능, 품질, 기타 문제로 옮겨가고 개발 속력은 여러 관심사 중 하나가 된다.
효율성 증가
고객 참여가 프로젝트 성공에 결정적인 영향을 미친다.
고객 관계를 강조하고 고객 중심 개발법을 선택하면 다음과 같은 비효율성을 제거할 수 있다.
- 고객은 자신이 무엇을 해야 하는지 이해하지 못함
- 요청한 내용의 검토를 위한 시간 할당을 하지 않음
- 핵심 문서 검토를 지연시키면 제품 출시가 지연된다는 사실을 깨닫지 못함
- 고객 책임자가 여러명이어서 결정 내용을 누구와 논의해야 하는지 확실하지 않은 상황
재작업 감소
고객이 거부하는 개발을 하게 되면 재작업을 하게 되므로 결코 괘속 개발을 이룰 수 없다.
보통 일부 기능을 거부하므로 해당 부분을 다시 설계하고 구현해야 한다.
재작업을 회피해서 쾌속 개발을 달성할 수 있다.
위험 감소
일정 위험을 증가시키는 경우는 다음과 같다.
- 원하는 걸 알지 못함
- 요구사항 문서에 서명 안함
- 새 요구사항을 고집
- 의사소통 안됨
- 검토 능력 부족
- 기술적 무지
- 개발자 간섭
- 소프트웨어 개발에 대한 무지
- 위험이 뭔지 아직 드러나지 않음
프로젝트에서 위험을 인지하고 감시하는 업무는 고객 관계가 원만할 때 더 잘 수행할 수 있다.
마찰 감소
고객과 사이가 나쁘면 고객 관계를 관리하는 데 시간을 뺏긴다.
고객 관계 관리는 시간이 걸리는 일이기에 업무에만 전념하기 힘들어진다.
별로 좋아하지 않는 고객을 위해 추가 근무를 하기는 어렵다.
고객이나 개발자 어느 쪽이든 마찰 원인을 제공할 수 있다.
하지만 고객을 협력자로 만들면 기술 제약을 이해하는데 훨씬 너그러워진다.
10.2 고객중심 개발법
- 계획 수립: 고객중심 개발법은 고객 만족도를 높이는 데 도움을 준다.
- 요구사항 분석: 고객중심 개발법은 진자 요구사항을 파악하고 재작업을 피하는 데 도움을 준다.
- 설계: 고객중심 개발법은 고객 요구사항에 대처하기 위해 필요한 유연성을 쌓는 데 도움을 준다.
- 구현: 고객중심 개발법은 진행상황을 확인하고 안심하게 만드는 데 도움을 준다.
계획 수립
- 적절한 생명주기 모델을 선택하라.
- 진짜 고객이 누군지 파악하라.
- 고객과 대화할 수 있는 효율적인 방안을 구축하라.
- 상생하는 프로젝트를 만들어라.
- 위험을 관리하라.
요구사항 분석
진자 요구사항을 찾는 건 쉽지 않은 일이다.
고객은 요구사항을 애매하게 명시하고 혼란을 일으키기 쉽다.
고객은 요구사항을 확대 해석하는 경향이 있는 반면, 개발자는 축소 해석하는 경향이 있다.
고객 중심 요구사항 수집 기법은 진짜 요구사항을 더 많이 발견하는 데 도움이 된다.
그림 10-1은 고객중심 개발법을 사용해서 수집한 요구사항과 이런 기법을 사용하지 않고 수집한 요구사항 사이에 나타나는 차이를 보여준다.
Figure 10-1. The difference between typical and customer-oriented requirements-gathering practices. Customer-oriented practices increase the proportion of realrequirements you can gather.
그림 10-2에서 고객 참여가 높아졌을 때, 그래프 최상부와 평균은 상당히 증가하고 최하부는 사실상 변화가 없다.
고객 참여는 개발 속력을 증가시키지만, 프로젝트 성공을 보장할 만큼 생산성 향상을 하진 못한다.
고객 참여 과정에서 요구사항 전부를 정하도록 방치하지 않는 일도 중요하다.
고객이 요구사항을 일방적으로 정하면 생산성이 감소한다는 현상도 발견할 수 있었고
사실상 그런 요구사항 중 절반 이상은 다시 작성해야 했다. (Vosburgh et al. 1984)
Figure 10-2. Findings for “Client Participation in Requirements Specification”factor (Vosburgh et al. 1984). Active customer participation can produce dra-matic improvements in productivity, but it is not by itself a guarantee of success.
요구사항 수집 과정에서 고객 참여 기법은 다음과 같다.
- 요구사항 도출 기법 사용 => 고객이 원하는 걸 스스로 깨닫게 도와줌
- 초점 집단(focus group)을 통해 고객이 원하는 바를 파악하게 한다.
- 소프트웨어를 사용하는 고객 촬영
- 고객 만족도 조사 수행 => 고객 관계 정량적 측정 가능
설계
요구사항 수집을 완벽하게 하지 못할 수 있다.
설계 과정에서 고객중심을 유지하기 위한 생산적인 방법은 다음과 같다.
고객이 때때로 마음을 바꿔도 되는 개발법 사용
요구사항에서 변경가능한 내용을 파악해 정보은닉과 캡슐화를 최대한 활용하라는 뜻이다.
구현
계획 수립, 요구사항 분석, 설계, 구현 단계까지 오면 고객은 개발 과정에 충분히 관여하고 있다고 봐도 된다.
구현 과정에서 효과 있는 고객중심 기법은 다음과 같다.
- 읽기 쉽고 수정하기 쉬운 코드 작성 => 고객 요구사항 변경에 쉽게 대처 가능
- 상세 중간목표와 같은 진행상황 감독 기법 활용 => 효과적인 진행상황 전달 가능
- 실제적인 진행상황을 보여줄 수 있는 생명주기 모델 선택
점진적인 생명주기 모델은 고객에게 동작하는 소프트웨어를 자주 넘길 수 있다는 점에서 좋은 선택이다.
10.3 고객 기대 관리하기
고객이 일정이나 비용에 거는 비현실적인 기대를 밝혀내고 기대 수준을 명시하려고 하는 건 결국 개발자에게 이익이 된다.
개발자가 비현실적인 일정에 동의하면 고객도 비현실적인 기대가 자리 잡는다.
고객과 협조를 통해 일정에 대한 기대를 현실적인 수준으로 조정하는 일이 성공을 위한 길이다.
고객들이 가끔 멍청해보이기는 하지만 정말 어리석지는 않다.
단시 소프트웨어 개발이 어떤지를 모를 뿐이다.
고객 역시 개발자가 비즈니스 환경을 이해하지 못해서 멍청하다고 느낄 수 있다.
서로 공평한 상황이다.
개발자로서 고객이 소프트웨어 개발을 더 잘 이해하도록 가르쳐야 한다.
그래야 고객 기대에 부응하기가 쉬워진다 (그림 10-3)
고객이 소프트웨어를 익히고 참여도 하면서 경험을 쌓으면 수준이 높아지고 전체 프로젝트 생산성도 증가한다. (Jones 1994)
Figure 10-3. Developers’ and customers’ views of the same phenomenon can bequite different.
어떤 내부 상황과 복잡한 관계에 있다고 해도 고객이 일정, 비용 기능에 대해 비현실적인 기대를 하게 만들면 프로젝트는 사실상 극복할 수 없는 위험이 생긴다.
고객 기대를 부풀리는 사람들은 결국 신용을 잃게 되며 고객 관계를 악화시킨다.
할 수 있는 일 이상을 약속하는 사람들은 처음엔 편해도 결국 힘든 시간을 보내게 된다.
그러므로 고객 기대 수준을 현실적으로 조정하려는 노력 또한 개발자 업무에 포함된다.
읽을 거리
- Karten, Naomi. Managing Expectations. New York: Dorset House, 1994.
- 더 많이, 더 낫게, 더 빨리, 더 일찍, 지금 당장 보여질 원하는 고객 문제를 다룬다.
- Whitaker, Ken. Managing Software Maniacs. New York: John Wiley & Sons,1994.
- 1장에 고객을 최우선으로 다뤄야 하는 중요성을 논한다.
- Peters, Tomas J., and Robert H. Waterman, Jr. In Search of Excellence. NewYork: Warner Books, 1982
- 관리에 대한 고전적인 책이다. 고객 만족의 중요성에 대한 분석과 사례 연구를 담고 있다.