读后有感，做以下摘要:
1、概要设计的时候，业务逻辑必须搞明白
2、学习的体系,激励机制；Expert排行榜,上榜人员是通过全体程序员投票选举出来的，公司将会对他们给予奖励。给予Expert称号的最大好处就是树立了在开发过程中的权威与榜样。如果有问题，可以找相应的expert解决，正所谓，闻道有先后，术业有专攻，他们既然是专家，就会对在解决相应问题的效率上和结果上都会有过人之处；同时也可以激励其他员工向他们学习，起到了模范作用；
3、SA不能与代码脱离，与技术脱离；
4、项目成员为自己的每一行代码，每一句话,承担责任。
取于http://www.cnblogs.com/perhaps/archive/2004/08/01/29176.aspx，原文如下
朝得银弹，夕死可矣（续）
[前言]：今天是7月30日，离开公司也正好一个星期。而今天也是我呆在深圳的最后一天，再过不到24小时就要踏上北上的征途了。离职之后，在深圳的窝里呆了几天，对于软件开发，尤其是项目的管理，有了一些新的想法。仅将项目中的不足之处记于此，以作日后警醒之用。
1、需求不明确；项目进行到现在，也有一年有余了，而进行需求分析和概要设计的时间也有近一年了。虽然我们有很多的文档，文档也是洋洋洒洒数千字，上万字，然而我们对于用户需求把握的程度还是很糟糕的。最明显的一点，由于我们所要做的系统第四版了，在此之前的第三版是十年前开发的。那么我们是对原有的系统进行升级呢？还是重新设计一个系统呢？我们的SA一开始都号称着要做一个全新的系统，然后都去跟客户做interview，去收集需求，可惜的是能力有限，时间又急迫，使得需求分析的结果还不足以指导进行概要设计。结果在开始做概要设计的时候，业务逻辑不清楚也没有采取进一步的措施。也不知道是谁提出了由旧系统的源代码去提炼业务逻辑，接下来公司就组织了很多SA，乃至AP去读源代码，然后根据这些源代码去写概要设计文档。说实在的，我觉得很不可思议，大家也许会说，读旧系统的代码没有问题啊。没错，以旧系统的代码作为参考是没有问题，可是如果是将旧系统的源代码直接转换成概要设计文档，我们前期做的业务需求分析不就一点用处都没有了吗？况且这样做，是不是也正好违背了做一个全新系统的想法呢？在我看来，根据源代码去提炼需求，并且做概要设计，无异于盲人摸象。缺少了整体考虑的需求分析，恐怕就是头痛医头，脚痛医脚，而人还是照样over了；
2、缺少一个完善的training和学习的体系；我觉得这是一个很糟糕的问题。虽然大家会觉得一个小型公司要建立一个完善的training体系几乎是不可思议的，可是我想说，我们必须需要这样的一个体系，即使这个体系仅仅是针对现有的项目的。因为会随着项目的进行，有人会离开，也有新人会进来，如果没有一个完善的体系的话，人员流动对于项目的影响将是非常的大。而且在促进大家去学习的过程也可以提高大家的学习能力，也能够筛选出人才来；
3、缺少激励机制；在项目当中，公司会有很多的惩罚措施，譬如会有一个所谓的红黑榜，然后只有人受罚，却没有人得到奖励。我曾多次表示反对这样的方式，因为我觉得人性总是本善的，应该通过激励的方式去促动大家努力工作。因此，我会想，如果有一个Expert排行榜，会不会更好呢？上榜人员是通过全体程序员投票选举出来的，公司将会对他们给予奖励。给予Expert称号的最大好处就是树立了在开发过程中的权威与榜样。如果有问题，可以找相应的expert解决，正所谓，闻道有先后，术业有专攻，他们既然是专家，就会对在解决相应问题的效率上和结果上都会有过人之处；同时也可以激励其他员工向他们学习，起到了模范作用；
4、SA与代码脱离，与技术脱离；这是我最百思不得其解的问题。SA是什么的缩写呢？是System Analyist。那什么是系统？我没有办法给出准确的定义，但是我想一个系统必须是为实现某个既定任务而存在的，业务需求就是“任务”，确实是最重要的。那么，如何“实现”是不是也很重要呢？没有了可行的实现手段，所有的“美丽任务”都变成了Mission Impossible了。我觉得两者都是具有相同的分量的，SA要关注需求，更要关注实现。然而我们的SA更多时候是充当着行业专家的角色，可是他们并不是行业专家。结果这个角色耗费着项目的大部分资源，却鲜有贡献。既做不了设计，又做不了coding，到了我将要离开的时候，他们充其量只是一个工头了，问程序员，“什么时候能够做完啊？”，“我只要结果”。这多么的可笑啊！SA是可以不直接参加做coding ，但是他们不能够对技术几乎一无所知，否则，他们如何做分析呢？System的组成不仅仅是业务逻辑，而且业务需求最后也转化为一行行的代码，一个个能够运行的模块啊。为什么就只有SA给大家培训业务逻辑，却没有人为SA培训技术呢？可笑！
5、缺乏诚信，缺乏敢于承担责任的勇气；在项目当中，从程序员到SA，都有一部分人员缺乏诚信。尤其是SA。我曾经听到三位subteam的老大关于保证业务逻辑的对话：
A问B：“你怎么保证业务逻辑都已经OK了呢？”
B马上说：“review代码咯。”回答得一点迟疑都没有。
C听了，接着说：“你真的一个一个class去看，一行行代码去看？”B也表示了怀疑：“你知道一个模块里面有多少的class，多少的代码吗？你怎么可能看得完呢？”
A显出一副无可奈何的神情点了点头：“没有办法啊，为了保证逻辑只好这么办啦。”
哇，我听了都快吐出来了。先不说保证业务逻辑根本就不是通过review代码可以实现的，光说A的诚信就TMD的有问题。他作为SA，首先不可能有那么多的时间将我们所有的代码进行review，而且，我也能保证他从来都没有看过，因为他根本就没有办法对我们的整个的架构说出个所以然来。还记得《程序员修炼之道》上的第一条：Take responsibility。与之相应的那一节的前面还有这样的一句名言：
The greatest of all weaknesses is the fear of appearing weak.
作为程序员，作为SA，乃至每一个做IT的人，都应该懂得承担责任，为自己的每一行代码，每一句话。我想这是做程序员的最基本要求吧。
[后记]：今天是8月1日，随笔终于都写完了。一部分是30日写的，而大部分则是在北上的大巴上写的。离开了，放弃了，然后徘徊了，痛心了，最后惊醒了。到了一个新的地方，期待着新的开始。写得不当之处，还请各位多多批评。
