阅读笔记《探索需求》3

最后一本书，也是最后一篇阅读笔记了。

  第十章讲的是产生想法的会议，第一点为什么，想法是最重要的，因此对于成功的需求工作者来说，简短的通知后很快就能集中一组人，并且产生一批新的想法是必须的。第二点什么时候，正如我们将要看到的那样，产生想法的会议通常是其他会议的组成部分。只要有两个人都认为他们需要一些想法，就可以随时召开产生想法的会议。第三点怎么做，注意以下的事情：

1.不许批评和责备

2.让想法自由飞翔

3.想法越多越好

4.更改和合成想法

5.产生想法的阶段之后采用一个或多个方法将想法的个数减少到一个可能操作的比例

只要符合前述1~4条基本的原则，你就可以设计你自己的头脑风暴的其他形式。

第四点相关者，产生想法的会议中人越多越好。只要他们愿意按照上述规则进行，更多的人意味着更多的想法。事实上，为了防止想法越来越陈旧单一，每次产生想法的会议都应该请陌生人参加。

  第十一章讲的是右脑方法，第一点为什么，“探索”来源于开发者的处理对象是需求的映射图，而不是需求本身。我们探索是为了制造映射图，而且最终我们制作了一张能够和地形非常接近的“地图”，用以满足实际的目的。可视化的工具常常是通过持续的接近目标来起作用的最好办法。第二点什么时候，我们的工作对象是“地图”，而不是地区本身。因此，我们必须总是有意识的工作来保证对不同的映射图保持相同的理解。第三点怎么做，制作映射图是一个过程，更是一个清楚的交流后得到的意识和许诺。发生交流问题是进入如下过程：

1.不要将所有困难的部分都交给别人来做

2.对可能出现的新方法，尤其是新的记号带来的变化做好准备

3.接受人们之间的差别，不要强迫每一个人都一样

4.记住，当你对符号的细微差别感觉有些恼火的时候，提醒自己“地图”并不等同于实际的地域，世界上并不存在完美的翻译

5.学会画草图，这样新的映射图能够包含足够的信息，而不是太多信息，从而不会暗示并不打算胆大的精确度

第四点相关者，每一个人都会使用映射图，尽管不是每一个都能够轻松应付每种绘制映射图的系统。那些能够轻松掌握映射图系统的人有责任无私的帮助他人熟悉系统。

  第十二章讲的是项目的名称，第一点为什么，名称总会被重复使用，他们容易掌控思想。如果它们被误解或者具有含混性，那么就成为麻烦的起点。第二点什么时候，只要一个新的项目或者子项目开始的时候，或者有任何新的事物需要命名的时候，我们就必须小心的挑选名称，以免造成误解或不明确。第三点怎么做，遵循以下过程：

1.提出一个名称

2.提出三个该名称不合适的原因

3.提出另外一个可以消除这三个问题的名称

4.重复这个命名过程，直到找到一个可用的名称为止

5.不要永远不听的寻找完美的名称，它根本不存在

第四点相关者，命名活动可以由一个人来完成，但是由项目的关键参与者组成的小组面对面的探讨将会取得更好的效果。

  第十三章讲的是面临冲突时的推动进度，第一点为什么，每一个项目都会经历冲突，如果没有某种推动力的话就很难成功消除它。一些项目非常幸运地拥有“业务的”推动者，在需要时能够起到推动者的作用。但是如果你不希望总是依赖幸运，那么就应该发展一个经过专业训练的推动者团队。第二点什么时候，无论适合召开有没有推动者的需求会议都是不明智的做法，因为你无法预测什么时候会爆发紧张对立的情绪。然而，一位好的推动者能够阻止绝大多数无关紧要的冲突，并且能够是其他冲突最小化。第三点怎么做，这一章是为了强调推动工作的重要性，而非教你自己成为以为熟练地推动者。第四点相关者，每一位参与者都应该为推动会议担负责任，但是少数人应该接受专业训练，成为这项工作的专家，掌握其高度发达的技巧。

  第十四章讲的是功能，第一点为什么，使用功能启发式方法来识别真正需要的功能，减少忽略重要隐含功能的机会，微信的功能提供认识和机会，创造功能一直处理方法。第二点什么时候，再细化每一个循环阶段应用功能启发式方式。第三点怎么做，跟你的客户进行以下步骤：

1.通过头脑风暴，开发潜在功能的原始列表

2.区分开每一种功能为明显、隐藏和装饰三类

3.利用这个分类结果，努力揭示没有提到的隐藏功能，可能是以头脑风暴的方式谈论功能列表得到结果

4.当你进行分类时，寻找暗示了一些解决方案的限制条件的功能描述，并且将这种措辞转变为问题描述，而非解决方案描述

5.为装饰性功能创建“如果你能够就实现它”的功能列表