Java/OOP Code Inspection Checklist

Code Inspection的checklist可以分两方面内容：基本编程原则检查和语言相关检查。

基本编程原则

基本编程原则对大多数语言都适用，尤其是面向对象语言。

• 格式
• 由于有IDE（Eclipse, Netbeans……）的支持，代码格式可以很容易地自动编排，统一大家的代码格式很方便。
• 乱糟糟的代码看起来很晕，没法让大家集中精力检查。
• 命名
• “编程语言”也是“语言”，需要传递信息。编程语言的规则能保证计算机能理解，但不能保证人能很好地理解。为了让人能理解，必须在变量、方法、类等命名方面下功夫，让人见名知意。
• 有一些基本的规则，如：类用名词、方法用动词、变量用名词等，可以参考各语言约定俗成的编程规范。
• 好的命名可以极大增加程序可读性。文档、注释也是为了理解程序。相较而言，程序同时还是最终真正“产品”，因此，应当让程序自身可读性加强，减少对文档和注释量的需求。这样在维护代码时会减少对文档和注释的维护量。
• 消灭魔数
• 所谓“魔数”指的是程序逻辑中包含的数字，这些数字可能在多处出现，或可能随时调整，如：
• if(user.type==1) ......
• 1代表嘛意思？得写个注释。如果定义成常量，有个名字，这地方就好理解多了。同时修改常量值比在代码中到处替换容易多了。
• 注释
• 意义就不用说了，老生常谈了。
• 虽然老生常谈，但往往做成了两个极端：太少，太多。
• 太少不奇怪，毕竟没有注释编译时也不会报错，人本性总有惰性。
• 太多怎么可能呢，多了怕嘛？！的确有太多的情况出现，恨不得每一句话都写一个注释，解释这句话的作用，或者在每个方法、程序块前详细描述其中的操作过程，代码就是注释的映射。这就太过了：首先，打开程序看的应该都是程序员，看合格的代码应该不会比看大段的注释难，注释白费了。其次，稍微修改程序就得同步修改注释，否则以后以谁为准？麻烦得很！
• 注释解释这段代码解决什么问题；代码本身接受如何解决。
• 解决两地分居
• 变量声明和使用相隔太远，或超过了必要的生命范围。
• 在某些语言中，这是语言自身的限制，只得将就了。但对于变量声明位置灵活的语言，再这样做就不厚道了。
• 变量就近声明；最小化生命范围。
• 重复代码
• 计算机上copy & paste太方便了，以至于大段的代码在程序中不断copy & paste。
• 由于copy & paste的太快，往往该改的地方没有改过来，产生bug。
• 修改代码的时候，由于被paste到太多地方，往往修改不完全，产生bug。
• 应该训练一种意识，写代码时只要按ctrl+C的时候就好好想想能否把copy的东西抽出来做成共用方法，避免重复代码。
• 即使没有copy & paste，多次手写重复代码也应有以上意识。
• 长方法
• 长方法难于阅读，受限于人脑的“缓存”，往往读了后面忘了前面，尤其在上下翻屏的情况下。
• 抽出多个方法。主逻辑中通过方法名就可以知道逻辑过程，岂不美哉？！
• 抽出的方法别其他地方调用的可能性大大增加，减少重复代码。
• 巨类
• 无所不包的类。由于包含了太多的功能，没有一个明确的现实对应，“四不象”。命名困难就是一个信号。
• 一个类只应该有一个方面功能，不要多管闲事。
• 耦合度
• 类/模块之间的耦合度应尽量低。来回频繁反复调用应该避免。
• 往往由于类/模块之间功能划分不合理造成。把方法放到合适的类/模块中去。
• 调用者在一个逻辑中多次调用被调用者的方法。可以认为是“微观管理”。
• Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.
• 滥用全局/成员变量
• 全局变量是否是必须的？
• 成员变量是否应该是类的一个属性？
• ……

语言相关检查

各语言有自己的pitfalls需要检查。例如Java中：

• null
• 是否在使用对象变量前判断不等于null？
• equals
• 对象的比较应该用equals。除非比较两个对象是否为“同一”对象，否则不能用==比较。
• 自定义类，如果需要用equals比较，是否重写了equals方法？
• 资源释放
• 如IO操作使用的file、socket等资源，需要在使用后主动释放。
• 为了保证资源的释放，需要在finally中主动释放。
• ……

Effective review

如何在软件项目中进行effective review？这是个问题。

在时间紧张的时候，大家过于关注自己的部分，往往对其他人的工作没有足够的熟悉程度，这时候进行review往往得不到好的效果，尤其是在不提前进行准备的情况下。

一直以来，认为大家先在底下独自review，然后再聚到一起把review结果汇报一下的做法不经济，所以选择让大家会上当场review，随着owner的引导，大家一路review过去。但一直有一个问题：很多人跟不上队伍，或者干脆不打算跟上，这样的review会留下很多隐患，以至于有些功能遗漏居然没有发现。其实大家独自review也会有这个问题，只是时间宽松一点，可以做的细致一点而已，但同样没有效率。

review最根本的功能有两个方面：例行检查与功能检查。例行检查目标是找出不符合普遍规范的地方，例如文档不完整，code形式不符合规范等。功能检查的目标是找出错误理解需求或遗漏需求的地方，也包括算法或架构性能、安全等方面的缺陷。

在采用现场review的时候，由于节奏很快，把这两方面的检查一起进行，可能就会导致很多人“身在曹营心在汉”的状况，review草草收场。

怎么办？分开呗，进行至少两遍review，第一遍例行检查，第二遍功能检查。如果有意见，也可以颠倒顺序。例行检查根据checklist进行，功能检查根据上一环节的input，如需求文档，设计文档等。

Document Review

首先owner展示文档，reviewer检查各部分是否齐全，是否遵守约定的模板。第二遍功能检查视各文档目的而定，如设计文档要看能否覆盖需求，如果不能，是否已在文档中指出。

Code Inspection

1.功能检查

按scenario进行，owner需要在会前准备scenario，并且标注每个scenario对应的需求点。

Inspection的第一步是检查scenario是否符合需求，覆盖所有需求点。

接下来对着每个scenario进行功能实现检查。

2.例行检查

例行检查的checklist需要在项目启动的时候定义好，或在编码前定义好，如果有人不熟悉，需要进行培训或沟通。

这个checklist需要经验的积累或借鉴别人经验的结晶，根据编程语言有所不同，例如C++语言需要检查指针操作、内存的分配/释放等，而Java项目就无须检查这些。但基本编程原则的check是一致的，例如变量命名等。

按需解决：设计的“长尾”

以“长尾理论”的观点来看，“按需解决”就是对产品和服务的尾巴催长剂。

在产品供不应求的阶段，产品的设计在和客户接触准备交易前就已经结束了，对某一市场按照统一的设计生产产品或提供服务。当产品竞争激励的时候自然需要尾巴的增长，如何增长？在《尾巴可以再长一点！》中有过分析，其中对设计生产的分析提出了对生产设备智能化更进一步的要求，当然这是针对制造类产品，有了很容易更改设计的生产设备就能大规模生产定制化的产品。

其实，这里还有一个问题：如何设计？再智能的生产设备也还是需要输入设计才能生产产品。当然是根据用户的需求。

对于普通产品，所谓的设计可能让用户选择一些产品属性的参数就可以了，比如DELL的电脑直销，用户可以选择CPU、内存、硬盘等参数，然后DELL就会将这台定制的电脑送到你家里。这是很容易的。

对于一些针对行业用户的产品或服务，客户购买这些产品或服务是用来产生价值，对这类产品或服务的设计就没有上面所述的那么简单了，因此会有《按需解决之道》这本书专门写这个。通过按需解决产生的解决方案满足了客户的特殊化需求。

因此，按需解决实际上是设计上的“长尾”。

按需解决之道

自从郭士纳喊出“谁说大象不能跳舞？！”之时，IBM这头笨重的大象就开始跳着舞步从“产品提供者”到“服务提供者”的转变，虽说这大象的舞姿不那么婀娜多姿，但到底是跳起来了，并且据说真的跳到了彼岸。当然，在彼岸的大象并没有停止跳舞，继续迈着舞步跳到了“按需解决方案提供者”的黄金海岸。

这就是《IBM按需解决之道》里描述的名为IBM的大象之舞。这本书描述了一个买方市场中卖方如何生存的“大道”：按需解决之道。

在产品提供者可以生存的时代，基本上是卖方市场，产品不愁没有买方，因此，产品提供者可以按照自己的想法设计产品，让买方适应产品，按照产品提供的功能凑合着使用产品。

当市场中的产品提供者越来越多，提供的产品越来越丰富，买方可以选择越来越多，于是买方开始关注产品提供的功能，而不在乎产品本身，这也是符合逻辑的，用户其实想要购买的是功能，而不是产品，在市场上能直接买到鸡蛋，何必非得买只会下蛋的母鸡回去呢？！即使市场上有不同类型的母鸡，如两条腿两个翅膀的、四条腿两个翅膀的、两条腿四个翅膀的等等，对于需要鸡蛋的人，这些都不重要，如果需要在这些参数上面花时间挑选，那太不经济了。于是乎，“服务提供者”粉墨登场，对客户直接提供服务，而非通过产品间接提供，比如不卖软件了，改为出租软件能力，如本来卖财务软件的，现在不卖了，把财务软件放在自己的服务器上，通过网络开放给客户，客户不用付软件本身费用，而是用一次付一次租用费，不用不付费。这样的好处是节省了用户一次性产品购买费，而转变成按需使用付费，和用电用水的流量付费一样。另外，客户不用为产品升级付费，这也减轻了产品快速更新换代对客户形成的成本压力。

随着时间的推移，服务市场上的竞争对手也越来越多，原来的“蓝海”被血流染成了“红海”，想活得更轻松只有去开辟新的“蓝海”，IBM这头大象于是继续前进，发现了“按需解决方案”的蓝海，率先进入。在这块“蓝海”中，服务提供者不简单地提供现成的服务，而是和客户一起研究客户面临的问题，提供相应的解决方案。至于产品，那早就是很古老的事物了，解决方案中选用产品的标准是能否解决客户问题，而非到底是谁的产品，解决方案提供者可以不提供任何产品或服务，而只需从第三方获得产品或服务，满足用户需求，为用户创造价值。

从销售产品到销售解决方案，看似小小的改变，却对方案提供者提出了很多公司组织制度上的改变。例如以前的销售人员只需要将产品介绍给客户，即将价值从产品生产部门传递给客户，做一个中间人，没有增加任何额外的价值。而销售解决方案的过程其实是和用户一起创造价值的过程，销售的过程直接就是创造价值，因此，企业组织就和以前有不小的改变。解决方案完全是知识工作及创新的结果，因此，提供解决方案的公司也必然是知识型企业，并且需要很好的创新能力，如何管理知识、激发创新也是很重要的方面。

虽然说不能对所有产业一概而论，但总得来说对IT及电信行业，这本书还是有一定指导意义的。尤其在电信行业，客户就那么几家，设备提供商的竞争日趋激烈，如何主动和客户一起发现问题、解决问题，帮客户产生额外价值，是设备提供商的一个很重要的生存技能。其实，在电信行业，类似做法已经比较普遍了，比如运营商在招标前会汇集各设备提供商的方案建议，综合分析后，得出一个实施方案，再进行招标。当然，这和按需解决之道还是有差距的，比如很多设备提供者为了中标，在投标过程中对用户需求无所不能，而在中标后又去努力遮遮掩掩，最终提交了一个和用户需求相差很大的产品，不要说创造额外价值，连正常价值也是掺了水的，这是非常不负责任的。

正是这个差距，形成了一个蓝海。就看谁的水性更好了！

当一切已成为习惯

上天是会捉弄人的！

没有拥有的时候是无所谓失去的，但当拥有并一切已成为习惯后，突然又从手中夺走，这种打击是让人无法立即接受的！

因为习惯了，总会不自觉地想起或在潜意支配下而做出习惯性动作，于是发现已经失去了，继而悲伤。

为何悲伤？感情的东西是无法说清楚的，也无意于搞清楚这些，但有一点应该是无疑的：把对方看成是和自己对等的，才会真正悲伤。

什么能和人称得上对等呢？只有人，有思想、有感情的人！

当然，人的感情判断是主观的，对于什么是有思想、有感情也是主观的，甚至什么算是人也是主观的，因为所有的东西都可以被拟人化，对着怀里抱着的宠物大喊“心肝宝贝”的大有人在。

所以，人真正是为自己、为自己投入的感情而悲伤，而不论悲伤的对象是否真的有思想有感情。这是否也说明感情是单向的呢？即使有看起来是双向的爱，或许那也仅仅是因为两个单向的爱在时间上重叠罢了。

悲伤让人痛苦，或者痛苦让人悲伤，分不清因果，或者本来就互为因果，无所谓。但如何才能让人没有悲伤、没有痛苦呢？也许永远办不到，已经吞下的智慧果是无法再吐出来的，作为万物之灵，“百忧感其心，万事劳其形”，这就是拥有智慧的代价。智慧（情商）越高，痛苦越多；之前的快乐越多，之后的悲伤也越强烈。大观园中的多情公子贾宝玉一开始极尽快乐，最终却逃不脱“宴席散去”后的无限悲痛，直到避入空门。

其实何止是人呢，只要是稍微拥有点智慧的动物都摆脱不了这个“诅咒”，智慧越多，“忧”也越多。有一集《动物世界》里有个猴子妈妈的一个幼猴死去，猴子妈妈就一直带着幼猴的尸体行走，好像没有死去一样，这样过了很多天，猴子妈妈才接受现实，放下怀中幼猴已经腐烂不堪的尸体独自离去。虽然猴子妈妈没有用人类可以理解的语言表达出自己的悲伤，但相信每个人看到如此行为都能感觉到她撕心裂肺的悲痛。

人不能免于悲伤。但对于具体的某一个悲伤是会痊愈或忘记的。时间会带走一切，包括曾经的习惯。当一次次下意识想起或动作，又一次次认识到已经没有意义并悲伤后，悲伤也就随着习惯就慢慢地走了。

数据揭示的软件项目管理

偶然之间，再次读到developerdotstar上转载的Robert L. Glass的文章《Success/Failure Criteria: Some Surprises》，上面罗列了最近的一些从真实软件项目中收集来的数据，总结了一些决定软件项目成功与失败的因素，其中的一些数据对习惯于传统软件工程思维或停留于纸上谈兵的人们应该具有很大刺激性，Some Surprises是肯定免不了的了。

去年差不多这时候就读过这篇文章，当时就觉得很有意思。有意思之处不在于使我surprised，恰恰相反，在于很多数据或结果佐证了我的想法。原本对自己的与众人“格格不入”的想法还心存疑虑，这下有了真实世界的数据撑腰，可以直起腰板了:)

当然，虽然我的某些想法或做法可能在Process非常严格的公司环境下显得有些格格不入，并不是因为刻意想标新立异，而是实际的情况使然，从本科做毕业设计开始参加的第一个实际软件开发项目以来，大大小小的正式项目（学校里的作业当然不算，只算最终软件要投入使用的）也有十来个了，在此过程中发现现实中的软件项目实施过程因为各种原因，往往与“传统智慧”不那么相符，或完全相反，而影响项目成功的各种因素也不是理想中的那么简单。

困惑引人思考，而思考就会有怪想法（上帝发笑），怪想法被证明为符合真理当然是令人得意的，不过得意忘形就不对了，所以还得时刻对自己的想法做检讨和检验。从最初看这篇文章到现在，一年过去了，现在就着这篇文章对软件工程作一番思考应该也是有价值的，学习老牛吃草的精神，吃的时候快速吃，吃过以后再抽空反刍。

现在反刍时间到了，以下英文为原文，中文为评：

Brisbane, Australia - At a breakfast seminar here June 6 on "Factors for IT Project Success and Failure," Prof. June Verner of NICTA (the National Information and Communication Technology institute of Australia) provided a fascinating mix of surprises and predictables related to her subject topic. The findings came from NICTA’s study of 400 projects in the U.S., Australia, and Chile, using questionnaires and interviews to discuss success and failure factors with practitioners.

What were the surprises?

• Most projects that had no schedule were successful
  • 没有schedule的项目居然会成功？第一条就让很多人感到非常surprise了。
  • schedule的用处何在呢？是不是说在项目开始之前定一个schedule就意味着项目会按照schedule进行？当然不是了，下面就有一条说75%的项目都会估计不足，因此延期是太正常不过了，Microsoft等软件巨头就经常宣布软件延期发布。因此schedule的存在对项目实际进行只能是辅助作用，在团队之间或内部起交流沟通之用，使大家在时间上有共同概念。如果团队成员间的沟通很好，或大家能有默契，把工作分块后放入工作池，每个人都从工作池中以最优化的分配算法选取任务，以最快的速度完成任务，再次取任务，如此循环。有什么理由需要事先制度一个详细的schedule呢？
  • 详细的schedule可以项目开始时制定出来吗？当然可以，但要想准确就难了。随着项目的进行，总会有很多一开始预计不足或变化的情况出现，按照之前的schedule肯定没有办法执行。因此，schedule的制订并不是一劳永逸的，需要在项目进行中随时调整。
  • 有schedule意味着最有效率吗？当然不是。上面所设想的工作池方式才是最有效率的，当然那是理想的情况下，团队成员没有个人的私心，一心为公，实际是否行的通还没有验证过。在事先制定schedule的情况下，由于大部分人都有把工作拖到最后一分钟的弱点，往往即使在工作可以提前完成的情况下也拖到最后，使效率比理想情况下低很多，往往还造成延期。为了克服这点，往往在安排schedule的时候会刻意把任务完成时间提前，将克扣的时间放入缓冲池，以待不时之需。
  • schedule是如何制定的呢？当然理想情况下是根据项目从需求到任务分割，再根据关键路径排出项目的详细schedule，得出一个软件发布日期。实际情况呢？往往很多项目先有一个deadline，根据deadline往前推，这是项目时间紧张情况下的惯常做法，往往安排的schedule是“不可能完成任务”，造成不是延期的“延期”。
  • 如此看来，这条并不surprising。只要对团队的管理和建设做的很好，完全可以在没有schedule的情况下更有效率地工作，成功有什么惊奇的呢？！
• Requirements are needed for project success, but not necessarily early in the project
  • 做项目当然得有需求，大家总得对做什么东西有个共同想法，这是毫无疑问的。但很多人往往又对需求太过强调了，以至于非得等所有需求确定后才能开始工作。这又走火入魔了。尤其在做项目的时候，往往客户是不可能一次性给出所有要求的，我们也没有办法做出一个一百年不变的需求设计，在项目的实施过程中会很经常地改变需求，这是正常的。因此，在项目的早期可以根据一个很粗略的需求开始工作，待项目过程中和用户的不断互动逐步明确需求。
  • 需求天天变，开发也时刻跟着变，还怎么往下做啊？需求的确可能天天变，但开发不需要时刻跟着变。可以对需求改变做管理，分批处理。
  • 如何使软件开发更适应变化？这是很大的话题。但有个总的原则：使开发团队能力提高，反应越敏捷就越能适应变化。一些技术可以帮助项目更适应变化，如code refactoring、test driven、AOP、OOP等。
• Projects often continue successfully for some time with unclear requirements
  • 项目可以在一段时间内在不清晰的需求情况下顺利进行。但接下来呢？当然需要清晰的需求了。
  • 如何能获得清晰的需求呢？快速原型法当然可以。但是编写原型花费的努力就白费了，并且通过一次原型演示就让用户说出所有要求好像也难了点。近几年的Agile方法更进了一步，在开发过程中引进客户代表一起工作，用小的release让客户代表反馈，利用反馈收集需求信息，逐步明确需求。
  • 客户代表的想法不错，但往往是请不到客户代表的。怎么办？只能在初步了解用户需求后，按照自己的设计开始工作。完成第一版后让用户反馈。只所以说自己设计是因为中国的客户很少有自己能说出需求来的，往往都是我们按照自己的想法去设计，引导客户。这点在国外的客户可能会好一些。
• The choice of requirements methodology does not matter; UML was "no help"
  • 这对UML的“粉丝”来说是不可接受的，软件工程可以没有人，怎么可以没有UML呢？当然不否认UML在某些情况下的价值，但对UML的顶礼膜拜大可不必。UML只是一个工具而已。requirements methodology 是需求管理的工具，UML也是，工具嘛，使着顺手又有效率就可以了，管他是什么UML呢！
• Using a development methodology was a success factor, especially when it was "appropriate to the application"
  • 无论采用什么方法，总得有个方法，这个方法会指导项目成员做事的方法、过程，统一团队的行动及标准。其实无论成功或失败的项目，都有其开发方法，即使完全没有所谓的methodology，那也是一种methodology
  • Methodology没有好坏之分，但在具体项目中是否有效是有差别的。各种开发者论坛里经常有Methodology之争，这个说要遵守严格的瀑布模型，那个说不应该守旧，应该用Agile，其他人则有Lean、Rup等等，公说公有理，婆说婆有理，谁也不让谁，都说自己的是最好的，其他人的是错误的。其实这和瞎子摸象一个道理，大家说的都对，在自己的项目环境下，他们所坚持的methodology都是有效的。
  • 每个项目应该以自身的特点选择methodology，开发一个用户社区网站和开发航天飞机系统软件当然不需要用同样的methodology，好比杀鸡不用宰牛刀，宰牛当然也不能用杀鸡刀。
  • 选择methodology一定要大家公认的methodology吗？当然不需要。更有效的做法应该是在每个项目开始前和项目组成员一起根据情况自己制定一套methodology，这个methodology独一无二，也许其他人不理解不认同，但只要项目组成员一致认同就可以了。遵守自己的methodology，让别人说去吧：）
  • 法无定则，随需应变。盯住目标，关注环境变化及上下文。
• Very few projects use risk management, and those that do rarely manage those risks
  • Risk永远都会有的。对于可预见的risk可以未雨绸缪，甚至立下制度，而对不可预测的risk也无需那么战战兢兢。如果不能提前知道山上是否有路，又必须越过这座山，而不能绕过，那么就相信“车到山前必有路”好了。
  • 可以在项目过程中把各种risk收集到一起，关注可以采取什么行动可以mitigate或者remove这些risk，追踪这些行动执行情况，及时update这些risk状态。
• Post mortem reviews are rarely held, and when they are it is almost always on successful projects
  • “失败乃成功之母”，这句话从小至今作文中无数次提及，人人熟知。但“成功之父”在哪儿呢？应该是对失败的反思。如果不能对失败认真反思，何谈吸取教训走向成功呢。
  • 每个项目（无论成败）过后都应该举行反思大会，根据目的不同，可以分几次举行，每次相关人员都必须出席。会议上回顾本项目做过了哪些事，哪些效果好需要继续保持，哪些效果不好需要改进，哪些无须做，哪些没有做而应该做等等。每个人畅所欲言，最后总结。作为项目介绍的一个反馈环节，可以对下一个项目很有帮助，对项目组成员也是一个学习改进的机会。
  • 时间比较长的项目在项目中适当的时候也可以举行。
• In the U.S. (but not elsewhere), developers are involved in project estimation only when there are poor requirements (Verner speculated that this is because the powers that be were looking for someone to blame!)
  • estimation一般由最了解项目的人来做，是否必须由developer来做倒是不一定。
  • 鄙视寻找替罪羊行为！

And the predictables?

• Success comes from a culture that investigates and deals with problems
  • 每个项目都会有问题，要想成功必须解决问题。解决的必要步骤就是investigation，了解清楚后根据情况提出解决方案。
  • 问题解决文化是一种不畏惧问题、不躲避问题的文化。
• The vision for the project (its business goals) must be shared among all project personnel, especially the project manager
  • 让团队成员都清楚项目的vision或目标，看似很明显的基本原则。
  • 实际的项目中经常是：不知道项目vision的PM有之，不知道项目vision的成员也很多，这往往给项目的进行造成很多麻烦，但实际情况就是这样的。
  • PM往往认为自己不需要懂技术，进而对于项目做什么、做成什么样也不去了解，或没有能力了解。最终往往变成schedule的recorder。
  • 很多成员认为自己只需要知道自己的那块任务就可以了，对于整个项目无须了解，也懒得花功夫。最终很多人只知道自己的任务，而不知道自己的成果对项目的作用何在，不能从全局考虑问题，埋藏很多bug而不自知。在这样的环境中，各种review机制很难执行，因为大家对其他人的工作没有足够的了解。没有vision的成员也很难获得成就感，很难打造一个强凝聚力的团队。
  • 解决这个糟糕局面只能靠一个或几个“操心”人，掌控大家的工作，粘合到一起，面面聚到。对这些“操心”人就一个字：累！
  • 解决这个问题：
    1. 成员努力了解整个项目的vision，不仅仅有这个权力，更有这个责任。
    2. 创造机会让团队参与vision的设定与维护。比如重要的会议让全体成员参与，其他会议的会议记录放在公共的地方或发邮件给全体成员。
• Project managers should be involved in the estimation activity
  • PM往往由于认为estimate是技术人员的事，往往只拿到最终结果。
  • PM需要知道项目要做的几块事，需要了解大体情况，和相关人员一起estimate是一种必要方式。
• Project managers should be good at customer and developer communication; they need not be good at the technology
  • 和用户沟通中的相关技术细节可以指定一个技术负责人和用户沟通，SE当然可以。 
  • 还是那句话，PM还是需要懂一点技术的，虽然不需要good at，至少要有共同语言。

There was some interesting data from the study, as well:

• 60% of organizations have no process to measure benefits
• 86% of projects had a business case, but 60% ignored it
  • 结合市场可能是大家都知道的，但大部分仅仅停留在口头上，没有好的措施来在行动上也保持对市场的关注。
• 33% of projects said they had no risks, but 62% of those failed
  • 身在祸中不知祸，只缘身在项目中！ 人总有一种盲目的乐观。
• 49% or organizations have had (one or more) project failures
  •  可能有90%的组织或公司会否认这点。他们的确大部分项目都完成了，产生了软件。但这些软件是否在用户那里运行的很好，和客户预期相符或超出预期？问到这里估计就“顾左右而言它”了。当然这条的failure标准下面是有的。
• In one-third of the projects, the project manager had no say in schedule/budget targets
• 75% of projects were underestimated, none were overestimated
  • 同样的原因，人有盲目乐观的倾向，对困难会预计不足。同时，随着项目的进行，用户的需求会逐步细化，并且越来越多，很容易失控，一开始的估计不足也就不足为怪了。
  • 从本人的经验了来看，也有同样的问题，一般我的估计*2是比较符合实际的，所以有时候不得不在最初估计之后再乘一个系数:(
• 5% of projects had no project manager; 16% changed project manager at least once (and that was correlated with project failure)
  • 有没有正式的PM这点不重要，关键看有没有人负起这个责任。小的项目没有必要设置一个专职的PM，可以兼任。
  • 在项目过程中换PM是比较忌讳的，尤其是PM参与项目的越深入，换PM带来的影响越大。PM往往决定了这个项目的运作方式，甚至一下methodology的选择。无论对国家还是对项目，政局不稳都不是好事。

Verner also asked developers what their criteria were for project success. They said:

• They had a sense they had delivered a quality product
• They had a sense of achievement
• They had enough independence to work creatively
• The requirements were met and the system worked as intended
  • 这些标准也挺有意思，来自于developer，而非商务部门，如果换成商务部门，肯定就不是这样的标准了，相信成功率也会提供很多，因为他们关心的是有没有赢利。而很多项目的确赢利了，但对于developer和客户来说，这样的项目还是失败的，因为这些项目或者没有给developer带来成就感和自信，或者没有给客户带来价值。

当然，上面的数据收集过程以及数据分析方法是否正确无从知晓。数字能说明很多问题，也有很多问题无须数字说明或数字说明不了。无论怎样，实践检验真理，在软件项目管理上，这点是没有错的。

教育之道在以身作则

《动物世界》里的非洲好像是世界的动物园，并且可以算是野生动物园，动物们自由地生活在野外而非铁笼子里，因此，在非洲的动物是幸福的。

非洲人呢？他们幸福吗？从小时候的课本中可以看到的非洲是饥饿的，儿童个个骨瘦如柴，大大的眼睛看着你像看着美餐一样。看到这里，有怜悯之心的共产主义战士们应该都会想：“可怜的孩子们，水深火热中的难兄难弟们，坚强一点，我们会尽快去解放你们的！”。如此，则党国之苦心没有白费。

然而，真实情况如此吗？从其他渠道了解的非洲好像不那么饥饿。并且非洲兄弟好像过得也挺自在，没钱了就全世界借，借了也不用着急还，一般拖个几年也就不必还了，比如说中国每年把非洲兄弟召集进京，到时候俺们的领导人一高兴就赦免大批债务，并且还会提供新的援助。因此，日子过得虽然紧吧一点，但比较逍遥自在，据说一般非洲兄弟上班的特点是挣到一些钱就不干了，等没钱了再过来，完全是“今朝有酒今朝醉，管它明朝不明朝”的境界。如果是农民，能靠树上的果子生活下去就不会出力去垦荒种田，顶多撒点种子，然后就到收获的时候来看看，靠天吃饭。因此，和自然的关系，那就一个词：和谐！所以，才保存那么好的自然环境，成为动物天堂。

不过，这人和动物混居，想像着挺美，实际情况怎样呢？简陋的木棚外整天有狮子、豹子等大型食肉动物溜达，万一要是它们饿急了不讲哥们义气，把人当成点心就惨了。这个担心不是多余的，还真有这样的事，狮子攻击人，当成食物。不过节目中说一般的狮子是不吃人的，默认状态不把人列在菜单上。但如果有一头狮子某一天突然有尝螃蟹的大胆想法，并且付诸实践，发现味道还不错，并且容易捕捉，那么这头狮子就不会忘记人的味道。如果这头狮子所在的狮群还有幼狮，并且也参与或目睹了捕猎过程或分了一杯羹，那么这些幼狮也会记住这个场景或这个味道，以后就会把人列入捕猎名单。太可怕了！

又有一个介绍人类孕育的科教节目，一个研究者每天给孕妇吃茴香味的糖果，等婴儿出生以后发现婴儿对茴香味有明显的偏好。据解释说是因为胎儿可以通过羊水共享母亲的食物气味，并会喜欢这个气味。因此，母亲的饮食喜好会影响到出生后的婴儿。很奇妙！

上面的两个事情有一个共同之处，那就是后代的行为会受上代行为的影响。这个不奇怪，没有人否认这点。但具体到行动时，大家好像却又忽略这点。

和上面两个例子类似，看看孩子的教育。在孩子的教育上，父母操透了心，尤其是中国的父母，往往把自己没有实现的梦想都寄托在孩子的身上，更是下足了功夫，不惜代价，上辅导班、特长班、奥赛班，请家教，买学习工具等等，只要有人说能提高孩子考试成绩的，一律去做。甚至考试之前求签拜佛也不敢错过。这样的教育，还不算尽心尽力吗？可是换来的分数，总是让很多父母眼泪“哗哗”地。

为什么会这样？解释当然多种多样。哪些因素会影响到孩子的成绩？各个专家也是七嘴八舌，不知道该信谁的。不过，在《魔鬼经济学》中，作者通过分析，给出了一个令那些刚才“哗哗”落泪的父母放声痛哭的结论，那就是：影响孩子成绩的主要因素是孩子的父母本身是什么样的人，而不是孩子的父母在孩子身上做了些什么。累死累活，白忙活了，能不哭嘛！并且把心思全放在孩子身上了，放弃了自身的修行，失去了给孩子做好榜样的机会。

看来为了教育，把眼睛死死地盯在教育手段上是不够的，得退一步，从自己做起，身先士卒，以身作则！

不光在孩子的教育上如此，在其他类型的教育或领导上也是如此，不以身作则，怎能要求他人去做呢？！自己都不想做的事，其他人当然也不愿意去做。己所不欲，勿施于人！

寻找尾巴的蓝海战略

《蓝海战略》这本书没有读过，只知道是一本教人商战“和为贵”的书，提倡开创新市场而非在血腥的旧市场上继续厮杀。

这个想法当然是好的，但怎样才能找到蓝海呢？书中也许有一些好的方法，没有读过，不得而知。

长尾，就那么一条细长的长尾，可能没有海那么宽广，但谁能否认苍蝇也是肉呢？！其实虽然长尾没有那么宽，但由于其很长，所以算面积那也是不小的。所以能找到长尾也是大有收获。

如何才能找到长尾呢？

实际上长尾是不用找的，自古至今一直存在，只是在条件不成熟的时候，人们都夹起了尾巴。因此，对于长尾用“发现”一词更合适。

如何能发现长尾呢？

科技。科技的发展破除物理的障碍，因此，需求的长尾便会露将出来。所谓科技刺激（引导）需求是也！

尾巴可以再长一点！

得寸进尺，人之常情。既然可以亮出尾巴，为什么不能亮得更长一点呢？！

之所以可以不再夹着尾巴做人，大胆秀出个性的需求，是拜网络和科技之福，是网络（电子商务）使个性商品可以通过网络销售，突破了商品流通的物理限制。流通只是商品生命周期的一个环节，科技能否在其他环节同样发挥作用，助长需求之尾呢？

商品生命周期可以分为：设计生产、流通、营销、售后服务。

设计生产

人类商品的设计生产经历了两阶段：

1. 原始的手工生产，生产规模很小，只能满足很少一部分人的需求，商品的种类也少。大部分需求得不到满足。
2. 大规模机械生产，生产规模很大，共用统一的生产流程和模具，因此，成本极大地降低，大部分人都有能力购买。但品种单一，个性化需求得不到满足。

接下来呢？

要满足个性化需求，那么对某些商品的生产就很难大规模生产，因为个性的东西往往消费的群体会变小，这和大规模生产降低成本是背道而驰的，势必增加成本，使更多的人消费不起。如何解决这个矛盾呢？

目前的大规模生产都是大的公司占优势，大公司拥有更多的资源，能产生规模优势。当在网络时代中，电子商务为销售等环节扫清道路，为什么小公司或个人不能凭借自身灵活的优势参与生产呢？！相信在很多小商品的生产上会出现百花齐放的现象。

对于一些较复杂的产品，需要复杂机械生产，目前的生产已经实现部分数控、生产线等，但局限于固定的数控机械、固定的生产线和模具，改变产品的设计需要同时改变这些物理设备，成本较高。能否更进一步，实现完全的数控生产，完全从数码设计到产品的映射，比如程序控制的机器人完成一件商品的一次性生产，而程序所依据的数据是按照用户需求单个采集的。如此，则产品的改变需要在设计和生产设备上的投资成本很小。其实，计算机本身就是很好的例子，计算机并不是固定用途的机械，其功能主体不在于物理装置，而在于控制其行为的软件，软件不是固定的，是可以随需求而变的信息流。编写软件就是告诉计算机如何行为，虽然目前编写软件还不是人人可以简单进行的，但通过改变软件来改变计算机的行为要比更改硬件来得容易并且成本小多了。并且终究会有一天计算机会懂得人类语言，普通用户即可无障碍操纵计算机。因此，以后的生产计算机或机器人和用户直接沟通需求再直接生产产品应该不是梦想。

如此，个性化商品和大众化商品的界限就不会那么明显了，生产上支持长尾。

流通

《长尾理论》中主要讲的就是流通环节，在可以信息化传递的商品上，如音乐、电影等，电子商务目前已经做的很好，为长尾扫除了物理障碍。但对于那些不能通过网络传输的商品呢？如食品、家具、纸质书等，这些商品最终依靠的还是物理流通，虽然展示可以放在网页上，但运输还得物理上进行。所以在物流产业没有很好发展起来之前，很多电子商务网站遭遇失败。目前DHL、UPS等物流巨头的兴起，对于很多商品的长尾起到了很大作用。而这些物流巨头的兴起，正是靠着信息技术的支撑。相信在信息技术的支持下，物流的成本还会进一步降低，物理的距离差别可以变得越来越无足轻重，长尾可以更长。

营销

这也是《长尾理论》中讨论较多的。个性化商品生产出来了，也摆到货架上了，但由于是那么多种个性化的商品，如何让人从这大量的商品中挑出其感兴趣的呢？这也是传统手段难以解决的。

一方面是商家努力让用户知道其个性化的商品，这当然需要广告，而传统的狂轰滥炸式广告成本对于少量的个性化产品来说成本太大，效率太低，因此Google应运而生，根据用户的搜索确定其需求，精确地投放广告，可以说其简洁的搜索页上的搜索框就是其精确制导仪。

有什么东西会比Google的搜索框更了解用户呢？手机会是其中之一吗？拭目以待！

另一方面是用户努力搜寻感兴趣的商品。又是Google，提供了一个搜索框，使用户能从海量信息中搜寻感兴趣的信息或商品，并且还不失时机地帮助第三方推销产品。

其他电子商务网站的相关产品也是一件利器，在用户浏览一件商品时，就列出相似或相关产品，让用户很容易接触到那些非流行商品。

还有什么更人性化的方法能让用户找到或接触到心目中的商品呢？

售后服务

通过信息技术的支持，客户可以在需要时方便地联系商品提供者，寻求帮助。并且对于很多产品来说，战争已经从前线的产品本身转移到后方的服务上去，而服务可以根据客户的需求不同而不同，用户需求的长尾显现。当然这离不开信息技术的支持。

同时，在信息技术支持下，商品提供者在提供售后服务时，可以更容易地收集用户需求，根据需求提供服务，发现长尾。

由此可见，通过深挖商品生命周期的各环节，利用科技的力量，未来消费者尾巴再长长一点的愿望并不仅仅是一个梦想：）

不再夹着尾巴做人

不再夹着尾巴做人，有尾巴就大胆地露出来。是什么让人类如此自信？科技！

这是看《长尾理论》时想到的。当然此尾巴非彼尾巴，长尾理论的尾巴的例子如下图：

图中X坐标是商品（音乐）的销售排名，而Y坐标是商品的销售量。可以看出排名靠前的一小部分商品，即黄色区域有很高的销售量，乍看起来这些商品的销售总量（黄色区域的面积）很可观。而灰色区域代表的是排名靠后的商品的销售情况，单个来看，销售量都不高，但拖的长度很长，在图中表现为好像永远会处于X轴之上，指向无穷远处，因此，从理性判断，灰色区域面积（销售量）也不会小，这也是大家关注这条“长尾”的原因所在。

图中还指出了黄色区域的音乐在沃尔玛超市和网上音乐商店Rhapsody都有售，而灰色区域的长尾部分的音乐只会在Rhapsody上有售。由于这个差别，这部分才被拎出来作为“长尾”研究。

为什么会有这个差别呢？原因就在与在沃尔玛销售的音乐是以物理媒介作为载体，而物理媒介如磁带、CD等都受到库存、展位等的物理限制，由于位于长尾部分的音乐的销售量很低，而在沃尔玛销售的单位平均成本会大于所得的利润，因此精打细算的沃尔玛是不会销售这部分的音乐的。但在Rhapsody上就是另一番景象了，由于是在线销售，不涉及展位等的物理成本限制，销售所有的音乐的成本几乎没有区别，因此长尾部分可以继续销售下去，并有利可图。

在传统的超市中，由于长尾部分被生生切去，对长尾音乐情有独钟者的需求是得不到满足的，而在网络时代中，从网络商店Rhapsody上，长尾音乐爱好者得到了满足。

所以，对于自己的需求，我们无须再夹着尾巴做人，可以大胆地露出需求的尾巴，并得到满足。从小的方面看，满足了个人的个性化需求，从大的方面看，是对人性的尊重，网络功不可没！