当我们讨论软降工程的时候在讨论什么

软件工程也是软件项目，如果只是当做一个项目，那么项目有项目的管理方式和特点，这个有PMP等课程，也是帮助项目负责人（项目经理）如何更好的把我项目，来控制项目的质量，进度，费用等。

从项目的特点而言，既然认定为项目，那么在很大程度上是需要一个team，一些人一起共同完成，其中的原因是一个人无法掌握这么多的知识，必须通过协作来达到项目的目标，当时这个项目的目标也是参与的各个人的共同目标。同一个组织，同一个梦想。

软件开发的过程一直在进化，从原来的额瀑布的方式，到敏捷等等。当我们最开始学习软件项目开发过程管理的时候，我记得比较重要的是说需求的确认要比代码的编写重要很多，而且在项目管理的过程中时间占比也重很多。

那么这里的需求和一般的项目需求的差别是什么？

土建项目和我们软件项目的管理的实施的差别在哪里？

软件项目开发常见的问题。

1.开发维护成本越来越高

2.开发周期过长

3.系统开发跟不上需求的变化

4.需求变更很频繁

在这里我主要想沟通一下关于我们系统开发跟不上需求变化的问题。

传统的软件项目需求管理人员在互联网时代是产品经理的角度。当然产品经理的角度更多是在2C的产品设计中，要重视用户的使用体验，如用户使用不爽，那么软件产品没有人使用，公司就没有任何价值。但这种使用除了功能的需求，还有其他角度的需求，体验爽不爽是一个非常综合性的问题。

传统企业的软件开发，是内部的，内部流程的确认，结合功能的开发。体验不是非常重要，管理流程是否确定是重中之重。

按照开发流程

确定需求->概要设计->详细设计->开发->测试->用户确认->上线

上述是一个比较典型的流程。

在这个确认需求的环节，好的需求管理人员需要进一步分析和了解用户的需求是什么，为什么这个需求，到底可能存在哪些变化，好的需求管理人员能很好的把握业务部门的需求，对于新的需求尽可能不做开发，或者不改变系统框架的条件下达成目标，也让我们的软件产品稳定，，降低我们的软件开发成本等。

那么软件是什么？如果从工具的角度而言，这个工具和别的工具什么差别？

我们用锄头来锄地，我们用电吹风来吹头发，这些都是工具。工具是用来解决问题，都存在这个东西的内在实现和用户使用两个视角。

工具的存在是为了解决特定的问题，这个问题需要有一定的边界，这个边界决定了这个工具设计的边界。我们需求人员在对于无结构化的业务部门提出的需求，需要进行分析和建模。这个是形式上比较理性的过程。业务流程，表单等等。

软件其实解决的信息流，这个东西比较抽象，也是无形的，你有一个吹风机，但一般的人可能不会想能否来一个自动吹头发的东西，我不用自己去摆弄这个吹风机工具，我头发就立刻干了，或者我的吹风机能够自动的来给我吹头发，各种角度。因为在用户的心中对于吹风机的功能有一个大概的范围，这个范围决定了这个产品能做什么，不能做什么。

由于信息的概念很广，好像什么都可以做，那么用户的需求可能比较天马行空。

软件项目在需求分析阶段，就是对于用户的需求进行假设和建模，领域模型理论，是认为每个特定的领域都有自己的业务模型，通过和业务专家沟通，完成不同领域的特定模型，帮助需求人员和业务部门加快确定业务需求，保证软件质量。

上述的描述问题的另外一个思路是，从系统的角度是多层次的，那么我们是否可以多层级，多角度的解决问题问题。我们的世界比较基础的是原子，但我们不需要原子的概念来看这个世界，用户的视图也是多角度的，我们需要在不同的层次来看是系统，也需要掌握系统不同层次的规律，从而让系统柔性调整达到我们的目的。

刚才说道吹风机的事情，说明我们对于用户的使用期望的控制，如何控制用户的期望，那么可以降低我们产品乱七八糟的需求。

如果从公司的层面来看，最高的企业愿景是一个非常抽象的东西，这个东西的实现可能在不同的时代是不同的东西。比如快递公司，我们的目标更快的交付物品。但是马车时代，汽车时代，飞机时代，这些具体物流工具是不一样的，不同的交通工具，需要内部对应的部门的组织架构，业务流程，人员岗位也有不同变化。企业目标的实现=组织流程架构+技术+人。

在很大程度上这个也是从管理的角度对于企业实际业务操作的抽象，这个抽象是为了让我们能够更高的层次来看企业，把控企业的风险和利益。

软件项目在很大程度上是让机器支持这个流程。

业务部门和需求管理需要因为企业愿景的抽象性到具体实现的差异性中间的相关因素，导致这种变化成本是很高的。

软件项目的最终产品的一个特性是刚性。你不能所以的修改功能，和在系统内完成事项的刚性。如果在显示生活中要求10点上交资料，也许你11点也能提交。但是软件系统是不允许的，这种刚性也是他的一个特点，这个是内在的特型，或者说是他比较基层的特型。

自然世界的运作规律是客观存在，人不可修改。物理规律，化学规律，你不能更改，但在更高的层面上你可以通过其他的方式方法达到目的。

过去的软件产品在很大程度上是提出需求，建模开发，这个开发是代码开发，周期成本都比较长。

目前的一些SAAS的产品，是可配置的，字段，表单，流程都可以配置，这个是一个高层次的抽象和使用，可以快速交付给用户使用。当然这个也有别的问题。

但通过上述的一个组合方式，且你可以理解这个是多层第的方式满足业务部门管理的需求，可能取长补短的额方式来完成企业，部门的战略达成。

代码的重构，是为了适应企业业务新的模型，和原来代码架构的补足为了满足业务的更大的容量。

企业和部门组织架构的重构（这里我希望用重构这个词）是为了让企业的内部流程满足外部的需求。

丰富的行业背景知道哪些是真需求，哪些可以变通，哪些需要真的调整系统的实现满足。

系统的结构3-5年的调整可能是一个好的方式，不要指望系统这个模型一直用下去，这个并非是一个好事情。

动态的调整，合理的成本，且思考这种动态变化反应的外部世界变化的方向，应该是公司，业务部门，需求管理人员深入思考的。