正文
——维基百科
所以，运用一些沟通技巧显得至关重要。只要一件事不是单凭一个人就能完成，你就得考虑如何提高协作效率。而产品经理和程序员的协作中，沟通又是最重要的。
下面展开说说具体可以做的一些事。主要是思路中的2和3。
我观察过一个现象，需求变更比较多的产品经理，他们的工作习惯往往是直接抄起原型工具就画原型，或者有很多工作时间花在原型工具里。
这样非常容易陷入到一个思维惯性里面去，就是过于关注交互层面的事情，而轻视了背后业务流程的设计，甚至是业务的合理性。
我认为产品经理做事的时候一定要以User Story为核心来展开，先构思好一个User Story，然后再把它真实发生的各种细节阐述清楚。
做这件事的过程先后分为以下四步：
-
定义User Story；
-
定义交付标准；
-
提供低保真原型；
-
编写Use Case。
这里面最费时费力的就是第四环节，而且你想把User Story阐述清楚离不开一个专业的 Use Case编写。我之前收藏了一个非常专业的Use Case模版，是从知乎上的张恂老师那看到的，你感受一下。
用例名称：提问
层次：!（用户目标层）
范围：问答网站（以下简称系统）
主用角：注册用户（以下简称用户）
其他干系者：...
后态：
前态：用户已登录。
触发事件：用户选择提问。
基本流：1. 系统显示新建问题框。
输入问题 {
2. 用户输入问题陈述（字数限制？）；系统即时验证输入的有效性，并提示已有答案的类似问题（数量？）以免重复提问。
3. 用户设定该问题的相关话题。
4. 可选项
用户可补充输入问题说明（背景、条件等详细信息）。
5. 可选项
……
6. 用户提交问题。
}
7. 系统验证该问题的有效性。
8. 系统发布该问题，并显示该问题页面。
扩展流：用户放弃提问：...
https://www.zhihu.com/question/48899115/answer/113274323 张恂老师的回答
作为产品经理的你，如果想要减少被程序员吐槽需求不够细，或者降低开发过程中变更需求的频次，把Use Case用心做好是必不可少的。
与程序员的沟通方面，我总结了五动作，分别是
“齐、拉、捧、说、谦”
，可以根据情况组合出击。
在聊需求之前，先交代需求的背景、意义。特别在中途需求变更的时候，这点非常重要。
