本文不包括基本职业素养,如学习能力、激情、敬业、沟通等。一家之言,仅供参考。

需求发现和分析能力

场景不停变化发展,用户需求是动态的,要求产品认知不断迭代,该能力的核心是识别定义需求场景和判断需求满足情况。通常通过用户调研报告、需求分析文档、需求评审文档、项目总结及述职等方式体现出来。

能力同时体现在数量和质量上:

1、数量是指用户需求被发现分析的个数。应考虑到产品不同的发展阶段,成熟产品相对初创产品,需求发现的难度要高,在数量的要求上也不同。

2、质量是指用户需求定义的准确性,包括考察人群覆盖比例,场景和需求的频次,满足程度,简言之是需求的性价比,而不只是需求发现的难度。

人群覆盖比率高,场景频次高,满足程度较大不足才应被纳入能力考察范围。极限情况下需求,用于考察思考完整性和深度,避免需求上的过早过度发现导致产品过早过度设计,造成资源和时间上的巨大浪费。

高质量的需求发现和分析,应符合以下三个要求:

1、直击本质

本质是指事物区别于其他事物,本身所固有的根本的属性。需求的本质指向某个普适性的心智模型,使得用户行为在具体的场景下可以被解释和预测,需求分析是理性科学的,可以被证伪的。避免用“用户偏好不同”来解释“用户行为不同”,“偏好”是个性的,分散的。任何偏离本质,流于表面的分析,都可以在“偏好”的指导下找到自己的解释力,这种万能说法伤害了需求满足的判断标准,使产品失去迭代进化的能力。

2、分析严谨

分析严谨的要求实际上包括了三段:

2.1、分析素材基于事实。分析素材的采集,要求准确(精确且完整,以可以支持分析为限,过于追求精确和完整将失去性价比)和客观(不参杂个人价值判断),是事实而非观点;

2.2、分析过程反映因果关系。需要强调的是相关性与因果性的差异,我们说统计上的正相关性,是指 A 与 B 同时增加或减少的情况,如泳裤与西瓜的销量同时上升,是相关性,而不是因果性。夏季来临,温度上升,人们消暑降温的需求增加,带来了销量增加,才是因果性。

2.3、分析结果可被重复校验。由于现实情况的复杂性,我们很难在每一个需求发现和分析中,都严格追求完美的因果关系,大部分时候,这种分析都是指用户在 A 的场景下,大概率会发生 B,重复多次,重复多人,都不改变这种概率或概率分布。

3、结论合理

应该意识到,结论是有前提条件的,结论指导的产品设计或商业实施,也应该是有可操作性的。假设一个三段论分析:稀有金属很值钱,月球上有很多稀有金属,所以去月球开采稀有金属能很赚钱。这个分析不严谨,结论也不合理,忽略了商业成本和现有技术条件。

从需求发现的深度上,可以层次分为:

1、发现现有产品对现有需求满足不足的地方,包括不限于文案、交互、功能缺失、策略疏漏、分支情况考虑不足等。

2、发现新的需求场景,通过延伸现有策略、功能、产品,可以满足此需求。1和2是基于现状的一种改良。

3、发现新的需求场景,通过新的策略、功能、产品来满足此需求。这是一种创新,容易产生新的业务增长机会,是需求发现和分析能力的最好体现。

从判断需求是否被满足的角度,可以层次分为:

1、不具备量化能力,依赖访谈和个人印象。

2、具备量化能力,量化方法有特殊性,仅用于严格同类型需求的判断。

3、量化方法具备可复制性,可用于指导同类型需求是否被满足的判断。

市场及竞品分析能力

市场与竞品分析能力的核心,是数据采集和结构化能力。通常通过商业分析报告、行业发展调研、竞品分析报告等方式呈现。

分析工具使用

包括不限于波士顿矩阵、波特五力模型、SWOT,使用成熟工具是为了清晰说明问题,依赖工具的分析,只注重了分析过程的逻辑性,而忽视了分析本身的目的是为了指导行动。分析报告是以观点为核心,而不是以使用工具的过程为核心。包含分析工具的报告,可以是这样一个结构:

分析目的 -> 观点 -> 证明观点的逻辑 -> 分析工具/模型对逻辑过程的支持 -> 实施代入分析工具 -> 结论 -> 结论的局限性 -> 校验结论的方法

分析质量

从分析内容完整性要求,应该包括分析目的、市场/竞品情况、对产品的影响广度及深度、应对方案、方案评估方法等。符合内容完整性要求的报告,可作为考察市场及竞品分析能力的重点,也可以针对不同类型的分析报告,设定不同的内容完整性要求。

从分析类型完整性要求,可以包括市场趋势、政策与法规影响、上下游产业链、外部渠道分析、主要竞争对手的规模变化与动作、主要竞品的特点与流程、潜在替代品分析等。产品经理可输出的符合内容完整性要求报告类型越多,越能体现相关能力。

从分析的深度上,可以层次分为:

1、描述型报告,描述市场上正在发生的事实,以及竞品的状态变化,缺少分析框架,主要考察数据收集能力。

2、评估型报告,除覆盖描述型报告的要求外,增加分析框架,可针对少数关键流程/产品特性/市场要素,准确评估外界市场环境和竞品变化对产品的影响。

3、对比型行业报告,除覆盖评估型报告的要求外,设计有针对性的数据采集清洗方法,构建分析工具和方法,相对准确做出中长期市场态势预测,对产品中长期规划提出合理化建议。

从数据有效性的角度,可以考察以下:

1、采集数据的来源和方法。数据来源的丰富性和数据准确性,直接影响到分析的质量,产品经理应掌握各类数据的来源,同时对数据来源的擅长领域、准确性、更新频次、覆盖范围等特点有清醒的认识。来源包括不限于数据分析工具、有关部门权威发布信息、研究机构行业报告、可信个人数据源。

2、清洗数据的能力。主要指从原始数据中分离对市场及竞品分析有用的数据的能力,熟练使用数据分析工具尤佳,包括不限于Excel、SQL、R语言。清洗思路通用性的价值优先于工具技能。

3、数据的呈现能力。数据除及时有效外,还应便于理解,市场及竞品分析中的数据可视化呈现及对分析结论的支持力度,也体现出产品经理理解和表达的能力,属非必要能力。

方案设计能力

业务的复杂性要求产品方案具备多样性,方案设计能力的核心,是抽象业务,并通过功能或流程满足的能力。通常在不同类型的PRD、分享、分析报告中体现。

从方案的类型区分,各种方案的难易度与业务场景有关:

1、靠近直接用户的交互功能设计

交互的操作步骤/操作时间,量化用户体验的方法可以通过搜索得到很多,不赘述;
功能对需求的满足程度,通过NPS考察,关键依然是需求的定义而不是功能点;

2、侧重业务流的操作流程设计方案

正向流程,节点明确,分支流程覆盖全面,使用业务流的各方角色任务划分清晰;
逆向流程,可从任意节点回退流程;
流程相对标准化,新增业务支持改动小;
作业模块简单可微服务化,针对同一要素的操作保持在同一作业模块中处理;

3、提高效率的策略/算法/模型设计方案

策略/算法/模型迭代产生的关键指标增长,在相似增长的情况下,简洁优于复杂;
可解释性高,可向非产品开发角色输出简化包装后的描述,方便理解;
从需求到策略/算法/模型的思考过程清晰,可输出到同类业务;

4、面向营销增长的运营方案设计方案

增长的结果,体现结果导向;
增长的性价比,体现经营思维;
运营方案的可重复性,体现抽象能力;
运营方案的特殊性,包含时机、目标人群、运营动作等,特殊性体现了产品经理对业务特殊性的理解;

5、涉及财务税务法务的支持方案设计方案

容易忽视的方向,通用性强,技术要求高,在考察时需要更多考虑协作方的NPS;
财税法相关的方案,考察数字准确性,对合规要求的支持程度和响应速度;
财务相关工作,存在相当多的可自动化的重复劳动,财务人力投入的减少,也可以作为考察指标之一;

对高阶的产品经理而言,除在方案设计上具备基本的能力外,还应当具备系统化视角,增加产品管理制度、产品架构设计、产品团队结构设计、商业创新设计等。

1、产品管理制度设计方案

包括产品方案设计的基本流程,文档模板,质量检验方法、评审规则等,这些制度设计风方案应当是被实施并取得相应效果的;
制度设计的实施需要得到开发等相关部门的支持,在考察中可以征求相关协作部门的意见;

2、产品架构设计方案

产品线之间的协同设计,考察产品线之间的交互模式;
产品矩阵之间的协同模式设计,考察产品是否形成逻辑自洽,市场反馈良好的网状结构,形成合力推动业务发展;

3、产品团队结构设计方案

产品团队的结构,需要覆盖产品架构设计,通过业务划分和梯队建设设计,在产品人力的投入上保证业务正常,同时需要考虑业务突然增长和人员意外流程产生的风险;
产品团队成长路径设计,在至少未来 6 个月的业务增长假设下,从招聘和成长两个维度建设团队。外部招聘时,可以通过对标内容明星项目和团队,考察高阶产品经理的团队建设方案能力

4、商业创新设计方案

产品反哺商业的方案设计,产品架构是否能容纳商业尝试的不确定性;
是否有产品机制保障商业创新;

方案难易程度的判断点:

1、涉及业务角色数量,难度与数量正相关。

2、涉及功能模块或系统数量,实质上就是方案适用场景的多少,难度与数量正相关。

3、涉及不可控要素数量,且方案可以限制不可控要素对完成度的影响。

4、方案的抽象性,可复制到其他业务场景的可能性越高,难度越大。

以上难易度的考察,受限于具体业务场景,难易考察创新型方案,可以通过建立“明星”方案作为参照物,得到方案的相对难度,逐步建立难易度量化能力。

方案执行能力

方案是否有效,说到底还是要通过实践来检验,执行是设计+实践+迭代的整体过程,执行能力的核心是资源利用和项目管理,项目管理类的资料和书籍非常多,简要说明。通常体现在项目结果中。

1、产品设计方案分拆,边界清晰,执行计划目标明确,milestone设计合理,执行过程可以被持续监督,不断反馈。

2、执行判断力,判断是否执行,判断执行优先级,取舍有方。对高阶产品经理,此项能力的要求更高,同时还需具备向上管理预期,平行协调沟通的能力。

3、产品设计方案资源估算准确,资源包括涉及角色、投入人力、时间等,无需求变更等特殊情况,误差应在10%以内。

4、产品设计方案对合作方的影响及协同方案设计实施能力,要求产品经理除自身负责的模块或产品线外,理解协作模块或产品线的运作方式,在方案设计及执行时,能大致评估出会影响到多少外部模块和产品线,并协调资源处理。

5、进度跟踪,迭代交付能力,重要的是不断反馈和调整,拿到结果。

以上几种能力的考察,主要是通过日常项目进度和结果,协作团队的评价进行。

对高阶产品经理,需要增加设计保证执行的工具,建立保障机制的能力。要求任何一个产品经理都克服一切困难,尤其是克服部门墙和职级差异造成的困难,是不现实的。在多人团队的协作中,除依赖个人执行能力之外,还需要设计和推动标准化流程和协作机制的建立,包括奖惩、指导、总结等环节,减少执行中的不确定性和不必要损耗。这种能力会降低对产品经理个人能力的要求,有利于产品团队产出质量。

商业能力

无论是 toB 还是 toC 的产品,最后都需要商业变现,或者是成为商业生态中的一环,支持商业变现。商业能力的核心是经营思维,通常体现在PRD和项目总结里的成本测算、收益评估等环节,日常工作中反映出来的财务思维也是重要考察项。

1、谈判能力。内部,通过目标协调一致;外部,通过共赢协调一致。谈判的结果,首先是达成合作,然后才是一城一地的得失计算。

2、财务思维。基本读懂财报,知晓复式记账法,了解现金流对公司经营的重要性,理解所有的资金都是有使用成本的,算大账超过算小账。

对高阶产品经理,理解组织的商业模式和收入模式非常重要。商业模式是我们为最终客户提供了什么价值,客户为什么商品付钱;收入模式是谁付钱给我们,让我们提供商品。商品与产品是不同的,整个商业组织的交付物,是交付给客户的商品,而产品经理所做的,是通过“产品”生产“商品”,因此,让“产品”容纳“商品”创新尤为可贵。

指导能力

考察指导能力,是指通过结果考察指导的广度和深度,能力核心是抽象总结和沟通。

指导的广度是指:

1、受指导的直接人数应超过管理的人数,即是指导范围超出管理范围。

2、能力建设和方法总结得当,具备普适性,可影响大部分产品经理,可以通过考察指导人方法论产出、专业领域的专利或业界口碑进行。

指导的深度需要从指导力度和质量来看。指导力度越大,耗时越多,与直接指导人数成反比;指导质量从被指导人的能力进步来判断,通常看被指导人承担项目的难易度增加和晋级情况。

指导力度可分级为:

1、动作指导。指导做什么事务,什么步骤,每一步的做法,指导者监控过程和结果。

2、战术指导。指导做什么事务,分解执行由被指导者完成,指导者评审方案和监控结果。

3、战略指导。指导做什么方向,战略节点、事务分拆都被指导者完成,指导者只监控结果。

4、目标共同体。具备战略建议和决策能力,自下而上提供战术战略,形成目标共同体,不再区分指导者与被指导者,而是合伙人角色。

执行层面的产品经理,应该具备动作指导下一级产品经理的能力,并接受上一级产品经理的战术指导。
有管理职能的产品经理,应该具备战术指导下一级产品经理的能力,并接受上一级产品经理的战略指导。
极少数的资深产品架构师,应该具备指导和培养产品管理者的能力,成为组织的目标共同体。

什么时候需要产品职级

能力的层级任何时候都需要,帮助我们定位自己;职位的层级可能带来高昂的管理成本,在产品团队规模较少,低于100人时,不要启动明确的职级划分。

在国内互联网公司的产品经理成长路径中,通常在对标阿里P7这个级别上,会出现一次P序列和M序列的分叉,一部分人走上了管理(M)之路,更多人走上了专业(P)之路。P序列的高级别,被称为"产品专家",或者是"产品架构师"。相对于能力更通用化,发展更成熟的研发线系统架构师,产品架构师的定位比较模糊,至少在实践中,工作内容与系统架构师有诸多重合之处。梳理产品架构师的内涵及外延,是一件有趣的事情,下面的内容都是我个人的理解,欢迎批判和探讨。

一、产品架构的一些问题

1、产品架构是什么

广义上,产品架构是业务结构的镜像,描述的是从实际业务中抽象出来的需求(子需求),和需求在如何通过在系统之中(子系统之间)进行交互,最终被满足的过程。

狭义上,产品架构是指需求和交付物之间的关系。

用下面一个表格来说明:

分层名称内容产出
业务交易(消费)结构客户表达并满足需求的过程和结果需求的定义
需求狭义产品架构需要什么交付物满足客户需求交付物的定义/配方
实现系统架构怎么在系统中生产交付物交付物生产工艺/流程

在实现层面,系统架构应该包括数据、业务/商务、运营、营销等整体业务流。

2、产品架构对组织架构的影响

组织架构变革在新零售话题中常常被提到很重要的位置,系统中台化趋势要求组织结构液态化,以响应商业环境和业务形态的快速转变;在产品架构话题中,组织架构和产品经理个人的成长却常常被忽视。

直接影响产品技术研发类组织架构,产品架构最后的交付物是系统架构,会切分好各子系统(子模块)之间的内容,PM和RD的工作内容和协作关系也随之确定。

间接影响整个业务流各参与角色的职责内容和协作关系,随着业务变化和系统改进,参与角色的工作内容甚至是角色本身,都可能改变或取消。

完成业务结构、产品/系统架构、个人成长三合一,是衡量产品架构是否优秀的一个重要视角。

3、产品架构的评判点

好的产品架构,应该是容器,提供空间(性能冗余/数据监控分析/损失管理等能力),容纳业务的不确定性(创新),是一种系统机制。

评判点也用一个表格来说明:

评判点内容
合理性需求(子需求)结构简洁,需求场景定义清楚;
子系统(子模块)高内聚松耦合,边界定义清晰,执行顺序可预知,系统交付物稳定。
前瞻性适应未来1-2年的业务发展,在业务变化快的情况下,至少适应1年的业务变化。
系统性结构上的横与纵:横-中台核心业务平台,纵-关键实施项目落地;警惕过度设计。

4、谁来评判产品架构

由于产品架构是需求间的关系和需求实现的过程,参与产品架构评估的角色,应包括具备业务抽象能力的业务方、产品、研发,以业务场景为基本维度。

5、产品架构设计实施的一般方法

产品架构与技术上的架构设计实施过程有一致性:

过程行为产出
商业诉求抽象产品需求
复杂系统分层基础通用能力和个性化作业
作业流程分治简单子任务工单
接口化中间层(中台实现)组合可演化的开放系统架构

乐高一般的开放系统架构应包括三个基本要素:

  • 组件/构件

    • 可复用的模块,尽量排除个性化的业务流程逻辑,排除过程。即是,内部信息流程不依赖外部模块处理,高内聚
    • 关注组件的输入输出,组件之间的信息流及媒介
  • 模式

    • 支持业务全流程的系统闭环的一组知识体系
    • 商业需求/客户需求被满足的生产交付过程
  • 规划

    • 对业务长期支持,设计未来整套行动方案

6、产品架构视角下的系统化创新

在业务发展的早期阶段,产品设计开发工作经常落后于业务创新,主要工作内容是响应和配合业务需求,产品经理及工程师,常常有疲于奔命的失控感,但这是一个基础设施建设的必要阶段。随着对业务理解加深及产品系统架构的完善,产品领先业务,进入系统化创新的阶段就会到来。

系统化创新常常以这样一种方式进行:

业务流程被抽象成为颗粒度非常细小的节点,通过四个方法(方法来自《简约至上:交互式设计四策略》)变成全新形态出现

  • 删除(自动化或智能化)非必要节点
  • 重组(有时是替换)为新模块
  • 隐藏支线节点
  • 转移节点到其他产品

二、产品架构师的一些问题

1、产品架构师是什么

产品架构师是产品团队内部的专业咨询顾问角色,深度参与到产品设计实施的全环节

  • 架构设计

    • 从业务诉求(商业诉求)中抽象需求,以结构合理的系统完成满足需求之交付物的生产,并使生产持续
  • 团队建设

    • 成为P序列产品成长的坐标和参考,为PM的专业序列制定能力模型阶梯及成长路径,提供产品专业相关的指导
    • 识别并培养具备产品架构师潜力的产品经理
    • 建立并维护适合架构师成长的规则及团队环境
  • 项目实施

    • 在实施层面的协调工作更多,平衡不同项目在方案上的投入产出
    • 分拆架构目标,落地到具体的项目实施中,确保架构目标/进度符合团队整体目标/进度

2、产品架构师职位要求

  • 对业务的理解

    • 理解业务全流程各环节,参与角色及其作业操作(包括管理)
    • 理解公司商业模式,所在业务线的商业模式及定位
    • 理解基础的技术实现
    • 行业趋势、产品方案趋势、竞争对手产品研究能力,关键是完成产品评价标准
    • plus-具备基本的财务/税务/法务知识
  • 对产品工作的理解

    • 具备探索并成功实施(规划/设计/运营/增长)创新方向的产品能力
    • 具备规划和部署产品矩阵,实现组织目标的能力
  • 对职级的要求

    • 应具备高级经理及以上的产品职级和能力,从内部培养效果更佳

3、产品架构师的工作方式

  • 产品架构师与产品执行负责人的协作

    • 架构师跨产品模块参与评审,为系统间交互提供符合架构设计的建议,尤其是在中台化项目中,重视流程;产品执行负责人确定具体设计及实施方案,重视细节;
    • 架构师对项目/系统目标负共同责任,以协商为基本前提,保留在对架构设计的最终决定权,同时承担最终责任;
    • 设置产品架构委员会,规避重大项目架构设计风险;
  • 产品架构师与技术负责人的协作

    • 产品架构师角色重需求抽象和场景定义;技术负责人重实现;
  • 产品架构师工作成果的评估

    • 落地项目的绩效
    • 产品、研发、业务团队的认同度调查
    • OKR及360度环评

4、产品构架师对PRD/MRD的影响

由于产品架构师重视中长期架构的规划实施,所以需要在PRD/MRD中强制增加以下内容

  • 数据流及模块I/O
  • 对不能严格控制的外部系统的依赖及交互,即是架构风险控制的内容
  • 系统目标的完成评估方法,重结果
  • 数据分析导向的监控和分析方法,重过程

5、产品架构师的晋级之路

下面的级别是从实施、变现、平台战略角度来说明,未必符合所有公司对架构师的晋级定位

级别核心定位
系统架构师设计实施符合业务流的系统间信息流
商业架构师结合财务税务法务知识,迭代和创新商业模式
生态架构师赋能行业生态的产品矩阵架构

在细分领域上,如电商、社交、工具、金融、人工智能等,都对产品架构师有非常高的专业要求,可以分别制定评分表来确定不同级别架构师的实际要求。

6、产品架构师的工作难点

  • 作为非管理角色,如何获知/参与业务目标规划
  • 作为规划型角色,如何平衡架构设计的长期收益与KPI的短期收益
  • 作为重咨询角色,如何平衡架构设计师与产品线负责人之间的产品方案及优先级冲突

三、市场中对产品架构师的描述

通过查看一些招聘网站,选择了两个case,来看看不同公司对产品架构师的不同描述,说明产品架构师这个角色,并没有整齐划一的刻板定义,对有志于在产品P序列向上发展的产品经理们,在自己特定的业务和组织场景中,都可以形成有特色的产品架构师成长路径。

百度中台产品架构师

职位说明:

- 负责百度知道内容tag模型和用户画像建设,支持多端产品的推荐工作

- 负责百度知道内容及用户反作弊工作,及内容审核工作

- 负责百度知道整体数据平台建设

- 负责百度知道相关的中台业务工作

任职要求:

- 5年以上产品经验,有搜索、推荐、内容等平台型用户产品经验优先

- 逻辑分析能力强,计算机、数据分析等理工科相关专业优先考虑

- 工作积极主动,抗压能力强,快速学习,踏实认真,有责任,具有优秀的理解、沟通与协调能力

京东金融解决方案产品架构师

职位说明:

- 从事部门创新产品的产品管理和产品经理团队管理;

- 负责核心产品的产品创新、设计、规划和运营;

- 组织内部、外部资源完成产品开发和推广;

- 指导产品经理团队完善产品分析和设计;

- 对内外宣传产品特性和价值;

- 培养产品团队成员能力;

- 横向沟通项目相关的产品、售前以及商务部门。

任职要求:

- 本科及以上学历,计算机或相关专业;

- 5年以上to B的计算机服务类产品运营经验,有互联网、金融等行业经验优先;

- 具有产品设计、组织研发和运营的能力;

- 良好的沟通能力,具有对外客户产品售前支持能力;

- 具有团队管理和提升的能力;

- 具有创新精神和创新意愿者优先。

四、结语

如果觉得我写得还有一点道理,欢迎留言沟通或邮件沟通sluke[at]qq.com,说不定有机会在互联网产品工作上合作,一起成为更好的产品经理。

业务符合需求,组织适应业务,系统镜像业务

从用标签区分客户到用户微粒数据镜像客户,需求越来越细节和个性化,要求组织、系统、产品都要相应变革

PM的工作有新目标:

  1. 信达雅翻译业务,用系统镜像业务
  2. 用成本低的系统试验变化,反哺业务创新和组织变革

mid-stage-position-1

系统分层,强化中台,业务也是一个操作系统

Google 的实验性操作系统 Fuchsia OS,设计了一个四层结构,可以用来帮助理解业务系统的前中后台划分。

中台,是通过信息流、资金流、物流来反映商业全生命周期的枢纽

强化中台,可以理解成强化对业务变化的反应能力,要求组织柔性化液态化,系统功能粒度更小,应用方案更丰富(类似应用市场中的 APP 更多)

中台系统PM重点关注:

  1. 客户最后获得的交付物是商品+服务,是一个漫长过程,结束不在商品交割的一刹那
  2. 中台有所有数据的最终版本,需要保持一致和完整

mid-stage-position-2

变化发生在用户第一线,就像是果实和种子

一线的业务细节变化良莠不齐,中后台的感知经常滞后,中台化在加强感知能力,面对不同的业务驱动模式,PM的定位也有不同

资源驱动阶段:面向新兴市场,向外求增量
管理驱动阶段:面向饱和市场,向内求优势
创新驱动阶段:创造新物种

mid-stage-position-3

做系统的股东

组织里的各种角色都在为业务服务,接近客户的还有销售和运营,接近系统的还有研发,PM是组织里的中台。

销售、运营、研发的工作相对于PM,容易评估,他们是系统的债主,先拿走确定收益率的回报。PM是系统的股东,拿走剩余的收益,要求PM的主人翁意识要强于其他角色,因为有潜在的超高回报收益。

背景:

为适应不断变化的业务形态,各大公司纷纷提出中台战略,强调虚拟小团队的重要性,推动组织形态从树状固态结构向网状液态结构变革。虚拟团队依据非常具体的业务建立,周期短,人员变化快,传统的“上级命令-下级反馈”的管理方式变得成本极高。

基本问题:

人员在复杂协作网络中的节点重要性评价

基本假设:

  • 工作群(或其他因任务而存在的人群聚合体)是协作的一种表现
  • 单个人员的时间是固定的,通过工作群对外联系(链接)
  • 单个人员间对外链接的强度与链接数成反比
  • 多个人员之间的链接,由多个工作群产生关系叠加形成(将所有工作群视为平等关系)

使用pagerank算法得到人员在复杂协作网路中的重要性

  • 人员类比网页
  • 人员之间的联系类比网页之间的链接

需要考虑的问题:

  • 因为角色的不同,在协作网络中的重要性表现不同
  • 因为级别的不同,对协作的实际影响不同
  • 因为入职时间的不同,影响链接数

对策:

  • 相同类型的角色做对比
  • 相同级别的角色做对比
  • 相似入职时间的员工做对比

使用场景:

  • 同一个人员在时间维度的上重要性动态变化,描述成长曲线
  • 同级别的人员,在相同时间区间中的数值,作为工作重要性的参考
  • 相似入职时间的员工,描述成长速度

潜在场景:

  • 提供另一个维度的人力成本定价
  • 为新加入的人员设定默认值和重要性成长目标

只是一个思路,有资源有时间有兴趣的可以算算看结果

OFO的押金问题是最近几天的一个热点事件,有些朋友提出了使用区块链技术的解决方案,我想换个角度来思考,就是设计一个“云押金”服务,核心逻辑是:“信用不够,押金来凑”

金融是基于信任的生意,当红的创新都是通过技术和数据,让陌生人尽可能块且成本低的方式形成共识,达成合作。我们还有一种古老的形成共识的方式,就是“押金”。

信用与押金的比较

大数据征信有诸多好处,但是我想提一些缺点:

  • 形成信用的成本高
  • 有个人隐私泄漏的风险
  • 增信困难
  • 机构之间信用模型差异大,难以迁移

押金完美规避这些问题:

  • 货币是人类共识
  • 现金是匿名的
  • 增资容易
  • 同一个货币无差别,不同货币可交易

押金的缺点

押金是对风险的估价,多个合作就要多个押金,缺点是资金占用成本高,且收到押金的一方有挪用可能性,监管难度大。

“云押金”对押金模式的修正

“云押金”将一笔资金放在金融机构的账号中,锁定金额。在需要信用或者押金时,授权服务提供方可以在违约情况下划扣押金。多个服务提供方可以获得对同一个押金账号的授权,在押金不足以覆盖风险时,云押金金融机构要求补充押金,同时拒绝新服务方接入,通知其他已授权服务方。到这里,还是只是一个常见的“保证金”模式,并没有降低资金占用,下面要开始组合式创新了:

  1. 提供云押金金融服务的机构,可以在用户授权的情况下,使用押金做投资,比如接入相对安全的货币基金,让押金增值,为客户带来收益
  2. 使用区块链技术,让服务使用信息上链,部分解决隐私问题,通过智能合约来处理违约扣除等情况
  3. 由于货币无差别,用户押金可以在多家机构之间迁移,同质化竞争迫使云押金提供商提高服务水平
  4. 押金是集中的,金融监管的难度变低,也容易形成标准化的技术服务和金融服务

进一步推演,以降低个人押金金额为目标:

  1. 形成类似支付宝“相互保”以及“水滴保”这样的互助机制,极大降低金额,分摊押金风险,代价是“押金”是有损失的,可以通过投资回报来弥补
  2. 引入真正的保险来保证云押金的安全,同时降低押金金额,保障需要押金的服务提供方的利益
  3. 形成信用+云押金的混合模式,“押金不够,信用来凑”

“云押金”金融服务商的收入

实际上,银行是比较适合提供这样的服务的,所以商业模式非常清晰,可以收取服务费以及投资收益。

远景

让信用+云押金的混合模式,结合区块链技术被市场广泛接受后,带来一个直接后果,就是在海量的交易中,信用和个人数据会被更准确定价,为信用在个人之间的交易形成基础,在这个远景下,人人有信用,信用可定价可交易,信用押金自由配比互换,陌生人交易费用更低,交易又会刺激市场更重视信用,正向循环。