导读：

山雨欲来风满楼——继前阶段Microsoft放出Express系列产品对Adobe的CS系列产品和Flash/Flex构成威胁后，本周五，微软再携多家知名媒体欲推出自己的电子出版物媒体格式和阅读器，以图从根基上（Adobe PDF）扼制对手的发展。这次PK的焦点如下有三：

• 开发工具：微软吴佩孚（M$ WPF） vs 奥多比太阳神（Adobe Apollo）。两者都已经具备了B/S+C/S+RIA的开发能力，特别是RIA的开发能力，已经彻底地打破了浏览器的限制。
• 文档格式：微软新格式 vs 奥多比PDF+SWF。两者都具有多媒体presentation能力，偕构成RIA内容部分的根基。以后是否会互相兼容还很难说。
• 阅读工具：P-I Reader vs Acrobat Read + Adobe Digital Editions。都处在起步阶段，得民心者得天下。

========================================================================================== 

译文：

微软联手出版业伙伴对决奥多比

在与Adobe的直接对决中，上周五（2007-02-24）Microsoft在3家主流媒体上宣布——正在计划使用WPF显示技术开发自己的数字化阅读器应用程序——这3家媒体分别是：Associated Newspapers Ltd.、Forbes Inc. 和Hearst Corp.

Hearst已经拥有了自己的一款新闻阅读器，它为旗下的Seattle Post-Intelligencer而准备，称为P-I Reader。这个软件目前处在Beta版并可自由下载。

“在Hearst，我们始终不懈地寻找能够触达读者的各种新途径。”Hearst Newspapers的总裁George B. Irish说，“显而易见，数字化的发布和消费对于将来报纸产业的成功至关重要。”在这款新应用程序上能与Microsoft进行合作，这让我们感到非常激动。对于这一技术能够在Seattle率先得以开发，我们感到十分欣喜，并且打算在不久的将来将其扩大到我们其它的主要报纸市场上去（铸剑师按：不知道有没有中国）。

P-I Reader被设计为能够在线/离线工作，并能存储6天的新闻内容存档。这款阅读器能根据屏幕的尺寸来格式化本文和图片，并允许用户使用键盘在各个页面中进行导航。它能够在所有运行Windows Vista或者Windows XP的计算机上运行。Microsoft表示将有计划使其扩展到其它设备上去，包括那些运行着苹果的Mac OS设备。（铸剑师按：呵呵，微软的跨平台看来是要玩儿真的了！先上Mac OS，这个比较靠谱。其实Adobe对Linux也不怎么待见吗。）

另一家报纸——The New York Times——已经在去年11月引进了基于Microsoft技术的阅读器。

Microsoft 的WPF是与Adobe的“未来悍将”Apollo开发平台及Flash、PDF相抗衡的技术。（铸剑师按：其实还少说了一个：Flex。目前M$使用ASP.NET来摆平Flex）“这两个公司”，IDC的内容与数字化媒体技术部门的program director Melissa Webster说：“所做所为提供的东西是一模一样的——Internet 应用程序通用客户端。”

目前的问题是——当断开与网络的连接后，Internet应用程序的运转就不尽如人意了。无论是Microsoft还是Adobe都在致力于解决这一问题。

Microsoft的出版界同仁正在测试这些新闻阅读应用程序，一个可能将被发现的潜在缺点是——缺少对视频的支持，这却是Adobe拥有的“杀手锏”——Adobe的Flash技术已然是铺天盖地了。尽管Microsoft言称为阅读器应用程序添加处理视频内容的功能易如反掌，但现在看来还是没有什么动静。

大战已经拉开帷幕。“现在就下结论为时过早”，Webster如是说：“Microsoft拥有的是开发者们的心灵与智慧。Adobe拥有的是设计者们的心灵与智慧。”

全文完

英文原版链接：

http://www.informationweek.com/internet/showArticle.jhtml;jsessionid=OBXI2ESVO5NBEQSNDLPSKH0CJUNN2JVN?articleID=197008516

==========================================================================================

铸剑师按：

如今的软件行业已经不是几十年前阳春白雪的“以需求为拉动、以技术为主导”的行业了，它已然成为了一个“以市场为拉动，以利润为主导”的商业分支——市场动因上升为主导；技术，已经退居次席。衡量技术优劣的标准除了在少数领域（如军事、科研）尚保持“更快、更稳定、更精确”外，在更大的民用市场，其标准已经悄悄地转向“更漂亮、更好玩儿、更人性化”。

值得注意的是——如同其它生产行业会产生产品过剩一样，软件行业一样会出现这种情况。或者说，一旦某个产业在利润的驱动下突破了需求的限制，那么必将引起产品过剩的出现。但软件行业的产品过剩与其它行业相比有其自身特点——不是单纯的“数量过剩”（软件的拷贝、边界成本几乎为零）而是表现为种类和功能过剩。

从本质上来讲，种类过剩和功能过剩的本质是一样的。以前一个软件的诞生是大众或者行业需要一些功能，然后程序员把它实现出来；现在倒过来，是软件公司为了维持自己的生存和发展而研究市场，“超前用户需求”写出软件，然后再利用近乎催眠术的办法告诉用户——You need this。软件公司之间的PK也由以前用产品互相PK转而为市场中用户量、资源、合作者的PK，现在已经上升到了产品还没出来就已经在理念上开始PK了（让我想起了《英雄》里的无名对长空）。

我们广大程序员在软件业的风浪中决不能只做看客。是抱朴守掘（继续使用C/C++/Java/AJAX），还是与时俱进（学习诸如WPF、Apollo）？这已经不仅仅是一个技术问题，而是职业生涯的前途与发展、行业发展、文化和潮流的问题。

乱世纷争，英雄自当拔剑四顾！不过，敢问兄弟——您拔的是哪根剑啊？

论坛里经常可以看到关于35岁程序员的生涯询问，他们之中有些人写了十年代码，有些人则是因为对编程发生了兴趣，中途转行，以下四点是给那些30—35岁程序员的建议：

* 照顾自己健康

以前，我认为“钱”是很重要的，俗话说的好：“钱不是万能，但没有钱万万不能”，所以过去我的焦点都是放在收入，但后来我发现有比钱更重要的东西，那是“家”，在你没有结婚前，这个家的概念是指你和父母的和谐关系，而在结婚后，家的概念是指如何维系一个家庭，包括和太太还有孩子的关系。

在IT这个行业里，很多人跟自己父母的想法是有差距的，认为上一代保守，食古不化，讲到很多东西没法沟通，另外，我的很多朋友事业做很大，但最后却离婚了，没有孩子还好，有孩子的要想更多，只有家，你才有奋斗的目标，才有精神的支持，否则就像电视里讲的那一句，失去了你，得到江山又如何？

但这个家的信念自从张国荣事件后，又改变了我的看法，那就是有比家更重要的东西，那是你的“健康”，这个健康包括生理和心理上的健康，想想看你拥有了一个家，但是因为没有健康，全家人都被拖下去了，每天看着你痛苦的吊瓶子，更严重的直接轻生，这样遗留给珍爱你的人只是更大的痛苦，你会C，C++，C#，Java……又怎样？那时候你会认为这些通通都是屁，做人做到能够“吃得下饭、睡得着觉、笑得出来”就已经是莫大的幸福。

35岁会困惑的人多半是因为二十几岁的时候就没有做好准备，过去的已经不可追，现在要想的应该是45岁怎么办？有人说年轻比的是学问，中年比的是财富，老年比的是健康，如果你现在不注意自己健康，那么很快更大的困扰就会上门了，人生每个阶段都有扮演的角色，要学会未雨绸缪，否则不用到50岁，可能40岁就会开始后悔了，健康要从饮食和运动着手，多涉猎这方面的常识，比搞那些过几年就要淘汰的技术有意义多了。

* 学会投资理财

很多人认为投资理财需要很多的钱，这是不正确的，会理财的人，小钱可以积累到大，不会理财的人，大钱也会消耗到光，投资理财首重的是风险管理，没有风险管理就像在刀口舔血一样，投资理财应该要趁早磨练，不要等到40岁的时候才去冒险，因为那时候你已经没有本钱跌倒，投资理财的方法有很多，并不是只有房地产，股票这些东西，从节约，储蓄，定存……每一步都是学习，关键是你要从投资的过程里去发现自己，并且了解如何正确对待甚至对付自己，这样你才有机会早一日达到经济自由，不会提心吊胆这个那个。

投资理财要量力而为，不要做超过你能力所能负荷的事情，我给程序员最好的建议是关注经济，不要浮躁，错把投机当投资，这样还不如定存来得可靠安全。

* 经营你的人脉

我觉得程序员除了普遍不善理财外，另外人际沟通也多有问题，很多人在离开公司的剎那，整个人感觉也都被掏空了，而且会有一种担忧，以前别人跟我说话那是因为我是某某公司的员工，现在不是了，可能就没有什么人会再鸟我了，这就是典型的人脉经营危机。

人脉的经营不是看你有没有朋友，而是有没有能帮助你同时又有实力的朋友。有些人朋友很多，但真正遇到困难，只能精神上支持一下，除此之外，帮不上任何忙，这代表人脉还是太单薄，不要总问别人能给你什么？也要问问你能给别人什么？懂得去欣赏别人，而不要像患了红眼病一样，漠视别人背后的辛劳的付出，只知道妒忌表面的风头，这样，只会将自己的路越走越窄。

经营自己的人脉是有秘诀的，首先你要了解自己存在的价值，如果没有存在的价值，那么经营的人脉是空的，这跟有存在价值却不知道怎样经营人脉，基本上差不多，经营人脉并不等于趋炎附势，而是指在得势的时候，就要想到落难的时刻，待人宽厚真诚，花无百日好，人无千日红，多欣赏别人，择友深交，别把时间浪费在小屁孩身上。

* 培养广泛兴趣

一个程序员如果除了IT以外，一点其它的兴趣也没有，那真的是很危险的事情，像我现在年龄已经超过35岁了，很快就要40，但我现在还是每天写代码，做项目已经不是为了维生，而是纯粹兴趣了，我想我会一直写下去，同时开始加强自己经营管理或财务方面的知识。你说郭安定以后玩不了电脑怎么办？他就去写书，万一双手废了怎么办？那就去配音，万一声音也哑了怎么办？那就重回金融市场，让徒子徒孙帮忙着下单，眼球看左就买，看右就卖，就这么一直玩下去……

所以人生不是只有一条路，你得为自己想好方方面面，而广泛的兴趣可以帮助你跳脱现况，看到更多。

以上四点不仅是35岁的人要注意的，很多甚至二十几岁的人也要开始关注，说真的，很多程序员看上去每个体型都不错，但体格都马马虎虎，很多人熬个两天夜就不行了，不知该说什么……一起加油吧。

1. 你们的项目组使用源代码管理工具了么？
MVM：应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。

2. 你们的项目组使用缺陷管理系统了么？
MVM：应该用。ClearQuest太复杂，我的推荐是BugZilla。

3. 你们的测试组还在用Word写测试用例么？
MVM：不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。

4. 你们的项目组有没有建立一个门户网站？
MVM：要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。

5. 你们的项目组用了你能买到最好的工具么？
MVM：应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。

6. 你们的程序员工作在安静的环境里么？
MVM：需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。

7. 你们的员工每个人都有一部电话么？
MVM：需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。

8. 你们每个人都知道出了问题应该找谁么？
MVM：应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。

9. 你遇到过有人说“我以为……”么？
MVM：要消灭“我以为”。Never assume anything。

10. 你们的项目组中所有的人都坐在一起么？
MVM：需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。

11. 你们的进度表是否反映最新开发进展情况？
MVM：应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。

12. 你们的工作量是先由每个人自己估算的么？
MVM：应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。

13. 你们的开发人员从项目一开始就加班么？
MVM：不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。

14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？
MVM：不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。

15. 值得再多花一些时间，从95%做到100%好
MVM：值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。

16. 登记新缺陷时，是否写清了重现步骤？
MVM：要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。

17. 写新代码前会把已知缺陷解决么？
MVM：要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。

18. 你们对缺陷的轻重缓急有事先的约定么？
MVM：必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。

19. 你们对意见不一的缺陷有三国会议么？
MVM：必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。

20. 所有的缺陷都是由登记的人最后关闭的么？
MVM：Bug应该由Opener关闭。Dev不能私自关闭Bug。

21. 你们的程序员厌恶修改老的代码么？
MVM：厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。

22. 你们项目组有Team Morale Activity么？
MVM：每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。

23. 你们项目组有自己的Logo么？
MVM：要有自己的Logo。至少应该有自己的Codename。

24. 你们的员工有印有公司Logo的T-Shirt么？
MVM：要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。

25. 总经理至少每月参加次项目组会议
MVM：要的。要让team member觉得高层关注这个项目。

26. 你们是给每个Dev开一个分支么？
MVM：反对。Branch的管理以及Merge的工作量太大，而且容易出错。

27. 有人长期不Check-In代码么？
MVM：不可以。对大部分项目来说，最多两三天就应该Check-In。

28. 在Check-In代码时都填写注释了么？
MVM：要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。

29. 有没有设定每天Check-In的最后期限？
MVM：要的，要明确Check-In Deadline。否则会Build Break。

30. 你们能把所有源码一下子编译成安装文件吗？
MVM：要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。

31. 你们的项目组做每日编译么？
MVM：当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。

32. 你们公司有没有积累一个项目风险列表？
MVM：要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。

33. 设计越简单越好
MVM：越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。

34. 尽量利用现有的产品、技术、代码
MVM：千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。

35. 你们会隔一段时间就停下来夯实代码么？
MVM：要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。

36. 你们的项目组每个人都写Daily Report么？
MVM：要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。

37. 你们的项目经理会发出Weekly Report么？
MVM：要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。

38. 你们项目组是否至少每周全体开会一次？
MVM：要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。

39. 你们项目组的会议、讨论都有记录么？
MVM：会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。

40. 其他部门知道你们项目组在干什么么？
MVM：要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。

41. 通过Email进行所有正式沟通
MVM：Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。

42. 为项目组建立多个Mailing Group
MVM：如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。

43. 每个人都知道哪里可以找到全部的文档么？
MVM：应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。

44. 你做决定、做变化时，告诉大家原因了么？
MVM：要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。

45. Stay agile and expect change
MVM：要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。

46. 你们有没有专职的软件测试人员？
MVM：要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。

47. 你们的测试有一份总的计划来规定做什么和怎么做么？
MVM：这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。

48. 你是先写Test Case然后再测试的么？
MVM：应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。

49. 你是否会为各种输入组合创建测试用例？
MVM：不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚，你是否有时间去运行那么多test case。

50. 你们的程序员能看到测试用例么？
MVM：要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。

51. 你们是否随便抓一些人来做易用性测试？
MVM：要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。

52. 你对自动测试的期望正确么？
MVM：别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。

53. 你们的性能测试是等所有功能都开发完才做的么？
MVM：不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。

54. 你注意到测试中的杀虫剂效应了么？
MVM：虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。

55. 你们项目组中有人能说出产品的当前整体质量情况么？
MVM：要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。

56. 你们有单元测试么？
MVM：单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了——可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。

57. 你们的程序员是写完代码就扔过墙的么？
MVM：大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。

58. 你们的程序中所有的函数都有输入检查么？
MVM：不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。

59. 产品有统一的错误处理机制和报错界面么？
MVM：要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。

60. 你们有统一的代码书写规范么？
MVM：要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。

61. 你们的每个人都了解项目的商业意义么？
MVM：要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。

62. 产品各部分的界面和操作习惯一致么？
MVM：要这样。要让用户觉得整个程序好像是一个人写出来的那样。

63. 有可以作为宣传亮点的Cool Feature么？
MVM：要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。

64. 尽可能缩短产品的启动时间
MVM：要这样。软件启动时间（Start-Up time）是客户对性能好坏的第一印象。

65. 不要过于注重内在品质而忽视了第一眼的外在印象
MVM：程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。

66. 你们根据详细产品功能说明书做开发么？
MVM：要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。

67. 开始开发和测试之前每个人都仔细审阅功能设计么？
MVM：要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧”

68. 所有人都始终想着The Whole Image么？
MVM：要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。

69. Dev工作的划分是单纯纵向或横向的么？
MVM：不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。

70. 你们的程序员写程序设计说明文档么？
MVM：要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。

71. 你在招人面试时让他写一段程序么？
MVM：要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。

72. 你们有没有技术交流讲座？
MVM：要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。

73. 你们的程序员都能专注于一件事情么？
MVM：要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。

74. 你们的程序员会夸大完成某项工作所需要的时间么？
MVM：会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。

75. 尽量不要用Virtual Heads
MVM：最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对Resource Manager的。

想首先问大家一个问题：你觉得中国人聪明还是美国人聪明？

我见过最好的回答是美籍华人。

我们说美国人很愚蠢，为什么呢？
你们都考过T或G吧，他们经常会出这么一道题1/3+1/2=？
50%的人回答是2/5，这可是美国研究生入学考试的试题呀！
通常在这个问题之前还有一个1/2+1/2=？为什么？
他们怕太难了，先给个容易的热身一下。
我在美国的时候见过很多的PHD，对于美国人来说if...else...是逻辑，而if...if...else...就成了 哲学，也是美国这么多哲学博士的原因：）
我们说美国人很愚蠢，那我们为什么还要学习他们呢？这个问题稍候我们会回答。
再问一个问题：如果你刚买了一个豪华的房子，可你三岁的儿子把整个墙壁上都写上“我爱长城永不到，我爱北京天安门”，你该怎么做 ？
有的女孩子说暴打，呵呵，这个答案从女生的嘴里说出来还是比较少见。
美国人怎么办？
他们会对孩子说：“你老人家真有绘画的天赋，简直就是毕加索的毕加索，你这一幅画至少能卖100万美金”你们知道美国人喜欢钱， 用金钱来量化一定是效果明显。
但显而易见，您老人家把画画在墙壁上是不能永久保存的，所以我明天给你买一个画布，你就尽情的画吧。否则我们要损失多少个毕加索 呀！ 于是我们就可以看见我们的小宝贝在画布上快乐的滚来滚去。墙面也干净了。
中国人很聪明，从大家就可以看出来，但中国人聪明做工作就有了聪明的做法，他们往往是每个项目都是按照自己的见解来做。
而美国人如何来操作呢，他们就象洗澡，会在面前挂一张纸，上面写着先洗头，再洗耳朵，再细脸，，，这样做事情就有了一定的流程， 渐渐的就形成了一套体系。
所以这也是我们今天来探讨项目管理的目的所在。
项目管理分九个知识领域，分别是成本管理、质量管理、时间管理、范围管理、人力资源管理、沟通管理、风险管理、采购管理和整体管 理。 其中时间，质量和成本管理构成了三角形
大家在纸上画一个三角形
在各个边上标上时间、质量、成本（等边三角形）
任何一方的移动必定带动其他的变形，如果时间缩短，怎么样？就是我们常说的“献礼工程”，同时必定会影响质量和成本。问大家一个 问题，这个三角形中间是什么东东？
对，是范围管理，也就是我们说的项目范围。这也就是我们常说的项目“项目管理三角形”
下面介绍一下项目管理的“项目管理三角形“
项目三角形中的成本，主要来自于所需资源的成本，自然也包括人力资源的成本。这个相信很好理解。
为了缩短项目时间，就需要增加项目成本（资源）或减少项目范围；
为了节约项目成本（资源），可以减少项目范围或延长项目时间；
如果需求变化导致增加项目范围，就需要增加项目成本（资源）或延长项目时间
通过“项目管理三角形“我们了解了项目成本、时间，质量和范围的简单定义。
我们说一个项目经理有多少时间是用来做沟通的工作的？
应该不少于75%的时间是用来沟通的，所以项目管理将项目沟通管理单独列了出来。
所有这些领域都有一个主线就是项目的整体管理来统一的。
由于时间的限制我们不详细讨论其他的知识领域，因为今天是入门的，哈哈
另外项目管理除了九个知识领域，还应该了解5个过程组
5个过程组就是：启动，计划，执行，控制，收尾。
这5个过程组贯穿于每个知识领域的始终，你们了解吗？
举个例子字来说：
某人（比喻）好不容易找了个女朋友，为了增进进一步的距离，他想来个欧亚8日游，于是他把自己多年的积蓄——3万元，一次性投入 。
但在旅游过程中，他的MM看上了另外一个帅哥，于是人财两空，说明什么问题？
说明他的项目启动的时候就出现了问题，没有很好的做市场调研，结果过程就没有办法控制。
根据PMI的解释，接单之后项目自然转入启动阶段
于是他刻苦的工作，终于又攒了3万，这次他不和美女旅游了，考虑到自己的费用，他请这个姑娘看了场电影。
于是他带这个这个姑娘看了——《第一滴血》
看的那叫爽，姑娘看的也很爽，看看完后她觉得这个家伙有暴力倾向，于是又分手。说明什么问题？
对，没有进行有效的需求调查，也就是在计划的时候没有明确的需求定义。
于是他下次的时候知道了姑娘爱看歌舞剧，于是他就请一个靓女看了《天鹅湖》，可是以外有发生了——
进去后发现座位不在一起，等他们把位子换到一起的时候歌舞剧结束了，这说明什么？
对，说明没有很好的执行，起码在执行过程中没有进行有效的监督。
其他的过程不一一解释，我在这里强调的是收尾的重要性。
我们往往非常注重合同性收尾，却总是忽略管理性收尾。什么是管理性收尾呢？
某人同志吸取了所有的经验教训，终于领了结婚证，还应该干些什么呢？
对了，还应该把所有的经验教训总结一下，以书面的形式汇报给老妈，并张贴于门后。
然后在中堂挂一幅对联：欲谈恋爱者需先阅读门后之——《恋爱指南》
以后凡是自己的兄弟姐妹要谈恋爱的，必须先参阅门后的恋爱指南。
这样能起到什么效果呢，对，以后他们的恋爱项目操作至少能停留在这个水平。
这个过程怎样来保证呢，对，还需要我们的QA人员，也就是他的妈妈负责质量控制。
家规一条，不参阅者或不照此操作者不许谈恋爱！
大公司一般有质量管理部门（QA），QA的成员基本上都是由非常有经验的PM转型过来的老狐狸，是老总接班人的有力争夺者：）
这也是我们说一个失败的项目会培养一批优秀的项目经理的原因。
哪个门后的《恋爱指南》我们称之为文档，文档重要吗？我们说在电信科技处的同志们说重要，为什么因为他们管这个，但对于我们呢？
大家拿起你身边的一只笔，告诉我他多长？
有的说10厘米，有的说10.0987厘米。
我们说他的估算很精确，但不准确！！
这是我如果拿一只笔告诉你正好10厘米，然后和你的笔比对你是不是就比较容易得出测算？
这说明文档是非常重要的，有的人认为文档是最无聊的，项目结束后做个总结不就是了吗。
错，文档的整理应该贯穿于项目管理的始终。
文档的管理是对项目进行良好的跟踪和监控的一个手段，简单的讲就是根据你的项目计划进行你的文档管理。
一般档案分类主线是：立项、计划、执行、结束4大类；然后在每大类中，再根据任务或者团组分类管理，根据哪个需要根据你项目复杂 程度和管理习惯，总之原则是方便你对整个项目进度的追踪。
以上我们讲了项目管理的九个知识领域，五大过程组，还有“项目管理三角形“，下面我们讲PMBOK。
PMBOK是项目管理圣经，也就是Project management body of knowledge，项目管理知识体系指南
它是美国项目管理协会（PMI）的核心指导出版物
但它象一本字典，往往你看到第三页会睡着：）
在此简单介绍美国项目管理协会（PMI）和国际项目管理协会（IPMA）
美国项目管理协会只有PMP一个证书，而IPMA有四级，你可以一毕业就可以考试，这个我们后面详细的讲。
下面讲几个名词，如果你掌握了，一和人讲项目管理你就抛出来，一定没有人敢小看你。
他们是WBS、甘特图、基准（BASELINE）、项目干系人和关键路径
WBS是WORK BREAKDOWN STRUCTRE ，工作分解结构
WBS的定义还是很麻烦的，PM要召开团队进行讨论，向成员提供与项目相关的所有详细资料，并把WBS树分解到二层三层。然后要 花上一段时间让成员 进行头脑风暴式（BRAINING STORM）思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。
比如我们要结婚了，怎么来分解呢
无非是办酒席，拍结婚照，，等等，这个在论坛上曾有人做了详细的分解，大家都可以找到。
我们说为什么WBS重要，而且大部分项目管理的咨询都是针对WBS的咨询
因为WBS做好了，以后工作就有了参考物，你就知道在不同的阶段你应该干什么，完成到什么进度。
其实WBS的划分是没有规则的，主要的考虑角度是方便你做各类的统计工作，为管理服务。
同样的一个项目其管理的侧重点不同，WBS结构的划分也可能是完全不同的。
衡量划分好坏的标准应该是看其是否满足你管理的需要。
甘特图也叫横道图等，很多名称，我们说它是甘特在第一次世界大战时开始使用，它就是在WBS的基础上将WBS形象化老控制进度
对于基准，我象举个例子。
我们在没有结婚之前，你脚踩几只船？
我们说法律允许但道德不允许，但你可以脚踩N只船：）
但当有一天你和你的朋友进了一个小黑屋子，然后带了两个盖章的本本的时候，你还可以脚踩N只船吗？
我们说此时就不允许了，因为你过了一个基准线（BASELINE）
如果你还想脚踩N只船就需要重新回小黑屋子再盖两个章就可以了。
那我们的项目要越轨怎么办，也就是项目变更？
我们说对这样的项目变更会影响各要素比如时间，成本，质量等
我们应该统一由项目管理办公室来进行控制，如果你要变更基准，必须要进行严格的限制。
在客户提出变更请求时，要建立变更申请登记表和变更申请表，并让客户签字。
有时候一些不是非常关键的模块PM也不至于一点不讲情面，该卖面子的时候还是要卖，尤其是当着对方领导的面，千万要 卖面子，但是也别卖的太干脆，不要让他们得到的太容易。
PM在变更管理中需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。
如果一个项目进行过程中，比如现在的点心的3G项目，你发现如果再多花一点时间就可以编写出对以后非常有用处的程序，但这个程序 不在本项目范围之内，你要不要做？
对，我们说不能做，你可以重新起一个项目来做，但不能在这个项目里做，这样会是我们的项目成本超出，风险增加，而且和其他的项目 缺少比对性和参照的价值。
这也是我们说现在有大约80%以上的项目失败的原因，我们说项目失败并不是项目进行不下去了，彻底破产，在PMI有明确的定义， 凡是项目的成本超出预算，质量没有得到保证，时间超过预计等等都在失败的范围之内。
这个在华为做的很好，华为有个有名的增量开发的名声。
只用20%的功能先满足你80%的需求，其他的功能我可以开发升级的版本，于是就在小数点后平明的增加数字，于是就是了V1，V 1.1，V1.11....等版本
它从来不一下子满足你所有的需求，我们大家想想，谁没有事情拿出自己的手机把所有的PING码都试用一下，我们说没有，我们大部 分的需求是在打电话，发消息，打打游戏，对不对？
这点在项目管理中非常重要，请大家结合资料好好研究。
项目干系人是什么东东，谁给我举一个例子？
对，包括项目人员的老婆孩子，正确
我们说有的项目需要的时间很紧张，如果你的项目成功了，但项目的程序员们都成了光棍，那项目还是非常失败，至少不是丧心病狂的P M这么想。
合理解决项目干系人的冲突是个很累的问题，其中还包括你的只能经理们，你的董事长，你的客户，等等，等等，有的说没用？
好，如果你的项目进展不下去，你该怎么办？
对，开会，把你的高层找一个坐到会议室，不用他说话，只让他暧昧的看着大家，大家一定会想，这个家伙一定和领导有关系，我们还是 好好的做这个项目，下一个项目再给他使拌子吧：）
所以为了不累死好好分析一下你的项目干系人吧
我们上次讲了一些基础的知识，包括什么是项目管理，项目管理包括什么？
你说项目管理有几个知识领域？
你说项目管理有几个过程组？
让我们想起了泡MM的例子是不是？
还有老母亲做QA的比喻
几天我们着重强调的是
项目是什么?人们常用“时间”，“资源(或缺乏资源)”，“某种工作努力”，“交付物或者产品”，“综合工程”，“缺乏凌驾其他 班组的职权”，以及“预算”来给它下定义。实际上，项目是一种独特的工作努力，即遵照某种规范及应用标准去导入或生产某种新产品 或某项新服务。这种工作努力应在限定的时间、成本费用、人力资源及资财等项目参数内完成。
首先给大家一个项目的定义，到底什么是项目？
根据PMPBOK的定义，项目是在一段时间内为完成某一独特的产品或提供独特的服务所进行努力的过程。
这个过程受到时间、人力、资源、成本、质量上的限制
项目有几个特征：1.临时性 2.独特性 3.一次性
下面大家告诉我下面哪个是项目：A惠普与康柏机构重组惠普与康柏机构重组。B建造一座新工厂 C改建道路 D工程材料采购 E开发软件包 F结婚典礼 G寻找拉登
有人说是寻找拉登，大家说寻找拉登有明确的结束时间吗？
当然我们可以假设寻找拉登50年如果找不到，项目就结束是不是？
所以说我们今天不讨论哪个到底是项目，所有的问题都要放到具体的环境下，否则没有意义。

下面大家可以开始提问了。
什么是WBS呢？
WBS是工作分解结构，就象一张道路交通图，它能够指引你如何从当前位置到达想去的地方。没有它，你可能就要迷路了。
怎样来做一个好的WBS呢？
有时候在接受新项目时前无例子可借鉴感觉分解时真困难, 因为每个人的解决问题思路不同,同一个项目不同的人有很多种分类, 因为可以按照工作的流程分解,也可以按照系统论的方法进行结构上的分解, 但我觉得有一条很重要的原则应该注意,那就是麦肯锡的精髓,他们在分解工作时非常强调的就是MECE, muturally exclusive, collectively exhaustive, 即相互独立,完全穷尽的原则, 也就是现在较流行的说法"横向到底,纵向到边" , 如果分解时坚持了这个原则, 我想一定会有Perfect 的WBS, 其实WBS并非是PMI的"真传", 只是被PMI起名为WBS, 有时候工作中我们也会用类似的方法解决问题无非是没有提升到理论高度, 但WBS确实是做事的核心步骤。
做一个WBS需要注意一些什么问题呢？
第一级通常与项目生命周期相同(如需求分析，设计，采购，施工……)
第一级应在项目进一步分解前完成
WBS的每一级都是其上一级的片断(Segment)
一个工作单元只与一个上层单元相关
上层单元的工作内容应该等于其所有直接下层工作单元的总和

一个工作单元由一个人负责

在整个WBS中使用同一种定义，在整个组织中亦然

通过将人员包括进WBS来激励他去完成计划
什么是甘特图呢？
1.以图形或表格的形式显示活动。
2.现在是一种通用的显示进度的方法。
3.构造时应包括实际日历天和持续时间。不要将周末和节假日算在进度之内
什么是风险呢？
首先问一个问题
你们说在一个项目中，初始阶段和结束阶段哪个时候项目的风险大？
对，是开始的时候，因为在开始的时候有无数的不可控制的因素。
那什么阶段的损失大呢？
对，在结束的时候，所以说两者是相反的。
所以说在项目的启动阶段成功的可能性最小，风险发生的概率也就最高，但是这时候一旦预计的风险发生了，损失是最小的。
想想广州和深圳很多烂尾楼？损失会有多少？？？！！！！！
另外我们要明确几个定义：
1是确定性。具有明显的可能性，比如中国和韩国对抗赛，胜负是很明显的：）
2是风险。韩国队能赢中国队几个球是一种风险的预测。
3是未知性。中国和美国比赛门球那就是未知的：）