 |
公 告 |
 |
登 陆 |
 |
日志日历 |
|
日 志 |
|
评 论 |
|
链 接 |
|
统 计 |
| [转帖] 计划的目的不是为了变更 | ||
| 该日志同步发布于帖子：“[转帖] 计划的目的不是为了变更” 定项目计划的目的是什么？又在这里提这种饭桶问题了。 我们常常看见，在项目初期，有一大堆计划需要制定，什么“开发计划”“需求计划”等等等等一大堆计划。可是这些计划一般有两个下场： 1、废弃不用（缺乏流程管控的项目。好像这样的项目组越来越少了，在此就不给出进一步的解释）。 2、等待“变更”（有流程管控的项目）。 其实无论什么“计划”，其差不多都是和小时候定的“学习计划”在功效上差不多的。“计划”的目的在于“执行”（以便于我们达成“目标”）。我记得，老师或者家长帮助我们制定学习计划的时候，总是要提醒我们留出足够的休息时间，娱乐时间，这一切都是为了“可执行”。“计划”是靶子，“可执行”是射箭；“按照计划执行”就是“指哪打哪”。 而我们常常遇到的是，制定计划的时候缺乏对于“可执行性”的考虑，但是为了计划能够顺利的“所谓的执行”，就不断的“变更计划”。通过变更计划，把原定的“指哪打哪”修改成了“打哪指哪”。 为什么我们上小学就知道的道理，到做项目的时候又全部忘记了呢？问题的关键在于我们只学到了“软件过程”的形，而没有学到“软件过程”的神。制定计划的目的成了为了满足“流程需要”而计划变更就更是为了“流程需要”。因此在自觉与不自觉的情况下，制定出为了“等待变更”的项目计划。 而项目计划远比“学习计划”复杂，其中不仅仅需要涉及多个项目组成员的相互配合，还需要涉及协调项目组外的相关资源；同时，由于“项目目标”也远比“学习目标”复杂。因此，项目计划的可执行性就更加的难以控制。但无论如何，“可执行性”永远是计划的第一要素，甚至高于“项目目标”。试想，有多少不切实际的 “项目目标”害了一堆堆的先烈们。 但是如果确实出现了“计划赶不上变化”的情况如何处理呢？解决这个问题的核心在于：维持可执行性，砍掉不切实际的需求。想想我们小时候如何对待“不能按计划执行”这个问题的，我们采取的措施一般都是“删除部分待学习内容”以及“减少学习时间”。同样，这也是唯一的应付项目中“计划赶不上变化”的方法。在保证计划“可执行”的前提下，删除部分待开发内容。而这些待删除的内容自然就是“低优先级”的需求。在我看来，没有“优先级”的需求就不算“需求” 如果需要深入了解“计划”，建议大家暂时放下“项目管理”这个课题；去了解一下“时间管理”等这些相对粗浅的理论。这样反而有助于理解“项目计划”真正的内在含义。从这里面，也可以充分的了解到“工具”对于“本质”并没有什么实质性的改善。当理解了“项目计划”的本质，工具可以起到帮助作用；但是工具绝不能帮助理解“项目计划”的本质。 | ||
|
- 上一篇：一个非技术人员是如何向项目经理的转变！
- 下一篇：[转帖] 项目验收会的准备
| Re:[转帖] 计划的目的不是为了变更 | ||
谢谢，对于正确认识与理解计划很有价值。 当前，很多人对于计划的理解是很肤浅的，也就导致了计划的失败。 若要推行计划管理，任重道远啊。 | ||
|