数字消费者与传统行业互联网转型

面对换商经济的冲击,从前几年尝鲜感受电子商务,到最近不得不为之,传统企业正在发生着变化,它们认识到消费者的生活方式已经彻底改变,数字化、智能化和社交化已经成为新常态,这迫使传统企业开始寻求打通线上和线下多渠道的途径。埃森哲2013年中国零售商全渠道零售能力调查显示,63%的传统零售商已开展多渠道零售,78%的单一渠道零售商正计划向多渠道转变。受调查企业中61%已拥有独立官方网,超过半数 (52%)已在第三方平台开设了网店。

数字体验业已成为消费体验不可或缺的重要组成 ,越来越多的企业也意识到了提升数字体验的重要性,从我们的观察来看, 围绕用户体验的提升建设企业分析数据的能力,打通线上和线下的体验是传统行业互联网转型的一大类方向。

用户数字体验,新方向

提到用户数字体验的提升,常见的误区是把用户数字体验简单的看成视觉设计而没有意识到用户数字体验的改进是系统工程,从实施的角度看,它往往被划分为快速启动、体验设计和实施三个阶段。快速启动关注愿景,着力于帮助相关人之间对未来产品的愿景达成一致,然后规划并设计产品最核心的用户体验, 包括完整的信息架构、信息及交互设计。在设计的过程中,往往采用各种原型工具来辅助交流,让相关人减少误解,尽快达成一致。

有信是微信在国内最大的竞争对手,设计团队和相关负责人在快速启动中从企业用户场景和业务模式入手,识别出了“舍不得挂断电话的异地情侣”的场景,从这一点出发,设计团队利用纸质原型、互动原型、低保真原型、高保真原型对需求进行了充分的发掘以及交流,从在相关人之间达成了对业务模式和设计的共识。

Screen+Shot+2014-12-23+a

体验设计关注设计本身。体验设计主要回答三个问题,用户看什么内容? 用户怎么找到这些内容?用户消费内容时的感受如何? 看什么内容是内容策略,设计团队往往需要从业务上下文出发对现有内容进行梳理。“怎么找到这些内容”是产品的信息架构,需要应用交互设计原则对产品的核心交互行为进行系统性的设计,这这个过程中,往往会利用用户的真实行为数据来辅助设计,让整体设计更容易落地。“感受”是视觉设计,即通常意义上的做“漂亮”,设计团队往往结合企业现有品牌和视觉标视对产品进行定位和设计。

实施关注的是验证和演进。产品在使用中往往有很多意想不到的地方,这需要通过真实数据不断验证,对设计进行调整打磨。买房网 是面向中国富人销售澳洲房产的项目, 设计师在初期设计了 澳洲行政区域图 ,用户可以通过点击区域来完成相应的搜索,令人吃惊的是 这一特性 上线后使用度为零。在回访中,设计师发现用户不知道这个图是可以交互,这说明设计过于复杂,需要进行调整。

用户常见的行为是在网上对商品进行比对、挑选、购买,再通过实体店享受产品和服务,数字 体验的改进必须同时考虑线下和线上。诺德斯特龙((Nordstrom)是美国一家高档连锁百货店,它 推出了一个 具有交互功能的显示屏 科技产品,一眼看去就像镜子但镜面可以交互,顾客可以在试穿衣服的同时浏览不同的尺码、颜色、款式甚至是产品评价,就像网购一样,不过优于网购的地方是:顾客可以随时召唤店员把想要购买的衣物拿过来让他们试穿。而不是试完一件衣服后脱下,又换上自己的衣服走回销售区去找挑选。 充分利用传感器和数字技术增强用户在物理世界的体验是线上、线下体验整合的新趋势。

9209426C-6213-4113-9E32-

创新,没有最好,只有更好

创新,则是着眼于尚未满足的体验。尼尔森提出了创新的三步:第一步,找出的尚未得到满足的需求,思考怎样才能实现;第二步,通过一种进化的测试-改进程序,不断地改善这些概念,进而完善依据这些概念而推出的产品;第三步,上市推广。

在实践中,我们发现寻找“尚未满足的需求”有两个关键路径,首先要学会与用户合作创新,Woolworth是澳洲最大的超市,客户对付款时排队久抱怨极大,Woolworth想通过手机应用让用户可以随时扫码付费,提高用户体验。设计团队采取了在超市现场与用户共同研发的方法,在几天内他们就发现这个计划行不通,大量客户不习惯提篮子所以腾不出手来使用设备扫码。同时,团队发现了一个“尚未满足的需求”:帮助客户决定晚餐吃什么? 并最快找齐食材,满足这个需求会大大提升购物体验和销售收入。

Screen+Shot+2014-12-25+a

学会与IT合作创新是另一个关键途径, 当今IT的角色绝不仅仅是支持业务,企业应当建设IT与业务融合的能力。内部创新日是帮助市场与 技术结合形成草根创新的行之有效的方法。 市场和IT部门自由组队围绕某主题进行头脑风暴,产生创新想法;团队2天内利用各种快速开发技术产出产品原型;通过创新市场 共同向市场部门 推销产品,寻找内部投资; 最终实现产品化。澳洲最大的房产门户正是通过这一套方法孵化数十个新产品。

尼尔森所提到的可演进的测试-改进程序是 不断试错、快速小步骤改进产品的能力。这种快速、高效、灵活的向用户交付新功能的原则和技术实践被称为持续交付。通过实现自动化的构建、部署和测试过程,并改进开发人员、测试人员、运维人员之间的协作,交付团队可以在几小时(甚至几分钟)内发布软件变更,从而得以不断收集数据判断软件的功能是否被用户接受,继而作出相应的改进。

围绕企业的核心竞争优势,寻找差异化,利用IT进行创新是我们观察到的另一大类企业互联网转型的方向。

着眼未来

马云和王健林打赌未来电商能不能超过零售的50%,雷军和董明珠以10亿豪赌小米在五年后能否超过格力。随着阿里巴巴的上市和小米的突飞猛进,让人颇有传统行业江河日下的 感觉。但其实风生水起的数字消费不过占了整个零售市场9% ,传统企业还大有潜力可挖。

着眼于中产阶级的消费升级。更更有趣的购物体验将吸引中产阶级回到传统渠道。电影是个很好的例子,在Youku, iQiyi们25元包月看电影的冲击下,中国全年电影票房依然保持着27.51%的高速增长,电影院提供的已经不仅仅是电影本身,而是周末全家出行,从吃到娱乐的全套服务和体验。

着眼于大规模定制化。定制化意味着差异化,从差异化出发, 传统企业可以避开目前数字渠道的劣势,以及充分利用生产的强项。 定制与大规模经常是一对天然的反义词,而最近然声名鹊起的红领西装,就用规模工业生产满足了个性化需求。定制西服往往就意味着手工量体、手工打版、制作毛坯等,一条小型定制生产线一天产量一般在五套左右,而让红领每天可以生产1200套西服。红领充分的利用了企业现有数据和计算机辅助设计大大提高了效率,而用户则被粘在了红领的终端上。在其它企业饱受高库存煎熬时,红领今年以来却实现了生产、销售、利润指标150%以上的同比增长。

着眼于未上网的消费者。在中国还有超过7亿没有使用互联网的消费者,有些是因为年龄的原因难以掌握新技术,有些是因为教育的原因,相比于互联网,传统企业的营销网络可以在不同的区域采取不同的策略,更容易去服务这个群体。

着眼于服务。劳斯莱斯在飞机引擎中安装了上百个传感器,引擎工作过程中任何的微小细节, 如振动, 压力, 温度, 速度等,都会通过卫星传送到进行数据分析的计算机中。通过利用这些数据,劳斯莱斯可以预测引擎的问题,根据航班的安排,可以在飞行目的地机场安排备货及时维修。这样,劳斯莱斯把自己从提供硬件重新定位为提供服务,从而获得更高的利润和粘性。

Share

极限会议: 原则与实践

luobosi.rules_

极限会议是解决开会过多, 会议效率低下的一组原则和实践. 它基于两个简单的理念:

  • 如果一个实践是有用的, 那么我们能不能把它做到极限?
  • 如果每个人都尽自己极限努力推进会议进程, 那么会议定会卓有成效.

会议效率是产出和所花时间的比值. 我们的原则跟实践, 有的致力于提升高价值产出, 有的致力于缩短所需时间, 有的两者皆涉及.

比如说:

  • 如果答疑对听众是有价值的, 那么我们能不能把它推到极致? 极致就是如果没有人有疑问, 就不要召集会议, 由有问题的人召集会议, 而不是有信息的人召集会议, 把推模式变成拉模式.
  • 如果做结论是好的, 那么我们能不能从第一分钟起就开始做结论?
  • 如果换位思考是好的, 那么我们能不能把它做到极致, 与会人员交换立场来发言?

这类实践会比较多, 本文主要介绍在其它类似主题的资料中少有涉及的几种实践. 更全面的实践敬请期待后续介绍.

会前实践

实践: 缺省是不参会

最节省时间的方式是减少参会的数量. 对于所有会议, 缺省是拒绝参加, 除非满足以下两点之一:

  • 你有问题想当众获得答案
  • 别人有问题想当众获得答案, 而你有其他人没有的信息或观点

总结一下就是, 如果你可以不发言, 就可以不去开会. 不发言意味着你对会议议程和结果不会产生影响, 同时你有很多其它途径可以获得会议内容及结论. 而一个等价的关于会前准备的规则是, 要么带着问题参会, 要么带着信息和观点参会.

如果你不确定自己有没有问题, 比如会不会讨论中触发你的疑问, 那你随便, 自己决定.

开场实践

如果做结论是好的, 我们从第一分钟起就做结论.
实践: 一分钟结束会议常识是会议结束时要有结论. 而常识往往不是最高效的. 有多少次, 你听着主持人开场介绍各种背景, blablabla, 而你不知道重点该听哪一句, 思考哪个方面. 好一点的主持人会介绍会议目的, 但依然无助于快速得到结论.既然你已经不得不来开会了, 那么节省时间的手段无非就是如何尽快的得到结论从而结束会议. 能花一分钟就不要花两分钟. 一种做法是先说结论, 先表决结论, 不一致了再讨论, 一致了就可以随时散会了. 这个实践也叫: 先表决再讨论.

最常见的两个例子, 是面试和工作量估算. 几轮面试完毕, 面试官开碰头会决定候选人去留的时候, 可以先手势表决, 如果大家意见一致了, 那么后面的讨论就可以随意点了, 你如果有事中途离席也影响不大了. 不一致了再讨论.

工作量估算也一样. 如果你还保留着估点的陋习的话, 那么一开始也是先表决, 意见一致或接近, 讨论时间就可以压缩.

每条规则都有适用场景. 你可能觉得一分钟结束会议适用于封闭性结论的讨论, 比如上面的去留或点数. 对于开放式的讨论, 开场根本就没有结论, 如何表决?

上面的质疑是有道理的. 但即使对于开放式的讨论, 也可以开场就扔个结论出来, 不过其意图不是快速结束讨论, 而是更好的激发讨论.

会中规则

如果积极思考是好的, 我们就把它做到极限.
下面的抛玉引砖, 欺负老实人, 挤牙膏等实践希望把与会人员的思路激发到极限.
实践: 抛玉引砖你很不幸, 会议没有在一分钟内结束, 只能让讨论尽可能高效了. 人们总是善于批评, 拙于创造. 利用这一点, 你只需扔块玉, 就能激起民愤, 群起而攻之, 一堆板砖飞过来.为什么不叫抛砖引玉呢? 这牵扯到对初始结论的要求. 初始结论必须极端, 才易于激发讨论. 它要么是工作量最小最简单的, 要么是最大最复杂的, 要么是最无厘头的. 总而言之, 你需要脑洞大开. 四平八稳的结论无助于大家思考.

比如对于任何(注意是任何)需求实现方案的讨论, 你都可以这样开头: “这个功能, 我们打算用导入导出Excel来实现, 大家有什么意见吗? “ (“有, 为什么不用金数据?” “…”)

实践: 欺负老实人

有时候作为主持人, 你感觉到场内不是每个人都精力集中, 开动脑筋, 而是开小差, 看手机等. 或者即使不看手机, 也感觉没有投入. 如何让大家始终精力集中呢? 你只需缺省做出对大家不利的结论即可, 除非参会人员抗争, 否则就是定论.

还是拿估点的陋习举例, 尤其是你的交付方式是基于承诺的风格的话. 在计划会议上, 你可以宣布, 所有story, 缺省都是一个点, 或者都必须在一天内完成, 除非开发团队拿出足够的理由. 这时大家为了合理的工作计划, 必须全神贯注的讨论对Story的理解.

会有一些副作用吧. 所有规则都有适用场景. 这个适用于跟团队的信任关系已经建立起来, 团队理解这是讨论的技巧而不是真正的压迫.

实践: 挤牙膏

有时你会发现气氛比较沉闷, 掌握最多信息的人拼命在说, 想把知道的一切都告诉大家, 但听众没什么反应. 一个可能的原因是你说的太多了, 剥夺了听众主动思考的机会. 那么指导思想很简单: 说得越多越沉闷, 问得越多越活跃, 我们只需要制造一种张力, 让团队不得不问.

还是拿估点陋习来说. BA惜字如金, 拿着Story, 除了念一遍, 不做任何解释, 就让大家估. 除非开发人员发问, BA不需要说任何一个字. 就算是回答开发人员的问题, 也点到为止, 一个字都不多说, 除非开发人员继续发问. 反正缺省都是一天做完, 而BA可以通过Story Kickoff, Story Signoff等手段来把关不会有验收条件缺失. 开发人员要争取合理的开发时间, 必须主动发问以获得足够的信息. 这在基于承诺的开发方式中比较适用.

如果获得全面的观点是好的, 我们就把它做到极限.

下面留白, 拱卒, 暗牌, 叛变等实践, 都是为了获得最全面的意见.

实践: 留白

如果你有多于其他参会人员的上下文, 甚至你知道讨论的话题某种程度上在开会之前就已经有结论了, 但你又想知道大家真实的想法, 各自的逻辑, 以便更好的利用集体智慧, 那么你应该留白, 不要一次性把所有上下文和结论都扔出去, 而是随着讨论的推进, 一点点的把约束加上.

上周项目开工会之前, 韵涛纠集了少数几个人上午讨论了下开工的准备工作, 有了一个初步的事项列表. 下午整个项目组开工讨论的时候, 我并没有直接抛出上午的结论, 而是让大家提供自己的意见, 就当上午的会没有发生过. 上午的结论只是备胎, 查缺补漏.

实践: 拱卒

有时你提供了发言机会, 但发现机会被少数人把持, 其他人参与程度不高. 常见的建议是轮流发言. 这里我要说的是, 仅仅轮流发言是不够的, 顺序很重要.

参与程度不高的两个原因是:

  • 即使我不参与, 反正也有别人参与, 即使没有我的输入, 反正也能得出结论.
  • 别人都已经说了, 我没有什么新东西.

那么我们可以让寡言者, 对话题不熟悉不权威的人先发言, 上面两条原因的前提都不存在了: 此时还没有别人参与, 别人也没说什么, 那么我不得不说. 而对话题上下文比较熟悉的人, 永远都可以在后面补充, 他们不会有什么顾忌.

统计表明, 机长驾驶飞机的事故概率高于副机长驾驶飞机的事故概率, 因为机长驾驶的时候, 就算副机长发现有什么不对劲, 也不太敢指出. 而副机长驾驶, 机长在旁边监督, 一旦发现什么问题, 机长是没什么顾虑的. (信息来自<<异类>>). 这是类似的做法.

实践: 暗牌

跟拱卒类似, 你想获得更全面的观点, 但又担心部分人员被权威影响. 那么只需让每个人准备好自己的观点, 同时亮出来就可以了. 这样异议就会暴露出来, 获得足够的关注. 面试和估点依然是常见的两个例子. 它跟一分钟结束会议形式类似, 意图不同. 一分钟结束会议是为了节省时间, 暗牌是为了暴露异议.

实践: 叛变

当你总是基于自己立场的话, 你是狭隘的. 常说要换位思考, 那为什么不直接换位呢? 销售和产品团队开会, 销售人员从产品团队立场去辩论, 产品团队从销售立场去辩论. 任何涉及多种角色合作的会议, 都可以尝试换位.

如果具体比抽象好, 那么我们就举例说明, 看图说话

实践: 比如说

有的人说话形容词副词太多了, 动词名词代词量词数词太少. 智能的, 自动的, 高效的, 等等. 碰到这种情况一定要摁住, 让他举例子. 你不需要在意他说了什么东西, 你只需要在他说完一句话停顿的空隙朱唇轻启补上一句: “比如说?

实践: 看图说话

这个在别处有详细介绍, 比如<<视觉会议>>等. 不多说了.

如果简短是好的, 我们就做到极限, 一个词, 一句话, 一分钟.

实践: 调教

有的人讨论很发散, 表达很跳跃, 永远都是在陈述, 在打转转而不对原始命题表态. 这种情况一定要摁住, 让他做完形填空. 打断他直接追问同意还是不同意, 限制他一个词或一句话或一分钟表明立场.

一个完形填空的例子就是Elevator Pitch, 提供一种结构化的断言, 来收敛结论.

收官实践

如果达成共识是好的, 那我们就追求内心深处的共识.
实践: 闭卷考试“大家都清楚了吗?” 这种问题是没有意义的. 大家都说”清楚了”你也无从确认是否真的清楚了. 而在讨论结束的时候, 我们需要每个人都对当天的结论, 后续的行动有一个一致的认识. 会议结束前我们必须验证大家的理解. 方法也很简单:关掉投影, 擦掉白板, 合上电脑(除了放投影的机器, 这个东西本就不应出现在会议室)和记事本, 参会人员依次回答每个议题的结论, 以验证对会议的理解是一致的. 第一个人说第一个结论, 然后问其他的人是否同意还是认为结论另有其它. 说完之后第二个人说第二个…

要点在于参会人员不得参考任何资料, 只能依赖自己的大脑.

实践背后的原则

上面的一组极限会议实践, 背后其实基于两条原则: 以终为始, 保持张力.

  • 以终为始: 在最早的时刻就把候选结论抛出来, 后续的讨论只是对初始结论的修正. 任何跑题的讨论都通过命题调教或举例说明拉回来.
  • 保持张力: 方式很多, 暴露异议来PK, 减少必要信息供给来促进思考, 制定不利的初始结论来提升紧迫感.

组合运用这些手段可以得出更多的规则.

答疑

这么着急得出结论, 会不会有些话题没有足够的时间充分讨论而错过更多可能性?

丧失部分可能性是可能的, 但讨论是否充分, 跟时间长短没有必然联系, 更能影响讨论充分性的, 是看目的是否明确, 是否有备而来, 是否有足够张力让你调动大量脑细胞. 给你充足的时间反而放松了. 放松的环境, 随意的交谈或许有助于激发灵感, 但那不需要组织会议也可以创造这种条件.

另外不是每个规则都奔着”时间短”去的, 比如”留白”. 真正的关注点还是效率: 单位时间内更充分的沟通和理解.

有些建议是冲突的, 比如”一分钟结束会议”和”留白”

实践不只包含具体操作, 还包括场景及意图. “一分钟结束会议”和”留白”的场景及意图不同.

Share

在ThoughtWorks我们如何做内部培训?

banner

ThoughtWorks内部培训

对新人的培训是每个企业都绕不开的一个话题,企业当然想要每个新人都能直接独当一面,最好可以直接上项目贡献自己的价值。但是从经验来看,所有新人到一个新环境都需要学习很多不同的新东西(新技术,框架,语言,工作方式等等),而每个企业对于培训新人都有各种各样的策略,比如老人带新人,比如扔到项目上让新人自己学。

在ThoughtWorks,我们有着丰富的培训方式,有面向社招的,有面向毕业生的,有民间自发的,有官方组织的,有内部的,也有面向社区的。

TWU

TWU全称ThoughtWorks University,面向毕业生,入职之后的第一堂课。TWU的地点设在印度,之前在班加罗尔,后来改到了普内。每一期5周,学生们需要和和全球其他国家地区的同学一起,一般会尽量将各个地区的学生打乱安排,尽量让学生体会多元化的文化,培训内容设计公司文化,软件开发方法论,敏捷开发(Project SImulation)实践等,同时还需要保证学生有足够的代码练习机会。

我在2013年作为讲师参加了一起TWU,对我自己的帮助也非常大,在和来自不同地区的讲师一起备课,学习中学习到了很多的东西,之前似是而非的一些概念也得到了纠正。

twu

TWI

TWI全称ThoughtWorks Immersion,面向有经验的社招同事,主要涉及的内容为公司文化(合作,沟通),专业服务(如何专业的解决客户的问题),软件开发流程,敏捷开发方法论等。

我在2012年时参加过TWI,并整理了几篇相关文章,可以参考这里这里还有这里

twi

Session

Office局限在ThoughtWorks办公室之内,内容随意,参加不参加随意,可以随时加入或随时离开。虽然内容没有限制,但是大多数时候分享的都是技术主题。比如自动化部署自动测试Spring 4Ruby中的构建工具等等。

Sessoin的形式是主讲者找一个自己感兴趣的主题,一个人讲,其他参与者听,鼓励互动。时间一般控制在一个小时以内,所以一般选择在中午饭的时候,有的session会给大家订饭,一边吃一边听。

虽然大部分Sessoin的主题是技术相关的,但是并不局限于此。比如旅游见闻,历史,财务,摄影等等,都可以分享,有时候这些趣味性的Session的参与者更多。

session

WorkShop

Office之内,内容随意,以动手为主,讲解为辅。

  • HTML/CSS
  • Testable JavaScript
  • 设计工作坊
  • OO BootCamp
  • Ruby BootCamp

一般来说,Workshop都会组成一个系列,通常会占用几天到几周不等。参与者需要带上电脑,在课堂上进行练习之外,课后还会有一些练习。

3周3页面可测试的JavaScript是我去年做的两个Workshop。由于Workshop会在下班后或者中午的休息时间,公司会为每个参与者订饭,以节省时间。

郑大晔校

面向刚刚得到offer的毕业生,在上项目之前,我们希望学生的基本技术达到特定的水平,因此设置了一系列的练习。包括

  • 编程基础
  • 开发流程
  • 工作方式
  • 公司文化

等等。郑大晔校的周期为每周一次,一次一天。涉及的内容会与大多数项目上的要求一致,比如西安office的Java/Ruby项目居多,我们的课程安排就会涉及到Java/Ruby方面。当然,各种软技能如工作方式也会在课程中涉及,尽量的寓教于乐。

每期郑大晔校大概会有10周,学生入职之后有的会直接去TWU,有的则会在项目上工作一段时间再去TWU。

组内培训

各个组内自行组织,并不要求其他同事参加。比如某个项目需要一些docker的知识,或者需要AngularJS相关的培训,一方面是找自己组内的专家组织一次内部培训,,另一种是找办公室内相关的专家来进行培训,形式比较灵活。

  • 项目中已经在使用的技术
  • 项目中将要使用的技术
  • 请别的组的专家来咨询

group learn

社区

  • OpenParty
  • Rails Girl

rails girl

问题

  • 谁当讲师
  • 活动经费
  • 内容如何持久化(人,内部知识分享系统)
  • 如何保证效果(宽松)

由于对任何的话题都没有限制,也没有对参与者的限制,因此任何人只要感兴趣都可以作为讲师。而又由于没有任何的强制措施,参与者和主讲者都凭着自己的热情来组织,这也算是比较独树一帜的事情。

而关于内容的持久化,更多的是为参与者打开一扇新的窗户,或者说洒下一些火星,而至于火星如何形成燎原之势,则完全在参与者自己的自觉。好多次和客户分享了我们的培训机制之后,被问到最多的问题是如何强迫参与者产生热情?

这个问题在ThoughtWorks不是问题,我们在一个人进入公司的最开始,也就是面试的时候,就考察了他的热情,如果在热情上有缺陷,则很可能会直接拒掉,免得破坏我们好不容易构建起来的学习氛围。

Share

创业提案的逻辑

最近花了大量时间在自己新的内部创业项目,免不了给各种不同的人(内部或外部)进行商业提案(Business Proposal)的工作,同时也在帮助湾区一些社会企业包装面向投资人的Pitch,结合以往大量商业合作项目的经验,我重新思考了商业提案的逻辑,相信无论提案的规模、内部或者外部、创业或者商业项目,一个合理的逻辑都是必不可少,希望这个总结能给你帮助。

不确定未来的要素

“投资人”(广义上的,可以是侠义上的投资者、也可以是你的客户和高层管理者)真正投资的是“不确定的未来”,在这份“不确定的未来”里实际上只有两个要素:

  1. 创始人:你和你的团队(即创始人)可能不能适应市场的要求快速和持续的成长;
  2. 市场:客户、客户需求、竞争、技术可能不按照当初设想的方式发展。

事实上,我并没有把产品放在其中,是因为,产品是内部团队对外部市场需求的答案,投资人在首次投资并不要求给出完整而详细的答案,在目前这个阶段它只是让投资人:

  1. 对“不确定未来的”创始人更加有信心:产品的方案部分(Solution)代表了创始人团队对市场需求的回应;
  2. 对“不确定未来的”市场更加有信心:产品的需求(Need)部分市场需求进行了具体化和细分。

对于投资人而言,Pitch结束后更好的结果应该是:

  1. 我对你们有信心;
  2. 我对你们所针对的市场有信心;
  3. 对于你们的产品形态,相信一个好的市场和优秀的你们会慢慢寻找到一个稳定成长的方向。

因此,过分强调现有产品可能喧宾夺主(创始人和市场)、完全忽视产品的描述也有可能减分。

完美逻辑

任何一次创业都是将市场、创始人、投资人三者之间关联,它体现着四种核心关系:

  1. 创始人用产品回应市场机会;
  2. 投资人要求创始人设计商业模式;
  3. 市场给予投资人回报;
  4. 为使得创始人能够运行产品、产生商业模式、最终从市场中获得回报,投资人需要投资。

因此对这四种关系的解答就是一个Pitch的精要,它分作以下7个步骤:

  1. 市场:你面对怎样一个市场?趋势、用户、习惯、需求、竞争、技术等;
  2. 产品:你的产品形态如何?目标用户、场景、功能、定位、竞品、模式、技术等;
  3. 创始人:为什么你和你的团队可以规划、创造、运营这个产品?经验、能力、资源、性格等;
  4. 商业模式:凭什么说这个产品可以带来商业价值?公司结构和治理、收入结构、支出结构、财务预测等;
  5. 投资人:为什么我要投你?投资组合、优势、战略、互补等;
  6. 投资:你需要投资多少?投资形式、合作方式、Burn Rate等;
  7. 回报:我可预期的回报是什么?回报形式、时间、风险等。

事实上,一个短时间的Pitch不可能完全完美回答以上所有这些内容,但是一个好的逻辑顺序引领投资人朝你所期待的方向前进,并帮助你或和你共同回答商业模式、投资、和回报三个问题。

一个好的逻辑顺序

一个好的Pitch永远是故事,你的听众是投资人,你的目标是将投资人拉入到你和市场的这个环中:

在这里,“商业模式”、“投资”、和“回报”不是你最擅长的,却是投资人最关系的三个问题:

  1. 怎么赚钱?
  2. 投多少?
  3. 挣多少?

一个好的逻辑顺序让你避开你最不擅长的领域,而把最吸引人的部分放在了前面所提到的“不确定未来的两个要素”:你(即创始人)和市场。这里我使用最多的逻辑是为以下:

  1. 趋势:市场发生了什么样的趋势?
  2. 人:趋势中人们发生了什么变化?产生了什么需求?
  3. 问题:需求和方案之间存在什么问题?
  4. 方案:我们如何解决这个问题?
  5. 独特处:我们方案的独特处是什么?
  6. 我们:我们是谁?
  7. 目标:我们要做什么?
  8. 状态:我们在做什么?
  9. 资源:我们需要什么资源?
  10. 计划:我们将如何使用资源?

通常一次Pitch的时间可能不超过30分钟,为了保证最后还有10分钟的交流时间,建议每点只用一张幻灯片讲2分钟,幻灯片尽可能视觉化和情景化,例如抽象层次的产品使用场景,而不用出现交互图。

再比如高度抽象化、结合图标设计的目标定义:

此外,根据使用场景的不同,例如投资人2分钟的快速沟通,我们还可以将其简略成五个逻辑,即:

  1. 解决什么问题?
  2. 怎么解决?
  3. 有何不同?
  4. 在做了什么?
  5. 还需要什么?

以一个社交性共享餐饮服务的模式做例子,一个两分钟的快速Pitch逻辑可以是:

用搭伙做饭的方式解决都市人中喜欢下厨的人的社交需求,它采用线上到线下的方式撮合和招揽食客,核心特点是基于一个200人的核心厨师群进行拓展,目前核心厨师群正在完成第50次主题家庭餐会,积累超过2000位食客群,需要场地和资金建设线下的旗舰厨房作为概念店。

如果我们只有30秒,我们该如何表达这个逻辑呢?

我们帮爱做饭的人寻找厨友和食客,有200个核心厨师加盟、2000食客、50次餐会,现在找地方找钱建线下概念店。

你看,越简单的逻辑越不出现解决方案,只告诉你我们在帮助谁?帮助什么?我们做了什么?我们要什么?这是不是比那种“我有一个想法”式的表述更加打动人?

最后,作为创始人,Pitch也许是每天在不同场合发生的事情,手上应该有适合2小时、30分钟、2分钟、30秒不同时长进行的口头表达,同时也有从30页PPT、5页PPT、移动端网站、名片等不同介质的平面表达。一个顺畅的逻辑表达(无论是口头还是平面)也让你更加清晰你和你的创始人团队、以及你所面对的市场,它也可以用来帮助招募早期和合伙人。

写在最后

打动投资人的是你展现的一个“有利可图”的不确定未来,里面是一个“有利可图”的团队,加一个“有利可图”的市场,同时在创业初期,我们不可能把市场、创始人团队、以及投资人所相互关联的逻辑关系彻底厘清,我们需要的是一个能够反复练习的逻辑,熟记在心,并在任何时候表达出来,随时接受挑战、并反复打磨。

我做业务分析师的时候,有这么一句话,“讲都讲不明白的需求十有八九是没必要做的”,那么讲都讲不通顺的创业逻辑,意味什么?最后的最后,一千次创业者热血沸腾的说道,也比不过一条从头到尾的逻辑。

Share

实战:持续交付中的业务分析

在需要频繁交付、不断收集用户反馈、拥抱变化、追求业务敏捷的项目中,软件的开发和交付是迭代式进行的。在这样的项目团队中,BA(业务分析师)通常需要在一个开发迭代开始之前完成该迭代开发任务的分析。但在特殊情况下,从收集客户需求到将功能细节传达给开发团队的周期会缩短到一至两天。BA可以用于思考和分析的时间远远少于可以预先做出所有设计的瀑布式项目。

那么在这样的敏捷项目中,BA如何能够适应这种交付模式,完成高质量的业务分析,协同团队为客户交付高价值的软件呢?

项目背景

ABC公司是一家知名的国际性会计师事务所,业务规模庞大,分支机构遍布全球170多个国家。

ThoughtWorks受邀对其“全球派遣服务(International Assignment Service)”业务部门提供IT解决方案,以及软件系统的开发。该系统包括收集其客户的全球派遣雇员的报税数据,以及管理ABC公司税务咨询师对这些数据的进行审核、汇算和出具报告的业务流程;逐步替换其目前已远远不能满足业务和性能需求的遗留系统。

该系统主要有两类用户,一类是ABC公司客户方被派往不同国家工作的雇员(以下简称Mary),这些雇员使用该系统填入报税需要的数据。另一类用户是ABC公司的税务咨询师(以下简称Kim),负责审核、处理Mary提交的数据。

BA在该项目中面临的主要挑战

  • 该项目为分布式开发,ABC公司的决策方在美国,而ThoughtWorks的开发团队在中国,沟通反馈周期有时较长。
  • 由于ABC公司对用户体验的重视,需要频繁交付软件,以便收集用户反馈并及时调整解决方案和后续开发计划。这大大缩短了从收集需求、开始分析到进入开发的周期,增加了分析中出现缺陷的风险。
  • 当开发过程中发现问题时,无法马上与客户取得沟通,开发进度可能会受到影响。

识别业务价值

业务分析的重要性在于首先做正确的事情。理解客户的业务,关注需求背后的价值可以帮助项目团队在软件的设计方面做出正确的选择。

而我们面临的困难是,客户提出的需求,往往都是直接的软件功能,而不是需要解决的业务问题。如果BA只专注于针对客户需要的功能进行系统分析,就丧失了帮助客户优化解决方案以及改进业务流程的机会。

如何寻找业务价值?

以敏捷开发方法中的用户故事为例,找出客户要解决的业务问题的一个简单办法是,用以下方式概括每个用户故事的内容:

As…(角色),I want to…(完成什么样的功能),So that…(解决什么问题,带来什么价值)

“So that…”说明了该故事的业务价值,即要解决的业务问题。准确的寻找业务价值将有利于我们设计出最适合的“I want to”,这很可能优于客户直接提出的功能要求。

需要注意的是,不要把解决方案或功能当成该用户故事的价值。以ABC公司业务系统中的一个用户故事为例,BA对该需求业务价值的了解程度将直接影响到解决方案的优劣。

作为(As…) 我想要(I want to…) 以便(So that…) 是否阐明了价值?
Mary 即时浏览我的行程统计数据 了解我在各个国家或地区停留的时间以及从事的活动
Mary 即时浏览我的行程统计数据 我可以迅速地检查我所输入的在各国家或地区停留时间及从事活动的数据是否正确(以保证我可以依照法律要求提交准确的报税数据)

在该用户故事的两种不同表述中,由于第一种表述只说明了需要的功能,没有说明业务价值,在功能设计时,我们可能会将“行程统计数据”的内容设计的过于详细而造成浪费,使用户不明白此功能的意图。而第二种表述的业务目标就非常明确,可以帮助我们更加容易地设计出适合的解决方案。

此外,BA在了解客户的业务问题时,最好请客户提供一些真实案例/场景来证实其观点并加深自己的理解。

避免分析错误

在实际工作中,我们发现有以下两个方面的分析工作容易被BA忽略,而做出错误的决定。

    1. 客户要求实现某些现有业务流程或遗留系统的功能

例如,客户需求的功能,是当前遗留系统中已经使用多年、且未收到过任何抱怨的功能。所以客户和BA往往认为这个功能是合理的,忽略了深入的分析和思考。而这种思考不全面而做出的决定可能会与可以预见的新功能产生冲突。

在ABC公司的遗留系统中,用来收集报税数据的问卷内容是通过excel表来维护的,而Mary在前台也是通过下载excel问卷,填写完毕后再上传。

在新开发的系统中,问卷被改为在线方式,并辅助以其他必要功能提升Mary的用户体验和满意度。但由于客户方的员工都是财务背景出身,非常喜欢使用excel表,而之前用excel表维护问卷内容也被证明是非常有效的,所以客户坚持在新系统中延用这种方式。经过仔细的分析,我们发现在针对提高Mary用户体验的新功能上线后,使用excel表维护问卷内容将大大增加维护的工作量及错误率,而这与项目的相关目标背道而驰。ThoughtWorks在列举了问题的细节后,说服客户采用了新的解决方案。

    1. 客户要求利用新的IT系统改变当前的业务流程

客户发现目前的业务流程有不合理的地方,希望在新的IT系统里直接改变这些流程。如果不经过仔细的分析,这种做法可能会很危险,业务流程的盲目改变可能会对一部分用户造成麻烦,为客户实施该软件形成强大阻力。那么了解清楚目前这些流程存在的价值和原因事关重要,从而可以帮助我们为客户提供科学的、逐步优化其流程的IT解决方案。

在ABC公司的业务流程中,Kim和Mary之间的一些交流是通过邮件来完成的。这里存在两个业务风险:1)Kim和Mary交流的重要信息被散落在各自的邮件里,系统无法记录,在遇到法律问题时,难以划分责任;2)Kim和Mary可能会使用邮件发送一些保密性较强的内容,如果发错,后果不堪设想。

在开发新系统时,客户要求我们增加了一个消息功能,使Kim和Mary之间的交流可以方便地在系统内部完成。该功能上线后,很好地化解了这两个业务风险,同时收到了Mary这类用户的良好反馈。然而这对该会计师事务所在某些国家分支机构里的Kim这类用户的工作却带来了不小的影响。由于之前使用邮件系统,Kim可以将Mary的邮件转发给相关的同事,并利用邮件丰富的功能进行结果的跟踪。而新上线的消息功能达不到邮件的所有要求,所以增加了他们的工作难度。此外,由于Mary对这个功能的青睐,发送消息的数量远远超过了在使用遗留系统时发送邮件的数量,超过了客户想提高Mary的满意度而在短期内所能承受的代价。

在遇到以上问题时,我们与客户一同分析,提出了折中的解决方案,花费了较少的代价将消息系统和客户的邮件进行集成,同时帮助客户制定了对此项业务流程改进和配套IT解决方案的蓝图。

理清需求优先级

在频繁上线的项目中,其中一个重要的实践是确定需求的优先级,使得重要的功能能够先被开发出来投入使用以便及时收集用户反馈。一般的做法是要求客户排好需求优先级,然后与项目相关成员一同制订迭代开发和上线计划。但由于客户决策方所处角色以及思维角度的局限性,对优先级的评定可能存在盲目。建议BA参照以下价值维度帮助客户对优先级进行评定。

从客户价值维度分析需求优先级

需求价值维度分析图

价值维度 说明
愿景目标 该功能点是否契合项目的愿景和业务目标?与项目目标的契合程度越高者优先级越高
时间限制 客户的业务是否有一定的时间表?如果该功能点必须在某时间点前投入使用,则该需求必须被排入相应时间的发布计划中
市场卖点 该功能点是否是吸引特定目标用户的卖点?如果客户的资金存在问题或者需要市场的快速认可,则可以考虑将该需求列为高优先级
有无替代方案 该功能点有无方便的替代方案?如果有简单易行的替代方案,则该需求的优先级较低
客户内部政治因素 该功能点是否存在客户内部的政治因素?例如某功能只对小部分用户提供价值,但会决定客户内部某个重要组织对这个项目的投资和评价,则可以考虑将该需求列为高优先级
投资收益 该功能点的开发成本和客户所能获得的收益是否匹配?例如客户某工作流程浪费了一个小组人员大量时间,但对其他部门或工作环节无影响。如果开发相应的软件功能造成的投入大于客户在一定时期内可以节省的资金,则该需求的优先级较低
技术依赖性 其他需求是否依赖于该功能点?如果依赖于这个功能点的需求优先级高,那么该功能的优先级应更高

技术风险对优先级的影响

除了来自客户方面的决定因素,我们还应考虑技术实现方面的影响。如果一些技术风险较高的功能可以先进入开发阶段,则问题会尽早地被暴露。开发人员在项目早期解决这些问题会有利于开发成本的节约。所以除以上客户价值维度外,应再参考以下矩阵来权衡需求的优先级。

需求优先级矩阵

客户价值维度和需求优先级矩阵并不是优先级高低的计算器,而是与客户以及团队沟通交流的工具。不同项目的影响维度也会有所不同。由于各项因素的复杂性,客户价值维度和技术风险因素需综合考虑,不可以权重来计算。BA可以与客户对以上因素的内容达成一致,使得客户在评定需求优先级时可以快速、准确地做出判断。同时,通过对价值维度的分析,我们将有机会清晰地了解到功能优先级高或低的原因,以便我们能够准确地编制项目开发和上线计划,并合理地划分用户故事范围。

借助价值维度分析,管理客户期望值

有些客户的决策人可能会依据自己的喜好划分优先级,这对于项目能够按目标成功交付造成一定的风险。此外,客户在功能的设计和验收阶段也容易对单个功能追求完美,造成额外工作量,增加项目范围。而这部分额外工作可能并不合理或者价值较低。长期如此,团队在开发过程中将逐渐偏离项目目标。如果能借助优先级维度对这些额外需求进行分析,则可以提供更有说服力的依据,帮助客户做出正确决定,达成BA和项目经理对客户期望值的有效管理,从而降低交付风险。

发挥团队其他成员在业务分析中的作用

在频繁交付的项目中,如果BA独自承担业务分析工作,难免会出现疏漏。ThoughtWorks曾与ABC公司的IT部门合作完成其业务系统的一些集成工作。在合作过程中发现,ABC公司IT部门的开发人员在业务分析中参与度很低,由此造成了如下问题:

  1. BA需要写大量需求文档,故从需求分析到软件交付的周期较长
  2. 设计缺陷的发现滞后
  3. 在需要频繁交付的情况下,解决方案质量较差,方案优化能力较弱

而ThoughtWorks的开发人员由于在业务分析中的参与度较高,则有效地避免了以上问题。

开发人员如何参与分析

开发人员是软件功能的实现人员,对方案的实现工作量有较准确的估计。在明确项目目标或业务问题后,BA如果能够和开发人员一同分析解决方案,将更有效地为客户找到兼顾成本和效果的方案。

在收集到客户需求后,BA可根据业务价值对需求进行分析,判断客户提出的功能或解决方案是否能很好地满足该业务价值或要解决的业务问题;或者按照自己的理解设计出满足该业务价值的功能或解决方案。

完成上述工作之后,BA应与开发人员就需求和业务价值进行充分沟通,验证功能实现的可行性,同时积极探寻更优方法。如果开发人员提出符合业务价值的不同方案,BA则可以要求开发人员提供一些关于开发工作量、方案优劣、技术风险方面的比较数据,从而帮助自己有效地与客户沟通并挑选最佳方案。甚至可以根据分析结果帮助客户调整该需求的优先级。对于技术难度和风险较高的功能点,建议邀请资深开发人员参与讨论。

与开发人员沟通中遇到的挑战与解决方法

由于上述方法需要与开发人员大量沟通,有些BA在应用以上实践时也遇到了以下挑战。

    1. 开发人员缺少参与业务分析的热情

在ThoughtWorks,大多数开发人员都喜欢积极思考、主动为业务分析提供帮助,大大减少了需求分析上的漏洞。然而在ABC公司的IT部门中,开发人员很少主动为业务分析出谋划策,尤其是团队中资历较浅的成员,甚至不愿意参与解决方案的讨论。团队成员的优势没有得到充分发挥,开发人员只管按需求埋头苦干,结果功能和解决方案的问题往往在测试或者验收阶段才暴露出来,不可避免地造成了浪费。

站在开发人员成长的角度,从ThoughtWorks实践来看,积极地理解业务、思考解决方案能够更快地提高技术能力。故此BA可以找出一些实际案例,协同项目经理与团队各成员进行沟通,鼓励大家积极参与业务分析,逐步形成开发人员与BA协作的良好氛围。

    1. 开发人员容易就客户需求或解决方案产生争论

开发人员在积极参于分析的过程中,有时会对软件功能的价值吹毛求疵,在细节上与BA产生较多争论,使BA在应付开发人员的问题以及与客户求证答案之间疲于奔命。

解决此类问题,可采取以下方法:

  • BA在收集需求时,尽可能充分地了解客户要解决的业务问题,以便能够快速回答开发人员的问题
  • 面对开发人员对解决方案的质疑时,应保持良好的心态,清楚地了解开发人员顾虑的问题和原因
  • 如果自己掌握的信息确实不能证明现行方案的合理性时,协同开发人员,找到更优方案并与现行方案进行优缺点比较
  • 将新旧方案与客户沟通,则可快速帮助客户做出判断

不要忽略测试人员在业务分析中的贡献

由于测试人员所处角度和对细节的关注,往往可以发现一些功能细节的设计漏洞。所以在用户故事进入开发前,BA与质量保证人员对相关业务价值进行充分沟通,会在功能进入开发之前为BA创造更正设计缺陷的机会。

做为质量保证人员,如果充分了解功能背后的业务价值,相对于只了解功能需求,将可以写出更加完善的测试用例,提高测试覆盖率。这会为交付高质量的软件把好最后一道关。

结语

业务分析是困难的,特别是我们面对未知领域的时候。如果只是简单地按照客户的具体需求进行软件开发,那么我们交付给客户的价值将非常有限。然而识别业务价值、帮助客户分析需求优先级、保障团队协作,将有效提升团队对软件的设计能力,解决客户真正的业务问题,交付更大价值。

作为一名业务分析人员,当您在尝试以上实践时,可能会发现自己对客户业务的理解变得更加深刻。在与客户的沟通中,也能够更加容易地提出有价值的问题以及建议,从而提升客户对项目团队的信任,为成功交付项目打下良好基础。

*注:“客户价值维度”的概念由ThoughtWorks咨询师李光磊提出。在此对李光磊表示感谢。


Share