菡萏如佳人人的马斯洛需求层次
1943年美国社会心理学家亚伯拉罕-马斯洛在他的论文《人类动机论》中提出了著名的理论，被称为马斯洛需求层次理论。
该理论对人类需求的相对重要性进行了排序，并提出了只有当一个人满足了较低的需求时，他才会对满足较高的需求产生兴趣。
最初提出的马斯洛需求层次是五阶的，如下图所示：
后面马斯洛需求层次其实已经扩展到了八阶，引入了认知、审美、超越需要。但引用最多和最被人们广为熟悉的还是最早的五阶。
• 1.生理需求：这一层讲的就是满足基本需求，维持个体生存。这是最低级的需要，如吃、喝、住所。对食物、水、空气、性等需求都是生理层面的。
• 2.安全需求：这一层讲的是保障安全稳定，免除恐惧威胁。包括心理上和物质上的安全保障，如不受盗窃和威胁，职业有保障，有社会保险和退休基金等。
• 3.社交需求：这一层讲的是与其他人建立情感联系，归属某一群体。包括对友谊、爱情以及隶属关系的需求。认识群居性动物，需要友谊和群体的归属感。
• 4.尊重需求：这一层讲的是人对内在价值肯定，外在成就认可。既包括自我的认可也包括他人对自己的认可。尊重需要包括要求受到别人的尊重和自己具有内在的自尊心。
• 5.自我实现需求：这一层讲的是充分发挥潜能，实现理想抱负。自我实现是指通过努力，实现自己对生活的期望，从而对生活和工作真正感受的意义。
我们可以看下西游记的取经团队中，各个人物在马斯洛需求层次中是如何体现的：
• 八戒，属于生理需求层，他的激励因素是食物、性。
• 沙僧，属于安全需求层，他的激励因素是安全、稳定、秩序。
• 白龙马，属于社交需求层，他的激励因素是友情、归属。
• 唐僧，属于尊重需求层，他的激励因素是成就、尊重、欣赏、荣誉。
• 孙悟空，属于自我实现层，他的激励因素是实现自我价值。
马斯洛需求层次指出人的需要层次是有高有低的，只有低层次的满足了，人们才会对更高层次的产生兴趣。
同样当某层次的需求已经满足了，那么这层的需要将不再是激励因素了。
在一个企业中，针对不同的员工应该根据员工所处的需求层次采用不同的激励方式。
所以你不应该也不能跟一个吃不饱穿不暖的人去谈自我实现，因为高层次是建立在低层次基础之上的。
以上是关于人类需求的层次介绍，下面我打算将该理论再引申一步，将它和软件项目结合起来，谈谈其实软件项目本身也存在一个类似的层次，我叫它软件马斯洛需求层次。
软件马斯洛需求层次
经过我长时间对各种软件项目开发过程的观察思考，得出一个感悟：其实软件项目(整个产品研发)也可以分为五个层次。
于是乎我就干脆套用马斯洛这个经典的五阶模型，姑且称之为：软件马斯洛需求层次理论。
整个模型自底向上向上分别为：生理需求、安全需求、社交需求、尊重需求、自我实现。名字虽然和马斯洛需求层次是一样的，但是在软件领域，在生理、安全、社交各个方面的含义和作用是不相同。
• 生理需求层：主要是满足基本需求，保障项目生存
• 安全需求层：主要是关注项目是否有充足资金时间，和位于可接受的风险范围内
• 社交需求层：主要关注项目里对外沟通和对内沟通，做好这些才能做出良好项目设计，构建可重复性
• 尊重需求层：这里尊重的对象是软件工程，要明白软件工程本身就是一个复杂事物，以及一些客观的规律
• 自我实现层：这里的自我实现主要是沉淀工具方法，沉淀出合适语言框架、通用工具。让软件项目的意义扩大延伸到更多的项目和地方。
和原生马斯洛需求层次一样，软件马斯洛需求层次中的每一个上层都是建立在其下层基础之上的，上层是为其下层服务的。例如：在原生需求层次中，吃饭是比就业更低的层次需求，大多数人工作是为了吃饭，而不是吃饭是为了工作。这一点尤其重要，很多公司的软件项目都有违背这一原则。
接下来我逐一介绍下软件马斯洛需求中各层次的具体含义
软件中生理需求
对于人来说生理需求是最底层，用来处理生存问题的。其实一个项目也和一个人一样，人需要空气、食物、水、衣服和房屋住所，而一个项目也必须要有对应的生存资料。对于一个项目来说，我把它们类比如下：
• 互联网基础设施是软件开发的空气，我们都在使用它，但越来越感觉不到它的存在。
软件开发都是构建于互联网基础设施之上，最原始基础设施有网络、DNS、基站、光纤、数据中心等，随着基础设施本身不断的发展，基础设施的概念开始从IaaS扩展到PaaS，现在及往后云服务、AI、函数式服务可能都会成为基础设施的一部分。
• 软件开发所需要的人(员工)，相当于其食物，项目是由员工共同创造的，必不可少。
项目必须由员工操作计算机来完成编写与测试工作。所以一个企业或者公司应该把员工看成是资源(食物)，而不是成本。一个伟大的软件肯定是由众多优秀的员工一起创造出来的，给员工赋能，构建良好的企业文化，才能促进企业和员工共同进步。
• 商业模式相当于软件/项目的水，一个人不吃食物可能能活一周左右，一个人不喝水可能就捱不过3天。
一个项目也是，如果没有合适的员工，但商业模式对了，项目可能勉强还能活一阵子。而如果项目的商业模式不对了，那项目生命周期很快就会终结。
• 知识产权相当于衣服，衣服不仅能御寒、抗侵扰起到保护作用，而且还有装扮遮羞的作用。
同样项目有了知识产权，可以很好抵御一些外部侵扰，而且拥有的知识产权越多，项目或企业的含金量或技术实力往往也越高。当所处市场环境不完善的情况下，我们也不应该去盗取他人的衣服，同时也要保护好自己的衣服。
• 工作场所相当于住所，一个项目也必须有一个让成员工作的场所，无论它是虚拟(远程)的还是现实(聚集办公)的。
一个良好的工作场所，有助于发挥项目成员的创造力，能保障互相沟通与协作顺畅，从而降低项目在质量控制、项目管理维度的风险。当然良好的工作场所重点不是办公室里球台与狗、食堂的丰富菜式。如果你会问那是什么呢？我不直接告诉你答案，我推荐你应该去看看杰夫-劳森的《开发者思维》或者里德-霍夫曼的《联盟》。
软件中安全需求
软件项目中的安全主要来自三个方面：资金、时间、风险
• 资金：项目是否有足够的资金支撑。
虽然资金在很多情况下不是项目成败的最关键因素，但是它的重要性也不言而喻。验证项目的关键假设需要资金，招募合适项目的优秀人才需要资金，使用互联网各种基础设施也需要资金。通常作为一个企业，一般准备实施一个承载着众多人期望的软件项目时，资金都是充足的，甚至是富余的。
• 时间：项目是否有足够的时间来完成工作。
曾经的一句天下武功，唯快不破，估计坑死了很多项目和企业。许多企业只看到了这句话的表面含义，而不知道正确理解这句话的前提条件，在项目关键假设还未被验证的时候，在市场需求还未被调研清楚的时候，在商业模式还未确定的时候，就已投扎了进去。然后要求项目在一个极其不合理的时间内完成，完全违背了事物的客观发展规律。就如一个孩子的出生需要10个月，而企业做法是给你10个孕妇，要求1个月把孩子生出来。
• 风险：任何的软件项目都是有风险的，没有百分百一定成功的软件项目。
如果有人这么保证的话，要不他是个骗子，要不他就是个傻子。当然我们更愿意用愚蠢来解释这个现象而不是用恶意。资金和时间也是影响软件项目风险的重要因素，此外还有来自外部环境的PEST(政治、经济、文化、技术)四因素，还有项目的关键路径设置，软件架构设计、项目架构设计等等。甚至是编程语言的选择都可能是组成项目风险因素之一。我们的目标是把风险控制在一个恰当的范围之内。
软件中社交需求
软件中的社交需求可以分为对外和对内两部分，对外主要是需求的获取与管理，对内主要是项目管理相关的，包含但不限于需求跟踪、质量把控、配置管理、部署管理等。
• 对外的需求获取和管理：这里的对外是指项目团队之外，比如客户、项目干系人等。
如何正确获取客户和干系人的需求(背后的问题)，如何管理干系人的预期。通过对外社交，减少因为外部因素导致项目风险增加的可能性，要知道外部的变化有时候才是致命的变化，所谓牵一发而动全身，往往是从需求端开始的。
• 对内的项目管理：内部的社交需求主要是项目管理相关的工作，这也是项目成功交付的基础能力。
它确保了实现制定好的项目计划能够按照进度有条不紊的开展，同时控制项目成本，完成最终交付承诺。这个过程还会伴随着项目质量的把控(单元测试、自动化测试)，需求进度跟踪和把控(需求池，燃尽图，看板)，项目配置管理(协作文档，wiki，知识库)，项目部署管理(CI/CD)等。
软件中自我尊重
按照我之前说的，下面三层都属于项目设计。如果项目设计的生理、安全、社交需求得到了保证，那么软件项目的注意力就可以转移到软件系统设计上来了。
我觉得这也是软件工程最具吸引力的方面了。
在软件自我尊重需求中，我们必须要以遵循软件工程的客观发展规律，对软件工程本身保持尊重。
尊重软件工程的过程意味着我们要建立一个组织流程，要从项目的实际情况出发指定项目架构和详细设计的周期，指定合理的培训和评审制度，采用DevOps来辅助完成项目构建流程，关注用户体验，做好专业知识的沉淀和分享等。
软件系统设计是一个宏大且复杂的议题，我在这里就不展开阐述了，关于怎么做好架构和系统设计，或许你可以从居瓦-洛瑞的《架构之道》，Bob大叔的《架构整洁之道》，George Fairbanks的《恰如其分的软件架构》中得到一些启示。
软件中自我实现
软件需求层次最上一层体现了软件系统超越了它本身的实现(商业价值)。这一层主要包含了开发技术、工具、方法论、框架相关的核心技术方面。
这是金字塔的巅峰，但是只有在较低的需求得到充分满足之后，它才能充分发挥出它的作用。
其实这也很好理解，一个软件系统首先要满足的当然是其商业上面的价值，而不是通过这个软件系统得到了哪些技术工具类，造了哪些轮子，封装了哪些基础库。
如果这个项目很快就夭折了，那么意味这所有这些技术和代码的生命周期只有短短的几个月，这些轮子、工具、方法论、框架可能都未能有时间得到充分的验证，也不可能再有机会去迭代和升级了。
但是很多技术人员，他们由于职业的局限性，在软件项目中往往最先关注的是金字塔的最顶层，这是十分危险的，相信你也看到了，最顶层的价值构建是需要建立在下层基础之上的。
你看看最上层的本质是工具，如果只关注最顶层，那岂非是自己把自己定位成了工具人呢？
模型小结
我再强调一次，在软件需求层次结构中，较高层次的需求是为较低层次需求服务的。如自我实现层的工具、框架、方法论是服务于尊重层的架构、流程。同样架构和流程需求是服务于安全需求的。
这也揭示了，我们在做软件设计的时候，应该是自顶向下的设计。其中自我实现层、尊重层的设计我通常称之为系统设计，社交层设计通常称之为项目设计，最后生理层和安全层不应该是设计出来的，而是已得到验证的。
因此按照时间顺序，我们必须先做好系统设计，之后才能通过项目设计来完成软件系统。但是我看到过很多软件项目，它居然是反过来设计的。我想他们心里想的是不是：有多少人干多少事？
验证模型
我们可以将一个典型的软件项目，将其成功的必要因素一一列出，然后进行优先级排序。最后把它们分配到这个层次结构中。假设有这么两个项目：
• 项目一：一个紧耦合设计的项目，维护成本很高，代码重用度很低，难以扩展。不过你有足够的时间来完成这个项目，项目人员配备合理。
• 项目二：一个令人惊叹的架构，拥有模块化和领域驱动设计，具备良好的可扩展性和可重用性，能经得起未来的考验，满足了所有的需求。但是团队人员不足，没有人和足够的时间来安全的开发系统。
好了，你的选择是什么？
毫无疑问，你应该选择第一个项目，没错!是第一个。时间和人员设计处在比架构设计更低的层次。我们说过，高层次是为低层次服务的，而不是反过来。
遗憾的是，许多的公司和软件项目开发，都是把软件需求层次的金字塔倒过来了。这也是很多软件项目失败的典型原因，你去看看，有多少开发团队几乎只关注技术、框架、库和平台。在架构和设计上几乎不花什么时间和精力(甚至没有），然后完全的忽略了时间、成本和风险等基本问题。
这种不稳定的结构，这种软件需求层次倒装的结构，项目失败了也不足为奇了，反而成功的话，那简直就是奇迹了！
好了，接下来请你来为你的项目做个拆解，看看你的软件需求层次健不健康，稳不稳定。