《软件方法》读后感 - IntoTw

近日，苦于不知道该怎么提升自己了，在原来老大的建议下，决定去学习一些关于建模和软件设计领域的书籍，来解决解决自己“感觉不对，但是说不清楚为什么不对”以及“感觉这么搞就对了，但是不知道为什么这么去规划，这么去划分就对”

第一本看的是潘加宇老师的《软件方法（上）业务建模和需求》,本篇读后感不再对文里的概念和内容一一赘述，只说说个人提炼到的收获

业务系统是人脑系统的映射

这是一个很关键的概念，也是让我们认清业务系统的本质，所以我们讨论很多问题是，也就有了依据。

我们平时所看到的软件系统，都以业务系统为主，他们要么是人脑系统的替代，要么是现实流程的表示，明白了这一点本质以后，我们对系统的边界和其中逻辑的合理性，就可以有了一个标尺。而不是“我觉得这里这么做不对，这个逻辑不对，但是具体又说不出来哪里不对，反正会出问题，这里不合理”。

我们如何用这个标尺来评价问题呢？举一个笔者了解到的例子，一套志愿填报辅助系统，其中有个“一键填报”的功能，智能推荐一些志愿，但是其推荐的逻辑竟然是选择一批志愿后，经过各种一系列花里胡哨的随机操作来“看似”随机得到一些数据，推荐给用户。

我们通过这个观念去思考这个问题，难道一个志愿填报报考专家，在帮助一名学生选择要填报的院校时，会一直“随机”挑选一些院校，而不是根据某些“标准”吗？

用潘加宇老师的话来说，这样的需求既不符合系统的“愿景”，也不符合涉众的“需求”，系统的愿景绝对不是随机给用户返回一些数据，系统涉众（系统的买家）的需求也绝对不是你给他随机返回一些数据。

作为一个志愿填报系统，系统的愿景一定是帮助用户填报志愿，指标可以是“更快的填报，更好的填报，更准的填报”，涉众的需求，也一定就是你的愿景。

阿布思考法

在我们平时讨论需求或者功能时，总是疏于讨论或者思考，也许这是国内软件公司发展时间较短带来统一的弊端。我们总是因为排期，或者上来就带入思路考虑实现的复杂度，来导致最后的方案不尽人意，其实这种思考方式只是从业者经验的浓缩，每个人的想法和理由都带着自己“私货”，产品经理一般没有能力和时间考虑的过于完整，项目经理在意项目的时间，研发经理在意实现的复杂度带来的系统问题，也在意项目的时间。

但是这种考虑问题的角度，不利于公司的发展和软件价值的实现，这里就涉及到了“大部分企业中层领导的利益价值和企业整体的利益价值是矛盾的”这个比较大的问题。我们就不深入讨论了。但是站在软件系统本身的价值来看，我们应该使用阿布思考法来考虑问题，即：尽可能先得到一个完美的方案，再考虑其中无法实现的地方去山寨。

我们举一个具体例子来看待这两种思考方式的区别，假设我们现在要研发一套自动驾驶技术的全套方案，按照阿布思考法，我们会从“如何才是完美的自动驾驶”这个点来考虑问题，考虑出需要的如31套各个细节子方案后，再依次对子方案找到目前最好的替代方案，最后得到了一套“目前时代下最好的自动驾驶系统”。

如果使用通常的思考路径去考虑，会发现在一开始就寸步难行，我们不知道一套自动驾驶技术方案要包括哪些方案，就算去思考，得到的也是支离破碎的一些方案，甚至落地的时候才会发现：“哦，这里原来少了个这个东西，需要再考虑下这里怎么实现”。要么就干脆先照抄友商，然后在UI、交互等方面做点“微创新”。但是如果没有友商呢？如果你是二次创业呢？这种思考方式无法帮你领会到新的东西，也无法帮你找到终极的方向。

__EOF__