产品经理避坑指南（二）——这些年我经历的非技术风险

一、前言

在项目中遇到的大部分风险都是非技术风险，从项目的属性进行划分，主要有组织风险、需求风险、进度风险、人员风险、质量风险、产品风险、沟通风险等。不同的软件项目因为项目类型、公司组织、业务形态等方面的不同而遭遇不同的风险，但是其风险点具有共性。笔者在文中梳理了从业过程中遇到的非技术项目风险，整理了具有共性的风险点，重点从识别风险、应对风险两个角度进行分析，希望能够帮助读者提升风险意识和风险识别能力。

二、风险案例说明

CASE1
某年某月笔者在W公司负责内部业务系统的产品设计工作，该业务系统涉及教务教学、市场管理、客户管理等方面，在0-1阶段的规划设计过程中，业务目标聚焦于教务系统的效率提升，逐渐由简单变得复杂，产品方案几经更改，需求规模不断扩大，最终花费半年多大时间V1.0版本才研发上线。试运行后发现系统设计的功能有很大的冗余，实施难度大，而且与业务的发展实际不符。同时由于系统规划目标中缺少对于市场、运营业务需求的支持，又导致了业务人员的负面反馈，进一步影响了系统的实施。

风险点	应对措施
项目目标不稳定，导致需求规模不断扩展，需求边界不清晰	回避：与管理者确定项目目标背后的目的和意义，制定合理可行的项目目标及实现规划，保证一段时间的项目目标不变，并对目标进行拆解，同时实现计划要跟管理者进行确认。
0-1阶段系统功能没有覆盖业务核心场景，影响系统实施效果	回避：在产品的0-1阶段要识别整个业务闭环，分析确认其中需要系统支撑的核心环节，并跟业务干系人确认实现的先后顺序，以及后实现部分线下替代方案，保证系统在实际实施过程中能够实现业务的闭环运转。

CASE2
某年某月笔者在H公司负责企业内部在线学习系统，该系统完成研发之后，业务部门并没有进行课程上传、对员工进行在线学习培训，花费资源研发的学习系统没有投入使用，进而导致该系统后续的相关项目优先级调低，同时跟业务方沟通系统没有投入使用的原因是系统功能不是业务方想要的。

风险点	应对措施
自研业务系统没有投入运营使用，导致开发资源浪费	回避：项目计划阶段要与业务方干系人确认阶段运营目标，并进行签字确认留档
用户对交付的产品功能不满意，要求重新设计或重做	缓解：关键里程碑评审（如需求评审、UI评审）邀请邀请业务干系人参加;设计文档必须经过业务干系人签字后才能投入开发

CASE3
笔者在W公司负责某系统的产品迭代工作，某次迭代的产品方案对原有系统功能做了重大调整，而且该功能的设计逻辑复杂，代码实现久远。由于参与此次迭代的开发之前都没有负责过该系统的相关功能开发，对系统的相关逻辑不是很熟悉，导致开发人员对需求逻辑的理解不是很清晰，进而对项目工作量评估不足、影响点评估不全，进而使得在项目进行过程中开发人员周末加班追赶进度，项目测试bug数量多影响到了项目质量，同时由于老功能的影响范围大，测试回归不全，导致项目上线后对其它相关功能产生不利影响；

风险点	应对措施
功能逻辑复杂，代码实现久远的模块需要比预期更多的测试，设计和实现工作	缓解：产品阶段需梳理功能调整范围，并在设计文档中进行标识区分，明确影响终端的范围，不要遗漏；技术方案设计阶段后端梳理本次需求对历史逻辑的影响、前后端历史交互方式，整理到设计文档中；测试阶段除了只能沙箱验证的功能，需进行全量回归，让更多的问题暴露在测试环境
项目组成员首次参与项目，对于历史功能实现逻辑不熟悉	缓解：产品经理需对开发人员讲解相关功能逻辑，预留一定的时间用于开发人员熟悉代码，衡量项目需求对历史逻辑的影响

CASE4
在笔者负责的某个项目上线的当天晚上，项目在完成上线后，测试人员进行上线后功能检验的时候，发现一个重大的BUG需要解决，但是负责修复该bug的研发通行已经下班回家了，紧急电话联系开发进行远程修复，但是由于开发人员家里的电脑无法搭建开发环境，需要返回公司进行解决，于是等到解决完问题的时候已经是凌晨3点了。

风险点	应对措施
上线过程中BUG责任人不在现场，不能及时修复问题	回避：项目上线阶段想过负责人员必须全部都在现场，如果因为特殊原因需要离场需制定问题应对方案，保证上线不会收到影响

CASE5
在笔者负责的某个项目在上线之前需要进行UI走查，由于设计人员的个人的时间安排，没有对PC端进行UI走查，在上线验收的时候发现一些PC端页面存在UI实现的问题，综合考虑问题优先级准后在后续版本里进行问题修复，但是版本上线后，系统功能在进行对外演示的时候，发现了该界面的UI问题，进而导致了部门领导对产品不满意。

风险点	应对措施
关键检验环节缺失，影响项目的完成质量	回避：提前制定好验收时间，预留充足的时间进行问题解决，制定好备选方案，保证项目流程的完整执行
项目存在未修复问题就上线	回避：产品经理在上线前需盘点项目中延期解决的问题，确认延期解决原因，是否会影响项目目标，提前制定问题修复计划，并向相关责任人汇报
忽略部分项目目标	回避：在项目规划前，需制定符合当前的战略规划的项目目标，不能忽略关键的项目目标

CASE6
曾经笔者在H公司负责一个高优先级项目，对于该项目技术人员给出的最终排期时间远远超过期望的交付时间，最后跟技术中心领导沟通确认项目的最终排期时间，该负责人直接根据功能UI设计稿的页面数量/3进行开发工作量的预估，进而得出最终的开发工作量，这种方法评估出的工作量是一种预估工作量，忽略了功能逻辑实现的复杂性，变相的通过deadline倒逼排期，使得开发人员通过加班来保证按时上线，但是这样的赶工也导致了项目在测试期间bug数量多，进而影响项目的质量。

风险点	应对措施
对交付日期要求严格，项目资源有限	缓解：梳理并确认出MVP需求，保证在交付日期内完成MVP交付 缓解：与业务方协调交付时间范围，为团队提供了一个灵活的空间，不要承担一些无所保留的承诺
错误估算任务所需时间	缓解：统一项目目标认识，建立责任共同体，让团队成员进行估算。在某些事情发生变化时给出重新估算。

总结

列举一下上述案例中描述的风险类型：

序号	类型	风险点
1	需求	项目目标不稳定，导致需求规模不断扩展，需求边界不清晰
2	需求	0-1阶段系统功能没有覆盖业务核心场景，影响系统实施效果
3	用户OR客户	自研业务系统没有投入运营使用，导致开发资源浪费
4	用户OR客户	用户对交付的产品功能不满意，要求重新设计或重做
5	设计和实现	功能逻辑复杂，代码实现久远的模块需要比预期更多的测试，设计和实现工作
6	人员	项目组成员首次参与项目，对于历史功能实现逻辑不熟悉
7	人员	上线过程中BUG责任人不在现场，不能及时修复问题
8	质量	关键检验环节缺失，影响项目的完成质量
9	质量	项目存在未修复问题就上线
10	计划	忽略部分项目目标
11	计划	对交付日期要求严格，项目资源有限
12	计划	错误估算任务所需时间

从中可以看到项目风险会贯穿整个项目过程，因此产品经理要始终保持着项目风险意识，做好风险识别、风险应对。

非技术项目风险点有很多，不仅限于文中所列举出的。结合上篇文章《产品经理避坑指南（一）—— 这些年我经历的技术风险》所列出的风险点，笔者希望自身经历的项目风险，能够帮助读者通过风险核对表的方法更好地识别出项目风险。