问题五：需求变更和二次开发问题

前面的文章提到过，需求变更必然发生在软件生命周期的各个环节中；

需求的提出方有两个，一个是甲方，一个是乙方，没错，乙方有时候也担当了需求意见的提出；

而需求的内容，受到企业业务发展迭代，领导个人喜好，和实际研发过程中的关键性问题等各个层面影响；

任何的IT系统项目都要有迭代和二次开发的阶段，这也是软件生命周期内一项十分重要的路程。然而程序的修改和Office-Word、Excel截然不同，它势必要经历：数据重构-前端调整-后台逻辑重新编译-测试回溯等阶段。一个需求的提出要1分钟，但是去改他可能就要1000分钟，甚至更久。

假设现在你是一家生产型企业的负责人，打算开发一套企业一体化的集成办公软件，里面包含了OA协调办公系统、CRM客户管理系统、进销存ERP系统等模块；

现在你联系了一家不错的软件开发公司，你们就眼下公司的发展模式和业务需求，进行了深入讨论，并指定了一套看似可行的开发方案：

签约后，由项目经理带头开会，程序员、UI设计师悉数与会，会上软件公司指定了开发架构和模块功能，明确了开发需求；

UI开始设计界面了，发给你看，你觉得不错挺好看，继续做吧

前端工程师开始做网页代码了，发给你看，你觉得不错挺好看，继续做吧

后端工程师开始些程序交互了，发给你看，你觉得不错，都对，继续做吧

测试工程师开始单元测试、集成测试、回归测试了，发给你测试，你测试了下，没毛病，继续做吧‘

项目经理找你验收，部署项目，交付交接培训；你觉得没问题，验收打款，正式开始使用！

等等？

上面这些真的如我说的那么顺利吗？

并不是，现实是，UI设计师画的图，您可能并不满意，表示红配绿，重新做

前端设计师，做的网页，你觉得用户体验不够好，重新做；

后端工程师做的程序，你表示怎么这么绕，简单一些，重新编写；

测试工程师告诉你没问题了，你自己测试的时候一大堆问题….

在某一个进程中，你提供了一堆指导性意见，开发方笑纳了的你的意见，并重新指导开发；

渐渐的你发现，开发方好像对你的提议并不感兴趣，你慢慢感觉，好像你不提出修改意见，他们就不会有任何好的建议和开发内容；你感觉这真是“属算盘珠的，拨一下动一下！”

找人开发，你觉得比自己学程序开发都累，这时候的你俨然已经是一个产品经理的角色了；

吭哧瘪肚的你的项目终于迎来了验收，而这时候距离要求的工期已经超出了1个多月；

而你也成功获得了一次极差的合作体验；

好，我们下面转换下视角：

假设你现在是一名软件公司的高级项目经理，鉴于你不错的销售能力和专业知识，客户找到了你，并且成功签约了一个大项目；

本着前期给客户大的优惠，一期工程不要考虑赚钱的初衷；你和甲方良好的沟通下确立最终的开发内容；

尽心尽力的你，保持着和客户的频繁沟通，时刻盯着手下的技术团队开发；确保每一个环节都是高效和正确的；

但是项目的研发并不遂人意，在第一次的UI效果图确认的阶段，客户就当着你的面给了当头一棒！ “这都设计的什么玩意？红配绿吗！”

你配合笑脸表示，重新再设计一稿，直到他满意为止….

在你的电脑里面的项目甘特图上，一个本应该5个工作日确认的UI的效果图的阶段，硬是搞了半个月，客户才点头同意；

你心急如焚的对前端工程师说，加紧进度，该加班加班，赶赶工期吧；

前端工程师是你的徒弟也很给力的完成了你认为不错的工作，保质保量；你拿着前端效果去找客户确认，客户却一脸阴沉的表示，不是很喜欢；

这时候你的据理力争，从专业的角度分析了各种利弊，以一个多年的行业人士的角度去帮客户评判了当前设计的良好用户体验，客户被你说服了。

到了编程的阶段，你对编程的程序员兄弟说，前面的框架客户都确认了，你就按照要求的功能去做就好了，越快越好；

后端的程序员完工了他的公司，给到测试这边；最后你带着产品去找客户验收了。

客户把你带到他们的会议室内，你当着公司的管理层用大屏幕演示了产品；

一时间，议论声纷纷；会后，你看着会议记录上密密麻麻的修改意见，陷入了沉思，如果按照客户的要求去一条一条改进的话，那么撇开工期不谈，成本至少翻了一番；

但如果不照做的话，就意味了得罪和失去了这个客户，以及后续的合作可能性；

你咬咬牙，拿着客户的修改意见折返公司，重新开会，技术员跟你说，这么来改，意味着前面的工作大幅度推到重来，且复杂度翻倍增加；

本着长期合作的希望，你力压群雄，让技术部重新给你做了大范围调整；

但是等着你的又是一堆新的修改意见；你无语了，你的老板找到了你狠狠的骂了一顿，本该属于你的奖金也没有了。

无奈的你委婉的推脱掉了客户的一次又一次修改需求，并表示要修改得加钱才可以；

客户和你大吵一架….

那么也恭喜你获得了一次项目经理人常见的不良体验；

/////////////////////////////////////////////////////////////////////

有人说了，我们按照合约办事严格履行不就可以了吗？

那么我告诉你，软件开发合约，和商品销售合约完全不一样；

商品销售合约，可以预定交付产品的型号、数量、和检验参数标准，已经交付日期等等；

但是软件合约无法就每一个功能要求去做详细的约束；

即便是互联网大外包公司，有着标准严格复杂的设计约束，也无可避免就某一个开发细节所产生的争议，包括但不限于，客户觉得，和你觉得；

需求的提供无可避免，也无可厚非，然而技术的门槛与隔阂势必在问题暴露的时候造就引发互相的不信任和质疑链；

合约内容无法精准理解，服务和产品销售有着本质化的差异；以人的主观意志为转移的观点看法，不是一份粗略的合约可以约束和规范的；

“我们需要寻找一个大家认可和接受的开发规范或平台框架，在这个系统内去高效快捷的制作我们所真正需要的产品；”

否则：“把这个地方改一改？重新做下”

“可以，得加钱”

“什么？！”

“我找别家公司给我改！”

别家公司：“抱歉改不了，需要整个重新做…”

你？？？？

所以这也就是我为什么总说，没有哪个公司的软件产品是不需要迭代和二次开发的；只有不断的修改，才能时刻紧密贴合公司实际发展需求；再经过了数论甚至数年的磨合和应用后，才算是一个合格的企业级软件应用架构体系；

不能觉得，只有企业管理系统会需要这样，就哪怕是一个简单的企业宣传官网，你公司发展了几年，产品更新、门头更新、办公场所、服务业务更新，你也要想着去改版升级吧？

本文套用了两个角色体验了，在企业软件开发过程中的，需求变更和二次开发等问题；

很遗憾，我并不能从需求的良好沟通性和软件合约的严谨性两个层面去得出解决办法；

这些问题终究是不可避免的；

但或许我们可以考虑从另一个角度去考虑解决问题的办法；

用一种升维的方式和方法：