需求评审开发玩手机不认真听，开发的时不看文档一直问需求，如何处理这种情况呢？
source link: https://www.pmcaff.com/discuss/3209114150256704?newwindow=1
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
首先从现象分析：
为什么测试、开发不听需求不看文档，看手机？是否很经常出现讲一大堆需求，然后是做好几个月或者一两个月的事情？
1、谁能知道一两个月后的事情？今天干这个项目，明天干另外一个项目，人只能关注近期的
2、这需求永远不变，既然变的话，那现在听不听有区别？
3、都是产品说了算，开发、测试是执行？工具人？如果是，工具人何必有想法，何必听？
这些是开发、测试角度的普遍想法，然后针对上面这些问题，其实敏捷开发理论里面有相对应的措施、做法。
1、分迭代，固定1-2周迭代，每次只说这迭代内的需求，非迭代内的需求，不做讨论！关注当前，搞完当前再搞其他
2、用故事，而不是功能描述来说需求。产品的设计不是最优的方案，作为产品，只需要把控故事、业务就好了，实现方法有很多种，集合开发、测试的专业能力，来完善故事，方案，才是正确方法。其实核心是增强开发、测试的参与度
3、让开发、测试来说需求，而不是产品。为什么需求一定要让产品来说？产品是对业务负责，开发、测试来说，然后产品来判断方案是否合理，然后哪里存在问题，再补充完善。不是挺好的？
4、所有的修改、验收标准，都以文档为准。不以口述为准！这点很关键，以前我那团队就要求这样配合，产品跟某个开发说了，产品必须要修改文档，并在项目管理工具上记录这个修订。测试人员、其他开发人员看到修订记录，就知道这里有变动，变动结果是怎么。不然产品说是做成A，开发理解成B，最后产品过了太久，记错成C，谁的责任？绝对是产品的，不是开发的。但是写到文档上，那就大家都能理解。
用领导压什么的，没啥用的。产品经理，不仅仅只是靠制度，更多是沟通、方法、技巧的问题。自身做不好，能用领导压下来，大家表面笑嘻嘻，背后狂捅你刀子，你能怎样？只会更累。
调教好团队，形成统一做事风格，产品一个想法，团队马上能领悟并更好的设计，完成。会更好。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK