我眼中的软件项目管理

前言
• 本文为本人在实际工作中，个人经验的总结。因此本文的信息仅仅是个人见解。如有兴趣，欢迎和本人充分沟通。QQ：416187887
• 由于是个人经验的总结，因此下面简单介绍一下本人的工作经验，以反映本文信息的局限性。
• 1>数码相机领域的日企，经历了3年的软件开发。
• 2>对日外包企业，经历近4年的车载语音识别系统的开发和技术型项目管理。
• 3>在互联网领域，目前有不到2年的产品设计经验。

项目管理到底在管理什么？
• 人员？技术？
• 项目管理总的来说就是管理风险

• 首先是内部风险的管理
• 其次是内部人员的能否有效沟通的风险（本身属于内部风险，但这里单独出来进行强调）
• 再次是外部风险的管理（优先级本应该是最高的，但一般情况下先做好前两个内部风险管理，才有可能意识到外部风险）
• 如何做风险管理（PDCA管理法）

内部风险-什么是风险？
• 风险是什么，笼统的来说：任何影响到最终项目交付的内容，都是风险。
• 什么是项目交付：交付成本，交付时间，交付质量

• 内部风险列举如下：
• 需求风险评估
• 技术风险评估
• 工作量风险评估（工时）
• 项目交付时间点风险评估（工期）
• 项目成员风险评估
• 其他风险

内部风险-需求风险
• 需求文档提供时间点是否满足项目工期的要求？
• 需求文档中的设计缺陷，是否达到了影响项目工期的程度？
• 开发人员在做需求解读的时候，是否充分的了解了需求细节点？如果存在不理解的点，是否会对整体技术架构造成影响？如果造成影响，是否会满足项目的工期要求？
• 测试人员在做需求解读的时候，是否充分了解了需求细节？是否会对测试方法，测试用例的做成造成影响？是否会影响项目交付后的品质？是否会影响项目工期？
• 是否存在需求变更的大风险？【需要和产品经理彻底沟通】

内部风险-技术风险
• 是否存在需要进行技术调研的风险点？
• 如果存在技术调研的点，预估的调研日程是否已经根据项目工期进行了安排？
• 如果最终技术风险上升成了技术障碍，是否有替代的解决方案？
• 在不影响项目工期的前提下，一定要做技术方案决最终策的时间点是否明确？
• 最终的技术方案决策，要由哪些人参与？最终结论由谁来正式给出？
• 如果技术障碍需要调整需求，由哪位技术人员向哪位产品人员主动提出？提出的最晚时间点是否明确？

内部风险-工时评估风险
• 进行工时评估的时候，是否考虑了合理的风险系数
• 每个小团队的工时评估，是否已经按照以往经验配置了不同的风险系数？
• 有些团队可能会习惯性的乐观估计，有些团队可能会习惯性的预估较多风险系数，因此需要根据不同的团队进行不同的风险系数调整

内部风险-工期评估风险
• 项目整体的管理者，是否给整个团队预留了交付工期的风险系数？

内部风险-项目成员风险
• 成员的稳定性
• 工作的主动性
• 技术能力的可靠性
• 成员与成员之间的能否高效的沟通？
• 当不同成员之间产生意见分歧的时候，是否有做最终决策的流程？这个最终决策的流程，是否每个成员都清楚？

内部风险-其他风险
• 之所以叫其他风险，因为这些风险是未知的，任何项目都不可能在计划阶段预估到所有的风险。

有效沟通
• 沟通，我的理解是：
• 1>听明白对方的表述
• 2>讲清楚自己的观点
• 3>双发达成共识，最次要让双方了解彼此的观点

有效沟通-沟通风险
• 沟通是一个人每天都要做的事情，但真正最好的，做到位的，做到高效的，其实并不多。
• 沟通产生偏差会导致很严重的问题，例如:
• 小张：xxxx事情，我们以前沟通的时候，你说的是A吧？现在怎么是B了呢？这样的话，我这边的设计都要重新改的，基本浪费了50%的工时。你说怎么搞？
• 小颜：我啥时候说是B了，明明我说的是A啊。怎么搞，你自己说怎么搞？
• 小张：[怒]
• 小颜：[怒]，不服你咬我啊

有效沟通-沟通风险
• 发生上面的情况，原因可能有：
• 1>有一个人说谎了（一个积极向上的团队中，这个基本是不会有的）
• 2>双方沟通的时候，产生了偏差，导致双方理解不一致

• 如何从流程上解决？可能答案是：
• 正式的沟通结论，一定以文档（文字，图标，流程图等）最终留存下来
• 这样做的好处：
• 文档的形式能够引起大家足够的重视
• 文档的形式可以留存项目过程中的宝贵信息
• 文档的形式在将来进行“责任归属”判定的时候，是一个有利的依据。【这一条，作为管理者，不到万不得已，不要使用。因为我们要的是解决当前问题，规避类似问题再发；而不是追究责任。】

有效沟通-沟通风险
• 上面同样的例子，如果加上了文档的保留，和合理的沟通方式，局面可能是这样的：
• 小张：xxxx事情，我们以前沟通的时候，你说的是A吧？现在怎么是B了呢？这样的话，我这边的设计都要重新改的，基本浪费了50%的工时。你说怎么搞？
• 小颜：这样么？我们看看文档再说。
• (看完后)小颜：你看看，我们当初说的是B吧。
• 小张：原来确实是B，我一开始弄错了，这个咋办？
• 小颜：[我们]看看还有没有挽回余地，寻找一个简便可行的变更方案，如果确实没有，风险就太高了，我们就要报告项目经理了。

• 无论如何，小颜摆脱了自己的责任，小张也意识到是自己的失误，双方也尝试共同来解决这个问题。
• 并且小张无论如何欠了小颜一个人情（下次小颜犯错的时候，小张就可以帮助小颜一起来应对了）

有效沟通-沟通风险
• 沟通达成的效果，基本有以下几点
• 1>什么叫做完成？也就是完成的标准
• 2>由谁来完成？
• 3>什么时间点完成（紧急的事情，一定要精确到小时，或者每半小时；通常的事情，至少要精确到天）
• 4>完成后谁主动提出“已经完成”，向谁提出？

• 人员安排，责任人，时间点，主动汇报者，汇报对象

有效沟通-沟通风险
• 沟通中要抱着解决问题的心态去和他人沟通
• 用词也要注意包容他人，不要搞“阶级对立” 。

• 少用“你”“你们”“你们后端的”“你们前端的”“你们运营部门”
• 多用“我们”“我们后端的同事”“我们前端的兄弟”“我们测试的团队”“我们的运营部门”

外部风险
• 什么风险是外部风险？
• 一切我们团队内部无法解决的风险，就是外部风险。
• 小到：周末团队要加班，但是周末中央空调不开机，要热死人啊。
• 大到：内测阶段需要外部实施部门配合，但是目前实施部门反馈他们很忙，最近没有时间配合我们。

发现风险
• 靠谁来发现风险？
• 靠项目经理？靠组长？
• 发现风险，报告风险，人人有责。

• 发现风险：需要靠主动思考风险的意识，需要靠偶然的机会。
• 报告风险：发现的风险，无论大小，一定要报告风险
• 人人有责：团队中的任何一个人都有权利和义务发现并报告风险，因为：发现了但不报告，那就等着之后风险爆发的时候，大家一起受苦吧。

报告风险
• 报告风险，仅仅是说明风险么？
• 报告风险，其实不仅仅是说明风险，更重要的是一定要提出自己的解决对策。
• 解决对策可能自己有，也可能自己没有。没有的时候就要表明：目前自己这边没有找到解决对策，希望得到相关人员的支持。
• 但前提是：这个风险在自己的范围内，确实是无法解决的。否则给别人的感觉就是：在抱怨，在推脱责任。

PDCA管理法
• PDCA循环又叫质量环，是管理学中的一个通用模型，最早由休哈特于1930年构想，后来被美国质量管理专家戴明博士在1950年再度挖掘出来，并加以广泛宣传和运用于持续改善产品质量的过程。
• 来源：百度百科

PDCA管理法 Plan
• P (plan) 计划，包括方针和目标的确定，以及活动规划的制定

• 工作量是可量化的，工作的完成点是可检查的
• 每一个内容是精确到责任人的
• 每一个内容的完成指标是明确的
• 每一个内容的完成时间点是明确的

PDCA管理法 Do
• D (Do) 执行，根据已知的信息，设计具体的方法、方案和计划布局；再根据设计和布局，进行具体运作，实现计划中的内容。

• 执行是一个过程，过程是要进行管理的。
• 过程管理，需要项目成员按照计划，管理好自己的工作进度。同时管理岗位的人员，需要管理好项目的整体进度。

PDCA管理法 Check
• C (check) 检查，总结执行计划的结果，分清哪些对了，哪些错了，明确效果，找出问题。

• 项目每推进一段时间，就需要根据当前项目的真实进度，并结合里程碑，调整下一步的工作计划。也就是Plan需要重新按照当前的实际情况来调整。
• 具体多长时间调整一次，需要根据项目的工期来灵活决定：
• 例如：1.5年的项目，项目前期每月调整，中期每月/每半月调整，项目后期每半月/每周调整
• 1个月的项目，至少全程每周调整，最后1.5周，可能需要2-3天调整一次

PDCA管理法 Action
• A (action)对总结检查的结果进行处理，对成功的经验加以肯定，并予以标准化；对于失败的教训也要总结，引起重视。对于没有解决的问题，应提交给下一个PDCA循环中去解决。

• 总结上一个小周期内，项目发现了多少风险，哪些风险是可以通过流程，通过制度在今后进行规避。从而在下一个小周期内落实这些流程，并观察效果。