《软件工程之美》—— 项目规划

项目开始之前有很多准备工作需要进行，可行性研究、项目计划、风险管控、流程规范的制定，选择合适的工具对项目整体进行管控。除此之外，还要树立正确的认知，避免感性奔走。

技术可行性
技术是否可行，关键还是在人。技术本身需要考虑两个方面：成熟度和覆盖面，对于不能解决的问题能够规避。

2、项目计划

A：既然飞机老是晚点，还要时间表干嘛br> B：没有时间表，你怎么知道飞机晚点了呢/p>

看到这里有一点脸红：
见过很多人抱怨项目经理制定的计划有问题，却很少看到会有人愿意主动参与制定项目计划。如果你不主动参与计划的制定，最终就只能按照项目经理的计划执行了，出现计划不合理的地方，你也只能接受，工作就会一直很被动。

其实大部分情况下，计划出炉后，都会问大家的意见，然后鸦雀无声。欸~工作中好多抱怨的声音是不是其实是事后为自己的**“怂”**哀嚎们有好多可以为环境的改变发力的时候，当时怂，后来抱怨，真的是过粪了。

当然制定计划也不是那么简单啦，需要有步骤地去多方考量。

2.1、如何制定计划

制定项目计划，通常有三个基本步骤：

• 任务分解
• 估算时间
• 排任务路径。

1、任务分解
WBS（Work Breakdown Structure）：把要做的事情，按照一个树形结构去组织，逐级分解，分割成小而具体的可交付结果，直到不能再拆分为止。
在制定计划的时候，除了要拆解任务，还要反复思考各种存在的问题。对技术细节不清楚的地方，要寻求技术人员的帮助。

2、估算时间
主要是靠经验，要想估算准确，需要从两个方面入手：

• 任务拆解越细致，想的越清楚，就能估算的越准确。
• 要让负责这个任务的人员参与估算

沟通最好的方式就是倾听和恰当的提问。

3、排路径
根据任务之间的关系，资源占用情况，排出合适的顺序。

2.2、设置里程碑

里程碑是承诺，不能轻易改变。
Deadline是第一生产力。
里程碑完成后，获得正面激励。

2.3、计划的跟踪调整

两种方式跟踪进度：

• 项目经理定期收集跟踪
• 项目成员主动汇

好的实践：

• 每日站立会议
• 看板

3、风险管理

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

风险包含两个方面的内容：

• 发生后，会造成什么损失
• 发生的概率有多大

做好风险管理可以分四步来做。

软件项目的风险主要分成以下几类：

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

建议：定期针对风险问题开一些头脑风暴会议，一起发现可能的风险。让项目成员有合适的渠道来反馈可能发生风险的问题。

3.2、风险量化

风险识别出来之后，需要从两个方面去评估：

• 发生的概率
• 后果的严重程度

划分优先级来制定策略。

3.3、应对计划

针对量化后的风险，主要分成以下几个策略：

MS Project缺点：不方便跟踪任务进度、进度不直观。
俺的结婚计划就是用MS Project，任务分解的时候很爽，但是因为没有同步协作，所以开始准备后就丢在一边没用了。

5.2、基于Ticket的任务跟踪系统

Ticket跟踪最早源于客服的工单系统，每次客服接到一个问题，就创建一个工单，后续和客户的每一次交流和处理，都要更新工单内容和状态，直到结束。
一个Ticket应该包含的信息如下：

• 标题：摘要性地描述Ticket内容
• 类型：属于什么类型的Ticket：Bug、需求、任务
• 内容：Ticket的详细内容。如，bug的话，包含bug内容和重现步骤
• 创建人
• 优先级
• 状态：未开始、处理中、已解决、重新打开、关闭等
• 指派给谁
• 历史记录

利用燃尽图可以直观的预测工作将在何时全部完成。
缺点：整体Ticket状态不是很直观，不能清楚看到哪些任务在进行中

5.3、基于看板的可视化任务管理

通过看板可以很直观地看到当前任务进展情况。

5.4、工具的选择

项目计划工具：MS Project（windows）、OmniPlan和Merlin Project（Mac）
基于Ticket的任务跟踪系统：Jira、Azure DevOps、Github的issue
国内同类产品：

站在更高一点的角度来思考会冷静些，哈哈哈
不一定要转管理，但是大局观的思维转变，于个人也是有莫大的好处的。

6.2、如何管理软件项目

软件项目的管理分两个维度：管好人和管好事。

当然，评论区的宝玉老师依旧可爱~

8、如何写好项目文档

程序员不喜欢的事：

• 不喜欢写文档
• 不喜欢项目文档太少

哈哈哈，笑了

为什么要写文档

• 帮助写文档的人理清思路：先写文档，就会抛开代码细节，去站在全局思考。
• 便于未来的维护和交接
• 团队更好的协作沟通

写文档最大的障碍是没想清楚，在心中只有一些未成型的混乱的想法和概念，必须要尼禄吧这些模糊的想法确定化和具体化，才能写出来。

如何写好文档
首先对文档要有一个正确的认识：文档写作，关键是通过文档把想法表达出来，至于用词、格式都是相对其次的。
有一些具体可行的文档写作方式可以借鉴：

• 从模仿开始
• 从小文档开始
• 从粗到细，迭代更新：先列提纲
• 掌握一些基本的画图技巧，使用截图

关于文档的建议：

• 文档很重要，但是工作的软件高于详尽的文档，平衡很重要
• 不需要为代码写很多文档，好的代码格式，良好的注释，完善的单元测试可以很大程度上替代针对代码而写的文档。
• 在线工具优于离线文档工具。在线工具有很好的版本管理，方便多人协作。
• 文档也应该作为项目任务放到计划中。

第二遍快速读完，第一条总结就是，树立正确的认知，先冷静分析，会更加不容易被卷入自己的小世界。