项目经理应该知道的97件事68478.docx

《项目经理应该知道的97件事68478.docx》由会员分享，可在线阅读，更多相关《项目经理应该知道的97件事68478.docx（129页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、项目经理应该知道的97件事以往的软件开发模式是先了解用户的要求，然后再在极度神秘的环境下进行编程测试。毕竟，用户根本不知道我们在做什么，对吧？直至项目结束，我们的魔术师才会匆匆登场，揭去魔法布，然后期望用户会对我们卓越的产品惊叹不已。然而用户此时的通常反应是： “咳，好吧，我知道你们花了很多功夫，但我们真正需要的是”今天，项目成功的秘诀就是尽早向用户展示任何可以展示的东西。如果能在项目启动早期，而不是当整个项目都结束的时候，就能发现项目中存在的问题，那该有多好啊！随着项目时间的推进，变更项目的成本越来越高。重新编码、重新测试以及改进当前软件的时间，加上整合外围代码进行集成测试所花费的时间都会大

2、大拖延项目进度。如果变化非常重大，还可能危及时间和成本底线，需要经过变更控制委员会一个漫长的批准程序。在一些细小环节上做出的编程决策，或许对于软件开发人员和项目经理而言道理十足，可当软件投入使用后却有可能给用户造成巨大的混乱。我知道曾经有一个大型的培训公司，花了500万美元重新设计它的订购软件系统。此前，项目编号同订购产品之间的匹配存在一定逻辑性。例如，4125可能是学生手册，4225则是配套的学生练习盘，4325可以代表教师手册，4425则是营销宣传时使用的课程大纲等。你可以在同一屏幕上订购4X25系列的所有项目。 PHR，即 Professional in Human Resources（

3、人力资源专家） ，是由美国认证协会（American Certi- fication Institute）推出的在国际范围内比较权威的人力资源管理知识体系认证资格。编者注每天，全球 140 个地方的行政助理一遍遍地反复订购同类材料，并很快记住了项目编号。一旦知道了学生手册的编号，他们无须查看就可以立即键入其他项目的编号，这样一来，订购过程十分快捷。在重新设计时，不知何故，这个项目团队居然忘记考虑实际情况下真人是如何进行订购的。新的设计方式中，项目之间没有逻辑关系。项目 6358 可能就是4125 曾经代表的学生手册，而其配套的学生练习盘现在是 8872，而同一类教师手册又是 3392。现在，不

4、仅用户不得不逐项查询并试着“忘记”旧的编号和系统，而且同类产品的不同项目也会分别出现在不同的页面上。行政助理们很愤怒。订购过程慢得就像是蜗牛在蠕动。该项目最后远远突破了它的时间和成本底线。作为项目经理，你应该尽早并经常让软件开发人员和用户交谈。2. 避免免打地鼠鼠式开发发软件项目经经理经常常面临及及早交付付产品的的巨大压压力。时时间是关关键。你你如何才才能快速速完成任任务呢？假设你你的团队队有两名名程序员员，伯尼尼和罗布布。两人人都很能能干，知知识面相相同，编编程语言言技巧也也相当。你你发现在在开发过过程中伯伯尼实现现软件功功能的速速度远远远超过罗罗布。当当伯尼着着力于快快速完成成编程时时，罗

5、布布正花时时间写代代码并对对其进行行重构。罗布布对变量量和方法法的命名名更擅长长。一旦旦写的程程序能够够运行起起来，他他就把这这个程序序分成几几小块。现现在他要要写测试试来确保保该程序序的每一一块都能能按照他他的意图图运行。当当他觉得得结果比比较满意意时才宣宣称实现现了功能能。但是是假设你你并不知知道上述述这些细细节。如如果你只只看他们们谁先宣宣称实现现了功能能，那么么很明显显伯尼表表现得更更好，对对吗？几几个星期期之后，你你向客户户演示这这些功能能。像往往常一样样，顾客客喜欢你你已经完完成的功功能，但但现在需需要你做做一些改改动和完完善。你你让软件件开发人人员修改改这些代代码。当当你把新新改

6、进的的功能带带回给客客户时，他他们试用用了罗布布实现的的功能，对对他做出出的改动动十分满满意。 重重构就是是改动代代码，完完善其内内部组成成结构而而不改变变其外部部功能。它它改进软软件产品品设计。重重构代码码是回过过头去完完善以前前仓促创创建并测测试的某某项可用用的功能能。现在在需要进进一步对对该功能能进行内内部改进进，以便便长期使使用，也也使日后后增加功功能更为为方便。遗憾的是他他们发现现伯尼实实现的功功能有些些奇怪。当当伯尼编编写好新新的功能能后，一一些以前前能使用用的功能能现在却却不能用用了。客客户把这这些作为为缺陷标标记出来来，然后后你让伯伯尼来修修改。客客户又一一次测试试这些功功能，

7、结结果后来来新增的的功能也也不能用用了。这这到底是是咋回事事呢？如如果你有有孩子，就就会知道道发生了了什么。伯伯尼创建建的是一一个打地地鼠式的的应用程程序。打打地鼠是是一种游游戏，孩孩子们拿拿着一个个木棒敲敲打几个个孔中随随意弹出出的地鼠鼠，他们们会很惊惊奇接下下来是哪哪个地鼠鼠弹出来来，而且且还乐此此不疲。然然而，在在修改应应用程序序的时候候如果总总有坏代代码不知知从何处处随意弹弹出，那那可不是是好玩的的事情。那那会令人人沮丧，结结果也难难以预料料，并且且它会减减慢产品品开发速速度。伯伯尼一开开始就全全速冲刺刺，只是是南辕北北辙了。 尽管管罗布从从一开始始就表现现得较慢慢，但实实际上他他编写

8、的的代码更更胜一筹筹。事实实证明，他他的节奏奏是可持持续发展展的。由由于最初初编写的的代码就就有较好好的质量量，所以以，他才才能更快快地做出出可行的的改动。而而且他早早期编写写的测试试能随时时带给他他反馈信信息，让让他了解解自己新新写的代代码是否否与原有有应用程程序的其其他部分分兼容。 当估估计某一一功能的的实现时时间时，不不要只考考虑最初初写代码码所花费费的时间间，还要要加上提提升、调调整和改改进这些些代码所所需的时时间。写写高质量量的代码码和测试试都需要要花时间间。从短短期来看看，这似似乎是一一种损失失，然而而它带来来的却是是长期收收获。问问问自己己，你是是想要速速度还是是想尽情情享受可可

9、持续发发展的乐乐趣。3. 一词词不慎坏坏大事哪一个词会会让你错错过最后后期限？答案是是“任何何一个词词” 。在在开发一一个将以以非英语语语言发发布的产产品时，你你将给项项目带来来许多新新的风险险和限制制。有些些风险和和限制是是技术性性的，且且显而易易见。例例如，如如果你的的产品将将投放日日本，那那么它必必须支持持适当的的字体。如如果不支支持，那那么，即即使英文文版运行行得很完完美，日日文版的的产品也也无法运运行。但但是，字字体兼容容性不受受你的控控制。你你和团队队需要特特别注意意的倒是是一些特特殊的翻翻译译法法，并在在编码前前就要考考虑到这这些因素素，确保保开发活活动遵循循有关国国际标准准，消

10、除除这类问问题。仅仅仅是转转换成其其他语言言版本也也会影响响到你何何时做何何种决定定。通常常情况下下，产品品本地化化（日语语、瑞典典语和德德语等）与与英语版版本的开开发是同同时进行行的，只只是具有有一定的的滞后。滞滞后的时时间可以以是几天天，几周周，甚至至几个月月。尽管管如此，在在某个时时间点，外外文版的的翻译必必须要“赶赶上”英英文版。在测试和审查阶段，你需要确保：英文版里的内容都可以被准确翻译过来； z翻译过来的内容同英文版是真正相符的； z翻译版产品的运行没有瑕疵。 z这里有一个问题。这三项事情可能是在英文版完成并批准后才进行测试的。在测试和审查本地化的版本时，你总会发现不止一个具有挑战

11、性的问题无法得到解决，除非回头去改变英文版产品。然而，要知知道，在在英文产产品里最最后一分分钟所做做的一个个相对简简单和低低风险的的改变，如如改写句句子（这这只需要要几秒钟钟来编码码） ，却却往往需需要好几几天时间间来运行行和重新新测试所所有本地地化的版版本。这这可能需需要额外外花费数数千美元元，尤其其是当你你正和一一家国外外的公司司签订翻翻译合约约时。经经验不足足的软件件开发项项目经理理常犯的的这个错错误很简简单。他他们就是是低估了了对英文文版进行行意外更更改所造造成的影影响有多多严重。为了预防这种情况发生，你可以采取以下两项主要措施。在进度表最后加一个“本地化缓冲区” 。 z 进度表的截止

12、日期意味着与项目计划中的英语产品相关的所有工作都必须在这个有效期限内结束。在目标结束日期之后做的任何改动，都必须符合非常具体、非常严格的标准，只有达到这个标准才可以“进入”返工队列。这个版本的任何变化都不可避免地引起其他外文版作出相应变化。把这些任务排序，让功能的质量控制和英文文本的质量审查分开来做。 z这其实很简单，甚至可以复制所有英文文本到一个电子表格里去进行校对。这样一来，如果有措辞不清楚的情况，我们就能立即发现它，而不必等到测试可运行的产品时才发现它。于是我们可以提前作出必要的改动，可能就不需要对所有其他的语言版本都进行返工了。4. 让项项目发起起人自己己写需求求项目失败并并不是只只有

13、美国国公司才才遇到的的问题。根根据几年年前一家家日本领领先 IIT杂志志社进行行的调查查，如果果按照质质量、成成本和交交付期的的标准来来衡量，日日本企业业实施的的项目中中，超过过 755% 都都被认为为是失败败的。跟跟大多数数其他国国家一样样，在日日本，项项目不能能达标的的首要原原因几乎乎总是需需求定义义太差。处处境最危危险的公公司是那那些业务务分析能能力较差差的公司司。由他他们来做做软件开开发这样样的技术术项目时时，成功功就被委委婉地归归为“不不可能发发生的”事事项。这这一结果果表明，要要发现、识识别并定定义一个个软件项项目的真真实需求求有多么么困难。既然是这样困难，很多项目所有人，如客户、

14、项目发起人或公司主管，就期望项目经理能自己定义和细化这些对软件的要求。项目所有人很少会提供指导或明确他们的需求。既然是一个软件项目，而自己可能又不懂软件开发，所以，他们认为没必要来亲自定义自己的期望。而对于软件项目经理而言，他通常没有权力或时间来自己发现、选择项目需求并排定优先级，尤其是当该项目可能涉及多个利益团体时，大家对软件完成后应实现的功能可能会有相互冲突的设想。项目经理要在项目实施前花时间与资助该项目的人交流，帮他们准确定义各自想要的功能。要能够迅速完成项目且只有少数错误，而且需要的预算尽可能地少，这难道不是最重要吗？但你又不能一箭三雕。哪些资源和技能对创建所需软件而言是至关重要的？资

15、助人是否给团队提供了这些资源？软件如何用于运行基础架构或为公司赚钱？时间期限是切实可行的吗？这些时间限制是不是被写进客户合同，是否绑定到某个重要的节假日，是否据此精心制作了一份营销计划？如果在需求定义阶段没有认真、具体地考虑这个项目要创建什么，那么，这个项目可是岌岌可危了。请记住，项目所有人需要传达的是他们想要这个软件做什么，而不是程序员将如何着手生成这一结果。说服项目所有人，他们必须自始至终参与这个过程。步调一致的需求计划可以明确地将商业意义、项目目标和项目结果联系到一起。否则，该项目不能产生他们所期待的令人满意的结果。 失败的软件项目对项目所有人伤害最大，因为是他们资助了这个项目，是他们一

16、直期待着能靠这个软件赚回投资。5. 要简简单，不不要复杂杂我的微波炉炉只需要要有一个个按钮，即即“增加加一分钟钟” 。要要烧开一一杯水喝喝咖啡，我得按下按钮三次；要融化奶酪饼干，只需轻轻点击一下；为了加热玉米粉饼，我按“增加一分钟” ，到点后过 15 秒钟再打开门。只有一个按钮的微波炉会通过产品规划委员会的认可吗？可能不会。看看我的那台微波炉上的功能选项（都是从未用过的） ，我就知道，产品规划委员会喜欢复杂而不要简单。当然，他们可能会给“复杂性”冠以“功能丰富”的头衔。没有人从一开始就树立目标：生产的产品就得极尽复杂。复杂性总是意外出现的。假设我有一块凉比萨饼需要热一下。根据制造商的说明，我应

17、该按“菜单”按钮。我现在面临的选择是“速热”和“再热” 。 （嗯，我猜应该选择“再热” ，虽然我有点饿了。速热会比再热快吗？） “饮料” 、 “面条” 、 “比萨饼” 、 “盘菜” 、 “酱”还是“汤”？ （我选择“比萨饼” ，尽管它上面确实有酱并且它也放在盘中。 ） “熟食 / 新做”还是“冷冻”？ （当然都不是，它只是吃剩下的外卖比萨饼。我猜应该选择“熟食 / 新做” 。 ） “一块” 、 “两块” 、 “三块”还是“四块”？我不知道这样的盘问将持续多久，所以我按取消，然后按“增加一分钟”按钮。这和软件开发有什么关系？就我而言，A 只有一个按钮，即“一键购物” 。哦，当然，我第一次访问时必

18、须输入我的地址和我的信用卡号码，但现在我只要点一下就可以实现自己的冲动购物了。软件通常要要解决复复杂的问问题。现现在的问问题是，那那种固有有的复杂杂问题中中有多少少是你强强加给最最终用户户的？你你的软件件是不是是一个复复杂问题题放大器器？成功功的软件件通常是是一个复复杂问题题吸收器器，因为为它首当当其冲地地为用户户承受了了复杂的的问题，而而不是将将这些问问题一路路传递给给用户。作为项目经理，你是复杂问题吸收器还是复杂问题放大器？最优秀的项目经理能够吸收程序员、最终用户和公司管理层等各方面抛出的复杂问题。当最终用户提出看似矛盾的需求时，你的任务就是帮助清理这些需求，而不是盲目地将这些问题传递给开

19、发人员。当开发人员由于技术原因不能实现需求时，你的任务就是翻译（吸收）这个复杂的问题，并向用户进行解释，用足够多的信息帮助用户选择另一个途径。使用你的应用程序有多容易？为应用程序添加一项新功能有多容易？对一项新功能提出要求有多容易？报告缺陷、部署新版本、回滚不良的版本又有多容易？ 简单性不会偶然发生，它需要积极培育。而复杂性会因你不留意而丛生。6. 偿还还你的技技术债不管是普通通的市民民还是成成功的企企业，只只要他们们管理得得当，债债务就是是一种有有用的金金融工具具。它通通过对未未来利润润的预支支来平衡衡目前的的资金不不足。明明智地使使用短期期债务能能够有效效地消除除现金大大涨大落落。可一一旦

20、滥用用，短期期债务又又会成为为一个使使企业举举步维艰艰的沉重重枷锁。在软件开发界，为了实现那些“处于危险之中”的里程碑，同时完善大部分需要实现的工作，借用时间可谓是一种有效的策略。沃德 坎宁汉（Ward Cunningham）提出了“技术债”的概念，就是指在时间紧迫的情况下，开发人员为实现迭代目标或快到截止日期时所采取的一种方法。在那一刻，他们无力用很恰当的方式来处理代码，但采取一些捷径，他们也许能够让编写好的程序“刚刚足以”冲过终点线。即使这套软件是临时的、有缺陷的，但只要有效地管理出现的技术债，这就是一种恰当的举措。可是，如果这笔债没有得到偿还，它就会变成一个令人痛苦的越滚越大的雪球。如果

21、持续向未来借债而不偿还，那么就会令整个项目变得岌岌可危。要想还清技术债，最好的方法就是评估在每个迭代结束前发生的所有“债务” 。可以要求开发人员确定他们想要展开的临时修改具体是什么，这样做需要花费多少时间。 迭代是指由一个敏捷项目小组选择的一段较短的时期（一周、两周或一个月等） ，在此期间，该小组会开发并测试由客户挑选的一个关键需求，并将结果发送给客户以征求其同意或意见。然后，小组会开始下一个迭代，以开发下一个最重要的需求并（或）纠正前一个迭代中完成的工作。 临时修改是指对一个在运行的编程问题作快速修复或解决，但这种解决方案并不是很理想，在时间允许的情况下可能需要重新修改。修改这种不完善的代码

22、可以称为“展开修改” 。开发人员并并不需要要立刻还还清债务务，不过过，趁他他们对这这些捷径径仍然记记忆犹新新时来估估量所需需的修复复工作，当当然是不不错的。一定要发现要重写的代码有什么具体问题，而不只是随意判断所需要花费的时间。不要借机偷懒，这是一种严肃的、保持代码库干净的有效方法。另外，有越来越多的软件分析工具能自动帮助识别出现“技术债”的地方，了解代码覆盖率、分析耦合性、检测风格偏离等，这些工具或许都可以在你不知情时工作。把留下“技术债”的地方记录到问题跟踪系统，并安排在以后的迭代中解决。只要可以平衡添加新业务功能的工作量并同时还清这些债务，就有可能既满足客户的功能要求又不使这些“技术债”

23、失去控制。软件难用的原因有很多，但通常都归结到临时修改、文档不足、依赖关系不恰当、快捷方式以及偏离预期设计等问题上。当开发人员最终举手投降说他们需要在一个系统上重打锣另开张时，实际情况极有可能是，许许多多没有偿还的技术债已经使他们不堪重负，债台高筑之下，他们觉得还不如痛快地宣布这套软件破产了。只有一直坚持识别债务并迅速处理它，你才可能总是用“最低补偿”来避免接踵而至的混乱。在向业务利益相关者进行解释时，这种比喻说法可谓出奇地管用，能让他们立刻明白软件如何会随着时间的推移而变得无法控制，以及为什么应该投入力量保持代码洁净。7. 为团团队增添添人才而而非技能能我过去采用用的招聘聘标准同同我们这这个

24、行业业里的每每一个人人的招聘聘方式都都是一样样的：技技能，技技能，技技能。直直到有一一天，一一位来面面试的应应聘者当当头泼我我一盆冷冷水（这这当然是是一种比比喻的说说法） ，这次次经历从从此改变变了我。当时我正期望为团队招纳一个有多年微软工作经验的能人。仔细翻阅了比尔的简历，我觉得他非常适合这个职位。他在所有相关技术方面都有六年多的经验。如果我能开出不错的薪酬，这将会是一件轻而易举的事。比尔接受了面试。我们先聊了聊，然后我向他介绍了我们手头上的一些项目，并对他说他是多么适合这个职位。我信心十足地认为这次招聘会进展得很顺利。可是突然间我意识到我会招不到他。我中途停止了面谈，问比尔发生了什么事。我

25、告诉他，他非常适合这个职位，也对他直说我感觉到他不会来。他的答复是： “理查德，如果我还想做过去六年来一直做的事情，我就会留在我现在的单位了。我听说你们即将开始一些非常酷、非常新的 Java 项目，所以我才会想来这儿工作，因为我把它看成一个学习和成长的机会。 ”就在那时我才恍然大悟。用“按技能挑简历”的方式来招聘新人，对一个要创建团队的经理而言，实在是最愚蠢的方法。你知道，我和我的伙伴之所以会进入这个高新技术产业，正是因为我们希望走在科技的最前沿。我们没有一个人希望在职业生涯中重复使用自己在大学学到的那些技能。我们之所以进入这个行业，正是因为这个行业所涉及的永远都是新领域，永远都要学习新技能和

26、新技术。但不知何时时出现了了严重的的错误。我我意识到到我们在在员工成成长上已已停止了了投资。我们不是在寻找新的人才，我们一直寻找的只是非常具体的精良技能。现在我要告诉大家，如果你们看到一个雇主在聘用新人时要求其技能达到精确匹配，那么，这个雇主其实是说： “我们不打算投资你。 ”对于所有努力创建强大团队的人，我要给出的忠告是：请记住你要聘请的是人才而非专业技能。当为敏捷开发团队招聘技术专家时，我要找的是什么样的人才？他们需要具备的优良技能不过是在幼儿园里就培养的：能和他人融洽相处吗？ z能主动合作吗？ z当完成任务后，会把自己的工作整理以做备用吗？ z会对新事物感到兴奋吗？ z喜欢学习吗？ z至

27、于技能，我可以教他。事实上在我们的敏捷团队环境中，学习技术简单而迅速。然而，教一个成年人如何主动合作几乎是不可能的。聘用人才而不是技能，这是组建团队的一种完全不同的方式。那些满腔热情、打算同我肩并肩一起开创激动人心的未来新技术的人，才是我想与之共事的人。8. 西蒙蒙，保持持简单项目的利益益相关者者往往使使事情变变得过分分复杂，这这是软件件项目失失败的一一种常见见原因。项项目组成成员一定定有能力力完整构构想该项项目的目目标并完完成实际际工作。可可那些利利益相关关者却臆臆想，只只靠几个个简单的的、不可可思议的的步骤就就能完成成这个项项目。他他们以为为实现最最终解决决方案是是轻而易易举的一一件事情情

28、，哪怕怕这个项项目很复复杂。利利益相关关者不应应该把软软件项目目建成一一个统一一、巨大大而僵化化的怪物物，而应应该让信信息技术术团队把把项目建建成一棵棵洋葱，每每长一层层就表示示成熟一一分。现现实世界界中没有有其他可可供选择择的余地地。不论论那些需需求有多多完善，总总是难免免会有变变动。如如果你的的软件不不够灵活活，不能能迅速适适应不断断变化的的需求，那那么这个个项目甚甚至在开开始前就就注定要要失败了了。为了了让事情情保持简简单，需需要牢记记下列关关键点。让需求保持简单 z 。需求分析人员往往会将自己脑海里冒出的某个解决方案同依据业务需要而提出的实际客户需求弄混淆。虽然实际的需求可能会非常简单

29、，但是由于需求分析人员和开发人员之间缺乏真正的理解，会导致双方的交流并不到位。需求分析人员应该用简单树形图写出需求。根本需求是总体项目的简单目标。细小枝叶的子级需求被分门别类组成代表父级需求的枝叶。在整个图中不断重复这个过程，直到每项需求都清晰明了。可以使用软件思维导图工具来依照这种方法记录需求。只要明确了一个小子集的需求，开发工作就可以开始了。遵循敏捷开开发过程程 z 。一一旦确定定了一个个小子集集的需求求，开发发小组就就可以立立刻开始始创建原原型。只只要原型型可用，利利益相关关者就可可以测试试并提供供反馈信信息。客客户的反反馈信息息能够确确保准确确的需求求，同时时发现需需求经需需求分析析员

30、从实实际客户户传递到到项目组组时有可可能形成成的交流流差异。让让客户看看到原型型，也可可以帮助助检查开开发人员员设想的的相应解解决方案案是否和和客户所所预想的的一致。这些差异变成新的需求，于是开发人员重做原型，接着周而复始重复这个循环。每个循环周期应尽可能地短，通常不超过两三个星期。定义需求的一个小子集，按照陈述的需求创建一个原型，然后获得反馈信息，这种循环能够确保项目的所有利益相关者总能达成共识，且每个人对进展情况都感到很满意。只要认真地遵循这些简单的技巧，每一个软件项目都可以取得圆满成功。这里说的成功意味着顾客满意且软件实用，而且软件所提供的有效业务功能完全符合创建初衷。9. 你并并不是非

31、非比寻常常的还记得你妈妈妈说的的话吗？“你是是非比寻寻常的！你是独独一无二二的！”其其实，所所有的妈妈妈都会会这么跟跟孩子说说。相信信那个爱爱的谎言言，结果果导致了了许多常常见的软软件项目目问题。我指导了许多不同的团队。当按照软件项目的达标情况进行考核时，那些相信他们是“非比寻常”的团队总是无一例外地落在了后面。因为他们自认为是非比寻常的，所以有着重塑一切的强烈倾向。他们认为： “其他的团队都不可能开发出实用的软件，或至少没有我们这个团队创造的软件这么优秀。 ”他们不从其他开发团队的错误中汲取经验教训，而是闷头重复犯着同样的错误。损失都由公司买单。他们把大量时间用在重写、调试以及把自己的奇怪想

32、法运用到那些已经成为行业标准的软件和工具上，以至于他们永远都无法完成客户项目，而这些项目才是他们应该出售来赚钱的产品。这些虚幻而神奇的产品本可以像这个团队一样非比寻常，当然，前提是这个团队真的有幸将它们写出来。听听这群独一无二的开发人员是怎么说的吧：任何现成的构建系统都不可能处理他们“独一无二”的需求。因此，他们必须为每个新项目编写一个新系统。不用现成的对象数据库映射工具，他们要写自己的。网络应用程序框架？他们信奉： “我们可以做。 ”持续集成？行。测试工具？我们也能写。他们当中那些最自负、最痴迷的人甚至还尝试自己编写编程语言。 工具：软件开发人员用来创建、调试、测试、分析、追踪或以其他方式支

33、持高质量的软件开发的简单程序。那么这些团团队每天天都在做做什么呢呢？由于于舍弃不不用那些些通常都都可以免免费获得得的、功功能完善善的软件件工具，他他们要自自己创建建那些未未经检验验的代码码，由此此便出现现许多问问题，而而他们每每天就是是在解决决这些问问题。如如果是编编写自己己的数据据库层，他他们每天天就要追追踪隐藏藏的缺陷陷和问题题。处理理这些边边缘事件件所花花费的时时间非常常多，如如果他们们能学习习或者修修改现有有的工具具，那花花费的时时间将会会少得多多。不那那么“非非比寻常常” （但但却更成成功）的的团队之之所以会会使用现现成的工工具，那那是因为为他们准准备解决决的问题题都是很很棘手的的。

34、他们们需要可可靠的工工具，因因此他们们的注意意力集中中在软件件项目的的解决方方案上，而而不是试试图为一一个已经经满满的的工具箱箱再装入入一个工工具。这这和有效效的软件件项目管管理有什什么关系系呢？不不要让你你的程序序员白费费力气做做重复工工作。如如果他们们跑来跟跟你解释释他们的的问题是是多么非非比寻常常，你就就直接向向他们点点明，他他们的妈妈妈在做做出“你你是非比比寻常”的的评价时时可能言言过其实实了。对对可以利利用的资资源要做做到了解解透彻、信信息灵通通，引导导团队使使用高品品质的开开源或商商业工具具。“非非我发明明不可”综综合症使使许多杰杰出团队队脱离正正轨。千千万不要要让你的的团队也也在

35、此出出轨了。 边缘事件：只在极端情况下（例如，最快或最慢的速度，最多或最少的数据量，或者最老或最新的浏览器接口）出现的问题或情况。通常是指将精力集中在琐碎且耗时的事情上，却忽略了重要的编程业务量。10. 随随时间滚滚动12 年前前，我的的团队作作为某家家图形设设计公司司的分包包商受邀邀开发一一个网络络应用程程序。我我们同客客户没有有直接的的联系。客客户将所所有的需需求都传传递给总总承包商商，然后后总承包包商再通通过一连连串随意意的电子子邮件将将这些信信息转达达给我们们。 有有一封电电子邮件件和我们们的艺术术家应该该使用的的屏幕分分辨率有有关。以以前的标标准一直直都是 64004880，但但最近

36、的的研究表表明网站站应该支支持高达达 80006600 的分辨辨率。今今天最常常见的屏屏幕分辨辨率为 102247768。 ）尽管管这是一一家经验验丰富的的设计公公司，它它却向客客户陈述述了这样样的正式式要求（我我们从来来没有见见过）：每一页页的布局局符合固固定的 8000 像素素宽和 6000 像素素高的标标准。如如果我们们看到了了这一要要求，肯肯定会立立即进行行更正如如下： “每页页的布局局符合固固定 8800 像素宽宽的标准准，而支支持的显显示器分分辨率最最高为 80006000。 ”我们们做过许许多网站站，知道道宽度是是最重要要的方面面。用户户讨厌水水平地滚滚动网页页，而垂垂直滚动动则

37、被看看做是使使用浏览览器的一一种现实实情况，甚甚至是一一种有利利条件。然然而，很很显然，这这条宝贵贵的真理理从来没没有被转转达给客客户。这这个网站站客户为为每个网网页都提提供了大大量的内内容。结结果，只只有极少少数的网网页能够够在分辨辨率为 80006000 的的 155 英寸寸显示器器上被完完整地纵纵向浏览览。必须须垂直滚滚动网页页。作为为终端用用户的客客户并没没有认识识到，如如果想在在单个屏屏幕上显显示这种种超量的的内容，我我们必须须是超人人才能实实现这个个奇迹，于于是他们们非常失失望。他他们指责责我们的的主承包包商，那那家设计计公司。反反过来，这这家设计计公司便便拒绝付付钱给我我们。据据

38、他们的的说法，我我们“没没有满足足书面要要求” 。有了这次经经验，我我认识到到粗制滥滥造的书书面要求求的危害害性，也也知道别别人怎么么利用它它来对付付你。永永远都要要用文档档记录下下你的设设想，并并坚持与与最终用用户而不不仅仅是是中间人人来审查查并签署署这些需需求，这这一点相相当重要要。幸运运的是，敏敏捷项目目管理实实践缓解解了这些些问题。由由于认识识到开发发人员和和最终客客户面对对面接触触的重要要性，我我们已经经开始共共同创建建用户故故事，开开始根据据他们提提供给客客户的商商业价值值而不是是需求清清单来排排定各项项功能的的轻重缓缓急。一一到两个个星期的的迭代过过程意味味着我们们必须有有早期和

39、和频繁的的反馈意意见，意意味着我我们有机机会阐明明客户的的期望。12 年后，我几乎遇到了一模一样的情形，一个客户希望在每个页面上显示大量内容，但同时也高度关注垂直滚动。幸运的是，按照我们如今的项目运行方式，再根据以往的经验教训，我们没有重蹈覆辙，而是迅速解决了这个问题，实现了客户的期望。11. 你你们的问问题，我我不买单单我们公司正正在使用用的培训训软件已已经滞后后了五次次升级，再再不及时时升级，供供应商都都不再提提供支持持。我们们的项目目就是与与这家供供应商进进行合作作，将培培训软件件升级到到最新版版本，然然后培训训我们的的用户使使用最新新版本的的软件。我们对工作作出了两项声明，一项概述了用

40、户培训协议，另一项明确了培训软件升级的费用上限。在获得我们的数据后，供应商开始了远程开发和测试脚本的过程，以便转换数据并应用第一次升级。脚本一旦通过供应商的测试，就会迁移到我们的开发环境，我们要进行用户测试。在这五次接踵而至的升级过程中，每次都要重复这个过程。测试期间，我们会把遇到的所有问题都记录下来，待供应商重写、重测他们的源脚本后，我们再重新测试这些问题。每次升级工作，用供应商的工作时间乘以声明中约定的费率，计算升级费用。进行升级时，我们会发现应用升级程序的错误，这些错误和我们用来安装升级写的客户脚本并不相关。我们会仔细记录每一个问题，打印屏幕界面，并提供一步步的细节，说明我们发现的是何种

41、问题，也告知了我们是在哪里以及是如何发现每个问题的。我们还要提供证明文件，说明供应商最早许诺过的软件功能。该供应商坚持认为软件是“按设计要求”运行的。后来我们发现，遇到的这些小 bug 只是冰山一角，它们还有更严重的后果。它们暴露出软件的基本功能存在严重的问题，甚至是在升级以后还存在问题。 脚本是指在计算机编程中由一个程序而不是计算机处理器执行的程序或指令序列。脚本可以用来控制软件应用而不用改变应用程序的核心代码。过了一段时时间，供供应商承承认我们们发现的的问题中中有几个个确实没没有“按按设计要要求”运运行，它它们的确确是 bbug。由由于约定定了“费费用上限限” ，虽虽然他们们为了修修改自己

42、己的产品品，不得得不做大大量的工工作，但但是除了了合同中中约定的的“上限限”费用用，他们们并没有有额外收收取我们们任何费费用。在在项目的的这个阶阶段，为为了满足足关键的的最后期期限要求求，我们们的注意意力完全全集中在在软件的的安装上上。只能能顾及一一个问题题到底是是“按设设计要求求”运行行的还是是一个bbug。显显而易见见，如果果我们当当初明确确记录了了供应商商修复每每个 bbug 所花的的具体时时间，那那么我们们可能都都无需支支付合同同约定的的上限费费用。当当与供应应商谈判判合同时时，应该该明确约约定双方方（即供供应商和和你的项项目团队队）的时时间要按按遇到的的具体问问题进行行追踪记记录。这

43、这样一来来，软件件项目经经理就能能有准确确的记录录，如果果问题与与合同项项目要解解决的问问题无关关，而是是出在供供应商的的原产品品上时，软件项目经理就能够减少费用的支出。12. 如如何发现现优秀的的 ITT 开发发人员软件项目经经理都知知道，项项目的成成功取决决于拥有有出色的的开发人人员。你你如何识识别千里里马呢？面试新新应聘者者前，和和最好的的开发人人员交谈谈一下。让让他们重重申一下下所需要要的具体体知识。具具有特定定开发生生命周期期的经验验、掌握握具体方方法或重重要工具具箱，以以及拥有有某方面面领域知知识（比比如国防防工业或或制药行行业） ，这些些是开发发人员最最好具备备的条件件还是必必须

44、具备备的条件件？要对对其知识识进行评评估。你你应和可可信任的的开发团团队代表表共同参参与面试试，还要要附加理理论测试试。一个个优秀的的软件工工程师能能够立刻刻修复“模模拟”的的语法错错误，并并且不会会精神紧紧张。他他不需要要看大量量文档，也也无需逐逐字阅读读就可以以看懂别别人的代代码，了了解它的的意图。当当面对有有问题的的程序时时，应聘聘者应该该能够迅迅速找出出问题，然然后既能能以“极极客开发发人员”的的语言也也能用非非 ITT 背景景的利益益相关者者能听懂懂的语言言描述它它。我们们招聘编编程技术术人才时时都认为为其技能能“越多多越好” 。但是是我们如如何界定定“多”？尽管应应聘者可可能拥有有

45、丰富的的知识，但但是这个个人可能能还没有有掌握有有效应用用它的技技巧。在在面对真真实世界界苛刻的的项目时时，一个个刚毕业业的大学学生或刚刚培训过过的开发发人员，想想要使用用从课本本上学到到的理论论知识时时会很吃吃力。当当最后期期限一步步步临近近，所剩剩时间无无几，而而客户和和其他利利益相关关者又施施加了强强大的压压力，你你除了有有基础知知识之外外还需要要足够的的经验。你和团队应该要求应聘的开发人员编写一段代码供你们审读。在分析了代码，并且与你信赖的开发人员讨论后，你才会知道这个人的方法和风格是否适合你的团队。还要考察应应聘者对对待工作作、同事事、客户户和利益益相关者者的态度度。我曾曾经和一一个

46、被称称为“吹吹风机”的的开发人人员共事事。传说说当他感感到不满满时，他他就会用用他的大大声吼叫叫吹干人人们的头头发。他他是一个个优秀的的开发人人员，但但是对于于整个项项目团队队而言，他他却是有有害无益益的。编编程世界界正朝着着敏捷开开发方向向发展，跨跨职能沟沟通和软软技能将将越来越越重要。开开发人员员将会与与公司中中其他部部门的人人组成小小团队一一起工作作。你未未来的新新队友若若总是处处于不受受控制的的自由状状态，你你跟他合合作还会会顺畅吗吗？招聘聘软件开开发人员员时需遵遵循以下下简单指指导原则则。审查查他们是是否掌握握开发生生命周期期的正确确知识、方方法、工工具，以以及他们们对 z所所在行业业（领域域）的熟熟悉程度度。考察察他们在在工作环环境下应应用知识识的能力力。 z测测试他们们的沟通通能力和和社交技技巧。 zz寻找对对工作有有正确态态度的人人既既渴望创创造出高高端产品品，又能能接受项项目 z的的限制条条件。是是否有证证据表明明他们能能及时且且在预算算之内生生产出“切切合意图图”的产产品？不不管你的的应聘者者多么有有风度而而且多么么懂技术术，都要要始终核核实发证证机关的的资格证证书和前前任雇主主的履历历条目。聘聘请阶段段小心谨谨慎可以以防止未未来很多多问题。13