作为PM怎么沟通 pm是什么意思( 三 ) _小知识

还是用注册的例子，比如我们想表达注册时须要校验邮箱的有效性。初级PM的描写可能就是“注册时须要校验邮箱有效性，有效则……无效则……” 。
这里的逻辑本身没有什么问题，但是这里有两个很显著的细节问题：
我知道很多PM都认为，“这都很基本啊，光标移出输入框校验不是很通用的交互逻辑吗？邮箱的有效性应当是业内的基本常识了，我为什么还要糟蹋时光去解释具体的校验规矩呢？”
可是当我们站在开发的角度，就会发明自己的懂得变得完整不一样了：

所有的行动都有触发条件：“注册时校验”——那我应当只用在点击注册按钮的时候校验了。不是每个开发都有UE经验，PM想当然的交互逻辑一般都实现得有偏差。
所有的断定都有一套运转规矩：“邮箱有效性”——那我是须要调第三方邮件服务确认邮箱真实资源网存在，还是只用断定邮箱格局（@和.）?

回过火来看，这次的沟通是不是很低效呢？
有预期不一致功效细节，还有须要二次确认的实现方法。当然，辩证地看这个例子，我们的PRD是不是须要面面俱到，事无巨细都提到呢？当然不是。
就像前面提的，每个公司，每个团队都是不一样的，我们的重点是站在开发的角度对待需求。
如果是合作多年的团队，特殊是核心组员没有变更过的团队，或则项目组内部对交互组件和常见的功效逻辑已经有了规范的情形下，都是没必要长篇累牍地描写的。
记住了PRD的重点始终是高效沟通，而不是刻意雕琢细节。
2.2.1.2 需求开发
幻想状况下，在需求开发的进程中，PM是不应当频繁地和开发同窗沟通的。因为信息传递的工作已经在前一个步骤完成，这个阶段PM只需在提测时确认自己的需求是否被完整实现。
然而幻想情形究竟是少数，比如参与需求评审的技巧一般不直接参与需求开发，所以PM在这个阶段也会遇到给不同的接收者重复沟通的情形。
当然我们的沟通目标仍然没有任何变更，但是沟通的情势值得我们注意。因为和一线开发同窗沟通时，往往不像需求评审那么正式。
所以我们要做到：所有的重点沟通都可追溯，这个时候就请求我们选择一个可靠的沟通媒介。口头交换的确更为便利，但是每次沟通停止后，通过即时聊天工具或则邮件通知对方二次确认是一个更好的选择。
2.2.1.3 紧迫需求
没有人会爱好紧迫需求，大家都更愿意做有预备的事情。
但是商业环境往往不许可我们的产品完整依照筹划迭代，所以PM必定要拥抱变更。对于紧迫情形得有自己的沟通套路，而不是单纯的转达命令。记住，所有的沟通都是有目标的，而不是单纯的转达信息。
“这个需求是老板要做的”、“这个功效是大客户加急要的”、“临时加个班，明天上线这个新功效”……
没有人会爱好这样的沟通方法，这种情形下开发的行为意愿只起源于工作职能的强迫请求，吸收者并没有真正地发生主观行为意愿。这样的沟通必定是不顺畅，而且低效的，也难怪大家都会讨厌紧迫需求了。
这个时候PM须要应用自己的同理心，扩大传递信息的维度，不要因为时光紧迫就只说功效。产品的愿景和价值对开发也是一种鼓励，而且可以更好的确保开发同窗懂得需求，转换为更为妥当的行为。
当然如果连你自己也不清晰这个紧迫需求的目标，那么所有后续的沟通中你都无法保证真实的目标是否达成，因为你只是沟通讯息流中的媒介，不是发起者。
2.2.2 日常问题
2.2.2.1 线上Bug
产品自身是无法解决bug的，所以及时和开发沟通，帮助开发解决bug才是我们的重点。这种特别场景下，我们须要格外注意信息传递的质量。
2.2.2.1.1 进步信息本身的质量：PM须要精确地描写如何复现bug，以及bug的影响规模和优先级。
很多PM会疏忽bug的影响规模，但这个条件往往决议了我们如何判定bug的优先级。而且如果产品能给出精确的影响规模而不是简略的“highest”描写，也更能让开发同窗意识到自己面临的是什么样的服务压力，时光的紧急感会更强烈。
注意并不是所有的bug都是最高优先级，有些bug影响规模非常有限，而且须要占用极大的开发资源来修复，这个时候PM须要站在更高的角度对待这个问题，在沟通前有取舍的做前置断定。
2.2.2.1.2 选择适合的传递媒介：不要留言、不要留言、不要留言。
对于已经判定为高优先级的bug，必定要确保吸收者及时地收到信息。能够当面沟通，就不要用即时聊天工具。同样的信息用不同的媒介转达，吸收者的感知是完整不一样。