(资料图)

记得很早以前，我还在一家公司做程序员的时候，当时我们公司内部想开发一个什么系统或者开发一个什么功能，都需要七八个人一起开会讨论。包括我们技术部的程序员、产品经理，以及业务部门的系统使用人员等等，开会结束以后形成文档，然后我们技术部的产品经理会把文档打印出来，让参会的每个人都逐一签字确认。

每个参会的人员都要有契约精神，签名就代表对这个需求的认可，避免开发出来的功能不是他们想要的，也避免到时候发生需求变更时，说不清这个需求是谁提的，谁确认的。这样做的目的就是，可以避免一些不必要的需求变更，让每个需求都落实到指定人的头上，要对这个需求做到负责，以后出问题也更好追责。其实，这么做不是说，以后不能发生需求变更，而是让每个人在提需求或者提需求变更时，可以更慎重，当然了，也可以适当避免浪费我们程序员们的时间。我们都知道，一款软件从上线到运营一段时间，系统永远不变是不可能的，改变才是永久的，而不变是相对的。只做有必要做的需求，可做可不做的需求，尽量别做。当然了，不改变是不可能的，改变宜早不宜晚。越是在项目前期，改变需求的影响面就越小，越是到项目快结束的时候改变，影响的范围就会越大。所以，一般情况是，在项目接近完工时，不能再进行任何改变。那到底是什么样的需求可以变动，什么样的需求不能变动呢？比如随着系统的运营过程中，发现一个功能不调整就不能使用了，不调整就影响正常运营了，这样就需要改动，而且是需要加急修改，也或者是某一项功能在运营的过程中发现没用，就可以把这项功能去掉，当然了，去掉这个功能不用太着急，在下一次版本迭代时去掉就行。那什么样的需求没必要变动呢？比如看着这个按钮颜色不太好，换一个颜色吧，比如看这根线条有点粗，调细一点吧等等，这种看起来是在调整，其实大多都是无意义的调整。说实话，对于需求的改来改去，让系统能不能变好不好说，肯定是会让程序员会觉得你的行为漂浮不定，在他们心里会产生对你的抵触心理。总之呢，频繁修改需求不是正常现象，无论是软件外包、还是公司自营的产品，都需要认真对待，不应该是把产品的需求变更当做工作的一项指标，不是说软件产品变更越多你的工作就越充实。软件产品需不需要变更，还是得真正运营起来通过客户的反馈、通过数据说话。

作者：北漂程序员创业

想了解更多精彩内容，快来关注北漂程序员创业