二、需求的变化类型

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

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

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

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

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

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

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

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

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

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

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

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