《项目经理应该知道的97件事》由会员分享，可在线阅读，更多相关《项目经理应该知道的97件事（39页珍藏版）》请在金锄头文库上搜索。
1、项目经理应该知道的 97 件事以往的软件开发模式是先了解用户的要求，然后再在极度神秘的环境下进行编程测试。毕竟，用户根本不知道我们在做什么，对吧？直至项目结束，我们的魔术师才会匆匆登场，揭去魔法布，然后期望用户会对我们卓越的产品惊叹不已。然而用户此时的通常反应是： “咳，好吧，我知道你们花了很多功夫，但我们真正需要的是”今天，项目成功的秘诀就是尽早向用户展示任何可以展示的东西。如果能在项目启动早期，而不是当整个项目都结束的时候，就能发现项目中存在的问题，那该有多好啊！随着项目时间的推进，变更项目的成本越来越高。重新编码、重新测试以及改进当前软件的时间，加上整合外围代码进行集成测试所花费的时间都
2、会大大拖延项目进度。如果变化非常重大，还可能危及时间和成本底线，需要经过变更控制委员会一个漫长的批准程序。在一些细小环节上做出的编程决策，或许对于软件开发人员和项目经理而言道理十足，可当软件投入使用后却有可能给用户造成巨大的混乱。我知道曾经有一个大型的培训公司，花了 500 万美元重新设计它的订购软件系统。此前，项目编号同订购产品之间的匹配存在一定逻辑性。例如，4125 可能是学生手册，4225 则是配套的学生练习盘，4325 可以代表教师手册，4425 则是营销宣传时使用的课程大纲等。你可以在同一屏幕上订购 4X25 系列的所有项目。 PHR，即 Professional in Human
3、Resources（人力资源专家） ，是由美国认证协会（American Certi- fication Institute）推出的在国际范围内比较权威的人力资源管理知识体系认证资格。编者注每天，全球 140 个地方的行政助理一遍遍地反复订购同类材料，并很快记住了项目编号。一旦知道了学生手册的编号，他们无须查看就可以立即键入其他项目的编号，这样一来，订购过程十分快捷。在重新设计时，不知何故，这个项目团队居然忘记考虑实际情况下真人是如何进行订购的。新的设计方式中，项目之间没有逻辑关系。项目 6358 可能就是4125 曾经代表的学生手册，而其配套的学生练习盘现在是 8872，而同一类教师手册又是
4、 3392。现在，不仅用户不得不逐项查询并试着“忘记”旧的编号和系统，而且同类产品的不同项目也会分别出现在不同的页面上。行政助理们很愤怒。订购过程慢得就像是蜗牛在蠕动。该项目最后远远突破了它的时间和成本底线。作为项目经理，你应该尽早并经常让软件开发人员和用户交谈。2. 避免打地鼠式开发软件项目经理经常面临及早交付产品的巨大压力。时间是关键。你如何才能快速完成任务呢？假设你的团队有两名程序员，伯尼和罗布。两人都很能干，知识面相同，编程语言技巧也相当。你发现在开发过程中伯尼实现软件功能的速度远远超过罗布。当伯尼着力于快速完成编程时，罗布正花时间写代码并对其进行重构。罗布对变量和方法的命名更擅长。一
5、旦写的程序能够运行起来，他就把这个程序分成几小块。现在他要写测试来确保该程序的每一块都能按照他的意图运行。当他觉得结果比较满意时才宣称实现了功能。但是假设你并不知道上述这些细节。如果你只看他们谁先宣称实现了功能，那么很明显伯尼表现得更好，对吗？几个星期之后，你向客户演示这些功能。像往常一样，顾客喜欢你已经完成的功能，但现在需要你做一些改动和完善。你让软件开发人员修改这些代码。当你把新改进的功能带回给客户时，他们试用了罗布实现的功能，对他做出的改动十分满意。 重构就是改动代码，完善其内部组成结构而不改变其外部功能。它改进软件产品设计。重构代码是回过头去完善以前仓促创建并测试的某项可用的功能。现在
6、需要进一步对该功能进行内部改进，以便长期使用，也使日后增加功能更为方便。遗憾的是他们发现伯尼实现的功能有些奇怪。当伯尼编写好新的功能后，一些以前能使用的功能现在却不能用了。客户把这些作为缺陷标记出来，然后你让伯尼来修改。客户又一次测试这些功能，结果后来新增的功能也不能用了。这到底是咋回事呢？如果你有孩子，就会知道发生了什么。伯尼创建的是一个打地鼠式的应用程序。打地鼠是一种游戏，孩子们拿着一个木棒敲打几个孔中随意弹出的地鼠，他们会很惊奇接下来是哪个地鼠弹出来，而且还乐此不疲。然而，在修改应用程序的时候如果总有坏代码不知从何处随意弹出，那可不是好玩的事情。那会令人沮丧，结果也难以预料，并且它会减慢
7、产品开发速度。伯尼一开始就全速冲刺，只是南辕北辙了。 尽管罗布从一开始就表现得较慢，但实际上他编写的代码更胜一筹。事实证明，他的节奏是可持续发展的。由于最初编写的代码就有较好的质量，所以，他才能更快地做出可行的改动。而且他早期编写的测试能随时带给他反馈信息，让他了解自己新写的代码是否与原有应用程序的其他部分兼容。 当估计某一功能的实现时间时，不要只考虑最初写代码所花费的时间，还要加上提升、调整和改进这些代码所需的时间。写高质量的代码和测试都需要花时间。从短期来看，这似乎是一种损失，然而它带来的却是长期收获。问问自己，你是想要速度还是想尽情享受可持续发展的乐趣。3. 一词不慎坏大事哪一个词会让你
8、错过最后期限？答案是“任何一个词” 。在开发一个将以非英语语言发布的产品时，你将给项目带来许多新的风险和限制。有些风险和限制是技术性的，且显而易见。例如，如果你的产品将投放日本，那么它必须支持适当的字体。如果不支持，那么，即使英文版运行得很完美，日文版的产品也无法运行。但是，字体兼容性不受你的控制。你和团队需要特别注意的倒是一些特殊的翻译译法，并在编码前就要考虑到这些因素，确保开发活动遵循有关国际标准，消除这类问题。仅仅是转换成其他语言版本也会影响到你何时做何种决定。通常情况下，产品本地化（日语、瑞典语和德语等）与英语版本的开发是同时进行的，只是具有一定的滞后。滞后的时间可以是几天，几周，甚至
9、几个月。尽管如此，在某个时间点，外文版的翻译必须要“赶上”英文版。在测试和审查阶段，你需要确保：英文版里的内容都可以被准确翻译过来； z翻译过来的内容同英文版是真正相符的； z翻译版产品的运行没有瑕疵。 z这里有一个问题。这三项事情可能是在英文版完成并批准后才进行测试的。在测试和审查本地化的版本时，你总会发现不止一个具有挑战性的问题无法得到解决，除非回头去改变英文版产品。然而，要知道，在英文产品里最后一分钟所做的一个相对简单和低风险的改变，如改写句子（这只需要几秒钟来编码） ，却往往需要好几天时间来运行和重新测试所有本地化的版本。这可能需要额外花费数千美元，尤其是当你正和一家国外的公司签订翻译
10、合约时。经验不足的软件开发项目经理常犯的这个错误很简单。他们就是低估了对英文版进行意外更改所造成的影响有多严重。为了预防这种情况发生，你可以采取以下两项主要措施。在进度表最后加一个“本地化缓冲区” 。 z 进度表的截止日期意味着与项目计划中的英语产品相关的所有工作都必须在这个有效期限内结束。在目标结束日期之后做的任何改动，都必须符合非常具体、非常严格的标准，只有达到这个标准才可以“进入”返工队列。这个版本的任何变化都不可避免地引起其他外文版作出相应变化。把这些任务排序，让功能的质量控制和英文文本的质量审查分开来做。 z这其实很简单，甚至可以复制所有英文文本到一个电子表格里去进行校对。这样一来，
11、如果有措辞不清楚的情况，我们就能立即发现它，而不必等到测试可运行的产品时才发现它。于是我们可以提前作出必要的改动，可能就不需要对所有其他的语言版本都进行返工了。4. 让项目发起人自己写需求项目失败并不是只有美国公司才遇到的问题。根据几年前一家日本领先 IT杂志社进行的调查，如果按照质量、成本和交付期的标准来衡量，日本企业实施的项目中，超过 75% 都被认为是失败的。跟大多数其他国家一样，在日本，项目不能达标的首要原因几乎总是需求定义太差。处境最危险的公司是那些业务分析能力较差的公司。由他们来做软件开发这样的技术项目时，成功就被委婉地归为“不可能发生的”事项。这一结果表明，要发现、识别并定义一个
12、软件项目的真实需求有多么困难。既然是这样困难，很多项目所有人，如客户、项目发起人或公司主管，就期望项目经理能自己定义和细化这些对软件的要求。项目所有人很少会提供指导或明确他们的需求。既然是一个软件项目，而自己可能又不懂软件开发，所以，他们认为没必要来亲自定义自己的期望。而对于软件项目经理而言，他通常没有权力或时间来自己发现、选择项目需求并排定优先级，尤其是当该项目可能涉及多个利益团体时，大家对软件完成后应实现的功能可能会有相互冲突的设想。项目经理要在项目实施前花时间与资助该项目的人交流，帮他们准确定义各自想要的功能。要能够迅速完成项目且只有少数错误，而且需要的预算尽可能地少，这难道不是最重要吗
13、？但你又不能一箭三雕。哪些资源和技能对创建所需软件而言是至关重要的？资助人是否给团队提供了这些资源？软件如何用于运行基础架构或为公司赚钱？时间期限是切实可行的吗？这些时间限制是不是被写进客户合同，是否绑定到某个重要的节假日，是否据此精心制作了一份营销计划？如果在需求定义阶段没有认真、具体地考虑这个项目要创建什么，那么，这个项目可是岌岌可危了。请记住，项目所有人需要传达的是他们想要这个软件做什么，而不是程序员将如何着手生成这一结果。说服项目所有人，他们必须自始至终参与这个过程。步调一致的需求计划可以明确地将商业意义、项目目标和项目结果联系到一起。否则，该项目不能产生他们所期待的令人满意的结果。
14、失败的软件项目对项目所有人伤害最大，因为是他们资助了这个项目，是他们一直期待着能靠这个软件赚回投资。5. 要简单，不要复杂我的微波炉只需要有一个按钮，即“增加一分钟” 。要烧开一杯水喝咖啡，我得按下按钮三次；要融化奶酪饼干，只需轻轻点击一下；为了加热玉米粉饼，我按“增加一分钟” ，到点后过 15 秒钟再打开门。只有一个按钮的微波炉会通过产品规划委员会的认可吗？可能不会。看看我的那台微波炉上的功能选项（都是从未用过的） ，我就知道，产品规划委员会喜欢复杂而不要简单。当然，他们可能会给“复杂性”冠以“功能丰富”的头衔。没有人从一开始就树立目标：生产的产品就得极尽复杂。复杂性总是意外出现的。假设我有
15、一块凉比萨饼需要热一下。根据制造商的说明，我应该按“菜单”按钮。我现在面临的选择是“速热”和“再热” 。 （嗯，我猜应该选择“再热” ，虽然我有点饿了。速热会比再热快吗？）“饮料” 、 “面条” 、 “比萨饼” 、 “盘菜” 、 “酱”还是“汤”？ （我选择“比萨饼” ，尽管它上面确实有酱并且它也放在盘中。 ） “熟食 / 新做”还是“冷冻”？ （当然都不是，它只是吃剩下的外卖比萨饼。我猜应该选择“熟食 / 新做” 。 ） “一块” 、 “两块” 、 “三块”还是“四块”？我不知道这样的盘问将持续多久，所以我按取消，然后按“增加一分钟”按钮。这和软件开发有什么关系？就我而言，A 只有一个按钮，
16、即“一键购物” 。哦，当然，我第一次访问时必须输入我的地址和我的信用卡号码，但现在我只要点一下就可以实现自己的冲动购物了。软件通常要解决复杂的问题。现在的问题是，那种固有的复杂问题中有多少是你强加给最终用户的？你的软件是不是一个复杂问题放大器？成功的软件通常是一个复杂问题吸收器，因为它首当其冲地为用户承受了复杂的问题，而不是将这些问题一路传递给用户。作为项目经理，你是复杂问题吸收器还是复杂问题放大器？最优秀的项目经理能够吸收程序员、最终用户和公司管理层等各方面抛出的复杂问题。当最终用户提出看似矛盾的需求时，你的任务就是帮助清理这些需求，而不是盲目地将这些问题传递给开发人员。当开发人员由于技术原因不能实现需求时，你的任务就是翻译（吸收）这个复杂的问题，并向用户进行解释，用足够多的信息帮助用户选择另一个途径。使用你的应用程序有多容易？为应用程序添加一项新功能有多容易？对一项新功能提出要求有多容易？报告缺陷、部署新版本、回滚不良的版本又有多容易？ 简单性不会偶然发生，它需要积极培育。而复杂性会因
