阿里巴巴需求分析师团队

     需求分析师（RA）在阿里巴巴b2b的主要职责是作为商业需求与软件实现的枢纽，我们协助分析商业需求的合理性、分析其可行性，我们细化商业需求，评估影响面和实现成本，我们指导并验收开发的成果。同时需求分析师经常会担任PM角色。
     我们认为有二类人适合做这份工作：有技术背景，对商业很有感觉的人；有商业背景，对技术非常喜欢的人。 
     我们希望需求分析师还有一些共同的特点：乐观、冷静、敏锐、细致、善于沟通。
     在b2b的工作很忙很开心，我们有虚拟团队，有RA委员会，每个RA在工作的同时，有一定的时间静下来，讨论问题，学习进步。
         有兴趣的朋友，请发邮件到：liwen.xielw@alibaba-inc.com  谢谢，期待您的加入！

• 上下文：
   这个功能怎么这样的？一点都不好用！ 
   这个功能什么时候发布的？怎么没有通知我们部门？
• 解决方案：尽量使客户和内部涉众参与到需求分析过程
  
• 说明：
• 需求调研阶段向最终客户收集需求
• 需要评审（多阶段评审）和最终客户确认需求
• 测试阶段让用户参与测试
• 发布阶段让用户验收

• 上下文：

          为什么这个UC就这么点东西，每次看都能发现新问题？

          为什么每次需求评审都有语义问题？

          在需求分析的过程你是不是发觉上述的现象？
    

• 解决方案：

1.  
   1. 写需求和写作没有什么不同，每次写可能的都有独特的环境，不同的思路，不同的组织方式。
   2. 每个人都会存在一定的错误率

       因此尽早产出需求分析文档；把需求分析文档放一段时间再返过去看；朗读自己编写的文档；收集自己编写需求分析的错误率

• 上下文：
           ××时间××项目进行的需求评审会：
             界面设计人员：

                          这个界面用户体验有问题，这样是不是更好一点！

                      DBA：

                         这个功能对数据库压力太大了，需要….

                      老板：

                          项目的目标必须是增加pv 100w….
                    结果：需求评审会变成了讨论会，经过n小时后大家都累的受不了宣布结束，择日再议。       

                 你越到过类似的问题吗？ 需求确认会变成了讨论会！我们得怎么办？     

• 解决方案：在需求的不同阶段召集不能的人员进行不同类型的评审，第一种是规模较小的内容评审，可能要进行多次；第二种是正式的团队评审，可能仅有一次，不对 正式的团队评审寄予太高期望

• 需求分析过程会有多次迭代，每次迭代产出都不同。

1.  刚开始业务流程产出时我们需要和业务部门确定业务流程是否满足业务要求；
2. 当领域模型出来是我们需要和架构，设计人员，需求人员讨论领域模型的合理性；
3. 当用例划分出来时我们需要和需求，业务人员确定用例是否包含了所有的功能范围
4. 当涉及到用例中具体的交互时我们需要和界面人员讨论交互的合理性。针对每个阶段到达一定程度，我们都可以发起阶段性评审。而不是到最后在和所有项目的涉众去确认。评审会的工夫都在会外

• 上下文：
       传说古时候楚国有个书生，由于生活贫穷，很想找到一条发财的捷径。他读到一本书，书上说：“谁得到螳螂捕蝉时遮身的那片树叶，就可以用它来隐身，别人就看不见了。”他信以为真，整天在树下抬头望着。嘿！他终于看到了一只螳螂躲在一片树叶后面，正准备捕捉知了呢！他连忙把那片树叶摘下来。不料那片树叶掉下来，混在地上的落叶里，再也辨认不出了。他只好把所有的树叶扫回家来，一片一片地试。他把树叶遮住自己的眼睛，问妻子：“你看得见我吗？”妻子总是说：“看得见！”后来，妻子被他问得厌烦了，随口答了一声：“看不见！”他喜出望外，马上带着这片树叶，当面去偷人家的东西，结果被人家扭送到衙门去了。县官经过审问，忍住笑，说：“你真是一叶障目，不见泰山呀！需求分析的过程是一个探索和发现的过程，不可能一下子就知道所有的细节。
• 解决方案-宽度优先，

  从顶至下，逐步精化

• UML是天生的宽带优先的工具：

  1 首先和客户/业务部门访谈，形成业务流程图：了解最原始的业务需求
  2 根据收集的业务流程图划分用例，形成领域模型：从整体了解需求的范围，对需求进行划分，形成整体的概念。
  3 针对划分出的用例编写主干流程 ，可以进行分工合作
  4 补充分支流程
  5 在用例中增加细节，比如文案，校验，demo等

我们在使用UML进行沟通中发现存在以下问题：

       实际工作中，UML图表的使用率减少，而其他文字类的沟通方式进行过多的辅助说明，原因发现，UML不能很好的在需求分析师、架构师、开发工程师、测试工程师之间形成沟通纽带。

      大家可以思考以下的问题：

　　１、我们为什么不爱使用UML？

       2、UML为什么不能成为人员沟通的纽带？

       3、是否存在更好的沟通方式？

       问题我暂时提三个，下面是我自己的想法：（我希望大家能思考，发表自己的看法）

        UML的原意是统一的建模语言。我认为分析上面的问题，要从人类的沟通需求看：

        1、作为一种沟通语言需要具备的是，沟通的多方使用统一的语义系统。

        2、语言的表达灵活简便（即输出）；语言的接收即时易懂（即输入）

        当前的UML显然在两个方面都存在缺陷：

        针对问题1，我们发现同样的功能用例可以被表达成不同的用例图，同样的用例图可以被理解成不同的功能用例。语义系统并非统一，查阅网络有关uml的很多资料都存在说法不一致或者表述不明确的情况。存在过于细微差异的图标定义，反而让使用者很难决定采用何种图标来进行表达。从表达环节出现偏差到理解环节再出现偏差，让表述的原意在传递过程中被损耗、歪曲。

        针对问题2，首先对于输出端的使用者来说，最容易被灵活使用的就是现有人类沟通语言体系中的文字体系，因此，也是这么多人使用文字说明来表达需求的原因之一。但是，图形在结构表达方面显然比文字更为出色，但在含义表达方面却逊色于文字描述。 分析当前我们在使用的UML，其中存在过多的含义表述是采用了图标而非文字。

       因此，也就形成了目前UML的简化使用趋势，各位不妨收集下UML当前的简化用法，看看是否简化的部分正是含义表达的图标而非结构表达的图标！

       所以，本周RA会议最后对于UML讨论的决定，我们将在今后会议中分别对UML基本图例进行深入研究。我的设想是：研究UML图例 ——> 找出当前UML容易出现多义的地方（这些部分也是作者表达不清，读者理解混淆的地方）——> 整理出ali的UML简化标准

     希望大家多参与！

  上周整理了一下面向对象概念关于对象之间关系的一些东东，写出来大家看看有啥不对的地方帮偶补充哈。

  对象之间的关系分为静态关系和动态关系两类。我们先说静态关系，对象之间的静态关系主要分为关联、依赖、泛化、实现四种。

1.   关联（association）

  在UML中关联被描述为：“不同对象或者类型之间的结构化关系”。指的是概念之间的一个有意义的或者让人产生兴趣的连接。值得注意的有两点，一是通常关联都是我们必须知道的某种关系的存在，二是关联是有生命周期的。

  在我们建立概念模型的时候通常要考虑以下两种类型的关联，

1）对象之间的关联是需要保存一定时间的关联；

2）从通用关联列表中派生出来的关联。在概念模型中加入关联时可以参照以下通用关联列表：

Read the rest of this entry »

写前面一篇文章的时候，发现有个浏览者的足迹，真的非常惊喜！

但同时心情又一落千丈了，原因很简单，只有几个字：啊~会议，路过！

呵呵，再回过头来看看我们的博客，会议记录已经第10次了，其他有实质性的内容呢？少得可怜~

从建立之初，我就抛出过这个论题，我们这个博客未来两个月的处境是怎样的，现在的结果大家也都看到了！

如果继续下去，只能会越来越糟。所以，就有了这篇题目。。。

大家有没有感觉，我们的会议也越来越形式化了。。。

原因，大家应该有体会吧~~~

从产品经理联盟看到的文章，作者也是引用的网络文章。我没有深究其最终的出处，从字面理解上我觉得应该值得我们借鉴。先转一下原文：

原则１

永远不要显得比客户更聪明

第一条：了解需求，而不是去批评客户；

第二条：客户比你更熟悉业务的环境；

第三条：客户总是知道问题在哪儿，你的工作就是要让他们自己愿意说出来；

原则２

尊重用户的现实选择

第一条：客户永远是对的；

第二条：提供最合适的解决方案，而非最好或最贵的方案；

第三条：不要把客户当傻瓜；

原则３

转述需求的人也是客户

第一条：转述者一般会把自己想象成设计者；

第二条：转述者可能会遗漏或补充一些额外的需求；

第三条：对转述者的自由发挥不应抱怨和生气，而是将其视为客户；

原则４

客户和用户要区别对待

第一条：产品为最终用户设计，需求的功能转换为最终用户的使用要求而确定；

第二条：为客户寻找价值上的需求；

第三条：用户的利益高于一切；

原则５

用最简单的文字工具记录需求

第一条：所有人都能懂的东西，最不容易出错；

第二条：不需要再学习的东西，最不容易出错；

第三条：不要希望客户能花更多的时间来了解需求转换后的模型；

第四条：保持沟通的通畅，是了解需求的保障；

原则６

天下没有免费的午餐

第一条：客户从来没有不合理的需求；

第二条：客户的要求都是可以实现的；

第三条：我们能做这事－这是所需的费用

从原文的出处，我们可以理解这是更符合从原始用户那里搜集需求的过程。

对比我们的需求过程，更多的是从PD那里得到的（BOPS的需求会更贴近一点客户）。

但我觉得方法是相通的。

就原则一而言，有时候我们对PD的想法嗤之以鼻，认为他们的需求是纯粹为了KPI的下三烂做法。但这种想法（或方案）的背后，我们不能说他们没有做过调查、不能说没有经过深思熟虑。作为RA的客户，他们更熟悉业务环境，更知道问题出在哪儿，更知道这是不得已而为之但又不失是一种捷径。

正如为了保证搜索结果的客观和真实性，google不会在搜索结果种掺杂任何商业元素；我相信，每个RA都想做google的模式，而不是百度。但，又大家有没有想过，中国的中小企业用户有多少又是希望在搜索结果中直接展示所要的商业信息呢？他们才不管是不是付费广告，更有甚者会认为在这个地方做广告的公司肯定有实力。昨天参加了《走进中小企业》的培训，得知这种情况发生的真实性；而且还是典型！

总之，我感受最深的是第一个原则。在我们挑战PD的想法的时候，先问问他们的出发点到底是什么！其他的原则，还没有太深的感受，等有了继续写。。。