近半年多时间，我作为主产品经理，参与到一个公司级项目中。该项目涉及系统多，涉及业务范围广，涉及相关人员多，项目实施过程中也出现了很多很多的问题，而从这些问题中，我也发现了一些项目管理解决不了的问题，而这些问题恰恰是职能经理管理工作没做好导致的（本人也担任产品部门经理，负责产品组日常管理工作）。
首先，产品经理在整个项目实施中参与度太深，具体如下图所示，在开发、内测、联测和全流程测试阶段，产品经理还需要花费大量时间和精力参与进来，解答开发或测试同学对流程、数据准确性、甚至接口对接字段等问题。并且，开发和测试同学遇到稍微复杂的问题，都一定要产品经理参与才能最终确认这个问题是不是bug，是不是需要调整功能，是不是满足需求等。开发和测试对产品经理的需求文档依赖性很高，并且开发根据需求文档写代码，测试根据需求文档写测试用例，两者都对产品经理的需求文档负责。而实际中，需求文档可能存在部分细节遗漏或表述不是特别恰当（作为产品经理，谁也没办法百分百保证不遗漏），遗漏部分则永远都发现不了。另外，开发和测试都对需求文档负责，但测试如果不熟悉功能要满足的需求场景，不熟悉功能调整可能影响的系统流程，不了解开发实现的大概逻辑，那就没办法完全测试出开发可能出现的bug，那么，测试质量从何保证。
产品经理在项目中各节点参与度
其次，项目实施中，开发和测试也因为工作问题吵过几次架。主要原因在于开发同学完成功能后，没有充分自测，甚至和其他系统对接的接口都跑不通，非常影响测试整体进度。这种情况导致了项目进度的压力全部转移到测试身上，测试又不能容忍大量阻塞性bug出现的问题，吵架自然不可避免。同时，开发阶段的一些不规范，无标准，也导致了开发质量比较差，比如：两个系统接口对接，出现了接口字段缺失，接口数据结构对不上等问题，而这些问题都是在联测阶段才暴露出来，也说明了开发要求太低，也没有相应标准。
最后，说说测试同学吧，内测，联测，全流程测试，其实是一步步扫雷的过程，也是一步步加深对系统和功能熟悉的过程，内测阶段对产品经理的依赖性还可以理解为需求理解不一致，需要部分内容再次澄清，但联测和全流程测试阶段，过渡依赖产品经理则只能说明我们的测试同学不够专业，并且每一轮测试应该达到什么效果，也没有明确的标准，导致整体测试周期比较长，但效果也没办法完全保证。
上述的问题，我一度认为是项目管理的问题，也一度认为是人员能力和态度的问题，也因此和开发、测试吵过架。但经过仔细分析和思考，我发现这些问题项目经理都没办法解决，他也不会花费大力气在解决这些问题上，项目运作的核心还在于通过计划、控制、协调、平衡等手段达到项目目标。同时，我们也不能过度依赖人员能力和态度，否则，以后我们都没有能力做好一个大项目，而人的问题始终能够转化为流程、标准、规范等管理手段，通过职能经理对产品、开发、测试人员工作的管理来减少项目运作中存在的问题。
作为主产品经理和产品组负责人，最值得我思考的还是如何减少产品经理在开发和测试阶段参与度。
那么，就需要厘清这几个问题：
1）产品经理在需求交给开发和测试同学时，到底应该达到哪种效果才算通过，才能减少后续开发和测试同学对产品的高度依赖。
2）产品经理的需求文档到底应该细化到哪种颗粒度，哪些问题是开发应该自主设计并做决策的。
3）各阶段测试的标准是什么，开发提测的标准是什么，产品，开发，测试怎么高效配合等等。
项目制管理的目的在于产品快速交付，并保证质量。而项目实施中会出现各种各样想不到的问题，比如：开发工程师不会写概要设计，那么，项目经理可能会考虑其他方式来规避不写概要设计的风险，但不会找人教会开发写概要设计，因为时间成本太高。这种类似问题在项目管理中可能还不止一个，而项目经理也只能通过协调资源，合理安排任务，寻找快速可替代方案，风险平衡等方式来达到项目目标。因此，项目组和职能组之间的关系则显而易见。
最后的最后，我想说的是，产品，开发，测试部门的经理，一定要对每个人有高标准、高要求，才能让每个人都能参与到项目中，也能输出更高质量的产品。公司的发展中，切忌出现产品、开发、测试要求相差甚远的情况，否则轻则出现某个岗位累个半死，员工大量离职，重则项目失败的情况。
网友评论