背景：由于计算机的普及、软件的广泛使用，公众对于软件项目是个啥东西都有一个概念上的认识。很多人对于公司哪些地方将要应用一套软件系统，已经能够提出一定的想法。然而，在从想法到软件落地应用的过程中，软件项目要经历若干艰苦的变化，才能逐步将之前的理想转变为现实。作为工作多年的人，有必要在这个信息共享时代和大家分享一些这方面的感悟和经验。
项目期初，一般而言，总会有那么一个或者几个人，对公司某方面的业务或者市场潜在产品需求产生想法，认为可以通过软件来构建业务信息系统或者是新一代产品，这样将给公司带来可观的收益。这一期间，称之为项目理想主义期。考虑这个软件的人，看到的往往都是软件利好的一面，大脑皮层围绕软件项目给公司及市场带来可观的利益。项目理想主义期推动了公司高层指派一位重要人士全权负责论证项目的背景、可行性、范围、风险、成本、时间、商业价值等等一系列项目特征性质的问题。而这位重要人士，在项目后续发展过程中，我们一般将会认识到他很可能就是项目经理。
至此为止，项目的萌芽已经在少数人当中孕育。项目经理着手收集高层次的项目想法、目标。在国内，政策性影响往往比其他的项目影响因素所占的比重要比国外的市场化标准占比要大得多。比如说，领导想上一套旅客跟踪服务系统，项目经理在收集论证可行性方面就显得毫无意义，不管客观方面可不可行，最终的结论总是可行，并且很容易实现。再比如，领导指示必须自主研发，而项目经理的论证结论肯定是可行。诚然的说，有了高层次的想法和目标，下属们才有工作的方向和动力，只不过，在项目建设这个客观事实的基础上，没充分客观考虑到方方面面的可行性，项目建设后期将花大量的精力来弥补前期工作欠缺考虑所带来的大量问题。
你作为一个合格的项目经理，要了解到项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况。
1. 准确了解项目目标。这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。在国内很多客户都很不成熟的情况下，千万不要根据项目的名称望文生义地去想象项目的目标。一个名为“办公自动化”的项目很有可能在进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统系统。前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就越小。2010年，接客户建设需要，将要建立一套停车场抬杠系统，而在深入了解客户需求时，发现是要建立一套停车场旅客引导服务系统，内容将要包括停车场抬杠系统、航显子系统、广播子系统、短信服务平台，这样直接导致项目建设成本大大增加，项目周期拉长。
2. 收集项目干系人。这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来，如项目监理公司、业主的行业主管机构等。项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望，可以让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为项目经理是一定要记住的。2010年，遇到过一个项目，本来项目所要建设的系统是客户的核心业务系统，前期已经规划出来要做好部门经理、公司经理级别的需求调研计划，而结果是从来就没办法去接触过对方的数个部门经理，更别说公司领导层面了。这样的后果之一将导致了后续项目出现的业务分歧不知道找谁来核定。
3. 了解各方支持的程度。基本了解了客户的情况后，下面的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视，这个决定了你在需要资源的时候，公司是否会根据你的要求提供最有力的支持。领导口头肯定是说支持的，你需要做的是了解公司对这个项目的实际期望，是想把项目越做越大还是想赚钱？是想做样板工程还是干脆想敷衍了事，公司领导对项目的态度决定了项目经理做这个项目的战略，而这个战略方针将对PM做项目计划产生直接的影响。作为PM，头疼的事情之一是领导口头支持，但公司各级人员不太配合：人员调动不了、公司资源缺乏而采购部门又拖延项目采购、公司在此项目的投入大大低于项目经理的预期。
4. 掂量自己的实力。有了各方积极的配合，至少项目在建设过程中将少一份外部空虚的压力。而在做整体项目计划前，还要大致计算一下你手上的资源。首先是时间，现在市场竞争激烈，往往很多项目要求在几乎不可能的时间范围里完成。对于这一点，你在做项目的风险控制计划的时候要充分考虑。其次是人员，根据项目预算和已往经验，大致计算一下未来的项目小组有多少种角色，每个角色目前公司是否有人，是否能完全归这个项目使用，是否需要另外招聘一些人员，招聘的准备工作要尽早启动。最后就是一些设备的准备，项目所需大件关键设备要尽早预定，以后不管发生设备等人还是人等设备的情况，浪费的都是你的时间。2010年所做的一个项目，由于有部分模块采购外部资源，在主要模块建设完成后，我们启动了子模块的采购工作，严重拖后了项目的进度。并且项目子模块的接口设计工作理应该在项目总体设计期间就定义好，以促成项目的并行工作，节约项目研发的时间。
5. 重视项目说明书。现在是做项目说明书的时候了。一份好的项目说明书不仅将要做的事情描述得很清楚（主要是讲做什么，而不是说怎么做），而且把如何检查也说明得很透彻。也就是说它不仅说明白了要做哪些事情，也让客户的业务人员（一般不懂技术）知道项目做成什么样就算完成了。简单地说，项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。很多人觉得，项目方案就是项目说明书。我只能这样说，项目方案前面章节描述的是项目说明书的内容，但项目方案还包括了项目将怎么做。而这里的项目说明书，将是甲乙双方理解项目各项内容指标的基础。在此之后的项目阶段交付物和项目验收，视此为重要参考。并且，项目说明书将是甲乙双方在项目公允价值上的共识依据。另外，很多客户在提出项目需求时候，都想建立企业的项目数据规范，作为项目经理，应该了解到，数据规范和项目建设是两种类型的事情，在项目说明书中，我们不能将数据规范的大量工作添加到项目范围中，这样会增加项目建设难度。
6. 分析项目机会和风险。是到做总体计划的时间了吗？不，你现在已经知道了客户的目标和你手上的资源，那么做计划以前，你还需要和你的经理和客户充分沟通资源的问题。因为很多资源是还不明确的，你需要写一份报告，详细分析这个项目的风险以及对资源的需求情况。如果一些问题不能得到解决的话，将发生什么样的后果。如果资源不够，就要高层改变策略，增加对这个项目的投入。甚至在条件许可的情况下，有些公司会放弃这个项目。总之，没有人能完成一个不可能完成的任务，如果项目经理不能尽早发现风险，那么就只能去当烈士了。
7. 挑选符合项目需要的团队成员。明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略，现在是成立项目小组的时候了。很多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难有什么具体要求，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配备行业专家（Industry expert），这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。在企业里面，有一部分技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。其实，明白自己想做什么的客户已经是很好的客户了，不知道自己要做什么，更不懂怎么做还要指手画脚的客户到处存在。但是要明白一点，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧，客户的指责和议论是应该的。作为项目经理，要积极主动和气的挑选符合项目需要的团队成员。
8. 重视项目沟通管理。现在你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备这些事情将是你的主要工作。既然沟通这么重要，那些事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则都是潜规则，如果你在一个部门时间做长了，对这些规则的运用觉得是一件理所应当的事情，但是，你现在面对的是多个部门甚至多个单位，不把沟通规则说清楚，你以后就会吃亏。下面的东西看起来无聊，其实还是很管用的：第一个是规定信息的流动方式和介质，是推还是拉。推的意思就是项目经理将主动发布信息，不管通过电话、邮件还是书面方式，保证将信息传达到每个人。这种情况适合小项目，人少；拉的意思就是项目经理就是一个类似web服务器，你自己需要什么信息就去问他。当然，没有项目经理把自己搞得那么累，他会用发布信息到公共介质的方式公布信息，简单的是白板，复杂一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉你。说这些看似很无聊，其实里面牵涉信息传达不完全的责任问题。当然，这些都是指一般的方式，而且不要绝对化，一般情况下，主动沟通和被动访问是同时存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。第二个问题就是文档问题，很多人怕写文档，但是项目经理一定要牢记“好记性不如烂笔头”的道理。有理有时候为什么会说不清呢？就是因为没有证据。所以项目经理开始就要和客户说清楚有些文档是必须签字的，比如项目经理的项目日志，每个星期至少让客户签字，另外所有达成共识的东西，比如会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样以后扯皮的时候，就能做到有据可查。记住：说了的就和没说一样，只有写下来大家签字后才算真正发生了的。还有一些问题，比如你提交的报告，给领导（包括本方领导和客户领导）做一个选择题，结果领导压住不批，让你无所适从，结果拖延了进度。这时候，你可以等，但是注意要留记录，标明是谁的责任；另外，如果你在开始阶段就和领导商定：如果批示提交三天后没有得到领导答复就算对方同意，这样你就会主动很多。再比如不同事件的审批流程问题：什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想得越周到，以后的工作就越主动。
项目同意并且你已经在为项目的建设做很多准备的工作了，接下来就是项目的具体性质的工作。这种具体性质的工作，包括为项目系统的开发所做的计划、项目需求获取、设计论证、技术方案应用论证、项目开发、项目测试、项目实施、项目收尾类型的工作。
1. 编写项目计划。做了很多前期工作，定义了一些游戏规则，现在是坐下来做计划的时候了。首先是找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作。项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。需求定义的是做什么的问题，而这里说的是怎么做的问题。这里要强调一点：完成一个目标有很多种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让你的项目减少很多风险。有时候客户会被某种新技术打动，坚持要你采用那种新技术，你就应该告诉他：你选我做这个项目，就应该容许我采用自己最喜欢的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成为第一批受害者。采用一个计划会让你的工作更加明确，比如用微软的Project软件，你填写完表格以后，就可以知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标志等。所有的结果最后用一个叫做甘特图的形式表现出来。你做完这个表以后会惊奇地发现，甘特图上项目的结束时间会远远落后于你的计划结束时间（签合同的人永远不会先征求你的意见的）。当然，学过项目管理的人会大谈什么WBS、优化路径之类的东西，但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。如果你没碰到这个问题，在我恭喜你挑了一个轻松活之前，请你再去确认你是否罗列了所有要做的事情和正确评估了他们所需要的时间。这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。按照什么标准牺牲？经验是如果你什么都赶进度，其结果可能就是十件事情你一件也没做好，想想多么失败啊。所以，把资源投到你熟悉和有把握的事情上，最后的结果是十件事情，你有三件做成了精品，三件完成，还有四件因为某些原因延误，成绩单是否靓丽了很多呢？战略决定优先级，而正确排列事情的优先级是一个项目经理能力的主要体现。项目计划作为PM向公司领导层、客户领导层以及项目内部管理都很重要，使得大家在每一个时间节点上有统一的关注度。此外，做好项目计划后，项目经理很有必要根据计划给项目团队成员做一次项目培训，这些培训内容包括：项目目标的重申、项目各成员任务的分配、项目沟通接口的说明、项目文档模板的统一、项目各工作标准的理解、项目进度及里程碑交付物的说明。这样的培训，为的就是围绕项目统一思想、统一认识。
2. 实施项目计划-管理项目需求。前期PM花了大量的精力，考量了项目方方面面的工作，也为项目实质性进展做了大量的准备，接下来就是组织项目资源执行计划、定期汇报项目、解决项目面临的实际问题。在项目需求阶段，项目经理需要业务专家、需求分析师的支持，快速获得系统需求。项目经理最忌讳的一点是客户高层用一句话概括了项目的建设内容，并因此认定为这就是项目所有需求。我在2011年参与过审计部门提出的一个内部评审控制系统的意向建设工作。当时客户提出了内部评审控制系统需求是：根据审计对象制定评审指标，对照评审指标统计分项得分，最终给出审计对象的总体得分。当我再去细化调研需求时，客户说不出来还有什么样的需求，并提供给我一大堆有关评审指标的文件，要求我深入了解系统需求。面对这样的需求，我直接给出了系统无法建设的结论。此外，客户在项目建设过程中，很有可能经常变更需求。对于这种需求天天变的客户，PM就一定要事先做好规矩：一、统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求你们内部先统一再和我谈，我不想卷入你们内部业务部门之间的矛盾之中；二、所有需求变更全部要有书面文字，这点切记！这样做好处多多：*有书面证据，以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的；*便于需求变更管理，需求如何慢慢演变的历史可以看清楚，从而更深切地体会客户的目的；*对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖章，他就要谨慎多了，而且一写东西，思想就会更加深入，很多无理要求也就这样胎死腹中了。对于有着大量需求的系统，PM要注意设立全职的需求管理人员，便于收集整理客户需求，并针对客户的大量变更予以合理的接受和拒绝。
3. 实施项目计划-做足设计论证工作。项目设计是认可项目需求的第一步，还是项目从需求变成项目实现的桥梁。项目经理在这一过程中要重视系统的功能设计、数据库设计、接口设计工作。根据项目大小，有必要分步做好概要设计和详细设计工作。而这些工作的组织实施，完全在于项目经理对于项目整体的把控。设计的论证工作必不可少。我之前遇到过一个例子，项目经理完全信任自己的团队成员，指派了项目各模块的设计人员，并要求设计人员与需求分析师及项目开发工程师沟通好即可。项目阶段省略了设计方案论证工作，导致后续的开发阶段，开发工程师完全不认可设计人员的设计方案，开发工程师的不能进入开发阶段，有的开发工程师为了赶项目进度，直接操练起模块的设计工作来，又导致后续开发的系统完全不符合项目需求，客户无法验收项目。因此，项目设计方案论证工作，是必须完成的一步。
4. 实施项目计划-有必要做好技术方案应用论证工作。有的项目，要求应用先进技术解决棘手问题。项目经理必须组织专家论证会议、技术应用指导大会，强调系统的重要部分将如何借助先进技术，解决一些重要问题。这一阶段的工作，视项目情况而定，可深可浅。
5. 实施项目计划-管理项目开发。项目开发工作，并不仅仅指项目编码工作。在开发前期，项目经理必须组织准备良好的项目研发工作环境、配备选用合适的项目研发工具，在开发周例会上，收集项目进度信息，协调解决项目问题。有必要强调一点的是，项目经理要重视项目版本管理，制定各文档、源代码的版本管理制度，向项目组成员强调版本管理的重要性。在2012年的一个项目中，我经历一个项目的研发，当时的项目开发人员就两个人，项目经理及其高层领导认为这样的团队更加利于管理和开发，而开发工程师们各自负责独立的模块开发，所有成员都没有考虑各文件版本管理工作。当项目需求变更时，开发工程师负责跟进修订项目模块，加上项目实现方案上，发生了开发工程师们推翻过去方案的事件，导致项目实际情况严重偏离了项目计划。项目经理在查找到底在哪一时间点发生问题时感到很迷茫，文件不知道何时被修改的，更不知道为何被修改了。项目只得推倒全部重来。如何管理项目开发，是项目经理在开发阶段要重点协调的工作。一般而言，我们有很多版本管理软件使用，比如SVN、VSS。在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，比如，【界面要求：美观大方、简洁明快】，这个要求我就不知道如何检查。所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划，里面有一个任务【开发人员熟悉EJB编程】，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。做项目就是为了验收，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。
6. 实施项目计划-管理项目测试。很多人不重视项目测试工作，认为项目流程走得通，项目能处理客户业务、满足需求就可以了。这是极其可怕的事情。项目测试工作，是要发现项目中隐藏的各类缺陷，降低因项目质量问题而给客户带来灾难性后果的风险。测试的结果不是项目通不通过验收，而是项目健不健壮。对于很多软件来说，实现客户基本需求是软件必须具备的功能，处理一些突发情况则是软件应该具备的能力，如断电前的数据备份，软件崩溃后自动重启，软件边界的无差错处理能力，高密度数据处理能力，不正常流程操作的系统容错能力等等。作为项目经理，应该做到管理好项目测试的全方位工作。你可以指定测试经理来分管测试工作，也可以自己承担测试经理的职责。项目测试工作包括：测试环境的部署、测试工具的选择、软件测试版本的管理、测试用例的设计与执行、测试报告的编写。当系统的功能、性能还达不到要求时，这样的工作将反复进行。我所知道的IBM的产品，拥有非常强大的测试团队，一个产品，在多国有几百人上千人的测试队伍，不但涵盖了功能性测试、性能测试，就连不同操作系统环境下的细粒度测试，他们都会列出详细的测试计划，交由专门的测试工程师负责处理。
7. 实施项目计划-管理项目实施。这是一项非常难的工作，毕竟前面的工作大部分面向团队内部成员，很多的工作可以通过项目指令来完成，而现在的实施工作是真刀真枪的实战场，没有机会给自己犯错误，给自己留面子。客户的抱怨和不满将接踵而来。项目实施，要做到提前向客户提出实施计划，要求客户为之准备些什么、如何配合工作。另外，指派熟悉项目产品又会沟通的人员组成实施团队，在客户现场实施产品。若是涉及到升级改造项目，项目实施工作将要重点保护原有业务系统能正常工作，以便在实施过程中发生意外时能及时切换系统。项目实施过程中，严格按照既定的实施流程，做好实施记录，跟踪观察已经部署的项目的运行情况。当项目运行到约定的时间点，记得及时向客户报告运营状况并请求客户签字确认。毕竟这是项目验收的必经环节。项目实施中还有一个考验项目经理功力的就是如何调动客户积极性的问题。一般来说，客户是懒的，这就是他花钱找你做事情的原因。一个项目的成败，和客户的配合程度很有关系。根据我的分析，一般项目中的客户都可以分为三类：支持的、消极观望的、抵触的。他们人数的分布一般是一个纺锤形：支持的和抵触的人少，观望的人多（如果你接了一个人人都抵触你的项目，那你还是不要做了）。首先，分析一下那些人为什么支持你和抵触你。很简单，于公于私两个方面分析，上了新系统，谁的工作量有所变化？谁的潜在利益是否受到威胁？谁的岗位是不是因为新系统而消失？传统的利益格局因为新系统的使用而发生怎么样的变化，这些东西，都是项目经理必须去了解的，这样，你才能团结那些支持你的人，消减那些抵触你的人。项目经理是一个很奇怪的角色，属于典型的责任大、权力小的角色，他能做的只有借力打力，不管在自己公司还是在客户那里，一定要依靠别人才能完成自己的目的。只有了解哪些人会因为什么而帮助你，哪些人会因为什么而抵触你，你才能让客户配合你做工作。比如上一些内部计算机辅助管理系统，其必然后果就是让本来管理混乱时有人可以浑水摸鱼的一些利益消失掉了，这样，有些人肯定就要捣乱，到处诋毁这个系统。这时候，你就可以散布一些“谁抵制新系统就说明自己屁股上有屎”这类的论调去压制他们，减弱他们的影响。
8. 实施项目计划-管理项目培训。项目要给客户用，必须教会客户如何用。项目经理要求规划好项目培训工作，指派团队善于沟通的、懂产品的工程师负责客户培训。这个阶段，项目经理一般要注意以下几个问题：一、给客户做培训的版本，一定要保证所有流程的正确性，注意每个界面的布局、用词、链接的正确性等等，总之不要让客户看到一些他不该看到的东西。文档方面，准备至少两个文档：用户手册和培训手册。这两个文档的内容很多都是一致的，但是角度完全不同。用户手册往往是站在系统设计者的角度，按照自己的思路，分模块讲解系统的操作和功能；而培训手册，一定要站在客户业务人员的角度，根据每个角色面对不同业务的办理，如何通过使用本系统的一系列功能来实现目标。此外，培训可能分部门培训，这就要求准备不同内容和版本的培训手册。所以，第一次培训以前，系统界面是否完整正确、培训文档是否完备都是很关键的因素，第一炮打不响，以后就麻烦很多。二、抓住一切机会给客户灌输你的实现方式，给他们心理准备，不会感觉新的东西太突然。三、培训、试运行过程不宜过长，免得搞得双方都很疲劳。从编码结束、培训、新系统数据准备到试运行，一定要紧凑，让大家在忙碌中上线。否则，时间拖长了，再给客户挑出几个小毛病，项目的组员士气下来了，人心散了，队伍就不好带了....
9. 实施项目计划-管理项目收尾。项目收尾意味着项目收钱。项目经理往往在这个阶段积极性最大，也最忙碌。项目经理必须在最快的时间内准备验收各文档、阶段性验收报告、了解客户实际的验收需求和交付物。在国内，很多企业在验收乙方的交付物时，往往和项目开始阶段制定的验收标准有一定的差别，这是国内实情。项目经理所做的大量工作即是满足客户的验收需求。此外，有一些企业又喜欢拿出行业标准来约束乙方的验收过程，这势必增加项目经理的工作，但项目经理又没有办法不去执行这些需求。一旦交付物和验收报告工作都完成了，项目收尾工作还剩下最后一项重要的工作——项目经验的总结。这不但是项目经理对整个项目建设过程的回顾，更是为接下来的项目建设工作提供重要的参考，有利于项目经理把控更复杂的项目研发。一般而言，项目总结工作有必要在项目团队中开展。而一些注重项目团队建设的公司，通常还会召开项目总结大会，提供项目庆功的平台，让项目团队成员之间、项目与内外部人员之间相互了解，以达成项目收尾的效果最大化。
项目从想法到实现，经历的环节大致有以上所述的过程，每一个成功的项目，都不可省略这些过程，否则，项目从整体上来说是失败的。作为整个项目的实际控制人，项目经理要面临诸多实际的问题，并为之制定有效的方法逐一解决。
原文地址：http://blog.csdn.net/lejuo/article/details/38047115
