最近在阅读《软件工程之美》，特在此做点记录。
一、项目规划
1）平衡软件质量与时间成本
在软件项目中，需要平衡软件质量（产品的质量，客户的满意度）与范围（需要实现多少功能）、时间（多久可以完成）、成本（花多少钱）四个要素。
- 老板要压缩项目时间怎么办？老板希望时间是 1 个月，也就是说时间这条边被缩短了，那么结果就是会影响到另两条边：范围和成本，如果另外两条边可以调整，也不是不可以。
- 产品经理要临时加需求怎么办？增加需求，也就是范围这条边要增加，那就必然对成本和时间这两条边造成影响，要么延期，要么增加成本。
从时间、成本和范围这三条边中找出来固定的一条或者两条边，再去调整另一条边。
2）可行性分析
对于软件项目的可行性研究，主要从以下几个方面入手：
- 经济可行性：从成本和收益角度分析，看投入产出比。不仅要分析短期利益，还要分析长期利益，看是不是值得做。
- 技术可行性：软件项目最终是需要人通过技术来实现的，所以要分析技术上是不是可行，如果有技术上解决不了的问题又能否规避。
- 社会可行性：社会可行性涉及法律、道德、社会影响等社会因素。比如，触犯国家法律的事情肯定不能做；产品如若不符合道德标准，可能带来较大的社会负面影响，那么也要慎重考虑。
3）项目计划
制定项目计划，通常有三个基本步骤：
- 第一步：任务分解，把复杂的问题拆分成简单的问题，大的模块拆成小的模块，在工程里面这个叫“分而治之”。分割成小而具体的可交付结果，直到不能再拆分为止。
- 第二步：估算时间，有很多方法可以参考，主要还是得依靠以前的经验。要想估算准确需要从两个方面入手：任务拆分的越细致，想的越清楚，就能估算的越准确。要让负责这个任务的人员参与估算。
- 第三步：排任务路径，根据任务之间的关系，资源的占用情况，排出合适的顺序。
有经验的项目经理会在项目启动后，根据制订好的初步计划，确定几个关键的里程碑。
项目管理中，并不是计划制定好了就完事了，还需要跟踪和调整。跟踪进度的方式主要有两种，一种是项目经理定期收集跟踪，一种是项目成员主动汇报。
4）流程和规范
以代码审查的规范为例，对于技术高的程序员来说，代码审查可能会耽误一点时间，但对整个团队来讲：
- 即使是水平高的程序员，也可能会被发现有错误，代码审查可以降低出错的概率，保障质量；
- 对于水平低的程序员，可以通过代码审查学习和成长，代码被高水平程序员审查后，可以有效提高质量。
借助流程规范，让项目管理从人治到“法治”。
好的项目管理，不需要直接管人管事，而是管理好计划和流程规范；项目成员不需要按照项目经理的指令做事，而是遵循计划和流程规范。
制定流程规范的四个步骤：
- 第一步：明确要解决的问题，例如：数据库操作之前先备份数据库，事先写好 SQL 语句，需要有人审查，测试环境先测试通过，最后再生产环境执行，那么就可以避免以后再出现不小心删除数据表的事情发生。
- 第二步：提出解决方案，先思考解决的方法，有了方法后再进一步思考是否能提炼流程规范。
- 第三步：达成共识，推广执行。对于大家都认可、很重要的流程规范，一定要让大家严格遵守，必要的时候需要配合一些奖惩制度，以保障其执行。
- 第四步： 持续优化，不断改进。随着时间推移，可能已经不能符合要求了，也需要考虑改进甚至放弃，不然反而会成为一种阻碍。
5）白天开会，加班写代码
开会其实是有成本的，而且还不低。需要减少开会的成本：
- 砍掉一些没价值的会议。
- 减少参与会议的人。
- 缩短开会时间。
- 提升会议所创造的价值。
6）风险管理
风险是指不确定的事件，一旦发生，将会造成消极的影响。风险包含两个方面的内容：
- 发生后，会造成什么样的损失？
- 发生的概率有多大？
风险 = 损失 x 发生概率。
对软件项目风险的管理，才是体现项目管理水平的地方。我们对比下面几种应对风险的层次来看：
- 被动应对：风险已经发生，造成了问题才被动应对；
- 有备无患：事先制定好风险发生后的补救方案，但没有任何防范措施；
- 防患未然：对可能的风险做出防范，并把风险防范作为项目任务的一部分。
项目中的任务，不能盲目乐观，都思考一下它最坏的结果是什么，如果最坏的结果不能接受，就说明要有个 B 计划，考虑风险管理了。
软件项目风险管理，通常分四步来做。
- 第一步：风险识别，识别可能的风险。软件项目的风险主要分成以下几类：
- 项目风险：项目预算、进度、用户和需求等方面的问题；
- 人员风险：人员离职、人手不足等问题；
- 技术风险：采用的技术所可能带来的风险；
- 商业风险：与市场、产品策略等有关的商业风险。
- 第二步：风险量化，对风险进行评估量化。发生的概率多大？发生后，后果多严重？
- 第三步：应对计划，对风险制定应对策略。
- 回避风险——更改导致风险的方案
- 转移风险——将损失转嫁出去
- 缓解风险——降低风险发生概率或减少可能造成的损失
- 接受风险——明知山有虎偏向虎山行
- 第四步：风险监控，对风险进行监控预警。要做好监控，第一要能对监控的内容量化，第二要设置阈值，第三就是要有后续的报警和处理机制。
7）项目文档
写文档，其实对个人、对项目、对团队，都是非常重要的事情。
- 帮助写文档的人理清楚思路。先写文档，就会抛开代码细节，去站在全局思考。
- 便于未来的维护和交接。
- 便于团队更好的协作沟通。
写文档的时候，主要有几种图比较常用：线框图、流程图、时序图、各种格式的截图。
线框图是最常用也最实用的一种图形，用简单的方框代替功能、模块、服务等，再用箭头表示关系或者数据流向，非常简单直接。要画好线框图并不难，主要是要理清楚有哪些模块，以及模块之间的关系是什么。用方框配上文字表示模块，方框之间的连线和箭头表示关系。
流程图是软件项目文档中一种常用图形，可以方便的表示各种不同条件下的逻辑路径。要画好流程图不难，重点是要理清楚逻辑关系，各个关键节点在不同条件下的走向。
时序图也是软件项目所特有的一种图形，可以表示不同对象之间发送消息的时间顺序，尤其在涉及网络通信的文档中特别常用。画好时序图，关键是要列清楚所有涉及的对象或者服务，以及消息发送的先后顺序。
二、需求分析
1）原型设计
快速原型模型就是，第一阶段确认界面布局和内容，第二阶段确认交互，第三阶段实现。
- 低保真原型设计，产品经理用线框图来代替第一阶段。
- 中等保真原型设计，像 Axure 这样专业的原型设计软件产生，不仅可以反映界面上的布局和内容，还可以展示网站的整体结构和交互。
- 高保真原型设计，对于移动端来说，因为界面比较小，布局和内容上已经没法玩出什么花样。所以客户更追求界面的美观和交互的炫酷，对原型的保真度要求也就越来越高。
2）产品意识
程序员的价值通常体现在两个方面。
- 第一，你的价值体现在你所做的产品之上。
- 第二，你的价值体现在团队中的稀缺性。
那些价值高的程序员通常在技术上或者技术之外都有一技之长：
- 有的程序员能搞定别人搞不定的技术难题；
- 有的程序员擅长培训新人；
- 有的程序员擅长和业务部门沟通；
- 有的程序员能高质量地完成功能模块；
- 有的程序员能按照需求设计好的架构，可以让团队高效率低成本地完成需求。
产品意识，本质就是一种思维方式，一种站在产品角度思考问题的方式。如果细分一下，产品意识包含：商业意识、用户意识和数据意识。
- 商业意识，就是所做的产品是要有商业价值的。商业意识的另一方面其实是成本，成本意识也是程序员容易忽视的。比如说：
- 有时候为了炫技，采用了更难更酷的技术方案，而忽视了所采用的方案会导致很高的开发成本；
- 花了太长时间去开会而忽略了开会的成本；
- 有时候又为了省钱，舍不得买一些成熟的商业组件或服务，反而是浪费了更多成本。
- 用户意识，就是说做产品时，你要能挖掘出用户的真实需求，让产品有好的用户体验。这需要你要有同理心，能站在用户的角度去思考和体验产品。大部分程序员可能更多专注于程序上，所以在用户意识上确实有所欠缺。举例来说：
- 一个产品功能，产品经理在细节上没有定义清楚，程序员可能并不会主动提出，最终做出来的产品会不好用；
- 在做技术方案时，更追求技术炫酷，而不是用户体验更好；
- 在设计接口时，并没有考虑调用者的便利性。
- 数据意识，就是在产品设计、产品运营时，通过数据来发现问题、证实结果。
程序员虽然逻辑很好，但是大多对数据倒是不敏感，对编译警告、测试覆盖率、程序 Crash 的比例、API 错误率、一个函数内上千行代码、性能指标等等这些数据经常选择性忽略。
要培养产品意识，其实和程序员转管理的类似，首先要解放思想，然后要改变习惯，最后要多实践。
- 解放思想，其实就是说，对于程序员，不要总是单纯的用技术眼光看问题，也可以从产品的角度看问题。技术思维会关注用什么技术，关注技术细节，关注功能“如何”实现；产品思维会关注用户体验，关注一个功能所创造的价值，会去思考为什么要或者不要一个功能。
- 改变习惯是是指在日常使用产品、开发产品的时候，多站在产品的角度思考，去思考它的商业价值、用户体验、使用场景等等。
- 不妨在业余时间做个小应用程序，或者设计一个原型，做完了再找你的朋友试用一下，让他们提提意见。在做产品的过程中，你自然会去站在产品的角度去思考，这会让你对产品方面有更多感悟。
3）需求变更
在需求变更这个事情上，没有赢家，每个人都是受害者。
目前也已经有很多管理需求变更的解决方案，比如这两个常见的解决方案。
- 方案一：增强需求变更流程，让需求变更规范起来。
- 方案二：快速迭代，缩短版本周期。
既然需求变更的原因是需求不确定和需求变更成本太低，那么我们就针对性地提出相应的解决方案：
- 提升需求确定性，把需求分析做好，减少需求变更；
- 提高需求变更的成本，让客户或者产品经理不能太容易就变更需求，这样就可以达到减少需求变更的目的。
三、开发编码
1）技术债务
技术债务，就是软件项目中对架构质量和代码质量的透支。
债务的“利息”，就是在后面对软件做修改的时候，需要额外的时间成本。
处理技术债务策略：
- 维持：修修补补，只还利息维持现状，只对严重问题修修补补，这其实是常见的一种策略，就跟还债的时候只还利息一样。
- 重构：新旧交替，分期付款重构相对是一种比较折中的策略，就跟我们采用分期付款的方式偿还贷款一样。
- 预防才是最好的方法：
- 预先投资：好的架构设计、高质量代码就像一种技术投资，能有效减少技术债务的发生；
- 不走捷径：大部分技术债务的来源都是因为走捷径，如果日常能做好代码审查、保障单元测试代码覆盖率，这些行之有效的措施都可以帮助你预防技术债务；
- 及时还债：有时候项目中，因为进度时间紧等客观原因，导致不得不走捷径，那么就应该把欠下的技术债务记下来，放到任务跟踪系统中，安排在后续的开发任务中，及时还债及时解决，就可以避免债务越来越多。
2）软件工程师的核心竞争力
软件工程师的核心竞争力，不是单一能力的体现，而是几种能力和价值的合集。学习能力、解决问题能力和影响力构成了软件工程师的核心竞争力。
- 学习能力：能快速学习掌握编程语言、框架、工具的学习能力才是软件工程师最基础的核心竞争力。
- 解决问题的能力：软件工程师这些日常开发工作的核心还是在发现问题、分析问题和解决问题，在这里我统称为解决问题的能力。
- 影响力：需要通过一点点技术成长的积累，需要通过一个个成功项目的积累，需要通过一篇篇技术文章分享的积累，需要通过一次次帮助其他人成长的积累。而一旦形成足够的影响力，就会变成软件工程师职场发展最牢固的护城河。
3）反面案例
项目管理协会（PMI）认为成功的项目必须满足六个条件：
- 按时交付。
- 成本在预算范围内。
- 能按照当初的设计正常运行。
- 有人使用。
- 满足项目最初的目标。
- 项目出资方对项目满意。
对于一个失败的软件项目案例，要去分析：外部环境、技术管理、项目管理和组织文化，这样才能帮助你找到项目失败的根源。
- 对于商业软件项目，很多是由于缩减成本导致的。因为商业竞争的大环境，企业为了节约成本，总是希望用更少的人做更多的事情。
- 在项目中使用了不成熟或不熟悉的技术，最终导致技术不可控，或者浪费大量的时间在技术的学习上。
- 项目经理掌握了资源的分配，还要制定项目的计划，对任务进行分配，组织分工协作，管理风险，项目成员的日常沟通等等。一旦这些决策出现大的失误，就会导致项目的失败。
- 在软件项目中，一个开放、平等、注重沟通协作的团队或组织更容易及早发现和解决问题。
如果细化一下，还可以总结出一些具体的常见的失败原因：
- 不切实际或者不明确的项目目标；
- 对项目所需要的资源估算不准确；
- 需求不明确或者频繁变更；
- 没有对风险进行有效管理；
- 和客户之间沟通不畅；
- 无法解决项目的复杂性；
- 没有好的开发实践；
- 糟糕的项目管理；
- 上层的政治斗争；
- 商业压力。
posted on
