项目管理和软件开发的认识(上)

时间永远是最大的风险：如果说软件开发的最大风险是什么，我认为是时间。从来还没有听说那个团队很轻松的在合同时间里很好的完成了项目。当拿到一个项目评估时间的时候，是很盲目的，即便是你估计到了每个功能，每个技术难点，总有很多的意外发生，致使项目本来预估很宽松的时间搞得紧张起来。另外是软件开发的速度总是慢于直觉，一个开发人员凭经验和直觉评估一个功能实现所需要的时间，往往是最乐观的时间，其实把这个时间再乘于二，才可能是正常的时间。所以要抓紧时间，无论在项目初期，中期还是末期，往往是在项目末期，时间搞得很紧，大家都忙的一团糟，加班加点，或加人手，我的看法是加班不可取，加人手更不可取，加班效率不一定怎样，并且透支的第二天的精力。加人手往往被认为是一种有效的方式，其实不然，新加的人手对项目不了解，要有个学习的过程，需要有人告诉他，这便耽误了其他成员的时间，另外新加的人能不能和其他的人合作，还是个问题，当然项目中期加人手还是可以的。所以要想项目时间风险降到最低，在项目一开始就要好好运筹。

软件开发一切问题本质源于沟通：软件开发过程中会有很多问题，项目延期、软件设计不合理（包括界面/功能/架构等）、或者做了很多无用功等等不一而足。而这些我认为都是现象，而本质是沟通。我们进行个简单的分析：首先项目延期，为什么项目延期，原因自然很多，但大家感受最深的一个理由应该是客户总是要求对一个功能这样那样的更改或者客户要求的功能永远都在增加，客户是上帝，他总是对的，这是无可辩驳的，那似乎这个问题是没办法解决的了，不然，我们来分析下为什么客户总是要求该来改去，其实要求的那个功能还是那个功能，只是我们是按照我们的理解来做的这个功能，而不是按照客户的理解来做这个功能，这是沟通不足的表现；客户要求的功能永远都在增加，有一句名言是这么说的“客户永远不知道他要的是什么，直到你给了他”，这句话用到软件开发我觉得尤其合适，当你把所作的软件界面给用户看了之后，客户发现他们比我们聪明多了，你看，少了这个功能，那个操作不方便等等要求就出来了，的确，这一次客户又对了，那就是我们错了，错到哪里了？错在我们没有理解刚才那句名言，如果我们在需求分析时就拿出原型或者就是一些简单的图片给客户看，他很早就提出了这些需求，根本就不是后期在变，当然这样不能保证100%的解决问题，但至少能解决大部分问题。还有极端的，负责和我们合作的客户代表对我们有敌意，故意挑刺，那是另外的问题，不过也可以归结到沟通问题，哈哈，那是某些人的沟通工作做的不到位。其次，软件设计不合理，这自然与设计人员的能力有关，但如果设计人员之间能讨论一番，估计不光每个设计人员的能力能大大提高，软件设计的也更合理些；最后，做了很多无用功，这个问题可以表述为做了一些客户不想要的功能或者一些功能做错了得重做，为什么出现这种情况，一句话，闭门造车，根本就没和客户或者别人交流过，纯粹按自己的想象做软件。上面分析的几个当然不是软件开发的全部问题，但软件开发过程中的问题我认为都可以归结为沟通问题，或团队成员之间，或开发人员与项目经理之间，或开发团队与客户之间。

软件开发不需要是精英团队：理想化的人认为如果软件团队中的每个人都是高手，岂不是能有快又好的做软件，如果这样，软件开发的失败率可能没有实际情况中的这么高了，因为有钱的公司一大把，他们都招技术牛人，项目肯定不会失败了，实际情况远非这样。其实是精英越多的团队，往往越容易出问题。这不难理解，每个人都想当将军，都不想做士兵，每个人都有自己的一套想法，都不愿听别人的，这就是软件开发高手的个性，不论哪个开发高手愿不愿意听我说这话，这是事实。你说：团队高手都各司其职，勤勤恳恳的把自己的工作又快又好的做完不就完了，呵呵，我说：一、一个团队这样的高手不好招，二、成本也太高了点。我认为软件的开发团队与做别的工程的团队没有什么区别，成员中的每个人都有不同的分工，技术水平和经验的多少也需要成梯度分布，经验多的多做做分析设计工作，经验少的做做做具体实现功能的工作。设计的人也不能脱离群众彻底不编码了，不写代码是做不出好的设计的。另外强调一点是，团队中最好有对使用的技术（如某个框架）非常熟悉的人，这样会在这方面少走很多弯路。高手肯定是需要的，我认为一个团队中有1-2个就够了，2个更好，可以相互弥补对方的知识弱点，也可以切磋切磋。

软件开发对开发人员说是艺术，对管理人员说是工程：软件像艺术品一样，是个人思想的反映，准确的说是对团队思想的反映，而某个功能则是个人思想的反映。同样的功能，不同的人来实现，写法千差万别，这个功能就是他创造的艺术品，甚至可以说看了某个人的代码就可以看出这个人的个性和思想，同一个人不同时期的代码反映了这个人个性和思想在不同时期的变迁，不信可以看看你以前写的代码或你同事的代码，和他的个性比较一下，这个当然也与水平有关。总之，写软件有点像书法、绘画、音乐等艺术。一个对编程热爱的人，在写代码时的确有艺术品创作时同样的快感。然而不同的是，艺术品往往是个人创作的，软件则是团队创造的，这从另一个侧面反映了软件是一个工程。对管理人员来说软件就是一个工程，因为管理人员要控制成本，风险等工程的指标，一个延期的软件项目，不是一个成功的工程，一个成本过高的软件项目，同样不是一个成功的工程，管理人员要从工程的角度来定义软件。

OO是对现实世界的一种理解方式：现在做软件的人没有人认为自己不理解OO，那个开发人员说自己不理解OO会被别人笑死的，快看那，这个人连OO都不理解。说那个开发人员不理解OO对那个人来说简直就是耻辱。如果问一个刚毕业的大学生，OO是什么？他会告诉你OO就是继承、封装和多态。进一步深入问为什么要OO？恐怕没人能回答，或者给你背一些书上的定义。这是问刚毕业大学生，他是这样回答，各位开发人员你问问自己呢。如果你问我这两个问题，我的回答是我不敢回答，一说即错，不论我怎么说，你都能找出我说的不严密的地方，何况就我这水平，恐怕还没你高。我只能侧面这么说，OO是对现实世界理解的一种方式，我们把现实世界的一切东西都看成对象，世界上发生的所有事情都是对象与对象相互作用的结果，这是一种理解世界的角度，你尽可以从别的角度来理解世界，以前的面向过程不就是以过程的角度理解过一遍世界了么。其实这两者并不冲突，有些以面向对象的方式理解更自然而另一些以面向过程的方式理解更自然，例如数学运算，就是一种过程。即便我这么说OO，还是不能和软件中的OO对应起来，如软件中的服务，就是把动作当成对象，当然，这是为了编程方便，另外一个原因是是由于技术限制，不可能做的和现实世界做的非常对应。经常看到有讨论说，某某做法不够OO等，其实没有去较真够不够OO，他根本不会阻碍你做出好软件，没有OO的时候不也照样做出好软件了！个人看法是，如果你真的理解OO了，当你分析一个问题的时候会有一种莫可名状的感觉，就是你一看到需求描述，你就看到一堆对象在相互作用来解决这个问题。呵呵，是不是有点走火入魔了。

说到这里，关于OO，想做个动态语言（Ruby）与静态语言（Java）的比较，动态语言从OO角度来看的一个特点是可以动态为类或者对象添加或卸载属性和方法，而静态语言则不可，静态语言一开始就定死了这个类有什么属性和方法。就拿最普通的Person类来说事，一个人最普通的行为是吃喝拉撒睡，按面向对象的说法，就是Person有这五个方法，这个没错，但问题来了，如果一个人喝酒喝醉（我们把醉酒也理解成一种行为）了，就和平时的吃喝拉撒睡不一样了，好，如果是Java，那我们就再定义一个接口，让Person类实现这个接口，这个人就可以醉酒了，但且慢，这样一个正常的人对象也拥有了醉酒这个行为，他成了一个人的固有行为，我们说这是不对的，他应该是只有在喝醉的时候才能拥有这个行为，这对静态语言来说是个解决不了难题，动态语言就恰恰很简单，动态的给这个对象加上醉酒这个方法啊。当酒醒了就把这个方法卸载了，太漂亮了，从这点看，动态语言是不是比静态语言更好的模拟了现实世界呢？

框架抑或语言是一种工具：

前有Java和.Net孰优孰劣的论战，后有各种框架那个那个坏的大讨论，这样讨论过来讨论过去，讨论不出个所以然来，如果是两个绝对可以相互替换的东西，如.Net和Java（除去平台移植），结论不了了之，没有哪个比那个更好，如果是两个有差异的技术。如Hibernate和ibatis,结论就是这两种技术各有优缺点，各有适用范围，择其善者而从之，讨论出这样不同不痒的不讨论也知道的结论来。哈哈，恰恰这结论是最有用的结论，考虑下我们用这些技术的本意是什么，解决问题，那好啊，既然是解决问题那就选择解决问题又快又好的方法啊，砍树当然用斧子而不是镰刀，割草当然用镰刀而不是斧子。“当我们在寻找解决问题的途中，我们是否迷失了？”，我们的确迷失了，当我们会用了某种技术，往往会认为这种技术是万能利器，认为自己的是最好的最强的，“有了一把锤子，看到处都是钉子”。与别人去争论，还有一点意义的是，对某种工具的优缺点理解更深刻些。我们要记住，不管是java还是.net或是Hibernate还是ibatis等等，我们找准他的特点，用它所长就是了，他是我们用的工具。更高一点的层次，软件、计算机也就是工具，如果某项业务不需要软件，或软件管理效果不明显，可以选择不用软件。他们都是工具，我们可以综合各方面因素考虑，选择用或不用，或选用那个。

下期将对以下主题阐述：
敏捷是一种以人为本的开发方法

把握了设计原则就是把握了设计精髓

设计模式是实现面向对象设计原则的形式

对项目工作的统筹，对团队成员的激励和团队团结以及面对客户的沟通，是体现项目经理能力的标准。

团队是个有生命的个体，有性格也有精神