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

项目经理应该知道的 97 件事  以往的软件开发模式是先了解用户的要求，然后再在极度神秘的环境下进行 编程测试。毕竟，用户根本不知道我们在做什么，对吧？直至项目结束，我们的 魔术师才会匆匆登场，揭去魔法布，然后期望用户会对我们卓越的产品惊叹不 已。然而用户此时的通常反应是： “咳，好吧，我知道你们花了很多功夫，但我 们真正需要的是……” 今天，项目成功的秘诀就是尽早向用户展示任何可以展示的东西。如果能在 项目启动早期，而不是当整个项目都结束的时候，就能发现项目中存在的问题， 那该有多好啊！ 随着项目时间的推进，变更项目的成本越来越高。重新编码、重新测试以及 改进当前软件的时间，加上整合外围代码进行集成测试所花费的时间都会大大拖 延项目进度。如果变化非常重大，还可能危及时间和成本底线，需要经过变更控 制委员会一个漫长的批准程序。 在一些细小环节上做出的编程决策，或许对于软件开发人员和项目经理而言 道理十足，可当软件投入使用后却有可能给用户造成巨大的混乱。 我知道曾经有一个大型的培训公司，花了500万美元重新设计它的订购软件 系统。此前，项目编号同订购产品之间的匹配存在一定逻辑性。例如，4125可能 是学生手册，4225则是配套的学生练习盘，4325可以代表教师手册，4425则是 营销宣传时使用的课程大纲等。你可以在同一屏幕上订购4X25系列的所有项目。 ① PHR，即 Professional in Human Resources（人力资源专家） ，是由美国认证协会 （American Certi- fication Institute）推出的在国际范围内比较权威的人力资源管理知识体系认证资格。——编者注 每天，全球 140 个地方的行政助理一遍遍地反复订购同类材料，并很快记住 了项目编号。一旦知道了学生手册的编号，他们无须查看就可以立即键入其他项 目的编号，这样一来，订购过程十分快捷。 在重新设计时，不知何故，这个项目团队居然忘记考虑实际情况下真人是如 何进行订购的。新的设计方式中，项目之间没有逻辑关系。项目 6358 可能就是 4125 曾经代表的学生手册，而其配套的学生练习盘现在是 8872，而同一类教师 手册又是 3392。 现在，不仅用户不得不逐项查询并试着“忘记”旧的编号和系统，而且同类 产品的不同项目也会分别出现在不同的页面上。 行政助理们很愤怒。订购过程慢得就像是蜗牛在蠕动。该项目最后远远突破 了它的时间和成本底线。 作为项目经理，你应该尽早并经常让软件开发人员和用户交谈。 2. 避免打地鼠式开发  软件项目经理经常面临及早交付产品的巨大压力。时间是关键。你如何才能 快速完成任务呢？ 假设你的团队有两名程序员，伯尼和罗布。两人都很能干，知识面相同， 编程语言技巧也相当。你发现在开发过程中伯尼实现软件功能的速度远远超过 罗布。 当伯尼着力于快速完成编程时，罗布正花时间写代码并对其进行重构①。罗 布对变量和方法的命名更擅长。一旦写的程序能够运行起来，他就把这个程序分 成几小块。现在他要写测试来确保该程序的每一块都能按照他的意图运行。当他 觉得结果比较满意时才宣称实现了功能。 但是假设你并不知道上述这些细节。如果你只看他们谁先宣称实现了功能， 那么很明显伯尼表现得更好，对吗？ 几个星期之后，你向客户演示这些功能。像往常一样，顾客喜欢你已经完 成的功能，但现在需要你做一些改动和完善。你让软件开发人员修改这些代码。 当你把新改进的功能带回给客户时，他们试用了罗布实现的功能，对他做出的 改动十分满意。 ① 重构就是改动代码，完善其内部组成结构而不改变其外部功能。它改进软件产品设计。重构代码 是回过头去完善以前仓促创建并测试的某项可用的功能。现在需要进一步对该功能进行内部改进， 以便长期使用，也使日后增加功能更为方便。 遗憾的是他们发现伯尼实现的功能有些奇怪。当伯尼编写好新的功能后，一 些以前能使用的功能现在却不能用了。客户把这些作为缺陷标记出来，然后你让 伯尼来修改。客户又一次测试这些功能，结果后来新增的功能也不能用了。这到 底是咋回事呢？ 如果你有孩子，就会知道发生了什么。伯尼创建的是一个打地鼠式的应用程 序。打地鼠是一种游戏，孩子们拿着一个木棒敲打几个孔中随意弹出的地鼠，他 们会很惊奇接下来是哪个地鼠弹出来，而且还乐此不疲。然而，在修改应用程序 的时候如果总有坏代码不知从何处随意弹出，那可不是好玩的事情。那会令人沮 丧，结果也难以预料，并且它会减慢产品开发速度。伯尼一开始就全