作者：troy

最近有一个朋友求助，其管理的一个项目在验收的时候出现问题，连续验收两次都被客户拒绝，向我求助帮忙，并且将项目资料以及已完成的地址统统发给我，让我分析并且找出问题所在。当我看完后，我内心其实是崩溃的，因为这个项目在我看来，完成度6成都达不到，不单还存在着链接报错的硬问题，而且页面很不完整，更不要提界面设计的友好性。而当我把这些问题提出摆在朋友面前时，我明显看得出，他在整个项目进行过程中对项目根本没有规划，仅仅将与客户确定的需求书扔给技术团队就撒手不管了。

其实这并不是一个单独的案例，因为很多项目经理都是这么做的——将客户需求甩给技术部门，然后就不再过问，直到项目完结前找技术部门要进度。这样的项目可想而知最终呈现出来的会是什么样的作品，除非运气好，技术部有一个经验丰富或者具有强迫症的技术人员来完成，不然，最终结果就是失控。很多时候，这个最终的黑锅都被技术部门默默的承担了，而始作俑者往往一脸无辜的面对客户和公司。

在看完项目后，我对这个朋友说，放弃验收吧，想办法找客户协调一个月的时间，你需要补补课了。对着近乎抓狂的朋友，我跟他详细讲了在项目中，项目经理是应该承担什么样的指责

沟通的发起者和需求的终结者

作为开发项目来说，项目经理将是在理念中最接近客户的人，因为客户的想法都要通过项目经理形成解决方案，随后要将这些需求转化为技术人员能够听得懂的语言传达给技术。这里并不是说贬低技术人员的理解能力，但是更多时候，客户或者需求说明中提到的效果往往只是一个概念，落实到具体效果压根不会提及，因此，这时候就需要项目经理，根据自己对于需求的理解，将每一步的细节将给技术人员听。而这一系列都要建立在详细不断的沟通上，这就是众多项目经理所犯的一个错误——忽略开发过程中的沟通。导致项目最终呈现效果与需求大相径庭。所以项目经理要与客户、与技术经理频繁的沟通，哪怕一点点细节。

其次，项目经理的另一项指责就是需求的终结者。熟悉开发的人直到，任何一个功能都有着近乎于无限的延伸。举个例子：一个普通的新闻发布的功能，乍一看似乎很简单，很多时候功能需求上都会直接写新闻发布功能，但是大家没有注意到，新闻发布功能后面有可能的延伸——新闻分类管理、新闻权限管理、评论发布、评论管理、分享、新闻排版管理、模版库等等。而这些细节都是在最初洽谈需求时候可能根本没有留意到的，这在项目进行过程中，就会因为客户的某一个想法而出现需求的变动，这时候就需要项目经理来出面进行判断和干预，确定最终效果应该是什么样子，什么功能超出了最初预期，而什么功能是需要进行完善。

说完这些，我跟朋友讲，你需要反思了，反思自己在这个项目开始过程中真的了解客户想要什么？花了多少精力用于与技术开发人员的沟通上？在后续客户提出的要求中，有没有区分客户要求是否合理？这些问题反思后至少目前出现的90%的问题都会解决。而剩下的10%则是最终决定项目走向的关键。

项目经理的质量标准

如果说90%的问题会在项目经理的不知疲倦的沟通上解决，那么最后的10%则是考验一个人的性格了。到底项目做到什么程度才算合格？我经常跟大家讲，只有强迫症的人才能成为一个合格的项目经理，为什么？因为他会极度的注重细节，不能接受任何一点点的问题遗留在最终的成品中。很多时候项目经理缺乏魄力，当遇到技术的质疑和客户的要求时，更多的时候在妥协，这种妥协造成的结果就是项目经理成为了传话工具，在项目验收评估过程中，管理缺失。

我跟公司很多项目经理说过，谁管理项目就要成为技术过不去的一道坎。如果一个项目经理自己对于项目质量标准没有要求，那么这一定是一个不合格的项目。项目经理的质量要求将决定项目最终达到的高度。因此，在我接手项目时，可能页面上一个多余的像素点我都要求技术修改，久而久之技术部整体的技术质量都随之提高。作为项目经理，如果我们的质量要求标准低于了客户要求，那么项目一定不会在验收过程中顺利过关，只要超出客户预期才能够获得认可。

客户可以对设计风格不满意，可以对功能流程不满，但是绝对不能让客户因为项目实施质量不高而不满，这是作为一个项目经理最根本的要求。

欢迎大家关注我们的官方微信，了解更多信息。

（原创文章，未经允许，禁止转载）