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

岗位：

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

 

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

 

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

 

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

 

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

 

心得：

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

 

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

 

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

 

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

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

 

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

 

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

 

问题及建议：

问题：

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

建议：

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

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

 

 

问题：

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

建议：

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

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

 

问题：

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

建议：

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

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

来自：http://blog.csdn.net/mhfcr/article/details/18701907