需求变化的根源是什么？

在不按时算薪的行业里，软件开发应该是加班最多的一个行业。码农，是很多程序员用以自嘲的称谓。长时间的加班，大量的BUG，无穷无尽的特性，永远都在做的重构，伴随着程序员职业生涯的始终。对比国外的微软、GOOGLE公司那种轻松愉快的工作，国内的程序员的工作真的就如同面朝黄土背朝天的农民一样艰辛。很多程序员都坦承软件开发是一件体力活，程序员干不到三十岁的论断，也流传甚广。

软件项目一直是一种高风险的项目，除了产品是否畅销的市场风险，还有大量的产品在开发过程中夭折。

比如软件项目的主要开发团队离职，旧的代码无法给新的开发人员接手，被迫重新开发，导致成本无法支持。

又比如软件项目的中的需求反复修改，客户意见一直无法稳定，而合同的金额却早已签订，最后项目只能以撕毁合同告终。

还有软件系统交付后，所谓后续维护的工作量大大高于原先预计，最后尾款无法收回。

有些软件系统开发进度总是让人感觉举步维艰，一些关键要素迟迟无法突破，比如在线用户数一高就会导致服务器崩溃；如此总总，多不胜数。

高强度的工作，却产出的是高失败风险的结果，这个悖论一直困扰着软件开发业。如何避免软件项目失败，整个软件业界都在孜孜以求。要探讨如何解决这个问题，必须先来研究一下造成问题的原因。

一 需求持续变化带来的痛苦

我们时常会从《硅谷传奇》之类的传记里面读到，一两个天才程序员，凭借在车库里面的一些天才的开发工作，写出了让世人惊奇的程序，然后迅速成为了IT业界的明星。然而现实是大量的软件，都在类似黑网吧环境的“软件血汗工厂”里面被开发出来。难道开发能力真的存在那么大的的差别吗？

软件项目管理的书籍汗牛充栋，无数专家学者都在这个领域花费毕生心血。但是软件项目管理也是至今为止进步最缓慢的一门“学科”。如果世界上真的存在一种知识，能复制车库里的神话，那么相信现在应该已经传遍全世界了。

为什么神话能是神话，为什么还有大量的开发团队在苦苦挣扎，我们要看一看两者项目之间的差别：

• “车库”产品的需求提出者是开发者本身，他们一心一意的做自己想要做的东西。“工厂”产品的需求提出者往往不是开发团队，他们需要完成很多不同方面的需求，有些甚至是互相矛盾和模糊不清的。
• “车库”产品的开发者人数很少，他们最多的沟通就是左脑和右脑之间。“工厂”产品往往涉及大量的不同岗位，从客户代表、市场人员、销售经理、售后工程师到程序员、美术、产品设计、项目经理、老板/投资人、测试人员等等。
• “车库”产品的开发者目标很清晰，以自己认为的最好方式，去做自己认可的事情。“工厂”产品的开发者往往很纠结，项目中有一些感兴趣的技术，或者创意想要实现，但是这些又不一定能被允许在项目中实施。 其实归根到底，两者最大的区别，还是关于需求的：

1) 需求是否明确；

2) 需求的沟通是否通畅；

3) 开发者自身的需求取舍。

二 需求的变化类型

对于需求是否明确，往往需要和需求方反复沟通，有很多时候还需要把程序做出来，然后在使用的过程中反复修改，才能一步步的逼近真正的需求真相。做过行业软件的程序员都知道，真正的产品和第一版展现给用户的产品，往往是大相径庭的。大部分非软件行业的客户，对于计算机的“死板”逻辑，以及软件工作方式，几乎是一无所知的，因此想让他们在纸面上描述出一个程序应该是什么样子几乎是不可能的。

开发团队往往需要根据自己的猜想（很多时候是幻想）来构造第一个版本的系统，因为开发团队也不具备行业知识，所以做出来的系统和客户的需求之间常常有巨大的差距。然而双发沟通需求的唯一媒介，就是这个看起来一无是处的软件。在经过不断的、天翻地覆式的修改之后，软件才慢慢接近需求的彼岸。而在这个过程中，开发团队付出了巨大的工作量，都是在最终版本的软件上看不见的。有很多运气不佳的团队，甚至在开发这个过程的路上就倒下了。因此说，客户的需求变化，就是开发团队的直接杀手。

[例子]2004年，我经历了一个项目，是一个著名私人医院关于短信平台的项目。因为是招标的项目，所以我们团队制作了标书，上面列满各种功能点。最后我们顺利中标，但是在经历了无数次在机房打地铺的通宵开发鏖战后，发现这个项目中所需要完成的功能，实际上并不是甲方非常在意的功能，他们最需要的仅仅是一个用户注册和广告发送的平台而已。虽然我们基于对合同的履行，把承诺的每一项功能都完美的做出来了，但是甲方在验收的时候都是轻轻放过，反而是那个并未纳入标书，在初步试用了系统之后，口头上提出了的需求，是对方最看重的。我们加班加点的在验收日到达前，赶完了这个粗燥的需求。虽然这个项目本身不致于失败，但是这个客户因为这个需求实现的不满意，最后等于是流失掉了。

[例子]2009年，N公司有一个网络社区，在经过2年多的开发后，终于上线了。然而就在上线的当天，就发生了运营事故。某个运维的配置错误导致了服务器当机。而在后续的三个月之内，几乎每天都有运维事故，或者是在线发现重大BUG。整个团队陷入了不断救火，然后因为救火而引入新的BUG，然后为了BUG要补偿玩家而加入新的临时功能和操作，这些操作又引发了新一轮的运维事故。另一方面，产品在上线之后，各种管理指令，客服后台，营销活动，部署发布，压力测试，甚至还有老板的个人特殊帐号需求等等的需求纷至沓来，开发团队一边要应付在线的需求，另外一方面还要继续开发内容。上线的产品在发挥了“沟通”的媒介作用之后，各种需求开始爆发。最后这个产品就因为不断的“还债”开发中而失败了，因为玩家觉得游戏内容更新太慢而纷纷离开。

第二个关于需求的沟通是否通畅的问题，在需求方和开发方两面来看，似乎还不是非常的复杂。但是如果你深入到开发的过程中，就会发现，需求方本身也并不太清晰，软件项目除了真正的使用者以外，市场部人员希望产品能有方便推广的卖点，销售人员时常也会提出能分渠道统计销售业绩的功能，售后人员则是希望有coredump等故障现场保留，老板则喜欢产品能体现公司的品牌风格……为了实现这些五花八门的需求，开发团队就不再仅仅靠程序员就能完成，需要额外加入人员包括美术、策划、测试甚至音乐制作人员，一个事情需要沟通的环节成几何级数上升，工作中的出错和延误也就因此暴涨。

[例子]M公司是一个创业公司，一群热爱游戏的成员一起开始开发梦想中的游戏，但是很快他们能就发现项目陷入了泥潭，技术人员往往都是在等美术人员的图像文件，然后等来的是技术无法直接使用的。因为那些图片要么容量过大，精度过高，要么就是隐藏在一大堆不知所谓的文件名的文件包之中。而美术人员则经常抱怨策划总是改他们做好的图，而且角色和场景的比例这些重要的设定全部没有，都要等画出来之后再看，大大延误了时间。策划除了受美术抱怨以外，还要天天被技术说配置的游戏数据表出错，有时一个简单的格式错误就能花策划一整天的时间去找。在版本发布之后，客服和市场部的抱怨也爆发了，因为他们根本不知道游戏里面修改内容的细节，很多玩家的咨询客服都无法回答，而市场部则错过了很多可以用来推广的游戏内容。而公司的老板则天天好像一个测试人员一样，不停的玩自己的游戏，因为这样他才能知道自己的投资到底变成了啥。整个公司团队都在一种郁闷的环境中工作，最后产品的开发进度越来越慢。

第三个关于开发者自身的需求，往往是被忽视的部分。我们通常都会说这些是因为技术人员的清高或者固执。但是无可否认，软件开发依然是现实世界中，唯一一种仅仅靠思想就能“制造”出的工程产品。开发人员的思想，会直接的影响着这个产品有很多项目组中，开发人员会因为不能被允许按照自己的方式开发产品，而选择辞职，这直接导致了大量产品开发的搁浅。开发人员对于需求的理解，直接形成了产品，他们所认为的轻重缓急，会不断受到开发过程的影响，这些影响也可以视为一种需求变化。为了应对这种变化，开发人员会增加许多额外的工作量。最典型的例证就是，一款正在向某目标开发的软件，因为第二天需要迎接某个风险投资人的评估，而临时改变开发目标。或者是客户对于某个很重要的需求的临时增加，也会打断既定的开发过程。这些打断，必然会引起开发者在某些方面的需求，比如软件的可插拔性，可扩充性等等。

另外开发者对于开发的过程也有需求，比如使用何种开发工具，在何种环境下开发，使用什么开发方法，采用什么开发架构来实现，这些都会对软件提出很多非功能性的需求。这些需求会随着开发过程会不断变化，比如有些开发者会学会了一种新的技术，就期望应用到现有的产品中，用来解决之前一直困扰他的一些问题。有一个网络社区的服务端主程序员，就自己利用周末时间，用新发布的Spring框架重写了整个系统。而某个CMS的开发人员，因为学会了更好的利用数据库性能，也直接重构了整个系统，并且重写了存储部分的代码。

[例子]某在线社区产品，使用FLASH ActionScript2.0语言开发的。但是在上线仅仅半年之后，FLASH就发布了ActionScript3.0语言，这个新的版本对于FLASH技术来说，是一次脱胎换骨式的更新。整个FLASH开发都会变得更加“专业”，语言本身的成熟度也提升了一个数量级，而且新的语言也带来了新的功能，和新的性能上的显著提升。于是开发团队就开始提出要用新的语言来重写整个产品，因为本身这个产品就是以“新技术”作为特点的产品。最后投资人同意了这个计划。但是，直到9个月之后，团队才完成了基本的重写工作，因为产品需要一边更新内容来留住用户，一边加班加点的希望重写进度能赶上新功能的开发速度。就在这9个月里面，很多竞争对手的产品如雨后春笋一样出现，这个产品从市场角度上失去了9个月的机会窗口。更严重的是，这个过程中过于巨大的工作压力，导致几乎所有参加这个项目的技术人员辞职。

[例子]K公司突然收到消息说3天之后，有一个重要的风投公司将来评估此公司的投资价值。为了彰显本公司的开发能力，老板决定集中力量尽快仿造当时最流行的《植物大战僵尸》，做出一款类似的游戏产品。于是整个项目的其他开发都停了下来，最有力的开发人员搬了电脑到会议室，开始了紧张的开发工作。然而3天过去了，投资的事情并没有这么快就落实下来。整个项目应为主力连续高强度的加班3天，连续的超长工作日导致有人生病，需要请假等等，这样就会让项目本身的进度受到了较大的影响。而这种临时性的需求，在这个项目的运营过程中发生过不止一次。

以上三种关于需求的讨论，最后都指向一个结果，就是会增加开发工作量。无怪乎程序员和软件开发团队的加班是如此的常见。

因此，可以总结出来，软件开发过程中，最核心的矛盾就是——需求变化和开发效率不符合的矛盾。

三 需求的变化带来的问题

这个矛盾始终贯穿着软件开发的历史，在进入互联网时代之前，需求变化已经是“臭名昭著”了的。需求变化可能来源于一个“喋喋不休”的老板，或者是那些心比天高的用户，又或者是强悍的竞争对手，市场部的兄弟姐妹们也经常充当这个“可恨”的角色。当然还有一些直接就是开发者自己给自己挖的坑。而要满足这些需求，开发团队能有的工具是如此的少，几乎只剩下一个手段，就是加班。不管是做出来客户不要，还是做出来有大量的BUG，又或者是根本就追不上发布计划，总之大多数公司都会下令：做完为止。

需求变化内容也难以捉摸，有的是要增加功能，有的是要限制功能，还有要求以前的旧功能的。从一两个界面的文字修改、按钮大小调整，到整个功能几乎全部不能用的都有。有时候这种需求所要的时间还非常紧急，昨天才说半年后可能需要，今天就说明天就要。开发团队对于这些需求变化导致代码质量下降，往往束手无策。

需求不断的变化，导致软件迟迟不能交付，加速需求变化似乎飘忽不定，原定架构无论怎样高瞻远瞩都无法涵盖，加上对于软件的频繁修改，更是带来了大量的缺陷，这里我们有一个通用的叫法：BUG。

需求的持续变化，带来了更多的深层次问题，最核心的就是开发团队的士气问题。“人心散了，队伍就不好带了”，无止尽的需求变化就会带来无止尽的BUG，以及无止尽的重构甚至推到重写，然后就是无止尽的加班。开发团队人员越来越疲劳，对项目失去信心，得过且过，或者直接跳槽。

如果开发人员跳槽了，就算能找到别人接手，面对一大堆别人写的，修修补补的代码，也是一个巨大的挑战，于是项目需要停下来等新程序员掌握旧代码，拖延的进度就越来越多。需求变化就如同一个潘多拉盒子，一旦打开，就会引发后续的连锁反应，直至把项目拖入是失败的深渊之中。有大量的软件项目是死于“做不完”和“赶不及”，而很少是死于“做不出来”。

经典软件项目管理书籍把“需求变化”比喻为焦油坑。焦油坑——很多史前巨兽，如猛犸象、剑齿虎一旦被陷进了焦油坑，无论如何挣扎，最终都会越陷越深，最后遭受灭顶之灾。这些焦油坑保留到现在，也是这些史前巨兽的化石宝库，可以让现在的人来研究。而那些大量因为需求变化而失败的项目，也是我们现在用来研究软件项目管理的最好资料。

无论多强大的软件公司，或者是技术高超的程序员，面对软件项目，经常都会发现自己处于一个项目的焦油坑：无论是继续增加人手、投入资金、购买服务，都无法顺利的结束这个已经延迟了很久的项目。只能眼睁睁看着所有人在项目里无望的挣扎。而软件项目管理的知识，就是避免开发团队陷入这种“焦油坑”的一种经验。

四 互联网上没有秘密，需求变化从开发者开始爆炸

在互联网兴起之后，软件开发领域突然进入了一种莫名其妙的混乱当中，在这个潮流里，人们分不清谁是用户，谁是开发者，谁是投资人。

开发者可能自己在用自己的服务，比IM软件，开发这个软件的开发人员，本身就天天在使用它，而且还经常把“自己认为应该”加入的功能，加入到开发计划之中。著名的LINUX系统，就是为了使用操作系统的“用户”自己去开发的。因为自己就是用户，因此产品需求中，开发者本身的需求会大大的增加。而且这些源于开发者自身的需求，往往是推动软件产品迅速进化的一个动力。有一些项目开发团队，无法分辨是应该听取那些不完整的用户意见，还是应该遵循自身需求，盲目的投入开发方向，最后导致项目失败的比比皆是。正如苹果的乔布斯所说，用户根本不知道自己要什么。在互联网时代，完全跟着订单来开发的模式往往是没有生命力的。

著名的游戏开发公司暴雪公司，就认为如果开发团队不喜欢的游戏，就注定是失败的游戏。而一些著名国内游戏开发团队，也因为对于产品有自己的坚持从而成功，比如《大话西游》和《梦幻西游》等都强调网游就一定要加强玩家的交互。而不像国外的游戏只是把网络特性作为游戏的一个方面。因此比国外网游多了很多专用于玩家交互的系统，比如师徒、夫妻、帮会等等。而《征途》则更加进一步把一个服务器的玩家组织起来和别的服务器玩家PK。这些需求的来源都是开发者本身，而非传统的制造业的那种订单模式。

因此互联网产品更多具备的是创作的特性，从这点来看更像电影拍摄，由开发者发起的产品需求，并且在开发者的价值观下进行生产。这种模式对于软件项目管理来说，就提出了巨大的挑战，因为需求管理不再是针对用户代表，而是要更多的关注开发团队自己。或者说如果开发团队本身提不出有效的需求，产品就会失败。这和传统的“挡”“推”“闪”应对需求变更，有天壤之别。这要求开发团队拥抱需求变化，而不是抵制需求变化。

五 为了获取需求而产生了大量需求

用户本身直接购买产品或提供价值给网站，供其继续运作。但是用户却并不直接下订单或者谈合同，而是以“用脚投票”的方式来表达自己的需求，这给需求搜集带来非常大的难度。而那些关于“用户沉默离开和用户为何要离开”等一系列的疑问解答，也只能从一些用户的使用行为中探寻。大量的互联网公司，都依赖直接分析用户的使用行为，来调整产品的需求定位，因此对数据统计和数据分析提出了重大挑战。

因为看待问题和寻找问题的方法都不同，行为需求的搜集和统计也都需要开发工作量。项目需要先定义哪些行为需要搜集，然后用开发程序去记录不同用户的使用行为。而程序开发记录需要把这些用户行为作为流水日志，并安装统计的目标来进行合并和过滤。因为需要统计查找的目标不同，合并和过滤的程序也不同。所以用户数据搜集工作本身也包含了大量的需求、发掘的需求。

有的项目就一直被困扰在不停的做数据统计之中，迟迟无法确定应该如何前进。有一款网游加速器产品，为了摸清楚现在网络的整体情况，以便能做出完美的加速方案，进行了长达数年的用户数据搜集工作。结果是网络本身的情况是在变化，而使用这个产品提供数据的用户也日新月异。这个项目就一直在不停的统计数据，而无法真正确定开发的需求来。

开发者会和用户在网上无时无刻的沟通，每分钟都可能修改软件，同时也获得反馈；不管是大名鼎鼎的QQ，还是论坛之王DISCUZ，包括163邮箱，以及几乎所有的网络游戏开发团队，都会设法直接在网上和用户互动，希望获得更多的用户反馈。虽然用户的意见有很多偏激和片面，但是也不乏有真知灼见和代表性的案例。“沉默的大多数”和“激昂的少数”同时存在，如何吸取这些意见的合理部分，如何发掘背后的需求，成了项目开发的重要课题。有些游戏完全依赖用户的论坛意见，结果渐渐做成了一款小众游戏。而有的产品则一意孤行，被别的竞争对手快速超过。

有一款网络游戏，每次在推出新的内容时候，都会收到大量的玩家骂声。因为新的内容往往提供了新入用户超越老玩家的机会，所以对于一个已经有老玩家“称王称霸”的社区里面，不管是任何的新内容都会有反对意见。开发团队碰到这些反对意见，因为缺乏处理的经验，往往惊慌失措的从新修改内容，保护老玩家的地位，结果这个游戏就因为新玩家流失越来越快而渐渐冷清了，最后老玩家也陆续离开了游戏。

互联网项目就好像一个变色龙，谁也不知道明天会变成什么样。但是开发者每天都在拼命试图去了解明天可能的模样，并且试图去控制这种变化。而这些努力，又是必须支付比以往更多的开发工作。

六 软件成为开发工具而产生的需求

互联网上的产品，他的功能和内容就是用户自己利用一些工具开发的。著名的网络游戏《魔兽世界》，就有大量的用户利用其插件脚本工具编写自己的界面，并且发布到网上供别的玩家使用。而社区型游戏《梦幻西游》，因为玩家的互动产生了大量的社区活动。更不要说类似微博、相册这类互联网应用，本身就是用户直接的信息共享平台。而大部分的现代网络社交产品，始发于FaceBook，都会提供开发者API，让用户自己在上面开发应用。Google的API则已经成为互联网上的开发经典库之一。而FaceBook已经拥有成千上万的用户应用程序。另外一个叫虚拟人生的产品，则直接提供了一整套3D建模工具给用户，让用户直接构造出虚拟世界。有的公司甚至靠在这个虚拟世界中卖虚拟产品为生。

这类产品形态，开发者和使用者往往混淆起来了，很多人认为“开发者”自己的需求并不重要，反而变成了重要的产品需求。而因为“用户开发者”的加入，为产品带来了巨大的不确定性。这些产品新的变种部分，可能增强或者危害产品本身。因此从后台浮现更多的实时监控、安全加密、架构设计需求到前台，项目的开发需求正经历完全不同的颠覆。

从另外一个层面上说，因为互联网产品需要持续的更新和开发，一套完善的产品工具库，包含了诸多经过实践提炼的需求实现，这些需求实现都是非常有价值的。那些能把自己的产品做成开发工具的项目，往往都具有强大的灵活性。在游戏开发范畴，这一类工具被称为“引擎”，最著名的“引擎”就是FPS类游戏QUAKE的引擎，还有3D游戏的BigWorld和Unreal等“引擎”都被广泛销售和使用。在网游的童年时代，那些称作MUD的文字网游，则几乎都是由一套叫做MudOS的代码驱动，上层配上不同的GameLib程序，从而形成完全不同的游戏。而这套MUD OS和基础GAME LIB，居然具备了在线文件管理和文件编辑及编译的整套功能，于是无数个MUD游戏诞生了。

这些应用软件的特定开发工具，能让互联网软件产品变得更加的丰富，为了获得这种强大的开发能力，所以我们对于软件的需求就不仅仅是用户的使用需求，还有另外一个重要需求，就是要满足开发者用来进一步开发这些软件本身的需要。

七 软件成为水和电后产生的非功能需求

全世界用户每天24小时都在使用互联网软件，开发者也不再是把软件塞入盒子交给用户就了事了。他们必须7X24的、不间断的为用户提供服务。互联网软件的运行往往依赖成千上万台机房里工作的服务器群，这些服务器就如同发电厂的发电机或者自来水厂的水泵一样，要求有高度的可用性管理。对于随时变化的使用量，服务器集群要能随时接受海量用户的冲击。这些都要求开发者将运维管理和监控的需求放到非常重要的地位。如果这些服务器管理的需求和功能需求混合到一起，没有好的软件技术支持，那么开发将是一场噩梦。在我们为软件添加各种各样的功能的同时，我们往往会忽略那些对应的性能需求以及管理需求。这种不完善的功能一旦上线，经常会导致服务器集群的大量故障，从而出现严重的运营事故，这种事故会造成大量的用户价值的损失。对于提供服务的公司来说，是非常致命的。

大家一定感受过在大年三十的晚上发短信发送成功的概率比平时要低，因为那天发短信的用户要比平时高出很多。而在911当天，很多新闻网站也被潮水般的网络访问者冲垮，原因也是用户访问量比平时多出10倍，从而导致网站服务器发生雪崩式的故障：过多同时涌入的访问者堵死了新闻数据库，然后导致了那些依赖数据的“缓冲数据”服务器的故障，最后那些提供页面显示的服务器被迫滞留大量网络连接，最终整个网站终于陷入整体瘫痪。

一个良好的互联网软件，现在普遍需要满足高可用、低延迟、容灾热备、负载均衡等互联网特性。而要满足这些特性，就需要额外的增加导航目录服务、接入服务、状态监控和自动切换服务等等。这些服务都隐藏在用户点击链接之后，默默无闻的提供高稳定性的软件运行。像提供服务器集群管理的LVS、作为高速WEB缓冲的反向代理软件Squied、还有用来提高数据库性能的sql-proxy等著名软件，可能每个上网者都用到过，但是知道的却不多。

这些复杂而精巧的软件，都是互联网软件特定的需求。

八 互联网产生的新型商业模式导致的需求

在互联网上，越来越多的用户只为软件提供短期付费，他们随时可能离开。开发者无法通过以往的销售手段，打包产品完整的卖给用户，因此，对于开发者的盈利能力来说，是一个非常重大的挑战。吵吵嚷嚷的用户论坛里面，笑脸共骂声一色，板砖与鲜花齐飞，让人难以鉴别哪些是真正有利润价值的需求。软件开发者往往顾的哥情失嫂意，新功能上线一天就倒退回到旧版本的事情是司空见惯。互联网项目就这样在不断的折腾中“运营”。很多公司因为无法承受这种折腾，最后只好关门大吉。

最典型的例子就是曾经的网络游戏，游戏运营团队都知道，公测之后的收费是一个巨大的坎，原因是很多游戏公测时宾客盈门，一到收费用户就大量离开。成功破解这个难题的产品就是一款收费游戏——《征途》，这款游戏利用富有争议性的道具收费，让玩家延迟支付，并且一点点的收取费用。从此国内网游几乎都走向了这种道具收费的模式。然而，这种收费模式必须比进门就收费的模式，承担更多的用户在线资源消耗，要维持大量的免费用户群体，必须付出额外的开发量，而这些开发量的回报，则再需要一些额外的系统，来向那些真正的消费群体收费。

互联网奇特的商业模式，让软件开发从“卖功能”转向“留用户，然后收费”的先吃后卖模式除此之外，互联网行业还有大量更加特别的商业模式，比如卖流量、卖排位、卖数据、用户间交易收费，等等。。这些商业模式的不断探索，也导致增加了大量的开发工作。

九 互联网残酷的竞争产生了新的需求

在互联网上，一个公司经过大量用户数据的搜集，然后花费大量精力的在数据中分析，找出市场机会，最后经过长时间艰苦的开发，终于让新功能成功发布，但是就在这个新功能在发布的同一天，他所有的竞争对手就能看到，并且可能就已经开始分析和仿制，这些“抄袭者”只需要面对“如何把东西做出来”的问题就可以了。所有的公司都在追求拥有最多最新潮的功能，也追求最稳定的质量。开发团队不是在和一个竞争对手生死较量，同时也在应付全世界所有的竞争对手。

我国的知识产权较弱，创意更加是“不值钱”，只有能最快最稳定的把创意做出来，才是有价值，而且要一直都做得最快。因为互联网行业往往是残忍的赢者通吃，用户会全部聚集到名列前茅的公司产品下。

我国著名的互联网公司腾讯，就曾以学习竞争对手而闻名。不管是亲密战友金山还是死对头奇虎360，都从善如流，拿来就做。就连互联网时代的病毒，都以一日三更新的速度在传播，著名的熊猫烧香，就是因为作者的“勤奋”而让诸多杀毒软件措手不及。

开发团队在激烈的竞争压力下，都会争相采用最新的技术，并且日以继夜的开发。加上软件通过互联网发布几乎是瞬间的，软件开发再无版本之间的“喘息”机会。如何能让开发团队保持好的开发效率，这几乎是每个项目经理都冥思苦想的问题，除非他并没意识到需要用提高开发效率来解决加班的问题。

十 不变的只有变化

需求变化最根本的来源是人对于世界的认识规律，人类必须要通过实践才能认识世界。同样软件本身，也必须通过使用和开发的实践，才能认识清楚软件的需求。因为软件的需求往往就是对于世界的认识。

1 软件业正致力于应对需求变化

软件只有被生产并应用起来，人才能真正的对其有正确的认识，基于这些认识，软件中的设计错误才有可能被改正。这个过程循环不止，但软件项目本身如果跟不上这个节奏，就可能惨败。如何能最低成本的进行这个循环，降低每次修改造成的浪费，是应对这种反复修改的重要手段。

在人类真正清晰完整的认识世界之前，需求变化都是不会停止的。所以我们要做的不是去怎样拒绝变化，而是把需求变化看出是软件开发中最重要的一环。软件业发展至今，业界已经在软件工程学上取得了很多突破，我们应该要去学会使用这些知识，去更好的控制需求变化，让需求变化为软件项目服务，而不是阻碍项目的发展。

需求变化所导致的问题，往往不是狭义的软件开发技术能解决的，于是软件业先辈们苦苦思索解决之道，软件项目管理，软件需求管理，软件开发管理等学科就开始萌芽了。结构化编程、面向对象分析方法、瀑布式开发模式、敏捷开发模式、持续集成、ITIL等软件管理知识不断被发明并总结出来。

另外一方面，在软件开发语言、开发工具等方面，也有大量为了解决“软件开发危机”而出现的新技术、新语言。从汇编到C语言，然后到基于虚拟机的JAVA，最后到现在诸多的脚本语言：LUA\PYTHON\JS\PHP\RUBY，善于解决并发问题的过程化语言Erlang\haskel\Scheme等等，无一不是在提高软件开发者的工作效率。开发工具从传统的gcc\vi\make到现在的IDE集成环境，再到插件式的IDE——Eclipse平台，都有着长足的进步。而设计模式、架构模式更是在不断的总结各种新环境下解决开发问题的经验。

现代的软件开发，已经从以往的对硬件性能的控制，全面转向以提高软件开发效率这方面。我把这些知识统称为“软件工程”知识。

2 提高开发效率是根本方法

所有的软件工程知识，最后都是为了达到一个根本目标——提高软件的开发效率。因为只有提高了开发效率，才能真正从本质上解决软件项目管理的难题。

开发效率提升之后，会让项目进度加快，同样会降低开发工作的强度，反过来会降低BUG的出现概率。

开发效率提高之后，软件不仅能更快的发布，而且还能更快的获得用户反馈进而能尽快修正开发方向。

同样更高的开发效率能在市场上保持强大的竞争力，不再怕对手的抄袭，因为就算抄也没我抄的快。

开发效率提高还能腾出更多的开发人员和资源，用来提高项目的安全性、稳定性、运行性等非功能目标，让软件在另外一个层面产生竞争优势。

然而，提高软件开发效率绝非易事，因为软件开发到现在为止，最主要的瓶颈还是开发者本身。到现在为止还没有哪种机器能做到“让一行行的软件代码和数据快速而高质量的生产出来”。而且更要命的是，没有一种作品像开发软件那样苛刻。比如说，一篇文章有个别用词不当，不会导致文章不可读；图画有一两败笔还能算一副图画；音乐演奏的一点点失误也尚可忍受。而软件则要求人类100%正确的去实现逻辑，这种劳动压力远远大于一般的脑力劳动。

要解决最常见的软件项目的开发难题——需求变更，只有提高开发效率是根本之道，而开发效率的根本所在是人。只有让人去掌握诸多软件知识，让人去关注开发效率，才能真正的拥抱需求变更。

以人为本，是软件项目管理的核心。

详细分析了需求变化的根源后，要如何应对这些需求变化呢？且看明天的推送——《如何打造顺畅的开发流程》

感谢大家的阅读，如觉得此文对你有那么一丁点的作用，麻烦动动手指转发或分享至朋友圈。如有不同意见，欢迎后台留言探讨。