02 工程思维：把每件事都当作一个项目来推进
你好，我是宝玉。我今天分享的主题是：掌握工程思维，把每件事都当作一个工程项目来推进。
我大学学的是软件工程专业，毕业十多年后再回顾当年学的专业课，好多专业概念已经记忆模糊，唯有对一位老师的教诲记忆深刻，对我毕业后的职业生涯影响深远：
软件工程是一门用工程化方法解决软件项目问题的学科，其本质也是一门工程学科，这门课的知识在学完后，不仅可以应用在软件项目中，还可以应用于日常生活中遇到的一些问题，Everything is a project。
这句话对我影响很大。我真的开始在日常生活中尝试应用“Everything is a project”的概念，小到做作业，大到完成工作中的复杂项目。
解决这些问题的方式，就是参考软件生命周期和瀑布模型，把一件事情分成几个阶段：分析、设计、实施、测试、完成，然后制定相应的计划。这种方法不仅非常有效，让我的做事效率大幅提高，而且让我在看待事情上，能够更全面地、站在更高的角度去思考。
2010年在上海的时候，我机缘巧合参加了一个关于产品设计与用户体验的线下活动，我可能是与会人员中，为数不多的非专业产品设计的同学。
在活动中组织者安排了一个游戏环节，每5个或6个人分成一个小组，来设计一个给老年人使用的手机，限时30分钟。完成后，每组选一个人上台花5分钟展示作品，最后投票选出做得最好的一组。
我的第一反应就是把它当作一个项目，于是快速地拟定了如下计划。
- 0~10分钟（分析）：头脑风暴，收集想法。
- 11~15分钟（设计）：根据头脑风暴结果，确定最终设计。
- 16~25分钟（开发）：将想法画在纸上。
- 26~30分钟（发布）：完善结果，准备展示。
这个计划小组成员都很认可，于是我们严格按照这个计划进行手机的设计。同时我观察了一下其他组的情况，大家都在热火朝天地讨论各种想法，似乎没有意识到时间其实是有限的。
轮到演示的时候，我们组毫无争议地拿到了第一，因为我们不仅准备充分，而且设计的手机功能完整，而其他很多组甚至还没来得及把想法完整地画下来。
什么是工程方法？
后来我才了解到，这种有目的、有计划、有步骤地解决问题的方法就是工程方法。工程方法不是软件工程独有的，几乎所有工程类别都可能会应用，例如建筑工程、电子工程等，只不过步骤可能略有不同。
工程方法通常会分成六个阶段：想法、概念、计划、设计、开发和发布。
- 想法：想法阶段通常是想要解决问题。最开始问题通常是模糊的，所以需要清晰地定义好问题，研究其可行性，检查是否有可行的解决方案。
- 概念：概念阶段就是用图纸、草图、模型等方式，提出一些概念性的解决方案。这些方案可能有多个，最终会确定一个解决方案。
- 计划：计划阶段是关于如何实施的计划，通常会包含人员、任务、任务持续时间、任务的依赖关系，以及完成项目所需要的预算。
- 设计：设计阶段就是要针对产品需求，将解决方案进一步细化，设计整体架构和划分功能模块，作为分工合作和开发实施的一个依据和参考。
- 开发：开发阶段就是根据设计方案，将解决方案构建实施。开发阶段通常是一个迭代的过程，这个阶段通常会有构建、测试、调试和重新设计的迭代。
- 发布：将最终结果包括文档发布。
如果你用这六个或者其中几个阶段对照日常工作和生活中遇到的问题，会发现绝大部分问题都可以看成一个项目，并且拆分成几个阶段，按照计划一步步完成。
站在整体而非局部去看问题
可能会有人说：“我不用这种工程方法去做事，一样可以做成呀，并没有什么区别。”确实，做一件事有很多种方式，但用工程方法去处理事情，有两点好处：
- 有一个被有效论证过的方法论指导你，可以帮助你提高成功概率，也可以提高效率。
- 当你用工程方法去思考的时候，你会更多的站在整体而非局部去思考，更有大局观。
前面提到的“设计一个老年机”的游戏就是个很好的例子，后来我在不同场合、不同人群中都组织过这个游戏，无论我如何强调时间限制（30分钟）和产出（必须要演示结果），绝大部分人还是会把时间和注意力放在各种稀奇古怪的想法上，并沉浸其中。等到时间快到了，他们才发现还来不及把方案画到纸上，甚至还没确定该选哪个方案。
这种现象其实很常见，我们在日常处理事务时，天然地会选择自己感兴趣的、擅长的那部分，而容易无视整体和其他部分。
所以问题的核心并不在于是不是用工程方法，而是有没有把这件事当作一个项目，是不是能看到这件事的全貌，而不是只看到局部。
在工作分工越来越细致的今天，一个项目里面有产品设计、开发、测试、运维等诸多岗位，每个岗位都有自己的价值追求，测试人员关注找出更多Bug、开发人员关注技术和高效开发功能、运维关心系统稳定。
分工带来的好处，就是复杂的任务可以分给不同的人来做，这也有助于技能的专业化，提高工作效率。但如果只站在自己的立场去考虑问题，没有人关注整体价值，就容易相互误解，产生矛盾、增加成本。
以下这些工作场景，估计你不会陌生。
- 产品经理提出一些天马行空、不切实际的需求，而技术上不可行或者实现成本很高，导致最后返工，造成资源浪费和进度延迟；
- 架构师为了满足开发上的成就感，更愿意自己“造轮子”，而不愿意采用现有开源程序或者购买合适的组件；
- 开发工程师喜欢在代码中使用各种设计模式或者最新技术，导致项目进度延迟，代码难以维护；
- 测试工程师不愿意学习自动化测试技术，导致测试周期较长，且容易出现疏漏；
- 除非产品经理特别注明，开发工程师和测试工程师不会注意用户体验上的细节。
这样的场景问题还有很多，为什么会出现这种情况呢？事实上，这在很大程度上都归因于大家只是站在自己岗位的角度来看问题，没有站在项目的整体角度来看。
如果能站在项目整体来看问题，你就会去关注项目的质量、项目的进度、项目的成本、项目的最终用户，那么上面这些场景将变成：
- 为了项目整体的效率和避免返工浪费，产品经理会及早和开发人员确认技术可行性，并对产品设计先行验证；
- 为了节约项目开发成本，提高开发效率，架构师选择成熟的架构，合理购买商业组件和使用开源程序；
- 为了提升开发效率，不影响项目开发进度，开发工程师尽可能采用成熟的技术，高效简洁地落实项目；
- 为了项目质量和效率，测试工程师学习自动化测试技术，将大部分测试变成自动化运行，极大地提高了测试效率和质量；
- 为了让用户有好的体验，不仅产品经理，每个人都会仔细体验用户界面，对于不合理的地方提出改进意见。
看起来很理想化对不对？但如果大家真能从自己做起，这样的结果并不是太难达到。
肯定有人会想，我又不是项目经理，干嘛要操这心呀？在这个问题上，我的看法是：每个项目成员，如果能多站在项目的角度去考虑，那么这样不仅对项目有利，更对自己有好处。
项目做成了，大家脸上都有光，也得到了更多的锻炼；项目没做成，不仅脸上无光，甚至可能面临丢工作的危险。很多人都有技术升管理的理想，能多站在项目整体角度去考虑的人，在日常工作中，也一定会有更多的锻炼机会，自然会多一些提升的空间。
我把这种思维方式称为“工程思维”。如果给一个定义的话，工程思维，本质上是一种思考问题的方式，在解决日常遇到的问题时，尝试从一个项目的角度去看待问题、尝试用工程方法去解决问题、站在一个整体而不是局部的角度去看问题。
在我的职业生涯中，一直习惯于用“工程思维”去思考问题，遇到问题，会尽可能把它当成一个项目，用工程方法有计划、有步骤地去解决它，这让我积累了不少的工程方法实践经验。
同时，我也更多站在整体的角度思考，这让我在项目中能更好地和其他同事合作，有更多的晋升机会。我还记得，我第一次开始管项目的时候，并没有慌张，而是把项目任务按阶段一拆分，然后按阶段制定好计划，再按照计划一点点执行、调整，很快就上手了项目管理的工作。
总结
改变，最有效的是方式是改变思想，这往往也是最难的部分。
当你开始学习这个软件工程专栏，我希望你不仅仅学到软件工程的理论知识，更希望你能用“工程思维”来思考你遇到的各类问题。
你不需要现在是一个项目经理或者管理者，也一样可以在日常生活中应用“工程思维”。比如学习这个专栏，你会制定一个什么样的计划？每个阶段达到一个什么样的成果？比如你今年有没有去旅行的计划？你会怎么制定你的旅行计划？
如果有兴趣的话，你还可以看看我以前写过的一篇文章“记录下两个孩子在MineCraft里面还原公寓的经历”。
这也是一个很有意思的工程思维实践，帮助孩子们在游戏里面还原公寓。这本质上也是一个项目，需要制定计划，需要设计、实现。我希望他们从小就有工程思维，能在未来有目的、有计划、有步骤地去解决日常生活的问题。
课后思考
最后，我希望你思考一下，你在日常生活中，会不会习惯上把一些事情看作项目？或者你看完这篇文章后，有没有觉得有一些事情可以看作项目？你会怎么应用工程方法来实践？
此外，在你参与的项目里面，你会站在项目整体的角度来考虑一些问题吗？你觉得如果站在项目整体的角度看，是不是可以对你的工作方式有所调整？欢迎你在留言区分享讨论。
感谢阅读，如果你觉得这篇文章对你有一些启发，欢迎把它分享给你的朋友。
- javaadu 👍（74） 💬（1）
1.做任何事情都要按照一定的理论指导来，例如，依靠系统化、结构化的“工程思维”，将生活和工作中的每个事情都看做一个项目，可以提高做事的成功率和效率，虽然不用这些理论指导也能做成事情，但是相对来说是偶然性的，不是常规性的。这就是常说的认知（意识）先行，持有高级的认知去跟低认知的人竞争，是一种降维打击。 2.工程思维的核心有两点：系统化，也就是全局观，要从站在整个项目的高度去看问题，不能做井底之蛙；结构化，也就是有步骤、有节奏得做事情的意识。 3.《软件工程之美》这个专栏，我给自己定了一个小目标：全部跟完，并且坚持留言跟老师交流想法。我制定了简单的阅读步骤：（1）文章至少阅读两次，第一次通读，第二次做笔记摘抄、整理文章的思维导图、提出自己的想法；（2）整理自己的学习心得，形成阅读笔记发到自己的博客（公众号）上 4.课后思考：我今年年初开始运营自己的公众号，我把它当做一个项目，就从下面几个方面进行了思考：我要提供的内容和定位是什么样的、我的用户是谁、我应该如何去运营；这些东西想好后，我就将要做的事情拆分为：公众号设置、文章内容输出、运营推广三块，然后按照一定的步骤去执行，现在公众号的设置已经基本完成，整个项目进入内容输出和运营推广的循环中了。站在项目的角度去看这个问题，可以让我在动手执行的时候更有方向感和节奏感，也会对自己清楚自己某个小的点做的改动会对全局产生什么影响；在没有使用这个角度去看问题之前，我只是简单得主张内容才是核心，但是不懂运营和推广，没什么章法。
2019-02-26 - 西西弗与卡夫卡 👍（25） 💬（2）
结合隔壁郑晔老师的《10×程序员工作法》中提及的“以终为始”、“任务分解”，工程思想真是无处不在
2019-02-26 - 拉欧 👍（15） 💬（1）
感觉工程思维是我现在欠缺的部分，做IT时间越久，越发现成事的可能存在于编码之外
2019-02-26 - 起而行 👍（13） 💬（1）
比如留学申请。项目思维的两个关键在于 1.主意局部任务与总体时间的关系 2.用熟悉的办法解决问题 1.在距离留学申请还有两年的时间，可以先做不确定性强，见效慢的事情，不是不重要，而且短时间内会来不及。比如未来职业规划，兴趣的培养，长期的科研与项目。 等到了申请还有半年的时候 要注意局部的任务与总体时间的关系。那么确定性不强的任务效果将不会特别好，而刷语言考试的成绩，这种确定性强，时间可控，反馈见效相对快的事情就要提上日程。 2.用熟悉的办法解决问题。在留学，这种高度信息不对称的领域，可以自己试着了解前人经验，但我认为，专业的事情给专业的人去做，那么找中介辅助申请就是个好的主意
2019-03-01 - Being 👍（9） 💬（1）
应对即将面临的考试，工程思维会帮大忙啦。先分析考试大纲，明白考的范围，定位重难点，设计一套一个半月的复习方案，适应自己的作息安排，接下来就是按计划复习，最后面对考试，就是交付知识的时候了。
2019-02-27 - Felix 👍（7） 💬（1）
机会都是留给有准备的人的，晋升管理的机会就是留给有工程思维的人的，好的技术管理一定是掌控全局的人
2019-02-28 - 女巫在寒江 👍（6） 💬（1）
我现在就是按老师提的做法去做的，把家庭、工作还有自我提升的事都当作项目来做后，感觉生活有掌控感多了 每个项目我会先做一个分解，大概需要哪些阶段，流程是什么，需要准备什么，需要谁协助，然后再继续分解成多个可以执行的步骤，定好时间点去跟踪，同时自己定期去监视各个项目的进度，这里我用的是甘特图查看，如果发现有些超前了，该项目就可以暂缓，把精力放到其他延迟的项目中去
2019-03-02 - 蜗牛 👍（5） 💬（1）
感觉自己之前做任何事情都没有章法，觉得只要做了就可以。通篇学完之后，知道自己哪里欠缺，应该怎样去学习及工作。谢谢宝玉老师！
2019-02-27 - 花灰 👍（4） 💬（1）
最近在准备换工作，借学习分析一下 分析：用一周时间，结合自己目前状况和找朋友了解，分析自己擅长什么、那些地方做的好那些不好… 设计：1天，划定自己的求职目标和方向 实施：3天，准备简历 测试：1个月、面试-复盘-修改简历-面试 完成：入职，每半年更新一次简历
2019-09-09 - Sudouble 👍（3） 💬（1）
结合以前看的关于批判性思维的内容和今天的内容，意识到思考的重要性，是时候对思维方式进行一个重要的关注了。everything is a project!
2019-03-02 - Noya 👍（2） 💬（2）
要培养工程思维, 考虑问题多用工程的角度看问题
2020-03-19 - hyeebeen 👍（2） 💬（1）
非常赞同“一切即项目”的思考模式，作者经历的培训活动我也经历过，确实在时间意识上会比没受过工程训练的人强一些，并注意过程控制。 ps：学习自动化测试其实不等于一定能缩短测试周期，“测试周期”的定义如果是测试独占的项目时间段的话，可以通过测试前移，加强自测，契约优先的接口自动化测试等来缩短独占时间。没有系统或者不够工程化的自动化测试脚本，反而会增加测试时间。
2019-03-14 - 梅同学 👍（2） 💬（1）
问题： 1. 如何指定有效可行的项目计划 2. 如何把项目计划有效的传递给开发人员，包括：开发思路，开发进度 3. 有哪些有效的辅助工具 方法： 带着问题看每一篇文章，总结收获 验收: 回答上述问题
2019-03-09 - 雷霹雳的爸爸 👍（2） 💬（1）
纯感谢
2019-03-08 - alva_xu 👍（2） 💬（1）
工程方法就是有目的、有计划、有步骤地解决问题的方法，而工程思维就是用工程方法解决问题的思维模式。这种思维模式，首先要求有全局观。而事实上，由于工程中的不同职责分工，导致各个角色有可能只从自己的分工角度去考虑问题，这实际上是软件工程中最大的障碍，也是传统的CMMI（过程域的规范化）、现在的DevOps和敏捷方法想要去解决的问题。正如《凤凰项目》中的观点，既要有自左向右的工作流，又要有自右向左的反馈流。通过人员和组织（自组织）的调整、工具和技术（CICD工具）的使用以及流程（Scrum等敏捷工作流程）的推广，确保整个工程项目不会被不同角色割裂开来，从而确保工程的实现。
2019-03-02