无休止的软件开发加班，无休止的软件项目实施变更、延期，无休止地在做软件需求调研、编写需求方案，展开需求验证，一再地处理因为二次开发带来的BUG；软件开发项目实施过程就被这无休止的二次开发活生生地拖死了，把这篇文章再翻出来，其实是想告诉大家：客户有他自己的要求，但对于软件开发管理和项目经理而言，并不是所有的要求就一定是需求。请注意软件开发管理在行为态度评估标准中关于“客户意识”的说明：帮助或服务客户的愿望以满足他们的要求，专注于如何发现并满足客户的需求（专业与公司战略和业务紧密结合）。我们的目标是满足客户的要求，但我们需要通过我们的专业能力专注于发现并满足客户的需求。意味着需求是被我们挖掘和发现的，往往不是客户直接所能表达的。这也是为什么我们有许多项目做了大量二次开发以后，客户满意度还不高的原因，因为我们看似满足了客户的要求，但这并不是他的真实需求。
多数情况下，二次开发都会演变成一个对软件系统无休止的修改过程，最终会把用户和厂商都拖进泥潭难以自拔，而开发和实施顾问则会心力交碎，生不如死。
在我做软件开发顾问的第一天，上司告诉我第一条准则就是要以用户需求为驱动。然后，上司又告诉我第二条准则：作为实施顾问要坚决不赞同用户进行太多的二次开发，过多的二次开发不仅会增加软件的不稳定性，还会延长实施项目的周期，从而增加项目成本，要用尽各种各样的办法把用户需求向软件软件已有的流程上走。这两个看起来相互矛盾的准则，令我在近期一个软件开发项目实施过程中感到生不如死，左右为难。
用户是一个老国企，在界面上和操作上提出非常多的特殊要求，固执地要求按他们的习惯进行二次开发，以满足他们原有的操作模式。一般来说，我们的软件软件产品为了具有较强通用性，软件功能已经比较标准，流程设置也相对规范化。虽然通过参数可调的形式可以部分满足不同用户的需求，但很多情况下这种“轻度”灵活会失效。
用户的固执或偏见主要是表现在这几面：
①不愿意改变现有的操作习惯。用户想把现在的手工流程、手工作业一成不变地搬到软件中去，而这恰恰是换汤不换药的做法。当我对用户分析软件现有的流程与用户原有的流程的优劣性比较时，用户一句话就把我顶住，说我们一直是这样做，而且还做得不错，我们就是用这样的管理手段得到发展，并且获得了上你们软件系统的资金，以后还打算一直用我们习惯的方式去管理。
用户除了在业务流程等方面具有个性化需求外，往往还存在着一些不涉及业务流程的、由企业的特殊性而产生的个性化需求，例如单据/表格的格式。一般软件都会提供通用的单据格式，而用户又有自己习惯的一套单据格式。因此在实施时，企业上来就问能否按这个格式打印。其实，这是本末倒置，只要该有的内容有了，没有必要一成不变的按原由的格式。
这样的问题在我参与的实施中时常出现，与用户沟通常常让我费尽心力，舌根冒火才勉强说服用户同意先试用单据格式。这样不但容易造成项目延期，而且还把大家注意力转移到无关系统的边缘流程上，吃力不讨好现象时常发生。
只有当碰到无法通过调节参数来完成;或者报表功能真是不适应用户需求时导致报表样式、内容要改变，这些情况才应该通过二次开发来实现。这种因操作习惯提出的二次开发主要针对用户各类报表系统的查询，打印格式和字段标准化等方面。
②不合理的管理制度造成的特殊流程需求。用户有些二次开发需求，是原先不合理的管理制度和流程所造成的。因此，我们首先要做的是判断其要求的合理性，然后深入到一线去找出真正的需求。而无数的事实证明，大量由于不合理的管理流程需求提出要二次开发的案例最终都失败了。
③软件软件确实无法满足需求。当然，每个用户确实都存在着一些软件无法满足的个性业务流程需求，毕竟软件是一个套装软件，而不是根据用户量身定制的。针对这种需求，即使通过各种各样的实施方法后，也没有找到更好的处理方式，那只好进行二次开发了。
当用户明确提出要二次开发的时候，则很容易出现项目延期、开发的程序不稳定容易报错等问题;或者用了一段时间后想再做修改，才发现原来当初这样做是不对的，但可能涉及当初拍板决定的各方领导利益问题，所以也没人敢改了，因此导致二次开发的程序成了鸡肋，扔也不是，不扔也不是。
①修改报表格式或用户查询系统等不涉及程序代码改动的需求相对简单，因为软件一般都具有报表生成功能，任何业务人员不需要有很多计算机知识就可以自行设置，这种情况在实施时经过实施顾问组与用户充分沟通一般比较容易解决。
②当用户需求具有个性化，并涉及改动程序代码时，工作就很复杂了，往往需要软件系统提供支持二次开发的工具，还可能需要有厂商软件的源程序支持，这些大都要支付额外费用。
当用户提出需要代码级二次开发时，实施顾问必须清楚与用户沟通，否则更易陷入泥潭，因为代码级二次开发可能会使软件系统变得越来越复杂，变成一个“四不象”的浮肿庞杂的软件系统。
一般来说，代码级二次