|
控制并不是良好的技术性工作的附属品。项目控制必须透过积极的项目管理与持续渐进的控制行动来落实。项目控制的具体行动将在本文其他部分谈到。项目管理者联盟文章
项目洞悉力项目管理培训
与项目控制密不可分的是“洞悉力”的概念，这是指决定项目真实状态的能力。项目是否进行在时间、预算目标的10%范围内，项目是否按部就班地达到质量目标，或是远远落后目标？如果项目团队答不出这样的问题，这支团队就缺乏足够的洞悉力来控制项目。
下面是一些改进洞悉力的方法：项目管理者联盟
◆用前景叙述或目标来订出项目的概括目标。如果你不知道项目的行动方向，项目大概就推动不了了。
◆在项目完成10%后做一次规划审查，看看项目可行与否，以决定是否该完成这个项目。
◆经常比较实际进度跟规划进度，以决定规划方式是否有用，是否需要修正。
◆用二元完成点决定该做的事情是否完成。完成点只有“做好了”和“没做好”两种状况，因为事实证明，从“完全做好了”让步到“90%完成”只会让项目状态信息的质量从“很好”降到“极糟”。
◆定期将产品做成可推出状态，以决定产品的真实状况，并控制质量水准。
◆在每个阶段末尾修订估计数据，依据这些新信息来改善规划方式，并更进一步了解规划方式中的假设状况。项目经理圈子
许多项目团队最后发现项目洞悉力并不是自动得来的。如果你想要有良好的项目洞悉力，得从一开始就把这一点放在项目规划中，而如果你想要有个成功的项目，你就得有良好的洞悉力。项目管理者联盟
人因工程转自项目管理者联盟
软件开发需要创意和智能、原创与持久再加上高度的干劲。任何对软件开发有效率的做法是，如果项目团队没进入状态，项目就不可能成功。成员们进入状态，但是他们有可能士气低落，或是缺乏一个可以让麻雀变凤凰的灵感，甚至连团队的核心都可能在推出产品之前就离开工作岗位。talent.mypm.net
Tom DeMarco与Timothy Lister让“人因工程（peopleware）”这个显示出在软件开发过程中人类成员才是最重要的字眼变得热门起来。如果你不是名软件开发者，人因工程的一些准则也许会吓倒你。项目管理论坛
照开发人员的兴趣分派工作bbs.mypm.net
一般来说，软件开发人员的最大动力就是工作能与个人兴趣相符。如果开发人员发现工作有趣，他们就会发挥高度干劲。如果他们觉得工作很无趣，就会趣味索然。Robert Zawacki研究了十五年后指出约60%的开发人员的生产力来自个人有兴趣的工作上。要让人们发挥最佳生产力，请依据开发人员的个别兴趣来分派工作。有些人的干劲来自不可能达成的目标。可是开发人员有时太钻牛角尖了，如果目标达成不了，反而会让他们失去干劲。
项目管理者联盟
让开发人员知道你真的欣赏他们的成就项目管理者联盟
就像其他人一样，开发人员也喜欢别人对他们的赏识。如果项目主持人真心赞赏开发人员，他们对项目就会更加投入。如果主管对他们的赞美虚伪而做作，他们也以虚应对。不要用敷衍手法、离谱的目标或金钱诱惑来挑动开发人员的干劲。项目管理论坛
提供思考导向的办公室空间项目管理者联盟
软件开发既要有发现也要有发明，缺一不可。整体过程中最好的环境就是既轻松又可以自在思考的场所。开发人员要如同数学家或物理学家般聚精会神。试想如果爱因斯坦坐在办公桌前听着他的主管责骂他说，“爱因斯坦，我们现在就要看你的相对论！快把它写出来！”你想他做得到吗？（译注：爱因斯坦发表相对论时还只是个邮局职员）况且软件开发人员远不如爱因斯坦般聪明，他们需要更有助于工作的环境。项目管理者联盟
避免采用开放式工作隔间blog.mypm.net
有个老生常谈的论调，说开放式的工作隔间有助于软件项目间的沟通。问题在于这样的隔间沟通起来反而杂乱无章，连带影响生产力。有效率而良好的沟通还不如在茶水间放部汽水机来进行。开放式工作隔间有助沟通的论调乍听起来很吸引人，可是经不起确切考验，而且软件研究资料清楚显示开发人员只有在一两个人的办公室内最具生产力。项目管理者联盟
一些研究发现开发人员在隐密、安静、一两个人的办公室内工作和在开放式隔间的办公室内相比，前者的生产力比后者要高出2.5倍。软件开发是个需要高度思考的活动，如果电话响个不停，广播系统播个没完，人们在你四周走来走去，每隔几分钟就来打扰，怎么可能专心思考问题。身为主管的工作要求是每隔几分钟就转移注意力以达到管理效果。
项目经理博客
一般软件开发人员要求几个钟头内最好不要转移注意力，才能专心。许多组织没办法提供开发人员安静隐密的办公室。他们有的是空间不足，有的是要留给副总裁之类的人用。有些组织发现，将他们的开发团队安排到另一个环境去会更好些。其他组织则试着让开发人员带着耳机工作杜绝干扰，或者干脆让他们在家工作。至于其他没办法提供开发人员安静隐密而不受干扰的组织，只好自求多福了。项目管理者联盟
使用者参与度项目管理者联盟
软件使用者参与的程度对软件项目很重要。软件成功的关键在于设计出一般使用者爱用的产品。如果没有使用者的参与，软件开发人员常常会考虑技术层面而忽略使用者的需要。这样的话或许软件产品中塞进过多功能，使用者实际用到的却没几种。项目管理者联盟
要想开发出使用者爱用的软件产品惟一方法，在于问问使用者的是什么，把开发中的产品先告诉使用者，并问问使用者喜不喜欢这东西，聆听使用者的心声并参考他们的意见。项目管理论坛
也许项目团队得努力好几次才能了解使用者要的是什么。使用者们也必须了解开发人员让他们看的雏形跟未来的成品也许相差十万八千里。有时有分辨出哪些可能是未来的“使用者”都有困难。这些都会在以后提到。blog.mypm.net
由于使用者的参与消除了一大变量——摒除了“差不多先生”的心态，这样一来项目所费的时间就少得多了。如果使用者没从头参与，以后对项目产品进行检视时，一定会指出有好些地方没照顾到他们的需要。这时开发团队就得面对一个艰难的抉择：依循原来的预算与时程目标而忽视使用者意见，或是在项目的下游阶段接纳使用者意见而让预算跟时间超出预期限制。通常开发人员会妥协，先采用可立即修正的使用者意见，而将难以立即采用的意见留到程序的下个版本去处理。说老实话，让使用者在产品还具可朔性时愈早参与愈好，而且最好是在那些不被喜欢的东西出现以前。
由于“做了比没做好，早做比晚做好”的观念，使用者对自己参与开发过程的项目反而比没让他们参与的期望更深。表面上，愈早让使用者参与开发的软件愈能满足使用者需求与期望，而这也成了一种质量的认定方式。实际上这样的软件缺陷的确更少，因为它们在开发过程中方向变动较少，而让产品架构、设计方式与实作更稳定。如果在项目中途才加入使用者需求，被迫将没想到的功能加进体质不良的现有构架中时，软件质量一定会大副下降。PgMp.mypm.net
|
