《项目管理修炼之道》 读后感

刚读完《项目管理修炼之道》不久,我也不记得从哪看到这本书的介绍,反正一直搁在书单上。虽少有项目管理的机会和经验,但有幸经历过几个管理糟糕的项目,已然知道如何可以做到最差,殊不知如何做到最好,遂找来一读。

作者基于大量风格迥异的案例来说明问题,并针对每种可能出现的项目管理问题给出了相应的应对之道,细致到给出相应统计表格样式。

alt

项目管理的主要是管什么?

简单说,项目管理即是对风险的管理。在整个项目周期中,需要项目管理解决和规避可能导致项目失败的风险。

而风险可能是不期而遇的,这要求项目管理能够及早认识和响应风险。

如何管理风险

1,限定开发时间盒

应该认识到这个充满变化的世界,没有人能准确规划过于长的周期。过长的周期意味着更多的风险,以及更慢的风险响应速度。所以开发时间应该限定在更小的时间周期内,这样较能准确预估和发现并响应风险。

2,迭代开发

迭代开发同限定时间盒一样,是为了更为快速灵活的交互,来响应需求和架构的变化。

3,测试

及早测试。尽早测试能够让问题解决的越及时和从容。

基于功能模块开发。为了更方便的测试问题,建议在开发时基于功能模块,而不是架构层级来实现。

测试驱动开发。好的测试驱动开发不光能减少漏洞,还能帮助实现更好的设计,再辅以代码重构,会让程序代码更为稳定高效。

4,高内聚的项目团队

各司其职的项目成员若分属于不同的部门,如测试人员在QA组,架构师在架构组,他们只向直属经理汇报工作而不是项目经理,不能被项目经理统一安排管理的话,那项目各工作将限于耗时的相互等待和推诿当中。

必须组建跨职能部门的高内聚团队,保证在该项目实施的周期内,所有相关人员资源能被独占并被统一管理。

5,高效的会议

会议是效率杀手,但又不可避免。为了保证会议的高效进行。会议组织者须在会议举行前就确定会议议题,时长,参会人员,会议产出等。尽量少召开需要所有人参加的会议。

总之会议应该像迭代开发的时间盒一样,短小精干,有的放矢。

吐槽

项目管理是一项很具技巧性和挑战的工作。为了使项目成功,需要项目经理具备多方面的能力,资源协调的能力,风险追踪量化的能力。

但就我个人经历的项目而言,管理是相当糟糕的。开发人员同时负责多个项目,经常需要来回切换于多个项目之间。测试只有在上线前进行,甚至没有测试,直接UAT。项目管理人员只依赖甘特图,以及几次会议所确定的几个重要里程碑节点,便以此作为项目管理的唯一依据,不能及时了解项目风险所在,不能用相关表格度量风险级别和数量,也就无从灵活调整项目进程。

总之这些怪现象的后果就是项目极其难以推进和交付,即便交付其问题也是其多。但却很少有项目管理人员能清晰认识到这些问题,依然用这种非技术的方式管理着项目,无怪乎国内太多的软件作坊,永远也长不大。