大多数人都曾在某个时候来到过这里——在你的项目中，你会收到非常小的请求，你很乐意照顾，但在某些时候，这些小事情会加起来。有时，实施某事所需的时间比重新协商项目计划所需的时间要少。
如果规范/需求计划是体面的，而且它不是一个注定要开始的项目，那么您实际上在什么时候吹哨并开始重新谈判？应任何要求？当该请求需要额外的页面/表格时？还是只是感觉出来？很想听听你是怎么打电话的。
routeNpingme
问问题
378 次
6 回答
12
在您的项目计划中预算 N 小时的临时请求。（你知道它会发生，那为什么不在那里呢？）然后跟踪你的临时请求并在预算用完时重新协商。
于 2009-02-15T20:30:06.507 回答
4
应任何要求？
真正的目标是让客户开心而不被敲诈，对吧？敏捷方法在很大程度上解决了这些问题。新的需求总是会出现，如果你没有在它们出现时解决它们，你最终会构建开箱即用的过时或功能失调的东西。所以你需要的是客户对流程的认可，尽快的工作原型，以及大量的迭代。当然，还有很多，但这应该足够继续了。
编辑添加：客户支持意味着他们知道您正在开发新功能，而不是您将要做的任何事情，并且他们同意。当您完成了您的日程安排和预算但仍未完成时，他们一直在您身边并且知道原因。没什么大惊喜 “什么？你还没做完？！”
于 2009-02-15T20:36:13.433 回答
1
我会说它什么时候会影响时间表/发布日期。如果发生这种情况，那么绝对是时候吹哨了。如果范围蔓延的幅度足够大，或者如果有足够多的累积变化影响您按时发货的能力，那么您应该推迟。
于 2009-02-15T20:32:53.957 回答
1
当你的预算被打破的那一刻。你不能继续做所有这些“免费赠品”的附加组件——除非你是为了慈善而做的。
一旦你放下脚，你会发现请求枯竭了！
于 2009-02-15T20:34:11.457 回答
1
我只在这种情况下使用内部工具，我们的既定目标是在无法提前预测需求的情况下最好地服务于我们“客户”的任何突发奇想。所以，我的回答持保留态度。
我的观点是，这个决定通常是政治性的，除非你是公司的负责人，否则它甚至可能不取决于你。不满意的客户把你交给老板的成本可能更具破坏性。
我非常相信敏捷和持续的需求收集，这确实涉及了解用户如何使用产品，并尝试满足他们的需求。然而，每个用户都有自己的“好东西”，没有办法让每个人都满意。如果你有多个目标用户，民主是一个很好的系统——只执行大多数用户可以从中受益的事情。
如果您的客户是一个有凝聚力的群体（例如，您正在为特定组织中特定部门的用户制作它），请运行一个 Wiki 站点或类似 SO 或其他引擎，他们可以在其中列出然后对可能的功能进行协作投票。明确表示您将优先考虑（但不保证）评级较高的功能，并且您可能不会优先考虑没有得到其他人投票的事情。
这样做，您可以让客户对想法应用一些协作过滤（或同行压力）。您还将获得一些可见性，因此人们可以了解为什么他们的意愿没有得到尊重。一个重要的附带好处是，现在请求某个功能的人都对制定请求及其理由很感兴趣，这样他们就可以让其他人投票给他们。这将消除一些愚蠢的半生不熟的想法。
当然，所有这一切的一个基本假设是，您预算了一些时间来与为项目付费的人“混合功能”。
于 2009-02-15T20:40:10.803 回答
0
估计的完成日期更像是一条概率曲线，而不是一个单一的日期。
任何额外的功能都会降低遇到某个特定日期的可能性。
如果可能性降低变得“显着”或值得一提，您应该“吹哨”。
于 2009-02-15T20:35:58.863 回答