很矛盾，鼓励反馈也能产生风险
之前谈到反馈，其实反馈也是项目风险来源之一，和技术风险一起需要项目管理人员及时发现和管理。假设我们已经通过合理的迭代计划（上篇日记记述）找到了鼓励有效反馈和发现记述风险的平衡，而技术风险可以由计划常规的技术风险规避工作量以及Tech Lead配置,对于反馈产生的风险我们如何控制？
用最简单的话说，软件开发最核心三个不同层次的要求是：做可用的软件，做对的可用软件，做对的好用的可用软件。然后考虑任何软件开发必然是一种商业投资，对于每个层次客户都在计算投入产出比：
- 质量控制：有多少缺陷，有多少性能问题，有多少架构问题；
- 需求验收：有多少不是需求所要求的，有多少不满足需求；
- 可用性测试：软件学习时间有多长，有多少误操作的情况，有多少可用性缺陷等等。
可以想想，在每个层次上，当客户发现一个问题，都会记录在某处，每一个问题有些是有效的改进反馈，有些则可能成为潜在的风险。而这些可能存在的潜在风险若聚合在一起又不加控制，最后积少成多累计为对项目延期甚至取消的巨大风险。
与传统瀑布式软件开发项目不同的是，敏捷开发对于过程的完全透明化，对于细节的明晰化，以及阶段性对交付物的展示，这使得客户在软件过程中发现的问题远多于瀑布式开发。这也是为什么瀑布式开发必须在进入开发前经历一个冗长的设计和文档准备期——客户需要把因为开发过程不透明而潜在风险确定在开发阶段之前。
我们放弃了整体设计和复杂文档，选择把开发过程公开以及和业务人员一起参与，我们就要接受在这个过程中激增的客户反馈（没有文档和流程验收，客户很难有安全感）而产生的之于我们的各种风险。换句话说，没有客户参与的项目是没有风险的，风险永远只有一个，项目成功交付或者不。
逻辑是，敏捷流程持续向客户输出交付物（不管是什么），输出交付物的目的是希望得到反馈，反馈必有承认和要求，而要求型的反馈必要需要工作量，额外的工作量（免费）就产生交付风险，但是“承认”型的反馈是不要额外工作量了，甚至能够降低交付风险。
那么，很多团队控制风险的手段就是致力于得到更多“承认”型反馈较少“要求”型反馈，当然在理论上来说，这是无可厚非的——通过更好的需求澄清工作，更优秀的设计和高质量的代码，让客户满意。
但是问题的关键是，很多团队的做法是——“隐藏那种可能产生要求型的反馈！只向或倾向于向客户展示可能产生承认型的反馈”，那么在一段时间里面，因为没有额外需要改进的东西，风险自然被降低，同时团队和客户其乐融融。这种“倾向于隐藏坏消息”的做法，最终只能导致真正的风险没有被引起重视。而过多展示好消息也能带来另外一种因为过高期待带来的风险——既然你一直都做得那么好，Velocity再挑战一下！
事实上控制风险的实质（官方版本）：展示风险，并和客户一起担当！背地邪＊恶（evil就是不和谐）版是：展示风险，让客户同意为避免风险投入。
那么我们如何控制风险？
第一步分析反馈。之前谈到软件的三个要求“对的软件”、“可用的软件”和“好用的软件”，客户对于软件的要求型反馈也不外乎对这三个方面的抱怨。当反馈产生的时候，我们需要首先跟客户讨论被反馈的功能本身：是不是不对？是不是可用？是不是好用？然后思考，这种反馈：是不是在反馈“它”（在不在范围里），如果就是在反馈“它”，那么是不是“它根本不对”？然后是不是在反馈“它目标是对的但是不可用”？然后是不是在反馈“它可用，也对，但是不够好用”。
分析反馈之后，我们已经知道，反馈到底属一类，对其采取行动。每一类我们要考虑的东西可能有所不同：
根本不在范围里型：这种实际上是最多的要求，客户往往没有范围的意识，就算你已经细心拆分用户故事，小诀窍是把用户故事多写几个字，如果你把“打印客户清单”作为用户故事的标题，但是只支持基本页面打印功能，客户很容易在看到Showcase时候问他是不是可以支持选择不同模版打印，如果你在标题后面加几个字，比如括号“（基本页面打印）”，至少他要求的时候会有足够的罪恶感，如果你能早想到他会要求这个，在Backlog中记下这张卡，便更好（之前谈到的Scope不在AC里，而是Backlog之外的所有）；
根本不对型：这种往往由于需求澄清引起，面临变更需求和代码返工，应该说这是我们不能出现的错误，但是也不排出客户确认周期长或者不负责任的验收需求文档。那么处理这种风险的方法是尽量使交付团队付出的额外工作量尽量少，因为客户有时会过于感情化地全盘否定仔细与客户分析这个“做得不对”的需求，找到已经实现，但是有可取之处的地方；
不可用型：对待这种类型的反馈的方法是分清楚什么是真的不可用，比如缺陷和故障，必须义不容辞的修改；什么是假的不可用，实际是不好用。对于真不可用，勇敢拍胸脯改正，对于假不可用，使用“不好用型反馈”的策略；
不好用型：这也是另外一个风险的高发来源，对于用户体验上的问题需要采取的策略是尽量让客户对大工作量的UI改进埋单，方法其实还是把大工作量的UI改进单独拆出放在Backlog中，切勿让客户认为这样的改进是免费；
除了因为客户反馈产生的潜在额外“免费”工作量而引起的风险之外，还有一种风险是客户无法发现的——技术风险，关于技术风险的规避在前一篇日记种提及，这里不赘述。
敏捷开发中我们鼓励客户提出反馈，但有时这种反馈变成了一种overused的权力（这里有个敏感词），对于反馈中客户臆想的免费的改进，我们需要理性地进行疏导，不能盲目接受，也不能武断拒绝。作为业务分析师应该认真分析反馈的实质，努力使客户跟交付团队一起为这个改进造成的工作量消耗负责。决不能因为害怕这样的反馈，而隐藏“坏消息”，不能及时发现和解决的风险所产生的后果，随时间级数增长，最后可能变成导致项目失败的关键因素。