作者:xlzd
链接:http://www.zhihu.com/question/26930016/answer/81263287
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。简单来讲,可以不严谨地把Python的装饰器看做一个包装函数的函数。

比如,有一个函数:

def func():
    print 'func() run.'

if '__main__' == __name__:
    func()

运行后将输出:

func() run.

现在需要在函数运行前后打印一条日志, 但是又不希望或者没有权限修改函数内部的结构, 就可以用到装饰器(decorator):

def log(function):
    def wrapper(*args, **kwargs):
        print 'before function [%s()] run.' % function.__name__
        rst = function(*args, **kwargs)
        print 'after function [%s()] run.' % function.__name__
        return rst
    return wrapper 

@log
def func():
    print 'func() run.'

if '__main__' == __name__:
    func()

对于原来的函数”func()”并没有做修改,而是给其使用了装饰器log,运行后的输出为:

before function [func()] run.
func() run.
after function [func()] run.

把”@log”放到func()函数定义的地方,相当于执行了如下语句:

func = log(func)

因为log()返回了一个函数, 所以原本的func指向了log()返回的函数wrapper。wrapper的参数列表为(*args, **kwargs), 所以其可以接受所有的参数调用, 在wrapper中,先打印了一行

‘before function [%s()] run.’ % function.__name__

(在Python中函数也是对象,函数的__name__是它的名字),然后执行了原来的函数并记录了返回值,在输出

‘after function [%s()] run.’ % function.__name__

后返回了函数的执行结果。

如果decorator本身需要传入参数,那就需要编写一个返回decorator的decorator。比如在Flask中:

@app.route('/')
def index():
    return 'hello, world!'

实现如下:

import functools

def log(text=''):
    def decorator(function):
        @functools.wraps(function)
        def wrapper(*args, **kwargs):
            print 'before function [%s()] run, text: [%s].' % (function.__name__, text)
            rst = function(*args, **kwargs)
            print 'after function [%s()] run, text: [%s].' % (function.__name__, text)
            return rst 
        return wrapper
    return decorator

@log('log text')
def func():
    print 'func() run.'

if '__main__' == __name__:
    func()

输出如下:

before function [func()] run, text: [log text].
func() run.
after function [func()] run, text: [log text].

最后脑洞小开一下, 有没有办法实现既支持不带参数(如log), 又支持带参数(如log(‘text’))的decorator吗?

import functools

def log(argument):
    if not callable(argument):
        def decorator(function):
            @functools.wraps(function)
            def wrapper(*args, **kwargs):
                print 'before function [%s()] run, text: [%s].' % (function.__name__, text)
                rst = function(*args, **kwargs)
                print 'after function [%s()] run, text: [%s].' % (function.__name__, text)
                return rst 
            return wrapper
        return decorator
    def wrapper(*args, **kwargs):
        print 'before function [%s()] run.' % function.__name__
        rst = function(*args, **kwargs)
        print 'after function [%s()] run.' % function.__name__
        return rst
    return wrapper

如上~~~

转自:http://www.jianshu.com/p/3a515cc30df3

有人曾从我工作的一家公司盗取了9千万美元。我不太懂得如何观人识人。这家公司最终关门了。

有一些事情我就是学不会。我很容易相信一个人。

因此,无论我如何尝试,判断一个人对我来说,简直太难了。所以,我寻找擅长做这件事的人,我让他们给我提供帮助。

Learn

Learn

不要强迫自己学习那些你不想或者不属于你天赋所及的事情。

天赋的作用到底有多大?非常小。但你需要从它开始起步。天赋是技能的种子。

你如何得知你在某个方面具有天赋?当你10岁时,如果你热爱它,如果你梦到过它,如果你喜欢阅读这方面的内容。请继续阅读以下内容,你会发现你的天赋到底在哪里。

当我说:每一个人在许多方面都具有天赋。请相信我。

在过去的20多年里,我一直在试着学习一些东西,而且我希望把它们学好。写作、编程、商业技巧(领导力,销售,协商和决策制定等等),戏剧,游戏。

所以,我专门研究出了一项由10个步骤组成的学习方法。

热爱你学习的东西

如果你不能从“热爱”出发,那么那些热爱它们的人将会战胜那些仅仅“喜欢”或者“讨厌”它们的人。

这是一条放之四海而皆准的规则。第一个从西伯利亚出发直至阿拉斯加穿越北极的人,即使零下60多度,他依旧热爱他所做的事情。其他人可能宁愿呆在东非的大草原上。

在我第一次写下“Hello World”计算机程序时,我就梦到了计算机。我凌晨4点起床,返回“计算机实验室”,写出了一个更复杂点儿的程序。

当我第一天开始写作时,我写了一整天。我无法停下来。而且,在那时,我只想和形形色色的写作者们谈话和交流。

当我只有10岁时,我写了一个有关我五年级同学的专栏。我每天都阅读 Judy Blume 的书。我几乎什么都读,我太喜欢写作了。

我的绝大多数朋友都觉得我很无趣,所以,我很快陷入了一种孤独境地。当然,写作的时候例外。

阅读与之相关内容

Bobby Fischer 原本不擅长国际象棋。他有这方面的天赋,但很多人不这么认为。

因此,在他大约12-13岁时,他消失了一年时间。

当他在13岁时,他再次出现,而且突然之间,他成了美国最好的国际象棋手,赢得了美国象棋冠军赛。他成为当时世界上最年轻的国际象棋大师。

他如何做到的呢?其实,在这一整年里,他几乎没有真正地下过一盘象棋。

相反,他只做了两件事:

a) 他把上个世纪所有的象棋赛棋局研究了一遍。

当他返回时,他对所有的开局模式都非常熟悉,而且他把这些开局模式做了必要的改进。没人知道怎样才能战胜这些改进模式。

事实上,在1972年举办的世界冠军赛的决赛中,他和 Spassky 对垒,Fischer 就是凭借其 1800 年代的武器装备,最终赢得了世界冠军。

Spassky 必须赢得比赛以保持其冠军称号。Fischer 必须获胜比赛才能摘得冠军头衔。

Spassky 采用了一个非常现代的极具进攻态势的开局(“The Sicilian”),但是在随后的13步之后,所有的评论员开始窃窃私语。

Fischer 故意将开局做成了一种老式风格的“The Scotch Game”模式。自此,Spassky 始终没能再有胜出的机会。

b) Fischer 通过阅读俄罗斯象棋杂志学习和了解了有关俄罗斯棋手的信息。那个时候,世界象棋排名前20都是俄罗斯人。美国人根本没有机会。

正当所有美国棋手研究各种俄罗斯人已经熟知的各类开局风格时,Fischer 却在研究俄罗斯人的具体棋法。

结果是,当 Fischer 赢得全美冠军时,他成为了第一位全胜棋手,甚至没有一盘和局。

研究历史,研究既往最佳棋手,是成为最佳棋手的关键。即使开始时你只是有点儿天赋而已。

尝试。但不要太艰难

如果你想成为一名作家,一位商界精英,或者一名程序员,你必须写很多东西,创办很多企业,编写很多程序。

失败或错误时有发生。这就是为什么在开始的时候,数量比质量更重要。

我们的学习曲线不是构建在你业已取得的成就之上,而是构筑在数量之上。

如果你看到一个东西1000次,你将会比那些只看10次的人更有见识。

不要忘记这条重要规则:快乐的秘密不在于“成就卓越”,而在于“不断成长”。

如果你仅仅“尝试”你能力范围内的事情,成长将会停止,对此,你不会感到快乐和幸福。

找到一位老师(外加一个10倍速规则)

如果我尝试自学西班牙语,我会迷失方向。但当我走出门,结识一些阿根廷人,我会学到更多。

在国际象棋,写作,编程,商业等方面,我总能找到比我更加出色的人,为此,我会每周安排一定时间向他们请教一些问题,让他们给我布置一些作业,帮助我发现错误并且告知我错误的具体细节。

对于任何你热爱的事情,找到一位老师,就能帮助你以10倍速的效率前进。

事实上,我放在这个列表中的每一件事情,都可以让你的学习以10倍的速度前进。因此,如果你在学习中应用了这份列表中每一项方法的话,你的学习效率将是其他人的10的10次方。

这就是让你在某个方面取得杰出成就的基本路径。

学习历史,学习现在

如果你想要成为一名优秀的程序员,不要仅仅满足于编写一个应用程序,你应该学习机器语言。

学习1和0,学习计算机的历史,学习如何设计一个操作系统,学习各种编程语言,Fortran,Cobol,Pascal,Lisp, C, C++ 直至现代语言,比如,Python 等。

如果你想要提高自己的写作技能,去读自1800年起的优秀的文章。阅读海明威和弗吉尼亚·伍尔夫,甚至“垮掉一代”(Beat Generation)的文学著作,阅读那些经得起时间考验的作品。

它们都历经了时间的考验。经过与其他几百万本书的比较,它们就是这个世界上最好的文学作品。

然后,你需要研习当代对这些书籍的评论和批评。这样做的重要性就如同阅读它们一样重要。

如果你希望学习商业,阅读洛克·菲勒和卡内基的传记,了解阿姆斯特丹成立的第一家交易所,90年代的垃圾债券泡沫,金融危机,每一次经济衰退。每一次经济衰退都是再一次经济繁荣的发源地。

阅读彼得·蒂尔撰写的“从零到一”这本书。在 CNBC 电视网上观看“The Profit”专栏节目。阅读苹果公司创始人史蒂夫·乔布斯的传记。阅读《权力的终结》了解柯达如何衰落。

不要阅读那些自助型商业书籍。它们没有什么价值。你己经进入一个广阔的领域 – 创新领域 – 现代社会创建的一个领域。不要读去年刚刚出版的平庸作品。

再进一步,你可以阅读一些有关通过创新如何将世界变成今天这个形态的著作。

阅读亨利·福特如何从创办三家汽车公司起家,最终怎样找到正确发展之路,而且你还需要知道为什么“三”对于亨利·福特而言,是一个重要的数字。

阅读了解为什么雷·克拉克的技巧成就了世界上最大的特许加盟连锁餐饮企业 – 麦当劳。阅读可口可乐如何通过不生产任何东西,却造就了世界上最大的饮料公司。

把你从这些阅读中收获的东西记录下来。

先易后难

Tony Robbins 曾经向我提及他的第一次教学工作经历,当时,他对这份工作甚至有点害怕。

他必须教会一组海军陆战队员提高他们的射击准确度。“我这一辈子都没打过枪,” 他说。

他之前在一些专业人士那里学了一些东西,然而不久之后,他就发现了一个技巧,结果使得受训陆战队员的射击成绩达到了前所未有的水平。

他只是把射击目标拉近了。

他将靶子放在距离仅有5英尺的地方。他们全都命中了靶心。然后,他再将其后移一点,直至标准距离。

他们全都击中靶心。

理查德·布兰森在他开办航空公司之前,从创办一本杂志起步。比尔盖茨在整个团队都从事 Windows 开发之前,他自己编写第一个 Basic 语言和编译器。

斯蒂芬妮·迈耶(是的,我包括了她)撰写了《暮光之城》,在此之前,她写过一本名叫《五十级灰度》的书。

在早期,海明威从没有梦想成为一位小说家。因此,他只是写了一些小故事。

程序员在着手设计第一个搜索引擎之前,编写“Hello World”程序。

许多国际象棋大师在你开始学习象棋时,会推荐你先学习象棋残局(只有几枚棋子)。

这样做会给予你信心,会给予你微妙的提示,会给予你有关成长和提高的强烈的感受。

回顾你学过的东西

有一天,我把我几乎所有的东西都扔了。所有的东西。我扔了我所有的书(捐献了)。我扔了我所有的衣服。

我扔了那些旧电脑。我扔掉了我从来不用的盘子。我扔掉了我认为我不会有机会穿着的衬衣。我扔了我所有的家具,纸张及其它东西。

我想来个大扫除。我就这么做了。

我发现了一本我写于1991年的小说。24年之前。真是可怕呀。

24年来,我第一次重读了这本小说。我知道了当时出错的地方(人物不相关。故事刻画太明显。故事的高潮都发生在同一个地点)。

有人告诉我一个关于 Amy Schumer(我最喜爱的喜剧演员之一) 的故事。她把自己所有的表演都录了下来。

然后她返回家中,仔细研究她自己的表演,一秒接一秒。“我当时应该在这个动作上停留四分之一秒。”

她希望成为一名最好的喜剧演员。她研究了自己的每一次表演。

我下棋的时候,如果输掉一局,我会把这个棋局保存在计算机中。事后,我会查看我下过的每一步棋和计算机提示。我会思考在我下了步臭棋时,我当时都在想些什么等诸如此类的事情。

我最近投资的一个项目失败了。对我来说,我的感受糟糕极了。但不管怎样,我必须要研究出我到底错在了那里。我在什么地方出的错误。在各个层面上,我都将其进行必要的反思,并且在最后把它们记录下来。

如果你无法沉迷于自己的错误,这可能表明你对这个领域还不够热爱。

你不应该问自己这样的问题“我擅长做什么?” 相反,你应该问自己:“我什么地方做得不对,我应该如何改进?”

在你持续不断地询问自己一个更好的问题过程中,你将会变得比那些只问自己糟糕问题的人更为优秀。

例子:我讨厌看到自己在电视里的表现。所以我无法在表演方面做得更好。

你就是你最要好的5个朋友的平均数

观察一下每一个文化,艺术以及商业场景。很少有人能够作为个体表现突出,他们往往作为一个群体而表现突出。

垮掉一代(文学):杰克·克鲁亚克,艾伦·金斯堡,威廉·博罗斯以及其他一些人。

技术与编程:史蒂夫·乔布斯,比尔·盖茨,泰德莱·昂西斯,保罗·艾伦,斯蒂夫·沃兹尼亚克等其它佳酿俱乐部成员。

50年代艺坛:贾斯珀·约翰斯,德·库宁,Pollack 等所有当时身处纽约芝麻街的那些人。

YouTube,LinkedIn,Tesla,Palantir 等所有这些被称为“PayPal 帮”的成员。

所有这些人都不是独自存在的。人类是一种以部落为单位的群居动物。我们需要和群体一起工作才能获得更大的提高。

找到这些最好的群体,尽量花费大量的时间和他们在一起,你就会变得和他们一样优秀。

你们每一个人彼此相互挑战,相互竞争,喜爱和欣赏彼此的工作成果,甚至彼此羡慕,最终,你们都将相互超越。

多多益善

坚持不懈与偶尔为之相比,坚持不懈更为重要。

我过去有一位朋友,一直想在绘画上有所提高。但是,她认为她应该去巴黎,因为那里的气氛更适合。

她的巴黎之旅一直没能成行。她目前坐在一个小隔间里,伴着荧光灯填写着各类报表,还有就是一些无聊的文书工作。

写作每一天,社交每一天,娱乐每一天,健康生活每一天。

请按照你所做事情的数量来衡量你的生活。

找到你自己的魔鬼计划

学生最终实现超越成为一名大师。

我曾为之工作的第一位对冲基金经理现在非常恨我。我开创自己的基金时,他的基金正要被淘汰出局。我的魔鬼计划最终来看比他的更有效。

然而,

自此之后,我会发现自己的声音。而且,当你用这种声音说话,世界就会呈现出一种新气象。

你的老师和朋友们可能并不希望听到这种声音。但是,如果你能够继续让喜欢和尊重你的人围绕在你周围,那么,他们会继续鼓励你发出那样的声音。

有句话是这样说的,“there are no new ideas.” But there are。

如果你能融合已有的思想或想法,你就是那只美丽的蝴蝶。

– 原文:The Only Technique To Learn Something New

– 感谢:Qingniu 帮助审阅和完成校对。

 

文/Jodoo(简书作者)
原文链接:http://www.jianshu.com/p/3a515cc30df3
著作权归作者所有,转载请联系作者获得授权,并标注“简书作者”。

转自:http://hellojava.info/?p=458

在上篇《架构师画像》的文章中提到了自己在系统设计上犯过的一些错,觉得还挺有意义的,这篇文章就来回顾下自己近八年来所做的一些系统设计,看看犯的一些比较大的血淋淋的错误(很多都是推倒重来),这八年来主要做了三个基础技术产品,三个横跨三年的大的技术项目(其中有两个还在进行中),发现大的错误基本集中在前面几年,从这个点看起来能比较自豪的说在最近的几年在系统设计的掌控上确实比以前成熟了很多。

第1个错
在设计服务框架时,我期望服务框架对使用者完全不侵入,于是做了一个在外部放一个.xml文件来描述spring里的哪些bean发布为服务的设计,这个版本发布后,第一个小白鼠的用户勉强在用,但觉得用的很别扭,不过还是忍着用下去了,到了发布的时候,发现出现了两个问题,一是这个xml文件研发也不知道放哪好,所以到了发布的时候都不知道去哪拿这个xml文件。
这个设计的关键错误就在于在设计时没考虑过这个设计方式对研发阶段、运维阶段的影响,后来纠正这个错误的方法是去掉了这个xml文件,改为写了一个Spring FactoryBean,用户在spring的bean配置文件中配置下就可以。
因此对于一个架构师来说,设计时在全面性上要充分考虑。

第2个错
服务框架在核心应用上线时,出现了前端web应用负载高,处理线程数不够用的现象,当时处理这个故障的方式是回滚了服务框架的上线,这个故障排查了比较长的时间后,查到的原因是服务框架用的JBoss Remoting在通信时默认时间是60s,导致一些处理速度慢的请求占据了前端web应用的处理线程池。
上面这里故障的原因简单来说是分布式调用中超时时间太长的问题,但更深层次来思考,问题是犯在了设计服务框架时的技术选型,在选择JBoss-Remoting时没有充分的掌握它的运行细节,这个设计的错误导致的是后来决定放弃JBoss-Remoting,改为基于Mina重写了服务框架的通信部分,这里造成了服务框架的可用版本发布推迟了两个多月。
因此对于一个架构师来说,在技术选型上对技术细节是要有很强的掌控力的。

第3个错
在服务框架大概演进到第4个版本时,通信协议上需要做一些改造,突然发现一个问题是以前的通信协议上是没有版本号的,于是悲催的只能在代码上做一个很龌蹉的处理来判断是新版本还是老版本。
这个设计的错误非常明显,这个其实只要在最早设计通信协议时参考下现有的很多的通信协议就可以避免了,因此这个错误纠正也非常简单,就是参考一些经典的协议重新设计了下。
因此对于一个架构师来说,知识面的广是非常重要的,或者是在设计时对未来有一定的考虑也是非常重要的。

说到协议,就顺带说下,当时在设计通信协议和选择序列化/反序列化上没充分考虑到将来多语言的问题,导致了后来在多语言场景非常的被动,这也是由于设计时前瞻性的缺失,所谓的前瞻性不是说一定要一开始就把未来可能会出现的问题就解掉,而是应该留下不需要整个改造就可以解掉的方法,这点对于架构师来说也是非常重要的。

第4个错
在服务框架切换为Mina的版本上线后,发布服务的应用重启时出现一个问题,就是发现重启后集群中的机器负载严重不均,排查发现是由于这个版本采用是服务的调用方会通过硬件负载均衡去建立到服务发布方的连接,而且是单个的长连接,由于是通过硬件负载均衡建连,意味着服务调用方其实看到的都是同一个地址,这也就导致了当服务发布方重启时,服务调用方重连就会集中的连到存活的机器上,连接还是长连,因此就导致了负载的不均衡现象。
这个设计的错误主要在于没有考虑生产环境中走硬件负载均衡后,这种单个长连接方式带来的问题,这个错误呢还真不太好纠正,当时临时用的一个方法是服务调用方的连接每发送了1w个请求后,就把连接自动断开重建,最终的解决方法是去掉了负载均衡设备这个中间点。
因此对于一个架构师来说,设计时的全面性要非常的好,我现在一般更多采用的方式是推演上线后的状况,一般来说在脑海里过一遍会比较容易考虑到这些问题。

第5个错
服务框架在做了一年多以后,某个版本中出现了一个严重bug,然后我们就希望能通知到用了这个版本的应用紧急升级,在这个时候悲催的发现一个问题是我们压根就不知道生产环境中哪些应用和机器部署了这个版本,当时只好用一个临时的扫全网机器的方法来解决。
这个问题后来纠正的方法是在服务发布和调用者在连接我们的一个点时,顺带把用的服务框架的版本号带上,于是就可以很简单的知道全网的服务框架目前在运行的版本号了。
因此对于一个架构师来说,设计时的全面性是非常重要的,推演能起到很大的帮助作用。

第6个错
服务框架这种基础类型的产品,在发布时会碰到个很大的问题,就是需要通知到使用者去发布,导致了整个发布周期会相当的长,当时做了一个决定,投入资源去实现完全动态化的发布,就是不需要重启,等到做的时候才发现这完全就是个超级大坑,最终这件事在投入两个人做了接近半年后,才终于决定放弃,而且最终来看其实升级的问题也没那么大。
这个问题最大的错误在于对细节把握不力,而且决策太慢。
因此对于一个架构师来说,技术细节的掌控非常重要,同时决策力也是非常重要的。

第7个错
服务发布方经常会碰到一个问题,就是一个服务里的某些方法是比较耗资源的,另外的一些可能是不太耗资源,但对业务非常重要的方法,有些场景下会出现由于耗资源的方法被请求的多了些导致不太耗资源的方法受影响,这种场景下如果要去拆成多个服务,会导致开发阶段还是挺痛苦的,因此服务框架这边决定提供一个按方法做七层路由的功能,服务的发布方可以在一个地方编写一个规则文件,这个规则文件允许按照方法将生产环境的机器划分为不同组,这样当服务调用方调用时就可以做到不同方法调用到不同的机器。
这个功能对有些场景来说用的很爽,但随着时间的演进和人员的更换,能维护那个文件的人越来越少了,也成为了问题。
这个功能到现在为止我自己其实觉得也是一直处于争议中,我也不知道到底是好还是不好…
因此对于一个架构师来说,设计时的全面性是非常重要的。

第8个错
服务框架在用的越来越广后,碰到了一个比较突出的问题,服务框架依赖的jar版本和应用依赖的jar版本冲突,服务框架作为一个通用技术产品,基本上没办法为了一个应用改变服务框架自己依赖的jar版本,这个问题到底怎么去解,当时思考了比较久。
可能是由于我以前OSGi这块背景的原因,在设计上我做了一个决定,引入OSGi,将服务框架的一堆jar处于一个独立的classloader,和应用本身的分开,这样就可以避免掉jar冲突的问题,在我做了引入OSGi这个决定后,团队的1个资深的同学就去做了,结果是折腾了近两个月整个匹配OSGi的maven开发环境都没完全搭好,后来我自己决定进去搞这件事,即使是我对OSGi比较熟,也折腾了差不多1个多月才把整个开发的环境,工程的结构,以及之前的代码基本迁移为OSGi结构,这件事当时折腾好上线后,效果看起来是不错的,达到了预期。
但这件事后来随着加入服务框架的新的研发人员越来越多,发现多数的新人都在学习OSGi模式的开发这件事上投入了不少的时间,就是比较难适应,所以后来有其他业务问是不是要引入OSGi的时候,我基本都会建议不要引入,主要的原因是OSGi模式对大家熟悉的开发模式、排查问题的冲击,除非是明确需要classloader隔离、动态化这两个点。
让我重新做一个决策的话,我会去掉对OSGi的引入,自己做一个简单的classloader隔离策略来解决jar版本冲突的问题,保持大家都很熟悉的开发模式。
因此对于一个架构师来说,设计时的全面性是非常重要的。

第9个错
服务框架在用的非常广了后,团队经常会被一个问题困扰和折腾,就是业务经常会碰到调用服务出错或超时的现象,这种情况通常会让服务框架这边的研发来帮助排查,这个现象之所以查起来会比较复杂,是因为服务调用通常是多层的关系,并不是简单的A–>B的问题,很多时候都会出现A–>B–>C–>D或者更多层的调用,超时或者出错都有可能是在其中某个环节,因此排查起来非常麻烦。
在这个问题越来越麻烦后,这个时候才想起在09年左右团队里有同学看过G家的一篇叫dapper的论文,并且做了一个类似的东西,只是当时上线后我们一直想不明白这东西拿来做什么,到了排查问题这个暴露的越来越严重后,终于逐渐想起这东西貌似可以对排查问题会产生很大的帮助。
到了这个阶段才开始做这件事后,碰到的主要不是技术问题,而是怎么把新版本升级上去的问题,这个折腾了挺长时间,然后上线后又发现了一个新的问题是,即使服务框架具备了Trace能力,但服务里又会调外部的例如数据库、缓存等,那些地方如果有问题也会看不到,排查起来还是麻烦,于是这件事要真正展现效果就必须让Trace完全贯穿所有系统,为了做成这件事,N个团队付出了好几年的代价。
因此对于一个架构师来说,设计时的全面性、前瞻性非常重要,例如Trace这个的重要性,如果在最初就考虑到,那么在一开始就可以留好口子埋好伏笔,后面再要做完整就不会太复杂。

第10个错
服务的发布方有些时候会碰到一个现象是,服务还没完全ready,就被调用了;还有第二个现象是服务发布方出现问题时,要保留现场排查问题,但服务又一直在被调用,这种情况下就没有办法很好的完全保留现场来慢慢排查问题了。
这两个现象会出现的原因是服务框架的设计是通过启动后和某个中心建立连接,心跳成功后其他调用方就可以调用到,心跳失败后就不会被调到,这样看起来很自动化,但事实上会导致的另外一个问题是外部控制上下线这件事的能力就很弱。
这个设计的错误主要还是在设计时考虑的不够全面。
因此对于一个架构师来说,设计时的全面性非常重要。

第11个错
在某年我和几个小伙伴决定改变当时用xen的模式,换成用一种轻量级的“虚拟机”方式来做,从而提升单机跑的应用数量的密度,在做这件事时,我们决定自己做一个轻量级的类虚拟机的方案,当时决定的做法是在一个机器上直接跑进程,然后碰到一堆的问题,例如从运维体系上来讲,希望ssh到“机器”、独立的ip、看到自己的系统指标等等,为了解决这些问题,用了N多的黑科技,搞得很悲催,更悲催的是当时觉得这个问题不多,于是用一些机器跑了这个模式,结果最后发现这里面要黑科技解决的问题实在太多了,后来突然有个小伙伴提出我们试用lxc吧,才发现我们之前用黑科技解的很多问题都没了,哎,然后就是决定切换到这个模式,结果就是线上的那堆机器重来。
这个设计的主要错误在于知识面不够广,导致做了个不正确的决定,而且推倒重来。
因此对于一个架构师来说,知识面的广非常重要,在技术选型这点上非常明显。

第12个错
还是上面这个技术产品,这个东西有一个需求是磁盘空间的限额,并且要支持磁盘空间一定程度的超卖,当时的做法是用image的方式来占磁盘空间限额,这个方式跑了一段时间觉得没什么问题,于是就更大程度的铺开了,但铺开跑了一段时间后,出现了一个问题,就是经常出现物理机磁盘空间不足的报警,而且删掉了lxc容器里的文件也还是不行,因为image方式只要占用了就会一直占着这个大小,只会扩大不会缩小。
当时对这个问题极度的头疼,只能是删掉文件后,重建image,但这个会有个要求是物理机上有足够的空间,即使有足够的空间,这个操作也是很折腾人的,因为得先停掉容器,cp文件到新创建的容器,这个如果东西多的话,还是要耗掉一定时间的。
后来觉得这个模式实在是没法玩,于是寻找新的解决方法,来满足磁盘空间限额,允许超卖的这两需求,最后我们也是折腾了比较长一段时间后终于找到了更靠谱的解决方案。
这个设计的主要错误还是在选择技术方案时没考虑清楚,对细节掌握不够,考虑的面不够全,导致了后面为了换掉image这个方案,用了极大的代价,我印象中是一堆的人熬了多次通宵来解决。
因此对于一个架构师来说,知识面的广、对技术细节的掌控和设计的全面性都非常重要。

第13个错
仍然是上面的这个技术产品,在运行的过程中,突然碰到了一个虚拟机中线程数创建太多,导致其他的虚拟机也创建不了线程的现象(不是因为物理资源不够的问题),排查发现是由于尽管lxc支持各个容器里跑相同名字的账号,但相同名字的账号的uid是相同的,而max processes是限制在UID上的,所以当一个虚拟机创建的线程数超过时,就同样影响到了其他相同账号的容器。
这个问题我觉得一定程度也可以算是设计问题,设计的时候确实由于对细节掌握的不够,考虑的不全导致忽略了这个点。
因此对于一个架构师来说,对技术细节的掌控和设计的全面性都非常重要。

第14个错
在三年前做一个非常大的项目时,项目即将到上线时间时,突然发现一个问题是,有一个关键的点遗漏掉了,只好赶紧临时讨论方案决定怎么做,这个的改动动作是非常大的,于是项目的上线时间只能推迟,我记得那个时候紧急周末加班等搞这件事,最后带着比较高的风险上了。
这个问题主要原因是在做整体设计时遗漏掉了这个关键点的考虑,当时倒不是完全忽略了这个点,而是在技术细节上判断错误,导致以为不太要做改动。
因此对于一个架构师来说,对技术细节的掌控是非常重要的,这里要注意的是,其实不代表架构师自己要完全什么都很懂,但架构师应该清楚在某个点上靠谱的人是谁。

钱没了,公司就死了,科技创业公司如何才能不把钱花光?

 

编者按:本文作者 Carol Leaman 是 Axonify公司的 CEO,她之前创办的公司被 Google 收购。

10年 前,我成了一家创业早期软件公司的 CEO。我本来受雇于一家私人股权公司,他们让我掌管他们觉得已经走错方向的业务。这并不完全是一场灾难,但是公司投入了上百万元,他们的一致认为:三位创始人需要一些 “帮助”。

5 天后,我开出了 7 万美元的个人工资单。在我运营过的四家科技公司里,这是最接近死亡的一个,我很长时间内都在思考为什么这些创始人会想有这种想法。更让我吃惊的是他们完全没有意识到自己的想法。

Y Combinator 的创始人 Paul Graham 多年前曾写过一篇博客,指出年轻的企业家在变得富有之前一定不要让公司死掉。

不幸的是,很多创业初期的公司像生活在童话故事里一样,他们不会在创业初期做决策时不会思考 “为了避免死亡我们应该怎么做。” 这不是说他们不应该关注走向成功需要做的事情,而是当涉及到一样东西——现金——时,需要作出理性的决策。

如果你在互联网上搜素 “为什么科技公司会失败?” 你会发现很多文章都将失败的主要原因归结于 “钱花光了。”

“撞到现金墙上了” 常常用来说明为什么科技公司会失败,现实情况是钱花光了是真实原因的结果。作为多年来上百家创业公司早期的导师,我可以说深层的原因是一致的。

以下是确保科技公司早期不会花光钱的 5 个建议:

1、不要把产品建立在空中楼阁之上。

如果非要让我说出一件让公司花光钱的事情,那就是闷头制造产品,但是不考察市场。实际上,CB Insights 曾发布过一份列表,这份列表由 156 名创业公司创始人和投资人撰写的,写明了他们的公司失败的原因。最常见的原因是他们制造的产品没有人愿意买。

很多创始人耗资百万余元,认为自己比任何人都了解产品的用户。很多创始人会告诉我 “当我们发布产品的时候,人们一定会喜欢它。” 但是事实证明:你不是乔布斯,你的产品也不是 iPhone。

2、尽早获取用户。

与第一点相关。用户意味着金钱。金钱意味着发展。发展意味着持续的生存能力。如果你无法说服别人购买你的产品,哪怕是小产品,那么你最好是 Facebook 或 Twitter 之类的公司,这样你才能找到像他们那样的投资人。用户是验证你的方向是否正确的最好方法。实际上,他们会帮你在恰当的时间吸引投资人,让公司获得恰当的估值。

3、不要低估融资的难度。

第一次创业的创业者,非常耀眼,有新鲜感。这些创始人对创业公司融资平均需要花费多长时间以及有多么困难不太了解。大部分天使和机构投资人一个月就会有几百次路演。几百次!你是在与有伟大想法的其他创始人进行竞争,你希望能脱颖而出。这是非常难的。在获得融资之前,你对融资的热情会消失殆尽,开始尝试接受现实,然后会变得疲惫。你给自己设定的期限是在六个月的时间内拿到必要的现金资源。

4、不要扩张太快。

不管你是否成功地融到了钱,还是使用自己的资金在支撑一段时间,扩招员工是最吸金的,而且员工的工资是需要不断支付的。第一批员工工资相对降低,但是如果你想扩张原有的团队,员工会希望拿到和市场待遇相近的薪资。这个固定的花费很快会失控,你的资金很快就会花完。

扩张规模主要在三个因素中寻求平衡:把钱花在哪儿、花钱的速度、预测你到达下一个里程碑需要多长时间。如果你在某一方面花费得过早或者花费得过多,那么你花光钱的几率会增加。

5、不要逃避数字。

很多年前,有人告诉我北美大部分公司的 CEO 都有商务、会计、金融背景,这都是有数据证明的。

我本身是一个 CPA(注册会计师),我立刻意识到有关金融和现金流方面的基础知识是如何为我管理年轻的公司提供坚实的基础支持的。

但是我一直很好奇为什么很多创始人不明白预定量和收益的不同,无法区分应收账款和现金流,甚至不会做最简单的、精确的现金预估。

当你开始创业时,最重要的事情是要了解公司每个周有哪些收入款项,哪些支出款项,以及下个周的现金余额状态。

如果你无法预见半年内的花费,也无法估计什么时候钱会花完,你会走我 10年 前的道路:钱花完了,还有 45 个人的工资没有支付。

本文编译自:venturebeat.com,如若转载,请注明出处:http://36kr.com/p/5044327.html

为何你的产品 Demo 如此糟糕?因为你太注重产品本身了

 

编者按:不管是大公司还是创业公司,我们很多时候都需要去给别人 Demo 产品,给客户 Demo,给投资人 Demo。但很多时候你会发现你的产品 Demo 并不尽如人意。为什么呢?如何才能做一个成功的产品 Demo 呢?本文就是为回答这个问题而来的。

“有人会讨厌你,也有人会质疑你,然后你会想办法证明他们是错误的。” 这是 Robert Falcone 对于产品 Demo 的看法,他自己一生中做过太多的产品 Demo 了。Falcone 现在是营销软件公司 Monetate 的联合创始人,在他的带领下,Monetate 已经和上百家企业进行深入的合作,为了获取这些企业用户,他做过的产品 Demo 也已经数不胜数。最开始的时候,他做的很多产品 Demo 并不成功,不过他很好地从中吸取了经验和教训,并总结了一套行之有效的产品 Demo 宝典。

“我之前以为产品 Demo 是一项很简单的工作,就是告诉人们这个产品是什么、有什么用途。然而每次当我做完产品 Demo 后,客户要么感觉非常困惑,要么非常礼貌地跟我说 ‘谢谢’,然后再也听不到他们的任何消息。” Falcone 说道。

在一次又一次地从客户那里得到这样的反馈后,他决定破解产品 Demo 的成功秘诀。如果产品 Demo 的简单明了能够带来客户转化率,那么如何做到产品 Demo 的简单明了呢?为了能找到这个问题的答案,他不断地去做产品 Demo、做 A/B 测试、去观察、再去重复。他将自己的产品 Demo 经验和心得都写进了《去你的 Demo》(Just F*cking Demo) 这本书中,这本书最近还进入了 Amazon 新书畅销榜单。

在这篇文章中,Falcone 分享了一个成功的产品 Demo 的结构、以及如何仅仅通过一次产品 Demo 就成功搞定客户的技巧与秘诀。

要搞砸一个产品 Demo 其实很简单

为何你的产品 Demo 如此糟糕?因为你太注重产品本身了

对我而言,我绝对算得上是我自己 Demo 的产品方面的专家,我自己也日复一日地向各种大公司 Demo 我们的 Monetate 这款产品,但很多时候还是无法成功地说服客户。很显然,对产品了然于心并不意味着你可以做一个成功的产品 Demo。

此外,看你做产品 Demo 的人很少会就 Demo 给你任何反馈,这样你就不知道该如何提升产品 Demo 的水平。那些看你做产品 Demo 的人中的大多数通常只会出于礼貌性地感谢你能抽时间过来 Demo 产品并就此结束对话。他们不会就如何改善产品给你提任何建议,更不会针对如何更好地向他们做产品 Demo 给你提意见。

“我会问他们:‘你理解我刚刚说的东西了吗?’,他们通常会回答:‘是的,理解了。’ 他们之所以这样回答是因为他们不想让自己看起来很蠢。不过你需要的肯定不仅是对方简单的一句:‘当然,我懂了。’ 你需要的实实在在的交易,是要他们购买你的产品。” Falcone 这样说道。

经过一系列失败的产品 Demo 后,他意识到必须要认真分析到底是哪里出问题了,他必须学会让自己的 Demo 百战百胜。他并没有可以向客户寻求反馈,在他 Demo 的过程中,他会非常注意房间内各种微妙的变化,他开始注意对话的语调,并不断地测试和记录自己的发现。他还会看其他人做 Demo 的视频,以从中寻找实用的建议。

他发现,人们在做产品 Demo 时最容易犯的一个错误、也是最大的一个错误在于不能给特定的展示对象做针对性地产品 Demo,无法引起客户的共鸣。例如,做产品 Demo 时,你不能从产品数十个功能和卖点中选取那几个能让展示对象(如特定的客户或投资者)产生共鸣的功能进行展示,从而促成交易。

成功的 Demo 并不一定非要完美适合产品,但必须要完美适合展示对象。

不管你的 Demo 对象是谁,你都需要好好花时间想想这个问题:在他们愿意达成交易之前,他们特别需要了解哪些东西?为确保能很好地回答这个问题,Falcone 专门针对产品 Demo 提出了 “你-他们-你” 的展示框架。你只需要给潜在客户展示他们需要知道的产品特性就行了,让他们知道你的产品是能帮助他们取得他们想要的结果的,这样你也能获得你要想的结果。一个 Demo 的成功与否取决于你的潜在客户是否能理解你的产品能带给他们的价值。

为了能让产品 Demo 更有吸引人和说服力,Falcone 还专门研究了包括 Malcolm Glandwell 和 Simon Sinek 在内的很多著名商业演讲家的演讲视频,他甚至还研究了魔术师的表演,看他们是如何让听众 / 观众那么全神贯注地看他们说或做的事情的。他发现了一个共同的特点,这些人对听众真正关心的东西都有非常深刻的理解。“如果你知道客户最关心的是什么问题,你就能最大限度地将自己的产品与他们最关心的问题联系在一起,这样有利于取得最好的 Demo 效果。”

做到灵活充分的准备

为何你的产品 Demo 如此糟糕?因为你太注重产品本身了

很多时候,原本那些我认为是我的强项的东西反而正在托我的后腿。如果你是一款产品方面的专家,那么你在做产品 Demo 时就得非常小心了,因为你会不由自主地向客户展示产品的每一项细节功能,而这又是非常乏味的,很有可能让客户听着听着就睡着了,或是客户突然提了一个你之前没有预料到的问题,这势必会让你乱了阵脚。

在做产品 Demo 前,与其想办法记住产品的每一个细节功能,还不如将这些准备时间用在思考你准备向客户问的问题以及他们可能会提的问题上面。如果对于这些问题你心中都已经有了答案,这才可以算作是有效的 Demo 准备。这时,你在 Demo 产品的时候便可以在各个 Demo 部分间顺畅转换,同时也能有效应对各种突发状况。注意,这些问题是专门针对客户准备的,你需要提前制作一个问题列表,确保能通过这些问题获得尽可能多的客户信息。

做产品 Demo 时,你需要的不是一个一层不变的固定方案,你需要的是一本玩法的指南,你需要了解所有玩法,但真正在做产品 Demo 时,你只需演示最符合当时需要的那几种玩法。

根据 Falcone 的经验,在所有的产品 Demo 中,有 10%的产品 Demo 无论如何都是会成功的,或许是因为展示对象之前曾与你一起共事过,或是第一次看你展示就特别欣赏你和你 Demo 的产品。还有 10% 的人不管你如何 Demo,他们都不会买你的帐,因为你给错误的客户群体展示了错误的解决方案。但是剩余的 80%的潜在客户将是你最主要的收入来源,对于这部分人群,你必须要想方设法搞定他们。

根据 Falcone 的经历,在 Demo 前做好充分的准备是可以为你搞定那剩下的 80%的潜在客户的。什么样的 Demo 才算是一个成功的 Demo 呢?就是容许听众在 Demo 中途打断你,既容许听众让你停下来重新解释演示过的内容,也要容许听众让你加快进度,而这些干扰都不会影响到你、让你惊慌错乱。你只需要 Demo 那些听众需要知道的内容即可。Demo 时务必做到顺畅与灵活。如果你在 Demo 之前认真演练过的话,这是能够做到的,会让听众看来非常自然。

用 5 分钟时间发现客户的需求

为何你的产品 Demo 如此糟糕?因为你太注重产品本身了

为了能让客户很明显地感受到你的产品和他们的需求之间是有关联的,你需要尽可能快地了解客户。或许你在 Demo 之前已经对 Demo 对象做了一定的背景调查,然而为了能让 Demo 更有效,你需要做的远不止这些。几十年前,商学院一般都会建议商人们在卖东西之前尽可能多地了解客户,甚至还有一本书建议商人花一整天时间来跟客户交流,以便能全面了解客户的需求。这在现在已经不可能了,没人愿意给你这么长的时间让你了解他的需求。

实际上,没有一个客户会愿意给你超过 1 小时的时间去做产品 Demo。所以在正式 Demo 之前,一定要尽可能地了解你的客户,你需要在 5 分钟之内就能了解他们的需求到底是什么。那么如何做呢?其实最好的方法就是直截了当地和客户说明:“在开始 Demo 前,我想先用 5 分钟时间来问大家一些问题,好让我了解你们最需要哪些功能。” 通过这种方式,Demo 双方就能形成共识,让客户直接参与到问答中。在 5 分钟的提问环节,时间控制非常重要。如果你把握不好时间超时了,客户可能就会要求你进入重点,这就意味着你已经失去了一个非常好的机会。

为了能充分利用这 5 分钟的时间,你需要首先从问答中梳理出客户 “之前” 的状态。他们的需求痛点在哪里?是什么影响了他们的工作效率?然后再将注意力集中在他们 “以后” 所希望实现的理想状态。你的产品能够帮助他们完成什么目标,能帮助他们解决什么问题?他们对这样的一款产品有什么要求?谁会使用这款产品?在你的产品的帮助下,他们的公司会变成什么样子?

如果能将 “之前” 和 “以后” 这两个问题搞清楚,就能让你的产品 Demo 变得更有针对性。当然,为了获得更精确的信息,你也可以在 Demo 过程中问问题。不过 Demo 之前的 5 分钟提问题的环境是最为重要的,直接关乎你是否能了解客户的需求。

尽管这 5 分钟非常重要,但是你还是无法在这么短的时间内获取所有有价值的信息的。你需要知道,他们告诉你的东西只是他们真实感受和期待的冰山一角。所以你必须要利用一切可以利用的机会来获取更多的信息。你还会发现,如果听众认为你的 Demo 和他们的需求有相关性,他们便会为你提供越来越多的信息。

正是通过这种方式,Falcone 最近成功搞定了一家大型电商的订单。在产品 Demo 的过程中,他了解到了一些关键性的细节信息:“我们需要真正了解客户正在面临的问题和挑战。他们所面临的最大的问题就是很难区分客户群体。为了推动营收增长,他们每个月的月底都会面向所有人进行打折促销。这家电商希望能够区分客户,给不同的客户群体提供最合适的折扣方案。” Falcone 了解了客户的这一需求后,他就在 Demo 产品时专门介绍了 Monetate 软件是如何能帮助对方解决这个问题的。

在了解了他们最关心的问题后,我就有底气这样说:“我觉得你们最大的营收增长机会就是使用我接下来将展示的工具。下面我就为你们详细介绍这款工具,看它是如何能为你们实现营收的增长的。”  如此一来,我成了能为他们实现目标的值得信赖的顾问,让我与那些单纯向他们销售产品的其他竞争对手有本质的区别。

首先告诉客户结果,再解释过程

畅销书作家 Malcolm Gladwell 写的书之所以这么受欢迎,其中很大原因在于他讲故事的方式:先告诉你故事的结局是什么,然后再解释其中的前因后果。其实同样的结构也适用于产品 Demo 中。你可以首先让客户能想象、甚至体验用了你的产品或服务之后的工作和生活是什么样子的。在他们的脑海中形成了这种画面感后,再返回去向他们解释为什么用了你的产品后他们的生活 / 工作能变得更好。这也算是 5 分钟问答环节中药留意客户 “以后” 所希望实现的理想状态的一部分,然后再针对性地进行回答。

迈克尔.乔丹是如何掀起一股运动鞋革命的?如果你回过头去重新看飞人乔丹拍过的电视广告的话,你就会发现,大家看完广告后之所以选择去买那款运动鞋并不是因为这是一款质量很好的产品,而是因为他们想和乔丹一样能飞。他们知道自己想成为什么样子,因此在做产品 Demo 时,你首先就要告诉他们你能帮他们实现的东西。

这是你们的目标,这是你们目前面临的问题,这是我们的产品帮你解决问题之后的样子。要尽快把这些信息告诉客户。

开头说完上面这部分内容后,如果客户给出以下这种回应:“嗯,不错,这正是我想要的。那你现在就告诉我你的产品是如何能帮我实现目标的。” 那么你离成功就不远了,这时你就可以向客户解释你的产品功能具体是如何能满足他们的需求的。

在给客户 Demo Monetate 这款产品的时候,Falcone 通常会采用下面这个非常有效的方法:先展示客户自己目前的网站,再展示加入了他们希望加入的内容和服务之后的网站,即使用了 Monetate 后网站是什么样子。通过这种对比的方式后,如果你把解决方案直接放在他们面前,客户想拒绝都难。

在 Demo 的时候,根据现场情况选择合适的展示语调也非常重要,可以选择热情洋溢,也可以表现得沉稳严肃。如果选择不恰当,则会适得其反。如果我的 Demo 对象是投资人,投资人说他只投那些真正具有革命性意义的 B2B 应用,这时我会表现得非常严肃和直接,告诉他为什么我的产品和市场上的其它产品是与众不同的。如果我的 Demo 对象是销售类公司,对方希望在没有 IT 的帮助下通过更快推内容来增加营收,这时我会用一种更具想象力的兴奋语气来向他们解释使用我们的产品是如何帮助他们实现这项目标的。

要学会洞察整个房间里微妙的变化,包括客户的用词、客户谈论自己的产品和你的产品的方式,这样你就能更快地了解双方。

Demo 产品时要按从宏观到微观的顺序

介绍产品时要从宏观入手,等于为接下来详细的介绍内容搭建一个框架。你要记住,你要演示的对象中的大部分人对你所要演示的内容是一无所知的,也不知道这个产品是如何运作的。如果你担心无法详细介绍产品的各项功能或是漏掉什么内容就去太快介绍产品细节的话,那么你很有可能就会搞砸。

你首先从宏观方面描述你的产品是如何能满足客户的需求的,然后再详细介绍产品的细节信息。如果客户能给出这样的反馈就最好了:“你刚刚介绍的产品的大概内容我了解了,整体上比较符合我们的需求,我想知道你的产品是如何具体满足我们的特殊需求的。”   在详细介绍产品的时候,你需要利用在之前的 5 分钟提问环节中发现的客户的需求来抓住他们的注意力。

举个例子,假如你销售的是一款设备,这款设备最大的特点之一就是它非常小巧。你需要把介绍重点放在设备质量上,同时让用户知道你甚至可以将这款设备放在口袋里。这是这款设备的宏观信息。然后你可以再去介绍设备的具体功能,这是微观信息,例如支持无线充电、电池容量等信息。

先展示产品的宏观信息,再介绍微观的具体功能,这样能够确保客户跟着你的逻辑走,让他们从一开始就对产品产生兴趣。如果接下来介绍的某些具体功能他们不感兴趣或是和他们的需求不相关,你要学会及时打住。如果你将自己准备的东西按照这个逻辑在大脑里多过几遍,那么你 Demo 的成功率就会越高。

掌控 Q&A 环节

为何你的产品 Demo 如此糟糕?因为你太注重产品本身了

一个成功的 Demo 就是一次以产品为背景的对话。

在理想情况下,在做产品 Demo 的过程中,你肯定希望大家能够提问交流,而不想讲 Demo 变成一场个人讲座。因此你可以尽早在 Demo 中问一些问题。

为了能让大家都参与进来并加强双方的了解,你可以在 Demo 过程中问几类问题。第一类问题是开放式问题。这类问题的目的就是为了能让客户进行讨论。例如:当前工作流程中的哪一方面最让你崩溃?千万不要低估了你选择问的问题的重要性。即便你只想通过问问题让大家讨论,你也需要认真想想该问什么问题。一定要避免问那些无法和产品功能关联起来的问题。

第二类问题是针对性的问题,问这种问题的目的是为了将 Demo 效果最大化。如果我发现了客户面临的一个非常大的挑战或想实现的目标,这时为了将我 Demo 的产品的影响最大化,我就可以问一个针对性的问题,例如:所有这些低效率工作都会浪费公司很多的钱,不是吗?。一般他们在同意这个说法之前都会先沉默一段时间。

当然产品 Demo 最紧张的环节还是客户的提问环节。如果你发现自己无法很好回答对方的问题,那么你最好的办法就是 ‘回应式提问’,也就是说在他们提一个问题后你可以提出一个你自己的问题。首先要考虑他们问问题的目的,他们为什么要问这个问题?也许是因为他们真的对一些东西还不了解,也许是因为他们认为竞争对手的产品更好,或许他们质疑你的产品交付能力。你可以通过回应式提问的方式来了解其中的缘由。

回应式问题可以帮你走出困境。Falcone 曾记得有一位客户问他:“你 Demo 的产品是否能根据用户的选择来自定义推送内容?” 他立刻说:“当然可以,我来给你展示一下如何做到的。” 演示完之后,客户竟然给出这样的反馈:“你知道吗,这个功能并不适合我们,如果每个人都能这样做的话,那就太糟糕了。”

今天,如果面临同样的情景和问题,Falcone 不会立刻问题对方的问题,而是会提一个回应式的问题:“你们要推送什么特别种类的内容?你们团队中是谁在做这项工作?你希望每个人都有这么大的权限吗?” 如果你能针对对方的问题问出这一系列精心准备的问题的话,客户一般都会从中挑选对于他们来说最重要的问题去解释回答,这样你就能获得更多的数据信息。如果对方告诉我,他们只希望技术用户能够推送内容,我就会告诉他们 Monetate 是如何可以帮助他们做到这一点的。

总结

  • 要尽可能地多地了解你的客户,甚至是他们的个人资料。Demo 前要多跑腿搜集尽可能多的资料,在正式 Demo 之前,先用 5 分钟时间去来了解他们真实的需求、挑战和目标。
  • 期待、准备、排练,直到你可以游刃有余得完成整个 Demo,做到 Demo 的信息充足、冷静沉稳、表达清晰。
  • 在 Demo 开始后,首先给客户他们想要的结果,让他们知道使用你的产品后他们的工作、生活是如何变得更好的,然后再解释原因。
  • Demo 时要从宏观入手,让他们了解大致情况,这部分尽可能简单,不能让客户厌烦。然后再根据客户的特别需求来介绍相应的产品微观功能。
  • 在整个 Demo 过程中,都要掌控 Q&A,尽可能让每个人都参与进来,同时要持续不断地强化产品卖点,并办法了解客户对产品的真实需求。

本文编译自:firstround.com,如若转载,请注明出处:http://36kr.com/p/5044093.html