프로그래머가 클라이언트를 "생각해야"하는가?

요구 사항 수집이 싫어지는 시점에 도달했습니다. 고객이 자신의 이익을 위해 너무 모호합니다. 클라이언트에게 완료 작업을 보여줄 수있는 민첩한 환경에서는 기능을 정기적으로 약간 수정 / 업데이트 할 수 있으므로 그리 나쁘지 않습니다.

환경의 "폭포 (waterfall)"유형 (요구 사항은 다음으로 거의 완전한 제품)에서 상황이 추악해질 수 있습니다. 이런 종류의 환경으로 인해 끊임없이 요구 사항에 의문이 생겼습니다. EG 고객은 "입력을 숫자 1로 자동 변환"을 원합니다 (주문의 수량 참조). 그러나 그들이 생각하지 않는 것은 "입력"이 단순한 type-o 일 수 있다는 것입니다. 텍스트 상자의 "x"는 "치약"제품 중 하나를 원하지 않는 "우프"일 수 있습니다. 그러나 요구 사항이 너무 많아서 몇 시간 동안 서서 원하는 것을 분쇄 할 수 있습니다. 이것은 건강하지 않습니다.

회사에서 일하면서, 우리를 도울 민첩한 모델에 맞게 문화를 조정하려고 할 수있었습니다. 또는 양탄자 아래에서 추한 세부 사항을 청소하고 최선을 다하십시오. 고객이 코드에 너무 가까이 접근하려고합니까?

너무 많은 질문을하지 않고 "고객을 생각하는"문제를 어떻게 처리합니까?

대부분의 경우 고객은 다른 조치를 취할 수 없습니다. 그들은 우리에게 분명한 방식으로 필요한 것을 설명 할 필요가 없었습니다. 그들의 마음에는 분명하다. 사용자 입력을 숫자 1로 변환하는 것에 대해 생각하고 있다는 사실조차도 실제로는 생각하는 데 익숙하지 않습니다.

정말 그래야합니다. 그들이 원하는 것을 정확하게 설명하는 방법을 정말로 새로운 것이면, 우리가 그것들을 위해 그것을 쓸 필요가 없습니다. 결과적으로, 우리의 책임은 프로세스를 통해 그들을 돕는 것입니다. 이 프로세스에는 의사 결정이 필요하므로 의사 결정 프로세스를보다 쉽게하기 위해 권장 사항도 필요합니다.

따라서 고객이 모호하고 높은 수준으로 이야기하게하십시오. 그들은 자신의 사업을 알고 있으며 그것이 그들이 잘하는 것입니다. 그들이 말한 것을 가지고 잠시 생각 하십시오. 결국 원하는 것을 원하는대로 얻을 수있는 훌륭한 아이디어를 얻는 동시에 필요한 것을 테스트하고 일관성있게 유지할 수 있습니다.

청크 작업을 적극 권장합니다. 고객을 만나면 서로 관련된 일련의 요구 사항이 있으며 원하는 것을 수행하려는 방법을 설명하십시오. 또한 왜 당신이 선택을했는지 설명하십시오. 그런 다음 고객은 제공 한 내용을보고이를 미세 조정할 수 있습니다. "나는 그런 생각을하지 않았지만 실제로 도움이 될 것"과 같은 응답을 받으면 고객이 어떻게 생각하는지에 대한 정보를 얻었음을 알 수 있습니다. 참고 : 이것은 기능 장애가 아니며 클라이언트 의 비즈니스 문제 에 가장 적합한 올바른 기능을 선택합니다 .

고객이 명시 적으로 말한 내용과 모순되는 내용이있는 경우 그 이유를 설명 할 차례입니다. 고객이 생각하지 못한 몇 가지 문제와 대안이 여전히 원하는 / 필요한 것을 제공하지만 잠재적 인 문제를 피하는 방법을 제시해야합니다. 약간의 푸시 백이 발생할 수 있지만 고객이 실제로 사용할 수있는 제품을 제공하려고한다는 사실을 깨닫게되면 고객 신뢰도도 높아집니다. 그들이 약간의 푸시 백을 주면, 그들은 왜 특정한 방식을 원했는지에 대해 설명하게됩니다. 이를 통해 고객을 더 잘 이해하고 필요에 따라 요구 사항을 조정할 수 있습니다.

고객을 가장 빠르게 입을 수있는 방법은 모든 작은 질문을 하나씩하는 것입니다. 접근 방식을 검토하기 위해 일련의 회의 를 계획 하고 예약 하려고합니다 . 기술 요구 사항 (팀이 제품을 구축하기 위해 사용하는 것)을 소유하고 고객이 비즈니스 요구 사항을 소유하고 이들을 서로 관련시킬 수있는 한, 격차를 해소 할 수있는 방법이 있습니다.

너무 많은 질문에서 '거짓말'하는 경우 더 나은 고객을 확보하십시오.

고객은 원하는 것을 모릅니다. 솔루션을 볼 때 반드시 솔루션을 인식하지는 않습니다. 그것은 문제이며, 그것은 당신이 해결해야 할 일입니다. 그들의 요구 사항을 소프트웨어 패키지로 전달 될 수있는 것으로 번역하는 것입니다.

그러기 위해서는 무엇을하고 있는지 알아야합니다. "텍스트 상자에 숫자를 넣을 때 어떤 일이 발생해야 합니까?" 라고 묻지 말고 "이 숫자가 중요한 이유는 무엇입니까?"라는 질문을해야합니다. 그들이 어떻게 일을하는지 가르쳐달라고한다. 그리고 그들이 무엇을 원하는지 모르기 때문에 자신이하는 말을 듣지 말고 자신이하는 일과 눈이가는 곳을보십시오 .

자세한 내용은 다음을 참조하십시오 : http://www.joelonsoftware.com/articles/fog0000000356.html

당신이 어떤 종류의 회사의 직원이라고 가정하면, 고객과 자신 사이의 세부 사항을 중재하는 데 도움이되는 훌륭한 비즈니스 분석가가 필요하다고 들립니다. 나는 당신이 그런 일을하는데 충분한 영향력을 가지고 있지 않다고 생각할 것이므로, 다음으로 내 최선의 조언은 고객이 일하고있는 도메인에 대해 더 배우는 것입니다. 비즈니스와 그들이 일하는 프로세스를 이해함으로써 느슨하고 잘못된 방법으로 설명하고 있지만 실제로 무엇을하고 싶은지 더 잘 알 수 있습니다. 그것은 당신이 그들이 요구 한 것을 분석 할 수있게하며, 나중에 그들이 원하는 것을 해석하고 그들이 정말로 원하는 것을 줄 수있는 제안으로 별도의 회의에서 다시 올 수 있습니다. 동일한 고객과 일관되게 작업하면

그것이 매우 어렵고, 고통 스럽거나, 매우 불쾌하거나, 비현실적으로 보일 경우, 마지막 조언은 비즈니스 분석가가있는 곳에서 새로운 일자리를 찾기 시작하는 것입니다.

요구 사항을 수집하는 경우 이러한 질문을하는 것이 귀하의 임무입니다.

예, 고객이 성 가실 수 있지만,이 경우 "이러한 모든 질문"을하는 이유를 설명해야합니다. 해당 비즈니스를 자동화 할 코드를 작성하려면 먼저 해당 비즈니스를 이해해야합니다. 클린 처는 당신이하지 않으면 실제로 그들이 원하는 것을하지 않는 시스템을 개발하는 데 많은 돈을 소비 할 것입니다.

이것의 부작용은 고객이 요구 사항을 수정하도록 도와야한다는 것입니다.

이는 Big Design Up Front 또는 Agile을 수행 중인지 여부에 적용됩니다.

안타깝게도 고객이 직접 할 수 없거나 할 수 없다면 고객을 생각하는 것이 당신의 일입니다.

나는 두 가지 가능한 결과를 얻었습니다.

• 고객은 자신이 말한 것에 대해 실제로 생각하고 있다는 것을 기쁘게 생각합니다.

• 고객이 자신의 요구 사항에 대해 다시 생각하도록 강요하기 때문에 고객은 화가납니다. 그러나 이러한 유형의 고객은 어쨌든 조만간 귀찮게 될 것입니다. 그는 당신이 처음에 그를 생각하지 않은 너무 늦게 알게되면 그는 매우 화가 될 것입니다. 나는 말할 것입니다 : 가능하다면 이런 유형의 고객을 피하십시오 :-)

신속한 응용 프로그램 개발 (RAD)가 아니라이 문제를 해결합니다.

필요한 것에 대한 최선의 추측을 바탕으로 프로그램에 대해 매우 거친 비 기능적 UI를 만들어 "클라이언트에 대한 생각"을 시작하십시오. 그런 다음 그들에게 보여주고 실제 필요를 충족시킬 때까지 반복적으로 작업하십시오.

그들이 원하는 것을 모르는 것은 아닙니다. 그들은 그들이 볼 때까지 그들이 원하는 것을 알지 못한다는 것입니다. 때로는 제외를 통해 원하는 것을 결정할 수도 있습니다. 즉, 원하지 않는 것을 보여주고 비판하는 방법에주의를 기울입니다.

BFUD (Big Up Front 디자인)의 주요 문제점은 고객이 무엇을 얻을 것인지 명시 적으로 설명하는 계약으로 고객을 강요하여 개발자를 비난으로부터 격리시키는 것입니다. 불행히도 이것은 프로젝트에 아무도 실제로 필요한 것을 잘 알지 못하는 시점에 이루어집니다. 결국, 이것은 고객이 사인을했기 때문에 구축 한 것을 수락하게하지만 단호하게 받아들입니다.

고객이 결과물에 만족하지 않으면 Pyrrhic의 승리 일뿐입니다.

고객은 필요한 것을 고객에게 전달해야합니다. 귀하의 임무는 필요한 것을 프로그래밍 할 수있을만큼 필요한 것을 이해하는 것입니다. 모든 입력을 하나로 변경하는 문제에 대한 분명한 질문은 "왜 모든 입력을 1로 변경 하시겠습니까?"라고 말하는 것입니다. 그런 다음 고객은 그 이유를 설명 할 수 있으므로 요구를 이해하고 그들이 요구하는 것이 아니라 필요한 것을 제공 할 수 있습니다. 당신이 그들이 무엇을 필요로한다고 확신한다면, 나는 당신이 반드시 그들의 생각의 선을 "수정"할 필요는 없다고 생각합니다. 그들은 제품과 "아! 완벽 해"를 사용합니다. 그러나 자신이 필요한 것이 무엇인지 확신하지 않으면 생각하고있는 것을 설명하고 고객과 함께 해결해야합니다. 불행히도 두 부분의 실제 청취와 관련된 많은 의사 소통없이 프로세스의이 부분을 수행 할 방법이 없습니다. 상황에 짜증을 내고 실제로 말하고 싶거나 말하고 싶은 말을 조심하십시오.

솔직히 : '큰 기능'이 아니라면, 가장 많은 도메인 지식을 가진 사람이 어떻게해야할지에 대해 최선의 추측을하고 그것을 구현하도록하십시오. 수용 테스트에서 다뤄질 것입니다-그것이 목적입니다.