如何与多方沟通项目问题

项目进度异常情况下，我们怎么进行多方的沟通呢？组间配合，沟通大都是为了双赢的结果，把问题解决。但有因为大家的立场不同，比较容易出现忘记原本目的，在沟通过程中出现争执或拍脑袋的现象。这篇文章都是干货，是实打实的经验总结，每一位测试工程师都应该看看。

下面是小编的一点经验总结。

以一次实际的项目进度沟通为例：

项目背景：PY7.5项目预期上线时间为下周三，但是在本周五下午的时候发现还有好几件事情未解决：

现有问题

PY7.4.1代码合并导致若干崩溃问题

GDI和内存的泄露问题

生僻字支持和自造字支持最终实现方案

静态变量修改问题

加密问题

bug修改

测试这边觉得项目在预期时间上线风险很大，需要跟产品和开发同步现有的项目情况，以及商讨解决方案.

参与人员：项目经理、开发人员、产品经理、测试人员

沟通过程：

【沟通开始】测试与项目经理、产品和开发说明了当前哪些问题影响了项目进度。

【沟通过程】

项目经理：“测试同学，你们需要我们提供什么信息。”

测试：“生僻字支持的功能需要产品给出最终的方案；其余事情需要开发给出测试解决的时间点，这样才能给出测试排期，以及上线计划。开发同学也是着急，经过短暂思考，回复说：下周一这些事情全能完成。我们听了之后，感觉这个回答并没有经过认真考虑，于是跟开发同学解释了我们的目的，我们不是来催他们给时间点的，我们是为了根据他们的时间点，评估项目最终完成的时间，以及上线风险。”

之后，产品同学：“要以项目质量为先，先不考虑之前预定的上线时间点。”

开发同学听了之后说：“那就是上线时间不重要了。”

产品同学解释说：“不是上线时间不重要，而是我们在保证质量的同时，尽可能保证上线时间。”

之后另一位产品同学：“为什么生僻字支持这个功能测试介入这么晚呢？”

测试作了解释：“本身开发提测比较晚，之前排期计划跟产品和开发人员都是已经核对过的，他们也是认可的。”

产品：“这样吧，我们不再一定要求必须在哪天哪天上线，现由开发人员给出我们问题能够解决的时间点，再由测试人员预估测试完成的时间，评估出一个实际可靠的上线时间。”

最后，开发同学也表示回去跟各负责人沟通，下班前邮件公示以上问题的预期能够解决的时间点。

这样这次沟通基本达到了目的。

根据以上的实例，我们总结一下如何做好项目进度沟通

什么情况需要进行项目沟通呢，场合比较多，比如项目进度异常，不符合预期，需要与开发和产品进行当面沟通，跟其他方同步项目信息，商讨解决方案。这些都需要去沟通了。

一、沟通前准备

【信息同步】组内就要沟通的事情，进行信息同步，把要沟通的事情先罗列出来。

列举出当前影响项目进度的问题list，并分出优先级

举例：PY7.5进度不符合预期,主要是以下几件事情还未解决：

现有问题	预计解决时间
PY7.4.1代码合并导致若干崩溃问题
GDI和内存的泄露问题
生僻字支持和自造字支持最终实现方案
静态变量修改问题
加密问题
bug修改

以上面的表格为例, 生僻字支持和自造字支持最终实现方案这件事情需要对应的产品同学给出一个最终的方案，之后需要开发同学给出开发完成的时间；其余的事情需要开发同学给出修改完毕的时间。这样我们根据对方给出的排期才能安排测试的排期。

【确认时间】和要沟通的人员，确认沟通时间。

【明确目的】正式沟通开始前先告知对方我们本次沟通的目的和需要沟通几件事情。说明目的是为了让对方了解当前项目情况，以及项目存在哪些问题， 以便大家共同商讨解决方案，而不是为了追责，也不是为了能够在预期时间上线而给对方过大压力。

 

二、沟通过程中

站在对方的角度和立场，理解对方的想法，及时聚类和确认自己理解的正确性，对方着急，情绪激动    对方没有考虑清楚，给出有风险答案。

下面总结了一些沟通中的注意事项：

【Delay提议应该由产品给出】当前进度不符合预期，而且很有可能会delay（双方都明白按预定时间上线基本不可能），当大家在商榷解决方案的时候，测试人员不应该主动提出项目delay的提议，这个决定必须由产品人员负责。虽然大家可能都明白项目最终会delay，但是不应该由测试人员提出，这不在测试人员的职责之内。

【沟通过程要有同理心】 在沟通过程中有时候容易给对方造成压力，人在压力大的情况下，容易做出不理智的回应，因此沟通过程要照顾对方感受，当对方给出不理智回应的时候，我们要有辨别的能力；同时跟对方强调我们沟通的目的；同样对对方的话，让我们有压力的时候，我们要对经过仔细考虑才能给出结论，切勿拍脑袋。

举例：PY7.5项目进度沟通过程中，测试人员列举了影响项目进度的问题，大部分都是需要开发人员来给出解决时间点的，这时候开发人员可能很有压力（而且大家都是为了项目才有这么大的压力），当即就下了结论：我们下周一下班前问题全解决。但是当天是周五下午六点左右，而且根据上面列举的问题list，基本可以判断开发人员给出的结论并不可靠，是没有经过心平气和思考而给出的结论，这时候我们要强调我们沟通目的，我们不是来逼对方给时间点的，是希望他们在冷静考虑之后，给出合理的估期，这样方便我们预估项目最后的上线时间，以及上线风险评估。所以测试要让开发理解自己的目的，而不能给开发施加压力。

【长尾需求的处理】有些某个需求成为了项目的长尾，产品人员会质疑测试人员为什么介入这么晚，面对这个问题，我们应该明确表达之前我们排期计划是与产品和开发同学沟通过的。

【沟通误差】有时候沟通过程中有些话会引起对方的误解，或者说容易出现理解偏差，这时候我们应该进一步解释清楚，避免出现理解误差。

举例：针对PY7.5存在的问题，产品表态要以项目质量为主，不要以之前的预期完成时间作为标准，有时候理解有误，以为产品的意思是上线时间不重要了，其实产品同学的意思的在上线时间和项目质量两者之间，我们选择以质量为主，但是不代表上线时间不重要，我们要在保证质量的同时，尽快上线。

【测试主动解决项目问题】在沟通过程中，我们不能只要对方去解决问题，我们也要从自己的角度，去思考有哪些可以改善的地方，共同去解决问题。例如我们人员怎么分配可以最大程度为项目节约时间，以及开发同学解决问题我们可以做哪些配合。

三、沟通结束后

整个沟通结束后，如果有必要可以把沟通结论公示一下，以作备忘，同时作为测试也要对本次沟通有所总结，为下一次沟通做准备。