项目管理-4-运筹帷幄

一叶舟 · 发表于 2012-6-8 15:46:20

本帖最后由 delia2010 于 2013-4-16 12:05 编辑

项目管理-4-运筹帷幄

引言
“运筹帷幄之中，决胜千里之外”“三岁知老”，前面的愿意说的是某人的智慧超群，现在的意思主要是说谋划的重要。后面一句说的是人在最初阶段对后面的重要影响。对于项目管理来说，项目最初的选择，对整个项目的成败，起着至关重要的作用。而这个最初的选择，就是项目的生命周期模型。
前面两节分别介绍了项目章程和项目规划，从这两个项目活动过程中，得到了项目的成功标准和发布条件，按照顺序的话，下一步应该是日程安排了，但是在日程安排之前，需要作出一个决定，即，这个项目采用哪种生命周期模型。不然的话，日程安排就没法往下做。所以这一节就说一下，如何为项目选择合适的生命周期模型。

跟前几节一样，先说概念，然后是注意，再有一张简图，简图包含了这一节的主要内容。

4.1概念定义
项目的生命周期模型：就是项目经理和团队组织产品开发的方式。说白点，就是你打算让你的孩子将来干哪一行。呵呵，如果你有孩子的话。
如果你的回答是‘没有什么具体打算，看他自己的兴趣吧，喜欢什么就学什么’，那么您选择的生命周期模型就是‘敏捷’。
如果您的回答是‘我打算让他学音乐，从胎教开始就让他听音乐，然后让他学习音乐培训课程，然后考音乐学院，是从音乐界的名师，然后进唱片公司’那么您选择的模型就是‘瀑布’。
如果您的回答是‘先看看在说吧，先送他进幼儿园，学习各种科学，文化知识，然后再根据孩子的爱好，专门培养孩子的这种爱好，使之成才’，那么您选择的模型就是‘增量原型’。

上面说了敏捷，瀑布，增量三种项目的生命周期模型，需要注意的这些模型本身的区别不重要，重要的是您对哪种运用的比较熟练。运用的好的话，这些模型都可以是项目成功。就好像上面的那个例子，只要多和孩子沟通，根据孩子的具体情况，身体方面的，头脑方面的，发挥孩子的潜力，都可以把孩子培养成才。还有就是，这些生命周期不是绝对的，一个成功的项目，往往是多个模型的组合，在项目的不同阶段，采用不同的模型，甚至在项目的同一阶段，使用多个模型的组合。再次引用伟人的一句话‘不管白猫，黑猫，

只要能抓住老鼠，那就是好猫’呵呵。记住，完美的生命周期，只是‘模型’而已。梦想要照进现实才行啊。

4.2选择生命周期模型
一般，项目的生命周期模型有以下几种：
如图所示。

这些模型的对比，如图所示。

前面已经说了，这些模型的定义不重要，重要的是灵活应用之。所以下面就说几种具体的情况，如果项目中有这些情况出现，应该如何应对。

及时的得到反馈。
对于项目经理来说，最麻烦的事情，就是没有反馈。可能不止对于项目经理，对于任何人做任何事，如果你才去了一个举动，结果没有任何反应，俗话说的好‘咬人的狗不叫’。没有反馈，就意味着你不知道这个举动的效果如何，所以比‘摸着石头过河’的情况还遭。因此，尽早的获得项目的反馈，就能尽早的摸到项目的脉搏，摸到脉搏了，才能掌控项目。而这个反馈，就来自于测试，所以，应该让测试人员尽早的加入到项目里来，对每一个新完成的代码段（功能模块）进行测试，这样开发人员也能得到反馈，也能验证架构设计的合理性，可行性，和稳定性。

如果这个项目中包含硬件或机械。
如果这个项目包含软件，硬件，还有机械等等领域，那么难度就很大，软件控制硬件，硬件控制机械结构，最终完成整个功能的执行过程。开发的话，顺序就反过来了，要现有机械，然后才能验证硬件的性能，然后有硬件，才能验证软件的性能。重要的是，硬件和机械的bug修复周期很长，一旦出错，就需要几天，甚至几十天的延迟，此外，也造成了成本的浪费，还有，有时候硬件的改动，会引起相应软件，尤其是驱动程序的修改，代价很大。所以，在这种情况下，我认为，想让机械和硬件先做，并让软件参与讨论和进行整体架构，等经过硬件基本完成调试后，才让软件开始编码工作。当然，如果你已经确定某些模块式硬件必须的，那么也可以开始软件的工作。不一定非要等到硬件全部做好。

管理设计风险，也就是架构风险。
如果你担心架构的某些方面存在风险，那么就尽早的开发可以验证这些风险的功能模块，来对架构进行测试和检验。对于瀑布来说，要尽早的做试验，检验一下架构是否可行。比如说，你现在做的事一套UI，里面含有对显卡，和内存要求比较高的动画效果，你担心的是在播放这些效果时会不会卡屏，你明白，一旦卡屏的话，就需要更换硬件平台，或者采用其他的播放技术。那么就先做一个简单的动画，然后在实际平台上播放一下。来决定是否采用现有平台。
另外一种措施就是，用时间盒来限制架构所用的时间，留下更多的时间用来调整或优化架构。

如果你开始接手这个项目时，用的是瀑布，那么如何才能摆脱出来呢。
用迭代和时间盒来规划和限制所有活动。
尽早的将产品原型化，即尽早的作出一个demo版，然后展示给客户，然后从客户那里得到反馈。我曾经历过一个项目，客户要求一个产品，我们做了大约两年的时间，客户基本上已经接受了，但是还有一些商品化属性，需要做。这时，来了一个新的开发人员，原来的开发人员被调到了其他项目组，这个开发人员来了之后，发现，已有的这个产品，做的太次，于是经过老板同意，用了大约3个月的时间，重新设计，出图，制造。调试完成后，拿给客户。结果是，客户认为，这个产品跟原来的产品差异太大，并且重量过重。后果可想而知。‘闭门造车’，我想就是这个意思。
从项目一开始，就开始测试。这个前面已经说了。
功能要逐个实现，不要把所有功能都实现后，再集成。要完成一个，集成一个，测试一个，也就是敏捷里面的‘持续集成’。

4.3小结
要综合使用生命周期模型。只有完美的模型，没有完美的项目。尽量不要采用瀑布，要不然在后期集成的时候，亡羊补牢，来不及了。羊都已经被狼吃完了。

上一篇：项目管理-3-起锚出港
下一篇：项目管理成功的四个因素