在学习宝玉老师的《软件工程之美》课程的时候，宝玉老师给出了工程思维的概念：
工程思维，本质上是一种思考问题的方式，在解决日常遇到的问题时，尝试从一个项目的角度去看待问题、尝试用工程方法去解决问题、站在一个整体而不是局部的角度去看问题。
任何问题我们都可以把它看作一个项目，运用工程方法来解决。工程方法会把解决一个问题分为6个步骤：想法、概念、计划、设计、开发、发布。
想法阶段要清晰地定义问题。只有问题定义清楚了，后面才能建立针对性的解决方案。
概念阶段就是使用草图、模型等建立多个概念性的解决方案，并从中选取最优的那个。
计划阶段是根据现有的资源、时间等的限制条件下制定出解决问题的实施计划。
设计阶段是将概念性的解决方案细化，作为分工合作和开发实施的依据和参考。
开发阶段按计划实现细化的设计方案。
发布阶段就是将结果发布，并验证问题是否得到解决。
所有的问题都可以通过以上6个阶段的落实去解决。
但是并不是说不通过这6个阶段就解决不了问题，也许你同样能够解决问题，但所付出的时间、成本、资源就未必能够得到控制。因为没有系统规划，就没有控制。
解决问题的这6个阶段实际上给出的就是一套系统方法。任何一个工程项目，都是一个系统。所谓工程思维，实际上就是系统思维。
而系统思维，还有另一层意思，那就是做工程项目要有大局观。不能因为你在项目中只是承担了需求分析或者测试这样的角色，就只管埋头做需求分析或者测试的工作，而是要有大局观，要看到项目的节点，要为项目的目标服务。
因为如果项目中的每个成员只考虑自己的职责范围，不关注整体，那可能会造成相互间的矛盾和推诿扯皮的现象，就像某些问题讨论会的常见场景那样。这会给项目带来无谓的消耗和成本的浪费。
在GJB5000A评价过程中的访谈节点常常反映出项目经理对项目中的各项软件工程要求比较理解，其他的项目角色，特别是工程组的项目成员，对这些工程要求不太理解。所以，在评价组中也常有这样的争议：
作为工程组的成员是否要了解GJB5000标准？
基于前面的工程思维的观点，项目成员不能囿于自己的角色和职责，而应该有大局观，有项目整体的意识，才不会给项目带来无谓的消耗和成本的浪费。
比如说，QA不理解开发的工作，会打出一些无意义的问题，由此产生争议，影响开发的进度；开发不理解需求跟踪的作用，可能会导致一些需求遗漏，直到后期发现才补充开发……
所以，实施GJB5000就需要每个人都有工程思维，需要每个人都理解GJB5000标准各个过程实施的意义。那些访谈时项目工程组对标准和体系根本不理解的组织，它实施GJB5000的有效性实在存疑。
这正是：
工程并非一人事，须知整体和大局
五千实施应如是，理解标准是根基
联系客服
