如果做好测试PM【转载】
本文来源于：https://yq.aliyun.com/articles/14578?spm=5176.100238.yqhn2.14.Lcie4Y
摘要今年整体带了几个项目。我本人不是专业的PMP培训出身，落文的目的主要是为了把所积累的一点点经验分享给大家，所以项目管理的术语和措辞上的不专业，希望大家谅解。 其中一个项目落地非常快，质量和效果产生也非常快的一个项目，落地到产生效果就一个月，所有项目成员都不是全职做这个项目，受到研究...
今年整体带了几个项目。我本人不是专业的PMP培训出身，落文的目的主要是为了把所积累的一点点经验分享给大家，所以项目管理的术语和措辞上的不专业，希望大家谅解。
其中一个项目落地非常快，质量和效果产生也非常快的一个项目，落地到产生效果就一个月，所有项目成员都不是全职做这个项目，受到研究员高度认可并取得对应成果的项目。
另一个项目历经小半年，横跨多个部门，最终取得了所有主链路全部达到秒开的水平，并被开发部申请了技术部牛气冲天奖的项目。
第三个是无线测试发声最多，体现最专业的一个项目，在项目的整体流程推进上，风险把控上，需求控制上，测试方都付出了不少的努力，运营和PD方纷纷回复邮件给测试团队点赞。
下面我就从自身的角度来讲讲我带项目考虑的几个方面：
一、整体规划
1.1需求管理
整体规划里，我比较关注的是需求列表和时间节点2个部分，首先将需求分类，大致分为强风险性需求、强需求性需求、普通需求、可删减性需求几个部分，如果非要划一个优先级，按照我的理念我会关注强需求性需求>强风险性需求>普通需求>可删减性需求。强需求性需求这种需求可能是导致本次版本更新的核心诉求，这种需求资源优先保证，所有风险性问题优先考虑，保证强需求性需求能够上线，这里不考虑强需求性需求不满足时间排期的情况。然后是强风险性需求，这种需求需要提前去沟通了解风险点，并且提前准备好备案，强风险性需求面临着可能多部门合作，进度问题，或者技术难点问题，时间问题等，分析出强风险性需求的瓶颈点，线下单独沟通，并准备好预案，如果该类需求在最后的节点仍然不能够达到我所期望的目标，那么因为我已及时沟通到各合作方，各合作方也有心里的预期和准备就更好容易处理一些，可删减性需求，这类需求可以按照当前的计划，时间，资源等条件因素选择性的提取，如果资源等情况充沛和全部接过来，否则最好在立项阶段就要对需求进行合理删减，不要出现当初承诺完成需求，在项目快结束时才周知相关利益人此需求无法完成的情况，这点对于其他人来讲是相当的讨厌的。
1.2时间节点
关注时间节点的原因是，当前阿里的大部分项目都是倒推的，每一个部分在什么时间完成都是有时间标准并且是可衡量的，例如需求沟通，PRD产出，视觉&交互的产出，开发开始时间与结束时间，项目提测时间，项目测试完成时间，项目灰度时间，项目小渠道发布时间，项目全渠道发布时间，在一个项目里，大部分的时间节点，在项目开始计划的时候就已经产出了，作为PM需要管理时间节点的风险，要经常和主要的责任人沟通相关项目的进度，不紧张的时候各合作方发周报通报内容，紧张的时候各合作方发日报通报内容，甚至当前沟通，建立项目的多种沟通方式，例如项目1推进每周一次的碰头会议，邮件组，旺旺群，钉钉，周报，日报等。PM不能想着到时间节点就要东西就好了，这不是一个好的PM，一个合格的PM应该时刻的关注每个节点的进度，质量，风险等情况，尤其是快到接近每个节点产出的时候，如果时间上发现已经delay，那么应该和相关的业务方沟通提高进度产出，加班等手段，把节点的产出和敏捷项目的管理相配合，这样就可以尽量保证每个时间节点都达到项目计划的规划目标。
二、沟通
2.1 人与人的沟通
人与人的沟通就是P2P，单点对单点，这种沟通的内容一定是该内容仅涉猎你们2个人的，例如某一个问题一直挂在某一个人上长期没有解决掉，作为PM要了解情况进行沟通，沟通的时候多从对方角度考虑问题，多从共赢的角度上考虑问题，不能说你作为PM你有这个权利怎么怎么样，这种沟通一般都对在对方心里产生抵制的效果，了解到可能是因为该责任人被安排了其他任务，还是说这个问题有难度不好解决，还是说人家准备要离职了，把影响项目进度的节点问题解决掉，沟通时可以先采取先邮件沟通，再旺旺沟通，最后当面沟通的方式，一般的阿里人到达第二步旺旺沟通的层次基本都会有响应了，如果旺旺都不行，那你一定要当面去沟通，不要怕，有的PM就不知道如何当面进行沟通，当面沟通预约好时间，不要先入为主，先把问题提出来，看看对方怎么说，然后你根据了解的情况再去有策略性的推进这个事情，前几步也都没有，直接当面质问，这个问题怎么还不解决，这个时候我都想骂他，我手里有更重要的事情好不好，你过来嘚瑟个屁来着。当然如果这个事情非常非常紧急，P1故障，那直接去找好了，这种问题没什么顾忌其他人感受的了，影响到我们的线上用户那是一等一的大事，还要什么面子。
2.2 合作方的沟通
与合作方的沟通，一定要让对方的leader知道并了解支持此事，这一点尤为重要，即使对方leader没有时间，那么也需要在旺旺或者邮件内抄送一下，避免最后因为各种理由，这个项目支持到中间半途而废了，再临时叫老大的老大的老大从上到下来压这件事情，按照我的话来说，就是这事办的不够漂亮了。对方老大知晓同意这件事，那么需要拟定合作方需要沟通的接口人，对方的团队毕竟是对方更熟悉，也更能说的上话，你在人家团队里，碧池碧池的说100句，可能不如人家在内部团队里嘻嘻哈哈的一句话，项目合作推进的事情一定要交付给接口人做，你作为PM不能把合作方团队也一并管理了，再说，真正项目做起来后，你也没有那份时间和精力的，定好接口人，这个接口人一定能把有效的信息传达到团队内，并落地执行，这样的接口人才是有效的，不要随便指定一个，哦，张三，你是接口人，结果张三自己在团队里什么都落实不掉，最后你说是张三的责任，还是你的责任，你俩都有责任，但最主要的可能还是你的责任，知人善任，作为PM，运营团队、PD团队、开发团队、测试团队，哪个团队都有哪些人非常适合做PM接口人，或者自己团队的PM，你至少平时工作中要多和合作团队了解，即使你不了解的团队，也最好侧面打听打听，要人的时候直接要指定的负责人，那办事效率杠杠的，沟通起来相当的丝滑，再提醒一点，与合作方的沟通一定要有礼有理有句有据，意思是一定要有礼貌要尊敬人家尊重人家的意见，你说的话一定要有道理，有理由能站得注脚，能经得起推敲，有句你说的话一定要清晰易懂有逻辑有重点，有据你说话一定要有根据，有事实，有数据，让合作方得知道你这个人要办的事情靠谱，人家才会非常愿意和你合作干项目，要不然背后说不定指着你脊梁骨骂，靠，什么鸟人，这个项目一点前景都看不到。
2.3 自己团队的沟通
自己的团队就是亲人，是最亲最亲的人，能自己上的，都不会让自己团队的人顶，所以项目的任何风险或者进度情况等对自己的团队就是实话实说，提前帮自己的团队多考虑一些事情，善意的提醒他们一些注意的事情，关键的节点等等，今天可能你是PM，明天可能就是别人就是PM，能把自己的经验传递给大家的就share给大家，多从团队方面考虑问题，也需要帮助其他人从团队的角度考虑所有事情，而不是个人角度，因为不管是项目，还是任务，没有任何一件事是属于指定的某个人的，你可以任何时候离职撂挑子不管，所以不管是自己团队还是别人团队，大家一起能参与这件事，一起做这个项目，你心里就要报有感激的心态，多去赞美别人，即使别人做错了，做的不好，也要懂得如何婉转的提醒给他，让他有面子的同时达到项目的目的，也许就是我的做人之道吧。每个人管理项目的手段都是不同的，人的不同就会导致风格的不同。
三、专业
什么是专业，就是把自己份内的事情做到极致，我认为这就是专业，一个PD需求写不好，一个运营页面都不会搭建，一个测试连Bug都不会跟踪不会提，这可能都是不专业的体现。在项目中，你是PM，或者你是其他角色都必须要做到够专业，测试的PM就要整体把控测试的进度，提测时间点，业务的风险点，测试完成时间，业务上线时间，把该暴漏的问题要尽早的暴露出来，很多测试PM总是怕得罪人，问题暴露出来了，这个问题是某某个团队的，某某个人的，人家会不会觉得我事多，记恨我，以后是不是合作上就有问题了，其实我觉得如果这个问题藏着掖着上线了，最后被爆出个P1\P2故障出来，我想人家更会记恨你，提前发的预警信息，风险邮件，加班邮件如果能把问题暴露出来，大家都应该感谢你的，测试PM都是从整个项目的质量上来考虑整个项目的，大家应该都能理解，你是测试PM，你要对这些事情负责，项目的周报定时的发送，让整个大促合作方都知晓测试的进度，项目时间紧时，要把风险性的问题及时发送邮件或者旺旺消息，让大促的总PM知晓，不暴露出来解决掉问题，就意味着时间不够用，要带bug上线，这种事情是必须全部周知才可以，否则凭什么你让业务带问题上线，是我，我这东北人的性情我就不爽。
专业的人做专业的事情，PM同学管理好项目的人与人的关系，业务的进度，风险，时间点等等，消息传达和沟通要尽量协调好，做一件事情要多考虑一分钟，想想是不是遗漏了什么，让大家都觉得很顺，很爽，下次做项目还愿意跟着你干，这不仅仅是项目的成功，也是你的成功，每个人身上都被其他人贴上了不同的标签，而你自己就是你的品牌。
四、回馈
什么是回馈，按照我的想法，就是付出就必然有回报，虽然大家做项目不是给你做的，说白了你也是给公司做的，那么作为PM这件事情的带头人，你有理由，有责任给与参与项目的人给予感谢，请大家吃个饭，来个下午茶，为大家申请加班倒休，为大家申请酒店住宿等加班条件，这都是PM需要考虑的事情，我又想抱怨一下，看过很多项目，做完了就做完了，作为PM连封感谢的邮件都没有，心里真是不爽啊，中国这个社会还是一个人际关系的社会，认识你喜欢你的，你没说话，事就给你办了，不认识你的不鸟的你，你天天求着人家，人家都不愿意给你办事，这事情就是这么个事情，我觉得非常简单，但是还是发现有很多人不是很明白这个道理，一定要多赞美人家，不要害臊，当面赞美，例如：这个模块，做的很牛，Bug非常少。给与开发同学实力上的肯定。这个需求写的非常清晰，我一看就懂了，多谢多谢，给与PD赞美，人家从内心上肯定你，后面还会坚持这么做，否则，今天我写的很好你不吱声，明天我写的不好你也不吱声，好，那下次我不写了，省事谁不会呢？
这个回馈方式有很多种，有大有小，你要变通着来，这样大家才原因跟着你干这个项目吧，否则要是我，我都觉得这个PM脑子是木头的....
总结：最后我想说，其实我嘚吧嘚吧这么多，也没有把自己所有的体验全嘚吧出来，也没有把项目的整体流程啊，目标啊什么的给大家说一遍，那是因为我觉得处在什么环境下，哪个所谓的流程啊，目标啊，标准啊什么的，都不是一成不变的，作为PM要考虑当前的环境，以前项目的方式等等因素和大家好好配合，有句话怎么说来着，树是死的人是活的，我觉得作为PM能够变通着做事情，让各位尽可能的满意，对项目满意，对你满意，对结果满意，又达到了项目的目标就“齐活”了。
