Project management 你什么时候吹哨？

大多数人都在某个时候来过这里——在你的项目中，你会收到一些非常小的请求，你很乐意处理这些请求，但在某个时候，这些小请求会累积起来。有时，实施某件事情所花的时间比重新协商项目计划所花的时间要少

---

如果规范/需求计划是体面的，而且它不是一个注定要开始的项目，那么你到底在什么时候吹哨并开始重新谈判？有任何请求吗？该请求何时需要额外的页面/表格？或者只是去感受一下？我很想听听你是如何打电话的。

在项目计划中预算N小时的临时请求。（你知道这会发生，为什么不在里面呢？）然后跟踪你的临时请求，并在预算到期时重新协商。

我想说什么时候会影响计划/发布日期。如果发生这种情况，那肯定是时候揭发真相了。如果范围蔓延的幅度足够大，或者有足够多的累积变化影响了您按时发货的能力，那么您应该在预算失控的那一刻后退。

。你不能一直做这些“免费”的附加组件，除非你是为了慈善事业

---

一旦你放下你的脚一次，你会发现请求干涸

与单个日期相比，预计完工日期更像是一条概率曲线

任何额外的功能都会降低满足某个特定日期的可能性

当可能性的降低变得“显著”或值得一提时，你应该“吹哨”

有任何请求吗

真正的目标是让客户满意，同时又不被敲诈，对吗？敏捷方法在很大程度上解决了这些问题。新的需求总是会出现，如果你不在它们出现的时候解决它们，你最终会构建出过时或功能失调的东西。因此，您需要的是客户对流程的认可，尽快创建一个工作原型，并进行大量迭代。当然还有一吨，但这应该足够了

---

编辑添加：客户购买意味着他们知道您正在开发新功能，而不是您将要做的任何事情，并且他们同意。当你完成了你的计划和预算，但仍然没有完成时，他们会一直陪伴着你，并知道为什么。毫无疑问，“什么？你还没做完？！”

我只在这种情况下使用内部工具，我们的目标是在无法提前预测需求的情况下，最好地满足“客户”的任何突发奇想。因此，对我的回答持保留态度

我的观点是，这个决定通常是政治性的，除非你是公司的负责人，否则它甚至可能不取决于你。不满意的客户向你的老板讨价还价的代价可能更具破坏性

我非常相信敏捷和持续的需求收集，它确实涉及到查看用户如何使用产品，并尝试满足他们的需求。然而，每个用户都有自己的“好东西”，没有办法让每个人都满意。如果您有多个目标用户，那么democracy是一个很好的系统——只实现大多数用户都能从中受益的东西

如果您的客户是一个有凝聚力的群体（例如，您为特定组织中特定部门的用户制作），请运行Wiki网站或类似网站或其他引擎，让他们列出可能的功能，然后协同投票。明确表示你将优先考虑（但不保证）更高评级的功能，并且你可能不会优先考虑那些没有得到他人投票的功能

通过这样做，您可以让客户对想法应用一些协作过滤（或同行压力）。你也会得到一些能见度，这样人们就能明白为什么他们的愿望没有得到尊重。一个重要的附带好处是，无论是谁请求一个特性，现在都有兴趣很好地制定请求及其理由，这样他们就可以让其他人投票支持他们。这将消除一些愚蠢的半生不熟的想法

当然，所有这一切的一个基本假设是，您为“杂项功能”与项目付款者安排了一些时间。

同意：“在初始计划中考虑修订的时间、预算和检查点，然后跟踪”。从一开始就把事情控制住要比重新行动容易得多，特别是当你事先知道任何设计活动都会有变化时。