代码改变世界

[原]浅谈在国内做项目的一些心得及问题建议

2014-01-23 11:54  池戎  阅读(202)  评论(0编辑  收藏  举报


岗位:

在项目的研发过程中,作为PM是整个团队的一面旗帜,应该无时无刻保持高昂的斗志,激励整个团队,让大伙感觉到一个整体的存在,共同进退。

 

在项目研发过程中,作为PM要维系好团队内部和外部的关系,有的时候,为了保证团队能获取更多更加有效的信息,PM应该出去“和”,与外部的商务、产品打成一片,了解更多更加有效的信息。

 

作为PM的角色,无时无刻对事不对人,针对问题要勇于提出问题,勇于指出团队的不足,同时不能烦躁,不应该因为一些小事就发火,而应该在任何时候保持良好的心态。

 

关心整个团队,特别是一些新人,让他们感觉到温暖,感觉到团队都会给予他们帮助,有目标,能学习到东西,有奋斗目标。定期开展培训,布道,宣扬个人能力,让团队成员能需要更多知识。

 

作为一个协调者,在任何时候都应该明确自己的职责,就是为了能将项目顺利结束掉,尽管项目进行过程中有这样或者那样的问题,在任何时候作为领导者都要顶住压力,跟团队成员一个轻松的环境,在任何时候都应该保持微笑,微笑面对团队,微笑面对项目,微笑面对各种困难。只有这样,才能让团队感觉到在一个战壕里面战斗,共进退,让团队更加团队,彼此信任,彼此了解对方。

 

心得:

哪怕一个项目在实施的初期看上去再美好,也应该抽出时间来评估其难易程度,有哪些细节会给将来埋下定时炸弹?

 

出现问题而指责别人是没有用的。即使是别人的错,如果没有解决方案,依然于事无补。

 

和客户的合作中,有的时候会出现一些问题相互埋怨,在这个时候曾经的口头承诺,口头的契约变得一文不值,需要书面的会议纪要形式的记录,有关于对此问题及解决方式的详细讨论。一定要遇事保持冷静,工作就是工作,不要掺入个人的情感,任何时候都不要在相互关系看上去比较融洽的时候给予任何承诺。个人感情只能成为项目的润滑剂,不能产生任何实质性的改变。

 

和客户在一起,永远都是工作,不管是和客户的谁在一起吃饭,那都是工作的一部分而已。

做项目的过程中真的不能前松后紧,这个是有非常大的风险的,作为一个好的PM,恰恰应该在大家不紧张的时候给大家加压,在大家紧张的时候给大家释放压力。

 

做项目如果对外发布的里程碑已经确认,应该确保在一周之前完成对Bug的修改,全力应对现场反馈回来的问题,一般有以下几个严重制约版本的按时发布:1.系统的技术问题;2.CQ里面的Bug3.现场反馈的问题。

 

项目不应该仅仅只盯着公司内部,如果能守住里程碑,就应该想尽一切法子守住里程碑,从技术和商务的角度来守。如果已经预判了里程碑无法达到,就应该想对策,如果实在没有对策,就应该想解释的理由,告知需求已经完成了,对于一些新增的问题,需要后续花时间来完成,这不是一两下能完成的,同时也应该清晰描述出做了哪些努力,完成了哪些工作,后续还需要完成哪些工作,从哪些方面来进行努力。

 

问题及建议:

问题:

在项目初期,有的时候我们会为了利益而满口答应客户的某些任务。这些任务在项目的初期也许是不明确的,甚至是无关紧要的,但是在项目的中后期,随着双方对项目认识的加深,这个时候对这些功能的描述就会越来越清晰明了,可能会对项目的进度产生致命的影响,非常影响项目开发进度。

建议:

1.项目前期对项目所使用的框架仔细分析,分析不仅仅是看这个框架是否跑的通,最好能叫上测试对所选择的框架进行功能和性能方面的测试,不盲目下结论。

2.PM布局,不单单完成手头上的工作,而应该思考下一两步,两三步,甚至四五步的棋会怎么样走。有了这样的思考,才有可能对开展的工作有针对性地思考。

 

 

问题:

对项目组而言,没有把“需求”和“Bug”区分清楚,用解决Bug的思维来应对需求变更,任务缺乏优先级,加班难以避免。

建议:

1.培养团队对问题的考虑深度,不单单盯在某一个问题上,而要放在全局,考虑到自己的工作对整个项目的影响,对其他人的影响。

2.加强对现场人员的培训,收集需求不是传声筒,对客户的需求,要有正式的记录,时间紧,客户说了马上就要,不是理由。坚决通过Q_List的方式来沟通。

 

问题:

在系统全面铺开后,临时对应现场的问题,出现了更多的Bug,通过加班,花了巨大的人力在开发上应对,在这件事情上我们缺乏一套有效的应急机制。

建议:

如果我们在出现问题的时候,在第一时间,只要一个人或者少数人就能够对现场的问题进行应对,能在完成之后进行自动化测试,有了这种机制能在出现紧急状况的情况下,由少数的人就能完成大量的工作。


我只是描述了自己的一些感受,每个人的心中都有一个自己的哈姆雷特。