변화하는 요구 사항과 관련하여 고객을 어떻게 관리합니까? [닫은

Question

스티브 예지의 지혜 그럼에도 불구하고 대부분의 개발자는 비 기술적 고객으로부터 수집 된 요구 사항에 직면 해 있습니다. 때로는 고객을 상대하고 요구 사항을 번역하는 프로젝트 관리자가 있습니다. 어쨌든 요구 사항이 변경 될 것이라는 사실은 불가피합니다.

"좋은 프로그래밍 연습"을 고립하는 대부분의 것과 관련이 있습니다. 적응할 수있는 시스템 개발 변화하는 요구 사항을 견딜 수 있도록. Yagni, 건조하고 느슨한 커플 링 등과 같은 원리가 이에 기여합니다. Agile과 같은 반복 개발 프로세스는 또한 움직이는 목표를 달성하려는 우려를 해결하려고 시도하고 물론 테스트중인 시스템을 사용하면 변경을 수행 할 수 있습니다.

그럼에도 불구하고 많은 사람들에게 변화하는 요구 사항이 소프트웨어의 품질을 상하게합니다, 그러나 할 수도 있습니다 우리의 동기 부여 그리고 우리가 누군가를 찌르고 싶어하게 만듭니다.

이 질문은 방법에 관한 것입니다 고객을 관리하십시오 임의적이거나 경박 한 변화를 낙담하면서 필요한 방식으로 요구 사항을 변경할 수있게합니다. 어떻게 하시나요?

• 고객으로부터 개발자를 격리시킬 프로젝트 관리자가 있습니까?
• 공식적인 변경 관리 프로세스가 있습니까? 변경 관리자?
• 고객이 실제로 필요할 때 변화를 얻는 것이 얼마나 어려운가?
• 반대로, 고객이 "경박"할 때 변화를 얻는 것이 얼마나 쉬운가요?
• 변경 비용을 설명 할 때 고객에게 얼마나 많은 세부 사항을 제공합니까?
• 변경 요청을받은 후 고객 에게이 정보를 얼마나 빨리 제공 할 수 있습니까?
• 프로세스를 어뢰 할 수있는 요인 (예 : PM은 누가 고객에게 거절 할 수 없습니까?)
• 당신에게 무엇이 효과가 있습니까?

Answer 1

고객이 마음을 바꾸지 않거나 이상적인 사양을 얻는 이상적인 세상을 찾고 있다면 - 당신은 잘못된 사업에 있습니다. 즉, 고객의 기대 및 변경 요청을 관리하기 위해 내가 찾은 가장 효과적인 메커니즘은 정확한 측정 시스템을 제정하는 것입니다.

이것이 제가 팀을 운영하는 방법입니다.

1) 우리는 사용자 스토리부터 시작합니다. 고객은 고객을 서면으로 참여하고 개발 팀은 각 사용자 스토리가 상대적으로 얼마나 오래 걸릴지 추정합니다.

2) 사전 경험을 사용하여 이러한 상대 추정치 (스토리 포인트)를 취하고 프로젝트의 주요 이정표가 완료 될 때 대략적인 일정을 만듭니다.

3)이 이정표에서 우리는 2 주 반복을 실행합니다. 고객은 승인 기준을 설정하고 스토리가 승인되었는지 여부에 관여합니다. 간단한 번 다운 차트는 고객에게 출시 목표를 달성하는 데 얼마나 가까운지를 보여줍니다.

4) 승인 세션 중에 종종 고객은 기능이 자신의 원래 승인 기준을 충족 했음에도 불구하고 기능이 예상되는 방법을 밝히지 않았기 때문에 변경을 요청합니다. 현재 새로운 추정치로 새로운 이야기를 생성합니다. 이정표 날짜를 적절하게 조정할 수도 있습니다. 그런 다음 공을 고객 법원에 다시 넣습니다.

• 종종 그들은 그들의 변경 요청이 그만한 가치가 없다는 것을 깨닫고 (상사로부터 승인을 받아야 함) 새로운 기능을 죽일 것입니다.
• 때로는 중요하므로 기능을 얻기 위해 기한을 지연시킬 수 있습니다.
• 그리고 마지막으로, 항상 동등한 시간이 걸리는 다른 중요한 기능을 죽일 수있는 옵션이 있습니다.

핵심은 변경 요청에서 벗어나는 것이 아니라 모든 변경 요청이 제품에 결과를 초래하도록 설정하는 것입니다. A와 같은 것은 없습니다 무료 점심.

Answer 2

나는 Indpenedent 개발자로 일하면서 고객과 직접 연락합니다. 대부분의 시간은 그들이 실제로 무엇을 원하는지 전혀 모른다는 것은 정상입니다. 그래서 우리는 천천히 시작하여 일찍 프로토 타입을 연주하기 위해 프로토 타입을 제공하고 변경 사항은 점진적으로 만들어 질 것입니다. 고객이 "경박 한"변화를 원한다고 생각한다면이 변화가 효과가 없거나 필요하지 않다고 말합니다. 그것이 5 분의 작업이라면 어쨌든 그렇게 할 수도 있습니다.

나중에 나올 작은 변경에 대한 돈을 얻기 위해 계약 일부 유지 보수 조항에 나중에 추가하는 데 도움이됩니다. 더 큰 변화의 경우 시간이 지남에 따라 충전합니다.

Answer 3

고객을 관리하는 것은 어렵고 매우 쉽게 잘못 될 수있는 것입니다.

가능한 한 빨리 당신은 신뢰를 얻으십시오 고객의. 나를 위해 나는 당신이 이것을 할 수 있다고 생각합니다.

• 고객에게 임명하도록 요청하십시오 제품 관리자 - 자신이 원하는 요구 사항을 의사 소통 할만 큼 충분히 생각하고 그/그녀와 강력한 업무 관계를 구축하려고합니다.
• 실제로 그들의 사업을 이해하려고 노력하십시오 - 도메인 전문가 일 필요는 없지만 고객이 어디에서 왔는지 알아야합니다.
• 그들이 원하는 것에 대해 관련 질문을하십시오. 그들이 (처음에) 그들이 요구하는 것을 가정하지 마십시오..
• 처음에 모든 변경 사항을 환영합니다. 이것은 고객이 짜증나고 변덕스러운 것이 아니라 고객이 실제로 원하는 것을 더 잘 이해할 수있는 기회입니다. 이것이 시간/돈이 들면, 당신은 그것을 손실 리더.
• 프로토 타입을 조기에 전달하십시오, 실용적으로 많은 고객 피드백을 통합합니다.
• 고객에게 줘 킥 엉덩이 제품.

이 작업을 수행하고 고객이 신뢰하면 불합리한 변경 사항을 무너 뜨리거나 이전에 범위에서 고려 된 것들에 대해 추가 지불/시간을 요청할 수있는 위치에있을 것입니다.

물론, 당신은 모든 고객과 이런 종류의 관계를 구축 할 수 없을 것입니다. ~이다 바보 (이 경우 다른 제품 관리자를 임명 할 수 있는지 확인) 그러나 항상만큼 많은 일을해야합니다. 너 효과적인 업무 관계를 구축 할 수 있습니다.

Answer 4

고객이 처음에 원하는 것을 알기를 기대할 수 없으므로 적응력이 있어야합니다. 또한 변경을 위해 변경을 중단해야합니다.

이것은 '내부'고객을위한 것입니다.

나는 고객과의 협상이 효과적인 방법이라는 것을 알았습니다. 그들은 기다릴 때 원하는 기능을 가질 수 있습니다. 이것은 그들이 시스템 전체와 관련하여 그들이 요구하는 변화의 가치에 대해 생각하도록 강요합니다.

때때로 이것은 잘 작동하고 좋은 타협에 도달합니다. 다른 경우에는 고객이 장난감을 유모차에서 쫓아 내고 높이가 높아지는 기능을 구현하고 품질이 줄어 듭니다.

고객이 지불하는 경우 다른 볼 게임입니다. 그들은 변화 비용을 알고 제품이 완료 될 때 비용이 증가한다는 것을 알고 있어야합니다. 이것은 당신이 당신이 제공 할 내용에 대한 많은 선형 분석을 수행하고 사양에 합의되어야한다는 것을 의미합니다. 그러면 변경된 내용을 측정 할 수 있습니다. 이것은 어느 당사자에게는 가장 효과적인 솔루션이 아니지만 물건을 자르고 건조하게 유지합니다. 그래서 그들은 불만족하지 않으며 당신은 많은 일을 무료로 수행하지 않습니다.

Answer 5

소프트웨어 엔지니어링에서 변화는 사실 일뿐입니다. 일어날 것입니다. 우리에게는 모든 것이 가격으로 온다. 우리는 고객이 원하는 모든 변화를 만들 것이지만, 항상 시간 추정치와 그와 관련된 비용이 있습니다. 우리는 클라이언트에게 아무 말도하지 않지만, 일반적으로는 아니지만 때로는 변경 요청이 매우 높은 비용으로 발생합니다. 우리는 잠재적 인 보안 위협 등에 선을 그립니다.이 경우 요청을 수용 할 수 없다고 침착하게 설명합니다.

우리는 고객에게 얼마를 설명합니까, 우리는 돈이 어디에 할당 될 것인지, 개발을위한 많은 것, 분석을위한 많은 것을 설명합니다. 이제 나는 이것이 일부 고객마다 약간 다양하다는 것을 인정할 것입니다. 그들 중 일부는 어디에 얼마나 많은 시간을 소비하는지에 대해 매우 상세한 청구를받습니다. 계약을 체결하기 위해서는 우리에게는 매우 드 rare니다.

우리는 때때로 거절 할 수없는 영업 사원이 있으며, 이로 인해 문제가 발생할 수 있습니다. 우리는 그 일을하는 데 많은 시간을 보냈지 만 불행히도 여전히 자랐습니다. 우리는 그들이 무엇을 취할 것인지 연구하지 않고 무언가를 인용함으로써 그들이 우리에게 얼마나 많은 비용을 지불하는지 설명함으로써 그것을 싸운다. 투명성은 모든 수준에서 핵심입니다. 모든 사람은 자신의 결정이 결론에 어떤 영향을 미치는지 알아야합니다.

우리는 경박 한 변화를합니까? 네. 당신이 기억해야 할 것은 대부분의 시간을 시간에 청구 할 때 5 분 동안 변경이 한 시간 내에 청구되므로 상당히 유리하다는 것입니다. 우리는 변경 요청과 마찬가지로 이전 에이 모든 것을 설명하므로 그들이 알고 있지 않지만, 그것이 실제로 중요하지 않으면 그러한 행동을 방해하는 데 도움이되는 경향이 있습니다. 사실 우리는 모든 변화를 동일하게 취급한다는 것입니다. 우리는 아무리 터무니없는 생각에 관계없이 그들에게 경박 한 것으로 간주되는 것을 알고 있다고 생각하지 않습니다. 우리는 고객이 우리가 그것을 적어 놓는 것을 요구하고 우리가 그것을 평가하고 작업 비용 추정치를 제시하는 것을 사인 오프하도록하는 공식적인 변경 프로세스가 있습니다. 그들은 어떤 경우에 그들이 공식적으로 문서에 서명하는 것이 우리에게 시작 되어도 괜찮다는 것을 알려 주거나 요청을 철회합니다. 우리는 부지런히 노력하지만, 우리는 그들의 요청에 대한 응답을 얻는 데 며칠이 걸릴 것이라고 그들에게 알렸다.

내 동료가 고객 관계 선박 관리에 대해 들어 본 최고의 조언을주었습니다. 주고받는 것입니다. 고객을 행복하게하려면 무언가가 필요할 때 기꺼이 도와야하지만 동시에 거절 할 수 있어야합니다. 사람들을 상대 할 때 그들은 당신이 그들을 도와주기를 원하지만 그들은 또한 당신이 척추를 가지고 있고 스스로 일어 서기를 원합니다. 그런 식으로 상생 상황이됩니다.

Answer 6

나는“변화하는 요구 사항”에 대한 진화 요구 사항의 용어를 선호합니다. Mmlehman 교수http://www.doc.ic.ac.uk/~mml/ 그리고 http://en.wikipedia.org/wiki/meir_manny_lehman) 소프트웨어 진화에 관한 연구에 상당한 기여를 해왔다. 그의 작품은 또한 모든 유형의 요구 사항이 진화하는 것은 아니라고 제안합니다. 요구 사항이 동일하게 유지되는 이러한 시스템 중 하나에서 작업하면 운이 좋다고 생각할 수 있습니다 (즉, 수학 라이브러리 등).

미국의 나머지 경험에 따르면 개발자는 가능한 한 목표에 대한 많은 정보를 선호하는 반면 고객이나 최종 사용자는 개발 프로세스에 가능한 한 늦게 요구 사항을 지정하거나 조정할 수있는 능력을 평가합니다. 전자는 솔루션을 계획하고 설계하는 데 도움이되는 자세한 정보가 필요하며, 후자는 요구 사항을 늦게 변경함으로써 전략적 이점을 얻을 수 있습니다. 고객은 변화하는 환경 또는 정보에 응답 할 수있는 공간을 제공하기 때문입니다. 프로젝트의 초기 단계 / 반복. 상세한 계획을 세우고 변화를 변화시키는 능력 사이의 상충 관계는 개발 과정 자체 (폭포, 민첩한, 나선 등)를 결정합니다.

요구 사항의 진화를 관리하는 실용적인 조언 :

• 진화하는 요구 사항, 여러 체크 포인트 또는 반복을 설명하기 위해 일부 공간을 초기 계획으로 구축하십시오.

• 일부 종류의 프로토 타이핑 또는 타당성 조사가 프로젝트를 명확히하거나 프로젝트의 늦게 변경을 계획 할 수 있도록 휘발성 요구 사항을 프로젝트의 시작에 넣으십시오.

• 요구 사항이 여전히 관련이 있음을 모니터링하십시오.

• 최신의 우선 순위가 최신의 현재 요구 사항 목록을 사용하십시오. 상대적 우선 순위와 비용을 포함하여 현재의“필수품”의 모든 이해 관계자에게 진화를 통제하는 데 도움이되지 않습니다.

• 시간이 얼마나 걸리는지에 대한 고객의 기대를 계속 관리하십시오. 이것은 또한 집중력을 유지하는 데 도움이됩니다.

• 필요한 경우 요구 사항을 변경하거나 추가하기위한 공식적인 프로세스를 소개합니다. 프로세스 설명은 이러한 관련된 역할, 검토 빈도 등의 역할을 지정해야합니다. 이는 정치적이고 가장 기회 주의적이지만 필수적인 요구 사항에 대한 좋은 보호 역할을 할 수 있습니다.

• 첫 번째 버전에서도 리팩토링을 위해 언젠가 빌드하십시오. 개발 중에 추가 지식 이득의 결과로 솔루션의 전부 또는 일부를 던질 가능성이 높습니다.

Answer 7

고객이 할 시간이 없거나 무엇을 해야할지 모르기 때문에 고객이 무언가를하기 위해 온다. (그리고 그들을 위해 돈을 지불하고 싶습니다). 요구 사항이 변경되면 요구 사항이 있습니다. 후자 때문입니다. 다시 말해, 그들은 세부 사항을 알아 내기 위해 당신에게 돈을 지불하고 있습니다! 그리고 그들은 그들이 좋아하고 좋아하지 않는 것을 알고 있지만 그것이 어떻게 작동하는지 알지 못합니다.

이것과 해결책이 필요한 모든 것을 인식하십시오.