软件项目管理（软件工程之美总结）

软件生命周期

项目规划

  需求方和开发方共同确定软件开发目标,同时进行可行性研究；

• 经济可行性。从成本和收益角度分析,看投入产出比。不仅要分析短期利益,还要分析长期利益,看是不是值得做。
• 技术可行性。从技术角度分析是否可行,如果有技术上解决不了的问题又能否规避。
• 社会可行性。社会可行性涉及法律、道德、社会影响等社会因素。比如,触犯国家法律的事情肯定不能做;产品如若不符合道德标准,可能带来较大的社会负面影响,那么也要慎重考虑。

需求分析

  对需求方提出的所有需求,进行详细的分析。这个阶段一般需要和客户反复确认，以保证能充分理解客户需求，最终会形成需求分析文档。

• 收集需求:对用户需求进行收集整理;
• 分析需求:对需求进行分析,挖掘用户真实需求;
• 需求评估:筛选过滤掉不可行的需求;
• 需求设计:针对用户需求提出解决方案,设计成产品方案;
• 验证需求:验证方案是否可行。

软件设计

  根据需求分析的结果,对整个软件系统进行抽象和设计,如系统框架设计,数据库设计等等，最后会形成架构设计文档。

架构师如何技术选型？

1. 明确目标或要解决的问题；
2. 技术调研。调研行业中现有的一些解决方案，重点考虑优缺点、社区活跃度、普及度以及代码质量等几个因素；
3. 验证；
4. 决策；

如何项目管理？

  要管理好一个项目，关键是要管理好项目中的人和事。
  项目中的人包括客户和项目成员。对客户的管理，本质是管理好客户的期望值，即软件质量、时间、成本和范围四个因素间的平衡，”金三角“理论可以帮助我们权衡取舍；对项目成员的管理，要做到”法治“，依靠流程规范管理项目成员，单纯的靠项目经理管理，容易出现分歧和瓶颈；
  对事的管理即对软件开发过程的管理，首先选择好开发模型，然后制定项目计划，按照计划推进跟踪，并及时做好项目的风险管理；

软件管理金三角

  一个软件/项目没法发同时实现质量高、时间短、成本低、和功能多的，需要在四个要素间进行取舍。”金三角“理论要求质量不能妥协，在保障质量的前提下，项目管理人员需要在时间、成本和范围之间权衡。
  举例说明，这几年流行的MVP开发模式（一开始只推出最核心的功能,满足用户最核心的需求,然后在用户的使用过程中收集反馈,进一步升级迭代），其实就是在保障时间短、成本低的时候，对范围进行了调整。

流程规范

为什么需要流程规范？

1. 提高团队效率；
2. 好的实践可以标准化流程化、有助于沉淀出工具；
3. 有助于项目管理；

如何制定流程规范？

1. 明确问题；
2. 提出解决方案；
3. 达成共识，推广执行；（最好能工具化）
4. 持续优化，不断改进；

业界好的流程规范

1. 开发模式： 瀑布模式、敏捷开发等；
2. 代码规范： 阿里巴巴Java开发手册、Google Java Style Guide；（个人推荐阿里的Java规范，从编程规约、异常日志、单元测试、安全规约、MySQL 数据库、工程结构、设计规约七个维度详细说明了Java开发的流程规范）
3. 源代码管理流程： Git是目前的主流，基于 Git 的代码管理已经有很多成熟的流程规范可以参考，例如阮一峰老师写过的《 Git 使用规范流程 》、《Git 工作流程》和《Git 分支管理策略》；
4. 部署流程： 持续交付是目前的主流，方便自动化打包、部署、测试等，以及部署规范的实施；

项目计划

如何制定项目计划？

1. 任务分解。任务尽可能的拆分的细，一方面有助于周全方案；另一方面，有助于工作时间的精准评估；
2. 估算时间。为了精准估算时间，一方面，任务要拆分的足够细；另一方面，开发人员参与共同评估；最后，考虑增加一些余量，防止突发事件或者存在未考虑到任务；
3. 排任务路径。根据任务的依赖关系和资源占用情况，排出合适的顺序。避免任务路径过长，尽可能并行进行；

风险管理

什么是风险管理？

  风险管理就是指在项目进行过程中,识别可能的风险,对风险进行评估,并加以监控,从而减少风险对项目的负面影响。

如何进行风险管理？

• 风险识别，识别可能存在的风险
• 风险量化，对风险进行评估量化（概率和损失）
• 应对计划，对风险指定应对策略；对于概率大,后果严重的风险,需要高优先级重点考虑;对于概率不高但后果严重的问题也要考虑,不过优先级略低;对于概率高但后果不严重的风险事件,可以优先级很低或者不考虑;对于概率低后果不严重的,则可以不予考虑。
• 风险监控，对风险进行监控预警

风险分类

• 项目风险:项目预算、进度、用户和需求等方面的问题;
• 人员风险:人员离职、人手不足等问题;
• 技术风险:采用的技术所可能带来的风险;
• 商业风险:与市场、产品策略等有关的商业风险。

常见项目风险

1. 第一版做太多功能 ;
2. 太依赖新技术平台;（技术风险）
3. 与公司另一个有份量的产品竞争;（商业风险）
4. 团队人手不足;（人员风险）
5. 复杂的问题,需要复杂的解法;
6. 成员开始隐藏进度落后的事实和原因;（人员风险）
7. 不断更改、增加的需求 ;（项目风险）
8. 2.0 症候群 - 非要更大、更强、更美 ;（项目风险）
9. 产品没有市场立足点;（商业风险）
10. 你根本无法解决的大问题；

如何应对需求变更？

1. 提升需求确定性,减少需求的变更。这就要求产品经理在需求分析阶段就能对用户需求理解透彻, 比如用原型设计低成本响应用户需求变更，做好需求分析和确认，减少需求变更；
2. 规范需求变更流程,减少需求变更。通过规范变更流程，减少无意义的变更，或者提升变更的成本；
3. 通过提升技术或管理的方式，快速响应需求变更。比如通过灵活的架构设计和强大的配置，或者快速迭代，缩短版本周期；

参考：

1. 极客时间《软件工程之美》