《构建之法》读后感之项目计划

最近看到 《构建之法》的“8.6 计划和估计”这一节,颇多感触。这些年来,不同的阶段,对项目计划都有不同的认识和掌握。

邹老师提到了制定计划的几个概念:目标、估计和决心。

  • 目标:表明一个希望达到的状态。例如,软件“五一”之前要投放市场!在建校一百周年之时把我校建成世界一流大学!不论这类目标如何重要,它们未必能够实现。
  • 估计:以当前了解的情况和掌握的资源,要花费多少人力物力时间才能实现某事。
  • 决心:保证在某个时间之前完成预先规定的功能和质量。例如:我们跑步前进,全民炼钢,两年超英赶美!

 

大二的暑假的时候,从学校BBS上接了个私活,帮人做个办公OA系统,第一次独立的去做项目,雇主给了我一个别人的办公系统,让我模仿着做一个,功能界面样式都一样,给了一个月的时间,结果就是我最后一周连续在机房熬了好多天通宵,在时间点之前赶出来了。现在回头来看,这其实只有目标和决心,而没有任何估计,如果目标再大一点,如果不是年轻的时候身体好能熬夜,是不太可能完成的。

但就算有估计,也不代表就能制定合理的计划。毕业后刚参加工作,在一个项目中,项目经理给我分配了一个比较复杂的功能,让我估计一下时间,我乐观的估计了一下,觉得三星期就能搞定,项目经理不放心,给我按一个月时间算上了,结果由于我急于在项目中应用一些不熟悉的新酷技术,沉迷于技术细节中,导致一个月时间到了还是没能按时完成,导致整体项目延误,最后项目经理挨了批评。

类似的错误我不止犯过一次,也看到很多程序员犯过类似的错误:过于沉迷技术,忽视进度,导致计划不能按期执行,所以后面我尝试作出了一些改变:

  • 对于不熟悉不成熟的技术,尽可能不要应用到项目中,利用项目之外的时间去学习试验,验证后再应用。
  • 将项目计划细化,不能说一个功能模块一周,争取把计划的力度细化到天,这样能及早的发现问题。
  • 设置关键的时间点,在这个时间点的时候,需要交付一定的东西出来,这样就逼着自己不敢在某一个细节上浪费太多时间。

 

后来在自己开始去做项目管理的时候,在做项目计划的时候相对有了经验,其实自我管理是最难的,管理别人要相对容易得多。但即使如此,在做项目计划时也遇到很多问题。

遇到的第一个问题就是如何做团队的项目计划,以前自己给自己做计划,相对容易,但如果整个项目的计划要一起做就比较麻烦了,每个人的能力水平不一样,预估项目的乐观程度不一样,要协调起来可不容易。

最开始的时候,我尝试按照自己写代码的经验来给大家分配任务和定计划,比如说这个用户注册模块我觉得我需要三天,给张三做,张三经验不如我丰富,那么张三应该四天能搞定,给他四天时间。这样计划是很快做出来了,但是问题马上来了:

  • 首先是准确度不高,误差比较大,每个人实际上在做的过程中都会遇到各种各样的问题,比如前面提到的让张三四天完成注册模块,可能他以前没做过,而且正好环境不熟悉,那么可能四天根本完不成。还有可能是他直接用一些现有第三方模块,一两天就完成了这个功能。
  • 然后是当发生计划不准确的时候,项目成员会有情绪。比如注册模块让张三四天完成,结果功能比预计要复杂,导致张三加班加点才勉强完成,张三就会想,这个功能我当时就觉得四天不够,你只给四天,这不是故意为难我吗?

 

于是尝试做出调整,对功能模块进行划分和分工后,让团队成员自己去预估时间,在实行一段时间后,大家积极性是提高了,自己定的计划,含着泪也要按时完成,但又有新的问题:

  • 以前计划都是项目经理一手包办,而现在需要自己去制定计划,很多人在定计划的时候才去了解项目需求,在需求不了解的情况下做出的计划不靠谱
  • 有的人的计划过于乐观,完全没有预估到项目的复杂性,导致最后项目计划难以完成;有的人比较偷懒,定的计划总是很松散。

显然项目经理想当甩手掌柜是不现实的,所以后来在定项目计划的时候,我一般会分成以下几步:

  1. 第一步,在目标(项目需求)明确后,开始预估项目计划,这时候精确度不需要太高,精确到周为单位即可。
  2. 第二步,对项目需求和团队成员进行同步,确保项目成员充分理解项目需求,将任务分配下去后,让项目成员自行评估各自项目计划
  3. 第三步,对项目成员的计划进行一一核查,参照第一步预估的时间,对过于乐观的和过于宽松的,都要一起把计划细化,细节仔细推敲探讨,确保计划科学合理
  4. 第四步,完成最终计划,并确定几个关键里程碑,确保在里程碑的时候能交付一定的内容


 

这样下来,制定的计划相对要合理多了,保持进度的跟踪,尤其是里程碑时间点的把握,基本上不会有太大的问题。

但项目计划还是很容易受到外部影响的。在《构建之法》里面提到了软件项目的时间估计可以从两个方面来看:

  1. 自底向上。团队成员各自估计底层模块和单个功能(及单元测试)所需的时间,再加上集成及基本测试的时间,就是大概的开发时间。这还没有考虑各个模块之间的相互依赖性。
  2. 回溯。团队从整个项目最终交付之日往回倒推。

 

很不幸,我见过的绝大多数项目都是采用的回溯法来制定计划的,比如客户说,这个功能我下个月必须上线;比如就算你按照自底向上制定好的2个月项目计划汇报给老板说,老板说2个月太长了,希望1个月就能看到。

这个问题其实在软件工程中是个非常典型的问题,有的比较滑头的项目经理会在上报给老板的进度加个比较大的Buffer,例如本来两个月可以做完的,报上去是三个月,那么老板压一压,还有两个月时间,这不是皆大欢喜了!不过这毕竟只是“术”,玩多了被揭穿了以后就没得玩了。

那么什么是“道”呢?在构建之法中有一张“功能/资源/时间的平衡图”,非常形象的说明了这几个项目要素的关系。

 

项目管理也是一种平衡之道,现在在资源不变,时间缩短的情况下,要么去牺牲功能,要么去牺牲质量。一般在这种情况下,如果不是一次性产品,我通常会选择牺牲功能,质量上欠的债终究是要加倍还的,功能可以通过版本的迭代来完善。

 

 

除了被缩短时间导致计划更改,还有个计划更改的重要因素是来自需求的变更!据说因为需求老变,产品经理或老板被程序员砍的例子不少!其实需求的变更在软件项目开发里面是常态,没必要太过抵触,但是需要科学的去管理。一般来讲,如果项目的周期越长,需求变更带来的影响越大!所以现在一般互联网的项目,都比较追求功能精简,快速上线,上线后持续迭代。

在遇到一些影响项目计划的问题时,我一般处理原则如下:

  1. 对于需要缩短计划时间的,根据情况减少一些功能或牺牲质量,并承担相应的后果
  2. 对于需求变更的,评估是否对整体进度有较大影响:
  • 如果影响不大,则不改变整体项目计划,只做局部调整
  • 如果影响较大,则对重新制定整体项目计划,走相应的需求变更流程

同时,为了能及时相应需求的变更,需要对每一期项目功能进行合理筛选,合理搭配核心功能和外围功能,让项目周期在一个相对可控范围。

 

项目计划是项目管理中非常重要的一环,不计划无管理。不同的项目不同的团队,项目计划的方式也各有不同,不过万变不离其宗,根本还是在于对软件工程构建之法的掌握和运用。

©️2020 CSDN 皮肤主题: 技术黑板 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值