企业想建构数据驱动文化,这五点一定要做到!

总的来说,如果高管希望他们的企业文化能够成功转为数据驱动的文化,他们需要采取一种超越数据工具本身的整套方法。这些转变不是依靠简单的努力就能达成的,但在当今这个混乱的时代,数据驱动的企业文化是必不可少的,而且是非常值得为之付出努力的。

五. 数字化企业的简单和复杂

简单方式: 其实要实现数字化企业的简单方式就是让信息通过各种方式流动起来,这种流动可以跨企业,跨职能部门,跨管理层级的。我们不用关心数据的内容,也不用去试图控制数据流动的方向,让数据的流动向市场经济一样,向地心引力一样,自然的按需的流动。数据生产者和消费者可以自由交换数据,我们需要做的仅仅是构建一个数据交换市场。这就像是为什么企业里员工人数越多,企业运转效率越低,而城市里的人口越多效率却越高的原理一样。其实企业中简单的数字化企业中只需为企业的参与者提供一个宽松的环境,让他们能畅所欲言,积极交互想法,让信息在企业和客户中流动起来,数字化企业就成功了一半了。例如:有一个宽松的论坛,论坛采用匿名方式不管员工在里边发布的是什么吐槽,抱怨,谩骂,赞美等,只要不发违法行为,企业就不用去控制和管理,让论坛自己去运转,我们可以看到这样的环境会使信息交换的更加有效率。

再例如: 我们可以在上班时间按照一定算法自动计算出需要最需要肢体活动和最需要沟通交流的部门(财务人员和生产人员等),最有矛盾的人员(研发人员和测试人员等)并自动推送聊天任务,让很多缺乏了解的部门人员5,6人一组在某个时间聚集在公司附近的某个区域,呆上10分钟,企业并不用关心他们聊聊什么,他们有没有再谈与工作无关的事,只是给他们一个可以相互了解的机会就足以促使企业生产效率的提升。

复杂方式:数据内容的解析,认知和智能决策是复杂的,我们通过对企业内部,外部的大量数据人为干预,预定义大量数据使用流程,场景,预定义各种可能的数据生产者和消费者,寄希望对各种数据使用的可能性进行枚举来完成对于数据驱动实现信息的交换,这样的投入和代价都比较大,灵活性不够,往往实践经验是预定义流程永远也满足不了实际客户的业务需求。

而在《诚实信号》一书中指出:与内容无关的互动模式可以准确测量想法流和决策。我们关注的互动的对象,频率和方式用简单手段也可以达到预期。

质量保证手段

有了高效稳定的流程,剩下的事情就是如何保证产品在快节奏的持续交付下的保持很高的质量。质量保障上面手机淘宝研发团队做了几方面事情:

1. 流程方面

1)创建了提测单、集成单、发布单等流程。建立了标准,并依托平台自动检查,提高了交付的质量。

2)建立持续集成体系,不但能提早发现更多的问题,而且提升了测试人员拿到的包的质量。

3)建立线上线下监控分析体系。

2. 包稳定性方面:

1)bundle阶段根据项目进度自己控制提测包的频率,集成阶段每日验证DailyBuild即可,所以解决了之前测试同学不断安装新版本的包的问题。

2)研发阶段的包内部支持环境切换,这实现了只构建一次,环境根据配置切换的梦想。测试时手机上只需要安装一次包即可完成多种环境下的测试。

3. 自动化测试与测试工具方面

1)引入多种静态扫描引擎,并定制多种规则:适配规则、Crash规则、框架约定规则、安全规则等,并且不断地将测试阶段、线上问题等总结抽象成新的扫描规则补充进入扫描引擎。

2)在测试阶段包种插入相应的测试SDK,并且这种SDK不会侵入应用代码,所以只需要在发布的时候去掉测试SDK即可。测试SDK可以在测试人员(包括外包适配测试人员)正常使用过程中自动检测并上报问题,这样就可以在同一的平台上看到研发过程中的质量情况并进行修复。

3)自动化平台方面也在根据测试经验不断的进化,在整个研发过程中自动化测试一直在执行,不仅可以提高产品稳定性,也可以发现性能、电量等非功能问题。

4)mock工具、验证平台等辅助测试工具也提升了测试人员的效率。

4. 线上线下监控分析

1)线下质量数据、线上业务问题、舆情反馈等信息统一汇集到平台上进行统一的分析告警,不仅能快速的发现问题,而且能通过数据分析能够帮助快速定位和解决问题。

2)根据平台中的数据,可以用经验推动流程的优化、补充测试用例、添加扫描规则、增加自动化场景、催生新的测试工具等,这样可以使经验形成闭环,使质量保障工作更加高效。

图片 1

在完成任务调整后的指标,检测平台并评估产品性能之后,您应该知道从哪里开始进行功能改进。

这不难理解,因为企业文化的转变本就是一项复杂的工作,而转变为一种真正由数据驱动的文化也不仅仅和技术有关,还和人有关。让我们来看看高管们需要在哪五个方面集中精力为变革奠定正确的基础。

六. 如何评价一个企业是否达到了数字化标准?

一直以来我们评价一个企业的好坏,往往是通过销售业绩指标来衡量的,例如:企业营收,利润等,而评价一个企业是否达到数字化标准,目前没有一个通用标准,我们其实可以用前面讲的观点来评测是否达到了数字化标准,这个标准不看企业有多少个系统,多少TB的数据量,多少流程被系统存储,而是看单位时间有多少数据在流动,多少数据在交换和他们的交换速率,这虽然不全面不过至少给了我们一个相对客观的评价标准,从技术实现上来看将企业的数据流动构建在Data Bus上通过评估数据在Data Bus上的流动速率和单位流动总量,来评估也更为容易,数据流动的速率越快,数据量越大就说明我们正在向数字化时代跨进。

敏捷中的QA日常活动

从迭代到发布,敏捷测试的生命周期各个阶段QA的活动主要有:测试分析,测试自动化策略分析、框架构建等,故事测试,迭代计划会议和客户演示,测试自动化的维护和执行等。如下图示:

图片 2

QA通常不是仅仅工作在某个迭代,而是并行的同时工作在多个迭代:要对当前迭代的故事进行验收测试、探索性测试,和开发人员结对实现测试自动化;还要和业务人员结对分析下一个迭代的故事,编写验收标准和测试用例。

图片 3

在单个迭代内部,伴随着故事生命周期,QA的活动有哪些呢?用户故事生命周期包括以下几个阶段:故事分析、故事计划、故事开发、故事验收、故事测试/探索性测试、系统测试和客户演示。QA参与故事的整个生命周期,在每个阶段都会发挥作用。

  • 故事分析阶段:需求澄清,业务场景和验收测试的确认
  • 故事计划阶段:拆分测试任务,在每个故事开发估算基础上考虑测试的时间和估算
  • 故事开发阶段:和开发人员结对实现自动化测试,和团队沟通发现的问题和缺陷
  • 故事验收阶段:开发人员开发完故事后,QA和业务分析人员要在开发机器上进行验收,以提供快速的反馈;同时还要对测试覆盖率(单元测试、组件集成测试、功能测试)进行确认和提出反馈
  • 故事测试/探索性测试阶段:执行自动化验收测试,执行探索性测试,强调会阻碍故事发布的因素,和团队就测试覆盖率进行沟通,为发现的缺陷添加自动化测试
  • 系统测试和客户演示阶段:执行端到端的系统测试,执行业务或集成的用户测试场景,和团队及客户就功能特性的质量和稳定性进行沟通,参与给客户演示功能和特性

正如前面提到的,在每个阶段,QA除了要独立进行测试,通常还需要跟不同的角色结对,包括业务分析人员、开发人员、以及客户。

图片 4

  • QA与业务分析人员结对:通常在业务分析师分析用户故事的时候,QA要与业务分析人员结对编写验收标准。通过与业务分析人员结对,QA能够更好的理解领域知识,从而有利于定义合适的测试用例;QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。
  • QA与开发人员结对:QA和开发人员分别能给团队带来不同的技能集,认识到这一点很重要。作为一个团队,最好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。通常在实现测试自动化的时候,QA与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高,有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分,而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。另一方面,QA通过与开发人员结对,编码能力也会相应有所提高,而开发人员通过与QA结对,测试意识也会增强,更有利于编写质量较高的产品代码,更有利于形成全功能团队。
  • QA与客户结对:客户是业务领域专家,通过与客户结对,QA能够更好的从终端用户的角度理解系统,从而定义或者增加更多的端到端的测试用例;一旦QA理解了领域知识和终端用户的观点,其业务价值分析能力会有所提高,在团队需要的时候可以承担业务分析角色;在用户验收测试(UAT)阶段,QA通过与客户结对,帮助客户熟悉使用系统,在必要时可以帮助客户解决一些系统问题。

敏捷QA的这些日常活动,的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。

敏捷QA与传统测试人员有何不同。我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面,来看看敏捷QA与传统测试人员有哪些不同:

传统测试人员 敏捷QA
单独的测试团队 多角色开发团队的一员
在开发流程后期才开始测试 测试贯穿于整个开发流中
通常是独立工作 QA和不同角色进行结对
被当作最后也是唯一的质量保证 关注并强调风险
缺乏与业务人员的直接沟通 和业务人员直接沟通
没有机会参与发布计划制定 参与发布计划的制定

从上表的对比可以看到,敏捷QA是特殊的,主要体现在:

  • 敏捷QA是提出建议者而非看门人,需要在参与的每个阶段提出自己的建议,而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求,还要发现需求是否能真正体现业务价值,分析是否有不恰当或缺失的需求。比如说,敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求,在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。
  • 发现风险,并将风险与团队及客户沟通。QA参与整个开发流程,对系统整体的认识和把握可以说是团队里边最全面的,因此也更容易看到系统存在的风险。
  • 及时向团队提供关于产品质量的反馈,便于调整。在每个迭代结束时候,QA需要分析统计该迭代的缺陷,并结合自己通过测试对系统质量的了解,及时跟团队反馈,讨论分析质量下降的原因以尽快作出改进,或总结质量上升的经验,鼓励团队再接再厉。
  • 在制定产品和版本的发布计划的时候,QA可以根据自己对产品质量的了解,从测试人员独有的视角提出一些关键的建议。
  • QA通过参与开发流程的每个阶段,能够协助团队从内部提升质量,让质量融入到产品开发中来。比如:在故事验收阶段对测试覆盖率的确认。

这些特殊性对敏捷QA也提出了更高的要求,需要做到:

  • 具有丰富的产品知识和对用户业务目标的准确了解
  • 对不同系统和数据库所用到的技术知识的了解
  • 和不同角色以及客户进行有效沟通
  • 主动验证质量目标并及时说出自己的想法
  • 编写测试计划,列出需要执行的活动并进行估算
  • 自动化测试的能力和对测试工具的基本了解
  • 在团队内部进行知识分享,协助整个团队参与到测试活动中来
  • 持续提供并获取反馈

不诚实或狭隘的指标。我将这些称为“虚荣指标”,因为它们使您的产品一目了然,但指标并不反映您的用户或产品的实际成功。虚荣指标的示例包括无意义的累积指标或费率(例如,没有营销支出上下文的顶级增长,或频繁的每月总登录,每个用户的每日参与是推动业务发展的因素)。

工具

“数字化企业”是一个既熟悉又陌生的词汇,

三、专项质量保障

(1)多副本分布式存储:旁路测试 & 线上数据检查,以数据完整 & 安全为使命

考虑灾备冗余、成本因素,云存储都会使用多个机房,跨机房的传输相比单机房的数据流动本身即增大了延迟,不同机房网络属性、机器性能等差异更对服务质量的保障提出了挑战。单一的机器性能测试已经不满足需求,需要引入旁路测试:复制线上的部署拓扑,进行等比例缩放,仿真线上的数据,在测试环境里重放,观察复杂部署和网络环境下服务的稳定性,辅佐一定的异常流量,评估系统的容错性以及灾难发生时预案是否能生效等。为更进一步保障数据的安全,对线上每日新增的数据较验各个副本的一致性及完整性。

(2)多机房 & P2P 流量架构:流量 diff 系统 & 实网系统 & 众测测速,传输速度体验

下载由源站IDC、CDN和P2P三部分承担,用户端、网络端、服务器云端的每一个环节都会影响速度。服务端的流量调度是根据用户地点、运营商网络、请求入口、文件所在机房、资源热度等多重属性对用户分配多个可带优先级的下载域名,让客户端充分并发及容错。多重维度的组合注定了调度策略的复杂性以及验证的难度,流量 diff 系统应运而生:在线下构造两套流量系统,一套线上代码环境,一套测试代码环境。通过回放线下真实流量,diff 前后调度是否符合预期,是否带来了非预期的变化。

三、最终

从质量标准、质量防线和质量闭环三个维度进行质量建设。首先对产品建立一套完善的产品质量标准体系,并将其度量化,固定成 benchmark。紧紧围绕质量数据,组建从用户(舆情热点)、端(产品体验)、服务器(稳定性)到基础网络(SLA)的实时防线,最后通过“上线管理—报警中心—智能定位—故障通报”的质量闭环环节落地,不断迭代优化。

产品经理通过创建”度量策略“可以帮助做出产品迭代的决策。

如今,几乎所有的企业都加大了对数据分析、大数据和人工智能项目的投资,企业高管们一致表示,他们正试图将他们的企业文化转变为以数据为驱动的文化。然而,只有大约三分之一的高管表示他们做到了这一点。

最近阅读了田溯宁的《数字化企业》读书分享文章深受启发,文章中提出数字化和数据化的另外解读这里边也提到了数字化和数据化的区别:

衡量软件质量的常用指标

软件开发实践过程中常用的几个衡量软件质量的指标,包括源代码行数、代码段/模块/时间段内的平均Bug数、代码覆盖率、设计/开发约束等

源代码行数(SLOC)

计算源代码行数也许是最简单的办法。它主要体现了软件的规模,并为项目的发展和规划提供了有用的信息。比如,如果我们每月计算一次源代码行数,那么就可以绘制一个项目成长图。当然,这种方式并太不可靠,原因是重构和设计阶段等因素会对此产生影响,但是至少可以为项目描绘一个趋势。首先,使用代码行数之和无法有效评估一个项目的实际进度,因为它更注重行为而不是结果。最终产品在多大程度上依赖于代码的性能和质量,这也是代码行数无法说明的。因此,聚焦于此实际上是非常有限的工作效率测量方式。SLOC无法表明要解决的问题的复杂性,也不能以可维护性、灵活性、扩展性等等因素来说明最终产品的质量。说到质量,它反而可能起到负面作用。通过重构、使用设计模式会减少代码行数,同时提升代码质量。代码量大,可能意味着有更多不必要的代码、更高不必要的复杂性、更加僵化难懂。

代码段/模块/时间段内的Bug数

缺陷跟踪对于更好的测试和维护是必不可少的。通过缺陷跟踪,我们可以利用报告工具(如Mantis)计算出每个代码段、模块或者特定时间段内的bug数量。凭借这些数据,我们可以尽早的查出和解决缺陷起因。Bug数量可能会作为衡量开发人员效率的指标之一,但是必须非常谨慎。如果把这项指标看得太重,那么开发人员和测试人员可能会成为敌人。在一个高效率的公司,所有的员工必须团结协作。为了更好地实现评估,bug可以被分为低、中、高等,因为这些缺陷的重要性和解决成本不是相同的。

代码覆盖率

代码覆盖率反映了程序当中源代码被测试的程度。有许多自动化工具可以完成该功能,比如Cobertura。代码覆盖率不能完全代表单元测试的整体质量,但是可以反映出测试覆盖率的问题。它可以和其他测试指标一起作为软件质量的指标。同时,单元测试代码、集成测试场景和结果应该经常地被审查。

有效的代码度量模型应具备以下特征:

  • 与组织的目标一致:代码度量模型的底线要与组织的要求一致,和业务相关的东西会体现在规范里。在支付宝,代码安全规范、敏感信息处理规范被作为代码质量最基本的要求。
  • 有针对性:要做针对性分析,比如对线上故障的研发原因进行分析,分析的规则会有周期性变动的,但不要太频繁,而且规则会随着组织的成熟度而改变。
  • 可操作性:要对度量维度做进一步分解,比如测试要有明确的检查点,覆盖要完整,可重复运行。支付宝就制定了具体的度量维度,从多个维度对系统加以度量。
  • 有工具支持:这不是必要条件,工具不能解决所有问题!能用工具最好,不行的话就人工检查。工具检测维度要按照优先级和操作性,逐步增加精细化维度。这一点上,支付宝将一些编码规则的检查放入了持续集成工具之中,以求尽早检查、频繁检查。

设计/开发约束

在软件开发过程中,存在许多设计约束和准则,其中包括:

  • 类和方法的长度
  • 单个类里方法和属性的个数
  • 方法或者构造函数的参数个数
  • 代码中的魔数、字符串用法等等
  • 注释行比例等

 

使用正确的工具完成工作

例如,电信公司可能会在客户服务对话快要结束时进行调查,调查方式可以直接通过电话,也可以通过人工智能对话,以获得关于客户体验的反馈。在这些反馈中,公司可能会听到这样的评论:“客户服务部分令人沮丧,我找不到我要找的答案,所以只好打电话来。”

简单的总结可以这样说: 在企业的数字化中“信息的度量是先驱,传递是根本”,而且数据的传递需要按需传递。

互联网产品下质量保障

质量保障的核心目标是质量 & 效率并重,对于互联网产品来说诠释如下:

六、如何创建北极星指标

授权意味着给员工去试验自己的新想法,并不断失败的自由,当然,大前提是他们能通过数据从错误中吸取教训,并最终在这个迭代的过程后创造出令人惊叹的产品和体验。想想Chase通过像Finn这样的全移动新产品来征服千禧一代市场的努力吧。尽管Chase是金融领域的一个老牌品牌,但该公司正在重塑客户与其服务人员的互动方式。这样的转变需要实验、测试、评估和迭代更新,这意味着在最终获得成功之前,要接受失败并从中学习。

二. 员工和客户是构建数字化企业的主体

企业必须专注于如何帮助消费者、员工、合作者等利益相关人员更多地利用技术获得成功。企业还必须培育新的公司文化,以技术为手段,帮助员工不断调整和学习、持续创造新型解决方案、推动变革、挑战现状。在以技术为上的时代,真正的领军企业必将以人为本。----埃森哲

“数字时代,以人为本”,数字时代的竞争中,技术能力固然重要,人则是制胜之本。虽然了解客户不断变化的需求和行为仍然重要,但真正的决定性因素是公司与时俱进改进企业文化的能力,即:员工能否在积极利用新兴技术的同时,拥抱技术所驱动的全新商业战略。

构成数字化企业的主体是员工和客户,而非老板或投资人,也非管理制度和流程,我们要以员工为本,以客户为中心。我们发现一直都有很多企业不断重复建设IT化,但很少真正把员工当成客户去服务和运营他们。就像很多城市不断的修新公路但公路的利用效率确很低,也缺少人性化设计,最终结果道路还是十分拥堵。最终很难真正实现企业的数字化。

依据德鲁克的概念,企业的目的是创造客户,而不是挣钱的机器。而实现创造客户的主体是员工,因为只有一线员工最熟悉客户。

我们先来看看GE完成的历史上最伟大的组织变革依靠的是什么?“群策群力”赋予了那些最熟悉客户的人足够的决定权,而摒弃掉层层上报的官僚体系。“FastWork”(快速决策)尊重每个员工的创意,并且用最短的时间回复这些创意。

一线人员有想法但没有权利去做,经理们有权力确没有时间去评价和批准,这是传统组织模式的瓶颈,是官僚主义造成的。

而员工的想法能在企业中流动是GE成功的秘诀,只是在那个阶段,要采集员工想法并在企业中形成流动是需要大量的管理成本和意志力的。而随着现在智能终端的普及和企业IT化,信息化建设的程度越来越高,我们需要的时间大大缩短。

质量

i.不仅仅是功能可用性层面,需要关注用户体验。

ii.不仅仅是上线前的质量保证,需要延伸至把关上线中、线上的质量。

iii.不仅仅只停留在好坏的感性模糊认识,需要将质量概念量化、可视化。

iv.不仅仅光靠抽样个例,需要大数据统计做强有力的支撑。

v.不仅仅只局限自身产品的质量,也需要关心竞品。

我们有自建后台不同数据字段含义的文档吗?如果没有,创建和维护文档需要什么?数据可能很复杂; 也许你的数据库管理员没有提出直观的字段名称,运营,一线市场同事对你如何获得这个数字有疑问。所以第三方通用的数据维度文档有助于建立对指标含义的共同理解,确保不仅一个人可以解释它们,并增加您使用的数据的可信度。(产品生命周期成熟期自建数据后台)。

当然,如果没有强大的流程将正确的部分组合在一起,那么即使是正确的数字工具也不会让您走得太远。当涉及到建立一个数据驱动的文化来推动持续的产品和用户体验改进时,创建一个流程让团队人员看到产品使用和行为数据如何与用户研究相关联是非常重要的。换句话说,当一个团队在他们的分析中发现了一些新观点时,他们应该能够通过用户研究来扩充这些观点,从而对所识别模式产生更为定性的理解。同样,来自用户研究或客户反馈的定性见解也可以通过定量行为分析得到验证和更好的理解。

十二. 我们需要构建更为灵活的柔性团队

企业为了跟上数字时代的变革步伐,升级了工具和技术等硬实力,但却忽略了锻造自身员工团队的软实力。企业需要的不只是合适的技术,更需要的是凝聚并发挥这些技术力量的人才。未来企业要组建一支能不断适应变革环境,具有较强应变能力的柔性团队。----埃森哲2016技术展望

走进大部分的传统企业我们看到的是严格按照职能划分的部门协作,例如:工程,研发,销售,市场,财务,HR等。部门协作采用预定义流程,文档,接口人,会议等。彼此相对孤立,每人都按照自己的本位职责开展工作,缺乏交叉和混合技术能力,例如:再这样的组织里一个研发人员只关心自己按照需求文档开发相应功能,但并不关心需求的来源背景,客户的愿望和需求分析人员的意见,只关心按照功能点一字不漏的完成任务。这样的协作是缺乏灵活性和创新性的,看似各司其职,其实他们合作水平低,缺乏信任,最终研发的产品缺乏客户认可和市场价值。目前的劳动力市场核心也正在发生悄然变化,员工需要混合技能才能满足当下不断变化的业务需求。一个好的UI设计师必须了解HTML5等代码语言,一个优秀的销售人员需要掌握各类数据分析工具,企业前所未有的需要大量复合型人才,这些复合型人才是组成柔性团队的关键。

这些年有些企业正在在寻求管理制度的变化以适应市场需求,有很多改良组织结构产生,有:按照临时任务的虚拟团队,有职能和区域划分组合的交叉管理组织,有基于产品研发的IPD流程等。这些组织管理变革都在强调每个角色都有承担更为复杂责任和需要掌握更加多的技能,每一个个体都有多条需要汇报和被管理等流程,虚拟团队有临时任务流程和职能任务流程,矩阵式管理有区域销售流程和职能研发流程,IPD有产品流程和职能流程。这样的模式在一定程度上缓解了传统树形组织结构的弊端,打通跨部门协作的瓶颈(一个团队可能由多个不同职能的成员组合而成),但也有一定的局限性,首先这样管理还是流程驱动而非数据驱动,信息传递方向是有限的和被预定义的。其次从根本上并不能促使员工发自内心,自愿的参与协作和达成企业目标,员工是被动的接受流程任务,同样缺乏创新性和灵活性。

对于大型传统企业非常羡慕当下的创业公司,公司人员从20到200人之间没有严格意义的职能划分,大家有多少能力就付出多少能力,没有管理流程,没有KPI.

“逻辑思维”的罗振宇说过:在逻辑思维公司200人的规模,目前没有KPI,没有树形组织体系,大家各司其职,自管理。“海底捞火锅”餐饮拥有1万多员工,而从不使用KPI,创新也没有流程,在海底捞火锅用餐都会有个给手机用的包丹袋,就是由一位叫包丹的员工发明的,并得到推广,在这里创新是没有时限没有流程的。这样的公司拥有更大创新性和灵活性。在这样的公司员工不只向自己的领导负责,而是向公司和客户负责,实际操作就会发现这是一个网状结构的管理体系,每个员工有自己的职能向自己的主管负责,但同时又有不限定的能力反馈或价值传递路径。

                                                              传统树形组织结构

                                                                 交叉组织结构

                                                                 网状组织结构

在这样一个没有预定义的信息反馈路径的环境里,就没有了对员工才能的限制,任何创新想法,协作请求,客户需求响应都是按需传递的,每一个员工就是一个企业分布式节点,他们扁平化,网络化存在,任何一个节点离职或者挂起都不会影响企业运转,而每个节点又都承担着企业,创新,研发,客户服务这样的混合业务,这样的团队就是柔性团队。

柔性团队将是企业组织方式的新常态,在数字时代,传统的组织结构已经无法跟上变革的步伐,具有前瞻性的企业已经意识到数字化员工有望成为一项重要的竞争资源。

在敏捷开发过程下质量保证

图片 5

对于目前的开发架构来说,一个用户故事,涉及这四个点,可以从这四个点入手来进行质量保证。如何做呢?单元测试就开发人员处理了;代码审查,测试人员可以参与和监督,其实就是要保证:将开发任务与提交到Git的代码进行关联。这样一来,当测试人员检查开发任务的时候,就可以找到改变过的代码。我曾经试过从这些代码里面查看逻辑,找到分支场景,补充到测试用例里面。

图片 6

Scrum中测试人员价值应当体现在:

  1. 预防缺陷的手段,提高洞察力,增强业务知识。
    缺陷在需求、开发前期就已经存在了,关键是用什么手段去挖掘出来预防。在sprint前获取到的需求,测试人员可以站在客户角度上来阐述自己的观点,与开发人员进行充分交流和讨论,使自己在用户体验、业务逻辑等等方面的经验充分体现出来。

  2. 在开发过程中,测试人员除了站在客户的角度进行测试,还应当提供更全面的质量反馈,包括代码质量的检查,这个可以通过redmine与git双向关联来做检查依据。目前整个过程测试人员尚未参与代码编写,应当参与并推进代码评审,将代码问题及时反馈出来;并且参与或者推进单元测试,检查单元测试状态(确保单元测试达到80%以上覆盖率,帮助开发人员开发出具有良好可测试性的代码),自始至终将质量问题及时反馈出来,保证在sprint的整个过程中质量受到足够的关注,提高质量改进的持续性和可视性。

  3. 随着版本任务的增加,每个版本回归测试的成本增加,可以适当考虑部分稳定功能进行自动化测试。当然,这是远景。

  4. 持续改进、反馈,充分发挥每个版本统计报告的作用,对缺陷进行分析,总结出一些规律,帮助开发人员建立良好的习惯,改进代码的质量。

North Star指标是衡量产品成功与否的关键指标集。它们提供了一种机制:使整个公司与定义产品成功的措施保持一致,以及传达公司实现该目标的进展。

紧跟着授权的必须是环境。您可以授权您的团队使用数据进行创新,但是如果您不创建一个透明的工作环境,使人们能够在组织中反复讨论和共享度量标准,那么您孤立的工作将很快陷入死胡同。

企业的数字化:是把企业生产运营过程中员工,产品,客户及协作者的行为实时记录下来;

敏捷软件测试的七个关键成功要素

包括​使用团队整体参与的方法、采用敏捷测试思维、​自动化回归测试、提供并获取反馈、构建核心实践的基础、与客户合作、保持大局观等。

1. 使用团队整体参与的方法

当整个开发团队负责测试和质量问题,你会拥有很多不同的技能集合和经验等级来处理测试可能发生的问题。测试自动化对于技能高超的开发人员来说不是大问题。当测试置于团队的优先权,任何人都参与测试任务,团队才会设计可测试的代码。使测试人员真正成为开发团队的一部分意味着向他们提供支持和训练他们适应敏捷开发的快节奏。他们需要时间掌握新技能以便与开发和客户团队紧密协作。

如果你管理一个敏捷团队,帮助团队使用团队整体参与的方法。记住质量,而不是速度,才是敏捷开发的目的。团队需要测试人员帮助客户理清需求,转化为指导开发的测试,提供发布优秀产品的唯一观点。确保测试人员能够把技能和长处转移到团队其他成员身上。确保他们不是局限于一种角色,如只做手动测试。确保当他们需要帮助时(可能需要极大的勇气),团队成员能够提供。反过来也是如此。测试人员应该随时准备帮助那些需要他们帮助的队友。

如果你是敏捷团队中的测试人员,并且计划会议和设计讨论没有邀请你,或者业务用户正在独自定义故事和需求,那你应该站出来和团队的其他成员交流。和开发人员一起参与会议,并提议尝试“三方协作”,即测试人员、开发人员和业务专家。谨慎地提供反馈并帮助客户提供例子。让你的问题成为团队的问题,让他们的问题成为你的问题。请你的同事采用团队整体参与的方法。

2. 采用敏捷测试思维

我们提醒敏捷测试人员丢掉一直以来的“质量警察”思维。现在你在敏捷团队中,开发人员参与测试,测试人员可以做任何事情以帮助团队生产最优秀的产品。敏捷测试态度是前瞻性的、创造性的、欢迎新思想、乐于承担任何任务。敏捷测试人员不断磨练自己的技能,随时准备协作,相信直觉,希望帮助团队和业务成功。我们并不是说你应该披上超级测试王的斗篷,去保护世界免受缺陷的危害。在敏捷团队中不存在狂妄自大。团队成员分享你对质量的追求。关注团队目标,帮助每一个更好地工作。使用敏捷准则和价值观指导你。不断尝试最简单的方法来满足测试需要。勇敢地寻求帮助和实验新想法。关注于产生价值。尽可能多的直接交流。灵活地应对变化。记住敏捷开发以人为中心,我们应该享受工作。当对此怀疑时,回顾敏捷价值和准则来决定该怎么做。

敏捷测试思维的一个重要部分是不断想办法改进工作。成功的敏捷测试人员持续地磨练技能。读好书、博客和文章以获得新想法和技能。参加本地的用户组会议。加入邮件列表讨论以获得问题或者新想法的反馈。如果你的公司没有付钱让你参加一个很好的会议,那么把你的经验写成报告在免费的会上作交换。对测试和敏捷开发社区进行反馈也会对你有益。实验新的实践、工具和技术。鼓励团队尝试新方法。短期迭代非常适合这种实验。你可能会失败,但是很快你可以尝试其他的。如果你管理敏捷测试人员或者敏捷团队,给他们时间去学习并提供所需的培训支持。移除障碍使他们更好地工作。当你面对影响测试的问题时,让团队都知道这些问题。通过头脑风暴的方式克服这些障碍。回顾会议可以讨论这些问题并想办法解决。维护一个阻碍事项列表,并在每个迭代中解决一到两个。使用可视化的大图片或者虚拟方式,确保所有人都知道发生的问题并可以跟踪编码和测试的进度。

3.自动化回归测试

敏捷团队没有测试自动化会成功吗?可能吧,但是我们所知道的成功团队都依赖自动化回归测试。如果你花费全部时间用在手动回归测试上,绝没有时间用于重要的探索性测试(会发现隐藏在代码中的危险行为)。敏捷开发利用测试来指导开发。为了编写代码使测试通过,你需要快速、简单地运行测试。没有短期反馈周期和安全的回归测试,团队将很快陷入技术债务,缺陷不断增加,速度越来越慢。

自动化回归测试是团队的工作。整个团队应该选择每种测试适合的工具。提前考虑测试将帮助开发人员为了便于测试自动化来设计代码。使用敏捷测试象限和测试自动化金字塔来帮助你自动化各种类型的测试。记住从简单入手。你会惊讶地发现一些基本的自动化冒烟测试或者自动化单元测试会发生很大作用。测试自动化是团队的工作。开始时很艰苦,需要克服很大的痛苦。如果你管理开发或者测试团队,确保在时间、培训和激励上提供了足够的支持。如果你是没有自动化测试的团队的测试人员,开发人员疯狂地编写代码以至于不会停下来考虑测试,那么你会面临很大的挑战。尝试从管理层和团队成员中获取支持以开始小规模的自动化工作。

4.提供并获取反馈

反馈是敏捷的核心价值。敏捷的短期迭代可以提供持续的反馈以帮助团队运转正常。测试人员通过自动化测试结果、探索性测试的发现和系统实际用户的观察结果的形式帮助提供反馈。敏捷方法允许团队获取有关构建中软件的反馈。这是关键。故事代表了测试人员和分析人员向开发人员提供反馈的工作单元。迭代发布有助于团队外部的反馈。大多数敏捷实践都创建了反馈循环使团队应用。测试人员也需要反馈。你怎么知道从客户手里拿到了预期行为的正确例子?你怎么知道编写的测试用例正确地反映了这些例子?开发人员通过查看你收集的例子和你创建的测试能够理解应该编写什么代码吗?一个最有价值的技能是学习如何寻求自己工作的反馈。询问开发人员是否得到了足够的信息以理解需求并且是否能够指导编码。询问客户是否理解质量标准。花时间参与迭代计划会议和回顾会议以讨论这些问题并提出改进方案。

5.构建核心实践的基础

  • 持续集成

每一个开发团队都需要代码管理和持续集成。如果不知道自己在测什么,就无法有效地测试,如果无法配置代码你根本无法测试。所有团队成员需要至少每天一次导入自己的工作。每一次集成必须通过自动化构建验证,其中包括提供软件状态快速反馈的测试。实现持续集成过程应该是软件开发团队中优先级最高的事情。如果团队没有每日构建验证的版本,停止手里的工作,开始构建。就是这么重要。一开始并不要求太高。如果你有很大的系统需要集成,肯定会更具挑战性。通常来说没有那么困难,市面上存在很多优秀的工具,开源的、商业的。

  • 测试环境

没有可控的测试环境就无法有效地测试。你需要知道部署了什么版本,使用的数据库模式是什么,其他人是不是正在更新,其他进程是否运行在那台机器上。硬件总是越来越便宜,开源软件越来越多。团队必须投资以有效地执行自动化和手动探索性测试。如果测试环境出现问题,赶紧说出来,让全队一起解决。

  • 管理技术债务

即使优秀的软件开发团队在感觉到时间压力之后,也会忽视重构或者快速解决问题修补缺陷。随着代码越来越混乱和难以维护,更多的缺陷出现,很快团队的速度就慢了下来,因为要解决缺陷才能添加新的功能。团队必须不断地评估技术债务的数量,并努力减少和避免。大家经常说:“我们的管理层不会给我们时间做这些,没有时间重构,日程很紧”。但是,我们可以很容易举一个业务用例来显示增长的技术债务如何耗费公司的成本。衡量代码和缺陷率哪些会导致技术负债变为对底线的影响存在很多办法。仅仅指出不断下降的速度就足够了。业务需要软件开发团队保持持续的生产力。他们不得不减少期望功能的范围以保证足够的时间来进行良好的、测试规范的代码设计和优秀实践,如持续小规模重构。自动化回归测试的良好覆盖率是最小化技术债务的关键。如果缺少,那就在每个迭代中拿出时间来构建自动化测试,规划一个“重构迭代”以升级或添加必要的工具,编写测试并进行重构。在每个迭代中花时间通过测试指导代码,重构必要的代码,添加丢失的自动化测试。对这件工作要重视。长期来看,团队能够变得更快。

  • 增量工作

敏捷团队能够生产高质量代码的一个原因是他们小规模地工作。故事代表了几天的工作量,每个故事被分解成小增量,按步构建。测试可以针对一小块,并且随着功能聚集再增量测试。如果团队成员喜欢一次开发一大块功能,鼓励他们采用步骤式的方法。提出问题:“这个故事的核心业务价值是什么?这块代码的最基本路径是什么?下一步干什么?”建议大家编写任务卡片以编码和测试小增量,记录设计概念和确认测试和测试自动化策略。

  • 编码和测试是同一个过程的组成部分

对敏捷思想不熟悉的人经常会问敏捷测试人员:“在所有故事完成并且可以测试的时候你会怎么做?”经验丰富的敏捷实践者会说:“测试人员必须贯穿整个迭代,整个开发过策划那个。否则就会失败”。测试人员基于客户提供的例子编写测试,以帮助开发人员理解故事并开始编程。测试和例子提供了一种通用语言使所有人都参与到软件理解中。测试人员和开发人员在编码时紧密合作,他们也会与客户紧密合作。开发人员向测试人员展示他们编写的功能,测试人员向开发人员展示他们发现的异常行为。测试人员随着编码进展编写更多测试,开发人员是其通过测试,测试人员进行更多探索性测试以了解是否生产了正确的价值。每一个敏捷迭代包含了若干持续、快速、增量的测试——代码—— 测试——代码——测试迭代。当这种合作和反馈周期被打断,并且测试与开发分离时,糟糕的事情会发生。如果故事是在编码之后的迭代中被发现的,开发人员不得不停止新的故事,回忆代码是如何实现上个迭代的故事的,修补它,并且等待其他人测试。在软件开发中没有什么几个事实,但是我们确定缺陷发现的越早,修补的成本越低。当编码一直由测试指导,编码的同时进行测试,我们更有可能达到客户预期的行为,提供客户所需的价值。测试是团队的职责。如果团队没有这种观念,让所有人想一想对质量的关注、对发布优秀产品的期待和采取哪些措施来确保团队实现目标。

  • 实践之间的协作

单个敏捷开发实践如持续集成能够发挥作用,但是多个敏捷实践的组合比各个部分相加要大。测试驱动设计、共有代码所有权和持续集成一起促进快速反馈、持续改进代码设计和快速产生业务价值。自动化测试很好,但是使用自动化测试驱动开发,随后是探索性测试以发现缺陷或者弱点,分多层次更好。某些实践单独操作并不好。没有自动化测试,重构是不可能的。通过迷你瀑布型的方式发布小版本会丢失敏捷开发的所有优势。如果你的现场客户没有做决定的授权,那么他对团队的价值有限。敏捷实践是互补的。花时间理解各个实践的目的,想想如何利用全部优势,针对什么对团队有用做出深思熟虑的决定。

6.与客户合作

测试人员对敏捷团队的最大贡献之一是帮助客户理清需求并设定优先级,通过预期行为和用户场景的具体例子描绘需求,并把这些例子转换为可执行的测试。测试人员使用业务的领域语言和开发团队的技术语言。我们担任优秀的辅助者和翻译。千万不要阻碍开发人员和客户之间的直接沟通。鼓励尽可能多地直接交流。使用“三方协作”方法。当需求丢失或者被误解,客户、开发人员和测试人员需要一起解决问题。请客户经常在白板或者其他虚拟工具前讨论问题。如果客户发布于不用的地区、国家,那就使用任何能找到的工具来加强沟通和协作。电视会议、即时消息和 wiki不能完美的替代面对面的交流,但是也比发邮件或者什么都不做要好。

7.保持大局观

我们发现测试人员有大局观,通常从客户的角度看问题。开发人员通常关注于实现当前的故事,虽然他们使用测试来指导,但是不得不关注于需求的技术实现。大局观对团队贡献巨大。测试驱动开发,如果完成得很好,单独的代码没有缺陷。如果新的功能导致一些应用明显不相关的部分崩溃怎么办?一些人不得不考虑这种对较大系统的影响并引起团队注意。如果我们忽略了一些可能惹恼客户的细节怎么办?新的UI可能没什么缺陷,但是如果背景颜色使文本难以阅读怎么办?这都是最终用户会注意到的问题。使用敏捷测试象限作为纲领来帮助规划测试覆盖所有范围。使用测试金字塔思想确保测试自动化的良好投资回报率。通过测试指导开发有助于确保你没有丢失重要的事情,但并不完美。使用探索性测试了解系统应该如何工作,测试应该指向哪个方向。让你的测试环境尽可能与生产环境类似,使用反映现实世界的数据。勤于重新构建一个生产环境类似的场景,如负载测试所需。团队的每一个人都很容易只关注手边的一个任务或者故事。这是一次只做一块功能的缺点。帮助你的团队后退一步,评估当前的故事如何负责业务的大局。不断问自己如何才能更好的产生真正的价值。

指标策略是让您的团队和产品与对业务至关重要的目标保持一致的最佳实践。如从北极星调整开始,每个人都在努力使用能够全面了解产品用户群的指标。指标也是一个迭代过程,指标度量策略随着产品生命周期一样发展。

有了客户的反馈意见,电信公司就可以使用行为分析技术进行更深入的挖掘,从而识别出使用户产生沮丧情绪的客户服务模式,并建立相对应的分析团队。通过识别与这类用户可能的摩擦点,产品和营销团队可以努力使客户服务部分更直观,并试验不同的副本,甚至考虑新的信息呈现方式。产品团队还应该跟踪他们的改进过程。

像现在一些大型企业随随便便就拥有几十套IT系统,覆盖了资源采购,销售管理,合同管理,招聘管理,员工,财务管理等关系企业运营方方面面;电信运营商在10年前就开始构建面向资源的OSS系统,面向客户的BSS系统和面向内部管理的MSS系统。但有这样系统的企业算是真正的数字化企业吗?

二、测试技术

线下集成持续化、测试服务化,以应用质量(QPS、SLA、性能)、业务指标、过程质量(代码覆盖率,千行 bug 率)一系列发版标准为目标,将自动化测试、性能、单测、异常等工具集成入构建—部署—quickcheck—slowcheck—release 的流程中,快速发现问题并解决,迭代质量。线下需要更多精力关注在异常和性能测试中,这些往往是线上问题多发区。

上线过程中灰度控制,把产品发布过程划分为多个级别,每个级别限制一定的流量和用户范围,并在每个级别对产品进行部署和验证的迭代过程。一方面逐步放量,小心验证,降低上线带来的风险;另一方面开展用户测试,让用户参与产品测试,加强与用户互动。让用户参与 beta 环境分为两种情形:被动命中(将同一特征的用户强制划分至小流量环境中)和主动邀请(邀请粉丝或有偿用户)。对服务器来说架构能够支持逐步放开流量,对客户端发版来说有一个平台支持哪些版本哪些用户能升级到beta版本,并且在小流量阶段要密切关注监控和用户反馈,将问题及时扼杀在萌牙阶段,不带到全量阶段。

线上监控 & 定位,从基础拓扑(网络、单机、数据库等底层服务)、服务稳定性(接口成功率、5XX、4XX非预期返回码的占比等服务器可用性层面)和业务质量(上传、下载的成功率等用户功能层面的易用性)三个核心要素延展开全方位细粒度的监控覆盖,并从质量标准、质量防线和质量闭环三个维度进行质量建设:首先对产品建立一套完善的产品质量标准体系,并将其度量化,固定成 benchmark。紧紧围绕质量数据,组建从用户(舆情热点)、端(产品体验)、服务器(稳定性)到基础网络(SLA)的层层实时防护网,最后通过上线管理—报警中心—智能定位—故障通报的质量闭环环节落地,不断迭代优化,能够快到线上问题快速预警、定位及解决。

产品经理通过“任务完成率指标“优先级创建策略模型。

流程

其实在以上企业的运营生产过程中我们也能感觉到一些数字化的影子,例如:可以通过电子差旅记录分析公司成本结构,帮助优化公司财务结构;可以通过软件的bug系统分析,协助优化研发过程;可以通过客服系统分析,提升客户反馈效率;可以通过销售数据分析,帮助制定销售目标和计划等。

效率

i.加快产品迭代,唯快不破。

ii.提高问题暴露,定位以及解决速度,快中求稳。

对产品建立质量标准,将其度量化并形成稳定的、可衡量的产品质量benchmark,对于产品可以列出数据完整性、安全性、传输速度、在线消费体验等最核心的质量维度。线下以此作为发版标准,驱动产品质量迭代越来越接近目标;线上以此作为监控范围,对线上质量问题主动防御,加快应对。

“以质量为中心,以数据为驱动”为宗旨贯穿整个流程,将各种测试工具和方法融入进来,构筑一套全流程质量保障体系,如下图所示:

图片 7

 

对齐重要的测量类别

环境

十三. 塑造数字化高效组织

前面讲到通过构建柔性团队提高组织的灵活性和创新性,但如何提高团队的效率呢?这就要借助数字化手段实现高效的组织。

在《智慧社会》一书中讲到塑造高效组织的途径是:参与,探索,多样性和发现魅力型连接者。

协作参与,要塑造数字化高效组织首先需要促使组织成员全面参与团队协作过程中,这样的参与可以通过线上远程协作(包括:视频交流,电话交流,邮件沟通,IM沟通,文档和代码协作)和线下面对面协作,当然面对面协作的效率尤其高效,如果我们能度量这些面对面的协作程度,并给出优化建议,促使组织全面参与协作和信息的传递。在文章的开头部分讲到的会议效率的场景,在这样的面对面的协作过程中如何度量呢?在我们的实验过程中我们开发了一个基于Android手机APP(cafe),采用声音,蓝牙,运动传感器,GPS,高度传感器等数字化手段识别参与者,交谈对象,音量,位置,姿势,频率,时长等信息,用于感知会议参与状况,并帮助我们改进协作效率,该APP的会议健康度量仪可以实时显示讨论的健康度。

图为:café的数据评估

理想高效的协作一定是网状信息传递,要求参与协作的人员全部参与讨论,发表意见,主动协作,会议的成果也一定是群策群力的结果,而不是某一两个人的个人智慧,这样的协作才是有效的。

协作探索,现在只有组织参与还不能完全达到高效,因为当一个组织完全参与协作,并促进信息在小范围充分传递后容易产生回音室效应(指:信息和想法在一个封闭的小圈子里得到加强),回音室效应是一种欺骗效应,当组织内部从出现不同种声音到通过逐渐相互理解,相互包容,统一思想和结论后,该结论就成为了以这个团队为代表的个人智慧,我们需要将该智慧同其他团体智慧进行碰撞,这就是探索。作为人类天生具备享受安逸区和好奇心的双重性格,安逸区是动物本能,好奇心是人本能,安逸区使人可以繁衍后代,好奇心使人完成进化(从进化的某种角度来说基因变异就是一种基因的好奇心)。好奇心促使人们探索,团队探索主要体现在主动和被动两种形式,主动探索往往是由前面讲到的流程驱动的,例如:方案评审。一个团队通过集体智慧产生一份技术方案或市场方案,依据公司流程驱动,需要跨部门相关人员进行综合评审。而数字化这样的探索过程可以告诉管理者,这样的方案靠不靠谱。对于这样数字化过程可以通过工作流审批等无互动方式数字化(只记录审批过程数据),当然没有互动探索是无意义的。我们推荐采用面对面,视频,语音等有互动能力数字化开展数字化探索,采用移动终端记录整个探索互动过程的对象,频率和方式。从而掌握探索的效果。而被动探索是我们经常忽略的更为重要一种方式,被动探索其实可以理解为一种随机探索,既:一种不提前知道探索目标和对象的探索。随机探索是需要数字化环境提供支持,我们说主动探索可以通过工作流和任务机制推进,而随机探索就要构建请求和响应模型了,具体如下:

发布探索请求---计算影响趋势---影响传递提醒---请求响应---产生协作---计算影响度---影响广播。

例如:当我需要评审一份技术方案或销售方案的时候,采用随机探索方式可以在一定范围的人群中发布审批请求,而企业数字化环境可以根据影响度随机分配评审人员,评审人员通过社会压力模型自己评估是否响应,整个响应过程是自愿和有环境压力考量的,评审人身边的朋友,同事都曾经做过的类似事情,都可以成为他响应该请求的因素,他接受了该评审并完成评审后,企业数字化环境会广播他的协作事迹,促使其他人共同参与。

一个有意思的游戏:在一个2000平米一层,拥有6层的大型开放式办公区域中,部门与部门之间,团队与团队之间还是缺乏了解,研发部门不理解财务部门为什么报销流程这么慢,财务部门不理解研发部门出差为什么不提前申请,CRM产品部不理解计费产品部为什么这么守旧,计费产品部不理解CRM产品部为什么这么多变,需求不理解研发,研发不理解客户,在这些互不理解的部门中如果单靠流程驱动完成任务,效果可想而知。我们在企业数字化环境中随机抽取最互不理解的人员,在某一时间到办公区某个位置协作寻宝,给他们20分钟协作和交流的时间,剩下的让他们自己去解决吧,你会发现一段时间后部门之间的隔阂在逐渐消除,这样的成本比换岗的代价要小很多。

协作探索能使团队消除回音室效应,能加入更多的声音和不同的见解,可以使团队协作变得更为高效,也就是说团队外面对面的探索 团队内部的参与=高创意团队。

组织的想法多样性,在一个组织内部我们可以通过探索方式和其他团队交换想法从而形成组织想法的多样性,保障想法的多样性对于一个高效创新团队尤其重要,而在我们的企业数字化环境中我们可以获取团队内部的参与程度和外部探索程度来度量这样的想法多样性,正如前面章节所言:我们的数字化互动无需知道想法的内容,而是观察想法交互的对象,频率和方式,企业数字化环境除了分析团队内部的数字化交互情况,还需分析跨团队之间的数字化交互。

发现魅力型连接者,《智慧社会》一书中这样描述魅力型连接者:精力充沛并有条不紊地与他人互动;能够引导组织内的互动模式朝正确方向发展;并不主宰团队内的讨论,而是鼓励好的想法流模式。其实在我们企业工作环境中一直存在这样的魅力型连接者,他们不仅是性格外向,最重要的是他们会换位思考,善于倾听,总会去理解对方的处境和意愿,哪怕对方只是一名保安或者保洁人员。这样的人也许正在担当跨团队的衔接和任务推进职责,也许还没有,我们通过企业数字化环境发现这样的人,把他们放到连接者的职位中,发挥他们的特长。或者鼓励更多人发展成为魅力型连接者,也许魅力型连接者在企业互联的环境中是一个值得大家尊重职位。

在我身边曾经有这样一个真实的人物,还在我供职于CRM系统架构师的职位时,最头疼的就是和计费系统的设计师们共同讨论产品接口模型,因为从CRM的角度来说,产品是基于商品来建模的,关注于怎么销售;从计费系统的角度来说,产品是基于服务来建模的,关注于如何计价。这是天生的矛盾,该问题必须要求双方团队都要一个整体判断和站在对方的角度上,双方团队平时缺乏协作参与和探索,这时简单问题也会变得复杂,谁都不愿意认输,谁都不愿意放弃自己的想法。这时出现了一个魅力型连接者,他善于倾听双方的理由,擅于引导

善于转换让双方认可一个都可以都可以接受的方案,虽然不是从根本解决(解决双方系统认知问题并不是连接者的功能,连接者优先保证双方处于一个高频,互动的环境)双方系统认知差异的问题,但至少达成了项目目的,建立了良好的沟通模式,为将来进一步解决该问题提供了保障。

怎么驱动产生更多的魅力型连接者,已实现网络的全连接呢?我们知道激发人协作的动力不是财富声望,而是同伴的帮助和协作。首先我们要识别出一个企业、一个团队中那些人是魅力型连接者,通过协作网络图(见下图),直接实时标出他所在的协作网络的关键位置;其次鼓励通过多维协作事件开展彼此互助协作(例如:A协助B bug调试,B协助A代码开发),从而激励更多人参与协作,魅力型连接者不是一个固定状态,他只是一个网络探索过程中的一个实时过程。最后建立影响力评估模型,通过社会压力来鼓励更多人,成为勇敢担当新网络的探索者。

魅力型连接者是保障高效组织的关键人物,他可以推进高效组织的建立,推进想法在跨组织之间流动,保障想法的多样性,也许在将来他会是一个全新的职位。

如图所见,节点F和E就是魅力型连接者。

软件质量保证的实践

常见的SQA的架构

图片 8

我们持续演化,对于将软件 QA 浓缩到所有开发任务完成后的测试阶段的方法,它们的问题在于:会给团队带来巨大成本并将整个项目置于高风险之中。在测试阶段,开发人员竭尽全力确保他们的代码具有极少的缺陷。然后测试人员努力揭示软件中每个可能的缺陷,而经理和客户希望他们拥有适合向市场发布的软件。

仓促的开发可能会为团队节省片刻的时间,但是,如果有一些重大开发问题没有从一开始就考虑到,最终可能导致需要投入更多的时间。结果是浪费了大量团队资源来修复和重新设计代码,而不是将这些资源投入到更有用的事情上。软件团队人员内心里对整个始末一目了然,但面对着唠叨的客户、严格的销售团队,以及一些自我感觉编写了无缺陷的软件的开发人员,软件团队确实很难将 QA 撇在一边而只顾着完成代码。

有几种实践方法,包括需求审核、代码审核和演练、基于会议的测试、基于风险的测试等.

在开始每个新开发阶段之前审核软件需求,这样做能够最大限度地减少缺陷并满足客户的需求。在实现之前审核需求,这样做有助于考虑潜在的变化,克服在项目的整个寿命中可能发生的误解。团队必须与客户一起反复检查所有应实现的业务领域细节。需求审核也可以使用原型和领域模型来完成。当开发团队在开始实际实现之前完成这个小任务时,他们的项目或开发迭代会获得良好的开局。通过确保在实现之前所有利益相关者都达成共识,并且每位团队成员都意见一致,客户和管理人员可确信开发人员将在开发周期结束时交付正确的成果。

而“代码审核和演练”听起来像很简单,但代码审核是软件开发中最有效的实践之一。它对减少缺陷数量以及增强代码和软件设计的质量具有直接影响。这消除了在未来的版本中执行重大的代码重构和清理的需求。

依据项目需求和实现细节,团队可能认同简单的编码和设计原则。团队成员应共同遵守这些原则,而且只要开发一项新功能,一个或多个团队成员(除了作者)应审核新代码,并搜索所有编码或设计错误。

这种做法可在许多方面为团队带来帮助,包括提高代码质量和设计,最大限度地减少缺陷,并预防它们。另外,它还使得整个团队能够深入了解彼此的工作,轻松移交工作,并提高团队对不同软件组件和功能的认知。团队协作验证和证明代码的质量和设计的实现方法。它们从同事那里获得直接反馈。这么做可谓一举两得:代码质量增加了,团队的认知和项目责任也增加了。

第三个实践是“基于会议的测试”,表示将测试负载分解为会议,每个会议有一个任务(一种希望从测试会议获得的明确规定的结果)。每个会议有一个既定的时间范围(从 20 到 40 分钟),测试人员在执行测试会议期间不应中断。

这就像将测试人员放在一个测试房间一段时间,让测试人员专注于查找特定软件特性或功能的缺陷。在会议期间,测试由一组测试案例引导执行,测试人员也可以执行探索性测试。因此,基于会议的测试是正式测试方法与测试创新的一种组合,因为它提供了测试人员房间来进行探索和获得直觉思维,留出了时间和自由空间来发现不常见的缺陷,或者通过折腾软件来进一步了解它。

会议期间,测试人员应将软件的行为记录在案,获取快照,以及写下软件在特定输入和设置下的行为。会议结束时,将与团队领导或技术经理讨论会议脚本。从他们的讨论中,他们找出所认为的正常行为和不正常行为,然后基于讨论创建缺陷报告。

另一种则是“基于风险的测试”,因为在开发流程中进行了一些更改,开发团队通常拥有同一个软件的许多常用版本。一种重要的 QA 实践是在每个主要版本之后彻底测试软件。另一方面,在每个版本中都对整个软件运行全面的回归测试既耗时又很难实现。但是,仅测试更改的功能或笨拙地删减测试案例套件是不安全的。一段代码可能解决了一个缺陷,但也可能破坏了代码中的其他内容。

基于风险的测试方法采用了折中方式。它的基本理念是按降序对软件功能和失败模式排序,从最重要或风险最高到值得拥有的功能和简单的风险(一个类似工具是 FMEA:失败模式和影响分析)。如果测试人员在严格的时间限制下测试某个新版本时手头有这个列表,他就可以集中精力确保新引入的更改不会破坏其他任何内容。然后就可以轻松地确保更改不会破坏软件中的任何最重要的功能,因而不会发生任何最严重的风险。

我们期望是

测试和开发同时进行。编写一些代码,马上进行测试和构建。接着,编写更多的代码,继续测试。更好的是,在你编码的时候或者编码之前,就计划好你的测试。测试不是一个独立分开的过程,它是开发的一部分。质量不等同于测试;要想有高质量的产品,就要把开发和测试紧密捆绑在一起,直到不分彼此。

保证质量,预防胜于检查:

质量来自开发,而不是测试。为了拓宽开发环节,我们可以把测试融入到开发中去。我们已经建立了一个超高效的增量流程,只要有一个增量被证明缺陷太多,我们就可以回滚这些错误。我们不仅预防了很多产品级问题,还大大地减少了那些为确保消除“召回级别”缺陷而安排的测试人员的人数。

五、产品经理如何定义指标

授权

一. 数字化首先实现数据的广域覆盖

数字化的前提是信息能被度量,而信息度量是将事物的线下操作行为,状态或模拟信号等复杂多变的信息转变为可以度量的数字、数据,转变为一系列二进制代码,引入计算机内部,进行统一处理。而我们最为常见的度量主要集中在固定流程的度量,他们在数据的广度和深度上还达不到数字化企业的要求。

企业的ERP, CRM, Billing等系统都是常见的按照企业运营流程进行度量和传递的数字化方式,我们度量订单,客户,消费,资源调用等这些企业运营数据,传递客户,商品,消费,资源的状态。

我们以典型的电信企业EDM模型为例可以说明我们在构建基于流程的运营系统中状态数据化的数量。以TMF SID为基础的EDM模型大致有200-300个状态,而我们这些状态数据还远远不够我们构建一个数字化企业,我们需要的数据更为庞大更为贴近客户和员工,我们需要的是以数据驱动的企业运营。

流程驱动,我们早期构建IT系统是先有管理制度,运营策略,销售,服务流程再思考数据的度量,典型的就是类似:CRM,ERP等。在这个重要前提下数据是有主次之分的,比如:客户的订单数据就比客户的行为数据重要,客户的账单数据就比客户的情绪数据重要。而在当前的互联网经济大潮下,我们需要更加灵活的运营策略时,数据之间就没有了明显的重要程度的差异性,而是依据我们所掌握的数据广度,来构建全新高适应的企业运营策略。比如:如果我们有了从客户产生需要,需求到被满足和服务使用过程的全程数据,有了员工从找工作编写简历到工作后上下班的路程数据,谁能说这些数据哪个更重要呢?原有传统流程驱动的企业中客户买的商品越多越是VIP客户,员工加班越多越是敬业员工。而只要我们稍微思考一下就很容易明白这样的思维过于简单化和标签化了,买的越多不代表客户是满意的,加班越多不代表是高效的或者对企业最有益的。

数据驱动,我们当前能听到和看到很多相关的提高企业数据分析能力的主张,但真正的数据驱动型企业,不能只靠提升分析工具或者人员技能来达成,而是彻底改变企业各层级的决策方式。企业必须摒弃以直觉,经验,甚至资历的决策模式,实现数据的充分渗透。数据驱动必须要体现对于数据的订阅和推送能力,数据依照员工的日常工作,生活的事件产生,并进行脱敏和隐私安全处理后推送给数据订阅人。我们目前正投入在企业的流程驱动到数据驱动转变的产业互联大潮中,没有预定义的流程,没有明确的数据方向,数据的使用完全是订阅者通过透明的个人数据商店,按需供给。

团队

任何时候都需要团队,需要这样的团队成员:

1.具有创新精神的测试人员
这类测试人员往往会较快的接受新生事物,他们喜欢探求从未使用过新奇工具、技术等。这些新的测试工具或新技术的发现,会带动整个测试团队技术上的推陈出新,让本来墨守成规的测试工作充满了新鲜的体验。大家在交流新技能的同时也会带动起较高的学习热情。

2.有测试欲望并能够持之以恒的测试人员
充满测试热情、善于发现隐藏的软件缺陷、较真是这类软件测试人员的共性。
往往枯燥的工作会让人失去耐心,但这类测试人员会始终抱着最大的热情投入到测试工作中。对于这样的成员来说,发现软件缺陷是他们最大的乐趣,工作上的每一个发现都会带给他们源源不断的自信。团队中也正是有这样的成员存在,正是有他们在关键时刻发现软件产品的隐患才能避免事后补救的不必要的人力、物力资源的浪费。

3.富有经验的软件测试人员
不管情况如何,他们都可以找到正确的位置来运行程序以发现关键的缺陷。这正是富有经验的软件测试人员的宝贵之处。在很多情况下,根据对相似类型的项目的经验,一个软件测试工程师可能会准确知道在哪里找“致命缺陷”。

4.具有远见性的测试人员
与具有创新精神的测试人员不同的是,具有远见的软件测试工程师往往会发现更高级的,策略性问题的解决方案。团队需要一个能看清团队发展方向的人——对如何进行软件测试有广泛认识,而且对团队成员的具体程序有深入认识的人。这类测试人员会推动整个团动的不断进步。


希望对您公司IT软件研发与质量管理有帮助。 其它您可能感兴趣的文章:

构建高效的研发与自动化运维
IT运维监控解决方案介绍
IT持续集成之质量管理
人才公司环境与企业文化
企业绩效管理系统之平衡记分卡
企业文化、团队文化与知识共享
高效能的团队建设
组织目标与个人目标
餐饮连锁公司IT信息化解决方案一

如有想了解更多软件研发 , 系统 IT集成 , 企业信息化,项目管理,企业管理 等资讯,请关注我的微信订阅号:

图片 9

 

作者:Petter Liu
出处:
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。

度量策略应从以下流程开始:成功定义,产品检测方法以及评估产品性能。

当然,任何一种好的数据转换都需要仔细考虑和运用一些工具。利用工具构建更强大的数据文化的关键是寻找那些可以被整个组织的团队广泛利用的工具,以获得他们自己的见解,跟踪产品的表现,并在这两个领域进行更深入的挖掘。

我们仔细分析这些常见的数字化场景不难发现,这些都是基于预定义流程的数字化,很难实现按需传递的数字化。

文化价值驱动质量

产品也是创造它们的文化产物。麻省理工学院马丁信托创业中心的总经理Bill Aulet,同时也是麻省理工斯隆商学院的资深讲师,提醒我们:文化会吞噬策略,并且,我质疑流程也一样会被文化所吞噬。当组织文化与流程改变的精神相冲突时,例如当命令式与控制式的文化试图通过自管理,敏捷团队来达到生产率的目的,每一次冲突都会是文化获胜。文化通过组织的价值观、标准、信念和习惯表现出了自己,这些表现形式进而通过规范团队行动的方式产品质量产生影响。我的这一观点并非来自某个组织的报告说明,而是通过组织在每一个级别上的行为所得出的。首先,组织的价值观通常能够帮助团队排列出优先级最高的任务。

  1. 领导重视。关于质量,领导需要展示如何“付诸行动”。并且必须来自于上层的授意。你可以通过如下方式来达成这一点:

    • 跟踪质量度量。定义高层领导、产品经理、质量保证人员和工程师都认同的有意义的质量测量。
    • 让你的度量可见。经常把在会议中提到它们,并且和你的团队定期地回顾评审。
    • 用质量做取舍。对最小质量级别创建清晰的定义和规范,当邻近发布时需要做出取舍时,就可以在会议中使用它们。当团队看到质量度量用于决策的取舍时,他们就会了解为什么要重视质量了。

    特别要注意的一点是,当你要在组织中介绍或改变度量的时候。就像其他任何变化一样,至关重要的是在采取这个改变时要在大家的认同和强行执行之间权衡利弊。度量的风险在于,不同的团队可能已经在使用自己的度量方式了,他们会着重于强调他们所感兴趣的部分。因由于度量的目的是全面地测量和转变团队的行为,因此关键在于让所有的干系人(高层领导、产品经理、质量保证人员和工程师)认同并且坚持某些通用原则,你可以通过如下方式来达到:

    • 有目的地建立一个跨职能的工作组。清晰地说明出,如果没有度量的情况下,当前存在的痛点,为什么必需要采取行动,以及常见的度量是如何帮助我们的,通过这些来激发大家对度量的需求。邀请那些有影响力的干系人,让来自于不同部门的高层领导、产品经理、质量保证人员和工程师来设计度量。在讨论的过程中,每一个参与者都代表了他们团队感兴趣的部分,也帮助了我们把度量在内部推广给其他人。选择一个好的引导师,并且请确保在度量设计完成之后,明确地要求参与者把这个结果推销给他们的同事。
    • 对有价值的产出进行测量。让工作组首先识别出不同的干系人所关心的、他们理想中的定性的产品产出是什么。一旦这些识别出这些产出之后,然后再邀请小组人员返回度量设计,选择促进或偏离每一个产出需要的测量。比方说,假设你的产品是一个云应用,计算成本上升的速度比使用的增长速度还快,高层管理人员对此问题表示关注。工作组可能会识别出各种度量来测量有效性,例如各台服务器的CPU使用率,而这是可以在开发和测试阶段进行监控的。一旦这些度量最终被确定和使用,请展示给你的团队并告诉它带来的影响是什么。
    • 对跨团队的度量进行标准化。让工作组创建模板或者仪表盘,因此所有的团队可以以此进行度量的查看。邀请每一位参与者展示他们特定团队的结果,并且确保各个团队统一使用这些标准工具。因为每个职能部门都对该流程表达了自己的观点,并且清晰地设定了期望。因此这些度量就可以让每个人在以后工作中使用。
  2. 消息的可靠性。成功的经理人都会根据与团队的共鸣度谨慎地选择正确的方式去沟通有关质量方面的消息。做好这一点也许需要经过一些试验。从不同的内部或外部的干系人的视角来沟通产品质量,看看如何激发你的团队。例如以下几种方式:

    • 客户满意度。采访或调查客户对产品的整体满意度,在过程中注意以语言引导他们的情绪。
    • 演示中的销售体验。就像任何一个销售代表会告诉你的一样,在预期演示的时候出现产品崩溃会带来十分严重的伤害,并且会让销售代表很难堪。应该注意了解销售代表在演示产品中的表现,以及他们在演示中产品所表现出的可靠程度。
    • 高层领导的看法。在很多组织中,高层领导(尤其是创始人)喜欢动手尝试新的产品功能。在邻近发布时,邀请他们参与使用,并且询问他们的体验。
  3. 同事参与。一旦他们开始彼此参与度量时,你的团队可能会将质量深入内心,你可以通过下面不同的步骤来鼓励团队:
    • 在设计阶段创造一些仪式。在设计讨论阶段,帮助你的团队开发一个流程来评估不同设计方案对质量的影响。为团队准备一些问题,让他们回答他们所考虑的每一个方案对质量的影响,并且在发布之后展示这些问题是如何对整体的质量做出贡献的。
    • 邀请同事评估。在定期的状态审核会议中,为你的团队展示最近的质量度量情况,并且要求每个人站在他们的立场做自己的评估。哪些是他们同意的,哪些是他们对结论有分歧的?不管答案是什么,只要邀请团队做他们自己的评估,就会让他们注意到质量。
    • 鼓励结对编程。如果定期实施结对编程,尤其是在初级的和资深的开发人员之间进行结对,这会鼓励大家在设计和实施的阶段讨论质量的问题。鼓励你们团队的资深开发人员在每一次结对编程的过程中进行讨论。
  4. 员工的主人翁意识和授权。你可以给你的团队授权,让他们做质量决策,并且通过这个结果,他们会感到更强的主人翁意识。可以考虑到用以下方式实现这一点:
    • 识别质量贡献者。创建个人的质量测量(例如每名开发的缺陷、也许根据项目的复杂度会变大),提供可见性,并在团队中赞誉那些获得优秀结果的人。创建一个仪表板,清晰地显示每个人与同事的对比。并且将这个结果用到会议中。
    • 创造竞赛意识。对于大的项目,可以考虑给那些编写出最高质量的代码,表现出众的员工颁奖。确保在开始的时候就宣布这个竞赛,并且说明衡量标准。你会从中获得很大乐趣。
    • 创造学习机会。邀请那些交付最好记录的团队成员参加午饭演讲活动,让他们分享创建高质量的方法、他们所做的设计决定和最近项目的一些产出。在准备这个演讲时,鼓励团队成员展示在他们在某一个功能实施时如何与质量方法的连接,客户、销售代表或者高层领导如何体验。

开始制定指标策略的最佳方法是考虑全局,并为客户,产品和公司确定最重要的指标。随着用于收集和分析数据的工具和软件的广泛可用性,在没有明确目标的情况下收集数据非常容易。

像振幅和工具面板这样的数字行为分析工具可以让团队看到在线客户的行为,并找出对他们工作来说最重要的行为。例如,保险公司可以使用行为分析工具来找出获取客户和索赔提交流程中的摩擦点。找出每个流程中的摩擦点使团队能够优化转化率或完成率,并改进潜在客户和客户的网页上和手机上的使用体验。利用这些工具收集的观点也可以反馈到产品开发周期中,并帮助团队构建更好的产品和产品特性。

图:一个无效的互动模式和一个良好的互动模式

研发流程

整个研发做到了类似于火车发车的发布过程:

  1. 各个bundle在有着自己的需求、开发、测试计划,相互独立。
  2. 主项目制定发布计划,确定集成窗口和发布时间点。
  3. 在集成窗口时间bundle可以自主提交集成。
  4. 集成提交需要走流程,包括填写checklist、代码检查、bug统计、提前编译预集成包进行测试等。这就避免了明显的集成问题遗漏到集成环境中。
  5. 集成期间的集成包每天出一个或者两个,避免了测试人员不断拿包回归的情况。
  6. 集成窗口对于时间要求严格,赶不上计划或者质量不达标的bundle不予集成。这就是火车不等人的原则。
  7. 以上机制保证了手机淘宝每天都有一个候选包,可以随时进行灰度发布,并且灰度发布单独拉取一个依赖配置分支,不影响集成窗口。
  8. bundle的独立,依赖配置的独立保证了手机淘宝可以并行多个发布计划,各个bundle可以按照需求自主决定搭乘哪个发布计划进行发布。
  9. 目前项目节奏为两个星期发布一个版本。如果需要还可以更快的进行发版。最短只需要1个小时就可以发一个新版。

图片 10

所有的项目生命周期都有相应的平台工具支持,如下图:

图片 11

图片 12

图片 13

四. 数据传递的关键在于速率

数据传递的关键在于速率,我们现在都知道ERP, CRM, Billing等这样的业务支撑系统往往都是流程驱动的,而流程本身强调的是预定义的路由,层级和节点,有固定的入口和出口。而对于我们信息的最优传递方法来看,这都是能量传递的损失和减速。

例如:消费者购买商品流程,通过订单系统下订单,计算费用,支付,通过库存审批,备货,快递接单,运输,配送,签收。数据的传递速率直接影响消费者收货的时间和客户满意度,所以在数字化时代,数字的传递效率的重要性已经逐渐超越物流效率(其实物流效率也离不开数据传递效率,现在没有单纯的和数据无关的线下活动),数据传递关键的是速率,而影响速率的主要因素包括:时间t(实时)和传递层级(距离)s。而当数据的传递是依赖一个流程驱动完成的时,自然速率就会降低。通过提高数据传递的实时反馈和缩减传递路径,可以提高信息传递的速率。

在敏捷开发过程中的快速迭代就是一种提高数据传递速率的典型案例,传统瀑布式开发过程中从需求分析,系统设计,开发,测试,上线交付等都是按照完整功能集和研发流程逐级推进,一个步骤完全完成,才进行下一个步骤,最终交付给客户使用。而敏捷开发强调快速迭代,用最小功能集产品快速研发MVP产品,投放给客户(客户有时也是测试人员),在此期间会跳跃式执行研发步骤,最终关心的是客户的实时反馈而非流程的完整。这是研发和客户的信息传递节点少了速率快了,这样方式更适合需求变化飞速,强调系统灵活性的当下。

我们鼓励建立一种客户直达研发生产一线的数据传递方式这样的信息传递是通过建立研发人员和客户利益共同体来完成的,这样的点对点方式传递方式路径最短,速率最快,信息最为保真。这个问题在下面的《从客户运营到员工运营》还会详解。

未来俩个季度收入增加25%指标需要怎么定义输入输出,了解执行团队(MKT或者运营推广团队)和产品领导者如何定义产品指标,有助于确保您和他们沟通时识别与其产生共鸣产品指标,并帮助推动资源分配和决策制定。

衡量标准

十. 数字化企业KPI

关键绩效指标法(Key Performance Indicator,KPI),它把对绩效的评估简化为对几个关键指标的考核,将关键指标当作评估标准,把员工的绩效与关键指标作出比较地评估方法,在一定程度上可以说是目标管理法与帕累托定律的有效结合。关键指标必须符合SMART原则:具体性(Specific)、衡量性(Measurable)、可达性(Attainable)、现实性(Realistic)、时限性(Time-based)。

以上是大家公认的KPI解释,一般来说这个话题总会有两派针锋相对的观点,在传统中大型企业中,强调对KPI使用的重要性,因为在传统的树形组织架构中,KPI是唯一可以量化的评估体系,它是保障企业的计划,任务和目标得以在组织体系中贯穿执行的保障,这就像高考模式一样虽然有这样那样的问题但到目前为止,还是唯一相对公平的手段。而另一派是以互联网初创公司为代表,他们认为KPI就是多余的产物,评价过于片面和功利化,而且经常忽略以人为本的精神,只有在投资人,企业,团队,员工目标不一致的情况下才会使用KPI,在这些初创公司里大家开始目标高度一致,完全不用花费额外成本在监视和制约员工的创造力上。

这两种观点站着各自角度上都无可厚非,都是代表当前不同类型企业的最优抉择。

但这两种观点真得是只是企业在发展到不同阶段的不同选择吗?

例如:初创公司为了提高工作效率和节约管理成本不使用KPI,当企业发展到一定规模和市场处于饱和状态后,才开始使用KPI,就连《逻辑思维》的罗胖也说:目前公司在200人左右不使用KPI,但不保证当企业发展到500人,800人的时候还不使用KPI。

这个答案困扰了我很久,在仔细分析KPI的定义(第一段),并结合大数据的发展历程后突然豁然开朗。在KPI的概念中K是关键指标,关键指标是需要满足当前技术条件和成本要求的SMART原则,而从过去企业BI发展到今天互联网大数据的过程中一直在强调数据的规模效益和关联性优于数据的抽样和建模,今天要构建一个海量数据处理中心的成本要比过去低廉很多。在当前大数据和移动互联网高度普及的今天,原有的关键指标已经不能满足当前需求,我们需要更加灵活,人性化,差异性和实时性的评估方案,也就是说KPI的K需要进化,进化到可以度量员工的情绪,协作,态度和效应。例如:过去我们要评估我们的工作是否产生了客户价值,主要KPI一定是销售额,因为销售额最符合SMART原则,但我们知道销售额高,不代表客户满意,客户价值从何而谈呢?如果过去我们要评估员工是否敬业,主要的KPI一定是工作时长,但我们知道加班多不代表对企业最有益。

在过去的KPI时代往往考核周期是季度、半年和全年,这是一个漫长的,离线的考核,员工无法通过实时反馈纠正自己的工作方法,从而失去了评估的意义。

而在数字化企业里的评估体系SMART原则的技术操作手段更多样化,成本更低,更实时,我们能处理和传递的信息量更为庞大大,准确和高效。也许员工给客户发送的一封邮件,客户没有阅读这样的一个行为能实时反馈给员工用于纠正客户交互方式;也许一次会议过程的讨论的一言堂(无效互动),讨论中心化,就能在会议过程中反馈给会议参会人员用于改进。

在数字化企业里,评估指标是广度覆盖的,是根据需求按需提供的,而且使用成本极低,低到可以满足初创公司的灵活性,高效性要求。也许进化后的KPI应该叫:CPI(Cooperation

Performance Indicator)更为合适,因为我们不在关注关键的抽样指标,而是更加关注企业协作指标(对象,频率,行为,方式),考核员工的综合能力可以通过协作网络以及他的影响力在该网络中传递的速率来决定。

您的数据分析应包含一组费率或汇总值,这些价值或汇总值是实现任务的最佳方式。提出这样的问题:“每天有多少用户这样做或每天用户多少次?对于我们的成功至关重要的是,我们有一定数量的用户采用此功能吗?或者从长远来看,稳定的活跃率是否更为重要?为什么“主动”群组以这种方式定义?“回答这些问题之后,就可以记录一组明确的指标,您将在产品发布之前,期间和之后一致地评估这些指标。

作为创建强大的数据文化的最后一步,团队必须针对正确的衡量标准进行协调,从而衡量在持续的基础上取得的成功和改进的机会。他们应该根据特定的目标以及总体客户满意度来评估自己的成功。

我们这里讲的数字化其实是企业的数字化管理,指通过技术手段度量和管理数据对象的状态和行为,实现企业研发、计划、组织、生产、协调、销售、服务、创新等职能的管理活动和方法。

定义输入和输出指标

高管们可以通过授权给他们的团队来作为创建强大数据文化的第一步,这不仅是为了包容改变,也是为了催化这种改变。研究一再表明,员工授权能增强员工的工作认同感,这也是创新思维的关键驱动力。

九. 我们需要的是一个信息能得到实时反馈的数字环境

我们要实现数字化企业的关键是要构建一个信息能得到实时反馈的环境,该环境是指在企业的生产运营过程中,企业,个人作出的每一项动作或者决策都需要环境给出实时反馈。其实这里的实时反馈环境在互联网创业公司中作用尤为常见,每当一个新产品或新功能要推出市场时,都需要中功能中内置实时数据采集接口,用于观察客户使用情况,客户是否满意?最喜欢什么功能?什么功能用的最多?等都从原有的离线问卷调查模式,转变为在线数据实时采集,这也是一种实时反馈,往往采用这样反馈机制的产品,才能真正了解客户对该产品的真实想法从而可以及时修正产品的方向。

在GE变革过程中“FastWork”(快速决策)一直是至为关键的成功因素,他们尊重每个员工的创意,并且需要决策者用最短的时间回复这些创意。

我们在企业的工作中最常用的沟通方法无非是:邮件,IM和面对面,如果从解决讨论问题的效率方面,毋庸置疑的是面对面是最优方案,那是因为面对面方式往往能得到更为实时和直接的信息反馈。

在互联网初创公司中对KPI考核总是嗤之以鼻的,臃肿的考核模式,非人性化,片面的评估指标,冗长的考核周期都是被诟病的对象。这里冗长的考核周期最为说明问题,一般企业的考核周期是以季度,半年,年为单位,考核目的就发生了变化,这样的考核目的一般只和绩效奖金挂钩而和实际工作改进无关了。(通过一年的KPI考核,成绩在第二年年初产生,你还记得上一年的需要改进的工作细节吗?)难道我们的考核不是以改进员工工作方式为目标的吗?

在教育业这样的现象尤为明显,我们知道一个优秀的小学班主任比一个名校还要重要,而一个好的班主任,不在于她的学历有多么漂亮,知识有多么全面和渊博,而仅在于她对每个学生信息的反馈是否及时,如果每次信息反馈都是靠期中,期末考试来表达,那她就不配当一名合格的老师。所以在教育业不应该争论考试(考试也是一种信息反馈)是否有必要,而是考虑怎么能为每一名学生提供及时的信息反馈体制。

我们再回到企业内部,员工的上下班时间,工作效率,沟通方式,会议决策,吃饭用餐的健康,工作空隙时间安排都是我们需要实时反馈和改进的目标。例如:技术团队内部会经常随机产生对于某个技术问题的讨论,团队中总有一些嗓门大,说话频率高,语速快爱插嘴,喜欢用语气压制其他人想法的人(更有甚者采用鄙视性的语言),最后讨论结果个人智慧代替了集体智慧。这类现象目前的企业管理办法无从入手解决,如果对这位“Monster”(我这样称呼他们)苦口婆心的教育其实完全没有作用,最好办法是建立数字化讨论状态及时反馈体系,在讨论过程中就实时呈现当前的讨论监控程度绿色为健康,红色为不健康,只要是红色即代表本次讨论无效(具体实现参考Café工具)。总之,员工在企业的运营过程受到很多环境因素的影响,而一个信息实时反馈的数字化环境将能帮助公司提高生产效率。

使用通用语言来说明成功的含义以及关键操作的定义,您可能会看到数据的趋势。避免根据已经浮出水面的使用趋势来定义成功的数据结论。您可以通过创建标题或tab来预先评估此信息。

其实并不需要太复杂的环境,只需要关注渠道与更新这两个方面。例如,在渠道方面,当涉及到鼓励围绕数据和新想法进行非正式对话和协作时,您会惊讶于一个专门用于数据的Slack通道所带来的高效率。就更新这一块而言,在团队会议期间共享高级度量标准可以让团队人员清楚地了解,哪些工作是奏效的,哪些是没有意义的。举个例子,如果上周记录的客户满意度有所提高,那么全体团队应该在每周会议上讨论这一问题,查看基本数据,并努力找出到底是哪一个地方的变化促成了客户满意度的提升,无论这项变化是发布了新功能,还是一场市场营销活动。

三. 数字化企业的不仅需要汇聚数据,更需要数据的流动

我们在谈论数字化的时候最先想到的就是把企业已建成的IT系统的数据汇聚和整理,从而分析预测员工动态,企业经营方向等。这本身没错,只是这样还不能称为数字化企业只能算IT化或信息化企业,数据只有采集和存储而没有流动,这样的数字化无意义,我们原来习惯把汇聚数据作为数字化的标准(传统BI就是这样的思路,数据抽取,清洗,整理,分析),数据静态存储量越大,说明数字化执行的越好,而往往忽略数据的流动性,而数据只有流动起来才能产生效力。和传统方式不一样的地方是:我们这里的数据流动并不关心数据的内容,数据内容只有数据请求方和答复方可以获知,数字化企业重点关心数据是否真正在企业组织中流动。

而数据依据什么来流动呢?在传统企业里,企业数据的流动方向常见方式,是按职责汇聚,即:什么样的组织结构和职责关系就决定着什么样的数据流动方向,而且往往这样的数据方向还是单向流动,即:数据回归,因为回归的方式是单一的,所以数据回归的重点在内容。在企业IT系统的树形组织结构中有个名词叫:数据权限,就是通过回归的组织职责关系自动控制数据内容的操作权限,即:只有上级可以操作下级的数据,而下级不能操作上级或者平级的数据。

这样的管理模式和IT系统就造就了这样的数据流动模式,这只是一个逆向汇聚型的,中心化的网络架构,数据在组织架构中逐级汇总后再作经营分析。

而在数字化企业中重点不是数据能汇聚,而是能在员工之间按需自由的流动。我们知道水的流动方向受地心引力影响,而数据的流动方向应受协作影响而非职权影响(回归结构就是一种数据按照职权回归流动的方式)。我们需要一种数据按照协作网络开展流动并彼此传递影响力的一种方式,我们称为数据的协作传递,数据在协作的双方或者多方之间双向传递、互为影响。有人发出协作请求,通过请求将数据传递给协作响应人,数据所有权仅限于协作的直接参与者,而对于整个协作网络我们关注的是互动模式。例如:A员工想搭其他员工的顺风车下班,就需要将自己的下车位置传递给开车的B员工;A员工想让其他员工帮忙检查和分析软件代码bug,就需要把代码源码传递给其他员工;A员工想组织评审自己的技术方案就需要把方案文档传递给参会人员等。

协作传递数据的方式是多样的,所以重点是与内容无关的互动模式。这是数据能大规模,自由流动关键,在《诚实信号》一书中指出:与内容无关的互动模式可以准确测量想法流和决策。而这样的互动模式通常只是交流的对象,频率和方式。例如:我们常用的数据传递工具:Email,如果我们要知道这样的信息是否是有效的传递,已经传递路径是什么,我们不需要去了解邮件的内容是什么,而只要知道这样的邮件交互是以什么样的形式开展的,邮件发出后,收件方是谁?他们是否已经阅读,有回复吗?又转发给了哪些人?邮件交互频率是什么?等。再后面章节我们还要继续讲解数据的传递。

如何添加更多指标或更改计算方式?如果公司目标每两个季度发生一次变化,那么改变您正在使用的指标(比如开发一个爆款H5小游戏),以人/小时或推广代价是否昂贵?这些信息将帮助您准备好回答管理团队的问题,并在公司目标发生变化时提出建议。

与此同时,更广泛的组织必须遵循“北极星KPI”,该KPI考虑到收入驱动因素以及围绕客户价值的度量。例如,一家旅游公司可能想要创建并排列每周满意旅行者的指标,这个指标可以代表对于预订数量的计算。

现在很多企业已经在做企业的IT化化,IT化就是信息化,实质上是将企业的生产过程、资源移动、事务处理、现金流动、客户交互等业务过程数字化,通过各种信息系统网络加工生成新的信息资源,提供给各层次的人们洞悉、观察各类动态业务中的一切信息,以作出有利于生产要素组合优化的决策。

我们今天可以衡量什么,以及访问这些数据有多容易?例如,是运营同事里第三方获取一些简单数据还是工程师专业提取数据?这些数据的途径的选择,帮你确定数据当期的真实实际性。。

在一个拥挤的会议室里,20个人正在激烈的讨论某个技术方案,他们有的人正在默默记着笔记,有的正在低头摆弄着自己的工牌或手机,而Team leader正在慷慨激昂的阐述自己的见解,有的人和他目光交流并不断点头表示认可,Leader正沉浸在以自己为中心的讨论环境中,不断在黑板上指指画画,并强调该方案的重要性。这个议题已经讨论到第三天了,大家疲惫不堪,都希望赶快结束这快要使人崩溃的会议,那些与主题没有直接关系的人为了配合这个氛围强撑着自己的眼皮,时不时点点头应应景,更多的人却一言不发,心里暗想,你是Boss你想怎样就怎样啦。最终大家妥协了,Leader心满意足的通过音量,持久战以及权利让大家认同了自己的想法,并对外宣称该结论是通过大家评审和讨论的结果,是大家共同的产物,但实际上这个结论的参与者就是最核心的3,4人,大多数人只是听众和过客。这样的场景每天都出现在企业的经营决策活动中,看似群策群力,实际还是个人智慧在决定项目的成败,而非集体智慧。我们有什么办法解决这样的问题吗?我们想到了实现数字化决策过程,用技术手段去度量会议的效果,让数据说话,20人的会议如果大多数人都没有参与讨论,那这项结论就不具备有效性。在一个企业的生产运营过程中,还有很多需要被数字化的生产,运营过程,这些过程组成一个数字化的企业,一个数字化的世界。

图片 14

七. 我们需要构建一个企业内部和外部数据交换市场

怎么才能构建一个简单化的数据交换体系呢?市场经济和城市建设的经验就告诉了我们答案那就是:根据供需关系构建数据交换市场,保障个人数据持有者的利益,实现等价交换,保证公正公平的环境,保障个人隐私需求和所有权,按需传递。

首先我们要构建个人数据商店,区分个人隐私数据和企业数据,对于个人数据,例如:定位信息,上班花费的时间,休息时间,同事圈亲密程度,偏好等信息,需要保证它们的隐私性。

在《智慧社会》一书的开放的PDS中写道:个人数据商店可以产生一个公平有效的数据市场。

公平:用户控制对它们数据的获取,并因此可以对服务进行排名和评价。用户可以决定相对于某个服务所需要的数据量及相关企业的声望,来评判该服务是否提供了足够的价值。在提出的框架中,授权用户可以询问如下问题:“找到这首歌的歌名是否值得我泄漏自己的位置信息?”,他还可以轻松地把自己的数据切换到另一个服务中。

有效:用户可以与新服务无缝交流并让该服务获取他们的数据。提出的框架去除了投入新商业机会的障碍,允许最有创新性的企业提供更好的数据驱动的服务。它也刺激了商业,因为用户选择的服务能够避免它们自己收集大部分的数据。商业将会进一步获取由智能手机上的传感器或其他应用与服务收集的历史数据。

个人在享受服务的过程中就要选择性的分享自己的个人数据,只有分享才能消费其他对自己有用的数据,比如:我只有分享自己的定位数据给地图软件,才能获取导航或者道路拥堵数据。

其次要构建DATA BUS,这是一个构建在信息产生源以外的第三方平台我们通过DATA BUS并不需要去了解交易或交换的信息内容(信息内容必须得到隐私保护)。而是去度量信息交换的对象,频率和方式。例如:我们可以通过度量某人说话的音量,频率,语速等与内容无关的信息,评估一个人的性格和说话的习惯,并给出改进意见(也可以根据他说话的时长提醒他喝水的时间)。

资源,即使您找到了可以帮助跟踪指标的优秀软件,运营经理也可能需要时间来为您的应用程序添加跟踪或帮助您提取数据。 通常,生成详细报告的能力不是创始团队的高优先级,可以利用第三方数据分析软件来代替反馈。

十一. 数据监控,非员工和客户所愿

设想一下如果我们的邮件,电话,沟通等一切操作都在一种完全监控的环境一下不论员工或者客户都会逃避而不是拥抱数字化。

我们需要数字化为企业生产运营带来优化,为客户消费带来便捷,但更要为他们提供一个安全和可信的环境。而数据监控不是企业的数字化,因为数字化关注的数据的流动的对象,频率和交互,并不需要破解数据的内容,数据内容的控制权还是交给数据的所有者吧!在这方面企业并不能比员工,客户占有更大的优势。如果我们想通过对数据内容绝对的控制权和监控来掌握员工和客户的一举一动,往往会得不偿失,还有违法风险。这样的环境无论员工还是客户都会避之不及怎么可能去使用和拥抱呢?曾经我有同事告诉我千万不要在使用公司的wifi时,用聊天工具,邮件等讨论一些对公司不利的话题,比如:弊病,牢骚,甚至对某些领导的不满,因为我们的聊天会被监控甚至会被领导约谈的。当然我并没有真正验证这样的机制是否在公司存在,但我想告诉这些管理者,如果你真以为这就是数字化,那就大错特错了,我们会远远的躲避你,以及你所提倡的数字化。

注意:保持现有用户x倍的时间。

十四.  从客户运营到员工运营

企业运营其实就是对于企业的生产,服务活动的过程化管理,体现在运营对象上就有:企业组织和流程,客户和员工,体现在运营手段上有:解决方案,合约,产品,服务,资源。体现在管理方式上有:计划,组织,设计,研发,实施/生产,服务和改进。

企业运营包括客户运营和员工运营两个主题:客户运营是把运营对象放在客户身上,以客户为中心,关注客户的生命周期;员工运营则是把运营对象放在员工身上,以员工为中心,关注员工的生命周期。从企业运营到员工运营看似功能差异不大,其实主体的变化代表着思考问题的不同,例如:企业运营中为了考评员工绩效,其中一项很关键的指标是出勤率,如果是基于企业组织和流程的运营,肯定要求员工严格实施打卡制度,并纳入年终考核绩效,但如果不考虑员工的想法和实际情况,就不能算员工运营方案。而员工运营的重点是要考虑员工的利益,当然员工这个角色存在的前提首先是企业,以及怎么实现员工,客户和企业的三方共赢。所以员工运营就不能不关注员工在企业运营中的生命周期。

员工的生命周期从应聘者向企业发出第一份简历建立了与企业的关系的时候到最后离职结束(其实这个时候和企业的关系还没有完全断绝,只是没有合同约束而已),大致跨越了:人才获取,人才融入,人才绩效和激励,人才培训和发展,人才离开5个阶段。这是一个庞大的话题,我本人并不是HR专家,所以本文章的焦点主要放在员工中企业的价值是通过什么来体现?

实现员工价值,客户价值,以及企业价值一直成功企业追求终极目标,依据德鲁克的概念,企业的目的是创造客户,而不是挣钱的机器。而实现创造客户的主体是员工,因为只有一线员工最熟悉客户。怎么让员工,客户,企业共同实现共赢目标呢?

在早期西方经济学理论中认为市场竞争机制一直是社会蓬勃发展的根源,而现代科学研究表明,在人类社会中,合作与竞争一样的重要和普遍。从进化论来说适者生存是主题,生物个体间的竞争异常激烈,生物的个体进化都是按照竞争最优方案选择的,但实际上生物个体中确有很多现象的进化方案不是按照个体竞争最优化来进化的,而是按照集体竞争最优来进化的,集体内部采用协作方式完成价值交互。例如:在一个狮群中雌狮的进化方案是最适合生存的,无论从爆发力,耐力和捕猎能力来说都达到了最优化,但雄狮的进化方案确不是为了生存和捕猎而选择的,它选择了协作方案,雄狮为雌狮以及群体提供了安全以及提升了和其他狮群中的竞争力。这类协作在动物和人类社会中比比皆是。

我们抛开经济学理论,仔细研究微观协作机制,将对我们形成员工,客户和企业共同体的最直接和有效的办法(当把员工,客户和企业看成一个团队一个整体后,要实现这个组织的正常运转就需要协作)。

而员工运营和客户运营的话题是不能分开的,创造和服务客户是员工工作的目标,也是企业的目标。而通过数字化手段构建员工和客户运营体系也一直大多数企业正在做的事情,这就有了一开始我们提到的类似:OA, CRM, Billing和ERP这类系统,它们从一出现就是企业运营IT化的具体实现,这些系统实现了解决方案,合约,产品,服务和资源整合;实现了计划,组织,设计,研发,实施/生产,服务和改进流程串通;同时也实现了员工到客户联通(准确来说是预定义单向联通,不是互动) 。但总体感觉无论客户运营还是员工运营都没有达到人们的预期, 原因是我们没有考虑协作以及协作所产生的交互作用在员工运营和客户运营中的作用。

例如:在B2B市场,一个20人PRD(Product Research Department)团队通过120人月的工作开发出一套订单系统,通过PSO(Professional Services Organization)给客户做工程实施,PSO和客户沟通,PRD和BA(Business Analyze)沟通,BA和客户,PSO沟通。整个运营过程有流程,有分工,有管理,但无协作和互动,PRD研发成员不会同客户产生协作关系,不会向客户提出关于这个需求缘由的问题,客户也不会问研发这样设计的依据和考虑。员工和客户之间是采用传统指定接口人(PRD, BA)的方式运转(协作网络呈现星型结构),信息传递容易失真,效率低下。而协作是双向的,是一种带权重的有向网络。(当然要说完全没有一点信息反馈也不客观,客户可以通过企业预定义客户问题流程反馈信息,只是这些反馈信息对研发运营的帮助真得可以忽略不计)。

一个案例:某电信运营商一年花上百万投资希望建立一个客户问卷调查系统,希望客户能在使用完服务后反馈服务使用意见。如果我们转换一下角色想,你是客户你为什么会免费给运营商提意见呢?而且这些意见最终的归属就是数据库里的一条记录,对改善服务没有任何帮助。最有效的信息反馈其实就是在企业和客户的产品使用和服务期间实时感知实时反馈,而不是离线反馈。某个音乐播放网站APP也定期淡出问卷评估,但其实可以通过播放音乐的过程感知来和客户进行实时互动,如果一首歌曲刚播放到20秒就被快进,不就说明客户对这首歌曲的不满意吗!

对于电信运营商,客户在消费服务的过程时也是可以实时感知的,网络稳定与否,语音图像是否清晰,这些客户的使用行为反馈就是实实在在的互动。

应该这样说企业的服务过程本身就不是单向的,而是有权重的双向网络,服务本身就是一种协作(有偿或无偿),而建立数字化的服务运营感知体系就是员工运营和客户运营的重点。

我们现在知道很多主流B2C的网站和APP在设计之初就把流量反馈和用户使用反馈的工作作为上线后运营重点,而下一代的员工和客户运营系统不仅是需要信息单向反馈而是要建立实时协作交互能力,这是在互联网时代告别野蛮扩张,进入精耕细作阶段的必备技能,暨:客户对服务使用,消费和员工对客户的服务都是动态交互和相互影响的。

例如:在软件研发行业B2B市场一位研发人员开发了业务系统的某一功能,而该功能的实际使用者是这个企业的员工或者是它的客户,其实两者或者多人之间就建立了某种联系(原来我们一般理解为B2B市场发生关系的是企业和企业与人无关),消费者使用频率高,依赖程度强,A公司开发人员能感到自豪和骄傲从而促使在该产品上投入更高的热情和智慧。消费者感知到开发人员到用心良苦自然也更加尊重对方的劳动成果。

A公司研发人员,B公司员工,消费者之间可以形成协作社交关系,这种协作社交并不是要消费者和A公司研发人员直接电话或者IM联系,而是通过建立协作网络的形式透明化的告知,传递情绪和想法。每一次的客户价值产生通过该网络传递到每一个项目参与者(重点是人而非组织),真正实现荣辱与共,或者我称为的:价值共同体。

消费者对于产品使用的满意程度,活跃度,效率等价值指标直接通过该协作网络传递到该产品的开发,测试,运维者身上,而研发和生产的过程需求响应,加班等也实时通过该网络传递到客户和最终消费者,真正实现价值共同体。

如果说一个企业的协作是运营的关键,那我们为什么不把运营的重点放到保障有效协作的产生中来呢?

每月数据点数。仔细监控您的使用情况,工具可能会变得非常昂贵,尤其是对于页面浏览等虚荣指标。

我们首先来看看什么是数字化,一般现在对数字化的狭义解释是:将许多复杂多变的信息转变为可以度量的数字、数据,再以这些数字、数据建立起适当的数字化模型,把它们转变为一系列二进制代码,引入计算机内部,进行统一处理,这就是数字化的基本过程。

评估表现

八. 通过正外部性的社会压力影响的效果大于负外部性惩罚

在《智慧社会》一书中,社会压力是指社会机制激励同伴(通过对他们征税或补贴)对个体施加(正的或负的)压力,从而导致负外部性的下降(或正外部性的增加)。在协作网络中可理解为通过某种策略或机制对个体在网络中的伙伴进行正向或负向的激励以促使其对该个体施加压力,从而使个体更倾向于与他人协作。(这里我们不考虑破坏协作的行为所带来的负外部性,所以施加压力的结果多表现为一种正外部性的增加)例如:在同事协作过程中有的人表现活跃,有的人表现冷漠我们采用正外部性的的社会压力影响就是将他的事迹发扬出去,激励他自己和刺激其他人向他学习的方式替代采用对表现冷漠的直接惩罚或者公开批评的方式,前者效果更好。很多企业都在纠结上班打卡的必要性问题,当然在这里我们并不是分析打卡的好处和坏处,而是利用正外部性打卡的方式可以更容易被员工接受,而企业也能得到想要的成本数据,正外部性打卡就是鼓励那些采用新型打卡手段,例如:手机定位,二维码扫描等方式鼓励大家签到,但绝不会对没有签到或者签到少的员工采取直接惩罚(因为没有签到打卡原因多样化,没有一种办法),而是采用正向激励手段鼓励那些积极签到的人,开展签到升级,打怪活动。让社会压力向正外部性传递。

社会压力会在协作网络中产生影响,并在协作网络中传递。但与因社会参与和社会关系所产生的固有协作网络不同,社会压力则是一种基于协作网络结构,利用外部手段对原有协作网络施加的一种干预,并通过这种干预来提高局部结点的正外部性。

未来两个季度业务成功的三个最重要指标是什么?业务计划在启动时快速变化,因此在项目初期,即较短的时间,产品指标框架开始是有用的。

企业的数据化:是把企业生产运营中所产生的数据进行资产化的管理,优化,计算,展现。

Ë ngagement:一个用户多少与产品交互的措施。

图片 15

可能会有一些关键行动来衡量 - 例如采用过程的开始和完成用户的活跃数。投入时间来测量产品,明确定义测量内容以及测试方法,并围绕团队将跨职能使用的KPI作为一种通用语言。

三、计划和指标

使用正确的工具

指标。填充列表中每个指标的名称,定义,目的和计算方法表格。

一、指标的三个维度

二、产品迭代怎么定义指标策略?

保证数据来源的真实性和可操作性。第三方数据平台帮你快速检索数据以及可以派生的需求指标,比如数据埋点产生的需求变更。需要你请教项目经理和数据分析师:

图片 16

检测,监控和衡量产品的KPI对您的指标策略至关重要。。

获得高管的支持。确保执行团队了解您正在测量的内容以及您不测量的内容。

用户数据。他们可以跟踪哪些用户数据?你想跟踪吗?你停止跟踪它有多容易?

短视或未对齐的指标。 如阿里巴巴早起的北极星指标是询盘数,你不可能基于签署的商家协议的数量,因为开店数,商户数,订单数无法长期保留。数据可能显示三个月是关键拐点,表明平台询盘完全致力于他们的订单,因此计算达到三个月标记的询盘数是一个更有用的成功指标,而不仅仅是签署的商户协议数量。

图片 17

例如,如果你的指标未来俩个季度收入增加25%,那么你的关键行动是拉新。你也可以尝试这个句子结构:我们希望增加到/ by的采用,因为我们知道采用这个的用户更有可能(接受与我们的使命相关的z好处)ARPU值。该声明将您的关键行动转变为具体,可衡量,可实现,现实和及时的关键绩效指标。

产品指标的共享总是有用的,因此可以向团队成员和利益相关者提供指标。避开冗长的电子邮件。创建标准化报告,您可以在站会指出这些报告,或者使用单张幻灯片进行全体操作或任何产品评审会议。关键是为团队成员提供问题并随时了解情况。

定义输入和输出指标

选择工具后,自己后台会开发一个分析规格表,以帮助使用正确的触发器测量正确的事物。规格表是一种向团队传达要测量的内容和原因的方法。

根据这些指标优先考虑项目工作是否重要,或者是否有其他指标的空间?这些信息将帮助您确定是否应该关注如何推动完成可带来收入的功能(如运营,市场一线建议的功能),或者您是否可以腾出时间从事技术更新和体验功能小改进。

如果您需要记录您的计划,请使用以下标题创建文字处理文档或幻灯片:

时间,在创业公司,团队中的任何成员都会有并行事情需要做,并且要迅速采取行,会产生很多研发压力,设计压力。产品经理的指标纳入项目流程,需要在项目启动会之前的时间和干系人讨论。

清晰度,产品经理弄清楚在产品中什么衡量是重要的?以及它与公司总体目标的关系产品,产品经理很难像市场一线清晰。产品经理指标清晰度在不同产品生命周期阶段的变化程度,取决于前线市场团队和老板定义产品成功的方式,以及项目经理路线图和关键绩效指标的完整形成程度。 所以,弄清楚如何将指标映射到产品功能,并将其与结果联系起来,做到产品生命周期每个阶段都精准。当产品迭代时间和资源紧张时,需要产品经理准备好经常审查并灵活处理干系人关系。

定义您的北极星指标

通过查找和使用与主要产品用例一致的比率并将这些比例与平台的整体视图进行平衡来避免此陷阱。

四、注意事项

图片 18

设定报告内容和时间的期望。您不希望创建这些报告的任务接管您的生活(微信公众平台定时发送)。

在一段时间结束时,如果您的产品不能满足其用户的需求,那么它就无法实现其目的。您的产品会发生变化,有时这意味着您还需要迭代您的指标策略。通过创建度量策略构建帮助您做出迭代决策。

数据监控

关键人物。枚举将此数据提取,分析,使用和维护的人员。

一个 doption:新用户在特定的时间段数。

漏斗跟踪。他们是否有即时使用的开箱即用漏斗?

了解与公司其他人会面的重要内容。你想要输入和指导,而不是人云亦云。

H appiness:用户态度或满意度的衡量标准。

定期分享任何产品情况 - 无论是研究,线框还是指标 - 都可以帮助您以自己的方式利用整个团队的观点和创造力,增大活动进度中做出反应的机会。

定义度量策略可能看起来很复杂,尤其是当面临项目启动会的约束时。但是,定义策略的过程本身就是一项有价值的工作,因为它迫使一线执行团队,产品和项目团队达成共识,并明确了解公司的优先级,业务战略和产品路线图。

图片 19

确保指标策略具有持久力:

关键指标定义成功

报告功能。您可以生成哪些数据报告?他们提供见解还是数字?

如果有重要的产品特定指标,它们是否可以汇总到公司的关键指标中?产品特定的指标包括应用程序的正常运行时间内,您对客户的功能请求或错误报告的响应能力。比如第2点我们说要把收入增加25%的目标,执行团队是否认为产品特定的指标(拉新?存量?增量?)是一个促成因素?如果是,你将迭代的功能报告为收入目标的输入。如果他们不是促成因素,就在产品需求池或项目表里继续跟踪,因为该信息可能仅对产品和项目交付最有用。

保持简单易行。尽可能使用不太难获得或维护的指标。大多数初创公司没有资源花费很长时间来提取和分析数据。

过时的指标。随着您的产品开发以及您的销售技巧,互动甚至商业模式的变化,您将需要停止并重新校准。例如,随着产品的成熟,服务的可靠性和用户的保留可能成为业务的转向力量,并取代原始的KPI以实现增长和收购。

自动跟踪功能。该工具是否会自动跟踪任何数据?

产品经理或项目核心需求为什么你在做什么,并用它的指导,告知什么你想要的目的。查看可以跟踪的行为和操作时,清楚地理解为什么简化了定义迭代成功的任务。

目标。在几个句子中,解释为什么要收集这些数据以及您打算使用它的原因。

分享。概述此数据的更新频率,可以找到的位置以及允许其访问的人员。

Google研究团队开发的HEART框架:

将这些措施应用到产品开发过程中,最好是在规范开发阶段(产品规范,设计规范,需求规范,项目开发规范等规范)。并非每项计划都会推动指标,制定明确的计划,高层次使用指标,将有助于确定每个项目的具体情况。

产品如何影响这些指标?产品成功通常与公司指标密切相关。假设您的初创公司希望在未来六个月内将收入增加25%。要做到这一点,您将需要新客户。如果您正在迭代的重要功能对于保护部分或全部拉新非常重要,那么它与公司目标相关联,是未来三个季度业务成功的重要指标。

产品经理通过”策略模型”适合明确业务目标/设计目标的项目产品。

定义您的北极星指标

将您的North Star指标视为输出指标。您的输入指标是获得该结果所需的操作。要制定输入指标,请考虑人们必须采取哪些措施才能生成所需的输出指标。最低级别的输入指标应该是您可以开发测试和跟踪进度的东西。

总之,我们分析了目标和产品特点指标,数据来源俩个问题,可以帮助我们在特定的时间,资源和清晰度的约束下最佳地工作,以达成有用且可行的指标策略,俩个季度提高25%。

在考虑指标策略时,我建议您执行以下步骤:

WBS:可以分解成更小的组件; 例如:花在任何给定任务上的时间(可以改进流程吗?

搜索第三方工具时需要考虑的事项:

对齐重要的测量类别

本文由betway必威登录平台发布于互联网论文,转载请注明出处:企业想建构数据驱动文化,这五点一定要做到!

Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。