由某产品线组织架构调整引发的思考

r囧r小猫 2022-01-14 01:37 271阅读 0赞

1 案例描述  
  
某产品线组合架构调整，项目管理方式较以前有些变化，产品组内部希望变革的呼声很高，提出不少设想，流程简化，项目周报，项目例会的方式，对各领域的要求等等。抛却旧有模式，一味创新，实际代价很大，建议变革前先认真体会IPD精髓，结合LPDT的实战智慧，群策群力优化改革，让管理模式可以积累和复制，变成产品线自己的财富。

2 案例分析与解决过程

产品经理的培养没有积累  
产品经理不是做项目的，项目结束就完了，而是对产品负责，知道它生它死，为什么生，为什么死，目前产品经理缺少相应的培养积累，态度和意识是前提。职责岗位说明来支撑，考核来牵引，本篇案例不再这个角度发散。建议系列产品开发的总结还是做起来，当前不一定要在全产品线推广，可以在目前较为规范的团队建议，将做产品的经验积累成可执行并贴合产品线实际的规范。

没走过IPD流程的产品经理建议不要过多的裁剪及简化流程，按流程走一遍，熟悉了解IPD流程，拿捏好那些活动可以有，那些活动可以弱化，活动背后的意义是什么，那些活动不适用，可以删除，那些我们的薄弱环节需要加强，自然而然的参与到过程改进中，和产品组团队成员一起将项目做好。

理解流程

流程不是规范，不是死的。只是指导，提示关键的活动顺序，重点是什么。具体的操作需要项目组根据实际情况执行，有活动的最终目的引导活动的过程，结合项目组管理及团队的特点固定合作或者执行活动的方式，形成适合自身并且可执行的规范，才是适合产品线的过程规范，并且可以积累的并持续优化的。

关于对QA的误解

QA到底做什么？监管还是引导？QA主要对过程质量负责，并且它是个闭环。但是过程制定不是QA主要操刀，是由产品经理主要把握的，首选在过程中体现他对项目的理解，觉得项目重点的点在那，QA给出与之匹配的过程建议，并且编写具体过程文档，这就是流程裁剪。流程裁剪不是QA工作，项目做成什么样，怎么做，LPDT必须有想法和计划，QA根据讨论的结果加入过程领域的建议，达成一致意见后，由QA成文的。  
根据流程裁剪表，LPDT制定计划，下发计划，POP跟踪计划的执行程度（完成情况），QA检查活动的完成情况（完成效果，可能有什么风险可以给出质量评估）。什么QA引导活动，安排计划的，都是浮云，如果计划活动是QA安排，那么会完全贴合项目吗？那么LPDT不管计划，怎么分派工作呢？

关于计划

形式其实是不限的，但是它需要是工作分解结构（Work Breakdown Structure）WBS，大家根据工作分解执行项目活动，并在执行过程中及时反馈项目问题。项目管理的的主线是计划，抛开计划谈何项目管理？！

关于例会

在IPD试行之初，就要求各领域每周出周报，明确例会制度，这个团队建立和沟通的保证，现在又重回原来的老路上，但是仍然缺少具体要求。项目如果没有计划与方向，周报只是流水账。

关于培养

应该是结果导向，产品怎么样算成功？不是一个一刀切的标准，不同的产品应该有不同的目标要求，这在立项就应当明确。项目的目标及可交付的成果不应该是某几篇文档，而应该是什么样要求的产品。LPDT的培养应该围绕做好产品开展，完成项目目标开展，流程只是很小的一方面。QA在其中承担的也只是很少的一部分。

3 总结

集成产品开发应该是一个包含项目管理和质量管理的完整体系。开发只是其中的一部分，各个领域不仅要被打通，还需要各个领域自身的规范，强矩阵的模式不适合集成产品开发，如果各领域自身制度的建立，招聘培养都有产品线承担，那将是产品线不能使承受之轻。管理是产品开发中很重要的环节，不是活动不做就是减负，而是很可能会产生潜在不确定及混乱的过程。适度创新，稳步推进改革才是王道。  
\- 本文出自天天软件测试社区，原文地址：http://www.×××/bbs/thread-29885-1-1.html

[客户与用户需求浅析][Link 1]

转载于:https://blog.51cto.com/my365testing/701430

[Link 1]: http://my365testing.blog.51cto.com/1270598/701428