项目管理相关书籍读书笔记

人月神话

一般很老的书，主要围绕作者在一个操作系统的项目过程展开，其开发模式和今天互联网的开发模式大不一样，他们当时的项目可能会有上千人参与，耗时几年，所以需要严格的项目流程，比如先由10人组成的架构组，对所有功能进行严格的规格制定和架构设计，再交付给开发实现人员去实现。

 

不过这也挺有意思的，至少有对比，知道老一辈的程序员所经历的项目管理是怎样的，他们的项目管理经验是什么。

按着书中的主线记录下重要的几个点：

1：估算，软件工程不像土木工程，可以通过增加人手来换取时间进度。

但往往有点项目，增加人手不并能减少工作时长，这里涉及到人员的理解、培训、熟悉过程

这里有个建议：向进度落后的项目中增加人手，只会使得更加落后

人月作为衡量一项 工作的规模是一个危险和有欺骗性神话。它暗示着人员数量和时间是可以相互
 

 

2：项目模块中间有相互依赖关系，按现在的说法是，要找到关键路径，得到项目最大的风险和瓶颈，

3：在基于可靠基础的估算出现之前，估算工作量的时候，项目经理要坚持自己估算。

4：分工：在小规模的团队中，比如10人左右，作者是建议参照外科手术的分工，一个主刀，其余辅助，高效完成同一件事情。

5：架构师在设计系统的时候，应该也让开发人员参与，一方面提高开发人员积极性，也充分发挥全员创新。系统设计不要成为架构师的专制特权。

6：如何避免二次重构？对于架构设计师而言，可以用一个公式：在每次改进之前，功能x不能超过m字节n毫秒。可以起到警示作用，对于项目经理而言：坚持拥有2个项目开发经验架构师的意见，同时保持主键，不被一些特殊的需求带偏，确保原则的概念和目标在详细设计上的完整性。

7：交流是成功的关键，特别是处于横向虚拟组织的时候，职权并不是那么明确，跨部门间的沟通协调是项目成功失败的重要决定因素

8：信息共享,没一天、半天的落后，比起重大问题更难发现和解决，严格指定进度表来解决这个问题

项目经理可以私下在处理这些进度风险，但是按里程碑向老板的汇报进度，老板则需要注意，对于项目经理可以完成的风险，不要随意发号施令，减少项目经理的积极性。

9：必须有评审的机制，从而所有成员可以通过它了解真正的状态。出于这个目的里程碑的计划和完成文档是关键。

10：文档非常重要，让其合并到源程序至关重要。

 

 

赋能

建立信任和信息共享的团队

案例1：飞机坠毁：机长充分讨论方案，但是最后一切就绪准备降落的时候发现汽油没了，最终迫降，另外一起事故因为机长把任务分配下去，每个小团队解决检查各自系统，最后完美降落。

案例二：海报突击队非常强大，但是训练的项目，都必须是2个以上的人才能一起完成，为的就是训练出团队能力非常强的军人。

 

加强信息互通，突破深井、打破囚徒困境

深井式组织结构在某些专精领域是有效的，但是在需要多部分协同作战的时候，由于信息不通畅，往往各自为战，囚徒困境也是一样，只有大家相互沟通、才能达成全体结果最优。

 

面对不确定性：赋能

将在外，君命有所不受，在复杂的情况下，抓住重点目标，大胆放权，提高组织的适应能力

 

项目管理精华

21世纪，人人都是项目经理，项目成功的关键是带领团队，发掘成员的潜力，让他们在参与的项目中发挥每个人的潜力。

 

核心观点：

最有效的项目管理：人+流程=成功

 

5个必要的流程组：发起-》（规划+执行）->监督与控制-》结束

 

非正式授权，怎么领导其他人？4个关键点：

展示尊重：相互尊重，坦诚相待

先聆听（好几本书都提到，非暴力沟通、人性的弱点）：克制自己说个不停的冲动，让成员勇敢表达自己的想法

明确期望：让团队成员达成共识，目标一致

承担责任：制定的规则严格执行，用于坦诚承担错误和失败

 

发起：将目标量化，让团队成员达成共识

（被蒙上眼睛的人无法走直线的）

组件团队，确定利益相关方，并进行访谈，完成项目范围的描述。

 

规划：设计清晰的路线图，确保做出正确的决定

风险评估和管理：影响*可能性=实际风险

设计项目日程表，知道什么时候做什么事情。包含全部的事情和里程碑

制定WBS（工具：可用思维导图推演、线性表格、便利贴）

为工作排序，甘特图，得出依赖关系和关键路径

 

 

执行：

责任：向团队成员明确，做的事情意义，明确责任划分，增加相互信任感

（自制力再强的人，也需要别人的监督，让别人承诺时间，也是加强影响力的方法）

团队责任机制：每周责任会，定期汇报机制，查看与既定目标的差距。（短小精悍）

如何让其他人对工作负责？定期汇报机制，调动他主观能动性，如果还是不行，需要在团队面前或者一对一的进行“责任对话”，需要明确正在采取措施解决问题。（当然需要首选展现尊重）

对话计划表：对象、我的目的是什么？事实是什么？影响是什么？后续措施是什么？截止时间是什么时候？

 

监督：

风险管理：不管好的坏的，都要坦诚汇报，隐藏问题，只会更糟糕

范围管理：不要随意变更范围，范围扩大，会容易让项目失控

需要走需求变更申请。让项目干系人都知晓这个变更带来的影响和应对措施，再次让目标达成一致

 

结束：

正式结束项目，总结经验教训、以供未来的项目进行参考。

过程中可以核对计划的清单，哪些完成哪些没完成，原因是什么，改进措施是什么？

这个点在仓储也是有借鉴意义的，现在项目收尾太随意了，完全没有什么沉淀。