软件心学格物致知篇(2) 软件马斯洛需求层次详解

前言

前一篇我结合基于人的马斯洛需求层次理论提出了软件层面的马斯洛需求层次。它的大致模型如下：

为了方便理解，模型的每一层名称都沿用了人的马斯洛需求层次中的叫法。但是其每一层具体的含义却不相同。

这一篇我会对每一层展开来谈谈，并且在文末提倡大家可以试着用该模型去拆解下自己所经历过的项目，看看这些项目分别是在哪个层次。在结合项目的现状，你是否能有新的一些感悟。

软件中生理需求

对于人来说生理需求是最底层，用来处理生存问题的。其实一个项目也和一个人一样，人需要空气、食物、水、衣服和房屋住所，而一个项目也必须要有对应的生存资料。

对于一个项目来说，我把它们类比如下：

• 互联网基础设施是软件开发的空气，我们都在使用它，但越来越感觉不到它的存在。

软件开发都是构建于互联网基础设施之上，最原始基础设施有网络、DNS、基站、光纤、数据中心等，随着基础设施本身不断的发展，基础设施的概念开始从IaaS扩展到PaaS，现在及往后云服务、AI、函数式服务可能都会成为基础设施的一部分。

• 软件开发所需要的人(员工)，相当于其食物，项目是由员工共同创造的，必不可少。

项目必须由员工操作计算机来完成编写与测试工作。所以一个企业或者公司应该把员工看成是资源(食物)，而不是成本。一个伟大的软件肯定是由众多优秀的员工一起创造出来的，给员工赋能，构建良好的企业文化，才能促进企业和员工共同进步。

• 商业模式相当于软件/项目的水，一个人不吃食物可能能活一周左右，一个人不喝水可能就捱不过3天。

一个项目也是，如果没有合适的员工，但商业模式对了，项目可能勉强还能活一阵子。而如果项目的商业模式不对了，那项目生命周期很快就会终结。

• 知识产权相当于衣服，衣服不仅能御寒、抗侵扰起到保护作用，而且还有装扮遮羞的作用。

同样项目有了知识产权，可以很好抵御一些外部侵扰，而且拥有的知识产权越多，项目或企业的含金量或技术实力往往也越高。当所处市场环境不完善的情况下，我们也不应该去盗取他人的衣服，同时也要保护好自己的衣服。

• 工作场所相当于住所，一个项目也必须有一个让成员工作的场所，无论它是虚拟(远程)的还是现实(聚集办公)的。

一个良好的工作场所，有助于发挥项目成员的创造力，能保障互相沟通与协作顺畅，从而降低项目在质量控制、项目管理维度的风险。当然良好的工作场所重点不是办公室里球台与狗、食堂的丰富菜式。如果你会问那是什么呢？我不直接告诉你答案，我推荐你应该去看看杰夫-劳森的《开发者思维》或者里德-霍夫曼的《联盟》。

软件中安全需求

软件项目中的安全主要来自三个方面：资金、时间、风险

• 资金：项目是否有足够的资金支撑。

虽然资金在很多情况下不是项目成败的最关键因素，但是它的重要性也不言而喻。验证项目的关键假设需要资金，招募合适项目的优秀人才需要资金，使用互联网各种基础设施也需要资金。通常作为一个企业，一般准备实施一个承载着众多人期望的软件项目时，资金都是充足的，甚至是富余的。

• 时间：项目是否有足够的时间来完成工作。

曾经的一句天下武功，唯快不破，估计坑死了很多项目和企业。许多企业只看到了这句话的表面含义，而不知道正确理解这句话的前提条件，在项目关键假设还未被验证的时候，在市场需求还未被调研清楚的时候，在商业模式还未确定的时候，就已投扎了进去。然后要求项目在一个极其不合理的时间内完成，完全违背了事物的客观发展规律。就如一个孩子的出生需要10个月，而企业做法是给你10个孕妇，要求1个月把孩子生出来。

• 风险：任何的软件项目都是有风险的，没有百分百一定成功的软件项目。

如果有人这么保证的话，要不他是个骗子，要不他就是个傻子。当然我们更愿意用愚蠢来解释这个现象而不是用恶意。资金和时间也是影响软件项目风险的重要因素，此外还有来自外部环境的PEST(政治、经济、文化、技术)四因素，还有项目的关键路径设置，软件架构设计、项目架构设计等等。甚至是编程语言的选择都可能是组成项目风险因素之一。我们的目标是把风险控制在一个恰当的范围之内。

软件中社交需求

软件中的社交需求可以分为对外和对内两部分。

对外主要是需求的获取与管理，对内主要是项目管理相关的，包含但不限于需求跟踪、质量把控、配置管理、部署管理等。

• 对外的需求获取和管理：这里的对外是指项目团队之外，比如客户、项目干系人等。

如何正确获取客户和干系人的需求(背后的问题)，如何管理干系人的预期。通过对外社交，减少因为外部因素导致项目风险增加的可能性，要知道外部的变化有时候才是致命的变化，所谓牵一发而动全身，往往是从需求端开始的。

• 对内的项目管理：内部的社交需求主要是项目管理相关的工作，这也是项目成功交付的基础能力。

它确保了实现制定好的项目计划能够按照进度有条不紊的开展，同时控制项目成本，完成最终交付承诺。这个过程还会伴随着项目质量的把控(单元测试、自动化测试)，需求进度跟踪和把控(需求池，燃尽图，看板)，项目配置管理(协作文档，wiki，知识库)，项目部署管理(CI/CD)等。

软件中自我尊重

按照我之前说的，下面三层都属于项目设计。如果项目设计的生理、安全、社交需求得到了保证，那么软件项目的注意力就可以转移到软件系统设计上来了。

我觉得这也是软件工程最具吸引力的方面了。

在软件自我尊重需求中，我们必须要以遵循软件工程的客观发展规律，对软件工程本身保持尊重。

尊重软件工程的过程意味着我们要建立一个组织流程，要从项目的实际情况出发指定项目架构和详细设计的周期，指定合理的培训和评审制度，采用DevOps来辅助完成项目构建流程，关注用户体验，做好专业知识的沉淀和分享等。

软件系统设计是一个宏大且复杂的议题，我在这里就不展开阐述了，关于怎么做好架构和系统设计，或许你可以从居瓦-洛瑞的《架构之道》，Bob大叔的《架构整洁之道》，George Fairbanks的《恰如其分的软件架构》中得到一些启示。

软件中自我实现

软件需求层次最上一层体现了软件系统超越了它本身的实现(商业价值)。这一层主要包含了开发技术、工具、方法论、框架相关的核心技术方面。

这是金字塔的巅峰，但是只有在较低的需求得到充分满足之后，它才能充分发挥出它的作用。

其实这也很好理解，一个软件系统首先要满足的当然是其商业上面的价值，而不是通过这个软件系统得到了哪些技术工具类，造了哪些轮子，封装了哪些基础库。

如果这个项目很快就夭折了，那么意味这所有这些技术和代码的生命周期只有短短的几个月，这些轮子、工具、方法论、框架可能都未能有时间得到充分的验证，也不可能再有机会去迭代和升级了。

但是很多技术人员，他们由于职业的局限性，在软件项目中往往最先关注的是金字塔的最顶层，这是十分危险的，相信你也看到了，最顶层的价值构建是需要建立在下层基础之上的。

你看看最上层的本质是工具，如果只关注最顶层，那岂非是自己把自己定位成了工具人呢？

模型小结

我再强调一次，在软件需求层次结构中，较高层次的需求是为较低层次需求服务的。如自我实现层的工具、框架、方法论是服务于尊重层的架构、流程。同样架构和流程需求是服务于安全需求的。

这也揭示了，我们在做软件设计的时候，应该是自顶向下的设计。其中自我实现层、尊重层的设计我通常称之为系统设计，社交层设计通常称之为项目设计，最后生理层和安全层不应该是设计出来的，而是已得到验证的。

因此按照时间顺序，我们必须先做好系统设计，之后才能通过项目设计来完成软件系统。但是我看到过很多软件项目，它居然是反过来设计的。我想他们心里想的是不是：有多少人干多少事？

验证模型

我们可以将一个典型的软件项目，将其成功的必要因素一一列出，然后进行优先级排序。最后把它们分配到这个层次结构中。假设有这么两个项目：

• 项目一：一个紧耦合设计的项目，维护成本很高，代码重用度很低，难以扩展。不过你有足够的时间来完成这个项目，项目人员配备合理。

• 项目二：一个令人惊叹的架构，拥有模块化和领域驱动设计，具备良好的可扩展性和可重用性，能经得起未来的考验，满足了所有的需求。但是团队人员不足，没有人和足够的时间来安全的开发系统。

好了，你的选择是什么？

毫无疑问，你应该选择第一个项目，没错!是第一个。时间和人员设计处在比架构设计更低的层次。我们说过，高层次是为低层次服务的，而不是反过来。

遗憾的是，许多的公司和软件项目开发，都是把软件需求层次的金字塔倒过来了。这也是很多软件项目失败的典型原因，你去看看，有多少开发团队几乎只关注技术、框架、库和平台。在架构和设计上几乎不花什么时间和精力(甚至没有），然后完全的忽略了时间、成本和风险等基本问题。

这种不稳定的结构，这种软件需求层次倒装的结构，项目失败了也不足为奇了，反而成功的话，那简直就是奇迹了！

好了，接下来请你来为你的项目做个拆解，看看你的软件需求层次健不健康，稳不稳定。