软件以人为本2 - 为什么软件要以人为本？

软件以人为本，这是一个值得讨论的话题吗？

1. 回顾“软件工厂” 

至今还记得在我国九十年代中期兴起，两千年左右火爆的 “软件工厂”运动。CMMI、TSP、PSP、RUP、UML还有MDD等等就是在那几年开始火爆的。招募一帮代码工人，给他们合适的工具，用最好的流程和方法学管理他们，他们就能生产出符合要求的软件产品。多么好的想法啊！公司老板和管理人员太喜欢了，于是很多公司轰轰烈烈加入了“软件工厂”运动中。如果加上MDD，在不远的未来代码都可以自动生成，代码工人可以取缔，于是真正的“软件工厂”就建成了。当时作为软件开发人员的我也有点小恐慌，做开发真的是青春饭啊，这才做开发几年，连写代码这个工种都要淘汰了。

软件工厂如此定义软件开发：

1. 软件是针对既定需求的产品。

2. 软件可由预定义的模块组装，也可由预定义的模型生成，也可由代码工人编写代码完成。其终极目标是根据预定义模型，基于预定义模块进行的组装。

3. 软件中最重要的是语言，方法，流程和工具。代码工人只是资源而已。

时至今日，软件工厂的概念已经随时间流逝而渐渐淡去。然而这种思想在现在依然很有市场，因为它的最大卖点在于可管理性和可预测性，很符合企业管理的特点。

案例1：客户不等于需求

项目经理：“这是我们为你开发的产品，请验收。”

客户：“对不起，我们不能验收，这不是我们想要的。”

项目经理：“但我们是按照需求报告开发的，你们当时还签了字的。”

客户：“。。。。。。”

案例2：开发不等于资源

项目经理：“这个业务要下周交付的话恐怕不成，资源已经全部被占用了。”

业务：“那从另外一个业务去调一个过来，时间应该赶得上吧！”

项目经理：“我试试！”

开发还是资源，很难谈得上成长。项目经理还在救火，业务还是一团忙乱。

案例3：规则还是交付

项目经理：“这个业务延迟了5天，因为我们前端开发资源紧缺。”

业务：“那能不能让其他的开发人员做呢？”

项目经理：“前端组的有要求，不让自己做！前段时间他们去老大那里投诉了，我很被动。”

公司大了，分工细了，协调难了。部门间目标不一致了，满足客户和遵守规则冲突了，流程越来越多越来越僵硬了，人的力量越来越难发挥了。

案例4：开发和业务的沟通难题

开发：“业务那边又变了，这事没法搞，改来改去，他们到底要的是什么，不能先搞清楚吗？”

开发找到开发的老大：“老大，我们是不是给他们增加个需求评审。”

业务：“开发怎么还没开发出来，这样的话业务怎么能完成任务。”

业务找到业务老大：“老大，我们是不是要他们给出开发计划，用这个来管他们。”

2. 软件以人为本 

2.1 为什么软件要以人为本

在传统的思想中，我们应对沟通、应对人、应对变化的方式就是把它固定下来。所以我们试图把客户的需求固定下来，把工作流程固定下来，把工作岗位固定下来，把开发模式固定下来，把管理方式固定下来。在这个过程中，为防止其他人的变化给我们的工作造成的困扰，我们不停的给其他人带来的变化设置更高的门槛。当然，软件开发中的所有人都试图这么做，所以我们制造出了相应的组织、文档、流程、方法、工具，试图避免减少与“人”的沟通交流合作，试图降低对个人能力和创造性的依赖，试图用简单的、可重复的、易于管理的方式取得成功。

但是时间能够固定下来？变化能够固定下来吗？人能够固定下来？沟通合作能够固定下来？创造性能够固定下来？

这就是软件以人为本的由来了。“人”是变化之因，“人”也是应对变化之本。

如果让我重新来定义软件开发，我会如此定义：

1. 软件是为客户（人）创造更高价值的产物。客户（人）对更高价值的理解会随时间而变化，软件需应对这种变化。

2. 软件是客户与开发团队和开发团队内的人与人间合作的产物。个人的能力与团队的合作是软件能否成功开发的关键。

3. 语言、方法、流程和工具的主要作用是辅助个人和团队发挥更大的力量，从而能更高效地为客户创造更高的价值。

软件以人为本将包括对如下内容的独立思考：

1. 如何提升个人的开发能力和管理能力？如何提升与他人的沟通能力和自己的影响力？

2. 如何融入团队，进行团队合作？如何建立团队，促进团队合作？如何有效利用工具（语言、方法、流程和工具）辅助个人能力提升，帮助团队发挥力量？

3. 如何与客户更好合作以在更短的时间内为客户创造更大的价值？

2.2 敏捷十年

来自InfoQ《敏捷宣言十年后的思考2》。在敏捷走完十个年头的时候，敏捷大牛们纷纷发表意见，不少敏捷大牛认为敏捷在人方面并未取得期望中的成功。他们对敏捷社区提出了下述期望：

1. 渴求技术卓越

2. 促进个人转变和领导组织变革

3. 管理知识并推动教育

4. 力图在整个流程中最大化地创造价值

软件以人为本看来是一个长期的问题。