项目管理无处不在

1         目的和范围

社会竞争日益激烈，对于个人来讲，如何是提高竞争力是个关键。提高竞争力的方式可以很多，比如，提高专业知识、参加社会实践项目、参加培训等。这些活动都涉及到时间、进度、成本等， 如何更好的管理活动，如何能达到一个很好的效果。项目管理可以是个很好的帮手。

本文根据自己生活、学习、工作等活动，提供了一些相关的经验。主要包括：

l         基本概念和方法

l         计划设计

l         人员管理

l         质量管理

l         成本管理

l         如果结合自身特点更好的进行管理

l         其他管理

“三分生产，七分管理”，很多项目的失败，很多主要因素可能不是技术上原因，而是管理上漏洞。通过项目管理，可以更好的管理的生活、学习、工作。

2         箴言

1． 要有独特的眼光和好的思路。

2． 好的思路和好的设计都离不开技术的支撑。否则就是纸上谈兵。

3． 学以致用。

4．  

3         过程管理

1． 确定愿景和目标。

a)        愿景包括：项目的愿景、团队的愿景。

b)        要有阶段性目标

c)        方法：头脑风暴

d)        增强信心。

2． 充分准备。

a)        采用模版文档。

b)        多查资料

c)        要采用行业术语

d)        语言描述要简洁。

e)        数字要准确。

f)          多用比较的方式。

g)        确定重点项目。

3． 知识管理。

a)        循序渐进。要反复的验证。

b)        把握重点。确定优先级，并进行排序。

c)        重点内容要投入更多的时间。非重点可以放到随后的版本处理。

d)        对于大的项目，分拆不同的人，进行细化。

e)        细化后，大家一起讨论。

f)          没有异议后，集中整理到整体文档中。作为里程碑。

4． 要有输出结果。

a)        每次讨论或整理，重要内容必须形成文档。

b)        作为阶段性成果。

c)        作为下一次讨论的依据。

d)        也是防止遗忘的方式。

5． 制定计划。

a)        根据工作难度、人员素质、时间要求进行权衡。

b)        粒度合理，可以把一个大的模块，拆分为小的模块或功能点。便于跟踪和检查。

c)        要有里程碑。便于检查和交流。增强成就感。

d)        计划可以变更。但是不能变更太大。

6． 分配资源

a)        方法：按每人的特点、按工作难度等。

b)        责任明确。明确的工作范围、时间点

c)        奖罚要明确。

7． 统一认识和团队互助和培养学习性团队。

a)        这是你的船。

b)        学习使人进步。不进则退。

8． 质量保证。

a)        定期更新计划表、

b)        定期会议、

c)        采用流行工具。比如： project、svn、mantis、wiki等

9． 度量标准

a)        计划中的工作是否完成

b)        代码质量是否合格。

                         i.              遵循开发规范。

                       ii.              设计合理。

                      iii.              采用模式。

c)        是否满足需求

d)        是否功能测试完毕

e)        是否性能满足业务需求

10．             体验

a)        确定试点项目、试点客户

b)        制定反馈表格

c)        开始制定销售计划、销售对象、策略、制定盈利点。

d)        确定支持人员

11．             正式发布

a)        正式发布仪式

b)        正式销售计划

12．             支持团队

a)        回答客户问题

b)        收集用户需求

13．             项目总结

a)        按劳分配。

b)        团队成员的心得，可以文档方式、也可以直接交流方式。

c)        对于好的经验，方法等，要推广，对不要的做法要摒弃。必须形成文档。作为今后的借鉴。

d)        关键技术必须形成文档。

14．              

4         计划管理

4.1         计划管理

为了更好地改进计划管理工作，一些建议：

1.        明确产品目标规划。

2.        优化计划模版，在计划模版中要求明确标注评审点、里程碑点和是否属于需要特别关注的主线计划等信息。

3.        明确每一项任务的具体输出。

4.        明确每一项任务的责任人。

5.        明确计划制定与控制的责任人，专人负责，信息共享。

6.        强调部门间的协调配合。

7.        计划的贯彻，要求基层员工人手一份计划。

充分预估风险，提前拟定风险减缓措施和应急措施。

4.2         对于软件开发的计划

4.2.1        半年计划

1.       合理设定里程碑：一般每个团队平均每个月设定1个里程碑。

2.        给外部评审预留充分的时间：一次评审从发起（提交评审材料）到结束（跟踪验证结束）需要一周左右时间。

4.2.2        月计划制定

1．  设定计划检查点

2．  对检查点相关的部门内部评审进行规划

3．  对部门内部培训、代码走查进行规划

4.2.3        制定、跟踪和控制计划的检查项

计划检查项

＃	检查项	备注
前提条件检查项
1	是否有明确的产品和版本规划	制定计划的基础
2	是否考虑了产品之间的优先级关系	在多个产品、项目之间做资源调配的基础
3	是否考虑了产品内各子系统/模块之间的优先级关系	在一个产品的各小组之间做资源调配的基础
4	是否考虑了产品的规格、进度和资源的优先级关系	进行调整的原则（即：规格优先、进度优先、或者资源固定）
计划制定检查项
5	是否按照产品研发/项目过程进行工作任务分解	避免遗漏重要工作任务

 

6	是否包括了评审、会议、配置管理、质量保证等活动，并安排了合适的工期	避免评审的仓促，避免遗漏必要的支持活动导致的计划变更
7	工作任务分解粒度是否合理（月计划的任务工期不超过1周）	粒度过大，可控性差；粒度过小，缺少弹性
8	是否设定了适当的里程碑	对于产品开发计划或项目计划，为每个阶段/迭代设定1个里程碑即可；对于月计划，每个产品/小组每周至少设定1个里程碑
9	是否建立了任务的关联或任务的限制条件	确定计划的关键路径的基础
10	是否为每项任务确定了输出	检查和控制的基础。如果开发过程比较完备且理解到位，该项内容可以取消
11	是否录入了所有可用资源及资源的成本信息	便于进行成本估算，便于进行资源调配。不要将小组作为一个资源处理，不利于工作任务分解和分配
12	是否为每项任务（不含摘要任务）分配了具体资源	确保为每项子任务分配了资源，并且确保没有给摘要任务分配资源
13	是否明确了资源投入百分比	体现准确的估算工作量，及计算准确的成本
14	消除了过渡分配	对于过渡分配安排了加班时间或者分散了工作任务压力，确保资源按计划完成任务，并且准确估算成本。
15	资源对所分配的任务有准确的理解并承诺完成	目标及任务理解的一致性和资源自身的承诺有利于提高资源的主动性
16	查看剩余资源，适当调整任务分配，以加快关键路径的进度	向关键路径要时间，向非关键路径要资源
17	是否全面考虑并且记录了相关的风险	提前采用风险减缓措施有利于保证计划的完成；风险包括政策、商务、技术、组织结构等方面（例如：人员变动大、人员缺口、需求不确定、涉及公司/部门外部配合的工作项都属于风险范畴）
计划的跟踪和控制检查项
18	是否及时跟踪计划，是否及时维护进度状态	是计划控制的基础
19	周报、月报是否与计划对应	避免计划和实际脱节，把计划当成摆设
20	变更计划时考虑了所有受影响的任务及相关资源	这点对于承担多项任务的资源尤为重要，计划的变更可能引发新的资源过渡分配问题，也可能导致关键路径的变化，必须对变更进行全面分析
21	是否按规范进行了风险管理，及时制定并执行减缓措施和应急措施	风险的跟踪也应纳入计划跟踪的范畴，这样才能进行全面的计划控制
计划分析检查项
22	计划是否多次变更（包括延迟、取消、调整资源等）	延迟多是由于评审时间长、工作量估算乐观、人员流动、需求不明确等原因导致的；
23	是否存在闲置人员或存在人员缺口？	通过分析资源使用情况，确定部门人员需求
24	资源的技能、岗位配比是否合理？	通过分析资源使用情况，确定部门人员配置

5         工作原则

1． 相互尊重的原则

2． 知识共享的原则

3． 按劳分配的原则

4． 相互促进的原则

5． 加强沟通的原则

6． 定期检查的原则

6         工作方法

序号	问题	备注	状态
1.	“阿布”思考法	先不要考虑太多成本，把想到的都先列出来，当然不是漫无边际的想。 然后，把握核心需求进行分析和讨论
2.	不从头造车
3.	站在巨人肩上 采用好的，并且成熟的开源工具包 Js、java、框架。	最可怕的就是不知道，还自己认为很强大。
4.	打好基础 1、 技术 2、 业务 3、 市场
5.	循序渐进
6.	要做产品，它不等价于项目 它来源于项目，并应用于项目，项目有反过来推进产品的演进	对于大的项目可以定制。
7.

7         不推荐的方法

序号	问题	备注	状态
1.	减少非生产性会议。
2.	根据项目的特点，选择不同的开发方法，以求整体利益的最大化，互联网的项目说到底是为了商业为目的，不是科研项目。所以那些技术更好，脱离了项目和具体的人来谈都是荒谬的。 对于项目管理人员来讲首先要考虑是如何在最短的时间内用最低的成本开发出符合质量和维护要求的项目，单纯地追求技术，对于一个项目来说是非常危险的事情。

 

8         过程改进有效实践

优良的软件过程可以为开发高质量的软件提供有效的实践方案，同时对团队的开发效率有着决定性的作用。

8.1         产品规划阶段－活动组织与计划监控

从计划跟踪结果发现：产品概念立项阶段延期普遍，如果单独以该阶段自身的周期做分母，往往延期达到100%甚至更多。虽然从绝对值上看，这个阶段的延期不是很大，但是属于关键路径延期，如果关键路径上的任务都以这个幅度延期，那么产品开发进度就完全失控了。

QA分析，概念立项阶段进度失控的重要原因之一是没有进行深入的任务分解，资源协作不及时，而这个阶段的任务如果要高质量完成，各方面的配合又是必须的。

本文专题介绍，如何对产品概念立项阶段的任务进行分解，以便减小任务粒度、提高资源到位率、最终使该阶段的进度受控。

任务分解的基本原则：

1) 将任务分解到合适的粒度：除沟通外，分解后的子任务由单个的资源完成并且工期不超过5个工作日。

2) 明确各项活动的资源、完成时间、输出及质量要求。

 

具体建议：

1) 明确概念立项阶段的任务。产品概念立项阶段的主要目的是明确产品“要不要做，做什么、不做什么”，是产品开发成功的基础。概念立项阶段包括以下3项任务，这3项任务基本是串行的：

确定远景和范围，制定产品路标规划：分析定义产品的市场需求和远景，描述高层的产品目标和需求，在实际约束条件下，确定产品的范围。

制定产品总体计划：明确后续各阶段的任务、工期、资源，包括开发计划、配置管理辅助计划等子计划，明确管理制度。

立项评审。

2) 对任务进行分解，提高任务内部各活动的并行度：

对于“定义远景和范围文档”，需要综合考虑市场前景、业务需求、运营需求、系统需求等，还需要确定产品技术策略，将这些任务分解到不同资源，并行完成。

对于“总体计划”，开发计划、测试计划、配置管理计划、质量保证计划、管理制度等分解到不同的资源，并行完成。

3) 与相关干系人保持及时和有效的沟通，在提交工作成果之前发现问题并及时纠正，而不是依赖于审核活动发现问题。

4) 明确阶段内的沟通活动，确保相关干系人按期参与沟通工作，降低协作风险。

5) 为各项子任务的工作成果审核及整合预留足够的时间。

6) 为审核后的修改预留足够的时间。

 

8.2         产品版本梳理

整理产品组件视图。较清晰的描述了产品的构成及各组件间的依赖关系，为配置管理提供了依据。

统一版本编号，整理版本资源文件。按照明确的版本定义规则，统一了组件版本编号并进行了说明。

8.3         配置管理改进

有效的软件配置管理工作对于提高团队开发效率、保障软件产品质量有重要意义。CTI团队在本月作了大量准备工作，为产品配置管理的工作开展打下了良好的基础。

规划并建立新的配置结构，区分受控区及个人区

定义配置库访问控制策略，明确各角色在配置管理中的职责

 

明确配置项变更流程，及对受控申请时提交产物的要求

统一版本标识定义规则

明确组件配置项版本和配置库目录结构的对应关系

按新的配置结构，对历史配置库进行清理及配置项迁移

8.4         测试和培训

强化单元测试及集成测试的执行，要求开发人员明确测试对象版本并进行必要的测试说明

明确测试与开发之间的交互流程，以便更有效的解决问题

针对部门的各产品组织内部培训，提高了测试人员产品的整体把握，为测试的充分性及有效性提供帮助，同时也增强了部门员工对产品的整体认知。

9         参考资料