【转】IT项目管理杂谈
上一篇 /
下一篇 2015-03-17 10:04:52
/ 个人分类：项目管理
计划
计划本身就是对项目的预测，如果等所有的事情都明确了再来做计划，那么可能你始终都无法去做计划，当你期待的东西明确后你又发现了新的不明确的东西。因此计划本身就是基于假设下的某种确定性，再简单点说就是如果人员，团队，环境和技术怎么样了？项目团队应该可以完成哪些事情。而假设即是风险，所以计划是基于风险的一种对事物发展趋势的预测。
当你面对一个大的不明确的事物的时候，首要工作仍然是分解，只有通过分解才能够把确定的东西和不确定的东西分离出来。对于确定性的事物可以先行，对于不确定性的可以考虑风险应对和替代方案。当我们面临一个关键技术没有解决的时候，我们往往第一反映是无法做计划，但是我们需要的却是基于假设和风险的计划。比如：
假设关键技术A能够在一周内预研成功和解决，项目应该在6周左右时间完成。如果关键技术在一周内无法解决，我们需要启动替代方案2，当采用替代方案2时候项目在8周左右时间能够完成。这种陈述方式本身就是计划，并且可以看到如果这样描述让我们会根据高度关注风险和不确定性。
范围
我不得不再回顾下教科书的内容，计划是渐进明细的，而范围是一开始就确定的。计划可以渐进明细，但是范围不能蔓延。但是实际的情况往往确实就是项目范围在蔓延，范围完全不变动基本很困难，所以项目管理者根据应该关注范围受控这个概念，范围可能会发生变化，但是一定要受控。
范围通用涉及到两个方面的内容，一个是产品范围，如果产品范围发生变化必然会增加项目范围，所以首先要控制产品范围和用户需求。其次是项目范围，当产品范围没有变化的时候，由于我们采用的过程管理策略同样影响到项目范围。即时产品范围和项目范围都没有变化，如果我们采用的技术实现方案不同，仍然会影响到工作量，而工作量直接影响到进度目标。
我们无法控制范围完全不变化，那就转变思路，尽量让范围的变化尽早的被识别出来并解决掉。即使是资深的需求分析师也无法保证完全能够通过需求规格说明书和原型覆盖用户的所有需求，因此唯一的方法就是短周期迭代，尽早的交付首版本，尽早的获取用户的范围变更信息。
进度
很多时候我们是知道进度会延期，但是却无能为力。由于导致进度延期的原因，涉及到的人，团队环境等因素太多了，导致我们无法快速的作出相应的应对决策。那好吧，还是抓紧时间赶进度吧，连沟通都免了，而最后结果往往确是进度恶化。如果我们只是发现问题，而不去解决问题，那发现问题本身也就没有了意义。进度都知道要延期了，还需要开会浪费时间吗？答案往往是暂停并集体思考和决策比贸然前进更加重要。
从软件开发生命周期来说，软件开发包括了需求，设计，编码，测试等诸多过程。前面需求，设计，编码都没有延期为何测试延期这么多呢？测试应该来背这个责任吗？要知道测试的时间长短首先是跟前面各个阶段的工件质量相关，其次才是和测试人员本身的效率相关。进度延期的根源往往是前面各个阶段不切实际的进度，我们采用可视化项目管理和增量迭代，冒烟测试和每日构建都是为了让前面阶段的进度尽早的可视化。
平衡
平衡是我们在项目管理中谈的比较多的一个词，平衡也是项目经理的一个重要能力。但是平衡仍然是相对的，很多时候我们谈平衡是项目目标驱动的，但是更应该谈平衡是用户满意驱动的。一个项目延期交付2个月，投入增加了30%是否就一定不成功呢？显然不是，因为在这段时间可能是用户驱动增加了一个关键需求和功能，而且也增加了投资，及时晚交付仍然可能是用户满意。
平衡不能牺牲质量，因为质量的一个衡量本身就是用户满意，要意识到其余都可以变化而质量不能变化。很多时候项目失败的原因就是去降低质量，导致了钱也花了，项目也延期了，最后仍然是用户无法满意。
说明：此文转自人月神话的博客。
相关阅读:
- 精确项目估计 (zaza9084, 2014-10-30)
- 做好项目沟通计划 (zaza9084, 2014-12-04)
- 项目管理工具Redmine各功能测试 (zaza9084, 2014-12-10)
- 项目管理——细节之处见真章 (zaza9084, 2015-1-21)
- 浅谈软件测试项目的风险管理 (zaza9084, 2015-1-27)
- 敏捷开发项目管理规程 (zaza9084, 2015-1-30)
- 软件项目将死的27个征兆 (zaza9084, 2015-2-04)
- 快速软件开发项目中的有效沟通 (zaza9084, 2015-2-25)
- 关于测试管理的一些经验之谈 (zaza9084, 2015-3-11)
- 谷歌将关闭代码项目管理平台Google Code (zaza9084, 2015-3-13)
收藏
举报
TAG:
项目管理
