上一篇 提到了对BA工作技能的一点看法，篇幅关系（一次性写两千字也差不多是我的极限），只谈了两点，沟通和Email的一些小技巧。刚刚回看了下这一篇以及第一篇的阅读量，加起来居然过千，狂喜。第一篇的链接 再贴下。感谢支持哈！喜欢的走过路过点个赞呗！
今天先补充说说我之前漏掉的一些东西。ps：原来简书支持markdown模式，我今天才知道。。。
沟通
沟通从来就不是一件容易的事，只要是与人打交道的职位，这项能力都尤其重要。但现实就是，沟通能力好的人在哪里都是稀缺。
沟通能力包括很多，表达，聆听，演讲等等。倾听可能比说更难。快言快语如我曾经在课堂上听到这么一个说法：“当你和他人交流的时候，如果你满脑子想的都是如何去回应对方的观点，那么，对不起，你并没有真的在聆听”。刻意练习一下聆听吧，会让用户更愿意和你分享他们的想法。
能面对面沟通的时候，Email可能不是最好的选择。提高工作效率要从好的沟通方式开始。当然，现实工作中，必要的邮件recap也是再次确认共识的方法。
简单补充过后，这一篇来谈点其他的基本技能吧。
原型工具
Prototype有助于在项目开始阶段方便大家更好地align对业务、系统流程的理解，也可以方便BA自查自己对需求的理解和设计，所以大家都非常推崇做原型。
可以用相对花时间的方法来做产品原型，高保真的；也可以用相对简单快速的方法，比如纸原型。丰俭由人，这取决于你希望通过原型解决什么样的问题，也取决于你对需求的把握到了什么阶段。
比如说，你和用户的沟通才刚刚开始，大家还不清楚是否已经达成了共识，那么一个简单的原型是个不错的开始。比如说，你和用户的沟通已经完成的差不多了，现在你希望可以更好的和开发沟通需求，并追求完美的呈现，那么花力气做个高保真原型也并不浪费。
工作中我们曾经用过不同的方法做原型：
- 直接写HTML+CSS+JavaScript（模拟系统反馈等效果）。简单直接，省钱（不需要任何license），但工作量还是很大的。
- Ext Js Designer，受制于当时参与的项目的技术栈，所以选择了这个工具，入门技术门槛略高，维护起来比较麻烦。
- Axure RP，看看官网的视频就能上手，很好的适用于团队共同开发原型的场景，可以很好的模拟出页面跳转等feature，模块化等特性做的也比较好。
这几年最流行的是sketch，颜值确实比较高，但我们并没有在项目中使用过。
我觉得一个合理的做原型流程是：
- 和用户在白板上用各种辅助工具align好大致的系统设计流程
- 用Visio绘制流程图，梳理清楚宏观设计，检查是否有逻辑错误
- 在白纸上画出大致的页面设计，表格按钮的摆放等等
- 用Axure，将更细致的设计，页面布局以及页面间的跳转逻辑反映出来
由宏观到局部，由难（难于回退）到易（容易改变），由总（总体的架构）到分（细节的处理）。
一些简单地交互原则，BA也是需要掌握的，比如10 Usability Heuristics for User Interface Design 。何谓之经典，这些就是。好的系统设计一定是结合了科学和艺术的。
如果BA团队能配备交互设计师，或者说BA能和交互设计师充分合作，绝对会比单打独斗强。虽然这两个职位需要的能力和工作方法上有部分共性，但对能力和天赋的要求还是不太一样的。
"The 10 most general principles for interaction design. They are called 'heuristics' because they are more in the nature of rules of thumb than specific usability guidelines."
These are one of the most used heuristics for User Interface Design. They were developed by Jakob Nielsen together with Rolf Molich in the early 90's. The final set, which you see here, was released by Nielsen in 1994.
The heuristics are explained in greater depth in this video on YouTube.
Documentation with Office365
当敏捷方法开始流行之后，我就常常听到认识的人说，“敏捷很好，从此不需要写文档了“。
敏捷宣言白纸黑字写的是“可工作的软件over复杂的文档”，“我们认同右边的item有价值，但我们觉得左边的更有价值”。
但为何大家的“理解”都是“敏捷是不需要写文档的”。文档真的很不被待见呀。
- 不要项目一开始就忙于写文档。当还不确定系统是否有用的时候，如实反映系统逻辑的文档可能也没用。建议推迟写文档的时间。
- 与其花大量的时间去写没人愿意看的文档，不如花点时间写出让人愿意去读也觉得查阅起来更方便的文档。我想这也是就user story产出的原因吧。够简短（只能写在卡片上），因为简单所以需要communication。
- 多用图形和表格，可以省略掉大段没人愿意写也没人愿意读的文字。举例来说：
-- 系统之间消息的传递，流程图，业务规则的逻辑设计： Visio；
-- 页面的查询条件组合，EDI Message Schema，数据字典： Excel；
-- 页面跳转关系：Prototype；
-- 用户的培训材料：系统截图制成的PPT
-- 我只在需要的时候用Word，比如需要阐述项目的背景，假设，一些难于用图形描绘的上下文业务规则等。
数据分析
我们常常说BA要多做数据分析，在需求分析阶段要做，在项目实施的过程中更要做。
要分析数据，就先得有数据。一个有技术背景的BA可以不求人，自己通过SQL Developer或者PL SQL直接去拿数据。这一波操作还是有些需要提醒的地方：
- 通常我们不会允许直接从prod环境直接拿数据，一是因为写的不好的查询语句是可能搞垮DB的，也是因为生产环境会有些敏感的数据，基于保密的原则，无法开放。
- 在我司根据不同的项目类型，主要会使用Oracle和MongoDB，查询时用到的工具也会有区别。
- 不清楚domain关系，可能会完全不知道哪些数据才有用。清楚了domain关系，也要通过尝试，才能找准自己想要的数据。
拿出数据后，分析的过程，也是可以通过一些工具辅助的，比如Excel的透视表，比如我司很推荐使用的Spotfire。在数据量不太大的时候，我觉得excel使用起来更方便。除了透视表，Excel中的各种常用函数啦，也都是可以辅助数据分析的利器。
分析完之后，就有了进一步通过图形化来呈现分析结果的要求，同样，Excel和Spotfire都可以做到。饼图，直方图，到底哪一种才适用于你想表达的内容，这完全都依赖于你本人对数据的理解。
数据分析确实是个因人而异的过程，我们常常说的business sense在这里体现的很多。
今天写这三点，也是有感而发，因为白天和同事们一起review我们的团队介绍slides，其中有一页就会分享下BA工作常用到的工具。
没有彩蛋的文章是不完整的，推荐一个我常用的图标网站吧！
