《软件工程之美》打卡第三周
这是笔者参加极客时间21天打卡行动第三周，三周的时间无间断刚好21天，这21天里我强迫自己每天都要学习半个小时并写100个字的分享，正是这样的自律让我找回以前的那种感觉，真的好久没这样认认真真做一件事情了。话不多说，下面是本周每日学习总结记录：
第十五天
今天学习了宝玉老师的《软件工程之美》中的“13 | 白天开会，加班写代码的节奏怎么破？”，以下是我的总结：
这节课的内容我感受不是很深，如果是正常的需求迭代，目标还是比较明确，所以不会存在太多无意义的开会。不过这个主题有一点我是比较认同的，就是开会是有成本的，而这个成本就是每个人员的单位时间成本。所以这个给我们提了个醒就是，开会必须是有价值的，而这个价值必须大于我们的成本，不然就造成浪费了。
那么怎样的会议是高效的？有以下几点：
- 参会人员少
- 时间短
- 议题和目标明确
例如每日站会就比较符合这样的标准。
既然开会有成本，怎么降低开会的成本？
-
没价值的会议不开
无目标、无法形成决策和行动指导的，跟你无关的基本可以砍掉。
-
减少参与会议的人数
只有相关人参加，容易达成一致目标。
-
缩短开会时间
限定讨论的范围，不做无意义的发散，事先有准备，把握节奏。
-
提升会议创造的价值
明确目标和主题，围绕会议目的展开。如果会议内容跟自己无关紧要又必须参加，可以寻找其他能在会议做的事情来减少时间的损耗。
第十六天
今天学习了宝玉老师的《软件工程之美》中的“14 | 项目管理工具：一切管理问题，都应思考能否通过工具解决”，以下是我的总结：
这节课说的管理问题主要是软件项目中困扰项目经理和开发人员的一些问题，比如任务进度量化的问题，项目进展不够直观，项目经理需要耗费很大的精力去做任务管理等。
项目管理工具软件发展史
阶段一：没有工具的年代
去管理项目确实是非常耗费精力，比如阿波罗项目，需要专业人士花大量时间和精力去制定计划和调整计划。
阶段二：项目计划工具
在瀑布模型为主软件项目，才出现了相对容易制定计划的项目计划工具，比如微软的MS Project，但存在不方便跟踪任务进度，进度不直观的缺点。
阶段三：基于Ticket的任务跟踪系统
传统项目计划工具不能解决具体的任务跟踪状态，后面才有了基于Ticket的任务跟踪系统，从用来跟踪bug逐步衍出跟踪需求和开发任务等功能。但缺点是不能直观看到哪些任务的状态。
阶段四：基于看板的可视化任务管理
可以很直观的看到不同的任务处于什么状态，项目经理和项目成员都可以很直观看到进展。
第十七天
今天学习了宝玉老师的《软件工程之美》中的“15 | 风险管理：不能盲目乐观，凡事都应该有B计划”，以下是我的总结：
风险管理的重要性不容忽视，如果软件项目没有做风险管理，造成的后果轻则项目不能按时完成，重则造成无法挽回的经济损失，拼多多被“薅羊毛”事件就是风险管理不到位的典型案例。
应对风险的几个层次：
- 被动应对：风险已经发生，造成了问题才被动应对；
- 有备无患：事先制定好风险发生后的补救方案，但没有任何防范措施；
- 防患于未然：对可能发生的风险作出防范，并把风险防范作为项目任务的一部分。
做好风险管理需要做好以下几点：
- 培养风险意识
不能盲目乐观，思考最坏的情形，提前做好Plan B。 - 管理风险
管理风险有四步：
2.1 风险识别
软件项目的风险有以下几类：
- 项目风险：项目预算、进度、用户和需求等方面问题；
- 人员风险：人员离职、人手不足等问题；
- 技术风险：采用技术所可能带来的风险；
- 商业风险：与市场、产品策略等有关商业风险。
可以按照上面的分类整理出自己的风险检查表。
2.2 风险量化
风险发生的概率和发生后后果的严重程度，概率大和后果严重的应该以优先级去重点考虑。
2.3 应对计划
一张图解释如何应对风险，我们可以根据实际情况来选择应对策略，减少可能的损失。
2.4 风险监控
要做好监控，有以下三点：
- 第一要能对监控内容良好
- 第二要设置阈值
- 第三要有后续的报警和处理机制
这就就比如我们会监控线上版本的Crash率，设定告警的阈值，比如2%，超过这个阈值我们就告警，相关开发人员要及时处理线上的Crash，通过热更新解决Bug来将Crash率维持阈值以下。
这个主题其实开发人员感受可能不会很深，我们日常更多是基于需求去评估单个需求完成可能存在的风险，比如技术选型和人力成本这些方面去考量，但对项目整体来看，要把需求都变得可控，所以风险管理就很重要，如果前期评估出了风险，可以通过砍需求或者延长时间来降低风险。但对于开发人员如果能全局去培养自己的风险意识，这样能很大程度帮助团队一起规避不必要的风险，防患于未然。
第十八天
今天学习了宝玉老师的《软件工程之美》中的“16 | 怎样才能写好项目文档？”，以下是我的总结：
我个人是比较偏向写文档的，很多程序员不愿意写文档，无非就以下几个原因：
- 不知道怎么写
- 太忙没时间写或者懒得写
- 觉得文档无用，价值不高
从这篇文章学习的内容，更加坚定了我对写文档的重要性的态度：
- 文档能够帮助自己理清思路
- 方便未来的维护和交接，最明显的是新人可能更快的融入团队，减少口口相传
- 团队更好的协作沟通
如何写好文档？
- 从模仿开始，参考别人是怎么写的
- 从简单开始，不要求一下子写大而全的文档
- 从粗到细，迭代更新
- 一图胜千言，能用图说明清楚的就不用文字，常用的有线框图、流程图、时序图、各种格式的截图等。
这一节我感受比较深，因为最近我也在帮助团队整理项目文档，因为我作为新人加入项目基本知道我缺什么东西，需要了解什么东西，如果之前有文档估计我可以更快融入团队和发挥自己的价值。
第十九天
今天学习了宝玉老师的《软件工程之美》中的“17 | 需求分析到底要分析什么？怎么分析？”，以下是我的总结：
这节课的信息量很大，需求分析说实话工程师参与的并不多，更多是产品经理将需求分析过后的翻译成我们能够理解的需求单。需求的重要性不用多说，只有真正理解用户的需求，我们才能做出触及用户内心诉求的产品。宝玉老师这节课提到了很多让我很受益的知识和观点，比如做需求分析的一些步骤：
- 收集需求
- 头脑风暴
- 用户调研
- 竞品分析
- 快速原型
- 分析需求
- 表层需求：用户对解决问题的期望
- 深层需求：用户的深层动机，诉求产生的原因
- 底层需求：人性本能的需求
- 需求评估
- 可行性：技术能否实现
- 成本：人工成本、时间成本
- 商业风险和收益：有没有商业的风险，收益是否合理
- 紧急性与重要性：是不是用户迫切的需求
- 评估其优先级：紧急重要四象限
- 需求设计
- 验证需求
在日常工作中，其实产品最终效果不明显很大程度就是没有做好需求分析，没有深入理解真实的用户需求，一种好的基于数据验证需求实践——AB Test，通过数据驱动来分析需求。
第二十天
今天学习了宝玉老师的《软件工程之美》中的“18 | 原型设计：如何用最小的代价完成产品特性？”，以下是我的总结：
原型设计经历了三个阶段：
- 低保真原型设计
- 中等保真原型设计
- 高保真原型设计
目前原型设计已经从一种快速开发模式演进成了设计工具，产品经理可以低成本、高效率的做出软件原型，便于更好的确认产品需求。
**如何做好原型设计？**分为以下四个部分：
- 分析：原型设计的目标是什么，搞清楚用户的需求
- 设计：从信息架构和使用流程两个维度去考量
- 实施：在设计的基础上通过原型工具进行界面搭建
- 验证：产品经理反复验证流程，调整存在走不通或者使用不方便的地方进行调整。
选择合适的原型设计工具的几个考虑维度
- 面向的平台：Web、桌面、手机；
- 保真度：
- 中等保真度还是高保真度；
- 功能：是否满足你的要求；
- 成本：价钱是否可以接受。
宝玉老师推荐了几款原型设计工具，可以结合自身的需求来选择：
- Axure RP
- 墨刀
- Adobe XD
- ProtoPie
- Framer X
这节课内容更偏向产品设计，开发人员可能日常比较少参与原型设计，不过作为一个有追求的程序员，提升自己的产品设计能力也有助于我们用产品的视角来看待用户需求，也能更好的跟产品经理进行沟通协作。
第二十一天
今天学习了宝玉老师的《软件工程之美》中的“19 | 作为程序员，你应该有产品意识”，以下是我的总结：
这节课很值得所有程序员都学习一下，里面的理念跟我一直贯彻的不谋而合。程序员的价值体现在两个方面：
- 体现在产品之上
- 团队中的稀缺性
程序员的价值不在于技术水平，而是通过技术给产品进行赋能。
产品意识是很多程序员都欠缺的，因为他是一种思维方式，需要站在产品角度去思考问题。产品意识包含：
- 商业意识（ 产品需要有商业价值，简单来说是能赚钱）
- 用户意识（良好的用户体验，有同理心）
- 数据意识（数据驱动去发现问题和验证结果）
培养产品意识宝玉老师提到：
- 首先要解放思想，从产品角度分析产品，关注用户体验，关注功能所创造的价值
- 然后改变习惯，从关注技术细节转变成关注用户体验，关注产品创造的价值、使用场景等
- 最后要多实践，业余实践做些原型，收集用户的使用意见，感受产品视角带来的感悟
最后
21天的打卡行动，就在春节的大年初二完成了，打卡虽然结束，但学习行动并未结束。软件工程之美这个专栏是今年的第一个学习专栏，很有价值，里面是宝玉老师的经验之道，也提供了很多术和器。学习真的贵在坚持，打卡虽然是个很傻的事情，但我们总是高估了自己自律性，而低估了自己的惰性。下周我们继续不间断打卡，直到完成今年的Flag。
欢迎关注我的公众号：巫山老妖
