比较失败的项目管理经历总结

这可以算是我在学习PM相关知识之后第一个跟项目相关的管理经历。现在项目即将GA了，回顾下来，我这个所谓的PM真是当得失败之极。

 

首先从项目的启动阶段开始。启动最大的问题在于耗时太长。在这个project时间限定的情况下，无形之中加紧了后面的进度。启动由于不是我负责，我只是帮助去写相关的需求和scope文档，而负责的人由于和US之间的沟通太长，从最开始确定到最后定下来整个项目范围，大概搞了个把月，而这个把月中Intern一直处于闲置状态，造成了人员的极度浪费。

 

这里得到的教训是从项目开始有个概念，就应该对相关问题进行思考，包括人员的安排，预先熟悉相关技术和环境，整个项目的时间已经可能达到的项目的scope，环境的限制和条件，项目的可行性等。

 

人员上，应该尽早考虑不同人员之间的专长，以及让对整个项目环境不熟悉的人员尽早熟悉相关技术和环境。

时间上，如何在现有的时间下基于不同的人员的基础，可能达到的项目的完成范围；

技术环境有没有什么限制，是否在环境方面存在某些风险，比如所依赖环境的不稳定，技术上的不确定因素等。

 

 

其次，从项目的设计上考虑。在项目范围确定后，WBS的分析主要是由我来做的，个人的感觉就是，真个WBS的粒度过大。由于时间紧迫，在考虑WBS的时候只是简单的进行了模块划分，简单的估算了时间就直接设定了schedule。期间并没有考虑很多风险。对的，风险是做项目经常会忽略的一个东西。下面我将主要讨论这中间存在的一些问题。

 

拿到一个项目的具体scope以及需求，该如何去估算项目的进度（成本不在考虑范围之类）。

第一个要考虑的是：如何划分为整个工作，也可以看做WBS的第一层级。我们知道软件项目最常见的是需求，概要设计，详细设计，编码，测试这几个步骤。WBS的划分可以基于项目阶段也可以基于工作内容。我觉得软件项目基于项目阶段是比较常见的。

 

以下是一个小型项目，我觉得常见要考虑的WBS的层次

概要设计：

---------模块设计

---------------------模块1

-------------------------------任务1

--------------------------------任务2

---------------------模块2

---------接口设计

---------文档攥写

详细设计：

（对不同的模块）

---------类设计

---------方法

---------流程

---------错误处理

编码：

-------模块编码

------- 单元测试

-------------------UT coverage

-------------------Bugs fix

-------整合

----------------code change

----------------Bugs fix

测试：

-------集成测试

---------------------具体的case coverage

------系统测试

--------------------case coverage

------部署

----------------环境准备

---------------部署测试

 

可能存在的风险：

1 模块设计的时候对需求的理解有偏差；

对于这种问题，应该在项目进行的每一个阶段和相关人员及时沟通，如进行文档，代码review，以及通过定期会议来保证这些偏差不会再最后的时候差的太远，能够及时纠正。

2 需求有所变更；

3模块的接口设计不符合实际或存在变更需求；

以上这些变更是难免的，主要是每个变更能及时通知到相关人员并尽量在设计的时候保持灵活性。

4 错误处理考虑不周到。这个是经常容易出现问题的地方，很多人员在开发项目的时候都会按照正常的思路去实现需求，而如果不及时发现最后会导致所有的问题会在最后崩溃，代码的五健壮性可言。避免这种问题的方法：一当然是提升开发人员的水平，但这是一个长期的过程，很难短时间实现。那么短期的话应尽量早点进行code review，并且经常讨论一些可能出现的异常，由于小项目，测试，开发可能都是同一拨人，那么就要尽早的进行测试，哪怕只是单元测试，白盒测试等。而且这种测试最好经常交叉，比如开发A去测B的代码，反之亦然。

 

当然我所在的项目我做的比较失职的地方就是知道demo出来我都没怎么管过他们写的code，最后到了后期光是修改这些异常处理不周的地方就费了2周左右。

 

5 接口：接口是最容易出毛病的地方，也是集成测试的时候最费事的地方。我觉得我们项目存在的主要问题是：第一，单元测试不够，在每一个模块充分保证其质量之前集成起来往往就是拆东墙补西墙，一会这边漏一会那边漏。 而单元测试主要是在于模块负责人个人的责任心。无奈实习生中有的实在很没工作了的人那么负责，虽然能力有的真的还可以。 当然我这个所谓的PM没有过早的进行验收和检查也是一个很大的原因。但如果所有的事情都要我这样的话，我真的很累~~~。第二个问题就是接口经常会发生变更。而这些变更有可能是对需求理解不够充分，有些问题没有考虑周到，或者需求的增减等。变更是不可避免的，这个我可以理解，但在重大的问题上最好还是不要老变来变去，除非非不得已。

 

 

把这些问题分解完毕之后可能就是需要对这些component或者task进行估算，怎么估算，PM介绍了很多方法。我主要谈论我遇到的问题。

一：没有考虑人员的工作时间量的问题，即工作时间和可用于项目的时间。很多intern经常需要请个假啦，或者某些人又很忙别的事情之类的。

所以在估算时间的时候，要考虑可用的时间，而且是可用且有效率的时间。二： 由于技术经验不够，有些问题不能准确的估算时间，而且有的时候一个技术问题往往会花费好几倍与估计的时间，第三：没有考虑环境的不稳定性。由于项目对环境有所依赖，有的时候环境的不稳定同样会影响项目的进度，所以这也是一个潜在的风险。

 

因为综合以上，因为充分考虑员工的可用且有效率的时间，将技术瓶颈问题所耗费的时间平摊，也就是说有的很简单的项目可能估算时间超过了预期，这样可以将其时间移过来，因为在估算每个task的时间的时候需要由一定的reserver time。 第三，将环境不稳定性当做一个可能发生的风险加以考虑。

 

再次：项目执行阶段。status meeting和review的重要性！！！我总结就是：盯着schedule，定期做review，变更要及时，问题早沟通。

 

我作为所谓的PM范了一个毛病，前面的时间基本没status review，我以为人们总是很自觉，总会按时完成所布置的问题，总会如实汇报。于是我就是简单的盯了盯。后来发现并不是这样的，有人会虚报，有人会偷工减料，有人也很懒，原来人总是有惰性的。按照那谁谁谁的人际管理理论应该悲观些（具体理论不记得了），就是下次应该假设人们总是会偷懒的，总是会不按时完成任务的。这样我会比较有警惕行。

 

对于schedule，重要的里程碑一定要保证，review的时候一定要结合每一个阶段应该完成的任务以及里程碑来，这样才能及时掌握发生了什么，有什么风险。问题早沟通，这点很重要，有的人埋头苦干，有了问题一个人钻研，但是别忘记了，我们的project是个teamwork，这是由时间限制的，所以保证进度是最重要的，其次才是 保证你的钻研心里，实在遇到问题了吼一吼所不定也就解决了。

 

最后：如果对于技术不是很精通的PM，得有个tech的军师，不然你都被忽悠了，还不知道~~~~

当然提升PM的专家权利是很重要的，可是这是个漫长的过程。

 

希望下一次我能做得好一点。

 

整个做下来一个感觉：亲力亲为，可是我真的很累~~~当然我不怨，因为我经验不够。。。失败也是难免的。好歹我总算保证了进度。