《给产品经理讲技术》读书笔记（九）

前面给大家留下了一个问题：程序员对需求文档不满意怎么办？其实我们应该分析其中的原因，然后找到解决的办法。

需求文档中的“优先级”选项也是令程序员很头疼的，优先级分为 高、中、低三个选项，大多数产品经理会说，高优先级必须上线，中低优先级也是需要做的。那还分什么优先级呢？或者说中低选做，这种模棱两可的感觉还不如抽象成做或者不做。

当然，这需要产品经理提升能力，能够清晰地评估出一个版本能否涵盖这么多的内容，其实程序员根本不需要这种文字式的需求告白书，这种文档应该是产品经理脑中的思路，而不应该被描述成文字交出来。程序员需要的是一份大家都认可的清晰的交互图，其关键位置需要有一些边界条件的说明。这份交互图不一定非要用专业的原型工具输出，一张草纸加铅笔描述清晰即可。

作者认为由产品经理和程序员一起讨论功能的关键路径，并一起确定每一个流程，然后简单地画出草稿，才是效率最高的方式，并且可以少开很多会议。若仅一个人想好了就发起评审，结果往往是需求被改得面目全非，不如大家在初期就一起讨论得出结论。

当然，程序员是很高傲的，产品经理没叫他参与讨论时，他会抱怨：“什么都不叫我，乱决策，现在一团糟，根本实现不了。”产品经理叫他的时候，他又会说：“整天跟产品经理在一起讨论问题，技术上都没有长进，没有积累。”或者抱怨说：“白天跟产品经理讨论，只有晚上加班才能写点代码，筋疲力尽，还总被批评效率不高。”

程序员大多认为自己有些武功，所以跟不同的程序员交流要用不同的方法，例如多请他们吃饭。从另一个角度看，所谓能力越大，责任越大，明白的程序员与产品经理早就想明白了，他们每天工作不是为他的老板，而是为自己，无论在哪里干，都当是创业。

精益（mvp）的作用是最小成本验证可行性，把所有资源投入到最大可能的方向。直播兴起的时候，是应该以产品上线为首要目的的，不应该过多地考虑带宽不够怎么办、用户激增到500万怎么办，或者播放质量不够高怎么办等问题。

道理很简单，做到却不容易，希望产品经理明确地知道当前目标，而不是抱着“既要……也要……还要……”的想法应对一个验证过程。目标明确，只突出一个点，能促使自己与程序员和设计师更快地达成一致。

关于沟通的内容就先介绍到这里了，下篇文章给大家做一个简单的总结：你只是在为自己工作。什么意思呢？赶紧去看看吧！

以上就是“《给产品经理讲技术》读书笔记（九）”的内容了，如果你还想了解其他相关内容，可以来 产品壹佰 官方网站。