关于软件业务场景分析总结随记

      这两个月的时间都在搞软件的场景分析，划分Story。由于软件还基本上是给内部用户使用，这段时间就跟着行销、测试的屁股后面跑---弄清楚他们希望用这个将要做出来的版本规划什么样的网络，当前由人工来完成是什么做的。软件要做到什么程度？ 是全自动（完全代替之前的人工操作），还是半自动（部分功能通过软件实现，部分仍由手工操作）。和用户、测试人员反复沟通，文档一再检视、返工，人困马乏，说分析阶段是软件开发最累的阶段也不为过。一个阶段快结束了，赶紧做一下小结。

 

一、用户怎么用做出来的软件

      好比设计一个自动取款机，用户会在它上面输入密码、设置全款金额、拿走现金、打印凭条等。必须把用户的每一个操作场景理清楚，任何的遗漏都后导致最终产品的功能漏掉。从用户的只言片语中挖掘价值需求，美其名曰“站在客户的角度考虑问题”。如果你的客户一个经验丰富的行业专家它会提纲挈领的告诉你他想要什么；如果你的客户是一个刚招进来的新手，对自己本职工作的业务还没有搞通透，别指望他能直接告诉你他需要什么（对，客户还不知道自己想要什么）。

 

二、用户希望软件能告诉他什么样的结果

 

      软件通过图纸输出分析的结果。销售人员拿这这些图纸知道如何报价、需要多少设备；施工人员拿这些图纸能够知道如何施工、每块设备如何对接。软件的目标用户针对不同的人群，他们的职责不同，关注点不同。分析场景时必须考虑所有的用户群体，对用户进行分类考虑，任何遗漏结果都将是“软件不满足要求”。

 

三、用户永远会告诉你他们需要更快的马车

      作为一个职业程序员是不应该满足于用户告诉你怎么做就怎么做。用户都是本行业的专家(除了少数刚招进来的），他们深刻知道需要软件消除他们哪里的“痛点”。A用户告诉你它需要A1功能来解决某个问题，过段时间B客户告诉你他需要B1功能来解决某个问题，过段时间......。 这个时候你需要将客户的需求抽象出来，识别它们相同的地方，不同的地方，提炼出通用原则，该原则可以解决能预见的一类问题。客户的意见需要听取，它是你提炼原则的原材料，但不应该止步于此。

 

四、分析也需要敏捷

      当你的分析文档出来一个初稿，带上它找客户、找测试、找其他同时。一遍又遍的讲解，不要害怕会提出一堆问题，不要想先搞出一个尽善尽美的方案再找客户。客户想要什么不是分析人员抓破脑袋就能拍出来的---让客户告诉你；你可以引导客户，初始文档就是沟通的基础。事实证明，这比先自己想一个尽善尽美的方案更有效率，很多时候开发人员自己费劲心思搞出了个“天衣无缝”的方案，在和客户一交流发现根本就不是客户想要的东西，全部推到重来。