作为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，一定要确保接收者及时地收到信息。能够当面沟通，就不要用即时聊天工具。同样的信息用不同的媒介传达，接收者的感知是完全不一样。