今天是如何预防TT的最后一场讨论，也是最热烈的一场，总结如下：
-
用户故事要清晰，一个好的用户故事要能回答下面4个问题：
a. 用户到底要解决什么问题？如果这个没有拿捏清楚，后续付出的所有成本都可能是浪费。这个需要我们的PM能够识别用户给出的是解决方案还是真正的问题。如果是解决方案，要多问用户几个为什么把真正的问题逼出来。
b. 系统对应的解决方案是什么，解决方案包括我们要在系统的哪些页面或哪些后台逻辑做哪些修改，系统逻辑是什么样的，原型是什么样的等等？
c. 对现有系统的影响点有哪些？有哪些功能会受到影响，影响是什么样的？
d. 用户验收测试是什么？功能上线以后，用户会怎么使用系统验证新的功能已经解决了TA的问题。 -
强化PO(Product Owner)的作用和价值，PM明确用户需求后，必须和PO讨论解决方案，按需邀请开发负责人参与讨论。
-
给解决方案做减法，在能够解决用户问题的前提下，我们提供的解决方案需要是简单、清楚和正确的。
a. 简单的：不增加系统的复杂度，影响面小
b. 清楚的：逻辑直白，易于理解，而不是绕来绕去。
c. 正确的：符合系统既有的Domain、功能框架和主业务流程，如果解决方案和主流程不兼容，则把它和主流程隔离开来，作为专门为某一客户定制的流程。 -
允许被DEV说服，BA要鼓励DEV有自己的想法，如果DEV提出的解决方案更好更简单，应当采纳DEV的解决方案。
-
要用产品数据验证自己的假设，比如对空值的处理，要默认空值是可能的，对于值非空的假设需要检查页面和数据库的设置是否都对空值进行了必填校验。
-
用户故事优先级管理，每个PM自行排优先级，1为最高优先级，一般为承诺客户上线或严重影响用户操作的用户故事; 2为能够有效节省开发或支持成本的用户故事; 3为最低优先级，需求Brief时严格按照优先级顺序，除非是特殊情况，每个客户的用户故事点数不能超出配额。
-
主动要求和参加Demo会议，尽早发现潜在的问题，比如UI展示的友好度等问题。
-
积累和记录每个客户的关键操作流程和模式，形成客户操作流程库，作为QA回归测试的依据。
-
学会反向管理客户
a. 解决方案需要和用户书面进行确认，并提醒需求变更会有额外成本，解决方案需要用户在每个迭代开始之前的周三前确认。
b. 合理安排开发和实施计划，避免出现紧急的需求，和客户坦诚沟通我们目前的开发节奏和满负荷开发的现状，取得用户的理解，使用户的预期和我们的开发现状一致。
c. 相信自己比用户更专业，不要全信客户说的每一句话，要独立思考并主动引领客户到正确的方向和解决方案上面。
知易行难，大家总结得相当好，接下来就要依靠每个人的行动、提醒和坚持把每一点都做到做好。
网友评论