软件工程第二课摘要
文章目录
瀑布模型
在第一课[^计算机系统结构]介绍了摩尔定律，在那种指数增长的情况下，整个硬件企业变成了“青春饭行业”，那时最NX的IBM公司，打败了所有的竞争者，最后却败给了时代…
现在也是，新的技术层出不穷，新的框架可以让没有编程经验的人做出很好的项目、成果。
未来有什么是不变的呢，也就是真正值得一学的 ------ 是【基础学科】。
比如，算法与数据结构、设计模式、软件工程、计算机系统结构与组成原理、面向过程与面向对象的思想。
要想写大的项目、或者成为世界上那为数不多能解决复杂问题的大师，就需要学习软件工程；可软件工程是什么呢，我们以画画来举个例子。
一般人画画通常就直接画 — 如画水里的两条金鱼就直接从某一个部分开始，从外形画起来了。
专业画家不是这么画的，他们会把金鱼分解成几个简单的几何图形 — 如头是一个大圆（头）和两个小圆（两个眼睛），身子是一个椭圆，鳍和尾巴是几个三角形。
一般人的画法结果经常是，画到后来比例不对，而且常常画得不像；而专业人士就是画什么像什么、细节特别突出！！！
专业人士又是如何做到的呢 ？？？
百思不得其解，先看看梵高的作品吧（素描）：
问了一下专业人士才明白，他们的画都讲究框架。
这是初中美术书上的《美杜莎之伐》，美术书上还有一副设计初稿：
这副画最高层的构图设计就是俩个金字塔形状，《美杜莎之伐》就是靠着俩个三角形的金字塔，画面保持了平衡。
那么，您再看看梵高的作品，能不能看出什么呢 ？
除了画画之外，我们学习写作不也讲究结构，像总分总等等…
对于编程来说，写一个能够完成特定功能的程序，就相当于是作一幅画、一篇文章。
因此，也有两种写法：
- 边写边改：接到活就直接写代码，虽然也可以做很多小的项目，但一点的项目就不能了。
- 瀑布模型：理解需求之后，抽象出作品需要的基本几何图形，而后用算法将这些模块进行组合，写出符合需求的程序。
【瀑布模型】的诞生，正是为了解决当时的软件危机。
在 1970年，Winston Royce博士借鉴了【建筑工程】，提出了瀑布开发模型，和盖房子的步骤基本一致。
【瀑布模型】：指开发软件也有相应的周期，要像瀑布一样，从上往下，完成一个又一个的阶段。
- （项目经理）【问题的定义及规划】：客户和工程师确定项目是否可行
- （产品经理）【需求分析】：对客户的所有需求详细分析、反复确认，确保真是客户的需求
- （架构师）【软件设计】：按照需求分析的结果，对整个软件系统进行设计
- （软件工程师）【程序实现】：将理论上的设计实现为真实可用的软件
- （测试工程师）【软件测试】：对软件进行测试，确认是否与需求相符合
- （运维工程师）【运行维护】：以后要不断维护、增加功能，保证正常运行
虽然【瀑布模型】简单易行，按照阶段能及时发现问题，可难以响应需求的变更，一定要等到软件测试后，才能发布，按照现在市场来看，基本抢不到用户。
【瀑布模型】就倒像完美主义者，对于建房子这是完全可以的，但软件不行。
如果一定要等到开发好才给客户看，当需求发生改变或者不一致时，这一套流程就做了很多无用功。软件，应该是了解客户需求开始设计，先做一个基本的、粗糙的软件，同时看客户的反馈和需求，再改变，不断迭代。
扎克伯格创业初期，在 Facebook 的办公室墙上贴了这么一条标语：
比完美更重要的是完成。
我们似乎总是没有准备好。知识不够，智慧不够，经验不够，理性不够，时机也总是不对。
如果您看懂了【瀑布模型】，就应该明白很多事情都不在于做的好不好，而是做不做！
哪怕是走在错误的道路上，也不算是完全错的。虽然让人踏上一条谬误的道路，可事实上，真相和谬误永远混杂在一起，真相是从谬误里头赎出来的。
比如，自己设定好一种商业模式，确定了一种产品，拿着这种产品去市场上试，结果市场根本不认账。
普通的创业者可能觉得创业失败了，但真正的创业者会从市场不认账这样一个行为中，一方面感受到自己这个设想的谬误，同时还会从用户的行为、反应和态度中感受到自己产品的某个看似不重要的功能或者价值主张是用户在意的，迅速迭代——这个“同时”如果找到了（部分找到了），就相当于找到了一个藏宝图。
这时候，做出来的产品再拿到市场上去，有三种可能：不被接受、部分接受、完全接受。
如果是第二种和第三种结果，那证明藏宝图已经找到或部分找到了；如果是第一种结果，要继续在用户的反映里发现某种奥妙，看到某种只有细心感受才能感受到的提示，这也是一个迭代的过程。
我们不是要找到某个宝藏，而是开启一条道路，而在这条路上就藏着一个真正的藏宝图（指引追求真理的道路），这个才是真正的宝藏。
如果觉得它是不靠谱、不确定的谬误之路，非要等到确定的道路才走的话，真相跟宝藏就永远跟人是无缘的。
我不知道结局，真的不知道，只是相信。
当您的行为导致的结果被很多人否定、反对的时候，您应该像被投到敌占区的伞兵，在到处是敌兵的地方发现自己的路，而不是投降或者死拼。
需求分析
在互联网时代，用户是一切的中心，真正能够迎合用户需求、解决用户问题的产品，想不成功都难。
那么，如何能够了解用户的需求呢？小灰先给大家讲一个故事：
从前，王大爷在一所大学旁边开了一家小旅馆。小旅馆运营了几个月，生意特别火爆，而且大部分顾客都是那所大学里的男生和女生。
王大爷感到很好奇，有一次就询问两个顾客：
王大爷一听，恍然大悟。
于是王大爷把旅馆房间的床都撤掉了，换上高档的书桌和书柜，还为学生准备了许多好书:
结果，两个月以后，不知道为啥，王大爷的旅馆破产了、破产了…
王大爷听到了用户亲口所说的需求，也积极地去满足用户需求，可为什么会有失败的结果呢？
因为王大爷的思维模式还是传统的商业模式，试图通过问“为什么”来获得用户需求，但这样得到的信息，往往并不是用户的“真需求”。
如果换成一个具有互联网思维的人会怎么做呢？
他会去分析用户的行为，而不是听用户怎么说。
所以，在这个时代想要充分理解用户的需求，不能全信用户的嘴。
男：现在的女孩子都特别懂事，知道男孩子没钱，都不愿意跟他在一起，不想给他添负担；
女：现在的男孩子也特别懂事，一有钱了，就想多照顾几个女生，体贴得不得了；
我：还好长的丑，没经历过各位的爱恨情仇…
转换问题
其实对用户的需求分析，它不是一个简单的、一次性的动作，而是一个动态的过程。
大部分用户提的需求，通常都不是真实的需求，需要通过现象看到本质。
一个计算机科学家的工作是把现实问题【转换为】数学问题，判断这个数学问题是否可计算[^给定输入，经过计算机的有限次计算，能得到一个确定的输出就是 “可计算”。]，如果是，就把数学问题描述成可计算问题；而后就可以用自身的知识来解决了。
同理，理解客户的需求，得学会把【抽象的商业问题】转化【可调研问题】。
问题一旦可调研，就意味着可量化、可执行。
通常是三个方面：
- 小空间：提问 人或部门 自身限制
- 大空间：提问 人或部门 所处行业、使用场景
- 时间层面：需要解决问题的时间周期
比如说，“怎样才能找到理想的女朋友” ？
-
小空间：从自身的角度，“我自己理想中的女友应该具备什么样的特质”；
-
大空间：从女性群体的角度，“如今18-23岁的女性，她们理想的男朋友应该是什么样子”；
-
时间层面：站在当前的时间点，思考自己找女友的目标到底是什么。
从这三个维度去转换问题，就更有可能达到事半功倍的效果了。
如何发现隐藏的需求？
人的真实需求往往是隐藏起来的，特别是关系中的语言。
-
如果她说我裤子皱了，她的意思是：我瘦了，你没发现。
-
如果她看中一样东西，提了很多次，却说太贵了，意思是说：为什么还不给我买？
-
如果她明明不高兴了，却说没事，意思是：赶紧过来，我需要找人倾诉，而你只需要回答：是的，让你委屈了。
-
如果她说太最近累了，记住不是真的累，是你最近关注她太少了，她需要一个大大的拥抱和陪伴。
-
如果她说你真肉麻，记住在她心里希望你多说几句“我爱你”。
如果听不懂也没关系，有一个通用公式：
- “叫宝宝，给抱抱，亲宝宝，喂饱饱，买包包”，最直接有效的关系语言，照做就对了。
关系语言中隐藏的信息倒是很微妙，有很多暗示…可，如何理解用户的需求改怎么理解呢！！！
不通过问“为什么”，获取隐藏的需求方式一般是在这些地方：
- 在场景里
- 在旁人的故事里
- 在细节里：浸入到用户的场景里去
【在场景里】
假如我们的产品是耳机，我们直接问客户，您想要一款什么样的耳机。
用户回答都很理想的，比如音质更好。音质更好，没毛病。可这不是一个可调研的问题，也就不是我们要找的需求了。
我们应该多问【场景】和【感受】。
问：您都什么时候用耳机呢？
答：地铁上。
问：您都听什么呢？
答：音乐。
问：您在地铁上听是什么感受呢？
答：有时候觉得周围太吵，耳机线还经常缠在一起，或者挂在了别人的包上。
那用户真正的需求，应该是：安静、方便的无线降噪耳机。
正是因为所有产品都得进入场景才能发挥作用，所以我们要在【场景】里发掘隐藏的需求。
【在旁人的故事里】
一般当您处在青春期，父母就会问孩子：“xxx，你要没有谈恋爱呀”？
这时候，应该没人会说真话，甚至说也没有喜欢的人。
这时候好多父母都会问，你们班有没有同学谈呀？（这是一个巨大的套路，让孩子觉得再说别人，和自己没关系，一些孩子就会说出真实的感受了）
父母：我太难了，孩子我不想你这么早就恋爱，不是因为考试，我是怕你这么早、这么小就受到那么巨大的伤害。
知道用户不想说，就嫁接到另一个人或者场景里去还原出来。
【在细节里：浸入到用户的场景里去】
根据【局部性原理】找1个或1%的用户，观察他们的一些细节。
找到典型的用户后，去用户家里协商，拍一个微型纪录片。
假如我们的产品是汽车，记录用户TA是怎么买车、用车的、家庭成员、怎么生活、娱乐、出游等等、个人爱好、工作梦想（最好是与关系联系的）。
这会让开发人员有一个共识，原来他们服务的对象是这么可爱，这么打动人的。
那么，我们的工程师无论是在设计上，还是性能上，都会想这样的设计、实现能不能让TA更舒服、更安全一些呢。
通过产品建立的情感共鸣。
复盘：
文章目录
