继续思考一下产品线管理模式下产品平台的维护策略，除了在互联网产品线管理模式思考2：产品平台的维护策略中提到从统一架构、统一变化入口、定期重构、管理支撑等手段外，尚有很多现实的问题没有得到有效解决，尤其是研发体系相关的问题，先记录下来，慢慢思考，例如：
1、怎样避免产品平台运营过程中“弱产品、强技术”的困境，最熟悉平台产品细节的人员不是产品人员
而是技术人员，最终导致平台的运营是技术驱动而非产品驱动、市场驱动。
2、产品平台技术维护团队培养与成长问题，怎样保证产品平台维护的核心团队稳定性，但同时避免“大厨式研发”、“牛人研发”问题。以及产品人员、技术人员等平台维护人员职业发展通道问题
3、产品平台中技术支持的定位、扮演的角色，怎样发挥出技术支持作为客户代言人的核心价值，而不是停留在低层次的技术答疑上
4、产品平台团队知识持续积累并传承问题，怎样营造学习型组织气氛
5、矩阵式组织机构在产品平台管理模式下优化问题，怎样达成职能专业化与跨功能整合之间的平衡
6、产品平台维护中敏捷性与整体规划下的流程化的平衡
这里先思考比较典型的问题1，其他有空慢慢思考。
导致问题1的主要原因主要如下：
1）、没有建立起适合自己公司实际需要的产品研发体系，尤其是针对产品线模式下的研发体系相应的调整。或是僵化生搬硬套CMMI、RUP，但最终因 繁琐而导致流程流于形式，或是以所谓的“敏捷开发过程”来为自己的无规划、无设计、无文档、无注释、无评审找理由（此种精神很符合party按照自己的需 要来定义所谓的国际惯例、中国特色，可以称之为“和谐版本的敏捷开发过程”）。
2）、在战略层面及产品层面对产品平台及产品没有合理的规划过程，所谓的战略家们画上几个ppt忽悠一遍就说产品思路已经很清晰了，只差产品细节设 计了。而产品人员与战略家们飘在空中的思维始终搭不上界。战略与产品实现始终是两层皮，产品成功了是战略的成功，产品失败了是产品研发的问题
3）、产品经理能力较弱，对产品需求并没有完整的规划和分析过程，只停留在简单的需求传递上。或是没有需求文档或是只言片语的需求描述，对于产品具体实现细节并不清楚，产品实现基本上由技术人员代劳。
4）、技术没有明确的分析设计过程，相关的产品设计文档缺失，对于业务实现细节只有程序员查代码才知道，所谓“代码是最好的注释和文档”
5）、QA没有对产品明确的业务测试用例，即使有也只是停留在简单的功能性测试上。每一次上线都是技术人员告诉测试要点和测试步骤，测试只是重复一遍技术人员的测试过程。
6）、在日常运营中，由于没有相关的产品支撑工具，例如使用文档、产品销售工具包、接入文档、二次研发指南、产品FAQ、产品知识库等，所有的问题 只有技术才能最终排查清楚，于是乎销售人员、技术支持、产品人员、运营人员等都养成了对技术人员的依赖症，所有的问题都直接交给技术来处理。产品人员对于 产品状况不是很清楚，对于用户的痛苦没有切身的感受，于是乎也没有动力和压力去持续优化产品。而技术人员在新功能开发与日常的维护支持中挣扎，也没有精力 去优化产品、完善相关支撑工具
7）、对产品没有持续规划和持续重构的心理预期，战略家们指望一次性的规划和一次性的研发能够做出完美的产品，无法理解和容忍一个产品需要持续不断 的重构和规划。其实对于互联网产品而言，持续有序的规划、反思和重构是敏捷响应市场需求有效的竞争手段。对于大部分公司而言，在严重缺少优秀的战略人员、 产品人员、研发人员、运营人员的情况下，可以通过持续规划和持续重构来降低单次研发风险。其实问题的核心不在于一次还是多次规划或重构，而在于规划和重构 过程是否有序、是否符合产品研发内在的节奏、是否能够持续改进
综上所述，问题1的出现并不单纯只是技术人员、产品人员的问题，而是整个公司产品研发体系不畅的问题，在如上每一个环节如果能够做到位都可以弥补因“弱产品、强技术”导致的各种问题。对于产品线模式下的研发体系继续思考中。
