구현 가능한지 확실하지 않은 기능을 제공 할 것을 약속해야합니까?

HN 의 기사에서 다음과 같은 조언을 얻었습니다.

확실하지 않더라도 항상 고객 / 사용자에게 "예"라고 말하십시오. 시간의 90 %를 할 수있는 방법을 찾을 수 있습니다. 시간의 10 %, 당신은 돌아가서 사과 할 것입니다. 큰 개인 성장을 위해 지불하는 작은 가격

그러나 나는 항상 고객 / 사용자에게 약속을 하기 전에 타당성 분석을 수행해야한다고 생각했습니다 . 그러면 어떤 상황에서 위의 조언을 적용해야합니까?

이것은 그 기사에 의해 짧은 연속으로 두 번째 질문입니다.

• 좋은 프로그래머 : 코드를 최적화합니다. 더 나은 프로그래머 : 나는 데이터를 구조화한다. 최고의 프로그래머 : 차이점은 무엇입니까?
  조기 최적화라는 또 다른 이름이 있습니다.

• 초기 출구를 사용하지 마십시오.
  이것이 "단일 진입 점 / 단일 출구"규칙입니다. 그것은 실제 문제에 대한 패치입니다. 조기 종료는 혼란을 초래할 수 있습니다. 올바른 규칙은 "엉망을 정리하는 것"입니다. 더 좋은 규칙은 프로그래머가 자신의 혼란을 정리하는 것에 대해 걱정할 필요가 없도록 스스로 정리하는 데이터 구조를 사용하는 것입니다.

• 그리고 확실하지 않더라도 항상 고객 / 사용자에게 "예"라고 말하십시오. 90 %의 시간을 할 수있는 방법을 찾을 수 있습니다.
  이것 역시 매우 나쁜 조언입니다.

때때로 고객에게 "아니오"라고 말하거나 "어떻게 이것을 원하는가?" 아키텍처를 파괴하거나 고객이 기꺼이 지출하는 것보다 훨씬 많은 비용이 들거나 달성 방법에 대한 단서가없는 것을 약속하지 마십시오. 당신은 고객이 아니라 기술을 알고 있습니다. 어떻게해야할지 모른다면 할 수 있다고 말하지 마십시오. 확실하지 않은 경우 가능한지 조사 할 시간이 필요하다고 가정하십시오. 정직하게하는 것이 좋으며, 문제를 피할 수 있습니다.

약속을 이행 할 수 없으면 고객은 신속하게 기존 고객이됩니다. 10 %의 실패율은 작게 들릴 수 있지만 고객의 10 %가 집중할 것입니다. 당신이 약속 한 것을 이행하지 못할 때 때때로 그들은 고소합니다. 당신은 정말로 그것을 원하지 않습니다. 다른 경우에는 약속을 지키는 일이 18 시간을 일하고 있기 때문에 파산하거나 미치거나 배우자를 잃게 만들 수 있습니다. 당신도 그것을 원하지 않습니다.

이 방법으로 생각하십시오 : 모든 비행기 착륙의 90 %가 성공했다면 항공 산업에 어떤 일이 일어날 것이라고 생각하십니까? 돌아가서 10 % 사과 한 것이 문제를 해결할 것이라고 생각하십니까?

"나는 할 수 있다고 생각한다"고 말하는 것이 좋습니다. 또는 "확인하고 다시 연락 드리겠습니다". 나는 아무 말도하지 않았거나 반대 의견을 제시 한 적이있다. 고객이 "인터넷에 연결하지 않고 작동하고 촉각 적 피드백을 사용하는 브라우저 기반 응용 프로그램"을 원한다면 가능할 것입니다. 그러나 비용이 많이 들고 실제 요구 사항에 대해 논의하는 것이 더 유용합니다.

정직하면 고객은 당신을 존중합니다. 문제의 조언에서, 그 사람은 시간의 10 %가 잘못되었습니다. 내가 매번 10 번씩 틀린 사람과 일한다면, 나는 그 / 그녀를 전혀 믿지 않을 것이다. 그것은 끔찍한 실적입니다.

달을 약속하고 바위를 제공하는 것은 용납해서는 안되는 일종의 영업 사원 접근법입니다. 가능한지 모른다면 조사하십시오. 또는 조사하는 데 걸리는 시간에 대한 견적을 제공하십시오. 이 방법으로 당신은 당신이 전달할 수없는 것을 약속하지 않지만, 당신이 그것을 조사하는데 걸리는 시간에 대한 대가를 받고 있습니다.

이 질문은 공식적으로 연구되었으며 공동으로 생산 된 IEEE Computer Society / ACM 윤리 강령에 의해 해결되었습니다 .

2.01. 그들의 경험과 교육의 한계에 대해 정직하고 솔직하게 그들의 역량 영역에서 서비스를 제공하십시오.

3.04. 교육 및 훈련과 경험의 적절한 조합을 통해 그들이 일하거나 제안하는 프로젝트에 대한 자격을 갖추도록하십시오.

3.09. 그들이 작업하거나 작업을 제안하는 프로젝트에서 비용, 일정, 인력, 품질 및 결과에 대한 현실적인 정량적 추정을 보장하고 이러한 추정에 대한 불확실성 평가를 제공합니다.

5.05. 그들이 일하거나 일을 제안하는 프로젝트에서 비용, 일정, 인력, 품질 및 결과에 대한 현실적인 정량적 추정을 보장하고 이러한 추정에 대한 불확실성 평가를 제공합니다.

당신이 전달할 수없는 것을 약속하는 데는 사업 적, 법적 의미가 있습니다. 일반적으로 고객은 다른 곳을 방문하거나 지불을 거부하거나 회사를 고소하는 고객으로부터옵니다. 귀하가 다른 사람과 파트너쉽을 맺고있는 경우, 귀하의 부품이 배송되지 않으면 다른 사람이 손해 배상을 청구 할 수 있습니다. 소송은 경쟁사에서 나올 수도 있습니다.

Seymour Cray와 Control Data Corporation의 팀이 제품을 출시하기 시작한 슈퍼 컴퓨터 초기의 이야기가 있습니다. 또 다른 대형 컴퓨터 회사가 고객에게 출시가 가까워 졌다고 말했습니다. 그 거짓말은 CDC에 많은 사업 비용이 들었고 대기업이 그들의 주장에 대한 확실한 증거를 보여줄 수없는 소송으로 변했습니다. 그 결과 1970 년에 8 천만 달러 규모의 큰 합의가 이루어졌습니다 (2012 년 약 2 억 2 천 2 백만 달러, 인플레이션 조정). 여기에서 읽을 수 있습니다.

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing

충분한 시간, 주어진 성공의 정의에 대한 자원과 유연성이 가능합니다. 흰색 x- 질량 예제는 정확도가 50 % 이상이고 사용자의 지리적 위치와 약간의 통계 데이터가있는 경우 쉽습니다.

대부분의 프로젝트에서 가장 먼저해야 할 첫 번째 질문은 무언가가 가능한지가 아니라 특정 상황이 주어진다면 합리적인지 여부입니다.

이 기능은 시도 비용을 보장하기에 충분한 가치를 제공합니까?

아이디어가 굉장히 훌륭하더라도 개발 기간이 길거나 이국적인 하드웨어를 구입해야하는 경우 고객이 미리 이해하고 대화를보다 합리적인 목표로 이끌어가는 것이 좋습니다.

누군가가 당신에게 백지 수표를 제출하고 마감 기한을 갖지 못할 정도로 미친다면, 모든 것이 가능하다는 것을 알려주십시오. 그들에게 목표에 도달하는 데 관련된 몇 가지 기술을 발명하고 배포해야한다는 것을 알려주십시오.

다른 한편으로, 합리적인 자원을 가진 합리적인 고객을 다룰 때, 고객에게 동의 한 후에 일부 기능을 중단해야한다고 말하는 것보다 나쁘지 않은 경우가 있습니다. 그것을 문서화하고 10 %가 프로젝트를 처음에 친환경적으로 받아 들인 것일 수 있습니다. 이러한 상황에 빠지면 고객을 잃어 버렸고 시장 전체에서 매우 구두로 나쁜 참조를 얻었을 것입니다.

악마의 옹호자 연주

분석적 사고 방식이기 때문에 기술 담당자는 주로 완료된 요청과 커밋 된 요청의 스코어 카드를 기준으로 성능이 판단된다고 가정 할 수 있지만 실제로는 잘리지 않고 건조되지 않습니다.

개발이 시작되기 전에 고객은 자신의 자신감과 의지 수준에 따라 팀의 성과에 대한 의견을 쓰기 시작합니다.

그 이유 중 하나는 고객이 계약자의 주저가 주저하는 것이 어려운지 또는 계약자의 능력이 부족한지 여부를 평가하는 데 어려움을 겪을 수 있기 때문입니다.

요청의 난이도를 측정하기위한 절대적인 기준이 없기 때문에, 고객에게 더 중요한 것은 종종 계약자가 요청의 90 % 또는 100 %를 충족시키는 것이 아니라 100 % 노력을 기울이고 있다는 신뢰입니다.

고객이 두 시나리오 중에서 선택해야한다고 가정하십시오.

계약자 A :

• 그들이 모든 요청을 전달할 수 있다고 확신
• 결과 : 전달 된 요청의 90 %
• 고객은 계약자가 100 % 노력을 기울인 것을 기쁘게 생각 합니다
• 예상치 못한 문제로되지 않은 요청이 있다고 인해 고객 인식되면, 이는 아마도 외부 계약자 제어

계약자 B :

• 요청의 90 %를 전달하기로 약속합니다. 그들이 나머지 10 %를 제공 할 수 있다고 확신하지 못함
• 결과 : 전달 된 요청의 90 %
• 고객은 계약자가 요청의 다른 10 %를 완료 하려고하지 않은 것에 실망했습니다.
• 고객은 요청의 완료되지 않은 10 %가 계약자의 노력 부족 또는 능력 부족 으로 인한 것으로 가정합니다.

두 시나리오 모두에서 동일한 수의 요청이 전달되었습니다. 그러나 고객은 "오버 커밋"계약자 A가 100 % 노력을 기울이고 나머지 요청이 실제로 계약자 A의 신용에 어려웠 음을 검증하는 데 사용했습니다.

반대로, 고객은 계약자 B가 100 % 노력을 기울이지 않은 것처럼 느끼고 모든 요청을 완료 할 수없는 것은 계약자 B의 노력이나 능력 부족으로 인한 것입니다.

면책 조항 : 나는 과잉 헌신을 전략으로 옹호하지 않습니다. 이것은 과잉 헌신이 긍정적 인 결과를 가져올 수있는 실제 상황의 관찰 일뿐입니다.

"스파이크 솔루션" 을 만들 시간을 주어야합니다 .

스파이크 솔루션은 코드 작성시 프로젝트에서 불확실성을 유발하는 방법 또는 가능한지 여부를 파악할 수있는 작은 프로그램입니다.

예를 들어, 프로그래밍 방식으로 SMS를 보내지 않았지만 어떻게 든 가능하다는 것을 알고 있다고 가정하십시오. 스파이크 솔루션은 SMS를 보내는 작은 프로그램을 만드는 것입니다. 그렇게하면 더 이상 불확실성이 없으며 실행 가능성에 대한 추가 추정을 할 수 있습니다.

다음은 eXtreme Programming 설명서에 나와있는 내용입니다.

까다로운 기술 또는 설계 문제에 대한 답을 찾기 위해 스파이크 솔루션을 만듭니다. 스파이크 솔루션은 잠재적 인 솔루션을 탐색하기위한 매우 간단한 프로그램입니다. 검사중인 문제 만 해결하고 다른 모든 문제는 무시하도록 스파이크를 만드십시오. 대부분의 스파이크는 유지하기에 충분하지 않으므로 버릴 것으로 예상하십시오. 목표는 기술적 인 문제의 위험을 줄이거 나 사용자 스토리 견적의 신뢰성을 높이는 것입니다. 기술적 인 어려움으로 인해 시스템 개발이 지연 될 경우 한 두 주 동안 한 쌍의 개발자가 문제를 해결하고 잠재적 인 위험을 줄입니다.

내 경험에 따르면 사용자가 무언가를 요청할 때 사용자가 실제로 원하는 것이 무엇인지에 대한 자세한 사양을 요구해야합니다. 더 자주, 당신은 다시 요청에 대해 듣지 않을 것입니다.