最近和同事在项目管理方法上有些讨论，过程中有些感慨与收获记录下来分享给大家。
背景是这样的:
一个互联网公司，在项目管理上推进敏捷开发管理，快速迭代的同时又希望能够持续提升大家的工作效率，希望通过软件工具来规范开发流程，监控每个项目的花费时间，分析目前存在的问题，探讨如何通过系统提升精细化管理。目前的项目名称采用产品的版本编号，比如某后台1.0版本。
同事A认为项目管理目标是精细化管理，认为在管理中要严格遵循项目设定的内容，如果有Delay的内容，此项目要一直delay ，直到所有任务都达成后才能标识为完成。这样做的目的是为了系统化管理，通过系统把控详细的进度。如果项目中有未完成项目，把任务移到后续项目中是不对的，会影响项目的统计。所以基于此小A认为最正确的方式就是等待完成后再标示项目为已完成。
我在此有不同的观点，工具只是工具而已，在我看来，上述是传统开发中的管理方式。敏捷开发的核心思想是持续迭代。在敏捷开发中，一个版本发布就可以定义为一个项目，所以我们在项目管理中采用版本编号的方式。项目立项会议共同制定本版本的内容与排期，如果有一个任务因为资源问题导致没有如期完成，项目是否要上线需要团队评定，制定的时间截点就是为了提供可预期的上线计划。如果因为一个任务延期导致整个版本延期是错误的行为，所以我认为应该把当前未完成的任务放到后续版本中持续迭代，不应该因为一个任务的延期这个版本就始终延期。项目管理终究只是手段而已，只是为了最终目标而服务，一个功能的缺失不应该成为项目不上线的理由，除非这个功能是killer型的。如果我们团队的既定目标是小步快跑，持续迭代。就应该把当前版本标示为完成，加注相关说明，然后把未完成任务创建到新的版本上。
在我看来，这样的方式更有利于项目的管理和维护，项目上线内容由团队评定，初始的目标可以进行调整和改变，更加符合敏捷开发的迭代思维。如果单纯只是为了看项目是否有延期不能够只通过系统来看，从上面的例子来看，项目内容发生了变化，但版本如期上线，通过系统就无法有效管理，因为上线内容和初始版本目标发生了变化，所以使用软件就无法进行有效统计。这样管理不是为了隐瞒进度延期，而是为了更好的管理发布。如果采用A的做法，单纯从项目管理角度来讲我是认可的，项目任务有一个未完成就始终进行中，但因为这个版本有内容未完成而始终无法发布，会对产品带来不利影响。如果基于此方式，那项目名称不应该使用版本编号定义，而应该通过一个其他名称来定义，采用版本编号来定义项目就认定了一个项目就是一个版本，版本的发布上线就应该标示项目完成，在完成时增加相关说明即可。
最后我想说的是软件只是软件，千万不要为了管理而管理，还是应该从目标出发，抛弃目标谈管理只是耍流氓。管理最终追求的是价值而不是手段。管理的最终目标是推进公司的战略方针实现，落地战略规划，实现公司价值。落到部门上也应该是最大化实现部门的价值。正确的做事很难，唯有坚持，坚持，再坚持！
