“我的管理总结”
前言
这几天是新型肺炎病毒的爆发期，戴上口罩也不想外出的节奏，在家宅着码字吧，๑乛◡乛๑。在上一篇中我就软件开发模型的选择，项目管理涉及的方方面面和团队组建运行做了展开和总结。本篇主要介绍软件开发的计划和实际实施，以及项目成本估算的一些思考。
软件开发计划
软件开发计划的输入是客户需求，但是绝大部分情况下客户需求是存在不确定性的，做计划的时候需要考虑。
在我所领导的项目中，我们采用WBS任务分解的方法进行计划的制定和控制。
任务分解结构（WBS）是一个分级的树型结构，是对项目由粗到细的分解过程。下图中是进行项目分解的一个wbs例子。
基本步骤
- 确认并分解项目的主要组成要素。在拿到主要需求的情况下，需要对软件整体架构设计和主要需求之间是否存在偏差进行评估。如果整体架构设计需要调整，那么第一个粗粒度的就是架构调整评估。在架构固化后，下一个粒度就是规模功能点评估。
- 确定分解标准。按照项目管理的方法分解，以上图WBS的方式进行分解，通常在架构固话后，我们以功能点作为下一个粒度的分解标准，功能点明确后，按照软件架构设计，以模块作为最后的粒度分解。
- 确认分解是否详细，分解结果是否可以作为费用和时间估计的标准，明确责任。工作细目的分解如果在很久的将来才能完成的话，那么这种分解也就没有了确定性，这种不确定的一般作为计划的不定期检查点。
- 确定项目交付成果，交付成果是有衡量标准的，一般我们以每个功能的缺陷率作为衡量标准。
- 验证分解正确性，验证分解正确后，建立一套标号系统，每一个分解好的任务在信息系统中以标号记录和跟踪。
- 分解后的任务，要考虑是否有人能担负起满意地完成这个项目的任务？如果没有，修正是有必要的，目的是提供一个充分的管理控制。也就是有的时候，本属于A模块的任务，因为A模块负责的人员没有能力承担，那么就需要调整。
WBS注意事项
- 任务分解的规模和数量因项目而异
- 注意收集与项目相关的所有信息
- 注意参看类似项目的任务分解结果，与相关人员讨论
- 可以参照模板进行分解
- 先分大块任务，然后再细分小的任务，最底层是可控的和可管理的，避免不必要的过细
- 按照软件项目的平均规模来说，推荐任务分解时至少拆分到一周的工作量（40小时）
- 每个工作包至少有一个提交物
- 定义任务完成的标准
- 任务分解结果必须有利于责任分配
- 可以准备WBS的字典
- 最后与相关人员进行评审。
项目规模估算
通常我们采用历史经验（专家法）的方式对项目进行规模估算，德尔菲法(Delphi technique)是最流行的专家评估技术，这种方法的优点主要是简便易行，具有一定科学性和实用性，可以避免会议讨论时产生的害怕权威随声附和，或固执已见，或因顾虑情面不愿与他人意见冲突等弊病；同时也可使大家发表的意见较快收敛，参加者也易接受结论，具有一定程度综合意见的客观性。但缺点是由于专家一般的时间紧，回答总是往往比较草率，同时由于预测主要依靠专家，因此归根到底仍属专家们的集体主观判断。此外，在选择合适的专家方面也较困难，征询意见的时间较长，对于需要快速判断的预测难于使用等。尽管如此，本方法因简便可靠，仍不失为一种人们常用的定性预测方法。根据目前的现状，我们可以从以下几个方面考虑：成本、工作量、项目规模、技术难点、风险列表、以往项目中可借鉴的地方。 而在实际的项目中，无法完全按照Delphi方法进行评估，通常主要以项目进度要求，项目架构师和模块负责人的经验进行评估。这种情况下，就会产生会议讨论时产生的害怕权威随声附和，或固执已见，或因顾虑情面不愿与他人意见冲突等弊病，这些都需要项目经理进行平衡。
工作量估算
如果按照正向估算的话，规模/平均生产率＝总工作量（参考公司度量库中的员工平均生率（个/人月)），总工作量中包含开发工作量和管理工作量。
在实际项目中，通常主要以项目进度要求为主，公司量度库中数据为辅进行估计。而这样就会产生有些工作量是压缩过的，需要员工进行加班才能赶上的情况，民企中的软件项目几乎不存在不加班的情况，但是加班意味着成本上升和员工效率下降的情况，这也是项目经理需要考量的地方。
成本估算
软件项目中的成本项主要如下：
- 人员成本，这是最主要的成本。人员根据岗位的不同，成本又不一样。参考公司量度库。
- 加班费用（元）
- 差旅费用（人数，次数，时间）
- 招待费（元）
- 采购费用（元）
- 关键物料资源。包含电脑、服务器、开发环境物料和仪器等
- 其他费用（元）
软件封版注意事项
- js上配置权限关闭修改
- 关闭代码提交权限
结束
好了，今天暂时更到这，欢迎大家阅读、批评和指正，下回再见。
