作者：韩伟
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
世界500强互联网产品经理管理笔记试读：
前言
中国互联网的发展如火如荼，每年都会诞生无数的财富奇迹，吸引着众多年轻人投身于这个行业。然而从另外一方面看，很多互联网企业，无论大小，在项目开发过程中都遭遇过很多麻烦，长期的高负荷工作，也让很多优秀的开发人员离开原来的岗位。
在国内互联网的早期阶段，项目经理这个岗位的名称，只是代表一个负责某项目的较高级别职员而已。而真正对于软件工程学在项目中的应用，仅仅是那些有兴趣的开发人员的自发行为。对于软件工程知识的无知或忽视，是早期大量项目失败的共同原因。
当今互联网企业的竞争已经进入白热化的时期，创意本身的作用已经变得没有那么重要了，实现创意的开发能力却显得越来越关键。要想在市场中脱颖而出，我们更需要通过提高自身的开发能力和管理水平来取得产品的成功。
然而大部分经典的项目管理著作，都不是在互联网时代的环境下写作的，其所论述的观点虽然都很有智慧，但是其论据却距离手头的工作很远。另外，一些项目管理的书，都是以描述一个完整的工作流程为主要内容的，然而在实践的环境下，我们往往无法依照别人的流程去做。在多次尝试各种不同的项目管理流程后，我终于发现，那些成功的项目，往往并不是依靠某套管理方法取得成功的，而是因为它们拥有非常合理的岗位设置，以及在这些岗位上的人都很称职。这些经验和教训改变了我的思想，我不再试图去寻找那些“一流”的管理流程，而是更实际地去思考开发团队本身。
因人设事是很多组织中的弊病，很多岗位的设立并没有根据实际的开发需求来决定。而另外一个极端是组织松散，几乎完全不对岗位进行区分。在这两种组织当中，无论用任何先进的技术和管理，都几乎不可能做出成功的产品来。“要改变世界，必先改变自己”，一个组织也是一样，要改变工作的结果，必先改变组织自身。任何方法论的实施，都必须有足够支持这种实践的角色才能得以进行。而这正是很多企业所忽视的地方，很多管理者认为只要现在的团队改变做事的流程或者方法，就能应用那些优秀的项目管理方法了，然而最后的结果却是一次次的失败。我并不反对流程、规范、文档、监督这些手段，相反我认为这些都是很好的。只不过我经历了太多架空在实际开发流程之上的“项目管理”，这种管理除了让大家写很多没用的报告和文档之外毫无意义。而那些真正在开发之中，和所做事情的细节相关的文档、流程、规范却往往缺乏得很。我们身边有很多身负管理职责的人，往往习惯性地把“管理”和“开发”割裂开来，试图用一些在开发之外的知识、过程、手段来“管理”开发过程。“学而优则仕”的古老观点还在控制着我们的思想，在这种观点的影响下，我们的管理者越来越脱离开发的实际环境，导致最终瞎指挥和无所作为的管理者充斥着我们的管理层。
如果我们不把项目管理看成一种需要监督的、束缚团队每个成员的流程，而是把项目管理的理论和实践需求拆分到具体的岗位中去，就会发现项目开发有一种神奇的改变：那个板着脸四处巡视的管理者消失了，取而代之的是整个团队的高效协作。互联网软件开发是类似于外科的行业，而不是血汗工厂，所以不需要手持皮鞭的经理，而是需要仁心仁术的“神医”。
纸上得来终觉浅，绝知此事要躬行。感谢那些在项目中折磨过我，以及被我折磨过的人，你们帮助我在实践中学习了知识。2014年1月第一篇陷入泥潭的产品经理作为软件行业的成员，我们常常能见到许多整天忧心忡忡的产品经理。他们日复一日地写着报告，开着会，做着汇报，挨着老板的骂……有些程序员觉得写程序很辛苦，于是去争取产品经理的职位，但真正成为产品经理之后，却发现这种工作只是和写程序截然不同的辛苦，一种似乎无穷无尽的担忧，总萦绕在心头。软件开发的工作，似乎就像一个泥潭，不管你在哪个位置，总能让你“难以自拔”。然而，我还是见过一些资深的产品经理，他们的工作得心应手，他们总结道：会写程序，不等于懂得软件开发工程，要想脱离这个泥潭，必须先了解这个泥潭。第1章焦油坑和变色龙
在不按时算薪的行业里，软件开发应该是加班最多的一个。“码农”，是很多程序员用以自嘲的称谓。长时间的加班、大量的BUG、无穷无尽的特性以及永远都在做的重构，贯穿程序员职业生涯的始终。对比国外的微软、谷歌公司那种轻松愉快的工作，国内程序员的工作真的就如同面朝黄土背朝天的农耕一样艰辛。很多程序员都认为软件开发是一种体力活，“程序员干不到三十岁”的说法也流传甚广。
软件项目一直是一种高风险的项目，除了产品是否畅销的市场风险，还有大量的产品会在开发过程中夭折的风险。
比如软件项目的主要开发团队离职，旧的代码无法由新的开发人员接手，被迫重新开发，会导致资金无法支持。
又比如软件项目中的需求反复修改，客户意见一直不稳定，而合同的金额却早已商定，最后项目只能以撕毁合同告终。
还有软件系统交付后，所谓后续维护的工作量大大高于原先预计，导致最后尾款无法收回。
有些软件系统开发进度总是让人感觉举步维艰，一些关键要素迟迟无法突破，比如在线用户数一高就会导致服务器崩溃，如此种种，数不胜数。
高强度的工作，产出的却是高失败风险的结果，这个矛盾一直困扰着软件开发业。如何避免软件项目失败，整个软件业界都在孜孜以求。要探讨如何解决这个问题，必须先来研究一下造成问题的原因。一、需求持续变化带来的痛苦
我们时常会从《硅谷传奇》之类的传记里面读到，一两个天才程序员，凭借在车库里面的一些天才的开发工作，写出了惊世骇俗的程序，然后迅速成为IT业界的明星。然而现实是大量的软件，都是在类似黑网吧的“软件血汗工厂”里面被开发出来的。难道开发能力真的存在那么大的差别吗？
软件项目管理的书籍汗牛充栋，无数专家学者都在这个领域花费毕生心血。但是软件项目管理也是至今为止进步最缓慢的一门“学科”。假设世界上真的存在一种知识，能复制车库里的神话，那么我相信它现在应该早已传遍全世界了。
为什么神话确实存在，而大量的开发团队却在苦苦挣扎，我们要看一看两者项目之间的差别：
◇“车库”产品的需求提出者是开发者本身，他们一心一意地做自己想要做的东西。“工厂”产品的需求提出者往往不是开发团队，而他们需要满足很多不同方面的需求，有些甚至是互相矛盾或模糊不清的。
◇“车库”产品的开发者人数很少，他们最多的沟通也就是在左脑和右脑之间。“工厂”产品往往涉及大量的不同岗位，从客户代表、市场人员、销售经理、售后工程师到程序员、美工、产品设计、项目经理、老板/投资人、测试人员，等等。
◇“车库”产品的开发者目标很清晰，以自己认为的最好方式，去做自己认可的事情。“工厂”产品的开发者往往很纠结，项目中有一些令他们感兴趣的技术或者创意想要实现，但是这些又不一定能被允许在项目中实施。
其实归根到底，两者最大的区别，还是关于需求的：（1）需求是否明确；（2）需求的沟通是否通畅；（3）开发者自身的需求取舍。二、需求的变化类型
对于需求是否明确，往往需要开发者和需求方反复沟通，有很多时候还需要把程序做出来，然后在使用的过程中反复修改，才能一步步逼近真正的需求真相。做过行业软件的程序员都知道，真正的产品和展现给用户的第一版产品，往往是相去甚远的。大部分非软件行业的客户，对于计算机的“死板”逻辑，以及软件的工作方式，几乎是一无所知的，因此想让他们在纸面上描述出一个程序模样几乎是不可能的。
开发团队往往需要根据自己的猜想（很多时候是幻想）来构造第一个版本的系统，因为开发团队也不具备行业知识，所以做出来的系统和客户的需求之间常常有巨大的差距。然而双方沟通需求的唯一媒介，就是这个看起来一无是处的软件。在经过不断地、天翻地覆地修改之后，软件才慢慢接近需求的彼岸。而在这个过程中，开发团队付出的巨大工作量，在最终版本的软件上却是看不见的。有很多运气不佳的团队，甚至在开发的路上就倒下了。因此说，客户的需求变化，就是开发团队的直接杀手。
[例子]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天，有多人生病，需要请假等，这就让项目本身的进度受到了较大的影响。而这种临时性的需求，在这个项目的运营过程中发生过不止一次。
以上三种关于需求的讨论，最后都指向一个结果，就是增加开发工作量。无怪乎程序员和软件开发团队加班是如此常见。
因此，可以总结出来，软件开发过程中，最核心的矛盾就是—需求变化和开发效率之间的矛盾。三、需求变化带来的问题
这个问题始终贯穿着软件开发的历史，在进入互联网时代之前，需求变化已经是“臭名昭著”了。需求变化可能来自于一个喋喋不休的老板，或者是那些心比天高的用户，又或者是强悍的竞争对手，市场部的兄弟姐妹们也经常充当这个“可恨”的角色。当然，还有一些是开发者给自己挖的坑。而要满足这些需求，开发团队能用的工具显得如此之少，几乎只剩下一个选择，就是加班。不管是做出来的产品不是客户想要的，还是做出来的产品有大量的BUG，又或者是根本就追不上发布计划，总之大多数公司都会下令：做完为止。
需求变化内容也令人难以捉摸，有的是要增加功能，有的是要限制功能，还有的是要求恢复以前的旧功能。从一两个界面的文字修改、按钮大小的调整，到整个功能几乎全部不能用的都有。有时候这种需求还非常紧急，昨天才说半年后可能需要，今天又说明天就要。开发团队对于这些需求变化导致的代码质量下降，往往无可奈何。
需求不断地变化，导致软件迟迟不能交付，加上需求变化似乎飘忽不定，原定架构无论怎样高瞻远瞩都无法涵盖，而对于软件的频繁修改，更是带来了大量的缺陷，这里我们有一个通用的叫法：BUG。
需求的持续变化，带来了更多深层次的问题，最核心的就是开发团队的士气问题。“人心散了，队伍就不好带了”，无止境的需求变化就会带来无止境的BUG，以及无止境的重构甚至推倒重写，然后就是无止境的加班。开发团队人员越来越疲劳，对项目失去信心，得过且过，或者直接跳槽。
如果开发人员跳槽了，就算能找到别人接手，新人面对一大堆别人写的、修修补补的代码，也是一个巨大的挑战，于是项目需要停下来等新程序员掌握旧代码，最终导致越来越多地拖延进度。需求变化就如同一个潘多拉盒子，一旦打开，就会引发后续的连锁反应，直至把项目拖入失败的深渊。大量的软件项目都是死于“做不完”和“赶不及”，而很少是死于“做不出来”。
经典软件项目管理书籍把“需求变化”比喻为焦油坑—很多史前巨兽，如猛犸象、剑齿虎一旦陷进了焦油坑，无论它们如何挣扎，最终都会越陷越深，以致遭受灭顶之灾。这些焦油坑保留到现在，也是这些史前巨兽的化石宝库，可以让现在的人来研究。而那些大量的因为需求变化而失败的项目，也是我们现在用来研究软件项目管理的最好资料。
无论多么强大的软件公司，或者是技术多么高超的程序员，面对软件项目时，经常都会发现自己处于一个项目的焦油坑中：无论是继续增加人手、投入资金还是购买服务，都无法顺利地结束这个已经延迟了很久的项目。只能眼睁睁看着所有人在项目里无望地挣扎。而软件项目管理的知识，就是一种避免开发团队陷入这种“焦油坑”的经验。四、互联网上没有秘密，需求变化从开发者开始爆炸
在互联网兴起之后，软件开发领域突然进入了一种莫名其妙的混乱当中。在这个潮流里，人们分不清谁是用户，谁是开发者，谁是投资人。
开发者可能自己在用自己的服务，比IM软件，开发这个软件的开发人员，本身就在每天使用它，而且还经常把“自己认为应该”加入的功能，加入到开发计划之中。著名的Linux系统，就是为了让使用操作系统的“用户”自己去开发的。因为自己就是用户，因此产品需求中，开发者本身的需求会大大地增加。而且这些源于开发者自身的需求，往往是推动软件产品迅速进化的一个动力。有一些项目开发团队，无法分辨是应该听取那些不完整的用户意见，还是应该遵循自身需求。盲目地投入开发方向，最后导致项目失败的比比皆是。正如苹果的乔布斯所说，用户根本不知道自己要什么。在互联网时代，完全按照订单来开发的模式往往是没有生命力的。
著名的游戏开发公司暴雪公司就认为，开发团队都不喜欢的游戏，注定是失败的游戏。而一些著名的国内游戏开发团队，也因为对于产品有自己的坚持而成功，比如《大话西游》和《梦幻西游》等都强调网游一定要加强玩家的交互。而不像国外的游戏只是把网络特性作为游戏的一个方面。因此它们比国外网游多了很多专用于玩家交互的系统，比如师徒、夫妻、帮会，等等。而《征途》则进一步把一个服务器的玩家组织起来和别的服务器玩家PK。这些需求的来源都是开发者本身，而非传统的制造业的那种订单。
因此互联网产品具备的是更多的创作特性，从这点来看它更像电影拍摄，由开发者提出产品需求，并且在开发者的价值观下进行生产。这种模式对软件项目管理提出了巨大的挑战，因为需求管理不再是针对用户代表，而是要更多地关注开发团队自身。或者说如果开发团队本身提不出有效的需求，产品就会失败。这和传统的“挡、推、闪”应对需求变更的方式，有天壤之别。这要求开发团队顺应需求变化，而不是抵制需求变化。五、为了获取需求而产生了大量需求
用户本身直接购买产品或提供价值给网站，供其继续运作。但是用户并不直接下订单或者谈合同，而是以“用脚投票”的方式来表达自己的需求，这给需求收集带来了非常大的难度。而那些关于“用户沉默离开”、“用户为何要离开”等一系列的疑问的答案，也只能从一些用户的使用行为中探寻。大量的互联网公司，都依赖直接分析用户的使用行为来调整产品的需求定位，因此也对数据统计和数据分析提出了重大挑战。
因为看待问题和寻找问题的方法都不同，行为需求的收集和统计也都需要增加工作量。项目需要先定义哪些行为需要收集，然后开发程序去记录不同用户的使用行为。而程序开发需要把这些用户行为作为流水日志，并按照统计的目标来进行合并和过滤。因为需要统计查找的目标不同，合并和过滤的程序也不同。所以用户数据收集工作本身也包含了大量的需求—发掘的需求。
有的项目一直就被困扰在不停地做数据统计之中，迟迟无法确定应该如何前进。有一款网游加速器产品，为了摸清楚现在网络的整体情况，以便能做出完美的加速方案，进行了长达数年的用户数据收集工作。结果是网络本身的情况在变化，而为这个产品提供数据的用户也日新月异。这个项目就一直在不停地统计数据，而无法真正确定开发的需求。
开发者会和用户在网上无时无刻地沟通，每分钟都可能修改软件，同时也获得反馈；不管是大名鼎鼎的QQ，还是论坛之王DISCUZ、163邮箱，以及几乎所有的网络游戏开发团队，都会设法直接在网上和用户互动，希望获得更多的用户反馈。虽然用户的意见有很多是偏激和片面的，但是也不乏真知灼见和代表性的案例。“沉默的大多数”和“激昂的少数”同时存在，如何汲取这些意见的合理部分，如何发掘背后的需求，成了项目开发的重要课题。有些游戏完全依赖用户的论坛意见，结果渐渐做成了一款小众游戏。而有的产品则一意孤行，以至于被别的竞争对手快速超越。
有一款网络游戏，在每次推出新内容的时候，都会听到大量的玩家骂声。因为新的内容往往提供了新用户超越老玩家的机会，所以在一个已经由老玩家“称王称霸”的社区里面，任何的新内容都会有反对意见。开发团队碰到这些反对意见，因为缺乏处理的经验，往往会惊慌失措地重新修改内容，来保护老玩家的地位，结果这个游戏就因为新玩家流失得越来越快而渐渐冷清了，最后老玩家也陆续离开了游戏。
互联网项目就好像一条变色龙，谁也不知道明天会变成什么样。但是开发者每天都在拼命试图去了解明天可能的模样，并且试图去控制这种变化。而这些努力，又必然导致比以往更多的开发工作。六、软件成为开发工具而产生的需求
互联网上产品的功能和内容允许用户自己利用一些工具开发。著名的网络游戏《魔兽世界》，就有大量的用户利用其插件脚本工具编写自己的界面，并且发布到网上供别的玩家使用。而社区型游戏《梦幻西游》，也因为玩家的互动而产生了大量的社区活动。更不要说微博、相册这类互联网应用，它们本身就是用户直接共享信息的平台。而大部分的现代网络社交产品，追溯至FaceBook，都会提供开发者API，让用户自己在上面开发应用。谷歌的API则已经成为互联网上的开发经典库之一，而FaceBook已经拥有成千上万的用户应用程序。另外一个叫虚拟人生的产品，则直接提供了一整套3D建模工具给用户，让用户直接构造出虚拟世界。有的公司甚至靠在这个虚拟世界中以卖虚拟产品为生。
在这类产品形态中，开发者和使用者往往混淆起来了，原本被认为并不重要的“开发者”自己的需求，反而变成了重要的产品需求。而“用户开发者”的加入，为产品带来了巨大的不确定性。这些产品新的变种部分，可能增强或者危害产品本身。因此从后台浮现出更多的实时监控、安全加密、架构设计需求到前台，使得项目的开发需求正在被颠覆。
从另外一个层面上说，因为互联网产品需要持续地更新和开发，一套完善的产品工具库，包含了诸多经过实践提炼的需求实现，这些需求实现都是非常有价值的。那些能把自己的产品做成开发工具的项目，往往都具有极大的灵活性。在游戏开发范畴，这一类工具被称为引擎，最著名的引擎就是FPS类游戏“QUAKE”的引擎，还有3D游戏的BigWorld和Unreal等引擎都被广泛销售和使用。在网游的童年时代，那些称为MUD的文字网游，则几乎都是由一套叫做MudOS的代码驱动，在其上层配上不同的GameLib程序，从而形成完全不同的游戏。而这套MudOS和基础GameLib，居然具备了在线文件管理和文件编辑及编译的整套功能，于是无数个MUD游戏诞生了。
这些应用软件的特定开发工具，能让互联网软件产品变得更加丰富。为了获得这种强大的开发能力，我们对于软件的需求就不仅仅是用户的使用需求，还有另外一个重要需求，就是要满足开发者用来进一步开发这些软件本身的需要。七、软件成为水和电后产生的非功能需求
全世界用户每天都在使用互联网软件，开发者也不再是把软件塞入盒子交给用户就了事了。他们必须7天×24小时不间断地为用户提供服务。互联网软件的运行往往依赖成千上万台机房里工作的服务器群，这些服务器就如同发电厂的发电机或者自来水厂的水泵一样，要求有高度的可用性管理。面对随时变化的使用量，服务器集群要能随时接受海量用户的冲击。这些都要求开发者将运维管理和监控的需求放到非常重要的地位。如果这些服务器的管理需求和功能需求混合到一起，却没有好的软件技术支持，那么开发将是一场噩梦。在我们为软件添加各种各样功能的同时，我们往往会忽略那些对应的性能需求以及管理需求。这种不完善的功能一旦上线，经常会导致服务器集群的大量故障，从而出现严重的运营事故，这种事故会造成大量的用户价值的损失。这对提供服务的公司来说，是非常致命的。
大家一定感受过在大年三十的晚上成功发送短信的概率比平时低，因为那天发短信的用户要比平时多很多。而在“9·11”当天，很多新闻网站也被潮水般的网络访问者冲垮，原因也是用户访问量是平时的10多倍，从而导致网站服务器发生雪崩式的故障：过多同时涌入的访问者堵死了新闻数据库，然后导致了那些依赖数据的“缓冲数据”服务器的故障，最后那些提供页面显示的服务器被迫滞留大量网络连接，网站最终陷入整体瘫痪。
一个良好的互联网软件，现在普遍需要满足高可用、低延迟、容灾热备、负载均衡等互联网特性。而要满足这些特性，就需要额外地增加导航目录服务、接入服务、状态监控和自动切换服务等。这些服务都隐藏在用户单击链接之后，默默无闻地提供高稳定性的软件运行。像提供服务器集群管理的LVS、作为高速Web缓冲的反向代理软件Squid还有用来提高数据库性能的SQL proxy等著名软件，可能每个上网者都用到过，但是知道的却不多。
这些复杂而精巧的软件，都是互联网软件特定的需求。八、互联网产生的新型商业模式导致的需求
在互联网上，越来越多的用户只为软件提供短期付费，也就是说，他们随时可能离开。开发者无法通过以往的销售手段，打包完整的产品卖给用户，因此，这对开发者的盈利能力来说，是一个非常重大的挑战。吵吵嚷嚷的用户论坛里面，笑脸共骂声一色，板砖与鲜花齐飞，让人难以鉴别哪些是真正有利润价值的需求。软件开发者往往顾得哥情失嫂意，新功能上线一天就倒退回到旧版本的事情司空见惯。互联网项目就这样在不断地折腾中运营。很多公司因为无法承受这种折腾，最后只好关门大吉。
最典型的例子就是网络游戏，游戏运营团队都知道，公测之后的收费是一个巨大的坎，原因是很多游戏公测时宾客盈门，一旦收费用户就大量离开。成功破解这个难题的产品就是一款收费游戏—《征途》，这款游戏利用富有争议性的道具收费，让玩家延迟支付，并且一点点地收取费用。从此国内网游几乎都走向了这种道具收费的模式。然而，这种收费模式必须比进门就收费的模式承担更多的用户在线资源消耗，要维持大量的免费用户群体，必须付出额外的开发量，而这些开发量的回报，则又需要一些额外的系统来向那些真正的消费群体收费。
互联网奇特的商业模式，让软件开发从“卖功能”转向“留用户，然后收费”的先吃后买模式。除此之外，互联网行业还有大量更加特别的商业模式，比如卖流量、卖排位、卖数据、用户间交易收费，等等。这些商业模式的不断探索，也导致增加了大量的开发工作。九、互联网残酷的竞争产生了新的需求
在互联网上，一个公司经过大量用户数据的收集，然后花费大量精力在数据分析中，找出市场机会，最后经过长时间艰苦的开发，终于让新功能成功发布，但是就在这个新功能发布的同一天，他所有的竞争对手就能看到，并且可能已经开始分析和仿制，这些“抄袭者”只需要解决“如何把东西做出来”的问题就可以了。所有的公司都在追求拥有最多、最新潮的功能，也追求最稳定的质量。开发团队不是在和一个竞争对手做生死较量，同时也在应付全世界的竞争对手。
我国的知识产权环境较差，创意更加“不值钱”，只有最快、最稳定地把创意做出来，才有价值，而且要一直都做得最快。因为互联网行业往往是残酷的赢家通吃结局，用户会全部聚集到名列前茅的公司产品下。
我国著名的互联网公司腾讯，就曾以学习竞争对手而闻名。不管是亲密战友金山，还是死对头奇虎360，它都“从善如流”，拿来就做。就连互联网时代的病毒，都以一日三更新的速度在发展，著名的熊猫烧香，就是因为作者的“勤奋”而让诸多杀毒软件措手不及。
开发团队在激烈的竞争压力下，都会争相采用最新的技术，并且夜以继日地开发。加上软件通过互联网发布几乎是瞬间的，软件开发再无版本之间的“喘息”机会。如何能让开发团队保持较高的开发效率，几乎是每个项目经理都在冥思苦想的问题，除非他并没意识到需要用提高开发效率来解决加班的问题。十、不变的只有变化
需求变化最根本的来源是人对于世界的认识规律。人类必须通过实践才能认识世界；同样，软件本身也必须通过使用和开发的实践，才能认识清楚其需求。因为软件的需求往往就是人对世界的认识。1．软件业正致力于应对需求变化
只有软件被生产并应用起来，人才能真正地对其有正确的认识，基于这些认识，软件中的设计错误才有可能被改正。这个过程循环不止，软件项目本身如果跟不上这个节奏，就可能惨败。如何能以最低成本进行这个循环，减少每次修改造成的浪费，是应对这种反复修改的重要手段。
在人类真正清晰、完整地认识世界之前，需求变化都是不会停止的。所以我们要做的不是去拒绝变化，而是把需求变化看成软件开发中最重要的一环。软件业发展至今，业界已经在软件工程学上取得了很多突破，我们应该去学会使用这些知识，去更好地控制需求变化，让需求变化为软件项目服务，而不是阻碍项目的发展。
需求变化所导致的问题，往往不是狭义的软件开发技术能解决的。于是软件业先辈们苦苦思索解决之道，软件项目管理、软件需求管理、软件开发管理等学科就萌芽了。结构化编程、面向对象分析方法、瀑布式开发模式、敏捷开发模式、持续集成、ITIL等软件管理知识不断被提出并整理出来。
另外，在软件开发语言、开发工具等方面，也有大量为了解决软件开发危机而出现的新技术、新语言。从汇编到C语言，然后到基于虚拟机的Java，再到现在诸多的脚本语言LUA、PYTHON、JS、PHP、RUBY，善于解决并发问题的过程化语言Erlang、Haskell、Scheme，等等，无一不在提高软件开发者的工作效率。开发工具从传统的GCC、Vi、Make到现在的IDE集成环境，再到插件式的IDE—Eclipse平台，都有着长足的进步。而设计模式、架构模式更是在不断地总结各种新环境下解决开发问题的经验。
现在的软件开发，已经从以往的对硬件性能的控制，全面转向以提高软件开发效率这方面。我把这些知识统称为软件工程知识。2．提高开发效率是根本方法
所有的软件工程知识，最后都是为了达到一个根本目标—提高软件的开发效率。因为只有提高开发效率，才能真正从本质上解决软件项目管理的难题。
开发效率的提升，会让项目进度加快，同样会降低开发工作的强度，进而降低BUG的出现概率。
开发效率提高之后，软件不仅能更快地发布，而且还能更快地获得用户反馈进而能尽快修正开发方向。
同样更高的开发效率能在市场上保持强大的竞争力，不再怕对手的抄袭，因为就算抄也来不及。
开发效率提高还能省出更多的开发人员和资源，用来提高项目的安全性、稳定性、运行性等非功能目标，让软件在另外一个层面产生竞争优势。
然而，提高软件开发效率绝非易事，因为软件开发到现在为止，最主要的“瓶颈”还是开发者本身。至今还没有哪种机器能做到“让一行行的软件代码和数据快速而高质量地生产出来”。而且更要命的是，没有一种作品像软件那样苛刻。比如说，一篇文章有个别用词不当，不会导致文章不可读；图画有一两处败笔还能算一幅图画；音乐演奏的一点点失误也尚可忍受。而软件则要求人类百分之百地去实现逻辑，这种劳动的压力远远大于一般的脑力劳动。
要解决最常见的软件项目的开发难题—需求变更，提高开发效率是根本之道，而开发效率地根本所在是人。只有让人去掌握诸多软件知识，让人去关注开发效率，才能真正地应对需求变更。
以人为本，是软件项目管理的核心。第2章创业容易守业难
对于软件开发这项工作的认知观念，决定了不同的软件开发理念。正确的理念会帮助我们处理需求变更，错误的理念则会让软件开发陷入泥潭。只是写好一个软件、让它运行起来很简单，但是要让这个软件能持续地服务于现实生活，却远没那么容易。一、软件是产品还是服务？软件的形态在不断变更
软件的核心到底是产品还是服务，这在20世纪还能算是一个问题。但是进入21世纪以来，几乎没有人再争论这个问题了，不是因为不存在争论的余地，而是大家已经觉得没有争论的必要了，因为软件的服务特性随着技术的发展变得越来越明显了。只有真正地理解了软件的本质，才能有效地对软件开发进行管理。
软件的发布方式，最早是通过硬盘和软盘互相复制，当时微软的DOS就是因为有方便复制的软件而流行起来的。DOS本身就是“磁盘操作系统”的缩写。在CD-ROM发明之后，软件的发布开始加速，有10年时间，国内电脑城的盗版光盘出售摊位都保持着热热闹闹的状态。在这种状况之下，软件很容易被看成一种产品。因为软件被打包成一个个实体的物品，然后通过购买实体，再回去安装使用。在企业软件方面，开发者也是生产出一个个版本的软件，然后复制到客户的电脑上安装。如果有客户需求的变化，则需要记录下来，回去之后重新修改和编译，完成后再拿回客户的电脑上安装，看起来就像是从工厂里运来产品设备，到客户的厂房里安装一样。那个时候软件的更新速度也非常慢，这从版本号上就能看出来，比如1.0、2.0、3.3等。因为软件的复制成本很低，所以不多的几个软件公司，都从这种模式中，既赚到了超额的利润，也被固化了思想：软件就是一种很有利润空间的产品。
然而就在互联网开始兴起的时候，一种叫做Web的技术进入开发者的视野。这种客户端软件仅仅依靠浏览器，就能进行一些有限度操作和沟通，直接取消了到客户电脑上的复制、安装的过程。程序的修改也可以立刻从服务器传输到客户面前。以前的企业应用软件修改完功能，往往需要软件开发人员跑到那些运行这个软件的电脑面前，重新安装一次这个软件。而这种基于浏览器的软件，则只需在企业内部的服务器上重新安装该软件就可以了，这是一种巨大的进步。于是企业开发者开始说服客户接受这种通过互联网提供的软件，并让客户逐渐认识软件在快速发布的部署上所带来的真实好处，因此，需求变化就能很快地被呈现于开发人员面前。
在普通用户软件层面，互联网上出现了一个伟大的发明：Webmail。这种仅仅需要打开浏览器，就能收电子邮件的“程序”，让无数的网民开始真正地使用互联网，而不是仅仅打开网页无所事事地浏览。著名互联网公司网易就是这种Webmail的最优秀代表。用户第一次不需要从光盘或者软盘复制软件安装，而是直接通过互联网来使用“软件”。虽然很多人并不认为这是软件，而认为这就是一个“网站的功能”。然而，越来越多的网站开始提供可交互的服务，实质上，在服务器上运行的就是一个个以HTML作为界面输出的软件。到现在，几乎所有和网络有关的软件类型，都可以在Web上面使用。这类软件的发展历程，可以大概列举一下：（1）CGI+HTML技术：实际上CGI只是一个标准，主要功能是让Web服务器使用一个特定的程序，来处理用户发来的特定数据。利用HTML仅有的几个输入型控件，如文本框、选择框、按钮来产生一个“表单”，这些输入数据传给Web服务器后再由特定CGI程序处理，结果则以HTML代码的格式发回给浏览器。浏览器安装的HTML设计、绘制出整个软件客户端的界面，包括图标、文本、按钮等。尽管CGI+HTML技术看起来似乎是一种原始的拼凑，用户体验也难以得到很大的提升，但是这不仅可以让用户以一种标准软件代替特定软件来实现一些功能，而且还是部署在服务器，更新维护非常方便的一种功能。（2）AJAX技术：由于CGI技术在表现上的局限性，客户端浏览器都开始支持JS语言的解释。这种从网上下载源代码，且在浏览器执行的语言，赋予了开发者提供动态的完整功能的可能性。有些开发者用JS开发过《星际争霸》这种大型游戏。而AJAX则是JS语言在应用软件领域的一次革新，因为它使得浏览器的程序不再是简单的页面型的HTML，而是作为一个可以完整体验的客户端软件存在。而对于服务器端，在CGI之后，诞生了FastCGI、PHP、JSP/Servlet、ASP等多种专门为了编写Web应用的语言和技术。这些技术除了提供更快捷简单的语言特性外，还在Web的应用模型下提高了处理能力。在客户端和服务端的共同发展下，我们有了现在的Web邮箱、微博、博客、相册等多种多样的互联网应用软件。就连一直以本地代码程序运行的QQ，也有了纯Web版本。而传统的应用程序，比如Outlook等都纷纷增加了Web方式的程序，甚至现在大部分的路由器都提供了Web模式的管理界面。（3）Java Applet：虽然可以说是一种“失败”或者“过时”的技术，但是它尝试在浏览器上建立一个虚拟机，直接下载后来运行编译过的代码，而不是像JS那样下载源代码来解释。Java语言竖起了“跨平台”的运行大旗。在Web技术突破软件发布在电脑之间的物理障碍之后，虚拟机技术进一步试图突破一款软件只能在特定操作系统上运行的障碍，以前在Windows上编写的程序就不能在Linux系统上运行，而虚拟机技术则提供了一款软件能在所有操作系统上运行的能力。之后，Java Web Start技术更是提供了一种自动下载—安装—更新—播放的完整部署流程。（4）Flash：这个技术原本只是一种矢量动画的播放技术，开发者希望能在浏览器上播放更多的动画格式，后来渐渐加入了一些脚本功能，可以由用户参与动画的播放，最后沿着Java虚拟机的路子，把动画格式SWF彻底地变成了一种跨平台虚拟机的运行文件。开发语言ActionScript也从以控制动画为主，最后发展成一门真正的专业编程语言。这种技术直接开启了席卷全国的页游市场，也同时让视频网站得以流行，让开发者第一次有了一种真正可以完全通过互联网来部署和运行的技术。微软的SilverLight也试图实现一个这类的技术，但是因为没有赶上互联网矢量动画的机会窗口，装机量一直不高。Unitiy3D则试图瞄准3D页游这个风头，来推广自己的技术。（5）HTML5：这是最新一代HTML标准，它已经不再是那种单纯地用于表现的标记语言，而是一门功能完整的客户端技术标准。在Flash和Unity3D、Java Applet等以浏览器插件为基础的虚拟机Web技术体系的另外一条路上，下载源代码解释执行的JS也在飞速发展，其中，HTML5就是一个里程碑。HTML不再是描述一个页面的标记语言，而开始成为一门有浏览器本身内置支持，可以运行任何逻辑的编程语言。比虚拟机技术更有优势的是，这种内置支持可以调用浏览器本身的诸多功能，如增加书签、新开页面等。在手机上，由于大部分的智能手机浏览器都支持HTML5，开发者可以很方便地把基于后台Web应用的程序，移植到手机上—所有的服务端程序功能都不需要修改，只需要修改显示界面部分而已。
在Web技术如火如荼的背后，我们能看到，软件已经通过一个个“包”来提供售卖，就像自来水厂给居民提供自来水一样，通过互联网来提供给用户使用，而用户也认为软件本身和网站提供的服务是密不可分的。开发者因为有了可以持续提供产品的技术，渐渐让产品的特性转向了服务的特性。软件从时间上和空间上，都渐渐变成了一种技术服务，而不是固定的功能承诺。
现在把所有软件都称为服务还为时尚早，但是“网络就是计算机”的提法很多年前就响彻IT行业。不管你是否愿意接受，软件开发正在渐渐成为一种在时间上有持续性、在用户空间上不受限制的工作。这种特性，正是软件开发从产品走向服务的一种征兆。
大量的软件都通过互联网渠道分发，最新的软件随时可以通过网络下载；而盒装软件现在是作为收藏品存在，很多Linux操作系统的发行版本里，直接就可以通过互联网安装和更新最新软件。现在流行的“云”概念更加把软件隐藏到互联网的背后，使其更彻底地成为一种“服务”。二、软件的存在环境在持续变更
有些人认为，软件一旦写完，就可以完成一定的功能，只要需求不变化，软件就可以如同一个物品一样，万世如一地使用下去。这个观点理论上是对的，但是事实上，人类本身是在快速发展的，旧的需求可能已经被满足，但是立刻就会诞生新的需求，只有新的需求才能产生新的利润。这些不断涌现的新需求，也正是源源不断的利润来源，以及软件技术本身进步的最大推动力。
[例子]在图形用户界面GUI诞生之前，命令行界面曾经统治着计算机很多年。对于那些专业的计算机使用者来说，图形界面几乎是无用的，因为这些东西只会延迟他们的输入，同时也会消耗大量的计算机资源。但是在计算机开始普及到各行各业之后，对于其使用的便捷性产生了新的需求，人们不想依靠厚厚的命令手册去操控计算机，而希望有更友好的使用界面。例如，施乐公司为了让用户更好地使用复印机，发明了GUI，从此之后计算机界面开始从命令行进化到图形界面。大量的软件都以图形方式提供使用界面，从此，鼠标代替键盘成为用户最主要的输入设备。而现在流行的触摸屏，也有望成为代替鼠标的一种新输入设备，支持触摸操作的软件，将可能带来一场新的软件革命。
[例子]电子表格曾经是计算机最广泛的应用之一。早期的电子表格，需要在文本中由用户手动输入各种画表线的控制符（如曾经很流行的CCED），虽然这种做法也能完成工作，但是极其容易出错，而且对格式调整很费时间，因为只有在执行了“打印”之后，人们才能看到效果。用户在使用了电子表格之后，自然地就出现了希望“所见即所得”的需求。因此现代的电子表格软件，如Lotus 1-2-3和微软的Excel，都是现在这种直接显示一张大的空白表格的软件形态。
[例子]163邮箱在上线之初，只是一个希望能让用户避免设置复杂的邮箱参数（你知道SMTP服务器和POP3服务器的含义吗？邮箱地址和服务器用户名有什么关系？），同时不需要去安装邮箱客户端软件而提供的服务。发展到今天，网页邮箱本身已经成为一个用户的信息中心，因为用户有大量的联系人、来往附件文件（中国人普遍用邮箱作为文件传输的主要渠道）、商务工作邮件都在邮箱系统上面保存。于是，邮箱增加了联系人管理、附件管理、在线文件预览、日程提示等额外的功能。在“邮箱应用”栏目上，添加了数十款不同功能的相关选项：记事本、电子名片、火车票查询、贺卡……
计算机技术本身也在快速发展，软件的运行环境同样日新月异，昨天还在计算机上运行的程序，今天就可以在手机上运行。触摸屏以前还是新鲜玩意，现在的操作系统都要以它为基础。
[例子]最早的DOS应用程序只能使用640KB内存，很多软件为了提供更多的计算能力，必须自己开发保护模式的程序代码。而且DOS也没有驱动硬件的能力，那个时候几乎所有的游戏本身都带声卡、显卡、鼠标等驱动程序。在进入Windows时代之后，操作系统统一了驱动程序层，甚至提供了DirectX这种统一接口，软件不再需要自己去操控硬件，而是转向更多地使用操作系统的功能，在内存的使用上也不再受到限制，同时还能进行多进程、多线程的并发编程。操作系统的进化，本身就促使软件开发必须不断更新，追上新的技术潮流。
[例子]古老的Nokia手机，都会附带一个叫贪食蛇的游戏，因为当时的手机只能运行这么简单的程序。而后来随着硬件的发展，Nokia手机发布了Symbian操作系统，开始有更多的应用程序在手机上运行。随后J2ME平台的流行，让大量Java程序员可以为手机写程序，现在还有大量的手机在运行Java程序。时至今日，Android和iOS瓜分高端智能手机市场，那些曾经的手机应用，又要以新的平台和技术改弦更张。然而新的硬件和软件平台，带来的是更好的使用体验。
软件如同一个生命体，它本身的形态在不断变化，而它所在的环境，如硬件、市场、基础技术，也在因为软件本身的变化而不断变化。如谷歌搜索引擎诞生于变革中的互联网，同样互联网行业也被谷歌这类搜索引擎所改变，过去的门户网站风光不再，用户的信息来源更多地来自于搜索而非推送。互联网信息从统一发布，渐渐走向个体发布趋势。
开发出一个软件并非难事，困难的是如何让用户陪着软件一直进化下去。
然而，软件开发不仅是一个持续变化的行业，也是一个商机无限的行业。正因为有无穷无尽的需求等待满足，才有无穷无尽的创新机会。放下“软件是产品”这种陈旧观念，把软件开发看成服务，提供持续的客户价值，才能发现软件业广阔的前景。
需求变化既是软件开发的世纪难题，也是软件业的活力源泉。只要我们把危机看成动力，利用项目管理的知识，就能让软件以服务的形态来产生无穷的利润。三、兵是流水的，营盘是铁打的吗
一般的软件项目，两年至少会换一遍核心开发人员。软件开发的特点就是会不断更换开发者。
这个时间限度，是一个大体的统计值。在某些大公司，可能会长于两年的时间，但是在大多数的小型公司，普遍都是一年左右就会换一批核心开发人员。因为大部分程序员都持“做一年看看有没有发展”这种想法。实际上对于一个项目来说，一年时间是很少的，因为需求变化如此之多，在反复折腾之中，一年能产生的效益极其有限。如果公司本身没有别的可以留住人才的措施，那么大多数人都愿意去换个地方试一下运气。而每换一次开发人员，基本上都需要两个月时间来交接，算下来很多公司的每年有效开发时间，就只剩下十个月。
在各种项目问题中，最让人头疼的莫过于人员流动。软件代码的交接难度之巨大，往往会让人宁愿自己重写一遍，也不愿意去解读别人的代码。况且有的时候代码量巨大，接手的程序员也没有时间去研究和解读。软件项目和一般的工程产品相比有很大的不同，最关键的生产要素是开发人员，而不是资金或者设备。
[例子]我曾经接手过N公司的一个《网上同学录》的产品。这个产品从用户角度来看，是个非常不错的产品。功能齐全，界面美观。本来这个产品并非是我参与开发的，但是因为产品上线之后，不时地会中断服务，让服务器重启。一直找不到这个故障的原因，所以就指定由我来解决。我打开这个程序的源代码看了一下，猛然有一种天旋地转的感觉，因为这个产品的代码结构，基本上可以用无结构来形容，所有的功能、界面都堆放在一个个的页面文件上，几乎没有什么重用的模块可言。于是我只能通过全文查找那些可能导致服务器进程重启的语句。老天保佑，我很快就找到了原因，尽管我解决了这个问题，但是我还是没有信心去改善它的代码结构。要读懂这些代码需要花大量的时间和精力。这个产品就这样经历过一个又一个程序员的手，都没有办法去改善了，最后终于因为有些BUG太难找，而被公司放弃了。
找到一个有能力，且有毅力的程序员来继承项目的开发，往往是可遇不可求的。很多公司都希望留住原有程序员，这也导致了很多问题，要不就是工资越调越高，但他实际上没有生产更多的价值，于是就产生了一批靠吃老本过活的老油条；要不就是阻碍员工的升职，压抑员工的发展。所以程序员总是很容易跳槽，这样也就没办法提高继承项目的工作效率。靠阻止人员流动是不可能解决项目交接问题的。
[例子]小F是N公司的老员工，之所以称之为“老”，是因为他从一进公司，就负责公司的短信平台工作，而且这一干就是五年。从短信平台的第一次建立，到中间的历次重写和重构，他都参与了。因为他主要是负责短信接口协议的底层实现，这个代码相对难以理解，要先学习通信协议本身，因此各公司领导就觉得最好还是由一个人来处理比较好。而对于底层关键性的代码，应该保持尽量稳定。加上小F又是一个谨慎踏实的人，所以接了这个活之后，他就没挪过窝。对于小F自己来说，他一直认为自己都是在做机械的事情，导致技术和职位都没有上升的空间，所以非常压抑。虽然他也知道他在负责公司的重要项目，但是人无远虑必有近忧，这种对于未来的担忧，如果没有得到好的解除，就会使压抑增加积累。最后，小F在没有任何“挫折”的情况下，毅然辞职，甚至离开了程序员这个行业。
软件项目之所以难以接手，一个重要原因是：代码是人思维的产物，同时代码又是由计算机负责运行的。任何一个程序员都会写出计算机能读懂的代码，但只有好的程序员才会写出人能读懂的代码。计算机程序语言并非人类的任何一种自然语言，所以难以理解，而且人的思维多变，要从代码中理解思路同样非常困难。
现代计算机语言都起源于计算机的指令码，一般来说，CPU指令码由一个动词指令和多个宾语指令构成，即“动词—宾语一—宾语二”这种结构。由此发展而来的计算机语言，基本上都是类似这种结构，而数学中的表达式和函数则是最直接可以借用的概念。计算机语言的语句，大部分都是以函数作为主体代码，配以分支选择、循环而构成的。除了加减乘除等数学运算以外，大部分程序代码的“谓语”，都是由程序员自定义的“函数”，这些函数的名字五花八门，都是完全取决于写代码的人的想法。虽然到了面向对象编程的时代，函数开始有了一个定语—描述这个函数是属于哪一个“对象”的，但是距离完整的人类语言却还很远。另外，程序中的数据，一般都以数据结构和变量来表达，然而数据结构本身并不具有天然的语义，比如两个连续的整数，可以视为一组X、Y坐标系下表示的位置，也可以看成是游戏中的生命力。数据结构名和类名，同样是由程序员“随心所欲”来创造的，变量的名字就更容易被“随便”定义。因此总结来说，计算机语言和人类语言的差别有以下几点：（1）编程语言通常没有主语，只有谓语和宾语，而且宾语可能很多。我就碰到过有些函数定义了十几个参数，要搞明白这个函数到底要做什么还真是一件难事。（2）编程语言采用数学符号来表示谓语，而不是常用的词汇组合。函数名则由程序员自己定义。这就好像有一门语言，里面的动词词汇都是由不同的人发明一样，想要理解用这种语言写的文章，显然犹如读天书。我见过完全用汉语拼音作为函数名来编写的程序，因为汉语本身是多音字，有些函数名真的让人不知道是什么意思。而且汉语本身的组合并不严谨，像duqu（读取）和duchu（读出）就很容易混淆。而且还有大量的汉语发音受方言影响，会导致有很多拼写错误，经典的就是z、c、s和zh、ch、sh。而英语一般词汇比较单一，且这些字母都是大家用得比较多的，所以比较适合来用于编程。（3）编程语言采用数字和程序员自己定义的名字来表达名词，如变量、结构名、类名等。同样，要学会一门其名词词汇可以随便乱定的语言，显然是极度困难的。我时常会在一些代码里面发现像aaa这种特别随便定义的变量名，我想，不出一个星期的时间，作者自身也会忘记它的含义。
试读结束[说明：试读内容隐藏了图片]