研发过程

谈谈活动发起能力

这里说的活动发起能力，说的是当你需要推进一个新的事情的时候，你会如何推进这件事情，使得团队能够接收？这一点是如此的重要，因为，这个能力决定了你是否能够把你的想法落实在实际操作中。

最简单的活动发起能力，无非是强制执行，对一个颁布的新的做法，给予一个公开的解释，然后安排人员进行Check，对于不按照此流程操作的人员，给予强烈的负面反馈，使得团队按照自己的想法来往前走。如果你希望尽快地落实一件事情，这种看起来非常粗暴的做法，也能获得比较不错的结果。但是这种做法未必是最有效的，他看起来有效仅仅是因为这是最容易进行操作的，管理者也相对来说更省心。但是，说他不是最有效的原因是，这种做法依赖于强烈的压力，使得团队成员按照自己的做法来做。支持他的观点认为：依靠着团队执行某一个流程，然后发现流程的好处，把这个流程转换为自身执行的流程，那时候将不需要过于多的监控。但是从现实工作的情况上来看，这种现象似乎并不是很多。如果你所有的流程都是如此来监控，一方面使得管理成本急剧上升，另外一方面，压制了团队自我的创造力，因为团队已经习惯于在一种高压下进行工作，并且使得他们觉得任何对现在流程提出改进的做法，都面临一个风险，那就是你企图不执行流程。这一点如果扩展开以后，将使得事情很难操作。管理者过于忙碌，而且觉得团队很难管理，同时团队觉得自己象一个小小螺丝钉，没有太多的主观能动性。这是一个必然的后果。而且，相对的来说，这种做法是不能持久的，当压力被慢慢消除的时候，团队会放弃这种做法。

其实，我们来想一想，为什么某一些做法能够得到团队成员几乎全部成员的支持（比如尽量好一些的版本控制方式），但是某一些过程不是呢（比如强制需要团队做出尽可能详细的设计文档，然后再进行编码）？这一般来说有两个原因，第一，目标本身就存在着问题，这种目标并不能解决关键性问题；其次，做法是存在问题，推动能力不够，使得这种做法，包括价值观和具体的操作方式没有落实到整个团队的核心中，将一个相对Lone-team的时段中，团队自动排斥了这种做法。

那么，我们举一个例子，我们希望达到这样一种做法，项目经理尽量详细地制定一个任务所要达成的目标，而允许团队成员对自己的工作分配提出异议。这种做法一方面强化了项目经理的工作，因为他再也无法通过一种若有若无的，以及临时性的任务分配，来完成对于团队成员的工作安排；另外一方面，需要加大项目经理的沟通难度。如果某一些人员对分配给自己的任务表示不满，项目经理需要有说服能力，以及任务的一些修改，来达到双方之间的认同；同时，他将使得团队成员真正认可自己的工作目标；并且需要项目经理对于工作任务无法完成的人员进行一些反馈等等。这看起来执行起来，会加大很多项目经理管理上的难度，但是他的优点是：过于慷慨的承诺将将被小心的承诺所取代，工作更加有序化，团队之间工作的关联性，将在其中得到了强化，团队成员对于项目的进展更清晰等等。同时，项目的模模糊糊的进展将被一种相对来说更明晰方式表现出来，使得我们对于项目进程更可控一些。

那么OK，也许我们会发现，这种做法上事实上面临几个压力源，比如项目经理是一个压力源，因为这将削弱项目经理的权威，并且加大项目经理的工作强度；对于团队成员来说，他们相对地来说会比较喜欢这种做法，因为这强化了他们对于工作的控制性，并且使得自己的工作相对来说更加清晰。

如果我面临这个流程的推进，我将会采取以下一些做法，来推进这项工作：

首先，我需要摘取一些历史数据，通过一个能够让全员知道的方式，公布出来。说明我们任务目标不明确，所面临的一些困境，说明这个问题，到了需要我们改变的时候。而如果我们达到了任务目标明确性的做法以后，将会获得好处等等；如果我有部分时间来推进这个流程的话，我不会抛出我的观点，因为我不希望自己的观点来影响其他的人员。而且，未必我现在的做法就一定是最好的做法，我们仅仅是为了达到这个目标而已。如果大家能够提出更好的解决方案，我有很大的动力，来采取别人的意见；

其次，我会寻找部门中的PM以及一些核心员工进行一些私下里的沟通，我相信一点，大多数人的看法大多数都是类似的。所以，我相信我们的PM和核心开发人员一定也会提出和我类似的，甚至更好的解决方案。OK，我不希望出现一点情况：认为这个方案是管理者想出来的，大家都不敢批评或者提出异议。如果他们认为这个想法是自己提出的，一来他们会更容易执行，第二，他们发现流程中有不完善的地方，也没有太多后顾之忧进行改进（呵呵，改改自己的说法，总比修改老板的要求要简单一些吧）。好了，进行这个步骤，主要有两个目的：群策群力，找到一个更好的解决方式；第二，让员工参与决策，便于将来的操作。这个阶段产出的主要内容是操作方式，和考核方式；

推进方式出来了以后，我们会找一个项目（而不是所有的项目）进行试验，在某个时间段中，推进这个流程，然后，按照我们当初确定的考核方式进行考核，看看流程推进得如何。

推进了一段时间（一般来说是1个月到一个半月的时间），然后我们进行一次汇总。从操作者身上来了解一些反馈。针对这个例子，我们可以从PM身上来了解工作量增加的程度，可以了解对于目标推进的作用；从开发人员身上，主要了解这种做法，对于工作是否有一定的帮助作用。然后我们综合考虑利益和成本，看看这件事情是否值得去做。如果值得做，那么成本方面是否有可以削减的地方？因为不管我们干什么，毕竟我们只是为了解决一个问题而已，没有必要把所有的问题，都企图在一个解决方案中解决掉。这样容易导致过于繁杂的流程。

然后，了解了情况以后，写一个介绍情况的PPT，让几个典型人员进行介绍。我的推荐是是让各个利益体方面都来说一说，比如开发人员会赞成这种做法，毕竟这种做法不会增大自己的工作量，而且明晰了自己的目标，但是对于PM来说，他会关注这件事情的价值和成本的关系。对于大型的项目来说，也许成本会增加到一种不可操作的层面，我们需要进行组织结构分层来支持这种流程（但是如果仅仅是为了推进这个流程，是否有必要进行组织结构的分层管理，也许那样做成本太高了，而且未必效果就一定好，风险也很大）。类似的，我们的PM和开发人员会为此进行一个讨论，并且修整一下流程；再投入多一些的项目推进。

在整个流程推进过程中，我们会尽量多得采用正向激励，当某一人完成这项工作比较出色，我们需要尽快得给予反馈，并且给予奖励。如果完成得不是很好，我们会推进一下，但是不会因此去批评得太多。

当整个流程稳定下来以后，我们会更多的使用负向激励。只要一个规章制度在那里，就是需要执行的。如果效果不好，随时反馈，我们会按照需要进行修改（绝大多数人都自认为是这样的，但是请大家想想一点，在去年一年的时间中，你采纳了多少别人的建议并且修改了流程？如果这一点很少很少，那么你说让大家反馈，实际上就是一句空话了）。

在推进的时候，我不喜欢一开始就非常复杂，徒劳地增加了很多工作量。因为那时候，我们也许有很多事情根本看不清楚。一件事情要开始做，最重要的是：我们需要起步，然后再改进。如果一开始就有一个很高的门槛，会使得起步很困难。这样的话，推进真的很困难啊。

而且，我喜欢一种讨论方式，不是那种纯粹学术上的。比如理论上说来，任何决定和任何信息，都记录在文档中，是一种最为保险的做法。因为他至少从理论上，能够提供任何回溯。但是这种事情绝大多数不可操作。是因为成本太高，以及实际上产出很少（大家可以去想想大家看见的需求文档，有多少是符合现在项目的？）。而且，这些成本在执行过程中，被流程制定人员大大低估了，我们总是认为，如果你每做一个改动，就修改一下文档，那么工作量不会很大。只有你一次性修改的时候，成本才会很高。

可以比较明确地说明一点，这种观点是错误的！在开发过程中，发现一些改变，然后对其中内在逻辑联系是依靠人员来维护的文档体系来说，这种做法的成本是极其高昂的。因为你打乱了开发者的思路。而且你认为提笔就修改的地方，有时候实在是太多了，以至于我们淹没在文档体系中。逐步修改，并不是能够极大的降低成本，只是把一次性成本投入分散在整个过程中去做而已。当然好处是，这使得开发人员能够真正去重视和有信心去维护一份文档。老是阶段性的大修改，使得人员对维护一份文档的正确性越来越失去信心。

软件管理流程，说白了最大的一个问题是：我们总是提出一整套的理念和解决方案，但是没有辅助手段去进行操作。说要什么文档很简单，但是有多少PM能够告诉我，某一份文档，在项目中维护，需要多少时间？至少我直到现在没有在一个Project的人时规划中，看见过一个项目经理，去留下足够的人力和时间去修改这些设计文档和需求文档，仿佛这些文档是可以自己更新完毕的（在CR过程中，倒是有的）。

所以，多听听手下人的抱怨，并且想办法去改变。而不是一切都归咎在他们的执行能力上，在实际工作中，总是比较有效的。

我举一个例子，说明一下某一项工作的工作量。当然，以下的情况也许绝大多数开发团队没有碰到的。我们都知道，需要在系统运营过程中，根据实际情况，去做数据库优化，以及数据库索引的建立等等类似的抉择。我们一般来说，对于这项任务分配的人时大约是100-200人时就很不错了。但是，如果一个真正需要认真进行这项工作的团队来说，需要10多个优秀的DBA持续进行监控和调优工作。如果你没有这个觉悟，那么就不要提出太理想化的流程，真的很难操作的。

在考虑流程和推进的时候，考虑考虑成本！考虑考虑执行可能性！

最后，我想说两个例子，来说明另外一种理想情况，当然这是另外一种理想情况，暂时几乎还不可能达到。但是这里写下来，只是为了让大家多一些其他的思路。有时候，简单的做法收到的效果要好的多。一次性成功的做法，在面临越来越严厉的环境下，将变得越来越不实际。

第一个例子：我们有一片很大的草坪，他如此地大，以至于我们必然要在里面设立几条道路，让别人走。但是我们不希望大家从草皮上走过去。粗暴一些的做法是：每隔20M设立一条路，然后在每个路口都设立一个牌子“禁止践踏草皮，违者罚款5元”。但是我们常常发现，很多人还是从草皮上走。于是我们就觉得：唉，这些人的素质为什么如此地差啊。只有20M的间隔，为什么就不能走上一小段呢？为了解决这个问题，我们设立不定时的检察员，去抓这些人员，但是仿佛总是抓不胜抓啊。这一点很讨厌（也很常见吧！想想为什么城市里面有那么多人翻越道路栏杆？因为两个能够给行人通过的路口之间有2站路，不然你去走走？恐怕自己都做不到吧！）。理想一些的做法是什么呢？我们先铺一整块草皮，然后让大家在上面走，经过1个月时间，上面自然会留下一些道路，这些道路是最多人踩的路。然后我们就知道，大家通过这个草皮，在最多情况下，是要到哪里去，然后我们就在自然形成的路上，开辟几条固定的道路出来，让大家去走。其他地方被禁止。虽然这种做法还是无法最终避免有人践踏草皮，但是相对的来说，我们需要监控的人就少了很多。一个流程应该是一个大部分人群能够执行的流程，我们去改进少部分人的做法而已。如果一个流程，需要管理者监控几乎所有人的工作，这实在有点过于难受了。

第二个例子是蚂蚁寻找食物的路线形成。蚂蚁一开始不知道食品在哪里，然后他们就外出四处寻找，这走过的路线将是很乱的，蚂蚁会在走过的道路上留下一个嗅觉的痕迹，然后他会沿着原路返回。并且告知其他蚂蚁：“跟我来，我找到大个的屎壳郎了！”。其他蚂蚁会沿着这条嗅觉去进行搬运。同样的，他们也会留下嗅觉痕迹。如果到那个屎壳郎的距离比较长，那么那条路上的蚂蚁就会回来得比较慢。如果距离比较短，就会回来得比较快，相同时间中，走过这条路的蚂蚁往返的次数就比较多，留下的痕迹也就比较浓。更多的蚂蚁将会吸引到这条路线上来，于是一条相对来说比较短的道路就形成了。这个过程仅仅依靠一个最简单的规则“寻找一条味道最浓的道路”。仅此而已，我们就能找到最短的道路。而如果我们企图依靠命令-控制这种方式，那么我们将使得问题复杂很多很多了。其实，这个例子在现实生活中也很常见，比如在公司升迁制度。公司的高层通过升迁制度，挑选适合自己企业的人员来进入中层，同时中层也使用同样的做法来挑选底层管理者。员工通过观察管理者为什么会得到晋升来衡量自己的做事方式，逐渐使得整个企业都具有一个很深厚的价值观和文化。但是，相对得来说，我们在公司升迁过程中的观察，并不是那么明确，因为很多东西在里面，你需要判断，到底哪些是关键点。这一点相对来说，就比较复杂了。但是，无论如何，这也是类似的。同样的，这就是为什么我们在流程初期大量使用正面激励的一个原因。因为这会明确告知大家一个信息，这是一条得到大家赞赏的路线。

呵呵，说到这一点，MPA的案例中，倒是有不少例子，来说明在政务中的一些做法，对我的启发还是比较大的。得空，大家可以去看看，的确还是不错的。你能够更多地从一种“命令－控制”方式，转移到一个“领导-反馈”的模式中来。而后一种模式更适合于将来。

好了，说了不少了，之所以指出一些流程本身的问题，是因为如果你需要增强你的活动发起能力，你需要首先保证你发起的不是一个烂东西。比如你发起一个活动“让大家把月薪的10%交给直属管理者”。你认为发起这个活动的结果是什么？我不看好！

OK，有意识地去锻炼这些能力，将使得你的工作事半功倍，不然，你就等着忙碌吧。

谈谈人才培养

人才依赖于外部空降还是依赖于内部培养，这一个问题不能一概而论。自己培养起来的人员相对的来说，对企业文化等方面理解比较深刻，和企业更容易丝丝入扣，但是新的思路不容易建立。而空降进来的人员，会快速带起一个团队，但是需要解决一个是否和企业适合的问题。这两点都很讨厌。

但是无论如何，都需要面对一个人才培养的问题。对于一个软件团队来说，产品的产出固然重要，但是至少同等重要的是，培养出来一支具有战斗力的团队。这支团队将在下一个项目中做得更好。一个管理者需要在这方面下更大的功夫。特别是承担People Manage工作的人员。

首先，先讲一个笑话，放松放松。事实上，我也亲身经历了这种过程。这是一种对付刚刚进入公司的新人，好像有个名词，叫做“蘑菇疗法”。说的是，刚进入公司的新人（特别是刚毕业的学生），管理者会把他往一个黑暗的角落里一扔，然后不时给你浇上一盆子“生物化肥”（就是大粪啦！），放这么个2-3个月。这种员工就会给培养成一种工作饥渴症。具体一点的做法是：就是找个角落，给你一台烂机器，然后开会的时候叫上你，平时也没有什么事情干，但是不允许你上班的时候干和上班无关的工作（也就是说，你实际上，就是闲着，什么都没得干）；然后，即使给你一些工作，也没有人给你任何的指导，就是让你这么自己胡乱做，然后干得不好，就是一顿批评；然后再闲着。很难受的。我经过了这样的疗法，大概有2个月。不知道他们是故意的呢，还是无意中如此干的。

突然有一天，一个项目经理对你说：“别歇着了，和我一起干项目吧！”，那时候，让你干什么，你都很拼命，而且这种害怕再次回到黑屋子的心理会不时影响你，使得你总是在一种工作渴望中。这种员工一般来说，工作会比较认真，而且危机感比较强，比较好使。但是这种员工，将来也需要再次教会他，不要去承担太多工作。呵呵。不过那是很以后的事情了。暂时还是很好用的。

不过一直觉得这是一个挺损的着呢。我直到2000年，才知道有个这种疗法。

用这个作为开头，来说人才培养，好像有点过分，但是，这也是培养的一种方式。

好了，下面开始说正经的了。

人才培养，首先你必须能够辨识出，什么人具有这样的品质，将来能够走得比较好一些。值得你给予他更多的机会。

联想有一句话，底层员工需要责任心，中层管理者需要上进心，高层管理者需要事业心。也就是说，如果一个人连基本的责任心都没有，那么是不值得去培养的。技巧方面容易培养，但是这种价值观方面的东西就不容易培养了。所以，一般来说，你还是对没有责任心的人省省心好了。

另外，人才的判断是一个很主观的东西，比如有人喜欢踏实工作的，有人喜欢头脑灵活的，这都不好说一定如何如何。但是基本的责任心这一点没有什么可说的。如果不具备，就走人！

在现代社会中，对于个人来说，最稀缺的资源是什么？我觉得是机会！我们说培养一个人员，是指给他更多的机会，去尝试一些更多层面的工作。这里面隐含着两点：首先你得到了一个犯错的机会，在你主管的心目中，他是有把握做好这件事情，也许已经准备了若干后手的，即使你失败了，要么这个错误是他能够Cover住的，要么是已经预留了牛牛，在后面替你补位；其次你得到了一个直接锻炼的机会，如果你的主管明白事理的话，在你不出很大错误的时候，是不会太多干涉你的。

所以，对于管理者来说，决定把机会给谁来做，是很重要的。对于一个员工来说，如果你突然接到一个超出你职权范围的工作，请加倍认真对待！

一般来说，对于软件行业来说，对于一般的员工，一般我们会提供三种机会：参与一个大型系统的框架设计工作；以及具体负责一个2-3人团队的微小型项目；或者提供一种给客户演示等等的机会。

一般说来，如果是承担框架设计工作，我们主要从以下几点进行考核，设计的感觉；思维的慎密程度；是否具备快速成长的能力，以及设计的落实能力等等，都是如此。这时候，我们一般会讲一个总体设计思路，然后让他逐渐展开后面的设计，看看他是否能够把总体设计思路贯穿下去。如果能够很好得贯穿在整体设计中，这样的人员我们会觉得没有看错。

如果是作为项目经理，我们会主要从项目管理过程上去看。这不是说要你把所有的流程都认真一点一点做下来，对于这种微小项目，实际上也是不必要的。我们主要会看以下几个方面：人员工作的安排是否恰当和及时；工作任务安排是否恰当合理；在碰到人员冲突的时候，应对冲突的能力如何；一般来说，如果第一个项目中，人员工作安排方面做得不错，就算可以了。但是如果团队内部怨声载道，那么我们可能也会考虑得更多一些，下次需要更谨慎一些。

如果说是面对客户方面的，主要看面对客户是否能够正常发挥，以及是否能够对客户尊重和换位思考。在技巧方面以后可以培养，但是这些最基本的认同方面，我不希望也需要我们花很多时间来培养。

以上是给予初始机会的一些人员锻炼。

事实上，在日常的工作中，我们来培养人员，不仅仅是提供一部分机会，在日常的工作中，我们也会持续得加以培养。比如在价值观方面，在硬性技能方面，软性技能方面都会持续的给予关注。

这就需要提到一点：学习氛围了。由于IT行业的知识更新换代的周期非常快，那么人员的部分知识在迅速地老化，特别是对于研发人员来说，知识老化的比例和速度会更快。那么如果我们希望在IT行业中长期工作下去，一个合适的团队学习氛围就是必不可少的。

我对于一个好的学习氛围的理解包括两个方面：首先是一个大家能够乐于和愿意接受新知识的一个过程，第二是团队气氛允许团队成员犯错，并且把这种犯错当作一种提高的过程。

首先，我见过很多公司，都在抱怨，我们的开发工程师为什么不喜欢学习啊？他们的素质不如其他公司的高。但是，我的理解是，这个现象的出现，公司至少要负80%的责任。因为如果一件事情发生在个别人身上，我们可以认为是个别人的问题，但是如果一个问题发生在绝大多数身上，我们还是仅仅批评素质问题，就多少有点不恰当了。应该还有一些其他的事情可以帮助这个问题的解决。

比如，我们是否给予一些恰当的时间来给予员工学习。不要把个人的学习都看成一种员工应该进行的课后作业，都需要员工占用自己的时间，来进行这方面的学习。这一点是比较困难的，而且还比较难以落实。当然了，员工都是成年人，如果他们希望自己的职业生涯将来更顺利一些，工作之余进行的各种课后作业，是需要的。但是，这一点我们无法要求别人要如何如何做。举一个例子来说，你每天让员工满负荷工作8-10小时，加班是家常便饭，然后期待于员工在下班之余，再通过浏览网站等等，来获得新的技术信息，你觉得这种事情能够长久吗？不要说：我就是这么干的，为什么我们的员工不能这么干！每个人对于生活态度都是不同的，你认同生活方式未必就是别人所认同的。这作为个人修养值得敬佩，但是用来对一个团队做要求，多少有点不近人情了。你还需要有更好一些的做法。比如，适度地给予一定的时间，来进行学习。程序员团队，绝大多数人员都有一种完美倾向，他们都希望能够使得程序看上去优美，但是太大的时间压力，使得很多人采取了一种近视的做法。

其次，公司是否乐于对新的内容进行一些尝试。如果我们认为所有新的知识，都不值得尝试，那么员工的学习将变得一点意义都没有，我们总是被动的。

另外，如果需要尝试，那么就必须有一点觉悟，可能会出现一些错误成本的。并不是所有的新知识都是无风险的，如果一个团队对于错误的认同是一种不能容忍的态度，那么任何新的东西，在这个团队都将无法推行开，因为大家会倾向于采取保守的态度。那么所谓学习气氛的加入就变得多少有点苛求了。

那么如何评价错误的接受程度呢？我的理解是，如果我们希望错误尽量少发生，那么必须有一个觉悟，就是必须给予他尽量多的资源来进行这项工作。如果缺乏这一点觉悟，而且在任何点上都需要不发生任何错误（比如，常用的借口是“细节决定成败”，这是一句绝对正确的废话，事实上，所有东西都决定了成败），那么员工将工作在极大的心理压力下。我的判断依据是，在外部的工作，我希望尽可能不要发生错误，所以对于这些内容，需要投入尽量多一些的资源，比如文档需要经过2个人以上的阅读等等。并且对于重点章节，需要安排一些会议来Review。保证正确性。

好了，多花一些精力在这方面，如果你的团队能够建立起来学习气氛，那么很多事情会比较容易展开。

最后说一点比较好使的方式，一般来说，开发人员有一些特征：比如一般来说，他们不善于一种主动的沟通（但是，作为管理者，如果沟通氛围没有建立起来，你不可以用这个作为托辞，沟通是双向的，所以你也需要努力往这个方向上走）；他们一般都相对有个性；其中有不少人对于个人的职业生涯规划思考得不是很多，所以会不时发生一些职业生涯的忧虑，这些忧虑有时候会促使他们做出一些快速的，从纯粹理性的角度来说比较冲动的举动（呵呵，这一点有时候，我也会如此啊）。

一般来说，我会如此来做。每隔一段时间，和开发人员进行沟通，来交流他们的职业发展。一般来说，技术人员的将来发展方向无非以下几类：管理方面、专业方面（比如项目管理领域，比如框架师）、或者跨市场和技术方面的行业咨询等等人员。大致如此，当然还有其他的出路。这里就不详细说了，因为这和具体的分析没有什么关系，你自己来考虑好了。

然后，你可以询问技术人员，他们希望在5年或者10年以后成为一个什么样的人。在这里你可以形容一些将来职业生涯中可能达到的一种场景，来做描述。比如对于项目管理来说，你可以说：“在将来，你可能空降进入一个公司，带领一个30-50人的一个团队，在半年之内带领你的团队，和10个左右的合作伙伴进行合作，建立起来一个全网业务的构建。”如果对于框架师来说，你可能说：“我们面临一个业务系统，基干数据量在T级别，每天访问量在1000-2000万左右，对于这样一个业务系统，我希望能够稳定运行，并且访问速度比较快，你准备如何做？”类似的等等。当然，我们清楚一点，我们在成长的过程中，未必什么都是如我们所想的，将来可能会发生一些变化，但是无论变化是什么，我们还是建立一个目前的职业规划，总比没有规划比较好一些。

然后，可能你的下属会告诉你：我希望将来成为一个很好的PM。能够带领一个大型项目。并且按时、按质完成项目。同时，做一个能够让很多人所使用超过3年的软件。

OK，我们得到了一个目标。下面我们就开始分解了。一般来说，当一个职业目标建立以后，我们会发现支撑这个职业方向的N个能力体系树。比如如果要成为一个好的PM（指纯粹意义上的PM），你需要精通PM的过程管理，你需要是一个好的人员管理者，你需要精通沟通技能，等等。然后如果需要，我们会分析一下，在这些技能树（当然，你可以划分得更细一些，比如把项目管理划分包括成本管理，风险管理等等在内的9个管理体系等等，这方面我不展开说了，自己参考PMP资料）中，你的优势在哪里，你的劣势是哪些。然后，记住这几个点，然后只要有机会，就给他介绍一些这方面的朋友，或者有意识地让他锻炼这方面的能力。

然后，过一段时间，回来看看这方面能力的一些锻炼是否适合他的性格，兴趣。看看这段时间是否有长进等等。让员工感觉自己的能力在提升，并且在工作中得到提升，是非常重要的。也能激发他的学习热情。OK，大家看着办好了。

团队组建的几个要点

OK，团队组建起来了。团队管理的东西太多了，多得几乎每一点都值得去写。但是最根本的，我认为无非3点：

1.          团队目标；

2.          团队规则；

3.          团队的文化；

下面展开，结合一些实例来说明吧。

OK，任何团队都需要一个目标，一个没有目标的团队，就象乡村俱乐部，仅仅是一堆人的聚会而已。没有太多的价值。目标能够使得我们在判断各种问题的时候，有判断的依据。如果缺乏一个目标，我们如何做都是对的，那如何还有战斗力啊？举一个例子来说，我们的目标是开发一个中间件产品，那么在作判断的时候，就相对比较简单了。比如，有个开发工程师过来告诉我，我们漏了一项东西，就是第三方接口的验证程序，如果缺少这个程序，等到我们的中间件和对方对接以后，出现大量问题的时候，排错成本很高。如果这是一个严格的中间件产品，而且我们的产品将要推出，那么没有什么可说的，即使开发难度大，成本高，也是必须去作的。但是，如果这个中间件目标是给我们的系统使用，那么这种验证程序，暂时是没有太多必要开发的。如果缺乏目标，这种问题会纠缠我们很多时候，公说公有理，婆说婆有理，实际上，问题的根源不是谁对，而是我们的目标是不明确的。顺便说一句，我在2000年的时候，非常惊讶于一些资深的管理人士能够迅速做出一些我认为很难处理的问题的决策。但是我现在至少明白，他们的心目中拥有一个非常明确的目标，并且有一条价值底限。用目标来衡量这件事是否要做，用价值底限来防止自己做出出格的决定，这样他们的决定也许不是最好的，但是大致也是不会错得太离谱的。这一点是如此的重要，以至于我决定在下面独立写得更详细一些，这里先放下，继续我们的话题。

团队的目标必须是清晰明了的，可能达到的而且有一定挑战性的，并且很少的。

说他清晰，是指这个目标应该是可以考核的，是可以衡量的。如果你说，我们团队的目标就是要让我们的工作做得比以前好一点。这个目标根本就不可考核。那么你说这个目标达到就达到了，你说没有达到就没有达到，这实在很无聊，团队成员也不会在意的。比如，我们说：“我要在12月底，通过电信的入围测试，进入设备选型的设备提供商之一”。就是一个比较明确的，可衡量的目标。

说他应该是可以达到，和有挑战性的；是指这个目标能够经过努力达到的。如果太低的目标，让人根本没有动力，比如“我们的目标就是把这个鸟程序磕出来，有错也无所谓，只要让客户看见就可以了”这种目标还不如不要，实在太嘲笑我们的能力了。但是如果类似于“我要用1年，干出一个Rich edit程序，替代MS Word，成为世界上最好的文字编辑器”。当然了，有想法不是坏事，但是这种目标，恐怕大家都不会接受，那么这个目标还是没有价值的。对团队士气打击最大的莫过于团队认为这件事根本不可能完成。如果一个团队认为不可能完成，你仅有两个选择：第一、和团队成员进行沟通，让他们明确这个目标是可以达到的，比如通过什么手段进行等等，期待他们建立信心；第二、修改修改吧，太固执也不是什么好事。

很少的，是指我们的精力是有限的，在一个阶段，我们只能接受少数目标，太多的目标，容易形成无重点，相互干扰，最后一个都干不好。比如在中途岛海战中，我以前一直很奇怪，南云的日本航母舰队，为什么这么执著地攻击中途岛，他的目标不就是引出美国航母舰队，然后山本大将冲上去，干一把大的，类似对马海战中一样干掉美国太平洋舰队主力吗（记得一个笨蛋的强盗，他去抢劫游乐厅，最后，随手抢了一口袋的游戏机币，离开他的抢劫地点—柜台—仅仅2米的地方坐下来，开始疯狂地玩了1个多小时游戏，结果被警察在游戏机前活捉。我很理解他用抢劫来的游戏机币进行游戏的心情，就像当年我多么期望有个哥们是开游戏机厅的，可以让我疯狂地投币玩游戏啊。真想一下投两个，一个自己玩，一个让别人玩给自己看，呵呵，多个目标害死人啊，将来多用这个很有创意的哥们来提醒提醒自己）？结果仔细看看才明白，南云领受了2个目标，轰炸中途岛，和（问题就是和这个字啊）攻击美国航母舰队，但是，事实上，南云顾此失彼，一会想轰炸中途岛，一会想轰炸舰队。航空队的弹药换来换去，结果把自己给折进去了。这是一个很奇怪的战略，如果山本已经花了这么大力气去追求攻击美国太平洋海上力量，那么为什么还动用那么多力量来攻击中途岛呢？如果这算顺手之举，那么也用不着这么拼命啊。两个目标害死了日本航母主力，使得日本精锐海上航空力量一蹶不振。同样的错误，我们今天也在重犯。相互矛盾的，大量的目标，把我们的精力都分散了。所以，还是少一些好了。什么都要，也就意味着什么都做不好。对此，请各位管理者记住一点：我们不再是孩子了，我们不能像孩子一样指着柜台上的各种新鲜玩意说：“我要这个，我要那个”，对于管理者来说，你必须明确告诉团队：“我就是要这个！”

写到这里，插一句额外的话，这是一个互联网的大拿说的，要作好一件事情，必须能够做到如下两点：

1、你必须敢于闯黄灯。如果你连黄灯都不敢闯，还是老老实实的算了。没有那么多事情，能够在循规蹈矩的情况下做成的；

2、你必须认准目标，然后为这个目标投入比对手更多的资源。大家谁都不比谁聪明多少，在你做5件事情的同时，你的对手只做一件事情，所以他成功了，我们成了半吊子。

以上的大拿，说的未必对，谁也不要在这个问题上和我争论太多的额外的东西，比如道德，比如资源调配，资源节省等等。我不想讨论这个问题。以上内容，就像管理中的所有问题一样，他只是在一个环境下，一定期限内是最佳实践而已。以上两点，仅仅是一种原则，原则的意义是什么？是你需要懂得行走在边缘上，走得太多是鲁莽、走得太少是懦弱。仅此而已。

好了，回到我们前面讨论的路子上去。

目标是重要的，所以值得你花费很多时间和精力去制定。良好的目标将指引你的团队走向胜利。一个失去目标或者拥有不适合目标的团队，使得团队涣散，而且这些问题将在长远的，深层的不断发生出来。

说完了团队的目标，该说说团队规则了。团队的规则就象你行车的分道线，提醒你把车稳稳地行驶在道路中，不会给别人的行车造成太大的问题。团队的规则，和目标一样，也是需要是明确的、而且很显然的，并且是很少的几条。我们先说说规则，然后再说，如何在团队中推行一种规则。

团队的规则是明确的。比如“大家要好好工作！”，这是一个胡扯的规则，还不如不订，显得自己很愚蠢。那么“兑现你自己的承诺”，就是一个相对比较明确的规则了。

说他只能有少少几条，是因为在实际工作中，太多的约束，实际上就是没有约束。因为大家都很难遵守，并且管理成本急剧上升。员工只干你考核的内容，不干你仅仅口头上说想要他们干的事情。

举一个例子来说明，我们有时候，觉得开发人员做了一个承诺，结果承诺没有达到，一般的PM都感到比较愤怒。但是，这个员工的确已经尽力了（或者看上去尽力了），但是还是没有达到。那么这种情况下，我们的各种计划都需要调整，如果这种情况一再发生，就让人感觉很无奈了。那么“兑现你的承诺”就是一个好的方式，在分配任务的时候，你可以明确告诉我，“对不起，老大，我能力不足，不能完成这项工作。”那么OK，我会给予更多的时间，或者指派其他人来完成这项工作。但是你一旦承诺了，我到时候就需要回收工作，如果工作不能得到顺利的回收，那么请尽快告诉我，如果在最后一天告诉我，对不起，实在太让我失望了。你的绩效会受到影响的！这也可以平衡一点，高级开发工程师每天假设能够开发200行难度比较高的代码，而初级工程师每天只能完成120行，而且质量远远不如高级工程师。我们不能“一视同仁”地考核，这种考核实际上意义并不是很大（但是，很奇怪的一点就是，我见过很多管理者就是这么考核的，那么很简单，谁的官大，谁的绩效就好。这是典型胡扯的观点。当然，你说考核本来就是政治，那么算我没有说你胡扯）。

那么规则建立起来了，如何推进呢？一般的来说，一个新的规则的建立，需要大量的迅速而明确的正向反馈，一个已经成熟的规则，则需要向触犯这些规则的人，进行一些负面激励了（比如你追尾了，没有什么可以说的，老老实实给别人修车买单；但是一些相对来说更高层次的内容，比如道德观等等，比如有人晚上开车喜欢开着远光灯，这一点让我非常愤怒，反光镜里面一片光芒，我什么都看不见。这一点，你是合适了，但是有没有替别人着想一下呢？但是对于这种人，我们没有太多办法进行规则层面的约束，只能从正向反馈上来做，比如我们说：替别人着想是一个有道德的人。仅此而已。说到这里，我想起来类似于经济上的劣币淘汰良币一样，是否社会上也存在劣人淘汰良人呢？呵呵，这个问题不太好回答，关键在于我们认为什么是良，什么是劣。呵呵，这是一个附加的哲学逻辑，大家有空可以考虑考虑，会有种感觉，认为自己很牛牛，就像阅读读者文摘的感觉一样，但是实际上，你是更变态了！呵呵，一个玩笑而已）。比如，我们希望团队成员，能够更多地考虑一些项目整体上的东西，那么对于这样考虑的人，我们需要尽快反馈，告诉大家：这一点我很欣赏！但是对于比如上班不要迟到等等，就不是表扬的事情了，而是如果迟到，请向我说明理由，即使你有理由，请向我事先请假，我们不太喜欢莫名其妙地你就消失了，然后问到你说：对不起，我家里有一些事情。任何人都有着急的事情需要处理，事先（哪怕5分钟也成）告诉我，也是必要的。最简单的一点，如果老板或者你的同事需要找你，我不喜欢我很难看地说：“对不起，我不知道”。将心比心，让我好做人一点吧。

OK，有了目标，团队知道自己努力的目标是什么，知道自己的规则是什么，然后就是一个团队的文化问题了。一个中大型的团队，他的团队文化中，有70%来自于公司的企业文化，剩下的30%中，有很大一部分来自于团队Leader的文化。这一点，请各位Team Leader注意。团队成员不会理睬你说什么，而是会关注你做什么。比如，如果你希望你的团队能够认真干活，就不要自己在上班的时候，偷偷打开游戏玩一会。这会给团队带来很大的影响的。

所以，当你的团队需要进入新人的时候，请告诉他们你的团队目标是什么？恐怕并不是所有人对你的目标都感到兴趣的，如果一个人对你的团队目标不关心，那么还是算了。另外，告诉他你的团队规则，和团队文化（比如你喜欢严谨的团队文化，但是有人不喜欢），免得将来进入团队以后，大家感觉不爽，那时候更难受了。

好了，很简单的三条吧。呵呵，一般来说，我喜欢简单的东西，不喜欢很多很多。但是要真的做好这三条，恐怕也不是很简单的事情了。

OK，下面，我们就讨论一些话题了。一些零零散散的话题。呵呵。

团队沟通

在团队这一章中，我首先提到的是团队沟通，因为这是最对于团队来说是最为重要的。特别对于一个软件项目项目组来说。我们在前面已经很多次地说到了这一点，软件行业的项目组将依赖于大家的沟通。在项目中，如何强调沟通都是不过分的。而事实上，绝大多数问题的出现，我们基本上都可以在沟通上找到一些问题的根源。举一个例子来说，我们很多人在工作中，都有一点感觉，我们之间的工作挂接不那么严丝合缝，似乎总是有一些灰色地带的存在，而正是这些模糊的地方，导致我们工作出现一些不和谐音。可以明确的说一点：这一点将在你的工作中，不断出现；而且随着你岗位的提升，责任的提升，这一点将变得越来越多。原因是，至少在现在我看来，任何组织结构都无法定义得如此明晰（因为我们面对着是变化越来越快的市场的这一个现实），所以，需要我们加强沟通，依靠沟通能力来弥补一些问题。

首先，团队沟通的成本上很高的，而且随着以下因素，沟通的成本会越来越高：人数的增加，工作地点的分离，缺乏共同的语境平台，不相同的价值观或者判断准则等等。

人数的增加，使得相互之间的沟通线越来越多，而且，信息的增加，不见得就一定能够把你导向成功，你将不得不判断各种不同的信息，从而使得成本越来越高。根据这点，我们在管理上，推荐进行单头领导（而不是多头领导）就是这个原因，我们赞成使用少量的高素质人员替代大量无经验的人员，也是基于这一点的判断。

工作地点的分离，也将导致沟通成本急剧上升。我不知道大家如何看待在这样的一个团队：我们的需求团队在北京，设计团队在上海，开发团队在武汉，测试团队在大连。如果是我看见这样的团队，将使得我很挠头。而且，但凡有可能，我极其不愿意使用这样一种团队，因为地点的分离，使得沟通和交流的数量和质量大大低于直接的面对面的交流。对于一般的开发团队来说，我希望他们不仅仅是在一个办公室里，而且更希望他们的办公位本身就是挨在一起的，这样他们抬起头就能交流。他们会变得更喜欢进行交流。很多项目经理告诉我，我们有MSN进行日常的沟通，我们有电话会议进行项目会议，我们有视频会议来解决面对面沟通的问题。但是，事实上，这一点远远不够。我们现在有很多手段进行沟通，但是诸位请回答我一个问题，以前你在家的时候，每天和你母亲说多少话？你离开母亲以后，虽然你也同样有各种很方便快捷的联系手段（而且我很多时候也和母亲在MSN上聊天），但是你每天聊多少句？你们的了解是更多了还是更少了？和母亲之间的沟通尚且如此，那么和一个项目组团队（甚至是你没有见过面的项目组成员），你们的沟通又是如何？人和人之间的沟通和交流，没有比直接的面对面更加有效的了，我们可以听见对方的话音，看见对方的每一个眼神……更重要的是，我们能够相互之间触手可及，这是一种鲜活的沟通手段，任何手段都比不上他。所以，除非万不得已，不要把你的团队分成那么多地点。

有一个例子，我们曾经试验过软件工厂（在武汉设立了软件工厂，以至于我看见我们举行会议的时候，总是会有几个武汉的同仁，风尘仆仆地赶到北京），理想状态下，我们希望在北京做需求、设计和验收测试，在武汉进行开发和测试。而且主要是研发一些独立性很强的产品（比如一个显示报表的工具），或者一个很简单的功能实现。当时，为了体现软件工厂的有效性，总经理下令，不强求在北京的团队使用武汉的软件工厂。结果几乎没有人使用武汉的软件工厂，而且即使有人使用了，也是直接把需求和设计人员直接派到武汉，象项目经理一样带这个项目。呵呵，当时我们很现实，软件工厂是否成功，不是我的事情；但是我的项目失败了，就是最大的问题了。所以，还是请一帮张口闭口软件工厂的兄弟们，至少自己亲手干一干，你会发现，其中的难度是非常高的，你仿佛一朝之内回到解放前，对于项目的忧虑和风险会急剧上升的。他并不是如同你所想像的那么容易驾驭。当然了，如果你真的能够很轻松地驾驭这方面的团队，我不得不说，你的项目管理能力以及团队管理能力非常出色，是一个国际性的项目管理大牛，但是……，国内的98%以上的小型项目，有必要采用这种方式研发吗？我觉得没有太大的必要。所以还是不要开口闭口的软件工厂，软件工厂的。我们知道一点，我们现在面临的问题，如同20年前提出软件工程的时候一样，是软件项目失败率太高，而不是我们已经解决了软件项目失败率问题，那么对于绝大多数项目来说，还是如何保证成功率，如何来做吧。

缺乏共同的语境平台，也会导致沟通成本的上升。比如我们希望某一种设计文档，能够按照一个相对固定的格式来做。当然，这种做法不值得走得太过（章节内容完全规定得非常死非常死，就容易引发负面效应了），但是，这种做法有效的一点是，他统一了语境平台，大家很清楚，到哪里可以找到你的某一部分内容（比如我总是希望在第1-2页，能够看见一张图，这张图是系统整体框架图，并且配上说明，告诉我里面的每一个模块完成什么功能，相互之间的接口如何定义等等）。

举一个通用管理上的例子来说，在联想，我们都清楚“我们把这件事拉一下”，这句话的意思是，我们找个地方，把这件事情好好梳理一下。比如我们看见一个哥们在会议上说话说错了（当然是那种一般的内部性质的会议，可不是很要命的地方、很要命的时间说错话），我们会善意地笑一下，说“再给他一次机会吧”。因为每一个刚进入联想的兄弟们，都会参加一个一周的“入模培训”，意思是，无论你在社会上是一个什么样子的人，进入联想就必须经过这个模子套一下，然后至少你们就能拥有相对比较一致的价值观了（这个入模培训基本上可以看成一个优秀传统介绍＋联想常用语的潜移默化＋简单拓展训练。也许过去N年以后，联想人会忘记很多事情，但是入模培训想来是难以忘记的了，至少我离开联想2年了，口头和做事方式中，还是多多少少带有一些联想的东西）。“给他一次机会吧”，这句话出自每一个入模培训中都会讲的小故事，说一个某某教练带着“某某学员”（这两个某某都可以换成你想说的人），去参加文化考试。

老师：“9+10等于多少啊？”

学员：“20！”

教练：“这种题目都会做错，老师，再给他一次机会吧！”

……

老师“那1+1等于多少啊？”

学员：“2！”

教练：“老师，要不……再，再给他一次机会？”

讲得兴起，再多说一点。通常每一期入模培训完毕以后，都是联想内部邮件系统受到很大压力的时候，因为这时候，很多“模友”（进入同一期入门培训的人，称为模友；如果你们有幸被分在一个组内，那就是更亲密的模友了，我们当时组名叫“VII”，发音为V Two，靠，一个土得掉渣的名字，现在还觉得有点脸红，当时就是老实，不然死也不会让这个名字通过啊。还有的队叫“大刀队”，呵呵那就更搞笑了，看见那个Team的组长上去，是个小小的瘦子，我还想着：这大刀敢情说的是水果刀？呵呵）。在联想这样一个大型公司中，部门层出不穷，我们在部门之间合作的时候，如果发现你的合作部门接口人是你的模友，那恭喜你了，一般来说，他不会太难为你的，甚至给予你很大的帮助。于是，你会发现，在很多的需要多部门合作的项目中，正式依靠着这种亲密的关系，才使得事情更容易推进。模友们的关系会维持很长的时间，以至于我们会聚在一起，给某个模友过生日；模友离开联想的时候，也会给我们发一份邮件，告知我们离开联想了。甚至上你的部门，向你当面道别。这是一个不错的方式啊。

这就是为了建立起来一个共同的语境平台（顺便说一句，程序是一种极其好的，无二义性的语境平台哦，无论是美国人还是中国人写出来的程序，都是我们能够看懂的的程序）。如果缺少这个语境平台，不理解对方所说的话，还是小事，但是他会使得你会象个外人一样，不能融入到整个团队中。

不相同的价值观或者判断准则，也会潜在得极大提高沟通成本。因为他会使得一些基本的判断发生偏差，使得管理者倾向于收回所有的判断权和决策权，并且使得团队成员丧失很多的锻炼的机会，。最后变得，团队Leader忙死，下面团队成员闲死（更可能的是，团队成员也忙死，但是忙得不得其要而已）。管理者会倾向于把做一件事情分解称为各种操作性指令，而总体目标在团队成员脑子里就是一个模糊的东西。这是一件很恐怖的事情。呵呵，讲到这一点，我想开过车的兄弟们都知道，我们总是希望在去某一个地点的时候，脑子里大致有一条路线图，我想很多人会很讨厌，在某一个非常繁忙的地段，然后旁边的哥们不告诉你目的地何在，开始发各种命令：“往左并线……”，“并线哪！”，“唉，唉，跟着那辆大车出去”，“那辆，那辆，跟着这辆有啥用处啊！”。如果这是一个哥们敢长期这么说，我就会打开车门，让他下车滚蛋！这至少会让我非常光火，因为我不得不到处寻找他所说的标帜物，而我实际上不知道他到底要干什么。会显得很笨拙，而且很不爽！我喜欢的指示是：“从桥下左拐，你需要在这里出高速道路”。这我就明白多了，然后即使你再给我各种指示，我也很容易理解了。

举一个现实的例子，一般来说，销售团队和研发团队之间的沟通，总是存在部分的问题。销售团队人员一个好产品，就是一个能够销售出去的产品；而研发团队所谓的一个好产品，是从技术本身出发所描述的。所以，销售一般不太愿意，为了所谓的框架来花费成本，但是研发总是对此念念不忘。

类似的，提高团队沟通成本的地方还有很多，比如语言的不通（比如一个英语不好的人员和老外沟通），相互之间背景的不相同（上面的销售和研发的冲突，就是如此），私下之间的关系属于臭鱼看不上烂虾的那种（当然，非常具备职业素养的人，会很好得平衡工作和私下的关系，但是这毕竟是很少部分人所具备的优秀的职业素养）等等。都会很大的提高沟通成本。

呵呵，以上说了提高沟通成本的一些事情，对于一个沟通如此重要的领域来说，尽可能降低一些沟通的难度和沟通的成本，对于项目来说总是有利的。这会潜在降低很多你的软件成本的。下面说说沟通上面一些需要注意的地方了。不说复杂的，就说简单的。呵呵。

沟通，其实往简单了说，就是“听”和“说”。说出你想说的，听别人想说的。这一点在沟通中极其重要。

呵呵，这一点，如果很枯燥地说教，令人也很烦哪，好像是老师在夏日闷闷的教室中，毫无语调地读书，下面学生昏昏欲睡。如果继续如此说下来，我几乎能够听到蝉的叫声了(我最喜欢，在那样的环境下，慢慢地睡着，脸上露出阳光灿烂的笑容，那简直就是一种享受)。我们换一个说法，让我们大家来结合BBS上的论战，来看看“说”和“听”好了。

首先说“听”，一般来说，这一点更难。虽然原则上说，听和说一样困难，但是现在聪明人太多了，以至于大家都能言善辩，但是，是否能够听到别人所说的，就不好说了。在沟通方面，我们经常犯这样的错误，包括：

我们会经常断章取义，有意无意地把其中某一段话理解成为全部的意思。当然了，这是论坛上一个惯用伎俩。在长篇大论中，总是会抓住一些说得不恰当的话的，然后从这个话题开始猛攻，使得对手离开他已经胜利的领域，从一个很难受的起点开始出发，这很无聊（更为好用的是，我们一般用引号去引用对方一小段话，如果对方一定要废话更多，引用以前他所写的1/3的段落，估计很多没有耐性的人也不会看，于是，他的话就成了证据确凿的罪证了），不是吗？我们听别人话，也要注意，是否我们顾及了上下文，而不是从中抽取一段出来，发挥和理解。

我们经常带着反驳的态度来看待对方的意见。本来嘛，在BBS上，一旦开始掐架了，就必须掐赢，虽然大家口口声声说着，自己为了讨论问题，估计到最后，讨论问题的心情没有了，肾上腺素才是维持我们掐架的由来了。我们经常使用的一个方式就是，带着有色眼镜看着对方的话，然后恶毒地把他往他所支持的观点方向一个劲地猛推，比如，某一个人支持在工作中赞成目标驱动的考核制度，于是大家说他：目标一切啦，只重视目标不重视过程啦，风险大啦，管理者的Training职责啦等等，比如另外一个人赞成过程考核的方式，于是别人开始说他目标不明晰啦，管理者容易做老好人啊，容易导致面子工程啦……等等。于是，大家觉得，对方那简直就是胡扯嘛。但是，实际上，这是因为我们本身就是带着反驳的态度来听别人如何说的。管理是在很多时候，都是一种权衡的艺术，所以，如果你把别人推到如此极端的地步，那么你的观点自然是正确的。BBS上用来这种方式掐架是可以，但是用于现实中，这样“听”对方的观点恐怕就不成了。这一点现象非常普遍，所以，在听到这些东西的时候，至少让自己考虑一下，我是不是也犯了这个毛病了？说对方错，真的很爽啊，不是吗？我们会象看着一个小丑或者一个孩子一样，感觉自己很明智，但是这种状态可不好，用这种方式去听，沟通基本上就不成了。

过于敏感，特别对于很多自我感觉非常良好的人来说，他会把任何建议和意见，看成对他个人全部的挑战。还记得大仲马笔下《三个火枪手》中的主人公吗？那是小说，如果现实中，你也如此的敏感的话，会令别人觉得你很难相处的啊。有的设计人员认为，任何的对设计提出的意见都是对自己的攻击，自己永远是对的。如果是那样的话，你就不是一个Team player。在工作中很难和你合作啊。

不尊重人，BBS上很常见的一种无礼之举是，没有看完别人的贴子，就开始疯狂批评。不错“尝一口就能够知道的臭鸡蛋，就不用吃完它”，但是（事情往往坏在“但是”上）如果你仅仅想爽一下，可以骂骂人，出出气。但是，如果你想讨论问题，最好还是看看清楚别人到底写了什么东西。这是一种对别人的尊重。不要根据只言片语，按照自己的理解，狠狠说一通，那样价值何在？典型的无效沟通。我们不是为了把人批臭批倒，来证明自己的胜利，我们是为了通过沟通解决问题。所以还是尊重一点比较好一些。

好了，听基本上说完了，很不完全，但是至少这些是第一时间反应到我脑子里面的东西，也是对我感触最深的地方。下面该说说“说”了。

首先，理清楚你的思路，不要说到东，说到西，我根本不知道你想说什么。这是一个思路的清晰程度的问题。同时也是IQ组成很重要的一点。至少体现出一些高IQ人员的素质（大家不是说IT人员的人，要IQ比较高吗？）。比如我们在面试中，喜欢用的一个方式是，一下子问7-8个问题，然后让面试者按照顺序回答下去（这7-8个问题，是有内在逻辑联系的，而且逻辑相对比较明了。对于低级的岗位来说，我们一般连续问4-5个问题），并且在他回答过程中，我们会企图问一些问题，然后让他继续回答。看他是否能够回答完毕这些问题，而且思路比较清晰。如果一个人员，连4-5个连续问题的压力都承受不了，一般来说，我就不再考虑了。所以，请维持一个清晰的思路，知道你要回答什么，不要象一个没头苍蝇一样，撞到哪里算哪里。

其次，请整理清楚你的逻辑，你举出的实例要能够证明你的论点，不要说得云山雾罩的，很让人困惑的。这一点在BBS上经常看见，一个哥们说完N段以后，突然告诉我，上面的例子也许举得不好，重新来过。我简直不知道该说什么好了。你不是我的冤家派来玩我的吧？最简单的逻辑整理方式是，提出你的观点，然后用1、2、3、4列出你的论据，这样大家比较容易沟通，不是吗？不要一会一个例子，一会一个例子，而且我都不能分辨前后例子之间存在什么逻辑关系。对此，我只能承认，自己的理解能力实在有一些跟不上你跳跃的思维了。

再次，如果不是万不得已（比如需要尽快的一个决策过程，不能再过多地讨论了）尽量少用一些攻击性很强的话。攻击性很强的话，基本上不能起到加强你观点的作用。这种方式类似一些怀疑别人做事的动机啊，问候别人的家人啊等等，一般来说，都是不必要的。对方会由此变得更加难以说服。因为他会自觉地保护自己，这时候已经不是事情本身了，而是变成人的事情了。一般来说，这更难以解决问题。当然，如果团队内部已经建立起来这样的文化，比如骂娘文化，那么有时候用用也无妨。但是我不喜欢这种文化而已。比如，有一个总监，和我争论下一阶段工作的时候（当然，这也是一种沟通，呵呵），曾经用手推了一下我胸口，当时正是夏天，本来就容易上火，我脑子突然一冲，几乎扬手一个耳光就过去了。但是还好忍下来了。但是那次争论没有任何结果。

最后，说话请靠谱一些。我很不喜欢的一种人是说话不靠谱，什么都敢说，但是基本上胡扯居多。所以，请注意你的说话，说话要保证你说的，至少是你认为对的东西，不然就悠着点说，很容易误导别人的。而且一旦被别人抓住，举几个数字出来，你就全完了。所以，我喜欢的一句话就是：“我不说，你不说，数字来说话”。呵呵，当然了，你让数字如何说话，里面还是有大讲究的。我的一个姨妈在统计局工作，她和当时在大学的我，讲了很多如何让数字来证明观点的小伎俩，以至于我现在看见数字，也会留一个心眼，看看有没有人在数字方面糊弄我。呵呵。学过统计学的哥们一定对这个很熟悉吧，呵呵。

好了。以上是一些常规的沟通，至于上下级之间的沟通，我就不在这里说明了，更多的会在团队管理中说明。

沟通成本很高，所以，让我们尽量有效地沟通，而少一些无畏的沟通。说和听都很重要，所以请认真对待。

接下去的一点，是给不少在“说”方面略有欠缺的技术兄弟们写的。呵呵，我知道有一些技术人员，心中有很多东西，但是临到说的时候，突然说不出来了，感觉很亏。如果你在公司被别人称之为“喷壶”或者“喷泉”，就不用看了，这方面技能你一定不缺少，我这点经验也不够你笑话的了。呵呵。

最常规的锻炼，是让你能够在大家面前滔滔不绝地说一些至少有一点意义的话。呵呵，这一点说起来难，其实也比较容易锻炼。比如，在部门级会议的时候（呵呵，本来我今年想在得实开发一部中推开，但是还没有来得及干，就离开得实了，很多得实的兄弟们说，希望如此做呢，这一点向兄弟们道歉了！将来有机会大家一起聚聚吧，很想念大家啊），凑个20-30个人，当然了，用其他方式，集中多一些人也是可以的，只是人不能太少。当然了，即使再少也是有用处，但是效果就没有那么好了。然后准备一个大盒子，盒子里面是各种小纸条，小纸条上写一个名词（比如竹子、比如长城），随意抽一个出来，然后用5-10秒作准备，然后就开始说，在5分钟时间中，不允许任何超过3秒钟的停顿（也不允许和朗读诗歌一样，一个“啊……”整个7-8秒，听的人感觉很不好，感觉你在台上公然被人毒打一样）。如果超过3秒的停顿，就下台，算失败。如果挺过了5分钟，然后大家来评判这些说话的内容是否连贯性强，思路是否清晰，演讲的时候的语气和语速控制等等。呵呵，这也是联想入模培训的一环，当时我面对100多个模友，突然开始说，多少感觉有点口干舌燥，但是过了一段时间，后来就好很多了。要有自信，这一点真的不难，问题是大家没有太多的机会来锻炼，往往锻炼的时候，就是公开演讲的时候，越做得不好，越没有自信；越没有自信，越给下次埋下失败的种子。所以，自信一些，大家都是这么来得。练几次就好了。

下面，就是一些技巧的东西了，呵呵，在“说”的方面的一般常用的技巧，我经常会用如下几种：

首先，明白你所对话的人，是一种什么样的人。然后再考虑如何说，对象是不懂技术的人，与精通技术的人，说话的方式是完全不一样的，这一点很简单，不多说了。关键一点，就是说对方能够明白的话。你沟通不是用来卖弄的，是要让对方明白你的意思。如果对方听不明白，不是对方的问题，是你说话没有水平哦。

其次，不要仅仅考虑你自己，而要考虑对方，是否明白你说话的意思。也就是说，你要从对方的思路上着手，而不是从你的思路上着手。举一个例子，如果你研发了一个电热水壶。你会如何说明给你的客户听？很多人上来就会说：“他会叫耶，水烧开了他就会叫耶”，“他热得比别人快，省电哪”。但是，我还不知道你的产品是个什么玩意呢。所以，最保险和最常规的（当然也是最没有创意的，如果要有创意一些该如何干？也许5年以后我会明白一些，但是现在我不知道 L ）的做法是：

第一，介绍产品是什么：电热水壶，就是用电把水烧开的东西；

第二，介绍产品能够为客户带来什么价值；为你烧开水呗；

第三，我们产品的特色是什么：电热的，

第四，为什么选择我们？用电的，环保，干净……

这样的描述相对客户容易理解一些。

再次，在介绍之前，首先很明确地说出你的观点是什么（当然，这是一种常规的说法，如果你要由对方自己导出观点，然后你再赞扬他几句，把这当做他自己的观点，那么就不用提出了）。

再次，说出你的论证体系。这是一个我习惯称之为“思维管道”的东西，我会告诉对方，我是根据什么体系来导出结论的。比如，我会说，我根据SWOT、竞争力模型分析得出结论，或者告知对方，你的出发点是什么，比如我认为你这个问题，实际上需要解决的这样一个难题等等。这主要有两个作用，首先划一条道路出来，让对方的思路在下面的时间中，在你的规则中走；其次，如果发生误解，那么也最快可以知道，免得说了一大通，发现说错了，很难看的啊。会显得你很笨的。呵呵。

再次，也是很重要的一点，明确说，我有5个理由，或者3个因素使得我认为应该如此做。这样做，容易使得别人感觉你的思路非常敏捷而且快速，或者你对这个问题已经考虑得很多了，是个非常专业的人。但是，在现实操作中，往往你听到一个问题，只有大约3秒钟的考虑时间，你需要利用这些时间来考虑明白你要说的理由，如果你想到了3-4点，请直接说我考虑有6个因素（因为你在说的过程中，多少会想到一些前面没有想到的东西的）。那么如果你按部就班说下来，如果发现：靠，只有5个啊，少一个；这一点很恶心，不过没有关系，你随便想一个好了，或者把前面的一个观点换一个方式说出来好了，如果你追求保险，最后总结的时候，说：“这一点和前面的某一点存在一些关系，但是有一些不同”，只要找到一点不同就可以了。相反的，如果你认为，坏了，少说了1点，应该是7点，该如何办啊。呵呵，这恭喜你，你的思维太敏捷了，以后要记得多说一些哦。但是这次呢，就说：“最后补充一点，虽然放在最后说，但是并不代表他不重要”，然后，坦白地说出来好了。总不能让自己的思路烂在肚子里啊。这不是教你扯谎，只是说，你用一种更有条理的方式，表达你的想法，仅此而已。当然，这个要素不是越多越好，别人也记不住，你需要分层次来说，一般来说，5-7点就是极限了。

再下来，就应该一点一点表述你的论据了，如果能够使用数字，就用数字来说明问题，太多的修饰词会引起别人的反感的。比如“很多”、“大量”等等，说多了，很容易被老板一句，“到底多少？”给闷在里面，很难受的。

最后，要适度总结，在最后的时候，请回顾一下你的观点摘要，这样有助于对方整理思路。如果对方听下来感觉很清晰，那么他会认为你的思路也很清晰。聪明人总是喜欢和聪明人沟通的，不是吗？必要的时候，和对方的问题挂接一下以后再结束，因为对方的问题，也是对方最关心的东西。

最后，想说的一点是，明白一点，和聪明人说话，不用说得太详细，说得太详细，面面俱到，容易让对方困倦，而且感觉很罗嗦（有的人还真喜欢这么说话，和他们对话，真的很累哦）。当然，如果和你对话的是个典型的棒槌，不妨说多一些（但是，老实说，我很少碰到过这样的人。不过还是有的！第一次向他汇报的时候，说完以后，他两眼茫然，搞得我很困惑；不明白是我说明上存在问题，还是他理解上存在问题。呵呵，结果那个哥们的秘书在领导内部述职的时候，当着全部管理者的面，说他头脑不清晰。呵呵，当时给我惊讶坏了，呵呵，这也是一件趣事啊）。

OK，结束了！很简单的技巧，不是吗？

至于在“听”的方面，我一般常用的技巧是：

首先，请凝聚起来你的眼神（当然不要太凶，这会使得别人感觉你在审问他的），至少要装得很聪明，很精干的样子；而且也使得对方认为你在认真听他说话。而且，据我自己的经验，在这种状况下，你的确在很认真地听人说话。这一点很重要。另外，把腰挺起来，跟一滩稀泥一样躺在椅子里的，看上去比较不健康，而且懒散。

其次，请把看着对方，如果是对方是女性，一般目标关注的范围大一些（不要盯着别人的眼睛看，会给人很大的心理压力的），如果是男性，但是他的目光老是躲开你的目光，可能他是一个相对比较软弱的人，不要老是盯着对方看了。适度多一些看看别的地方。我们看着对方，只是希望让对方知道，我们很认真地在听他说话，不是给人太大的压力。另外，如果某个人身上有某个缺陷（比如眼睛斜视等等），请务必不要盯着看（虽然也许你很好奇），这会使得别人更加不自然的。

再次，适度记一些笔记；但是，不要太奢望，如果你真的希望把整个谈话记录下来，一个人肯定是不够的，需要2个人以上才可能。如果是一个人和对方沟通，只能记录下来一些重点，以及让对方感觉你很重视他而已。你做做样子也好，真的记录也好，但是在谈话中，带一个笔记本，总是不会错的。

再次，多点点头，多“恩”、“对”，给予对方一些反馈。但是别太多了，我说一句，你“恩”一次，感觉就不爽了，和CD光盘坏了一样，难受；

再次，适度地表示一些疑惑，对方说的东西你可能不明白，请适度表达出来，这样才有沟通的意味，而不是一言堂，而且相对来说，这一点往往是对方比较感兴趣或者比较自豪的，适度表达一下，也好让对方满足一把。

再次，如果你的意见和对方不同，请首先听完他说的，不要打断他。这是一个很大的坏毛病，而且很不礼貌（我有时候，这一点也做得不好啊，将来要改改）。让对方说完。当然碰到一些话篓子，而且你的时间也很紧张，不妨直截了当地说出来，这样都比较节省时间，让他概要地说出他要说的事情，如果说不出来，下次想好了以后，再说吧。

如果发现不明白的地方，如果很重要，请直接说出来。不然很难受的。呵呵，有一次我和一个哥们去一个合作公司那里，和合作公司谈技术。那个公司的员工，简直就是一个假洋鬼子，英文单词懂得恐怕也不太多，但是但凡懂的都用英语来说了（呵呵）。里面有大量的PC TO phone；phone TO PC；我很奇怪，我那个同事为什么不说话，最后出来的时候，那个同事问我“周海峰，TO Phone是什么？”。呵呵，估计那个合作公司的哥们发音也比较奇怪，害得我那个同事，郁闷了半天。但是，这样的沟通是无效的。而且，很容易让对方感觉你的思路很奇怪。不值得，该说还是说出来吧。

OK，呵呵，反正我的一项原则是，老老实实做事，无愧于心做人；所以，老老实实地说。尊重别人地听。就是了。如果你真正和别人进行有效沟通，叁人行，则必有我师的。一次在火车上，和一个打工回家的民工谈子女教育（呵呵，那时候我大学毕业刚刚半年，连老婆都不知道在哪里呢），别的收获不大，倒是感觉到一颗为孩子而跳动的心，和为孩子操心而花白的头发、都不易啊！善待自己的父母吧，不要让自己将来后悔。除了工作，我们还有很多更值得我们关注的事情呢。

不说了，就这样吧。

团队

下面我们要开始花很多篇章说管理了哦。如果对这块不感兴趣，请自行跳过，直接看后面的项目管理部分，但是我认为如果项目管理缺少人力管理这部分，就变得太不完整了。而且，我在项目管理过程中，一般对人员关注很多，所以，这里也就花比较多的篇幅了。

团队是如此的重要，以至于现在任何的岗位，都需要你首先是一个“Team Player”。那么团队是什么呢？首先不是一堆人在一起就是一个团队了，他只是一堆人的集合而已。我们想想，我们打牌的时候，和对家就是一个小的Team。这个Team具备了团队的基本一些特征：共同的目标（你们都想联合起来打败对手），你们有一些共同的工作规则（你们之间的默契，你们必须按照牌理出牌），团队的成功依赖于你们的共同努力（我最不喜欢和合作的牌友，就是一有好牌，就疯狂出打牌，根本不考虑如何利用双方的牌进行配合，然后抱怨你一手烂牌）。

同样，项目组也是如此，我们具有共同的目标（希望一个项目成功）；我们具有相同的一些工作规则（我们在一个规范下，进行研发），目标的达成，依赖于我们每个人的努力（缺少任何一个岗位的团队，都是残缺不全的，和离开成功希望越来越远的）。也就是说，我们是为了达成目标而集中起来的，我们的努力目标就是达成团队目标（以及在此过程中，达成自己的目标）。

这对我来说，就是团队！

说明白了团队，我们下面按照这样的思路展开吧：

首先说说团队沟通，因为他是基石，缺乏沟通的管理，根本做不好管理；

其次，由于团队管理方面涉及的内容太多，我取其中我认为最为重要的3点去说，然后展开一系列的话题，每个话题解决一个问题，当然这都是我的观点，看得不顺眼的就跳过不看好了。管理无所谓对或者错，只是个人的一种风格。

以此看来，用这种方法表述，对于个人来说，真的很偷懒，但是偷懒就偷懒吧。我的能力也只能做到此为止了，将来更有经验了一些，再整理好了。

软件角色总结

在上面，我们花了不少篇幅去写从一个项目经理眼中的各个角色。当然，还有很多角色被漏掉了，比如公司内部其他部门的人员，比如工程人员，比如售后人员等等，都没有很好地去表述他。这并不代表他们不重要。相反的他们很重要。但是，我也不想一一地说太多了。

软件是由那么多角色，人员配合才能顺利产生出来。其中必要的沟通和相互的谅解是必然的。无论做为一个客户也好，做为一个高层管理者也好，做为一个项目组中一员也好，只有大家都认识到这一点，我们才能构造出适用的软件。

其中，最为项目成功的最大的要素，不是其他的，是沟通！

贯穿于项目中点点滴滴的沟通，我们所做的各种额外的工作，绝大多数是为了沟通。在项目中，再如何强调沟通都是不过分的。

让我们为一个美妙的软件而合作，而沟通。

其实，对于很多软件人员来说，能够参与一个成功的软件的研发过程，都是一个美妙的过程。这是一个拥有无穷成就感的工作。让沟通，让理解把我们从一个一个软件噩梦中拯救出来！

祝福软件行业中的每一员，我相信，随着时代的进步，我们会做得越来越好。

客户

之所以把客户列在其中，是因为客户也是项目组中的一部分，而且是很重要的一部分。

在这里，我主要想说的就是一点，如何和客户沟通。其他的部分，都不重要，但是这一点做不好，累死你也没有好下场啊。再往后，我们会讨论几个我们老是会碰到的问题。

首先，和客户沟通应该抱着一个什么态度？首先必须肯定的一点是：你不是什么救世主，客户不需要你来拯救世界；你也不要把自己看成帮助客户来改善他们的工作的专家，一般来说，这种态度往往得不到别人的认可，他们之前的工作已经做得很好了，不需要你来改善工作，你所做的仅仅是帮助他们更轻松地完成他们本来已经做得很好的工作而已。记住这一点！这很重要。这是一个沟通的站位问题。

其次，和客户沟通的技巧。技巧原则上其实很简单，这里我不准备详细说“服务客户技能”，这方面的内容，值得我为它另外写一篇东西。我这里就是简单说一说。你需要换位思考，首先考虑考虑你的客户的个人利益，企业利益，然后再考虑考虑你的个人利益和企业利益，如果都能符合了，那么恐怕就是一个好的提议了。比如要你的客户为你买单什么东西之类的东西，就不用说了，说了也是白说。一般的来说，对于客户方面的工程师来说，你首先最好知道他的背景，比如他是一个研发背景，希望将来在技术领域走得很深的人，那么你最好在适当的机会，提供各种设计分析等等内容，并且结合你的项目，提供一些结论性的东西，他会很自然去使用这些东西的；如果希望走项目管理路线的，记得组间协同和项目文档必须做得好，让他在汇报的时候，可以很轻松引用你的东西，那么将在他的老板心目中，给他造就一个人才的印象，这对你来说是很有利的；对于客户方面的中层管理者来说，一般来说，他们都希望事情能够安全做完，并且得到老板认同，那么不要用太多激进的东西会比较稳妥一些，而且他们喜欢看见数字性的东西，说明问题的时候，最好使用数字来说话，不然很难说服他们的；至于高级管理者来说，你多讨论讨论将来叁个月到半年系统带来的战略上的价值，会更引起他的兴趣的。当然了，这是普遍意义上的说法，并不具备个体意义，你的目标客户是什么样的人，他的个人利益是什么，这一点如果不能分析清楚，那么很多事情的确很难做啊。

另外，在合作中，尽可能采用一种配合的心态进行工作，而不是相互之间挑错。有一些很有性格的技术人员，经常会和我说：“某某公司的人员如何如何的不专业”，“这是他们的错！”。少去理会这一点，我们是在合作做一个项目，如果碰到类似问题，请第一时间说：“OK，我们一起来看看问题何在”，而不是说：“靠，这是你的问题”。这种话不能解决问题。我的一个建议是，大气一些，至少在项目过程中，保持着一种对对方的敬意，至少在这个项目中，你们是合作的双方，不是竞争的双方。而且，尽量看见对方的优点，而不是看见对方的缺点。如果你一味看对方缺点，并且喋喋不休地向你直接上级汇报，我可以明确告诉你结果是什么，这会使得你的上级十分不好受，甚至认为你的工作能力存在问题。所以，如果许可的情况下，还是多多合作吧。而且你老是存在这种心态，给人的感觉是你比较不自信，自信一些吧，兄弟们。这会给你增加一些个人魅力（呵呵，至少会多几个朋友，不是吗？）的。

积极的沟通心态。我们一直说，沟通是首先是一种意识，然后才是一种技巧。

举一个我自己的例子；我在做水利行业信息化的时候，当时是1998年，我刚刚毕业一年，我独立去到客户那里做一个数据集成项目，刚开始的时候，总是感觉很难推进，因为面临了很多很多的数据源，而且一般他们都很忙，忙得不理睬我，于是我就今天干一点，明天干一点，感觉项目推进得极其缓慢（不过还是挺爽的，平均每周工作4天，另外一天基本上自己给自己放假了）；后来我意识到，如果得不到客户的大力支持，这个项目一辈子都干不完。看着遥遥无期的项目，我至少已经2个月没有回公司了，我感觉多少有点害怕了（那时候还是一个刚毕业的，没有太多经验的孩子，离开自己的团队越来越远，是会感觉有点担心的，害怕别人把我忘记了）。后来，在一次意外的情况下，我突然发现他们的信息化主任参与了和欧共体合作的台风信息系统的建设，这个项目令得他非常自豪和珍惜（一个50多岁的技术人员，几乎把这个系统看成自己的孩子），他们的中心副主任，对一个水情系统非常自豪，因为这是他还在读研究生阶段就主持开发的系统，并且使用至今。于是，我就得空下来，找这两个人咨询一些关于他们专业的知识，让他们给我讲讲台风、水情。就是在那里，我知道了97年最大的台风是什么（那个台风飘飘荡荡，横扫大半个中国，现在想来，还是比较触目惊心呢），知道了2/3的台风漂向了日本，亲眼目睹一个台风经过3天的时间，从福建边上擦过，直扑日本而去（呵呵）；知道大多数台风是从哪里起源的（以至于现在我看云图，都会习惯性地关注菲律宾和中太平洋海面上，一块白白的圆的云，因为这往往意味着台风的生成）；也同时知道了水情采集系统是如何进行数据采集、通过何种途径来保证数据传输的稳定等等。最后，他们变得愿意给我提供各种信息，而且对我的工作成果也相对容忍了很多，一个制作得比较粗糙的网站，他们也觉得“不错不错”，只要能够完成功能就可以了；这使得我们后面的合作多少舒服一些，当然，他们也在我的老板面前竭力夸奖了我一通（我一直怀疑，当我的老板看见我花了那么长时间，就干了这么点活，而且还那么粗糙，是不是感觉：你个小子，不干好活！不过看在客户面子上，也放过我了，不和我计较旷工的事情了，不过从那以后，我再也没有那么舒服过，几乎都是象驴一样干活了），并且主动给我介绍一些水利局的项目（比如2个网页的查询系统，我收了15000，现在是看不见这种好事情了！唉！），当我们拿下了水利局的一些项目以后，公司老板开始认为我还算干得不错（在200-300名技术人员中，我是属于必须保留的5人之一）。这种沟通使得我受益匪浅。所以，当你企图去沟通的时候，你首先考虑的是意识，然后才谈得上技巧。

另外，我们一直说一点：最使得我们讨厌的人，大多数并不是我们真正讨厌的人，而是那些讨厌我们的人；所以，多多看见别人的优点，然后从喜欢对方的角度出发来相互沟通，这样也比较容易得到对方的信赖。不要认为别人是傻瓜，看不出你对别人的藐视或者讨厌。一旦对方感觉到这一点，将来你们的很多合作将变得很难进行了。

有时候，客户会提出一些不现实的时间需求，那么针对这种情况如何进行处理。这首先，需要你首先建立和客户之间的信任。如果缺乏信任，你说什么都将使得客户难以相信，那么什么技巧都是白搭。相反，如果能够建立信任，客户就真正是项目组中的一员了。然后，你一些能够帮助他的地方上尽快地和主动地帮助他，在其他的地方，期待于他的理解。当然，碰到一个白眼狼，你还需要一些其他的技巧了。好人不见得就是天下通吃的。

没有其他可以说的了，和客户沟通的技巧很多，但是基本立足点就是以上所说的，换位思考，双赢的考虑和试图真正地去喜欢客户。最后，重复一句最重要的话，沟通，首先是一种意识，然后才是一种技巧。

高层管理者

高层管理者，这里之所以要提起，是因为，事实上，使得项目成功，在很大程度上也需要取决于高层管理者对于项目的一些做法和态度。那么做为一个项目经理的角度出发，我们期待于高层管理者如何呢？

首先，我们希望能够保证资源的供给，保证时间、人力和资金的保证。当然每个人都希望从投入中得到足够多的反馈，但是我希望高管们能够理解项目、工程的一般性原则，有时候，我们的确无法答应一些时间条件，不要和我过多地谈起我给你1倍的人，你是否可以少用一半的时间完成这种怪问题，我真的很难回答（当然，现在这种什么都不懂的高层管理者不多了，倒是看见不少底层管理者敢于对上面这个问题，回答“是！”）。如果我真的如此答应你，那么对于你来说，恐怕也是一场灾难。因为，我可能仅仅是因为希望扩大一些沉没成本而已，来使得这个项目更难以取消。

其次，我希望高管们，在一定时间中，维持一个相对来说比较稳定的环境，而不是变化多端的环境给研发团队，人的想法变化很快，但是一个项目目标老是改变，就很难受了。不是吗？至少有一定的定力来维持一个至少短期的一个稳定。我们能够拥抱变化，但是不是说，去拥抱无节制的变化。比如，原先一个产品是为了解决项目中的实际问题而做的引擎，后期变成了为了演示而开发的引擎等等；这就多少让我惊讶万分了。

再次，做好你的事情，其他的事情，让兄弟们干好了。我不喜欢伸手得太长的高管。比如在有的合作中，做为产品和市场方面的高管，每天和我一起讨论技术问题和一些界面安排问题。我觉得多少有点离谱，对于一个新开始做的行业来说，在这段非常重要的时间中，我希望你能够提供更多的市场信心，找到合作者，找到我们产品的试用者，找到我们的合作伙伴，而不是一天又一天得和我讨论，项目何时开始编码比较合适。直到某一天，我的一个同仁对对方说：“某某，还是让周海峰负责研发方面的决定就可以了，毕竟他好歹也算做得比较长时间的研发经理了，我觉得我可以和你一起来谈谈一些其他问题，比如做一些BD的工作”。但是一切都没有改变。于是，大家的工作似乎都纠缠在一起，我们非要有一个全面超越竞争对手的产品，然后才能找到客户（如果真的如此，那么还不如不做算了，没有客户的直接接触，我如何知道我的产品是真的在正确的道路上行走，而不是闭门造车？），然后我希望能够在第一阶段版本出来以后，能够找到2-3个试用者来使用这个产品，我可以提供前向兼容的功能，使得用户能够使用这个产品等等。如果这种问题纠缠在一起，什么东西都做不出来。请首先解决这种问题！

最后，高管们，拿出一些个人魅力来，多多少少让手下人能够从你身上看见多一些的传统美德，比如排队尽量不要插队啊，如果说一个公司的文化，并不取决于你老板如何想，而是看你老板现实中如何做，那么请注意，有时候小小的几件事情，会使得你的下属对你将来的话表示一些不信任的。

另外，几个做法，我认为对于项目或者团队来说，是比较有效的，做为一点建议提出：

首先，有期望的奖励会远远超过无期望的奖励，后者更大程度上被团队认为是意外的，不可重复的。所以，如果推出项目奖金制度，尽量事先确立项目奖金的标准，并且在其后落实这样的项目奖金；不要在最后发放的时候，大家还不知道因为什么而发放的；

其次，给一个团队固定的一定费用做为Team Building费用，这一点和部门经理或者项目经理明确交待，并且可以由项目经理或部门经理直接使用，而不用打招呼。不然，这笔费用会类似一种优秀的奖励，或者项目结束的庆祝，但是在其他的一些情况下，可能需要Team Building的时候，就难以使用了。一般的做法是每人每个季度100-200元，大致如此。

再次，给一个项目管理者以一定的考核权（如果他没有的话），我们都很期待自己能够达到无职权管理的境界，但是对于一个初开始做管理的人来说，这一点很难达到。同时，为了平衡这个人员的管理水平等等，你可以由更上面一层的人（部门经理是一个好的选择）来综合考虑，并且把这个人员的考核表都附在后面。这样对于一个项目管理者来说，是相对有一些作用的。

就象项目经理善待团队成员一样，高管们，善待你的下级。

测试人员

做为一个测试人员，首先你需要明确自己的责任何在？我很愿意把测试人员看成是球场上的守门员，虽然我们不是依靠测试人员来取得胜利，但是如果一个差劲的测试团队，将使得项目离开胜利越来越远。你是团队的最后一道防线了。请站好自己的位置！

我一直说，如果我的精力仅仅允许我在项目中做一件事情，那么我做需求工作，如果允许我做2件事情，我做需求和测试，如果允许我做三件事情，我做需求、测试、和框架设计；这是测试在我心目中的地位！

中国明显缺乏优秀的测试人员。我从事软件行业8年以来，接触的测试人员，测试团队换了一波又一波，但是真正让我觉得很放心的测试人员，只有一个，我很高兴，在去年的时间中，为得实找到了一个良好的高级测试工程师，这是我去年中令我最高兴的3件事情之一（一件是我找到了唐明浩和李兆松，唐明浩在测试领域中的优秀素养让我倍加放心，只要她进行的测试的项目，总是令我很放心，以至于评审她的测试点和测试大纲，是一件让我非常愉快的事情；李兆松是一个非常具有前途的工程师，虽然到目前为止，我还没有看见李兆松完全地发挥出来，但是我相信自己的眼光，具有非常清晰思路，做事明了，具有想法的人员，将来必定能够让我眼界大开的，期待中……，一件是我不顾团队中成员的反对，起用刘海琳，正是刘海琳的宽阔思路和严谨的工作作风，使得Syncin能够很顺利地向前推进，而且几乎没有占据我多少精力，刘海琳的将来也是值得期待的啊……一件是通过我们的努力，我们战胜了不少竞争对手，看着自己的产品逐渐发展起来，多少是让人有自豪感的。）但是就是在这样的环境下，我们还是认为测试是项目中最不重要的一环，测试团队的工资普遍低于开发团队，一个人员如果在开发中并不出色，往往会往测试团队中一塞，仿佛那里是流放地。但是正是这种若有若无的测试，正在摧毁着我们工作热情，折磨着我们的客户，我们的团队。

那么测试团队应该如何作呢？我的概念是：

首先，测试团队（至少是他的Leader），需要了解整体的测试方式，在项目初期就有必要，而且是非常大的必要切入团队，即使参与需求的讨论也是不浪费资源的一种做法，这将使得测试团队更了解客户的需求，能够了解软件的测试重点（我们从来没有足够的资源，来进行完美的测试，那么明了重点何在就显得非常重要了），并且，在需求阶段，他也能从可测试性的角度提出自己的意见，如果一个需求模模糊糊的，测试人员是最敏感的，比如“用户输入正确的内容，然后点击保存……”这种说法，将会令一个测试人员很头疼，这不是扯淡吗？什么叫正确的内容？什么叫不正确的内容？这一点必须搞清楚。

然后，在团队成员进行框架设计的时候，我们的测试主管，一般在进行一些测试方案和测试点设计的工作，比如对于性能性和稳定性测试要求，如果没有测试方案，那么我们如何认可测试的结果呢？比如你用一台PC机运行WebLoad，并发100个企图去压垮一台SUN服务器，这简直就是扯淡，几乎可以确定的一点是，这台PC机受不了了，服务器还是老老实实地站着，结果就是，如果你仅仅通过并发数来衡量系统，你会发现你的系统几乎坚如磐石，如果你使用交易/秒的参数来衡量系统，你会发现这个数据明显偏小。同时，测试点的设计，是根据重要性对系统的重要点进行排列，比如我需要从功能性角度在哪几个地方进行明确的测试，等等；

然后，在团队进行设计的同时，如果需要进行有组织的自动化测试或者有组织的单元测试，那么还需要规划出来自动化测试或者单元测试的框架，来容纳将来的测试代码。并且展开测试大纲的撰写。我们撰写测试大纲，类似于我们的设计文档，我们总是希望测试大纲能够完善，于是后期只要找几个人员（哪怕什么都不懂的），按照测试大纲进行测试就可以了。这是一种理想的状态，但是商业上的事情，我们总不能依靠理想状态来生活着吧。事实上，我们在按照前置条件，过程，后置条件等等安排测试用例的时候，我们应该多少有点觉悟，有时候，你还是需要人员的主观能动性的。并且通过良好的反馈和沟通渠道把发现的问题反馈出来，并且补充进去。测试大纲为我提供的作用是，他是一个规范化的容器，能够不断容纳我们的各种想法，并能够使得这种想法，能够得到确实的落实。

说到这里，我想起一个笑话，但是这个笑话是真实的，这多少有点匪夷所思。呵呵。起因是这样的，某一个部门由于找不到合适的测试工程师（根本原因是认为测试工程师谁都能干，无所谓，简单！），于是缺少测试工程师的部门经理很头疼，而且测试的内容主要是电信领域的信令，说测试工程师一般不了解（其实我认为，不了解就去了解吧，一个协议是很难了解，但是也到不了不能理解的地步吧），于是，想出一个好办法：让项目组自身的开发工程师承担测试任务，部门经理从测试大纲上来控制，确保测试大纲的完整性，然后交由开发工程师相互之间进行测试，来完成测试任务。这个观点让第一次听见的我几乎瞠目结舌，这首先是企图让项目组承担部门管理的失误，如果一个部门管理上文化有问题，导致测试工程师无法到位，就交由开发工程师进行测试，并且承担相应的责任，这是典型的让别人替自己把关的事情。项目组所需要合适的人来进行项目，如果缺失某种人员导致项目的失败，首先资源分配者必须承担责任，而不是团队成员来承担责任。而且从实际管理角度来讲，也是不恰当的，我们面对的不是棋子，你要他往哪个方向走，他就一定会往某个方向走的，开发工程师对此如何看待？他们是否真的有能力做好这件事情（我不认为一个优秀的开发人员，必然是一个合格的测试人员）？我可以想像一下后果：OK，设计是我们大家做出的，代码是我编写的，首先开发工程师会更关注自己的代码，而不是别人代码出现了问题（这是人之常情）；当然了，我们将来可以在规则上做出某种责任归属问题，比如某个模块出现了问题，那么开发者和该模块的测试者同时承担责任，这样就可以提高测试者对于测试模块的关注程度了，但是对于一些集成起来的Bugs，谁来负责？而且，由于这种方式，对测试大纲需要进行非常严格的控制，不然你责任如何归属（我是开发人员，不是测试人员，我可以执行测试，但是，要我对测试结果负责，必须是我能够保证我已经执行了某个确定的测试用例，你才能说这是我的问题啊）？那么结果就是两个，要么项目经理兼职做测试主管，要么提一个人起来做测试主管，很简单的结果，不是吗？那么我就不明白了，为什么要那么复杂地解决一个问题呢？这也会造成考核上的一些问题，因为开发工程师的岗位说明书上，没有测试别人代码的职责，你如何考核？等等，说白了就是一点，这种方法，基本上就是胡扯。提出这种解决方案的部门经理，不认为自己多少有点搞笑吗？反正我绝对不会执行这样的方式，就象我不会用技术来解决沟通问题一样，我也不会用所谓的项目流程来解决People manage的工作。而且，把测试的结果完全寄托在测试大纲的完整性上，无异于把自己放在一个危险的境地中，这恐怕过于相信自己的用例设计实力了。我可以容忍小项目组中，需求设计开发人员一路走下来，但是我无法接受开发测试合二为一的做法。如果这样，最简单的方式，就是说服一个哥们，干一段时间专职的测试好了（你可以和他说：靠，哥们，大哥对不起你，我无能，找不到合适的测试工程师，你帮哥们顶一阵子，3个月以后，如果还没有人到位，大哥来替你），要么你就干脆自己冲上去摆平这件事。而不是提出一些类是而非的解决方案，然后问题就是下面人来承担了。这是我所比较鄙视的做法。当然了，有一些公司本身就没有测试，坚信用户就是我们的免费测试人员，呵呵，我也看过也做过。这就没有什么好说的了。这样无顾忌得看待自己的客户，我觉得你有义务把自己的特长贡献给公务员领域（尽快尽快，将来恐怕也不好干呢）。

接着，项目进行开发了，一般来说，我们总是按照某一个周期进行集成和发布，这时候，测试也将对新出现的功能进行测试。一般来说，开发团队需要在下一次版本提交的时候，修复这些Bug。而且原则上说，这些Bug修复的优先级是高于代码的构造的。我总是不希望把一些没有修复Bug的版本，当做一个正常版本发布，因为这会导致过程估算的误导，认为我们项目已经进展得非常顺利了，但是实际上，在最后可能会埋下一个雷的。同时，测试工程师需要反馈，在测试过程中，发现测试大纲的某一些不完善的地方，或者某些用例实际上是可以合并的，对测试大纲进行修整和改进。这也是必须的。我们承认自己可能犯错，但是这些错误需要提供一个正常的渠道进行修改。在不断的提交版本的间隙进行这方面的修改是一个良好的时间。这将使得测试大纲逐渐地更加符合项目，并且这些修改，将使得我们能够对后期项目集成测试的时间进行更准确的估算。

如此循环，一直到项目的构造基本结束，全部模块一起集成起来了，这时候会进行全面的测试，这种测试会以一定的周期进行，比如一周进行一次。这时候，由于已经进入到后期，所以，在非常紧急的时间压力下，我们可能会采用每天下午4:30，进行一次Bugs Review，来确定这些Bug的修改人，以及这些Bug修复的时间等等（在一定程度上，这种方法的确能够提高团队对于Bug修改的重视程度，而且，可以使得团队对于Bug了解更深入一些，同时，可以避免做一些无用功，防止修改了半天，发现最好在另外一个地方修改，并且，由于在项目后期，所以很多Bug未必就是编码期间的Bug，有时候可能出现需求Bug或者设计Bug，这时候，需要尽快决定修改方式来推进）。每天就昨天Bug修改进行一次反馈。当然，在全部周期中，我不太愿意采用这种方法，因为害怕这种会议如果长期使用，慢慢得可能变成一种形式，在平常开发中，我还是愿意采用周例会制度。

进入最后，一般来说，我们会根据Bug衰减的速率来预测测试过程和修复Bugs的过程是否正常，一般来说，Bug应该呈现出2/3的缩减率开始减少（在每个周期内），这样的Bug图表基本上的正常的，如果Bug突起突落，那么很不正常，还需要进一步测试（当然这是建立在良好的Bug填报制度的基础上的，如果Bug填报的制度不完善，那么如何总结都是胡扯）。一般来说，如果是严格的要求的话，一般来说，在1-2个周期的全面测试过程中，仅仅出现2-5个微小Bug，其他没有什么太多的Bug出现，那么这个版本基本上就可以提交了。当然，国内的大多数项目，基本上到不了这个地步，首先我们给予测试留下的时间太短，一般来说，如果真的要达到这种地步，需要留下和设计以及开发相同的时间，测试人员和开发人员之比需要是1:1，基本上可以到达，但是一般我们使用的时间只有1/4，能够让整体流程顺利运行起来，就不错了。这是成本所导致的必然，所以，请各位测试经理和研发经理注意，如果你的产品要求质量很高，那么请至少按照以上比例来安排测试时间和人员。

以上基本上没有涉及性能性测试、稳定性测试以及灾难测试的东西，下面我简要的就我在工作中的做法，做一些说明，这一点在专业的测试人员面前无异于班门弄斧，但是为了完整性起见，还是写下一些比较合适。

性能性测试一般我们如此来进行：首先建立业务模型，比如一个BBS系统，我们根据以前的类似系统的参数可以知道，平均每个用户在网站上会停留10分钟左右，那么在这10分钟中，我们假设用户会进行发表2个新贴子，浏览30-40个贴子，需要登录一次。OK，那么我们就把这种业务做为一个总的“事务”，然后根据总体的性能要求（比如希望每个网页在不考虑传输的情况下，基本上在5秒左右完成打开）。这样我们知道了如何在压力工具上设计事务，也知道我们的目标是什么了。接下来，我们就该建立一个基本的环境，虽然从理论上来说，使用TCPP数值可以完成不同服务器性能之间的换算，但是这一点我在具体的性能测试中，发现其中不是直线换算关系，所以，如果可能，我尽量使用实际的服务器（当然，你的系统的目标服务器如果是IBM小型机之类的高端服务器，那么你还是老老实实和设备提供商的工程师进行性能方面的讨论吧，按照他们的建议来进行性能测试比较好一些），而不使用低端服务器来模拟高端服务器。而且网络的结构也类似于正式环境。然后开始测试了，一般来说，我们会首先压上20-30个并发（按照一般PC机的性能，一般每台PC机器发起10个并发），取一次数据，然后压50、100、200个并发（这对于每天处理百万级PV的系统来说，基本上够了，如果访问量更大，适度增加，但是记住一点，压得太高的并发，实际上意义不大，因为最后对我们来说，有价值的数据不是并发量--这是一个无法衡量的数字--我们所需要是的每秒业务量的数据），然后开一个表格，把统计出来的并发数量，相应时间，平均每个业务处理时间拿出来。

我举一个例子，比如一个系统，一个业务模型中包括50个业务（这是真实业务，比如有的网站中，一个Frameset中包含了5个Frame，你不能把这个算成5个业务过程，只能算一个），然后用100个并发来压，平均每个业务跑10次。假设在500秒内跑完了全部的并发操作，这样一共跑了50000个业务，平均每秒处理业务数量就是100个（这对于一般的业务系统来说是个比较高的数值）。

然后，我们就可以计算了，假设这个服务器来说，大致的访问时间是8:00-17:00（也就是10个小时），那么在10个小时中，一共有36000秒，每秒处理100个业务，也就是每天基本上可以处理360万笔业务。为了应付尖峰时期，我们对360万除以1.5的经验系数，也就是这套系统基本上可以应付240万的业务访问。如果是互联网应用来说，这个数值基本上可以直接对应到日常统计所使用的数据，看看这个数值和其他业务系统来比，性能如何；如果是业务系统，你就需要观察一下，平均每个用户每天处理的业务模型了，这样的业务模型相对来说，就不是上面那么简单了。但是也是使用相同方式来建立模型和大致估算。

同时值得关注的另外一个数值就是每个响应在这样的压力下，平均响应时间是多少。比如上面我们说过是希望在5秒以内，我们就取90%以上访问在5秒以下的那个压力来计算就可以了。

这种统计方法的一个好处是，相对来说比较容易操作，而且数值和客户的使用密切相关；而且对于开发来说，他提供了一种瓶颈的判断方式，比如我们发现性能不能满足要求，那么我们就应该寻找在业务模型中，花费时间最大，而且交易量最大的那个业务着手处理，比如一般来说登录都比较慢，但是他未必就是值得投入最大精力去解决的，因为这一般来说，在业务环中占的比重不大，即使提高得比较多，也未必能够提高很多总体参数。当然了，如果你真的觉得登录速度很重要，那么单独做为一个指标来做，也是适合的。

而且，在性能测试中，一定要注意CPU和内存情况，如果内存一下子全部吃掉了（这一般来说，可能性不大），或者在数据库服务器上，CPU占有率超过了60%，都是值得注意的，在压力环境下，如果出现这样的情况，服务器持续运行时间如果比较长的话，可能存在部分问题。还是适度降低一些比较好一些。

下面，就性能测试讲一些改进的方式，一般来说，数据库访问应用中，对于性能影响最大的现实例子包括，没有使用Connection Pool（不过我觉得，现在还这么干的人，恐怕不是很多的吧，太幼稚的错误了）；无节制地取出大数据量，然后在内存中进行分析，而不是使用恰当的做法，使得复杂操作能够在数据库内完成，只取出你需要的数据（数据库IO对性能的消耗，在大数据量的情况下，会占绝大多数的性能损耗），这一般出现在开发时间小于2-3年的开发工程师身上；由于对数据库SQL不熟悉，从而把某一个数据集取出来以后，然后根据其中的某一部分的数值，再次进行检索，这将引起极其大的开销，和适当的撰写SQL来想比，将导致数量级别上的性能损耗，这一般出现在开发时间少于1年的开发工程师身上（偶尔在一些老手的程序中也会发现，这实在有点不负责任了）；没有适当使用数据参数绑定，使得性能下降，这在绝大多数团队的开发中都存在……一般来说，你使用数据库监控工具，去分析某一个时间段中的查询，会发现很多问题的。如果是Java程序方面的性能问题，一般来说，你使用一些性能测试工具去跟踪执行，同样也会发现瓶颈所在。要说的一点是，这些工具只是告诉你性能瓶颈在何处，具体如何来做，还是需要依靠有经验的开发工程师的。

性能测试的结果一般来说，对于一台SUN低端服务器做为APP Server，DB被分拆在另外一个服务器上，那么每秒业务量80是应该能够比较轻松做到的。当然，这需要你的业务足够扁平，如果你的一个业务处理非常多的事情，那么你应该反思一下，你是否真的那么需要在一个业务中，做那么多事情了。对于性能来说，框架设计固然能够打下一个基础，但是在编码过程中，造成的损耗也是不可忽视的。比如在一个典型的业务处理系统中，在框架设计中，每秒业务量基本上达到360-380，但是，在系统出现的时候，实际处理业务量降低到100左右。下降得非常厉害。而且这个项目在过程中还是比较重视性能的，要不然可能下降得更厉害了。所以，PM尽量不要去说，我们的业务系统复杂啊，我们的业务大啊之类的话，所以需要非常好的服务器，首先考虑考虑你的业务系统是否有提高的必要。当然我不赞成无限制地去做性能提升，毕竟后面提升的难度越来越大了，但是如果不做一次系统性能的调优，那么实在有点说不过去呢。当然，如果你的系统仅仅20万每天的访问量，即使使用一台低端服务器，也没有太大必要做了，这种访问量，如何做都不会死人的。

稳定性测试方式和性能测试很多相似，但是一般来说，如果时间足够，我们会使用轻载情况下，比如5-10个并发，持续压2周，如果不发现系统问题（比如内存的持续上扬等等），基本上可以认为问题不大。当然，在业务设计中，你需要更仔细一些，尽量能够覆盖住客户的全部操作比较好一些。不要仅仅跑2个业务，跑死了也没有用的。另外一种是重载情况下连续运行3天左右，这主要是因为我有时候发现系统在轻访问量的情况下，反应还不错，但是压力一上来，经常会发现一些奇怪的问题，所以我也倾向于使用重载情况下的测试。当然，稳定性测试的时候，尽量保证系统的平稳运行，不要因为别人给你把机器关掉之类的事情发生，很郁闷的。呵呵，想起来一点，以前有一个哥们为了下班能够下载游戏或者电影，但是怕别人把机器给他关了（下班不关机器，如果被抓，可是比较讨厌的啊，是需要通报的），于是一年四季在自己PC上贴一张纸“稳定性测试，勿动！”，结果一年下来，连保洁的阿姨都不敢替他擦机器了，他的机器显得比别人脏很多啊，呵呵，现在还记得那张忽忽悠悠的纸张，飘动在机器之上，隐隐约约从中可以看见那个哥们的一个烂人模样啊。哈哈。

破坏性测试，难度相对就很高了。绝大多数在系统运行过程中，发生的奇怪问题，都是某一个地方意外出现问题以后，而发生的。比如，一个短信Proxy程序，曾经有一段时间，在和网关失去连接以后，会持续连接，系统会变得很不稳定。等等，这需要测试人员分析系统的各个组成部分，然后使用某些手段，来制造一些异常，来看看问题何在了。当然，在一些协议性测试工作中，这种工作就相对来说很多了，给协议机发送各种错误的协议等等，来模拟各种网络错误，这就是必须的了。呵呵，这一点我没有太多建议，因为这需要单个Case来讨论了。只能说一点，如果必要，你就是做一个错误发生器，对于关键应用来说，都是值得的。因为系统如果上线以后，从现场重现这种错误，难度极大（首先，客户不允许停机来处理Bug，首先必须恢复系统，其次，一旦系统恢复了，除了常规的系统日志，应用日志，你再也没有其他的手段了，只能在相同环境中重现，即使在其中花费1周时间来发现错误，都是很常见的时间，这样成本就高得可怕了，而且这类问题多了一些，会使得我们的客户，我们的开发人员信心急剧下降，士气低落，相比之下，还是事先做一些事情比较好）。我弟弟做了N年的嵌入式开发，他们的测试工程师经常在外设还在读写的时候，突然断电或者突然拔掉数据线，如果发生问题，就当Bug汇报，并且露出阳光灿烂的笑容，很难想像一个一个刚毕业不久的小女孩干出这么粗鲁的事情，很让人惊讶啊，不知道会不会造成心理阴影，形成虐待的倾向。但是这也是必须的，至于用书把回车键（或者其他任何键）压住，然后回家了，回来发现应用程序出错，就是家常便饭性的工作了。

好了，说了很多关于测试的工作，其他也没有什么好说的了。好的程序不是测试出来的，这一点是真理，但是另外一个真理是，好的程序背后必然有一个好的测试，这也是真理。

开发人员

OK，产品开始构造了，这段时间中，一般都是团队士气比较高涨的时期，看着产品逐渐地被构造出来，而且没有很多烦人的事情，这一切都很愉快不是吗？我想绝大多数开发人员都有这样的感触，疯狂地写代码，然后看见程序逐渐地出现，这是一件多少令人愉快，且具有成就感的事情啊。

那么首先，做为一个开发人员，从项目经理的角度出发，希望什么样子的开发工程师，会认为是一个好的开发工程师呢？

首先，我们希望他的思路清晰，这是一句类似于废话的表达，我们希望所有的人思路都很清晰，但是这的确很重要；

其次，我们希望他思维慎密，我们代码的一个大问题是，只考虑正常路径，对于异常路径考虑不足，这在小型应用中，一旦出现问题，很容易进行判别，但是对于大型应用来说，一旦逻辑由于异常而飞掉，那么想要判断出来问题何在就很麻烦了。异常路径的考虑绝不仅仅是Try，然后Catch一把这么简单。记住这一点，在你写程序的时候，多考虑一下，如果这样会发生什么？如果那样会发生什么？如果用户不按照你的设计的流程来做，那么结果是什么（即使你说，程序会出错，也没有问题，但是必须是我们知道他会出错，而不是不清楚结果是什么）？如果I/O出现问题，那么会发生什么情况？等等。

再次，我们希望不管你面对的压力如何，请动动脑子，不要写一些采用一些非常近视，将来必然会发生问题的做法。原则上来说，这些问题应该设计来解决，但是正如我们所知道的，设计一般来说，真的很难做到那么Detail，那么还是有很多问题，会留在开发阶段来解决。我在2001年看过一个程序，这是一个贺卡发送程序，用户点击了贺卡发送后，会生成一个页面，然后把URL发送给接受贺卡的人员邮箱中，开发人员把所有的贺卡生成的页面都放在一个文件夹中，结果时间略微长一些，在那个文件夹下，就生成了上百万的文件，以至于系统维护人员几乎认为机器崩溃了，因为根本无法访问这个目录。这是一个很幼稚的错误，不是吗？如果多考虑一下，这些错误是可以很容易避免的。而且很麻烦的是，这些问题，如果不是在使用中，你采用功能性测试，是根本无法测试出问题的。

另外，尽量采用规范化的代码撰写方式进行代码的撰写。我虽然不是很赞成采用上百条的代码撰写格式来约束大家的思路，但是常规的做法还是需要做好的，比如代码缩进等等，尽量使自己的工作看上去专业一些，不是对于我们来说，更好一些吗？

另外，一般来说，项目经理会和你就你的工作进行沟通，比如本周是否能够完成某一个模块程序的编写，请合理进行估计，如果你确实不能完成，请第一时间告诉你的项目经理，这对于他的工作非常重要，同样，对你的工作评价也很重要，请保护一下自己，也保护一下你的项目经理，让大家工作多少愉快一些。不要去承诺自己无法完成的工作！

另外，我希望开发人员能够具备良好的沟通能力，当你发现一些问题的时候，请提出来，不要想当然地去解决，你的解决方案不见得就是我们所希望看见的解决方案。在PM一级，他们看见的东西会比你多，所以判断事情的准则也会比你高一个层面，有时候从你的角度出发的一个好的解决方案，从整体来说，未必就是一个好的解决方案；

另外，请务必在你撰写代码以前，进行单元性测试的代码的撰写。你需要明白，你应该如何自动化测试你的代码，而不是仅仅写一个Main函数，然后简单跑一跑，就认为可以提交了。健壮的模块，是一个良好稳定程序的先决条件。所以，如果你需要，可以把开发时间拉长一倍，但是我更希望你的代码在提交测试以前经过你自己良好的unit test。

最后想说的是，做为一个开发人员，不要被所谓的蓝领程序员一说给迷惑了。如果有人愿意使用蓝领程序员，那么他们可以去使用，这是别人的自由。但是做为一个优秀的开发工程师，你永远都能找到一个组织，他们希望有第一流的开发工程师来进行项目的开发，而不愿意使用所谓的蓝领程序员。理由很简单，开发工程师也许将来使用的工具会越来越高级，比如最初的时候，我们用汇编来执行32位乘法，非常非常累人，但是今天在Java中实现一个乘法，则是很容易的事情了。但是，这只是我们的工作在日益向我们的客户靠拢，去考虑我们所最需要关注的东西，而不是说，我们就不需要好的开发工程师了。开发工程师是一种美妙的，值得终身去投入的职业，一个8年工作经验的开发工程师，撰写出来的代码不是2-3年经验开发工程师所能够比的，这一点我深有感触，在一些关键性模块中，我情愿付给高级开发工程师2-3倍于初级工程师的工资，来进行关键模块的撰写，从长远意义上来说，他们的成本相对更低，因为节省了测试成本，而且程序更健壮等等。这一点我想很多项目经理会更有感触。我坚信一点，无论时代如何进展，只要这个工作是一个头脑驱动的工作，那么我们就永远无法象管理流水线上工人一样，管理软件工作者，我们还是需要采用知识人员的管理方式进行管理。当然，蓝领这个词本身就是一个很模糊的用词，我倒是觉得，如果说我现在的工作是蓝领的话，我也无所谓，蓝领就蓝领吧！但是奇怪的是一点，当传统行业都开始越来越重视流水线上工人的主观能动性的同时，我们中国软件行业倒是开始贬低自己的开发者了。并且认为这种观点，能够是推动中国软件业的发展的根源，这多少让我有点感觉奇怪了！

在软件行业，我们不时听到这样一种声音，某某公司又提供了某种中间件，某种系统级的开发不需要开发工程师来完成了，所以我们的代码越来越简单，我们的入门门槛越来越低了，我们将变得越来越没有价值了。从某种意义上来说，这是对的。原因是我们很多软件工程师的技能集中在工具使用上，和API使用上，那么一旦开发工具发生改变，你的很大一块知识将变得过期。当然了，你非得这样定位自己的核心价值，你被工具和时代抛弃就是必然的了。但是在另外一层意义上来说，这句话也是错误的。如果说开发工具可能变，但是根本的设计方式和根本的一些理念，是不会发生变化的。我在1998年使用ASP开发，2000年以后，基本上使用Java和一段时间的C++，我没有明显感觉使用JSP就和ASP不一样，ASP+DLL的模式我看起来和JSP+JavaBean没有什么太多的不同。我们该如何设计还是如何设计系统，现在我们使用EJB或者使用dot net，除了某一些特征点以外，还有多少根本的东西在发生变化了吗？我们还是不断在需求阶段给项目埋下最根本的失败根源，我们还是开发出大量无人使用的软件，我们还是在抱怨别人的设计是如此低能等等。而且，无论使用何种工具，无能的开发者开发出来的程序，要不是很难使用，要不就是根本无法使用。当你觉得开发工具不那么重要的时候，就是你在驾驭开发工具来实现你的想法，而不是开发工具在指导你的思维的时候，这时候，你会更上一层楼了。

好了，开发人员大家自勉，为能够开发出一个好的，能够有大量的人来使用的软件而努力吧。虽然这70%取决于你在哪个项目组，30%取决于你的努力，但是，让我们做得更好吧。让很多愚蠢的说法见鬼去吧。我们踏实做好自己的事情就可以了。

设计人员

对于一个15-20人左右的开发团队来说，设计人员在项目中，主要完成项目的总体框架设计工作和设计工作，一般的来说，由于他们会承担一些Code Review，以及一些系统级的工作（比如集成发布等等），并且承担一些核心模块的开发工作。在这个环节，我们主要把精力放在设计环节上。

首先做一个定义，我同样不清楚书上是如何说的，说设计是什么。在实际操作环节中，总体设计的产出的标志，一般是package能够确立，并且package之间的协议（如果有的话），协议确立一个0.1版本，设计的一个中间阶段的产出是（常说的概要设计，但是我现在倾向于这两者不做那么严格的分离，实际上，也很难做什么太多的分离）文件目录确立，比如对于WEB开发来说，一般采用Frame结构，以及Frame结构内的页面名称基本上已经确立，并且很清楚，在每个页面中所需要完成的工作是什么，更严格一些的要求，需要把Class也确立出来，接口函数定义等等基本产出，空Project基本上确立起来就可以了。当然这个目标是比较难以达到的，但是如果能够做到，能够为后面的工作，减少很多随意性。

OK，定义说完了，接下去，我们先讨论一个问题，如何看待设计和编码之间的结合，一般来说，15-20人的团队，其中只有一个设计人员可以不延续到编码阶段，因为在研发过程中的种种调整工作，会消耗他的很多精力，对于更小的团队来说，独立设置设计人员，强制分离设计人员和编码人员，实在是意义不大的，理由很简单，你的沟通成本太高了，在过程中，可能产生的误解也太多了（当然，这通过统一设计语境平台等等，可以减少这些误解的机会，但是没有一种方法，可以避免这一点，而且就现在来看，这种方式也是执行成本比较高昂的方式）。

请大家明了一个事实，不要被误导了，很细的分工会使得工作整体提高效率的一个前提是这个工作相互之间的交流不多，比如流水线上的工人，事实上，他们并不需要在工作中进行太多的交流（你看见工厂工人，经常会离开办公位，到另外一个工人那里，说我觉得这个地方应该这样干，而不是现在这样的吗？我从来没有看见过，嘿嘿，这是我大学的2个月的学工生涯中，看不见的和听不见的）；另外一个情况是，由于我们的Project的原因，前期我们无法进入到编码阶段，于是使得我们可以在很长时间中，来充分利用这段时间，进行事无巨细的设计过程，但是，我们在编码阶段需要在短期内构造出大量的代码，在这种情况下，迫于时间压力，我们不得不采用早期疯狂的完美设计，编码阶段才可能加入大量的人员来进行编码工作。但是，以上提到两种方式，在目前我们开发的项目中，存在得并不多，我相信总不会有人说，我们的研发不需要相互之间的沟通吧？而且对于我们的项目来说，我们早一天开始或者晚一天开始整体的工作，实际上并没有严格的约束条件。所以，该早一点开始的还是早一点开始吧。我推荐的一种方式是：人员逐步投入，高级开发工程师最早进入到项目中，开始一些技术难点的预研工作，并且承担框架设计工作，建立一个良好的可扩展的框架以后，中级工程师开始介入进来，进行后面相对Detail的一些设计工作，包括类结构的设计等等，最后，在进入非常Detail设计的时候（事实上，这个阶段，我们基本上已经开始了编码，更详细的，比如如何从数据库中取出某种数据的方法等等，一般来说，是不独立去做设计的，至少我还没有这种自信，认为自己在这方面能够想的如此周全，这么Detail的工作，还是谁具体操作，谁具体来做吧，只要建立起来一个Review的制度，由中级工程师或者高级工程师把把关就是了，我们总不能把每一个函数的每一个处理逻辑都列出来的，如果真的那么自信，也许你主持开发一个自动化代码生成工具，会很挣钱的，相信不少坚信蓝领程序员是解决软件问题的公司，对此一定会花大价钱购买的，呵呵，糊弄一些自以为专家的人的空谈者，这种事情我比较喜欢），初级一些的开发工程师，在中级工程师的指导下锲入项目，进行项目的细节设计和编码工作。

写到这里，我突然感觉，软件行业实际上就象一个混沌系统，我们企图不断明晰这个系统，但是这个系统是无法无限制明晰下去的，因为外界的扰动，使得这个系统会不断陷入混沌。就象我们对待需求一样，你不可能限制需求的变更，我们所做的就是，在风险容忍的情况下，使得需求的变更尽量有序化一些而已。类似的，在软件行业中，我们只是在风险允许的情况下，设置一个混沌上限；在成本和操作性允许的情况下，设置一个混沌下限，然后在其中研发软件，仅此而已。在我看来，这至少是在目前来说，相对实际一些的想法。

好了，在下面，我会来谈谈，我希望设计人员能够具备哪些特制呢？

我一直说一点：设计一个系统，更多的是一种艺术，而不是一种科学。比如我有时候，看一个系统设计，在第一眼，就感觉这个系统设计得让人很难受，但是，具体如何难受，暂时还说不出来，但是随着对系统的更进一步的研究，发现问题原来如此如此。你一定要我说，为什么你第一眼就感觉难受，我真的说不出，我只能说这是一种直觉，仅此而已。我相信，很多做设计的同仁们，一定也有和我一样的感觉，因为我们经常在层次以及复杂度，过度设计和无设计之间不断平衡，而且我们也看见了太多的设计，在后来的系统研发中，到底是如何的经验，也许正式由于此，给我们留下了一种直觉的东西。

举一个简单的例子来说，数据库设计范式，想必在学校学过数据库的同仁们都明白三大范式是什么，比如我们有时候，在後段经常需要进行数据集市，进行BI操作的系统设计的时候，会非常自然和倾向于使用星形的数据库设计，一张主表来记录基干信息，然后其他表象众星拱月一样，记录辅助的各种信息，这种设计从逻辑上来看，非常干净清楚，而且将来的扩展性也比较好一些。但是，这种设计会使得系统频繁地发生跨N个表的查询，这对於大型应用来说，要求性能比较高的系统来说，在一个数量级以后，就将是一场灾难了。另外的，比如我们使用冗余数据来作系统，虽然使得查询效果急剧上升，但是由于冗余数据，使得数据的维护变得很复杂，可能使得系统中存在若干个逻辑中心，这些逻辑中心包含了太多的逻辑，以至于似乎任何更改都必须记住他们。这是一种很难受的设计，而且系统也显得不干不净的。但是，你说不上什么一定对，或者什么一定错。在这个方面进行权衡的一般准则，我是如此来做的，对于一般系统来说，我倾向于采用非冗余的干净数据库，但是当数据量上升到G以上的级别的时候，我会小心一些，当数据急剧上升到更多，比如主表数据在3000万以上，辅助表的数据也同样在1000-3000万之间，那么我会考虑采用发布的技术，在某一个节点进行数据发布，采用冗余数据的方式来做。但是对于绝大多数系统来说，这是不必要的。采用冗余数据，纯粹给自己找麻烦。你可以通过数据库Housekeeping的工作或者历史数据和业务数据进行业务上或者逻辑上的拆分来做这件事情。

这就是我所说的，平衡感，这对於一个良好的设计人员来说，是非常重要的。

第二，设计人员需要具备一个开阔的技术视野，这样对你的设计来说，将变得更有益处。比如系统级别的HA解决方案，比如各种常用的中间件技术或者某一些解决方案，还是需要知道的。不然，你将不得不自己去做很多问题的解决，从前大家犯过的错误将再次重犯一次。比如SSO（单点登录技术），在很多公司都有成熟的解决方案，相对的来说，对系统资源消耗较少，而且对应用程序修改较少，但是我至少2次听说过有人用自己的解决方案来处理SSO问题，结果可想而知。做为一个软件设计人员，你必须明白，我们的工作不是从头开始自己做一个系统，而是在一个平台上来构造一个系统就可以了。所以，如果有MVC框架，为什么不使用呢？

我记得在一次BEA的内部培训中（那是2004年1月份），那是一个昏昏沉沉的下午，我偷偷睡了一个小时，醒来的时候，发现讲师还在无聊地讲着BEA Weblogic platform中的Portal技术，一通猛吹，让我感觉比较不爽，本来就是一个内部讲解，没有必要讲得云里雾里的，于是问了讲师一个问题：“你觉得BEA Weblogic platform到底为我们带来了什么？你是否意味着现在Platform中所附带的一些开发工具等，能够应付我们将来的开发？”。讲师很诡异地笑了笑，沉思了5秒钟，说：“Platform给你带来的最大的价值在于，他建立了一个良好的框架，在这个框架中构建你的应用，将使得你的应用在系统结构层面上比较好，而且扩展性比较好，仅此而已”。这一点让我记忆到现在，当然我不清楚Protal现在是否比去年要好了很多，但是这个观点，使我受益不浅。

第三，明确的价值观。知道什么是一个好的设计，什么不是。有时候，看上去能够上课程书的设计，并不一定是个好设计。这个理由很简单，课程书上的设计最重要考虑的是设计的优美性，但是在实际项目中，我们面对的是客户的需求，在能够满足客户需求，并且略考虑一些将来的扩展性的考虑，就足够了，你没有太大的必要来做非常复杂的设计。

设计人员和开发人员分离，导致的另外一个后果就是，设计人员企图做一个框架上完美的设计，但是这种设计实际上意义并不是很大。我举一个现实的例子，在我们做权限，角色，人员对应关系的设计时候（当然，有时候我们也会加入组织结构这个因子），我们往往会考虑很多的东西，比如为了SSO，使得我们必须把一个服务做成需要接口验证，密码通过MD5加密，来使得访问能够安全一些，为了使得灵活性更高，我们往往会内置一些逻辑，生成一些根据组织结构的缺省的角色，为了使得各种数据结构可以在后期方便更新，我们需要采用Profile技术来运行期定义数据结构等等，我曾经给一个朋友做过这样的设计（这是在2003年左右），仅仅是概念级考虑的框架设计文档，已经达到8页Word文档，考虑得非常周到，当时我对于这个设计，感觉还是比较不错的，但是现在看起来，有点让我脸红了，这个设计如果真的需要实现出来，基本上需要5-6个工程师的Team，工作3-4个月的时间（这还是比较保守的估算），那么在一般项目中，用这种设计方式进行设计，几乎是必定不实用的。所以，不要说什么设计一定是好的设计，什么设计一定是不好的设计，判断的唯一标准就是是否满足了客户的需求？并且在将来的时候尽可能方便得进行修改（当然，上面两点是冲突的，在出现严重冲突的时候，我建议你以第一个准则为主，因为将来方便进行修改是主观的，也许你今天考虑的很多东西，根本不可能出现，你为此白白做了太多的事情，不值得），开发成本是否能够接受？

第四、要明确，一个好的设计，来源于对业务系统的良好理解，设计不是脱离业务存在的，比如你做一个BI系统和做一个业务系统，在包括数据库设计、框架设计方面，几乎是不相同的。而且，我们在具体的工作过程中，也能经常得发现，一个没有很多开发背景，但是思路清晰的业务人员，在进行框架设计的时候，也能提出很多好的想法，甚至组织这种设计工作。原因很简单，他很清晰客户的需求，并且能够自觉地把客户的概念融入到设计中，由于此设计和客户的概念是相互融合的，所以在将来发生实际的变更的时候，他的修改也相对更容易进行。我举一个例子来说明这个问题，比如我们在设计工作流的时候，大家都知道WFMC模型，我们按照WFMC模型进行各种节点的定义，流向的定义，在后面半年的开发中，我总是发现，根据这套模型走，加入一个新的功能，没有对我们原先的设计产生非常严重的冲击，这一点让我很佩服，这是源自于对业务的良好理解和切分。缺少对业务系统的良好理解，就企图能够做好High Level Design的工作，这一点实在有点过于自以为是了。

第五、不要轻易地决定去做一些系统级的东西，因为这些东西往往在严厉的环境中很容易出错。比如除非万不得已，我绝对不企图自己去撰写DB的ConnectionPool这种东西，首先看起来他很容易。OK，建立一个缓冲区，在启动的时候，建立和数据库之间的连接，然后在应用程序访问的时候，分配一个Connection出去，然后在程序访问完毕以后，把这个Connection回收，以备于将来访问。但是，这种东西，真的在实际应用中，出现的问题极其恶心，比如我们发现Connection Pool里面不知道为什么，为出现几个错误的连接，其他的连接都是好的，就是某几个连接出现问题了，于是应用程序开始呈现一定概率地发生访问数据库问题，一直到现在，我也不明白为什么会发生这样的情况；当然为了解决这个问题，最简单的一种处理是周期性地进行Connection的扫描，来发现其中是否有Connection失效，如果发现失效，那么就重新建立一次连接等等；但是你想想，这种程序将会显得多么庞大啊。于是除非我走投无路了，我一般不进行类似工作。至于有一些无知而可笑的设计人员认为，这些系统级的工作很容易做，Connection Pool可以自己来干，甚至撰写一个Java容器也很容易，甚至我们可以通过20-30行代码的方式提供一种HA方案，但是在实际使用的过程中，我从来没有感觉这种HA方案能够为客户提供什么价值，他充其量是一种学术上可行的方案，但是问题是，我们不知道在什么情况下他会出现问题，而这种软件就是要在错误中进行系统的维持工作的，如果缺乏系统级别的理解，我们很难进行这些工作。所以，不要轻易去做系统级的东西，因为我们没有能力做好。这不是你的能力的问题，我们绝大多数设计人员和开发人员的优势在理解客户的需求，然后快速实现客户的需求，我们没有太多机会进行这种系统级工作，因为绝大多数这部分工作，我们可以找到相关的产品使用。

设计人员需要培养一种设计美感，有的设计让你看起来，越来越觉得清晰和流畅，你几乎不用翻过来，看前面的设计，这是因为他的设计元素安排和一个业务系统丝丝入扣；有的设计，简直就是一堆概念的综合体，仿佛仅仅为了设计而进行的设计，概念被杂乱地堆放在各个角落，看起来让人觉得头疼。

以上，是我对设计的一些基本的观点，当然，具体的做法还有很多，这里就不展开了。

最后，我想说一下，如果做为一个开发人员，那么你如何提升你自己的设计能力呢？我想这个话题是我以前的一些同仁们，很多次问起的一个话题，也是很多初进入软件行业的开发人员所好奇的东西。我也能够理解，因为当年我也是如此一步一步走过来，也面临同样的困惑。一般来说，我是如此增强自己的设计感受的：

首先，我会挑选一个项目，我自己认为做得不错或者做得不好的项目，然后使用半天时间，试图在一张PPT上，用各种图形把这个系统关系搭建出来，并且画上数据流向图，以及相互引用关系图等等，而且层面应该比较高，因为在一张PPT中，你实在没有精力去做出太多的东西。这是强制让你放弃某些更细节的设计，把注意力放在和你的产品（或者模块）的最上层的设计本身，然后，你可以修改这张PPT，我的概念是，一般来说，这张PPT需要进行5-6次修改，才能让你自己满意，他的各个箭头都是正确的，他的各个模块的层次结构（是平行的，还是从属的？是相互依赖的吗？你需要挑选一种方式，把这些关系表达出来）。如果你第一次着手进行这方面工作，我建议你参考一下别的产品的PPT，比如你可以看看BEA Weblogic Platform的一个简单的图，看看他是如何把各个产品放在合适的位置上位置的。就这张图，我和我太太曾经讨论了一个上午，因为我太太认为BEA的一个产品在产品线图上放错了位置，因为感觉逻辑上怪怪的。结果我们讨论了一个上午，发现这个位置没有放错，而且放得很巧妙。通过这些工作，主要培养的是2个能力：清晰的逻辑判断能力和整体思维能力；通过这种方式的锻炼，你对于各个不同模块之间的关系，以及层次的合理性等等方面会比较敏感一些。

其次，如果可能的话，找N个朋友（N<5），其中至少有一个设计方面比较有经验者，然后你们挑选一个小，而且大家能够很容易理解的方向（比如说一个简单的用户进入超市，购买商品，然后付款的流程），提出一个简单的，最Base的需求，大家分头去准备设计文档（不一定要用Rose等等，挑选任何你能够完全表达你意思的工具，我觉得白纸就不错，在跟随思路方面，至少我还没有发现更好的工具是什么），经过1周的时间，设计准备完毕了。你们找一个周末，准备至少半天的时间，每个人告诉别人，自己的设计是什么，为什么这样设计，实现这种设计，如果你来完成的话，需要多少时间？然后，大家把自己的设计图给挂起来。下面就是现场的变化了，牵头者不断提出：客户需要如此变化，客户需要那样变化，你的设计该如何来尽可能容纳这些变化，在容纳这些变化的时候，你的开发时间将如何变化？最后总是有人的设计崩盘了，没有关系，这表示我们的设计在某个点上是不能够容纳这样层面的变化的，看看其他人如何做？最后，我们挑选出一个设计，他能够最大限度容纳变化，而且研发的成本也相对比较低，把所有后面加上去的那些设计变化去掉，在原型本身，让这个人说说，他是如何考虑的？也许仅仅是运气好，也许是考虑比较深远，最后大家做一个总结，散会，找个地方去放松放松脑子好了。一般来说，这半天的工作，是比较累的，而且收获是比较大的。唯一需要注意的是：不要把设计水平相差太大的人合并为一个组，这会使得有一部分时间，一部分人觉得难以明白，有点类似空谈；另外一些人觉得多少有点嘲笑他智力的感觉。同时，请牵头的人员，在准备案例的时候，请尽量用一个现实的例子，不要使用虚幻中的例子，过多虚幻的例子，会使得大家的设计偏向于过度设计，这不是我们希望看见的，而且请至少用半天时间精心准备整个案例，不然可能大家都是在浪费时间。这种方法是比较有效的，而且还顺带着进行了一些Team Building的工作，而且，如果是一个团队进行的话，也会使得设计经验最大限度进行交流；最后一点，由于设计的不确定性和主观性，将使得一个即使经验比较缺少的团队成员，也能有一种感觉，自己在某一方面是强项，从而使得在将来实际设计中，敢于和愿意去说话，这不是很好吗？这种做法，我觉得还是值得推荐的，在1-2个月内做一次，效果还是比较明显的，能够看见设计团队的能力在得到提升，并且大家能够相对比较容易建立一个共同的语境平台，并且熟悉相互之间的设计思路和理念。

再次，通过开源代码或者一些类似平台发布程序（比如MS的商务平台程序，他会为一个Project生成很多框架性代码，然后你可以根据这些框架性代码进行修改，以实现你自己的逻辑，但是框架是已经建立起来了）的阅读，来领会一些其他人的设计，这一点也是相对比较有效的。比如我相信很多人阅读过SUN平台上Petstore的程序吧。这个程序的阅读，以及分析，还是能够给人带来很多关于MVC方面的收益的。当然，这需要比较长的时间，在阅读的时候，记得旁边摆一张白纸，把你阅读过程中的感触，写一个小小的提纲，因为也许仅仅15分钟以后，你会忘记某一点收获。

最后，记得给自己一个时间，总结你的自己的设计理念和体系。我们在工作中，最容易积累的是点点滴滴的知识和实践的工作，但是，如果你的知识永远是点点滴滴的，那么你将难以形成一个基本的设计理念和基本的设计价值观，为了这一点，我们有必要在每个项目结束的时候，或者定期（我习惯是每个季度进行一次）总结，我的做法是把整个体系树立起来，比如从数据库设计，框架设计，Detail的设计，性能，稳定性，跨平台性，安全性等等建立起来一个基本的框架，然后把点点滴滴的知识放入到这个框架中，来整理自己的整体思路。经过几次总结，你会发现你对于设计的整体性方面会更强了。这一点我深有感触。

有一次在和一个咨询界的朋友聊天的时候，他说起实践工作者和咨询者的不同，实践工作者拥有大量的实际工作经验，但是不善于进行总结，所以，老是感觉没有一个整体的思路，似乎什么都是零零散散的；咨询者善于总结，但是实际工作经验偏少，其中可能可能充满着想当然和以猜测的源头而来的结论；我想，如果能够把两者结合起来，至少让我们实践工作者，也能有部分时间来从咨询的角度出发考虑问题，也许对于个人来说，会比较有利一些吧。

设计人员要记得一点，在中国绝大多数项目，甚至国外的一些超大型项目中，一个优秀的项目经理能够为项目成功带来15%左右的提升率，而一个好的架构设计人员，将为项目带来30%多的成功提升率。所以，在项目中说出你的观点，为项目建立一个良好的稳定的设计，是项目经理最为关注的。顺便说一句，我们现在之所以觉得在项目中，项目经理更重要，是因为我们的项目大多数来源于技术人员，所以我们对于管理、协调更为关注，但是实际上，不要忘记一点，如果你的团队没有良好的设计者，所有的管理、协调将无从立足。管理是重要的，但是远远不是唯一重要的因素。嘿嘿，我记得2003年在CSDN上，我写过一些东西，有一个很奇怪的现象，就是我经常在CSDN的项目管理论坛中，看见大量技术出身的人，认为自己的管理和协调能力比技术能力出色，而在职业经理人的论坛上，我却又看见不少经理人认为自己在技术（或者专业）全局的把控上，能力出众。这一点不是很奇怪吗？原因何在，大家应该很明白吧，不多说了。

OK，良好的基石由你们来建立。我看过了太多的无设计，随便干了干数据库设计，就开始全面的编码了，结果后期发现项目的结构恶心坏了，后面的程序员不断抱怨前面的设计者的愚蠢，但是同样的事情在不断上演。我也同样看见过太多的例子，设计者扬扬自得得设计出一个超复杂系统（嘿嘿，这一点我也看到很多哦），兄弟们累死累活，但是项目就是老是不稳定，老是觉得有不少问题在其中，一个系统过于复杂，必然问题多，不要把这些问题都放在开发者身上，设计者同样要对这个结果负责。

SQA人员

SQA人员，是一个对项目流程进行监控的人员。他是一个监控者的角色。我们可以想像一点，SQA使用各种方式，从项目中获取信息，并且站在第三方的角度上，来衡量项目的进程，估算项目的进展。并且通过各种通报手段进行预警等工作。

但是，恐怕绝大多数公司SQA部门似乎变成了一个文档管理部门，他们仅仅监控了项目的关键几份文档的入库，认为通过监控这些文档，就可以监控整个过程了。这是一个笑话。负责一些的SQA人员，会通过长时间的工作，感到一些不对劲，为什么我总是无法发现项目问题呢？于是私下的频繁沟通，换位思考等更有效的方法开始衍生出来，这是一个进步，比那种“文档保管员”有用得多。他们至少开始意识到自己和项目组团队不是警察和小偷之间的关系，是一种合作关系（这不是公司的大道理，那种大道理我连听都不想听）；但是，他们还是发现，自己对于流程的监控并不是那么有效，经常是外部而不是他们发现项目组问题，这似乎成了一个事后追查部门，而不是过程监控的部门。

在我和SQA人员进行配合的过程，我对以下几种SQA人员抱有好感，他们一般具备以下的特制：

1.          他们多少是参与过项目，并且很多人在进行SQA管理之前，具有非常丰富的项目管理经验，我曾经碰到过一个SQA Leader，具备6年以上项目管理经验；和他进行合作的时候，我感到至少我们能够就某些问题的操作性进行一些讨论，并且他也能理解我在项目中碰到的具体问题，并为我提出建议，如何进行流程裁减，并且执行某几个关键流程来解决目前的问题；

2.          他们是良好的沟通者和良好的协调者，他们很会换位思考能力。让一个团队或者一个个人喜欢一个“监工”，是一句笑话，但是在公司各个部门合作过程中，如果仅仅是这种关系，将是一个双败的结局，当然，SQA可以通过通报的方式，来使得项目组按照流程来进展，但是项目经理也可以通过事后造文档等等工作，来使得目标发生严重偏移。和上面提到的那个SQA的合作过程中，他经常性提到的一个词是“操作性”，我们最主要讨论的问题是：根据团队的现状，我们主要需要改进哪几个点？而不是在你面前摊开一本书，然后说：“照着这个玩意干！”。这种SQA基本上是扯淡！

3.          他们是一个数据敏感性的人，他们能够根据公司大量的项目数据，进行各种整体和搜集，从中发现问题，并且提出改进现实的改进措施。在得实和SQA的合作中，是比较让人愉快的。SQA经理最经常说的一句话是：“我如何能够帮助你在项目中进行改进？”，虽然我们所希望看见的改变，一点也没有发生，但是，至少让我感觉到了我们是一起企图让项目走得更顺利的。SQA经理，在2004年末，对开发一部的所有项目进行了综合和分析，的确让我看见了不少存在的问题，以及一些主观和客观上存在的因素；

4.          他们是一个乐于接受新事物的人，而不是紧紧抱着N多年以前的某个观点不放的。当然新观点，不一定是正确的观点，老的观点，不一定是腐朽的个观点；但是，对于项目管理过程中的新思路，和新思维的接受，恐怕并不是对SQA的奢求，毕竟这是你的本职工作；但是，有多少SQA乐于接受新的流程和过程？并且考虑在这种情况下，如何进行监控，能够给自己带来什么变化？

5.          讲求操作性，而不仅仅是原则：SQA说明需要做什么，但是具体做事的人，是项目组成员。所以，在执行一个原则的时候，请多少考虑考虑可操作性，不要发布了一堆规则，然后让大家执行。如果执行发生问题，就说是项目组的问题，事实上，这也是我们不成熟的一个表现，在公认的情况下，这一般是管理者的问题。请记住这一点，当你发布如下命令的时候，你就成了一个“具备理想化倾向的监工”，比如在没有专职文档工程师的前提下，需要对超过30份文档进行相互间逻辑的维护工作；希望通过各种流程和规范，认为能够使得所有工作不再需要经验，而仅仅需要傻瓜就能完成；等等。明确的说：这是不现实的，如果你一定要发布这种流程，请至少自己先做一次，然后再考虑如何推进，只考虑目标，不考虑是否能够实际操作的人，也许学校的课堂是一个好的归宿，但是公司不是！

在这里多说一句的是：流程是什么？流程是一种经验的固化，他的作用是使得各个团队之间的经验能够得到快速复制，并且使得一个团队快速得到成长；但是绝大多数流程缺乏前置条件，这隐藏着一个假设，即认为所有项目都能从一个一致的过程中，得到有益的指导；这实际上，是不现实的。举一个旁证，我们招聘一个管理者（People Manager）的时候，喜欢问的几个问题是：“你如何对待团队中的冲突？”“你如何对你的下属进行考核？”等等，事实上，我们大家都知道，任何一个公司中，无论是季度考核还是年度考核，都是有流程的，但是，我们为什么问这个问题，我们希望听见的，不是你们的考核表如何组成这种文档上的东西，而是你如何面对考核过程中的沟通问题，如何通过考核，来实现你的组织目标等等；我们绝对不会因为一个人掌握了一个大型公司（比如GE公司）的全套规章制度，就认为他是一个良好的管理者，绝对不是！（顺便说一句，我这里有大约100M的这样的文档模板，如果有谁认为这是一个管理者的80%的工作，请向我索要，我保证你能够通过阅读这些文档，顺利地成长为以一个出色的“规章制度管理员”）。那么为什么我们认为项目管理就是这样一种流程呢？无视项目中的不同，无视其他的前置条件，仅仅通过一些规章制度，就能做好呢？此上的话题也许有些偏激，但是这是我在工作经验中，感觉这种思路给软件业造成的损害，已经开始越来越突出了。有一个大型软件公司的老总宣称，只要给民工培训3个月，他们就能成为一个合格的软件工程师。我不相信这一点，也许这种软件也就能给仅仅通过3个月的民工所使用（当然，在这里我无意对民工表示任何的不尊，因为这一天即使到来了，我还是会尊重我手下的每一个程序员，是他们用自己的聪明来构造了整个软件，而不是流程构造了整个软件，虽然流程有助于构造好的软件）。

我做为一个比较愤青的项目经理（大家说，70年代的人，是一个愤青的年代，也许吧，我觉得我还是不够成熟，还是一个愤青，但是愤青有一个好处，就是会说出自己的不满，而不会假装喜欢），向各位SQA提出一个要求，请你在发布任何一个流程的时候，用笔计算一下，这个流程给整个开发成本造成多少影响，你的目的是什么？看看为了达到你的目的，我们是否值得付出这些成本？看看还有没有更简洁的方式，来达到同样的目的。我不希望仅仅为了煮熟一个鸡蛋，就烧毁整个村庄，虽然他也能煮熟鸡蛋。

同时，请建立自己的理论体系，不要看见文档都正常入库了，就认为一切正常了，如果项目如此简单地就能进行管理，恐怕也不需要有经验的项目经理了。请在自己每个流程企图去落实的时候，考虑一下如何逐步推进，如何在将来对这个流程进行评判，是否真的对软件有利？是否能够节省掉其中的某些部分。这是对于一个管理者来说，非常重要的活动发起能力，请多少锻炼一下自己的流程发起能力。说到这里，想起一点不同来，在很多外企，非常关注一个管理者的活动发起能力，如果一个活动不能发起，不能落实，是管理者的职责，但是很多国内的企业，把这个看成一个属下的一个执行能力。呵呵，这一点的确很奇怪的，执行能力不是为了弥补发起能力的不足的。缺乏前者，强调后者，恐怕效果也不会很好。联想的执行能力很强，但是一般来说，我们看不见强制发起的一系列流程，都会经过一个阶段的铺垫然后再开展下去（包括裁员的时候也是如此，一般提前2个月就开始有风声了，告诉你，找找自己的奶酪哦……）

如果说，我们看见不足，立即用流程规范，是一种快速变化的短期行为，那么同样的，请在发现流程过于庞杂的时候，也请立即削减流程或者适应流程。请保护保护各位公司中的项目经理，他们的精力不是无限的，他们只能有精力做好几件事情，如果什么都要做，那么他们只能做死为止了。

我推荐的一种监控过程是如此的：在项目的阶段中，设置Mailstone，不管Mailstone是什么，但是目标必须是可见的，比如某一个功能被加入到项目中，做为内部版本发布了（有一些项目经理告诉我，这对於他们的项目来说不现实，我的认识是：不可能，一个项目不可能只能在最后才能集成起来，如果是那样，所有项目管理的所谓监控都是扯淡，我们都是在空谈。如果一定要这么做，那么还不如不监控好了），相关的设计文档和需求文档被更新了，同时这些功能通过了简单的冒烟测试，被测试人员所接受，那么这个Mailstone算通过。在项目过程中通过此种方式来进行监控project的进展，成本计划和风险计划，在项目周报中体现，并且这是项目周报最需要关注的点。在项目后期，进入到集成测试阶段，那么Bug图表是必须监控的。从Bug系统中导出的Bug情况日报表和修复Bug所需要的时间等等，是可以从中看出项目是否在正常推进的。在每个Release阶段，我们需要对BaseLine的成果进行一次Review，在明确需要进行的某几个过程和文档（我的建议是，如果你的团队非常不愿意，或者你的团队还没有到这个程度，那么还不如不做，但是如果确定要做的几个过程，还是有必要加以严格监控的。我的唯一建议是：做好你能够做好的事情，就能够使得团队不断进步。），加以监控。仅仅是监控文档或者监控周报，没有任何数据支撑，仅仅是描述，企图用此来监控项目，不如说是为了收集数据，准备在后期给项目经理失败的时候，来个最后一击而已。

同时，加强和项目经理的沟通，包括公开的沟通，比如非常重要的几个会议：项目首次例会，项目的启动会议等等，这些会议还是参加比较好，不然这些信息你还是需要向项目经理咨询的。那么还是自己了解一下比较方便；包括私下的沟通，我的建议是：如果一个SQA同时监控的项目为7-8个的话，那么你应该有时间，可以就这些项目，每周和具体项目经理进行一次面谈，为时大概半小时到一小时左右，看看项目进展如何，并且反馈一些问题和意见。这些私下的反馈，会让你了解到很多台面上不能讲的话（你别告诉我，你们公司如此的公开，以至于这种私下的沟通是不需要的，我只能说，如果有这种念头，恐怕太幼稚了）。但是记住一点，不要把私下沟通的一些内容，在公司内部传播，不管是正式渠道还是非正式渠道，不然当项目经理知道，他私下沟通的内容，第二天就会放在老板的办公桌上，那么任谁都无法和你沟通了，你所要做的就是，了解这些信息，并且看看，如何处理这些问题，加强SQA和团队的合作。

做好一个SQA有1个基本的平衡能力需要把握，首先，SQA首先是一个监督的角色，所以不要费尽心机去企图讨好项目经理，这是和你的岗位职责相违背的，从一个职业素养的角度来说，说出你应该说的，是一个SQA必须的，否则要你何用？其次，SQA又需要站在一个合作的角度来进行工作，正如上面说的，监工的事情，在IT行业中，特别对于SQA来说，是一个很难做好的事情。OK，任何工作都需要在钢丝上跳舞，希望SQA的同仁们也跳的漂亮一些吧，别老是搞得自己和“人形的规章制度”一样，挺累的，不是吗？如果一件事情，你做得如此累，而且别人也觉得很无聊，那么也许这件事情本身就错了。

其实，上面推荐的方式，不管如何做，关键点就是三个：明确监控的点是什么，监控的点的产出必须是和产品产出明确挂钩的（象什么开发人员日志之类的东西，就不必监控了，意义不大，那是项目组内部的事情，如果你非要把这些文档拿出来给别人评审，那么想想你小时候为老师写的周记吧。反正我已经很多次拣到钱和很多次搀扶老奶奶过马路了），沟通能力！

和诸位SQA共勉！

需求人员

需求人员，是一个项目成功还是失败的，最重要的一环（我不想讲，是最重要的几环中的一环，事实上，任何人员，都决定着项目的生死，我们说他是最重要的一环，是因为我们绝大多数项目，失败的首要原因是项目需求模糊，混乱）。

做为一个需求人员，你需要分析客户的需求列表，进行需求获取，需求分析的工作，并且为团队整体工作，打下一个良好的基础。同时，在项目过程中，我希望他能够有相当的精力，来维护整个需求文档，因为这是我们开发软件的唯一的一份准则。

目前，需求获取和需求分析方面，有一些很不错的资料，在Xprogrammer和ITURL网站中，都有很大的篇幅去说明在和客户沟通过程中的一些注意事项，以及使用各种工具，来分析，挖掘需求的技巧。而且，不管你使用什么工具，不管你使用何种分析方式，我们还是需要认识到，需求分析，还是需要很大程度上依靠着需求人员的经验。这些经验往往是最难获取的，也是最决定成败的一件事情。

其他的不多说了，事实上，在绝大多数小型项目中（7-8人的项目组，半年以下的研发时间），我强烈建议不设置专门的需求人员（也许有些人说这是小作坊，小作坊也没有什么不好的，我们最关心的是产生出来的东西是什么，而不是到底如何产生出来的，流程是为目的服务的，而不是以流程本身做为目的的。），由PM（我希望他必须具有良好的沟通能力和一些些商业知识以及谈判技巧），技术设计人员（他首先应该具备清晰的思路，能够在需求阶段从技术角度提出一些解决方案，以供客户选择，并且我希望他能够把在需求过程中，所吸收到的东西，能够贯穿到项目全部过程中），测试主管（我首先需要他具备良好的整体思维能力，能够敏锐地发现需求的不完善或者不完整的地方，他需要从可测试性的角度来看待需求）；一起来进行需求的获取和分析。

在需求获取和分析阶段，有几个问题，是绝对不能犯的：

1.          过多地从设计、开发角度，而不是从客户本身来考虑问题。当然，这一点有时候是难以避免的，比如我们很多项目，是在合同额已经确立的情况下，才进行需求的获取和分析，所以，严格意义上要完全避免这个问题，是难以做到的。比如我举一个例子，用户系统的用户注册量有几千万甚至更多，而且对登录速度要求很高，你会如何做？我想你一定会倾向于使用LDAP来做这一块。但是，过于多地考虑如何实现，就不应该了。在需求阶段，我们还是讨论实现什么，而不去考虑如何实现的问题。

2.          让技术为沟通买单，我记得，在一次面试中，对方公司的老总问过我一个问题：“如果你们团队中，PM和技术人员对于需求的认知不同，那么你如何办”。很简单，我们也许都错了，去问客户，不要怕问客户，害怕别人觉得你很烦，甚至觉得客户很难相处。于是，自己设想一个过程，这种由于沟通的缺乏，而使得工作白费的事情恐怕太多了吧。不要让技术为沟通买单，也许很多技术出身的人员会倾向于这一点，希望通过自己多完成一些工作，来弥补自己在沟通上的不足，但是经验表明，这种解决方式根本就是南辕北辙。我举一个例子，在一次部署过程中，我们的一个高级工程师，在配置短信网关的时候，发现以前配置完成的短信网关，不能正常工作了。当时我们怀疑是运营商的短信中心发生了一些问题（结果证明也是如此），我们的工程师去和运营商沟通，运营商的一个技术人员说我们做错了（但是实际上并没有错，而且这一点在北京的同事给予了支持，说明了很多次并没有问题）。但是我们的工程师不再愿意和对方进行沟通了，让我们发送了一份CMPP协议，并且磕了1个下午来学习CMPP，然后开始现场修改代码（并且没有做好版本控制，以至于找不到当时调试通过的代码了），而且更奇怪的是，这次修改代码的目的仅仅是想按照别人说的做，然后肯定还是不能联通，以此证明对方是错误的。我很奇怪这样的解决方式，难道我们真的认为，一个下午的CMPP协议的学习，能够顶得上别人半年的开发经验吗？而且和运营商的工程师如此较劲，有必要吗？为什么不进行再次沟通呢？即使再次沟通存在困难，为什么不通过我们的合作公司（我们和他们一起做这个项目），和运营商进行沟通呢？答复是：我不想别人认为我们不懂CMPP！这件事情的结果有三：第一，合作公司认为，为什么你们的程序如此不稳定？突然好，突然不好的，而且很不理解，为什么你们不能提供一份通过连通性测试的结果，来证明你们是正确的？第二，现场大量代码的修改，而且缺乏版本控制，使得代码最后只能回滚到到现场的第一天的状态，所有在现场所做的调试工作，全部白费了；第三，我们的两个现场工程师几乎通宵了3天，看着他们疲惫的眼神，我简直不知道应该如何去说，说你不称职吧，有点不忍心，毕竟如此旺盛的斗志是我希望看见的，表扬你吧，我简直觉得这种忙碌是自己折腾出来的。请记住，无论你做什么职位，在哪个领域，如果缺少良好的沟通意识和沟通能力，都将使你的工作很难推进。我能够理解沟通中存在的难度，至少在我们很多工程师的心目中，他比在4个小时内，读懂整个CMPP协议要困难，但是，无论你如何认为，也无论你技术能力多么出色，企图用技术手段来解决沟通问题，是不太现实的。

3.          不要自以为是；这一点我说过很多次，这里就不展开了，老老实实地向你的客户学习，他们才是你的老师，而且他们以前没有IT系统辅助他们的工作，他们那么多年也能工作得很好，所以不存在你教他们应该如何做他们的工作，你只是辅助他们更轻松，更方便得完成他们已经完成得很好的工作。记住这一点，不要自以为是！

4.          尽可能的简单，你今天落实下来的工作，将来都是要实现在代码中的，今天一段100字的需求描述，可能需要你在设计阶段付出20人时的时间，在编码阶段花费30-40人时，在测试阶段付出50-60人时，在维护阶段付出100以上的人时，同时，也存在也许能力不足，导致的概念混乱，而导致的高昂的平衡成本，这是极其划不来的。不要仅仅把成本想成一段代码，在整个软件过程中，这将随着时间增长，而增加可怕得多的成本。如果你不明白这一点，请首先去明白这一点，不然你将把项目组带入灾难中。

最后说一句，为什么对于小型的团队（当然，上百人的项目组，项目费用几千万甚至上亿，团队在N个国家进行日不落的开发和测试，项目经理在1年中仅仅在视频会议上见过2次等等，这种项目，我没有做过，而且也很明白一点，这份文档中，所列出的很多经验和教训，并不适合这种项目，因为在这种项目中，无所谓成本高或者成本低，你必须依赖于非面对面沟通）来说，我建议需求人员由项目组成员来一起做？理论上来说，应该有独立的需求人员，然后传递需求规约书或者需求描述给下面的设计人员，但是，这将使得需求人员的压力非常大，他因为不知道后续阅读者会是谁，从而需要把所有的细节都包含进入文档，这将使得文档非常庞大和难以维护；同时更可怕的一点是，需求规约书是用自然语言进行描述的，进行一次需求的传递，必然发生理解上的扭曲。那么我们也许更好的选择是，那就是尽可能地让项目组成员加入需求过程。OK，我的概念是，在最容易错误的领域内，即使多投入一些成本，还是有必要的。

这一点，是我在项目实践过程中的一个坚持，因为我不是理论派的人，我只知道，在项目过程中，进行大量的人员层次划分，将使得沟通成本急剧上升，所以，但凡有可能，对于一般的小团队项目来说，还是多讲一些实际，少讲一些理论比较好一些。

产品经理

做为一个产品经理，首先需要的是你的创意和思路，你必须去规划产品所应该具备的功能，这将使用各种分析方法和手段，比如从竞争对手的产品中进行正向和反向的思维；你需要为自己的产品构造一个好的环境，研发虽然是产品中重要的一环，但是绝对不是唯一的一环，你需要有良好的构思，来形成产品在整个业务环中的定位，需要找到各种合作伙伴来和我们一起推进整个产品在市场上的成熟，你需要根据产品在使用过程中的反馈，来考虑不断的改善（有时候，也是通过一些数据分析手段和数据分析方法，这一点，我一直认为Yahoo做得不错，他们的改进都是有系统监控数据支撑的，而不时拍脑袋出来的），并且分析用户行为，来修整自己的产品；同时，也需要为整个研发部门指明一条前进的方向，说明我们的产品在各个阶段将是什么样子的；并且你还将牵头进行产品的推广的一些工作，比如产品的关键字，产品的宣传语，产品的基本色调等等，这些都是你必须去做的。同时，象对待孩子一样看待这个产品，你必须对这个产品的过程具有一个很清晰的思路，你必须十分明白你的产品目前处于什么阶段，并且清醒地指出下一个阶段的发展方向。

在去年一年中，Yahoo的产品给我留下最深刻的印象是，他们的产品具备了良好的监控能力，我们可以很简单地加入某些代码，来监控用户在站点上的操作访问，并且能够很轻松地定义出各种综合条件的监控，这样，我们才有各种依据来说，某一项工作是否有价值，某一项工作需要改进等等。在产品设计之初，我们就必须考虑这些要素，虽然绝大多数公司未必具有这样一个灵活的监控系统，但是即使是生磕代码，我们也需要加入这些探针，为我们将来的工作来留下一些监控的余地。

以上是产品经理应该做到的一些事情。后面，我仅仅谈一些对我印象最为深刻的产品的思路，当然，这些点不足以构成整个理论体系，但是，只是这些内容在我印象中太深刻了，以至于不吐不快。

首先，如果你的产品是一种直接接第三方开发商的软件（这直接来自于以前开发的工作流引擎产品的感受），即我们常规意义上的中间件产品，那么你在软件设计之初，首先需要考虑的应该是，别人如何使用你的软件完成一部分功能，自己的扩展功能如何能够接入到你的体系中，或者你的系统如何能够嵌入到别人的系统中，这一点是非常重要的。原因是，我们并没有想像中的那么出色，很多看上去很漂亮的中间件产品，在实际的项目使用过程中，开始出现不实用的现象，这在很大程度上，形成了我们后一个阶段研发的重点，也就是说，我们必须预料到我们的产品在前几个项目的实施过程中，可能并不完善，但是，如果还要在项目中得到使用，就必然需要你的系统允许别人用代码来调度，而不仅仅是按照你的思路或者想法来构造。

举一个实际的例子，我想，很多人做过工作流系统吧，规划得比较大的工作流系统一般会包含一下的一些内容，表单生成器，工作流核心引擎，第三方代码注册工具，等等；我们为什么需要第三方代码生成工具呢？原因很简单，我们的工作流虽然定义了各种流转条件，定义了各种运算方法、逻辑判断方法等等，但是我们不能保证用户的工作流流转一定通过这种方法就能构造出来，比如某一个报销的表单，要根据远程数据库的内容，来动态定义流转到什么哪个具体的流程上，那么通过第三方组件的注册，我们可以使得这个代码类似我们工作流引擎自身携带的某些组件，根据这个组件的返回值，来确定流转方向。当然，我们说，如果一个具体的需求暴出来以后，我们对这个具体的需求进行定制化的研发总是容易的，但是做为产品来说，我们在最初的时候，可能还无法预料到如此多的需求，如果没有这些第三方代码的注册工具，我们将被项目牵着走得很累，而且产品会变得越来越象一个项目的附属品。如果我们能够定义出一种模型来构造这些业务，那么这个时候，将是你把这个组件放入自己公用代码库的时候了。这样使得一个产品能够随着项目得到成长，而不是完全象**产品**项目版这种情况出现。在这一点上请做中间件的产品经理务必记得。

其次，产品需要具备良好的设计，但是千万不要自作聪明，设计得极其复杂；这首先是从设计理念上说的，目前有一些做法，是将设计人员和编码人员分离开，独立出来一个设计的角色（其实，我并不十分赞同这种做法，在理论上，这种方案是可行的，但是在实际工作工程中，特别是不断有变化情况下，往往会发生设计思路和理念无法有效传递的情况出现），使得设计人员为了保证自己的设计成果，采用了过分复杂的设计手段进行设计。比如我举一个典型的现实例子来看，在一个业务系统中，需要进行人员通过角色和权限的一个映射关系；如果你要面面俱到地考虑，那么首先，用户、角色、权限层你需要独立分离开，并且和存储方式无关（用LDAP也好，用Oracle也好，用SQLServer2000也好都可以），而且我们为了应付SSO，也需要将服务切分开，使得服务能够远程访问，并且做接口认证和MD5加密，然后我们为了使得用户信息尽量地能够满足要求，所以，需要给角色、权限、用户建立Profile来对应具体的实体；等等，从纯粹设计的思路上来看，这种设计真的很不错，如果将来发生变化，将使得这些变化落在我们的考虑之中，但是，如果从这种理念上，来做产品的话，会使得产品的出现遥遥无期，而且产品很很长的一个时间段中，都无法稳定和投入使用（这一点，我们最好有一个觉悟，我的经验是，如果一个软件开发时间为半年，那么他至少需要额外的1年时间，进行各种改进和稳定，使得他能够让人相对比较放心的运行）。所以，我现在给自己的一个提醒是：我要避免出现两种情况，过于单纯的设计，使得将来的修改变得很困难，和过于复杂的，故意多层的设计，使得产品研发困难重重。我一般的做法是这样，在设计的时候，多考虑可能碰到的问题，但是，在具体落实在设计中的时候，仅仅把可能出现问题的地方，用一层简单隔离开，举一个例子来说，假设，我们可能需要添加一个功能，使得一个用户通过信任关系，或者被信任的关系，把自己的部分权限在某一个时间段中交付给别人，那么在权限系统的设计上就会需要一些变化；但是我绝对不会在这个阶段，就加上各种表的支持，然后需要产品支持这种特征，我只是会注意一点，在用户跨角色到权限的获取过程，必须是一个独立的服务，这样，即使我将来加上这些功能，也仅仅是在一个地方进行修改而已，不会有更多的地方需要改动。千万不要卖弄设计，卖弄设计的一个后果就是系统无意义地庞大而且臃肿，并且使得构造难度加大，部署难度加大，而用户不会为他所不需要的东西付款的。

第三，在可能的情况下，尽量保持概念的简单化，功能简单化。没有人是因为你这个软件能够完成世界上一切事情而购买你的软件的；他们只是因为你解决了他们某一方面的需求而购买的。比如Word，首先能够是个RichEdit工具，然后他会加入各种拼写校对的功能，但是这也是一个一个阶段发布出来的。而不是在一个阶段就全面提供的，因为用户也需要学习，他也需要一点一点地了解系统；你贸然推出一个极其复杂的系统，而且没有良好的概念整合能力，带给客户的将是一场灾难。同时，要记住，代码量越大，概念集越庞大，将使得软件的开发和维护越来越困难，成本的提升不是一种线性的概念，是一种指数的概念。一个包罗万象，而不稳定的产品，还不如一个简简单单的实用的东西。

不要象女孩逛商场一样，或者象我逛书市一样，看见的东西，都想拿下来。这是严重的失误。你在知道你要什么的同时，也需要明确的知道，你不要什么。不要把自己的工作，推卸给研发团队来做。比如某两种逻辑，不知道客户到底需要哪一种，很简单地说一句：“我希望能够通过配置文件，简单地切换整个逻辑流程”。这是典型的不负责任，如果你不明白什么是需要，什么是不需要的，最保险的做法是：不要去做，等你多少明白了一些再说，如果你仅仅想尝试一下，那么请尽量只做一种。配置文档不是麻将中的“百搭”，他最多只能实现你想明白的某种切换（哈哈，在2002年的时候，曾经就这个问题，参与过一次CSDN争论，很激烈，但是现在想来，也有点无聊呢），而不是什么都没有想明白的一种托辞。我碰到了不止一个如此的产品经理，希望以后能够碰到更明白一些的产品经理，而不是什么都要的孩子。

不要把眼光仅仅放在产品本身，要记住还有很多东西会影响你的决定，为你的产品或者产品线构造出来一个良好的业务环和业务圈，将使得他的生命力更顽强。这里我举一个例子，正是由于得实公司的销售和产品的努力，使得在半年多的时间中，我感觉信心百倍（随便提一句，希望得实公司的刘总能够顶住市场上的压力，把这些策略贯彻下去，刘玉璋总经理是一个很令我敬佩的人，他对于工作的执著，他的强烈的事业心，他的严谨的工作态度，他的人性化的管理，给我留下了深刻的印象。正是刘总的个人魅力，是我来到得实的最大动力。虽然我离开了得实，但是还是很珍惜和刘总共事的这段时间，这是我工作得很开心的一段时间，我想我永远不会忘记我来得实之前，和刘总在餐厅的那次面谈，以及我离开得实前夕，略带偏激的，和刘总之间的面谈）。我们提供的产品包括手机端研发的嵌入式软件，包括Syncever的数据同步中间件，以及后台的业务系统；由于这项业务需要手机端的支持（在MOTO、Nokia、Simens、SE等公司的手机上，都提供了这种服务的客户端），而且需要相对比较快速的数据传输（通过GPRS走数据，多少有点慢），需要一个市场的培育期（这是一个新开始的业务，市场从尝试到大规模接受，是需要比较长时间的，这一点是需要我们有一个心理准备的），但是公司不可能为了这个产品，无休止地等待下去。于是得实走了一条我认为很漂亮的路线，抓紧中国移动的大旗，把自己的产品和中国移动绑在一起，来树立自己在同步领域的名声，争取同步业务的单子；同时走国内的终端厂商的单子，力求能够赢得一些短期的现金流，然后，因为有终端的支持，所以，以此向其他服务提供厂商等等进行合作，以期在将来赢得一些长期稳定的现金流。当然，也许有更好的做法，但是，就当时来说，我觉得这个布局实在很不错。

顺便说一句，在2004年，一次到北京近郊去玩的时候，夜晚在院子里烧柴火，我扔了一根很长，很粗的木柴进去（这是一条四四方方的凳子腿），然后坐在边上，期待他能够燃烧起来，但是火越来越小，我很不解。结果旁边的人说：你不会烧火，独木不能烧起来，只有多跟木头支撑起来一个空间，才容易点燃；接着，把木头打断成三截，果然很容易地烧起来了。这件事情让我印象非常深刻，产品也是如此，如果单一的产品，在市场上生存，那么存在比较大的风险，无论如何，需要为你的产品设计出来一条产品线，这条产品线中的产品能够相互依托和相互支持，这样使得你在将来的市场上能够左右逢源一些。至少更容易操作。

各位产品经理啊，你们是产品的构思者，你们决定着产品的走向。如果我的团队仅仅有一个优秀的人才，其他人都比较平庸，我希望他能够担任产品经理的之职。千万不要把产品给忽略了，这将在将来给自己带来极大的麻烦。产品经理的思路如果不够清晰，产品也模糊不清楚；产品经理浮夸，将使得产品充满花里胡哨的东西，一点都不实用；等等。各位产品经理，请重视自己的工作，你的一举一动，都决定着产品叁个月以上的走向。为了整个团队，请至少充分重视自己的决定。