系统设计方法论1-拧干水分，竖切需求

系统设计方法论1-拧干水分，竖切需求

1、如何成为别人眼中“既懂业务又懂技术”的大牛？

2、怎么才能听完需求后，马上提出完善的方案，让业务和开发都叹服？

3、程序员的核心竞争力以及“护城河”

在程序员的乌托邦世界中，产品经理或者业务人员，能够精准的描述出来所有的产品功能、需求条目以及逻辑处理流程。

然后，程序员只需要按部就班的开发，就可以了。

可惜，这只是白日梦。

也幸好这只是白日梦，否则程序员马上就会被机器替代。

所有程序员都憎恨需求的频繁变更，尤其是在到了开发的中后期。

因为，修改设计方案的代价非常大。

并且压缩了开发周期，如果无法按时交付，总归是程序员背锅。

好像所有人都认为“只要开发加加班就好啦！”

因为程序员的工作量容易量化，而业务需求、产品设计，无法很好的管控。

或者说，无法管控。

如果业务说：哎呀，这个功能必须改，否则影响整体业务流程。

又或者说：没办法，这是监管要求。辛苦大家啦。

程序员能拒绝吗？

领导会支持谁？

顶多笑眯眯的说，大家辛苦一下，体现能力的时候到了。

于是程序员加班……脱发……猝死……

……

这个世界上总是有一些不靠谱的人，还有一些我们无法拒绝的人。

所以，我们只好自己更牛逼一点。

作为开发的起点，对需求的分析把控，决定着项目的生死、开发团队的“死活”。

也是一个架构师或者带头人能力的核心展现！

1

业务表述100%有问题

你要坚信，业务人员的表达百分百有问题！

有了这个信念，你就会带着批判的眼光，去看业务需求文档、去听业务人员的描述。

这是你牛逼的起点。

业务系统开发，难度不在于技术，而在于准确把握“需求”。

尤其是在产品经理或者业务人员“有意无意”间，没有准确描述需求本质的情况下。

因为，99%的业务人员，没有受过专业的需求培训，总是在需求中掺杂了自己的想法，对原始的需求进行了潜意识的加工。

或者无意中描述了他自己臆想的实现方案。

可怕的是，他自己都没有意识到这一点。

有一个稍微极端的例子：

业务人员：我要造一个梯子，并且需求文档中已经明确了所有的细节参数，例如梯子的材质、颜色等一系列要素……你们只需要实现就好了。

牛人：为什么要造梯子？

业务人员：客户要去摘苹果，苹果太高，够不着。

牛人：为什么要去摘苹果？

业务人员：客户说他口渴了。

牛人：为什么不直接去买水？

业务人员：……

上面的例子比较极端，下面具体一点讲述。

2

拧干水分

造梯子的需求稍微极端了一点。

实际上，需求中的水分都有一个特点，在需求文档中显得非常正常，且让需求非常饱满。

似乎按照需求文档去实现就好了。

但是真的这么开发，产品就会变成四不像。

水分之一，业务自己加上了技术实现方案

举一个实际的例子，当然是脱敏，重新演绎后。

在一个2 B产品中。

集团企业需要为它的子公司、孙公司等，分别录入每一个公司的具体信息，这些信息非常多。

每一个信息都是必须的，形成表单，交给后面的处理节点使用。

而这些集团企业，都是同一法人，一些信息都是相同的。

业务需求文档中写道：

集团总公司操作人，填写一个子集团后的通用信息后，再分别填写各个子公司的个性化信息，系统生成表单，填写到每一个子公司的信息记录中。达到共享信息的目的。

通读一遍，似乎已经表述的非常清楚。

但是，很明显，这么做非常复杂，且耦合。

很多开发人员，看到这里也许就去想怎么实现了。

甚至可能考虑到了，是不是设计纵表的方式，来存储较少的个性化信息，并且增强扩展性……

实际上，面对需求，首先要考虑的业务本质。

应该问：为什么提出这么一个通用信息合并的方案，到底要解决什么问题？

业务答复，就是为了解决操作人，需要多次填写相同信息的问题，提升使用体验。

很明显，这个需求，是业务人员自己加上了他能想到的实现方案。

实际上，我们完全可以做到更好。

例如，直接给他一个方案，我们提供模板功能。

当客户填写完成一个之公司信息记录后，填写新的公司信息时，可以通过选择之前已经填写的记录，将通用信息直接带到新公司信息表单中。

这样的话，还是提升了客户体验，且系统实现上非常简单。

水分二，业务加上了不成熟的交互方案

再看另外一种类型的水分。

是一个银行提供的资金监管类产品。

需求描述：

为减少核心企业财务工作负担，在接收经销商打款时，需要分别独立控制付方金额、付方账号、付方户名，如果付款账号不在设置的白名单中，需要直接原路退回资金。另外，金额、账号、户名等白名单的设置，在签约时由客户经理登录产品系统设置，或者发生变化时，进行修改。

描述的交互流程也貌似很完善。

但是，实际上再继续想一下，这个方案非常不合适。

1. 控制付方白名单、金额白名单，竟然需要去修改签约配置信息。这个信息，难道需要通过客户线下交给客户经理，让客户经理再去操作？
2. 付方金额、付款账号、付方户名，以及之后可能的控制规则，应该都可以无限叠加，而不是每次去人工修改签约信息。

这个需求的本质，是提供给客户控制付方白名单的能力，防止造成很多没有登记的白名单，导致财务需要清分的工作量较多。

那么，实际上最好的解决方案，就是给客户提供付方白名单控制接口，对方的ERP系统随时来调用、修改。

完全系统交互，不再需求人工参与。

水分三，非标准表述，造成的谬误

例如“白名单”、“黑名单”等有固有含义的名词，不能滥用。

在程序员眼中，一些约定俗成的词语是有严格的功能含义的。

白名单，指的是有某种权限做某种事，例如网络白名单、客户白名单。

黑名单，是指不允许做某种事情的列表。例如，咱们国内访问不了Google的网址，大家一般都说是被“墙”了，实际上是被中国的网络总控添加到黑名单了。

而一些业务人员，认为可能会误用此类词语。

程序员一定要详细咨询，业务的具体背景流程。

而不是见到这个词语，就认为是自己理解的那个含义。

因为开发人员与业务人员，对于某些词语，没有达成共同的语义认知。

所以一定要刨根究底，通过下面的竖切需求方式，找到本质需求。

3

5W2H 竖切需求

需求分析，尤其是业务方面的分析，实际上有明确的方法。

最首要的是，看到需求文档后，大略浏览一下要做什么事情。

具体的需求，当面讨论。

为什么当面讨论？

是因为业务在将需求落地到文档中的时候，肯定是进行了加工。

而谈论的时候，往往会用了另外的表达方式来表述，能暴露出更多的信息。

所以，首先要通过下面的方法，追本溯源，找到需求的本来面目。

也就是砍掉需求上的枝丫，找到本质。

还是拿上面的需求例子：

为减少核心企业财务工作负担，在接收经销商打款时，需要分别独立控制付方金额、付方账号、付方户名，如果付款账号不在设置的白名单中，需要直接原路退回资金。另外，金额、账号、户名等白名单的设置，在签约时由客户经理登录产品系统设置，或者发生变化时，进行修改。

追本溯源，名词、动词、参与方

1. What ——是什么，目的是什么？本质是什么？

   第一步，将需求中的名词、动词标出来不同的颜色。

   为减少核心企业财务工作负担，在接收经销商打款时，需要分别独立控制付方金额、付方账号、付方户名，如果付款账号不在设置的白名单中，需要直接原路退回资金。另外，金额、账号、户名等白名单的设置，在签约时由客户经理登录产品系统设置，或者发生变化时，进行修改。

   第二步，根据以往经验分析扩展，需求本质是：对付款方的入金控制，需要支持金额、账号、户名等维度的控制。

2. Why ——为什么，为什么这么做，原因是什么？

   核心企业的财务人员，需要根据下游经销商的入款，做对账，后续出货处理。

   但是，很多经销商使用的付款账户，可能是照的亲朋好友的账号，这导致财务人员需要人工清分联系确认，工作非常繁琐。

   那么，这个需求的本质原因，就是经销商付款账号杂乱，核心企业财务人员工作负担大。

3. Where ——何处？在哪里做，从哪里入手？

   那么，为了杜绝客户财务人员的人工工作量，在业务交互那个过程中做优化？

   这个需求，比较简单，在入金的时候，做控制。而不是在签约信息表中，不停的修改。

4. When——何时，什么时候发生，什么时候完成？

   应更讲究时效性，在有入金时，马上进行校验白名单，不符合的马上退回。

5. Who——谁？谁来承担？谁来完成？谁来负责？

   刚才讲过，不要让自己的运营人员手工操作；并且从时效性考虑，最好是白名单客户设置后，实时生效，并且控制权交给客户。服务方只是提供能力。

6. How -怎么做？如何完成

   提供白名单控制接口，供客户ERP系统或者财务系统，随时调用。

7. How Much——多少，做到什么程度？

   完全自由，放开能力给客户。并且白名单的规则，随时叠加。

这么几步分析下来，整个需求，以及设计方案就明确了。

绝不是初始需求中描述的样子。

4

找到遗漏

通过上面的步骤，将需求中的功能分析完成之后，设计方案就比较完善了。

但是，还有一类细节需要注意。

某些情况下，业务人员需求中描述的信息不完全，会导致后面设计返工。

例如，某种服务，需要登录人行某系统，查询校验。

业务人员，只是提了一句，根据客户证件号码验证某种信息，唯一性校验等。

但是，登录人行某系统的时候，还需要输入注册地址、客户类型等一系列信息……

所以，在看到需求描述时，尤其是看似非常确定的点，一定要仔细考虑参数，是否完整的问题。

5

技术是护城河？

程序员的护城河是什么？

是个人的技术能力？

技术能力，不仅仅是对于某种语言、框架的熟练使用，精通各个细节。

还指具体的分析问题、解决问题的能力。

这也是任何一个行业都适用的最底层能力。

但是，现在新技术日新月异，而除了少数工作以外，很多应用系统都是使用框架做业务开发。

任何一个人，熟练了API之后，都可以快速上手。

所以，程序员的护城河，如果是技术能力的话，很浅，构不成防御。

6

核心竞争力

那么到底，什么是一个人的核心竞争力？

核心竞争力，是一个人的独特的知识经验的组合。

技术人员的底层能力，是所有人通用的基本能力，例如沟通表达、分析解决问题等等。

而外层能力，除了技术以外，还要考虑自己的业务能力，项目管理能力，产品设计能力。

技术能力，在所有技术人中达到90%以上很难，项目管理能力90%以上很难，产品能力90%以上也很难。

但是，如果你的技术能力80%以上，项目管理能力80%，产品能力80%，组合起来就形成了独特的竞争力。

但是，虽说实际工作中，各种能力都会用到，但是这样会不会给自己没有明显的标签？

我现在能想到的一个方法，是拿到PMP、NPDP等证书。

而业务方面，如果是做金融服务的，拿到一个CFA是非常有用的。

如果不是一个特别拔尖的高精尖人才，这条路子应该是最合适的。