우리는 모두 모호한 코드와 기괴한 예기치 않은 기능을 통해 수정하고 해결하기 어려운 문제를 가지고 있습니다. 패턴, 오류, 실수를 찾으려고 천천히 논리적으로 노력하십시오. 이 프로세스는 시간이 걸리고 종종 고객이 쉽게 이해하지 못하는 문제가 있습니다.
“언제 언제 수행됩니까?”라는 질문을 받았을 때, 특히 클라이언트가 소프트웨어 개발의 고유 한 복잡성을 이해하지 못하는 경우에 어떻게 대답합니까?
답변
당신은 정직하게 질문에 대답합니다.
당신은 그들에게 어려운 문제라고 말하고, 해결책은 분명하지 않으며, 해결하는데 얼마나 오래 걸릴지 확신하지 못합니다. 모든 [시간 프레임]마다 진행 상황을 업데이트하도록 약속하면 진행중인 작업을 알 수 있으며 실제로 업데이트를 보낼 수도 있습니다.
답변
개발자는 복잡한 문제를 작은 문제로 분해하여 개별적으로 해결함으로써 복잡한 문제에 접근합니다.
이상적인 세계 에서 문제를 해결하는 것은 복잡한 문제 A 가 될 것이며 주어진 시간에 문제를 짧은 문제 의 목록으로 분해 할 수있을 것입니다 .A 1 ~ A n , 각 평가 시간은 간단합니다. 초기 복잡한 문제를 해결하는 데 필요한 시간은 다음과 같습니다.
와 D는 분해 과정 자체 인.
실제 세계 에서 유일한 문제는 작은 문제를 해결하는 데 소요되는 시간보다 t ( D )가 실제로 더 크다는 것입니다. 다시 말해, 문제의이 수준의 분해에 도달하려면 실제로 문제 자체를 해결해야합니다.
당신은 여전히 할 수 있습니다 :
-
주어진 작업 (문제 해결)을 작은 청크로 분리하십시오. 각 청크는 여전히 복잡한 문제입니다.
-
각 청크의 예상 시간과 해당 위험을 평가하십시오.
예를 들어, 작업 1에는 약. 5 시간이지만 차단할 위험이 높으므로 고객에게 12 시간을 기대하십시오.
-
종속성과 시간에 미치는 영향을 평가하십시오.
예를 들어, 작업 19에는 2 시간이 필요하며 위험이 너무 낮아 2 시간이라고 말할 수 있습니다. 아닙니다. 3. 아닙니다. 그러나 작업 19는 작업 24에 의존합니다. 작업 24는 다른 접근 방식을 사용하여 작업 19의 코드를 완전히 다시 작성해야하는 방식으로 작업 19에 영향을 줄 수 있습니다.
-
모든 세부 사항을 고객에게 제공하십시오. 합계를주지 마십시오.
마지막 요점이 중요합니다. 합산하면 192 시간이라고 가정하면 고객은 매우 정확한 측정 기준이라고 생각하며 소비 시간은 189 ~ 195 시간입니다.
대신 세부 정보를 제공하면
-
걱정하는 고객은 192 시간이 아니라는 것을 이해할 것입니다. 평가 중에 결정된 위험을 고려하여 모든 것이 잘못되면 192 시간입니다. 모든 것이 더 나빠지면 238 시간입니다. 모든 것이 정상이라면 85 시간입니다.
-
걱정하지 않는 고객에 대해서는 모든 경우에 귀하의 답변을 읽지 않습니다. 그가 원하는 것은 나중에 당신을 비난 할 수있는 숫자입니다. 그가 읽지 않을 매우 상세한 답변을함으로써, 당신은 그가 당신에게 다시 걸리는 시간을 요구할 수 없다는 것을 알고 있습니다 : 당신은 이미 그 대답을했습니다. 그는 또한 합계를 계산하기 위해 답변을 읽지 않았기 때문에 나중에 당신을 비난 할 수 없습니다.
답변
Hofstadter의 법칙 을 포함하는 것을 잊지 마십시오 : Hofstadter의 법칙 을 고려하더라도 항상 예상보다 오래 걸립니다.
답변
일반적으로 CPM / PERT의 수정 된 수식을 사용합니다. 다음과 같습니다.
Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.
(멋진 수학 형식을 모두 수행하는 방법을 잘 모르겠습니다. 누군가이 형식을 편집하려면 자유롭게 느끼십시오.)
So, if you think:
Mn = 60 hours
Mx = 180 hours
T = 100 hours
C = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.
프로젝트 진행 방식에 따라 크게 달라질 수 있다고 강조하고 싶습니다. 며칠마다 프로젝트를 재평가하면 매주 업데이트를 제공 할 수도 있습니다. 그것은 과민 한 고객을 만족시키기 위해 먼 길을 간다. 🙂
답변
비 기술적 인 사용자에게 모호한 타임 라인을 설명하는 것은 어렵습니다. 이는 프로젝트의 창의적인 단계와 성가신 버그를 추적 할 때 모두 해당됩니다. 두 경우 모두 전통적인 “작업을 더 작은 조각으로 분해”도 작동하지 않습니다.
원래 작업은 후자의 경우에 중점을 두므로 그에 대해 살펴 보겠습니다. 타임 라인을 제공 할 수없는 경우 사용자에게 무엇을 시도하고 언제 다시 연락해야하는지 알려주십시오. 자체 부과 타임 라인의 중간 지점에 도달하면 짧고 정직한 이메일 업데이트를 제공하십시오. 마감 시간 최소 1 시간 전에 정식 답변을 제공하십시오. 이제 당신은 신뢰성이 있습니다. 문제가 해결되지 않으면 최소한 빛이 비추는 것입니다. 시간 낭비처럼 보이지만 그렇지 않습니다.
답변
알려지지 않은로드 블록과 예상치 못한 놀라움을 설명 할 수 없으므로 자신감있게 추정하는 것이 어려울 수 있습니다. 아이디어 :
- 범위를보십시오 – “나는 확실히 그것을 적어도 N 일 (예 : 3)을 차지하지만 수 4N 많은으로 가라.”
- 견적을 추정하고 방어하는 데있어 상급 엔지니어의 지원을 요청하십시오.
- 더 짧은 반복 (Agile / Scrum 스타일)으로 작업하여 비즈니스 가치를 추가 (신뢰 및 신뢰 확보)하는 최소한의 코드를 생성 한 다음 반복하십시오.
- 고전적인 예 (예 : http://www.amazon.com/gp/aw/d/0143118757)와 같은 책에서 협상 기술을 배우십시오.
답변
새로운 개발, 특히 애자일 개발 :
“추가 할 항목이 없을 때가 아니라 제거 할 항목이 없을 때 완벽합니다.” -앙투안 드 생 텍쥐 페르
시스템에 대한 친숙한 도메인 지식을 가진 개발자가 거의 없거나 전혀없는 끔찍하게 지나치게 복잡한 시스템에서 오류를 재현하기 위해 거의 불가능한 오류를 수정하려는 노력과 시간을 추정하는 경우 유일한 해결책은 “고정 될 때”입니다.