产品管理方法论(下):规划的逻辑 & 研发的架构

admin 2022年12月23日23:07:39评论51 views字数 8710阅读29分2秒阅读模式

如何打破产品战略规划的神秘感和主观色彩,让其有据可依,让大家都能理解?同时,在数字化转型之下,传统的产品研发管理模式是否还能适配,需要如何转型?这是本文所阐述的两方面重要内容,篇幅较长,请耐心阅读。

第四篇规划的逻辑

白日    周丹

谈起产品战略规划很多人认为这是拍脑袋的事或者认为这是艺术家的活写这篇的目的是让产品战略规划这件事更科学更严谨更有逻辑让更多人看得懂理解得了

1. 战略的核心

要支撑战略决策和承接战略落地就要先理解战略谈起战略大多数人认为是神圣不可及的事尤其被某些咨询公司冠以“高度视野格局”等词汇之后战略更被认为是“肉食者谋之”高高在上的事然而抛却华丽和神秘的外衣战略的核心就是讲清楚两件事干什么事”和“怎么赚钱”翻译成战略词汇就是业务闭环“商业闭环”且这两件事各有三个灵魂拷问对于业务闭环来说需要回答三个问题做什么不做什么为什么是我做why me)?对于商业闭环来说需要回答另外三个问题干这事怎么赚钱我赚哪部分钱为什么是我赚钱why me)?

图 8 战略的核心

这六个问题当中这里只强调一个“不做什么”无论做企业还是做产品一定要有边界意识知道自己擅长做什么不擅长做什么擅长的地方就努力做精不擅长的地方就通过生态对接然而国内大多数企业很难守住自己的业务边界认为这也能做那也能行于是造成市场上大量重复且低劣的轮子上篇提到的产品生态策略其最大阻碍通常来自于研发部门的两句话这个我们也能做那个我们也有不信你可以问问研发

2. 需求究竟从何而来

当企业把上述六个问题想清楚弄明白之后就到了怎么做的阶段分解到产品战略规划就是要依据战略长期方向明确相应的产品方向性需求或称产品体系需求),进而根据产品方向性需求设计产品总体规划或称产品体系规划)。那么产品方向性需求究竟从何而来呢?

a. 对于这个问题,大部分人的第一答案是需求来自客户和市场。然而,长期靠客户和市场指导产品需求的通常是项目型企业,因为此类企业的业务模式就是客户说什么就做什么,客户要什么就满足什么,只要客户给钱就行,所谓的产品就成了一个个定制化项目;诚然,市场头部具备前瞻视野的客户可以提供大量有价值的前瞻性需求,但对于企业而言,并不清楚这些需求的本质以及背后原因和发展脉络,只是被动的响应这些需求,把这些需求做出来而已,企业和产品只知其然,不知其所以然,长而久之,项目型企业就逐渐沦为客户的人力外包团队;

b. 有人认为需求来自竞争对手。别人做了什么产品,产品发布了哪些功能,自己就跟着做,但长此以往,就会丧失产品的创新本质以及差异化的能力,最终导致产品同质化严重,最后不得不在低价中搏杀;

c. 还有人认为需求来自行业研究报告或者行业标准。行研报告通常是对行业现状的总结和发展趋势的预测,能写在行研报告中的,一定是已经有人在做的,并且做成的事情,对于产品跟随者而言有一定的参考价值,但能否超越早期对手,取决于对行业最前瞻方向和需求的理解认知;行业标准是业内多家企业所达成的交集和共识,事实上是所有行业产品必须满足的最小需求集合,因此行业标准只代表了产品的最低合规需求。

事实上上述这些需求都是产品的表象性需求那么产品的核心需求究竟从何而来如何才能挖掘到产品的核心需求呢这里就引出了一个关键话题规划的逻辑

3. 规划的逻辑

总体规划通常分两步走第一步是定义“演化的过程”明确演化方向划分发展阶段标识属性特征推导演化结果“预见未来Foresee the Future第二步是基于“预见”的结果定义“体系的架构”分析内部属性分解外部特征构建模型框架设计体系架构“定义未来Define the Future

产品管理方法论(下):规划的逻辑 & 研发的架构

图 9 演化的过程

总体规划中最具挑战的其实就是定义“演化的过程”大家一定会问如何完成“演化过程”的推导和实现“预见未来”的能力答案是“大胆假设小心求证这个过程不仅需要感性思维的想象力更需要理性思维的逻辑大胆假设的想象力因人而异不可言传但小心求证的逻辑还是可以用模型解释清楚的其核心思想是矛盾论事物是由矛盾构成的矛盾是事物发展变化的根本原因可以通过分析事物的矛盾要素推导事物的演化方向和演化结果这里把从一个事物从节点A到节点B的演化逻辑抽象为如下三个过程

图 10 演化的逻辑

a. 抽象

将一个事物在节点A的各种现象的关键特征进行抽象不是总结也不是归纳),还原其本质

b. 演绎

基于事物的本质对事物在节点A进行矛盾分析找到其内部矛盾和外部矛盾以及主要矛盾和次要矛盾所谓内部矛盾和外部矛盾就是影响事物发展的内部因素和外部因素所谓主要矛盾和次要矛盾对应的是各类因素的重要性和优先级

矛盾是推动事物发展的根本动力主要矛盾居于支配地位、对事物的发展过程起决定作用因此进一步对内外部主次因素进行分析和推导可推演出事物接下来的发展方向和发展结果由此可得到事物的下一个发展节点即节点B

c. 分形

较之节点A节点B的内外矛盾和主次矛盾又发生了新的变化围绕这些新的矛盾要素一定会呈现众多全新的具体场景和表象现象),节点B的内部要素及其各类外部场景和表象一起构成了事物在节点B未来的某个阶段的内部属性和外部特征

时时有矛盾事事有矛盾矛盾在事物发展变化过程中不仅会互相转化还会不断发生变化因此要时刻关注各种矛盾要素自身的发展和变化不断评估事物演化的过程和结果重复上述过程不仅可以完成事物从0N的完整演化过程的推导又可以完成各阶段假设结果的求证此为总体规划的第一步“预见未来”规划的前瞻性正体现于此

总体规划的第二步基于“预见”的结果定义“体系的架构”分析内部属性是指根据内因找出事物的内部逻辑构成以及各构成之间的相互关系分解外部特征是指根据外因找出事物的各种外部表象和对应场景以及各种表象和场景之间的映射关系构建模型框架是指根据内部关系抽象出内在逻辑模型根据外部表象抽象出外在呈现框架设计体系架构是指根据内在逻辑模型和外在呈现框架重构出完整的体系架构“定义未来”

产品总体规划也是依据上述过程先通过演化过程的推导得到演化结果再以演化结果为目标对象完成产品体系架构回到本章节的核心问题需求究竟从何而来看到这里也就不言而喻了产品的需求核心来自事物预期的发展规律以及演化结果正确的产品需求来自对事物演化发展的正确判断市场和客户的需求只是事物发展到一定阶段的必然产物是最终验证规划预判和产品需求的方式好的产品一定是引领市场和客户需求的它会在不远的未来“等待”客户需求一步步到来等待”市场时机逐渐成熟

4. 进入市场的时机和方式

好的规划不仅能正确判断未来领域的发展方向和发展结果还能正确判断未来市场的启动时机所以说好的方向是规划成功的一半好的时机是规划成功的另一半做产品的目的是为了满足市场需求如果市场需求始终没有到来或者市场需求高点已过一定要好好反省规划的市场时机是否恰当过往有非常多优秀的企业萌生过很多有前瞻性的规划和想法但由于误判市场时机过早或过晚进入市场导致规划失效产品失败战略失败的案例比比皆是在这里我们依照市场生命周期根据企业进入市场的时机将企业划分成四种类型

图 11 企业进入市场的时机

a. 引领者

顾名思义企业早于市场看到了新的领域机会它引发创造了新的市场需求是市场需求的引领者是新兴市场的开拓者同时也是早期市场和早期客户的教育者属于上述引领客户需求一步步到来开创市场并引领市场逐渐走向成熟的先驱

b. 洞察者

在早期市场阶段一定会有对市场较为敏锐的企业洞察到来自新兴市场的机会并选择快速跟进一起推动市场从早期阶段发展到主流阶段属于对市场发展持有洞见的早期玩家他们捕获市场机会的方式可能来自早期市场的客户也可能来自第三方研究机构对新兴市场的分析报告等等洞察者也许很早也预判了同样的领域方向只是不确定市场到来的时机不想第一个吃螃蟹然而一旦市场出现声音他们就会伺机而动

c. 跟随者

一旦市场呈现爆发趋势跟风的企业就会越来越多他们或抱着分杯羹的心态进来参与或基于竞争策略被迫选择跟随或看到市场逐渐企稳向好市场技术日趋成熟此时进入市场风险较小林林总总最终众多跟随者共同助力快速将市场推向龙卷风暴和主街同样在这批跟随者当中仍然不缺少对领域有前瞻看法的企业他们愿意先观察着这个市场的变化以及赛道中各个赛手的表现待上述时机成熟再以生态投资并购赛手等方式进入市场

d. 滞后者

出于各种原因总会有市场判断和市场响应较为迟缓的企业此类企业或缺少远见或缺少资源或出现严重市场误判最终丧失了市场时机如果市场在自身业务边界之内同时又符合战略目标丧失机会就意味着自杀市场竞争犹如逆水行舟不进则退业务踏空可能面临整体被淘汰的风险

找准市场的方向和时机很重要进入市场的方式也同样重要企业或者选择躬身入局从产品研发一步步做起或者选择生态引入或OEM引入还可以选择战略投资的方式介入市场有甚者还会选择收购并购赛道上的选手进入市场等等不同方式每个企业对于市场机会Opportunity的判断进入市场时机Timing的判断以及进入市场方式Way的选择都不一样取决于企业的战略方向商业模式风险偏好经营策略竞争态势企业规模发展阶段资源配比、财务状况企业文化、技术路线等等一系列因素引领者未必能笑到最后也可能成为先烈洞见者未必不能将引领者取而代之跟随者未必不能赚的盆满钵满无论怎样企业首先要具备规划未来领域发展方向的前瞻能力其次再根据自身情况选择进入市场的时机和方式

由于篇幅有限上述理论在这里不便通过案例和实践展开看起来会觉得烧脑和干涩的确规划过程集合了一个人或一个团队的抽象思维逻辑思维以及体系思维等综合能力同时还需要大量认知和经验的支撑

第五篇研发的架构

白日    周丹

开篇讲过产品研发管理的职责是依据产品体系规划的要求对每个相关产品进行详细规划明确每个产品的具体需求并给出产品详细设计最后根据产品详细设计研发出所需要的产品解决产品“怎么做”的问题其核心是对接能力和需求传统产品研发管理所涉及的项目管理需求管理以及团队管理大家都非常熟悉了这里不多赘述今天在数字化转型之下传统的产品研发管理模式是否还能适配?需要如何转型?这是本篇所探讨的内容

1. 研发管理的挑战

传统研发管理过程中广泛存在三大挑战一是来自组织的挑战“混淆研究开发和定制二是来自业务的挑战需求响应三是来自人的挑战“代码艺术家”

a. 混淆研究开发和定制

我们一直在讲的“研发”事实上包括“研究”“开发”和“定制”三件事先说研究“开发”研究关注的是领域方向创新以及核心技术公关开发关注的是产品工程化虽同属研发体系但侧重点不同价值提供也不同然而大多数企业只重视“开发”和“定制”忽略或者混淆了“研究”没有研究企业找不到领域的发展方向产品会缺少创新动力失去核心技术支撑最终会被市场所遗弃再说“开发”和“定制”大多数企业认为开发就是按照用户的需求完成定制项目型企业这样理解没有问题产品型企业这样理解就会有问题核心问题在于无法区分哪些是领域需求哪些是场景需求哪些和技术有关哪些和业务有关因此如何对研究开发和定制进行区分和定位如何划分组织和团队职责如何在方向价值和目标上协同一致这是研发管理需要解决的第一件事

b. 需求响应

造成需求变更的原因有很多比如原始需求不清晰需求本身发生了变化不断有新的需求提出需求传递过程中出现信息偏差等等软件行业响应需求的方式主要依靠软件工程无论是瀑布模型快速原型极限编程还是敏捷开发等等其核心都是为了保证做出来的产品符合需求要求传统方式下大量的需求需要依靠文档的方式记录保存更新和传递项目团队需要花费大量的时间和精力确保需求理解的准确性完整性和一致性然而无论用哪种软件工程模式最终产品和原始需求之间总会存在或多或少的差异数字化转型之下需求产生和需求变更的频次会呈级数增长用户业务要具备敏捷性具备随需而变的能力传统软件开发和交付方式是否具备快速且准确对接用户需求变化的能力这是研发管理需要解决的第二件事如何快速准确响应需求

c. 代码艺术家

做过研发管理的人都知道每个研发团队中都会有一两个叫“张三”的关键人只要张三在出现重大问题就能搞得定项目就有保证老板就放心一旦张三不在项目马上就塌老板就心慌张三”是让研发管理者又惊又喜且又难以拿捏的一类人通常称之为“代码艺术家”代码艺术家在技术领域有很深的造诣是各类技术的带头人也是项目的中流砥柱但是项目的成功如果取决于代码艺术家的个人技巧和能力而不是依靠架构和体系力量的保障那么代码艺术家就会成为项目中的重大风险这样的项目通常不会长久这样研发的产品也会举步维艰因此研发管理需要解决的第三件事如何使用代码艺术家

事实上上述个三方面挑战并不是今天高科技企业才遇到的传统工业化时期就遇到过同样挑战并且工业化时期的成熟工厂模式已经给出了解决方案大家是否留意国内大多数开发都是面向成品的开发方式也就是说需求描述的成品是什么样子研发就按照什么样子进行开发而国外大多是面向工厂的开发方式也就是先造机床先建产线再把零件和流程打造好最后完成面向成品的装配同样的机床同样的产线今天生产汽车明天生产坦克这种方式在早期投入的成本比较大但是工厂一旦完成其生产效率和对接各类需求的能力会极大提升早期手工作坊和现代化工厂的差距可以说明一切工厂不仅是将能力和需求对接制造产品的地方同时也是将创新和工程技术和业务系统和人进行解耦的一种架构方式这种模式同样值得研发管理学习和借鉴

2. 研发的架构

综上研发管理可以通过以下三方面的架构调整实现创新和工程技术和业务系统和人的解耦用系统和科学的方式解决上述三方面挑战

图 12 研发的架构

a. 组织架构将创新和工程解耦

从组织上有人要研究设计何种工厂机床流程零件以及如何设计有人要建造厂房机床和产线还有人要生产零件调整流水线最后还要有人完成组装因此从组织架构视角一个研发组织可以划分成核心研究生产开发以及定制集成三个部分

核心研究偏向领域细分研究以及核心技术公关创新型组织Innovative Group关注的是创新能力最终关系到企业的领先性和竞争优势而生产开发和定制集成偏向技术工程化Technology Engineering和业务工程化Business Engineering工程化组织Engineering Group关注的是生产力质量成本效率和交付能力等虽然前者会给后者提供能力支撑但二者的目标过程和产出截然不同因此研发管理需要从组织架构上对创新和工程进行解耦把研究和开发定制划分开

图 13 研发的组织架构

b. 工程架构将技术和业务解耦

工厂的生产开发部门需要考虑如何构建机床和产线作为生产的基础平台再根据定制集成的需求快速生产相关零件调整相关流程最后由工厂的定制集成部门把相关零件按照相关流程装配成所需的成品交付给用户大量的基础平台工人零件工人和流程工人不需要关心成品的样子只有定制集成部门才需要看用户的成品需求设计图纸然后分解所需的零件分解装配流程分解项目管理和质量管理等要素最后完成成品装配

虽然生产开发和定制集成都是工程化组织但成熟工厂体系已经将两者进行了剥离生产开发侧重技术工程化与领域需求相关这些领域需求来自产品战略规划输出的演化过程和演化结果),负责将满足行业80%以上领域需求的技术能力封装成基础框架基础平台基础零件和基础流程等基础架构定制集成侧重业务工程化与场景需求相关这些需求来自用户的实际业务),负责对接上述基础架构和来自用户最后一公里的实际业务需求最终装配出成品

图 14 研发的工程架构

企业的生产开发需要由面向成品的开发转到面向基础框架基础平台基础零件基础流程等基础架构的开发然后交付给最懂业务的定制集成人员甚至是用户自己的业务人员再由他们完成最终的成品装配从而保证从业务需求到成品交付的快速对接和无损落地上述过程的核心是将领域需求和场景需求划分开从工程架构上实现技术和业务的解耦打破业务对技术的依赖让懂业务懂需求的人直接参与业务的构建和实现将需求快速并准确地转化为成品想到即做到让业务人员专注业务本身而不用关心技术实现

在上述过程中与产品相关的研发管理主要集中在生产开发环节产品研发经理需要根据产品体系规划的要求完成基础框架基础平台基础零件以及基础流程等基础架构产品的需求细化以及详细设计由于这些产品的需求和设计与技术能力承载相关与用户具体场景无关因此产品研发经理不仅要具备高度的解耦能力和抽象能力还要具备扎实的系统架构能力

另一方面对于定制集成人员或者用户自己的业务人员而言要通过业务工程化将上述基础架构和实际业务需求快速对接完成成品定制集成过程的最大挑战来自于需求结构化原始需求是混沌的杂乱的没有条理的只有将需求结构化理清业务边界业务构成和业务逻辑才能实现对业务需求的准确和快速响应

c. 技术架构将系统和人解耦

代码艺术家擅于使用技术技巧解决难题这种能力非常适合技术研究领域然而在工程化领域试图通过技术技巧解决复杂系统问题反而会引入更多新的问题一来二去系统复杂度反而会成倍增加人和系统的耦合度也会越来越高解决复杂系统问题的方式有很多架构无疑是最科学的方法架构的核心是解构抽象和重构先将复杂系统解构成多个原子构成再抽象成简单模型最后基于模型重构体系架构是将复杂系统简单化的有效方式

通过上述工厂模式在组织层面和工程层面的解耦事实上已经把大型复杂系统解构并降维到多个简单场景和环节对全栈型代码艺术家的依赖已大幅降低但是在技术层面仍然需要通过技术架构对每个场景和环节的具体问题进一步解构和降维降低问题的复杂度和难度,从而降低岗位对个人技能的要求,张三能干,李四王五也能干,从技术架构上实现系统和人的解耦,完成复杂系统对应的大量岗位只需要熟练工,而无需艺术家这种方式不仅可以保证系统的成功,同时也将个人对系统的影响降到最低

3. 数字化转型的挑战

事实上工业化时期催生并运用了大量系统工程和管理科学的方式方法上述三方面的架构思想也是工业化时期的产物在今天看来并不是什么新鲜事然而相较成熟的工业化管理当前的研发管理还处于相对早期的发展阶段还存在大量作坊式的小团队上述架构思想仍然值得我们借鉴和学习因为接下来的数字化转型会改变传统的生产力和生产关系就供给侧而言数字化转型对传统研发的影响一定不亚于工业革命对传统工场手工业的影响传统研发模式也一定会被数字工厂模式所取代与数字化转型关系巨大的软件行业一定会走上软件工业化的道路企业要数字化转型支撑转型的研发供给侧必先践行数字化转型如果研发自身从组织管理到技术都不知道如何理解和实践数字化转型给客户谈数字化转型就是一句空话

结束语

上述五篇文章均来自过往20多年相关工作的积累总结和抽象尝试以产品为金线将企业战略规划研发管理和市场营销三大体系的有机串接起来并实现企业资源的优化配置旨在让更多To B领域高科技产品企业知道如何构建并管理完整的产品管理体系了解产品管理对一个企业的价值和意义同时也让更多人清楚企业资源配置的决策依据熟悉产品市场营销的一般策略揭开产品战略规划的神秘面纱并且打破产品研发管理的传统认知

图 15 产品管理方法论

数字化转型的暴风雨即将到来既是一场革命也是一场机遇企业能否承受住未来的钢铁洪流顺应时代发展的趋势一定是让每个企业负责人或焦虑或兴奋地睡不着觉的问题

本文只着重介绍产品管理的体系框架和方法篇幅有限相关案例和实操这里不做展开有兴趣的朋友欢迎私下联系讨论可公众号留言或加个人微信:PEPSI_NJ

借此感谢我最尊敬的良师益友童宁先生童宁先生是产品管理领域的大师是我进入产品管理领域的带路人他教给我很多产品管理的理念和方法非常乐于分享自己对于产品管理的理解观点以及实践经验感谢童宁先生对本文核心思想和体系框架的指导和建议其次感谢我入行时遇到的恩师彭涛先生虽然在一起共事只有短短几个月时间其体系化和架构化的思维方式在我工作二十余年中一直深深地影响着我并让我受用至今感谢他对本文的审阅以及宝贵意见同时感谢本文的合作者周丹先生周丹先生拥有近30年的银行工作经验在金融科技领域研究颇深对事物的抽象能力对本质的洞见能力对分析的逻辑能力以及对未来的预见能力让我受益匪浅同时为本文的关键理念方法和模型的形成提供了至关重要的指导和建议最后感谢2022这个充满变幻的一年

余不一一

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年12月23日23:07:39
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   产品管理方法论(下):规划的逻辑 & 研发的架构http://cn-sec.com/archives/1479020.html

发表评论

匿名网友 填写信息