Part3 项目规划篇

09 | 为什么软件工程项目普遍不重视可行性分析？

可行性分析维度

• 经济可行性

• 技术可行性

• 社会可行性

哪怕你做的可行性研究不能改变决策，最后项目结束的时候，和当初做的可行性研究做一下对比，也都是非常宝贵的项目经验积累。

10 | 如果你想技术转管理，先来试试管好一个项目

管理，最重要的一点就是大局观，要能从整个项目的角度，从整个团队的角度去思考，去确定方向，去发现问题，对问题及时解决及时调整。

就软件项目管理来说，“道”就是管好人、管好事。

怎样管好软件项目中的人？

1. 管理好客户的预期（质量达标、完整交付、按时交付、预算之内）。

2. 用流程和规范让项目成员一起紧密协作。

好的项目管理，不需要直接去管人，而是管理好流程规范；项目成员不需要按照项目经理的指令做事，而是遵循流程规范。

怎样管好软件项目中的事？

1. 选择适合项目的开发模式

2. 制定好项目计划

3. 对计划进行跟踪和控制，同时做好风险管理

管事理人.jpg

技术转管理的一些经验教训分享

• 控制你想写代码的冲动

• 团队的成功，才是你的成功

• 形成自己的管理风格

• 坚持就是胜利

11 | 项目计划：代码未动，计划先行

没有计划，你的项目可能会陷入一种无序和混乱中。

如何制定计划？

1. 任务分解
   WBS（Work Breakdown Structure）把要做的事情，按照一个树形结构去组织，逐级分解，分割成小而具体的可交付结果，直到不能再拆分为止。
2. 估算时间

• 任务拆分的越细致，想的越清楚，就能估算的越准确。
• 要让负责这个任务的人员参与估算。通过沟通，消除偏差。

3. 排路径
   依赖关系、路径长度、关键路径、并行、避免等待。

设置里程碑

Deadline 是第一生产力。

里程碑完成团队能获得正面激励。里程碑不宜过多调整，防止变成狼来了。

计划需要跟踪和调整

跟踪进度的两种方式，项目经理定期收集跟踪，项目成员主动汇报。

推荐实践：每日站会，看板

12 | 流程和规范：红绿灯不是约束，而是用来提高效率

流程规范的作用

• 从个体来看，因为流程规范的存在，确实可能存在效率降低的情况，但从团队的角度来看，好的流程规范反而是提升效率的。

• 将好的实践标准化流程化。

• 而好的项目管理，不需要直接管人管事，而是管理好计划和流程规范；项目成员不需要按照项目经理的指令做事，而是遵循计划和流程规范。

制定流程规范的四个步骤

1. 明确要解决的问题

2. 提出解决方案

3. 达成共识，推广执行

4. 持续优化，不断改进

将流程规范工具化

尽可能借助技术手段来推动甚至替代流程规范。

“软件工程”和“质量工程”需要依靠架构技术，而不是依靠 CMM 和 QA 管理流程。一切工程问题，首先要思考能否通过技术解决，当前技术无法解决的问题，暂时由管理手段代劳，同时不停止寻找技术手段。

13 | 白天开会，加班写代码的节奏怎么破？

开会是有价值的，同时开会也是有成本的，而且成本不低。

会议对不同人的价值大不一样。

你是砍柴的，他是放羊的，你和他聊了一天，他的羊吃饱了，你的柴呢？

如何提高开会效率？

两个角度：减少开会的成本，增加开会创造的价值！。

1. 砍掉一些没价值的会议

2. 减少参与会议的人

3. 缩短开会时间

4. 提升会议所创造的价值（停车场技术 Parking lot）

麦肯锡会议技巧

• 每个成员有一张黄牌，用于喊停其他人会议中发散讨论无意义的话题；

• 有人控制节奏，大家快速发言；

• PPT 不超过 3 张，鼓励大家预先准备，多讨论。

14 | 项目管理工具：一切管理问题，都应思考能否通过工具解决

一个任务，只有 0% 和 100% 两种状态是准确的，中间状态都是不靠谱的。

一切管理问题，都应思考能否通过工具或技术解决，如果当前工具或技术无法解决，暂时由流程规范代替，同时不停止寻找工具和技术。

项目管理工具软件发展史

• 没有软件工具，使用看板墙，手工报表和计划。

• 项目计划工具，MS Project

• 基于 Ticket 的任务跟踪系统

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

NASA阿波罗登月巨型计划图.png

15 | 风险管理：不能盲目乐观，凡事都应该有B计划

认识风险管理

风险 = 损失 x 发生概率

软件项目风险的管理，才是体现项目管理水平的地方

层次：被动应对，有备无患，防患未然

如何做好风险管理

培养风险意识

一、风险识别，识别可能的风险

检查表法

• 项目风险：项目预算、进度、用户和需求等方面的问题；

• 人员风险：人员离职、人手不足等问题；

• 技术风险：采用的技术所可能带来的风险；

• 商业风险：与市场、产品策略等有关的商业风险。

10 个项目死亡的信号：

1. 第一版做太多功能 ;

2. 太依赖新技术平台；

3. 与公司另一个有份量的产品竞争；

4. 团队人手不足；

5. 复杂的问题，需要复杂的解法；

6. 成员开始隐藏进度落后的事实和原因；

7. 不断更改、增加的需求 ；

8. 2.0 症候群 - 非要更大、更强、更美 ；

9. 产品没有市场立足点；

10. 你根本无法解决的大问题。

二、风险量化，对风险进行评估量化

• 发生的概率多大？

• 发生后，后果多严重？

三、应对计划，对风险制定应对策略

风险应对策略.jpg

• 回避风险——更改导致风险的方案

• 转移风险——将损失转嫁出去

• 缓解风险——降低风险发生概率或减少可能造成的损失

• 接受风险——明知山有虎偏向虎山行

四、风险监控，对风险进行监控预警

风险管理循环

风险管理循环.jpg

16 | 怎样才能写好项目文档？

短期高估文档的重要性，而长期低估文档的重要性。

工作的软件高于详尽的文档。

为什么要写文档？

• 帮助写文档的人理清楚思路

先写文档，就会抛开代码细节，去站在全局思考。

真正的障碍是没想清楚，在心中只有一些未成型的混乱的想法和概念，必须要努力把这些模糊的想法确定化和具体化，才能写出来。换个角度来说，如果你连文档都写不出来，那又怎么能指望代码写得好呢？

• 便于未来的维护和交接

• 团队更好的协作沟通

如何写好文档？

1. 从模仿开始

2. 从小文档开始

3. 从粗到细，迭代更新

4. 一些基本的画图的技巧

字不如表，表不如图，一图胜千言

线框图、流程图、时序图、各种截图

课后感

• 为什么不重视可行性分析？其中一种误解是软件能做一切，大家把计算机神化了。或者说通过这个工具，人把自己神化了。

• 可行性分析可以使用PESTLE（Political, Economic, Sociological, Technological, Legal, Environmental）模型进行。

• 管理其实是管事理人（lead 人）。对人不应该管，应该信任沟通、理解、带领。-- 大局观，从整个系统去观察发现问题。不要聚焦个人，而应聚焦整个团结的效能。不要只聚焦某个点/阶段，要从整个系统/生命周期去观察问题。精益的其中一条思想，Optimize the Whole（整体优化）。

• 艾森豪威尔将军说过，Plans are nothing, planning is everything. 计划注重的是过程，通过这个过程去思考，提炼信息，分析细节。计划很难一成不变，需要我们根据实际情况进行调整。所以敏捷认为，响应变化高于遵循计划。

• 将好的实践流程化，将好的流程工具化，优先考虑使用工具/技术手段解决问题。