领导和管理（这两者是不同的）远非简单的与Dilbert
的老板背道而驰（译者注：Dilbert 是一个漫画人物，以“拥有”一个“白痴老板”而著称）。当你计划如何做好项目管理时，考虑采取以下列出的行动。也许你想做的事情很多，但下面的这些建议会帮助你集中到那些能提高效率（你自己的效率和团队的效率）的事情上。

设立优先级

你要着手的第一件大事很可能就是有意识的设立你作为项目经理的优先级。尽管你可能因为各种原因还需要很大程度上参与软件的开发，但除此之外，你还有一些新的职责。很多新任的项目经理都摆脱不了技术的诱惑，以致忽略了项目成员向自己寻求的帮助。

富有效率的项目经理知道，他们最高优先的就是为项目成员提供服务。这些服务包括：指导和教育，处理冲突，提供资源，设立项目目标和优先级等等，适当时也要提供技术指导。我发现，把自己视为为成员工作，而非监工是很有价值的。不管你正在做或者将要做多重要的事，来你这儿寻求帮助的项目成员应该有“非屏蔽中断” （译者注：非屏蔽中断是一个硬件术语，此处意即最优先的）优先级。

你第二优先的是让你所在组织的客户满意。作为一个项目经理，如果你不再涉足产品的一线开发，也许你很少有直接的机会可以让客户满意。但你必须为你的项目成员创造一个环境，使得他们在这个环境下工作，可以最有效的满足客户的需求。这是项目经理的一个重要职能。

你第三优先的是你自己的事情。可能是一个与项目有关的技术问题（当然也是你感兴趣的），也可能是你的老板要你做的某件事。但当这些事与上面两个较高优先级冲突时，你要做好延后处理的准备。

你最低优先的是那些纯粹取悦你的老板的事情。在一个正常的组织（非Dilbet 式的组织）中，如果你做好了前面所说的更重要的三件事情，你的老板已经是非常惊喜了。尽管并非每个人都那么幸运可以在一个“正常”的组织工作，但还是努力做好这三件最重要的事。把注意力放在尽可能的帮助下属富有效率--
并且快乐-- 上，而不是取悦于那些“上面”的人。

分析你的技能差距

初为项目经理，通常你会意识到你在领导和管理技能方面的差距，除非你已经为这个新职位做了充分准备。你有很强的技术背景，可能这也是提拔你领导技术团队的一个原因，但你还需要一些其他的技能。你需要客观的评价自己的长处和短处，并且着手缩小自己的差距。

做软件的人常常被认为缺乏出色的交际能力。你需要加强你的人际处理能，诸如调解矛盾、说服他人、“推销”自己。你需要应付一些不想应付的场面，比如解雇你的下属、在进度上“讨价还价”、为争取下属的绩效“吵架”。

伴我开始经理职涯的是倾听（Listening）技能的课程，我觉得很有价值。一线开发时，往往我们都有过人的精力来表达自己的技术观点。但作为管理人员，更需要一种包容和聆听的工作风格和交流方式。然后，从“听”的位置走到“说”的位置，你需要提高你的演讲（Presentation）技能。如果你对在公众场合演讲感到不适，你需要接受一些专门的演讲培训。这对你今后的工作很有好处。

作为一个项目经理，协调他人的工作、计划和跟踪项目、必要时进行项目回溯并采取纠正措施等等都是你的职责。可能的话，接受有关项目管理的培训，学习如何设立优先级、如何主持高效的会议、如何明白无误的沟通等等技能；多看一些项目管理和风险管理的书籍和杂志，比如Project Management Institute 的月刊《PM Network》（译者注：你也可以从《PMT 评论》获得大量有价值的软件项目知识）。你还可以从SWCMM（软件能力成熟度模型）中找到很多有关软件项目管理的有用建议。

定义“ 质量”

尽管绝大多数人都认真对待质量，也想生产出优质的产品；但是，有关软件质量的定义仍存在很大争议，比如高质量是“足够好”还是更为经典的质量观点--“无缺陷”。为了领导你的团队走向成功彼岸，你需要花些时间和你的下属以及客户一起来明确，对于他们，质量意味着什么。

你的下属和客户是不同的两帮人，他们很可能对质量没有一致的看法，也就容易抱有不同的目的。如果客户很强调交货期，那他很可能没有耐心听程序员解释为什么需要额外的时间去检查每一行代码。如果客户看重的是软件的可靠性，那他在增加功能和减少Bug之间多半会选择后者。如果客户习惯了老版本的键盘操作，那他很少会对新的图形操作界面感兴趣。

在我曾经负责的一个项目中，为了更好的了解客户的质量要求，我举办了一次开放式讨论会（Open Forum），除了项目成员和客户参加外，我还客户的上司们一起来参加讨论。这次讨论很有价值，因为我们发现很多原有的想法是和客户真正的质量需求背道而驰的。了解这些想法的差异，使得我们可以把力量集中在让客户满意的事情上，而不是放在让“开发满意”的事情上。

软件质量通常被理解为合乎规格说明，满足客户需求，以及在文档和代码中尽量少的缺陷（Defect）等等，这些都是比较“经典”的定义。“六西格码质量”（Six-sigma Quality，译者注：是一种质量标准及相应的质量管理方法）为缺陷密度（Defect Density）和/ 或失效率（Frequency of Failure）设定了一个很高的标准，但是，它没有涉及质量的其他方面，比如交货期、可用性、特性集和性能价格比等等。无论我们是作为生产者还是消费者，我们都希望产品的质量在所有这些方面都是尽量高的，但事实上，我们总要在其中做出权衡和选择。

我们在需求阶段就考虑，对于客户哪些质量特性是重要的，并把它们列举出来（比如，交互性、正确性、易学性等）。然后，我们找来一些关键的客户代表，请他们对这些质量特性打分。这样，我们就可以掌握哪些质量特性是最主要的，哪些是次要的，从而就可以有的放矢，为这些质量特性而优化设计。

我听说的更有意思的一种软件质量定义是“客户回来的，但产品没有”（the customer comes back, but the product does not）。和你的下属以及客户一起定义合适的质量目标，一旦定义了，则要不遗余力的为达成这些目标而努力。也要以身作则，以高标准要求自己。记住这句话： “非完美不争取，非卓越不满足”（Strive for perfection; settle for excellence）。

表彰进步

表扬和奖励项目成员的成绩是很重要的激励方式。你要把建立奖励计划Recognition Program）视为头等大事，除非你已经有了适当的奖励计划。奖励既可以是象征性的奖状、证书，也可以是实实在在的奖品和现金。发奖时记得说，“感谢您的帮助”，或者“祝贺您完成了...”。还要记得奖励的范围不要局限在你的项目组内部，客户代表和一些向你提供特别帮助的项目组外部人员也是要考虑的。

奖励计划不仅需要你投入一小笔钱，也需要你多动动脑，想想以何种方式奖励。和你的下属多交流，了解他们在乎什么样的奖励。要把奖励活动变成团队文化的一部分。另外，尝试“隐形”的奖励，让你的下属明白你是真的知晓他们所做的贡献，并且对此心存感激。

前车之鉴，后事之师

你负责的项目很可能是半途接手的，而且你的前任做的并不怎么好；或者，虽然是新项目，但从前有类似的项目完成，当然有成功的，也有失败的。不管是哪种情形，你作为项目的负责人，应该花些时间分析以往的成功经验和失败教训。你要了解这些项目曾经出现过什么问题，以此避免自己重蹈覆辙。失败是成功之母，但你没有太多的机会失败，所以你要多从别人的失败中学习。

不要戴着有色眼镜去看以往的项目，或许某个你不喜欢的家伙出色的完成了他的项目，你当然可以把这归结为运气或者侥幸，但如果你客观的分析，或许更有助于你的成功。

你也需要客观的去评价自己完成的一些项目（如果有的话），了解自己的团队究竟强在哪里，弱在何处。事实上，每个完成的项目都要进行项目回顾（Post-project Review），有时这种总结式的项目回顾也叫做“开棺验尸”（Postmortem）。注意项目回顾不是为了追究谁的责任，发现问题、剖析问题是为了以后做得更好。你可以采取头脑风暴的做法，鼓励项目组成员各抒己见。另外，这种项目回顾也可以扩展到项目进行中，在每个大的阶段结束时都进行回顾。

除此之外，你需要了解被软件业界普遍认可的最佳实践（Best practice）。在SteveMcConnell 的《Rapid Development》（Microsoft Press，1996）中介绍了27 个最佳实践和36 个软件开发的“经典”问题。此书曾获Jolt Award，是一个很好的学习起点。当你想把一些好的方法、工具和流程引入到你的项目中时，其他人可能会排斥、反对，甚至抵制，而这恰恰是你的职责所在，你要让项目成员明白为什么要这样做，并且确保他们不折不扣的执行。在你的团队内部，也会产生一些最佳实践，所以你要采取一些措施，促使在项目成员之间交流和采纳这些实践。

设立改进目标

当你回顾了以往的项目，并且确定了“质量”的含义，你需要设立一些短期的和长期的改进目标。只要可能，这些目标应该是可以量化的，这样你可以通过一些简单的指标来衡量自己是否在朝着这些目标前进。

举个例子，你发现以往的项目由于需求多变而经常延后，于是，你可以设立一个半年的目标，力求将需求的稳定性提高50%。这样的一个目标要求你每周每月做实际的工作：统计需求的改变数，查明需求的来源和改变的原因，采取措施来控制改变。这很可能将改变你与那些需求更改者的交往方式。< br>
你的这些目标和指标构成了软件流程改进的一部分。尽管流程改进常被人指责为“官僚作风”的体现，但事实上，每个团队都能找到一些可以改进的地方。如果你停留在一贯以来的做事方法上，你最好不要指望能获得比以前更好的结果。

改进流程的原因通常有两个：纠正错误和预防错误。你要把精力集中到威胁或者可能威胁项目成功的因素上；带领你的团队一起分析你们目前做法的长处和短处，以及所面临的威胁。

我自己的团队就组织过一次两阶段的头脑风暴练习，以此来确认提高我们的产量和质量的障碍。在第一阶段，参与者将自己想到的障碍写在即时贴上，每张即时贴写一个想法；然后，协调者就把这些即时贴收集起来，并进行分类；于是我们得到了若干大的分类，我们就把这些分类写在一张大的白纸上。< br>
在第二阶段，同样还是这些参与者，针对前面写的障碍，把想到的克服方法写到即时贴上，并且粘贴到相应的分类上。经过进一步的讨论和分析，我们得以把这些障碍细化，并且获得了一系列可操作的应对方法。

设立可度量的、可争取的目标将集中你为改进流程而付出的努力。你要和你的队员们一起定期检视改进的结果。记住流程改进的目的是为了项目和公司的成功，而不是为了满足书本上的条条框框。把流程改进当成项目来操作，有自己的进度、投入和产出。否则，流程改进总是得不到应有的重视，最终被琐碎的日常工作而淹没。

不要急于求成

本文所建议的一些做法将帮助你这个项目管理的新手和你的团队取得更大的成功，随着你每天面临的工作压力，你或许会沦为又一个“苟延残喘”者，但是，你要始终明白你肩负的一个任务（可能也是你获得成功的机会），那就是形成你的团队文化和一套做事的方法，这是一个长期的任务。你不可能一下子把想做的事都做到，你可以根据自己的处境有所选择，从容上路。

祝你好运！

　　3、管理就是树立榜样。

　　4、高层管理不等于高高在上。

　　5、管理者必须进行问题管理，而不是危机管理。

　　6、干部怕的就是不知道自己怕什么。

　　7、没思路的领导不想互动，没控制力的领导不敢互动。

　　8、干部怎样对待问题?要100%地落实责任，即“见数也见人”的原则。每个1%的问题都可以转化为100%的责任，100%的责任人。

　　9、干部怎样对员工?创造一个充满活力的氛围。

　　10、干部怎样对市场?创与闯。既要创新、创造;又要有闯劲、冲劲。

　　11、干部怎样对待管理?悟性和韧性。

　　12、干部的目标:做超级领导，即你的领导水平达到了能够让下属在没有领导的时候仍能够正常工作。形成有活力的员工，有合力的组织。

　　13、干部是事业成败的关键。

　　14、如果你或你的部门没有了上升的空间，也将失去生存空间。

　　15、终端的问题就是领导的问题。

　　16、看不出问题是最大的问题。

　　17、重复出现的问题是作风上的问题。

　　18、部下素质低不是你的责任，但是不能提高部下的素质是你的责任。

　　19、观念不变原地转，观念一变天地宽。

　　20、管事先管人，管人带作风。

　　21、渐进就是守旧。所以经营理念创新，就要反渐进，必须一步到位。

　　22、不只做一颗螺丝钉，要经营一部机器。

　　23、先画靶子再打枪。

　　24、特殊论就是给问题放行。

　　25、“立刻办”是奔着有预算的目标立刻办;“想想看”是没有预算的闭门造车。

　　26、开发的是市场而不是产品。

　　27、市场目标的确定不是以个人能力为限，而是以用户满意度为准。

　　28、对市场目标的确定就是以在市场上有竞争力增值为标准。

　　29、带动全球经济增长的火车头减速并不意味着所有的车厢都减速。

　　30、零增长不等于零需求。

　　31、有效供给才能创造出市场。

　　32、海尔人只有创业没有守业。

　　33、海尔国际化战略能否成功，主要是靠每一个海尔人的国际化，有了每一个人的国际化才能保证海尔集团的国际化。

　　34、企业竞争力的实现取决于创新的细胞——SBU。

　　35、企业核心竞争力就是获取用户资源的能力。

　　36、一个企业的竞争力是看一个企业的员工是增值的资产还是负债。

　　37、要以秒为计算单位。

　　38、客户的要求不等于客户的需求。

　　39、造势产品输入的是用户的需求，输出的是用户的满意。

　　40、企业一旦站立到创新的浪尖上，维持的办法只有一个，就是要持续创新。

　　41、要持续造势，就要把企业做成一条流动的河。源头是创新的SBU，河的终点是用户的满意度，即对企业忠诚的用户。

　　42、把每位员工经营成创新的SBU并不断经营出高素质的人才的决定性因素就是管理者能否经营自我。

　　43、成为SBU的四个要素是:市场目标、市场定单、市场效果、市场报酬。

　　44、SBU具体的体现就是速度和创新。

　　45、经营企业就是要经营人，经营人首先要尊重人。

　　46、止谤莫如自修。战胜非议的唯一途径就是战胜自我。

　　47、挑战目标首先要挑战自我。

　　48、工作要简化，不要简单化。

　　49、求人不如求己。

　　50、“想干与不想干”是有没有责任感问题，是“德”的问题;“会干与不会干”是“才”的问题，但是不会干是被动的，是按照别人的要求去干;“能干与不能干”是创新的问题，即能不能不断提高自己的目标。

　　51、没有市场定单的管理者就是不要管理的管理者;没有市场定单的员工就是不干工作的员工，责任不在员工身上，而在于管理者;没有市场定单的工作就是无效工作。

　　52、决胜在终端。

　　53、流程再造就是先要再造人。

　　54、企业内部管理革命是为了创造企业外部的市场。

　　55、不是因为有些事情难以做到，我们才失去了斗志，而是因为我们失去了斗志，那些事情才难以做到。

　　56、我们所有的质量问题，都是人的问题，设备不好是人不好;零部件不合格是人不合格;我们所有发展不起来的问题都是思路问题，不是缺人是缺思路;不是缺件是缺思路。

　　57、企业发展的空间无限大，企业与用户的距离无限小。

　　58、有价值的定单是企业发展的永恒的主题，企业要发展必须有定单而且是有价值的定单。

　　59、质量无止境，企业无边界，名牌无国界。

　　60、“一站到位”的服务，“一票到底”的流程。

　　61、员工齐心，管理用心，对用户真心。

　　62、企业生命之树的土壤是用户。

　　63、企业做到极致，满足用户需求，无有他奇，只是本然。

　　64、要在国际市场竞争中取胜，第一是质量，第二是质量，第三还是质量。

　　65、质量不打折、服务不打折、信誉不打折。

　　66、质量一次就做对。

　　67、有缺陷的产品就是废品。

　　68、在一个管理好的企业内部没有激动人心的事情发生。

　　69、管理的关键不在于知而在于行。

　　70、没有定单就没有目标，没有目标就没有工资。

　　71、盘活资产首先要盘活人。

　　72、在别人否定自己之前先自我否定。

　　73、只有自己才能打倒自己。

　　74、突破自我，突破思维定势，突破昨天。

　　75、智力比知识重要，素质比智力重要，觉悟比素质更重要。

　　76、创新的目标是创造有价值的定单;创新的本质是创造性的破坏，破坏所有阻碍创造有价值定单的枷锁;创新的途径是创造性的模仿和借鉴，即借力。

　　77、监控就是爱护，委任就是信任。

　　78、观念创新就是目标创新，目标创新就是提出别人认为不可能达到的目标，并用创新的办法实现它。

　　79、每个中高级管理人员只有自己先找到市场才能找到市场中竞争的方向。

　　80、不能用职能管理的手推职能管理的山。

　　81、永远战战兢兢，永远如履薄冰。

　　82、职能签字是事先没有市场目标的签字，事先无人负责的签字。用户的签字才是有效的签字。

　　83、用户的钞票才是企业的选票，用户的口碑才是企业的金杯。

　　84、只有真正实现了问题清零和买断损失，才能卖出有价值的定单。

　　85、要效果，不要借口。

　　86、没有思路就没有出路。

　　87、举一纲而万目张，失一机而万事毁。

　　88、管理无小事。

　　89、物流以时间消灭空间，商流以空间消灭时间。

　　90、什么是不简单?能够把简单的事千百遍都做对，就是不简单;什么不容易?大家公认的非常容易的事情认真地做好，就是不容易。

　　91、图难于其易，为大于其细。

　　92、把不可能变成可能。

　　93、昨天的成功经验与辉煌可能是明天成功的阻碍。

　　94、要做到实事求是，有两点很重要:其一是能不能实事求是，即思维方式的改变问题;其二是敢不敢实事求是，即思想境界的提高问题。

　　95、解决无效管理，首先要在思想观念上树立以几何级数去提高工作效果的信心;其次，要有创新是无止境的观念，创新的空间存在于每个地方、每个人、每件事上。

　　96、一切结论产生在调查研究之后;在调查研究中，如果找不出原因和解决办法就不能放过。

　　97、抓管理肯定要数，但如果就数抓数，最后连数也得不到，或者只抓到一个假数。抓好提高人的素质工作，数自然会产生;不抓人的工作，数就会越来越差，不能见数不见人。

　　98、以人为本的管理就是管理人员的创新精神。

　　99、真正的人才是在寻找实现自我的机遇。

　　100、市场是每个人的上级。

我们期待自己成为一个优秀的软件模型设计者，但是，要怎样做，又从哪里开始呢？

将下列原则应用到你的软件工程中，你会获得立杆见影的成果。

1. 人远比技术重要

你开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平，因为他们那时侯将主要精力都集中在技术上。显然，构件（components），EJB（Enterprise Java Beans）和代理（agent）是很有趣的东西。但是对于用户来说，如果你设计的软件很难使用或者不能满足他们的需求，后台用再好的技术也于事无补。多花点时间到软件需求和设计一个使用户能很容易理解的界面上。

2. 理解你要实现的东西

好的软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。

3. 谦虚是必须的品格

你不可能知道一切，你甚至要很努力才能获得足够用的知识。软件开发是一项复杂而艰巨的工作，因为软件开发所用到的工具和技术是在不断更新的。而且，一个人也不可能了解软件开发的所有过程。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事软件开发的人来说，每天可以学习很多新东西（如果愿意的话）。

4. 需求就是需求

如果你没有任何需求，你就不要动手开发任何软件。成功的软件取决于时间（在用户要求的时间内完成）、预算和是否满足用户的需求。如果你不能确切知道用户需要的是什么，或者软件的需求定义，那么你的工程注定会失败。

5. 需求其实很少改变，改变的是你对需求的理解

Object ToolSmiths公司（www.objecttoolsmiths.com）的Doug Smith常喜欢说：“分析是一门科学，设计是一门艺术”。他的意思是说在众多的“正确”分析模型中只存在一个最“正确”分析模型可以完全满足解决某个具体问题的需要（我理解的意思是需求分析需要一丝不苟、精确的完成,而设计的时候反而可以发挥创造力和想象力 - 译者注）。

如果需求经常改动，很可能是你没有作好需求分析，并不是需求真的改变了。

你可以抱怨用户不能告诉你他们想得到什么，但是不要忘记，收集需求信息是你工作。

你可以说是新来的开发人员把事情搞得一团糟，但是，你应该确定在工程的第一天就告诉他们应该做什么和怎样去做。

如果你觉得公司不让你与用户充分接触，那只能说明公司的管理层并不是真正支持你的项目。

你可以抱怨公司有关软件工程的管理制度不合理，但你必须了解大多同行公司是怎么做的。

你可以借口说你们的竞争对手的成功是因为他们有了一个新的理念，但是为什么你没先想到呢？

需求真正改变的情况很少，但是没有做好需求分析工作的理由却很多。

6. 经常阅读

在这个每日都在发生变化的产业中，你不可能在已取得的成就上陶醉太久。

每个月至少读2、3本专业杂志或者1本专业书籍。保持不落伍需要付出很多的时间和金钱，但会使你成为一个很有实力的竞争者。

7. 降低软件模块间的耦合度

高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。

你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库（我的经验法则是：当应用程序员在写SQL代码的时候，你的程序的耦合度就已经很高了）。

耦合度低的软件可以很容易被重用、维护和扩充。

8. 提高软件的内聚性

如果一个软件的模块只实现一个功能，那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。

判断一个模块是否有高的内聚性，看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词，则说明你需要将该模块细化。

只有高内聚性的模块才可能被重用。

9. 考虑软件的移植性

移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传（比如java 的宣传口号write once run many ? 译者注）。

即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。

记得从16位Windows移植到32位windows的“乐趣”吗 ？当你使用了某个操作系统的特性，如它的进程间通信(IPC)策略，或用某数据库专有语言写了存储过程。你的软件和那个特定的产品结合度就已经很高了。

好的软件设计者把那些特有的实现细节打包隐藏起来，所以，当那些特性该变的时候，你的仅仅需要更新那个包就可以了。

10. 接受变化

这是一句老话了：唯一不变的只有变化。

你应该将所有系统将可能发生的变化以及潜在需求记录下来,以便将来能够实现（参见“Architecting for Change”，Thinking Objectively, May 1999）

通过在建模期间考虑这些假设的情况，你就有可能开发出足够强壮且容易维护的软件。设计强壮的软件是你最基本的目标。

11. 不要低估对软件规模的需求

Internet 带给我们的最大的教训是你必须在软件开发的最初阶段就考虑软件规模的可扩充性。

今天只有100人的部门使用的应用程序，明天可能会被有好几万人的组织使用，下月，通过因特网可能会有几百万人使用它。

在软件设计的初期，根据在用例模型中定义的必须支持的基本事务处理，确定软件的基本功能。然后，在建造系统的时候再逐步加入比较常用的功能。

在设计的开始考虑软件的规模需求，避免在用户群突然增大的情况下，重写软件。

12. 性能仅仅是很多设计因素之一

关注软件设计中的一个重要因素--性能，这好象也是用户最关心的事情。一个性能不佳的软件将不可避免被重写。

但是你的设计还必须具有可靠性，可用性，便携性和可扩展性。你应该在工程开始就应该定义并区分好这些因素，以便在工作中恰当使用。性能可以是，也可以不是优先级最高的因素，我的观点是，给每个设计因素应有的考虑。

13. 管理接口

“UML User Guide”（Grady Booch，Ivar Jacobson和Jim Rumbaugh ,Addison Wesley, 1999）中指出，你应该在开发阶段的早期就定义软件模块之间的接口。

这有助于你的开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工作。一旦模块的接口确定之后，模块怎样实现就不是很重要了。

从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。

14. 走近路需要更长的时间

在软件开发中没有捷径可以走。

缩短你的在需求分析上花的时间，结果只能是开发出来的软件不能满足用户的需求，必须被重写。

在软件建模上每节省一周，在将来的编码阶段可能会多花几周时间，因为你在全面思考之前就动手写程序。

你为了节省一天的测试时间而漏掉了一个bug，在将来的维护阶段，可能需要花几周甚至几个月的时间去修复。与其如此，还不如重新安排一下项目计划。

避免走捷径，只做一次但要做对（do it once by doing it right）。

15. 别信赖任何人

产品和服务销售公司不是你的朋友，你的大部分员工和高层管理人员也不是。

大部分产品供应商希望把你牢牢绑在他们的产品上，可能是操作系统，数据库或者某个开发工具。

大部分的顾问和承包商只关心你的钱并不是你的工程（停止向他们付款，看一看他们会在周围呆多长时间）。

大部分程序员认为他们自己比其他人更优秀，他们可能抛弃你设计的模型而用自己认为更好的。

只有良好的沟通才能解决这些问题。

要明确的是，不要只依靠一家产品或服务提供商，即使你的公司（或组织）已经在建模、文档和过程等方面向那个公司投入了很多钱。

16. 证明你的设计在实践中可行

在设计的时候应当先建立一个技术原型， 或者称为“端到端”原型。以证明你的设计是能够工作的。

你应该在开发工作的早期做这些事情，因为，如果软件的设计方案是不可行的，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计将更容易获得支持。

17. 应用已知的模式

目前，我们有大量现成的分析和设计模式以及问题的解决方案可以使用。

一般来说，好的模型设计和开发人员，都会避免重新设计已经成熟的并被广泛应用的东西。
http://www.ambysoft.com/processPatternsPage.html 收藏了许多开发模式的信息。

18. 研究每个模型的长处和弱点

目前有很多种类的模型可以使用,如下图所示。用例捕获的是系统行为需求，数据模型则描述支持一个系统运行所需要的数据构成。你可能会试图在用例中加入实际数据描述，但是，这对开发者不是非常有用。同样，数据模型对描述软件需求来说是无用的。每个模型在你建模过程中有其相应的位置，但是，你需要明白在什么地方，什么时候使用它们。

19. 在现有任务中应用多个模型

当你收集需求的时候，考虑使用用例模型，用户界面模型和领域级的类模型。

当你设计软件的时候，应该考虑制作类模型，顺序图、状态图、协作图和最终的软件实际物理模型。

程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求，要么很难扩展。

20. 教育你的听众

你花了很大力气建立一个很成熟的系统模型，而你的听众却不能理解它们，甚至更糟－连为什么要先建立模型都不知道。那么你的工作是毫无意义的。

教给你开发人员基本的建模知识；否则，他们会只看看你画的漂亮图表，然后继续编写不规范的程序。

另外， 你还需要告诉你的用户一些需求建模的基础知识。给他们解释你的用例(uses case)和用户界面模型，以使他们能够明白你要表达地东西。当每个人都能使用一个通用的设计语言的时候（比如UML-译者注），你的团队才能实现真正的合作。

21. 带工具的傻瓜还是傻瓜

你给我CAD/CAM工具，请我设计一座桥。但是，如果那座桥建成的话，我肯定不想当第一个从桥上过的人，因为我对建筑一窍不通。

使用一个很优秀的CASE工具并不能使你成为一个建模专家，只能使你成为一个优秀CASE工具的使用者。成为一个优秀的建模专家需要多年的积累，不会是一周针对某个价值几千美元工具的培训。一个优秀的CASE工具是很重要，但你必须学习使用它，并能够使用它设计它支持的模型。

22. 理解完整的过程

好的设计人员应该理解整个软件过程，尽管他们可能不是精通全部实现细节。

软件开发是一个很复杂的过程，还记得《object-oriented software process》第36页的内容吗？除了编程、建模、测试等你擅长工作外，还有很多工作要做。

好的设计者需要考虑全局。必须从长远考虑如何使软件满足用户需要，如何提供维护和技术支持等。

23. 常做测试，早做测试

如果测试对你的软件来说是无所谓的，那么你的软件多半也没什么必要被开发出来。

建立一个技术原型供技术评审使用，以检验你的软件模型。

在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵。尽可能早的做测试是很值得的。

24. 把你的工作归档

不值得归档的工作往往也不值得做。归档你的设想，以及根据设想做出的决定；归档软件模型中很重要但不很明显的部分。 给每个模型一些概要描述以使别人很快明白模型所表达的内容。

25. 技术会变，基本原理不会

如果有人说“使用某种开发语言、某个工具或某某技术，我们就不需要再做需求分析，建模，编码或测试”。不要相信，这只说明他还缺乏经验。抛开技术和人的因素，实际上软件开发的基本原理自20世纪70年代以来就没有改变过。你必须还定义需求，建模，编码，测试，配置，面对风险，发布产品，管理工作人员等等。

软件建模技术是需要多年的实际工作才能完全掌握的。好在你可以从我的建议开始，完善你们自己的软件开发经验。

以鸡汤开始，加入自己的蔬菜。然后，开始享受你自己的丰盛晚餐吧。

   说道“三个代表”，纯粹是拿来吸引眼球的，俺准备这篇Blog能够给俺的访问数目提升一下，鹅滴神啊。闲话少说书归正传，让我们来看看到底是那三个代表：代表客户的利益、代表员工的利益、代表公司的利益。

      没有利益的事情是不会有人去做的，只是不同的时间、地点、空间和人员，利益的定义和取舍不同。资本论里面把利益这个东西描述的相当清楚。在这里提出这个“利益”其实是想强调一个网络和相关性。一个项目的存在就有这三方的利益互相挂钩在一起.当然还有一方的利益没有说在这里，我将会在本文的最后一段阐述第四个代表。

第一个代表：客户的利益

      “为客户考虑的同时就是为企业的生存考虑”这是鹅多年前提出的一个口号，一个软件产品是一个空洞的东西，大家都是在空中楼阁，从无到有的画圆，只是画这个圆的时候客户告诉你了一个方的框架；然后就看你是否能够画一个圆出来，是椭圆还是正圆，还是一个不规则的多边形？？？

      软件产品不同于修楼和盖房子，这是一个很纯粹的空想和冥想的智力活动的结晶。这个结晶没有产生前大家都只能互相描述这个结晶的样子，然后互相在脑海中YY出一个形象，这个大家包括所有人：客户、设计人员、需求人员、编码人员等等。一直到完工拿这个结晶给客户，客户左看三圈，右看三圈。哎呀呀，好像不是我要的那个样子，你们怎么做成这样呢？？？于是大家重新合计了一下，回去再修改了一下这个结晶再拿给客户，客户看了一下：嗯，好像是这个样子。不要高兴太早了，过几天你又被客户叫过去了：你们弄出来的这个东西不好用，会去再改改... ... ... ...嗯，我想加一些功能... ... ...

      （我不知道我写到这里的时候各位看官有没有兴趣继续看下去，虽然俺写的不是很累，好歹你也给鹅一点Face抢一个沙发嘛！）

      如我上面描述的那样，一个软件项目的大概情况就是这样，按照那本软件工程的书里面所说或许可以同那个什么“螺旋式上升”挂钩；但是这种螺旋不是项目管理人员愿意看到的：项目周期加长，成本增加等等，很多问题产生（当然有些螺旋是始终避免不了的）。

      软件这个东西始终不同于修房子，人类从群居以来有了几千年的修房子的经验，而软件开发管理的过程从整个人类学来说也不过几十年，再来到中国也真正不过几年。中国人都喜欢热闹，那里热闹就瞅那里，也喜欢一步登天，考，好歹中国人飞天也是这么几年的事情，大家急个P.

      说了一点废话，我有点混乱和偏题了，其实我的想法就是一个项目管理人员不能只为了完成项目而完成项目。项目管理人员要真正为客户考虑，为客户解决问题，站在客户的角度考虑问题，从客户的角度来看这个正在进行中的软件项目，把客户的需求变为管理人员的需求（把自己变为客户人员），拿这些需求去完善和要求项目。这样才能真正保证这个项目是客户要的，才能保证客户使用起来不会有生涩感。才能避免一些螺旋的产生，主动解决问题比消极应战好。如果项目管理人员不能把自己放在客户的位置，对于软件的要求始终都是存在一定差距的。

     第二个代表：代表员工的利益

      我一直有些看法：软件产品不是测试出来的，他是制造出来的，测试只是辅助手段。保证软件产品质量的非常重要因素是一个团队。软件是一个智力性的产品，而载体就是人，项目管理的人。

      在我看来（根据我这么多年经验），最能表达软件质量的是人员的积极性、主动性。人这种动物是非常有惰性的，而且依附性比较强，很多时候都是得过且过；但是当这种动物对什么感兴趣的时候这种最能燃烧小宇宙。

     而一个项目管理人员要做的就是协调和沟通，提高他们的积极性和主动性，取得他们的信任，了解他们对于自己价值的体现。有正对性的给他们提供相应的利益服务。

     其实大部分智力性人员一般需要的是两个方面：一种被需要认可的价值；一种被金钱认可的价值。前者需要导向，这个导向没有什么好说的，我认为不同的管理人员方法不一样。后者分为两个方面工资和项目奖金，工资这块我就不多说了，我说的是项目奖金问题：

     还记得大锅饭不，没有项目奖惩制度的项目就是一个大锅饭，做好做坏一个样，质量问题很严重，没有项目奖惩制度就是对于项目确少可控制的细节，项目管理人员手中无权，就缺少控制手段。管理，即要管，又要理。项目管理人员手里必须要有权啊，有人事权，财权。胡萝卜没有，大棒也没有哪能做什么事情???

     大家出来混其实都是混口饭吃，所以根本就是一个钱，钱啊。一个项目的利益分配方案必须让项目人员认可，否则改项目就是一个松散型的项目：质量问题、进度问题、沟通问题... ...

对比1：

A、普通开发人员：

掌握了计算机基础知识；
熟悉计算机资源，学会了编程语言，喜欢卖弄技巧，喜欢比较编程语言的优劣；
以能编出某种特殊功能的程序为荣，不懂原理，不求甚解；
喜欢个人开发，不重视文档编写；

B、软件工程师：

计算机基础知识扎实；
掌握两门以上编程语言，很少停留在表面比较编程语言的优劣；
以编写出用户满意的高质量软件为荣。
懂得个人开发和团队开发的利弊，文档规范，齐全。

对比2：

A、普通开发人员：

只重视功能的实现，不重进度和质量的把握。
怕被“管”得太死，动不动就说限制了思路，没有发挥空间。
不喜欢做测试工作，认为测试低人一等，从来没有做过测试工作。
只根据自己的爱好学习技术；

B、软件工程师：

懂得在进度、质量（功能）和成本之间平衡。
懂得规范的目的在于重用，重用有利于提高效率和集中精力创新。
认为测试工作比编码更具挑战性，自己经常为同伴的代码做白盒测试。
根据企业项目的需求和自己发展目标的共同点选择学习内容和方向；

对比3：

A、普通开发人员：

认为别人程序很差，不喜欢看别人的代码；
总认为自己比业务专家还更理解需求。
项目开始时，喜欢说:“没问题，SO EASY”。
项目大大延期时，喜欢说：“设计太烂，没法编程”。

B、软件工程师：

喜欢为同事走查代码，并以此获得学习他人优点的机会；
懂得自己只是可能比业务专家更懂编程。
项目开始时，喜欢问:“那是什么？这是为什么？”。
项目大大延期时，喜欢说：“我为什么就没想到…”。

1. 你们的项目组使用源代码管理工具了么？
MVM : 应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。
郁也风 : 公司使用的是VSS，在网上与朋友玩的就是CVS了。

2. 你们的项目组使用缺陷管理系统了么？
MVM : 应该用。ClearQuest太复杂，我的推荐是BugZilla。
郁也风 : 嫌BugZilla安装太费事，界面太简陋，我选择的是Jira的破解版。

3. 你们的测试组还在用Word写测试用例么？
MVM : 不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。
郁也风 : 用Word，而且测试工作很是不上台面（中国软件的通病，所以我们公司也没少得了犯）。

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写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。
郁也风 : 我一向认为所谓的Notepad开发是自虐狂的不良嗜好。我们使用Eclipse，不要钱的，但我认为是java开发最好的工具了。

6. 你们的程序员工作在安静的环境里么？
MVM : 需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。
郁也风 : 看来这位兄台是看过人件了，可惜我们公司的办公环境只能说是一般，极为一般。

7. 你们的员工每个人都有一部电话么？
MVM : 需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。
郁也风 : 你果然看了人件了，但请认清形式吧，那是美国，这是中国，“中国国情”四个字会噎死你的，现在的实际情况是很多公司都不让用QQ，MSN（肯定包括我们公司了）。

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 : 值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。
郁也风 : 我们多是在客户的逼迫下完成那最后的5%的。而且100%并不代表Over，而是另一个100%的开始，成就了一个完美的恶性循环。

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也是一个方法。
郁也风 : Code Review？我们老板不喜欢。

22. 你们项目组有Team Morale Activity么？
MVM : 每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。
郁也风 : 这点绝对不会少的，至少我带过的团队的凝聚力还是不错的。

23. 你们项目组有自己的Logo么？
MVM : 要有自己的Logo。至少应该有自己的Codename。
郁也风 : 没想过，今天头要搞个我们部门的文化衫，我强烈反对了。不过Logo可以考虑。

24. 你们的员工有印有公司Logo的T-Shirt么？
MVM : 要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。
郁也风 : 哦，前一个我说了，我反对了。我不喜欢千人一面的感觉。

25. 总经理至少每月参加次项目组会议
MVM : 要的。要让team member觉得高层关注这个项目。
郁也风 : 好像是个不可能完成的任务。不知别的公司如何。

26. 你们是给每个Dev开一个分支么？
MVM : 反对。Branch的管理以及Merge的工作量太大，而且容易出错。
郁也风 : 反对，管理困难，也没有必要，可以加Lable。

27. 有人长期不Check-In代码么？
MVM : 不可以。对大部分项目来说，最多两三天就应该Check-In。
郁也风 : 不可以，我每天都监控VSS的。

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

29. 有没有设定每天Check-In的最后期限？
MVM : 要的，要明确Check-In Deadline。否则会Build Break。
郁也风 : 没有，整合就是个明确的Deadline了。

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来确认。
郁也风 : 很少使用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来回答。
郁也风 : 知道需要，可实际情况同46。

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

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应该负责回答。
郁也风 : 这当然是TL/PM的活了。

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。
郁也风 : 有，这也是j2ee 的规范了。

60. 你们有统一的代码书写规范么？
MVM : 要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。
郁也风 : 有，首先是IDE的format工具，然后是Checkstyle之类的检查工具在每天的day build之前使用。

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条。
郁也风 : 我也同样反对“软件蓝领”，一向唾弃这个学院派制造的名词。我们采取的方式也同样可以参加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%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的 资源了。
郁也风 : 我也懂，可实际情况是，现在有4个项目和我有关联。

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的。
郁也风 : 我想说的同73。