昨晚看完《人月神话》一书，结合我所做项目经历，对我感触最深词语有：人月、里程碑、文档管理。
人月
在书本提到：
认为用人月作为衡量一项工作的规模是一个危险和带有欺骗的神话。他暗示着人员数量和时间是可以相互替换的。
在带项目确实犯过使用人员数量和时间相互替换的错误。当项目紧张时，考虑过加人手问题，如果只受到编码进度因素影响，这样确实能解决问题。但实际上，不仅受到编码进度，还会受到分析设计、人员培训、人员沟通时间、资源配合、外围接口等等影响。这些都是相互影响，影响的结果是非线性。请记住Brooks法则：
向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）
当项目进度已落后比较好的做法是：
分析当前项目落后的原因，主要内部因素还是外部因素引起。
如果是外部因素引起无须增加人手，还可以考虑减掉人手，以免消耗更多人月。
如果是内部因素再分析是人员工作问题还是错误估算时间的问题，项目落后往往是错误估算时间的问题。
当项目进度已落后，切忌增加人手。
里程碑
曾参与过项目都比较遵守软件项目流程，但项目计划的里程碑不够明确。主要害怕承担责任。项目经理负责做项目计划，但不应该他承担所有责任，责任需要共同承担，项目计划用于督促双方是否遵守计划完成任务。
里程碑必须是具体的、特定的、可度量的事件。
在需求分析、设计阶段的里程碑，主要交付产物是需求分析书、系统概要设计文档和数据库设计文档。交付产物都需要双方评审通过才能达到里程碑要求。
在编码阶段的里程碑的交付产物是比较难的定义，要每个程序员评定各自负责功能实现程度是比较主观。在这个阶段可以采用是两两监督方式，比如A同事所实现功能，需要B同事来检查实现功能进度，如果功能实现进度是100%，需要双方签字确认。同时，A也监督B的所实现功能进度。如有问题需求追究双方责任，这样可以避免实现功能与需求说明书不一致问题。
说明在每个阶段定义明确里程碑，方便以后检查进度和以及知道进度落后的原因。
管理文档
经历几个项目组后，发现都不注意管理文档。大部分开发人员都认为理解需求就好，不注意更新文档。这样会影响后续开发和维护工作。
最常见的问题是：容易出现新同事不熟悉已离职同事负责的模块功能。这情况下，只好咨询老同事怎么实现，如老同事知道该功能业务流程还好，虽然还会造成一定沟通成本提升。但老同事不知道该功能业务流程时，就需要老同事和新同事一起熟悉该功能，至少耗费两个人工作时间去了解该功能，这是就能体现需求文档和设计文档的重要性。
还有一个比较常见问题是：需求变更记录文档。需求变更影响到项目开发、项目测试、项目验收。如果需求变更没有及时通知上面所说某一环节，都会影响到整个项目进度。
在项目处于各个阶段都需要严格管理文档版本，保持版本库的文档是最新的。
