我的第一次项目管理--一次惨痛的教训

Posted 工藤-新一

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了我的第一次项目管理--一次惨痛的教训相关的知识,希望对你有一定的参考价值。

  最近总想发点时间写些东西但抽不出时间,趁着放年假并且今天刚开完项目的年前回顾会议赶紧写出来,其实挺不好意思讲的,有点尴尬。

莫名的项目负责人:

  由于公司逐步发展,项目越来越多,没有人有时间来负责这个项目,我的老板们可能看我比较顺眼于是便让我来负责这次的项目开发,于是我便莫名其妙的变成了项目负责人,一开始我是拒绝的,让一个什么都不懂的人来管理项目真的是太可怕了。哦,忘了说明,我们的项目成员就几个人并且每个人都身兼多个项目开发任务,因为是小公司。

项目工作量的预估:  

  当时在做工作量预估的时候参考了像《程序员的职业素养》、《网易一千零一夜》等书上描述的工作量预估方法,将模块细分并采用理想人日来估算,当时算完的时候还觉得估算挺合理的。结果打脸了,我的天,大大超出了项目的预期完成时间。我们没有考虑到项目的缓冲时间,如需求改动以及其他优先级更高项目任务开发导致的时间延迟等。

缺乏沟通导致的项目失控:

  在确认迭代的工作内容后我们开始了二十天的第一次迭代开发,在这期间我们很少沟通除了有依赖的部分确认下,在我完成工作内容时发现另一模块的开发停止了,他们被指派去做其它优先级更高的任务,项目组的其他成员并不知情。这个时候的我并未发起会议向上层领导反馈协商开发的时间,而是选择催促他们,直到又过了礼拜我发觉他们的开发还是停留在原地于是才让我的领导发起协商。

  将近耽误了一个月的时间,很明显责任在于我,之后我开始觉得站会、周会等的重要性,并开始实施,效果比较显著。这些会议能让项目组所有成员清楚的了解项目的最新进展、各成员的开发状态以及项目风险的评估。

编码质量不过关:

  上一篇博客也有提到过我们公司目前代码质量的问题,我认为对于代码的质量是研发人员必须保证的,我们需要以让测试人员找不出Bug为目标,尤其是目前我们公司的测试仅仅是在做一些模拟用户行为的测试,并不像《google软件测试之道》中描述的还有软件测试开发人员配合我们测试。 

有效会议的重要性:

  现在公司大大小小的会议可能都需要最高层领导来参加,根据我最近一段时间参与的会议以及这次项目过程中发起的一些会议,我们在会议前总是没有把会议想要讨论的内容、通过会议我们想实现什么目标、我们需要与会人员什么帮助等,并且会议中没有意识到时间的把控,我们知道会议的成本是非常昂贵的尤其是在有最高层领导的会议上,会议的把控也是今后要努力的一个方向。

总结:  

  写的有点乱,但大致上想讲的也就这些,据说公司三月份测试部门回来七个应届毕业女实习生,据测试部内部消息好像有几个还挺漂亮的,所以,年假这段时间再好好充实下自己,晚安。

 

 

 

 

 

  

以上是关于我的第一次项目管理--一次惨痛的教训的主要内容,如果未能解决你的问题,请参考以下文章

一次惨痛教训让我写了个Windows定期备份文件脚本

USB走线布局经验,一次惨痛的教训

USB走线布局经验,一次惨痛的教训

github总结--关于git reset --hard这个命令的惨痛教训

使用ConcurrentLinkedQueue惨痛的教训

兵败DevOps!一个Bug损失4.6亿美金,不得不看的惨痛教训!