科技博客的黄金时代远未结束

  编者按:针对两天前Jeremiah Owyang的《科技博客黄金时代已结束》一文,国外知名科技博客TechCrunch前高级编辑Sarah Lacy写了一篇观点截然不同的文章,如下。

  首先,本人非常欣赏Jeremiah Owyang的市场分析,不过对于最近的《科技博客的黄金时代已结束》一文,本人实难苟同。

  科技博客的黄金时代绝对没有结束,真结束了也不是因为科技博客死了,而是步入了白金时代,不但科技博客,连博客离结束也还还很遥远,事实上,个人觉得科技博客步入了一个激动人心的时期 。

  很多分析科技趋势的在短期太过夸大其词,长期太过低估,不过Jeremiah有的观点的确很对,过去三年证明了博客存在许多局限性,比如,我们不能通过科技博客做生意或者获得很多粉丝,取代不了旧形式的媒体。

  许多网站,如Facebook,Yelp及Twitter都渴望通过发布大量的越来越简单且无关痛痒的文章来表达自己,的确很流行,但仍然有非常多得人喜欢写作,喜欢博客的风格,写自己的想法,释放自己,而不仅仅仅是简单的分享,Tweet,评论,如果是为了表达思想,博客仍然是最好的平台,其实现在很多专业博客处于起步阶段,正是有胆识,有思想的竞争者站在博客巨人肩膀上大展宏图的时候。

  而且也有一些新媒体做得很出色,像Sport Blog Nation一样,美国体育专业网站Bleacher Report就建立了一个长期以来被忽视的体育博客世界,而Verge在博客界(隶属于SB)正颠覆传统博客,打造了一个相当成功的Gadget博客,如果你相信我,科技博客将会增加更多新成员。

  我承认,许多第一波博客被收购或者创始人疲惫不堪,难以继续,或者已经变得没有博客的味道,但那并不代表博客已死或垂死挣扎,暂且不反驳这个观点,现在正是彻底改造博客的时候,是时候推出下一代博客的时候,下一代博客一定要具有创意,具有很好的商业模式。

  就新博客的建立,提几点建议:

  1)读者博客:比如现在的HuffPo及SeekingAlpha,如果有一天,为科技博客供稿的都不是专职编辑或者付费作家,而是读者自己,那么参与度将更高,也不会面临传播方面的问题。有的人写作不是为了谋生,仅仅是想表达自己的观点。

  确实许多顶级文章都来自于专业人士,比如像Chris  Dixon ,Fred Wilson及Ben Horowitz这样的VC,但他们不想也不会每天都发博客,如果他们只是零星的发布几篇博客,那么博客的传播就存在问题,所以,科技博客需要读者参与。

  2)UI:现在的博客都靠堆积量来增加网站流量,所以这个行业在用户界面方面存在很大问题,许多新兴的博客都想努力解决这个问题,比如Verge,UI很漂亮。

  3)博客不是越短越好,也不应完全关于商品:Jeremiah说,现在人们都喜欢关注度短博客,而不是长篇大论,可是本人在TechCrunch期间也写了不少长文章,流量一样很高,其实只要你写得好,分析到位,人们还是很愿意花时间去阅读,不要为了长而长,而是要写真正有质量的东西,这样才会赢得读者青睐。

  4)商业模式:做博客就一定要盈利,要不你怎么继续。很多时候,博客都不知如何利用自己的影响力去盈利,比如我呆过的地方中,TechCrunch影响力最大,而广告的平均盈利却最少,所以,下一代博客就要考虑如何在旧形式博客上扬长避短,建立庞大观众群,在提高影响力的同时,懂得如何利用自己的影响力去盈利。

  5)不要变成个人舞台:对第一代博客来说,最大的 问题就是很多博客变成了一个人的舞台,虽然TechCrunch在这方面做得很不错,但也免不了出现这样的问题,部分原因就是一些博客始于一种爱好,所以下一代博客就应该遵循商业第一,并从一开始就解决博主单一问题。

  6)永远不要出售博客:如果出售了,平台犹在,灵魂易主,表达的是不一样的东西,可能是你不想看到的,要建立一个屹立不倒的媒体一定要为了某个主题,而不是为了某个人。

  英文原文:Sarahlacy:Golden Age of Tech Blogging Done? I Couldn’t Disagree More

  中文翻译:雷锋网编译。

评论《科技博客的黄金时代远未结束》的内容…

相关文章: 谈谈博客、微博客与轻博客 WordPress与Tumblr:传统博客与轻博客之争 被匿没的恐惧——也谈blog的发展趋势 探索中国独立博客的发展 月光博客博客写作编辑规范

微博:新浪微博 – 腾讯微博 月光博客投稿信箱:williamlong.info(at)gmail.comCreated by William Long www.williamlong.info

【Android开发笔记】2.第一个Demo

前言

上一节已经完成了Android开发环境的搭建,在这一节,将会新建一个Demo,以熟悉Eclipse。包括详细的开发步骤、如何使用模拟器、如何连接手机、如何生成安装包等。

声明

本系列文章不是教程,仅为笔记,如有不当之处请指正。

欢迎转载,转载请保留原出处:http://www.cnblogs.com/rayee

正文

新建一个Demo并运行。

一、新建工程

打开Eclipse,File –> New –> Project

选择Android Project

选择Android SDK版本(这将决定程序能运行在哪些版本的设备上。Android程序支持向下兼容,也就是说Android4.0.3的设备能运行基于Android1.6 SDK开发的程序,反过来则不能运行。你可以选择最低的Android1.6以兼容更多的设备,但在程序中不能使用更高版本中的特性,所谓鱼和熊掌不能兼得,根据实际情况选择才是王道。)

选择Android2.2,点击Next

█ 标注1处填写程序名称,即运行程序时显示在顶部的名称。

█ 标注2处填写包的名称,学过JAVA的同学都明白何为“包”,对于还没接触“包”的同学,我就个人的理解说一下:

Package(包),为了防止同名的class产生冲突而把他们分到不同的组,这个组就是“包”,具体表现形式为文件夹,如com.android.demo,在工程的下src下可看到com/android/demo,三个依次包含的文件夹。>>点此查看详细资料

注意:1.包名中不能包含中文字符,2.不能以分隔符“.”结尾,3.不能少于两层。

█ 标注3处为主Activity的名称,自动生成,无需修改。

Activity是Android组件中最基本也是最常用的一种组件。在一个Android应用中,一个Activity表现为一个单独的屏幕(功能类似于wml里面的card)。每一个Activity都被实现为一个独立的类,并且继承于Activity这个基类。>>点此查看详细资料

█ 标注4处,支持的最低版本,即为上一步选择的SDK版本。

点击Finish,可看到工程就新建好了。

二、工程文件介绍

上图为一个工程的目录结构,下面将依次介绍:

█ src文件夹

此文件夹下存放着程序的JAVA程序源码,可以看到已存在包com.android.demo、DemoActivity.java,这是新建工程时自动生成的。以后的编码工作主要在此文件夹下进行。

█ gen文件夹

可看到这个文件夹下存在包com.android.demo,包里面有一个R.java文件,里面保存了用到的资源的相关信息,由IDE自动维护,不需要手动修改。以后用到会详细讲解。

█ Android 2.2

这个为SDK包,如果选择其它的SDK这里会有所不同。

█  assets文件夹

存放资产文件的文件夹。

█ bin文件夹

编译生成的apk程序会存放到此文件夹下。

█ […]

【Android开发笔记】1.开发环境的搭建

前言

为提高产品的竞争力,决定开发Android客户端,但连JAVA都还不是很熟悉,只得从零开始。

我会把整个过程记录下来,包括JAVA的学习、Android的开发方式,一来是为了锻炼一下自己的写作能力,因为发现自己快连一句话都写不清楚了,二来也是为了理清思路,加快产品开发。当然如果能够你对有所帮助,那是再好不过。

声明

本系列文章不是教程,仅为笔记,如有不当之处请指正。

欢迎转载,转载请保留原出处:http://www.cnblogs.com/rayee

正文

关于Android的发展历史和资料这里不做多的介绍,如有不了解或有兴趣的朋友可以在此下载详细资料新版Android开发教程及笔记-完整版.pdf 荐。

本节主要记录开发环境的部署:

一、安装JDK (Java Development Kit)

Android软件采用JAVA开发,当然需要JAVA的开发包。

官方下载地址为:http://www.oracle.com/technetwork/java/javase/downloads/jdk-7u2-download-1377129.html

下载后按提示安装,安装后在命令行下运行 javac ,若有如下提示,则说明安装JDK成功,可以进行下一步安装。

若提示“javac不是内部或外部命令,也不是可执行程序”,说明JDK安装出现异常,环境变量未设置好,不能继续进行下一步安装。

关于JDK的安装配置请看:http://hi.baidu.com/sbsgap/blog/item/dda2cd179e61aa1d4b90a73a.html

我采用云端平台的JDK,很方便,下载即可,不需要安装,不需要额外配置。

二、安装Android SDK

Android SDK,没什么好说的,官方下载:http://developer.android.com/sdk/index.html

推荐下载绿色版,下载后解压到任意目录,后面在IED中指定路径即可。

三、安装IDE (Integrated Development,集成开发环境)

Android开发IDE有很多选择,但绝大多数人都采用Eclipse。

官方下载地址:http://www.eclipse.org/downloads/

Eclipse的版本有很多,支持JAVA的即可,但我第一次下载安装Eclipse Classic后,在安装ADT时出现错误,具体提示忘了。

重新下载安装了Eclipse IDE for Java EE Developers。

安装好Eclipse后开始安装ADT(Android Development Tools)(ADT是google针对Eclipse开发的插件,将Eclipse和Android SDK粘合在一起,使得Eclipse能开发Android程序,如果你选择的其它IDE需要安装对应的插件):

运行Eclipse,选择Help –> Install New Software

[…]

Facebook图片存储架构的学习

分享照片是Facebook上最流行的的功能之一。截至目前,用户已经上传超过15亿张照片,这使得Facebook成为最大的照片共享网站。对于每一个上传的照片,Facebook都生成并存储四个大小不同的图像,从而转化为共60亿张照片,总容量超过1.5PB。目前以每周220万新照片的速度增长,相当于每周要额外增加25TB存储。在高峰期每秒需要传输55万照片。这些数字对Facebook的照片存储基础设施的一个重大的挑战。

旧的 NFS 照片架构

老的照片系统架构分以下几个层:

上传层接收用户上传的照片并保存在 NFS 存储层。 照片服务层接收 HTTP 请求并从 NFS 存储层输出照片。 NFS存储层建立在商业存储系统之上。

因为每张照片都以文件形式单独存储,这样庞大的照片量导致非常庞大的元数据规模,超过了 NFS 存储层的缓存上限,导致每次请求上传都包含多次I/O操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么 Facebook 主要依赖 CDN 的原因。为了解决这些问题,他们做了两项优化:

因为每张照片都以文件形式单独存储,大量为目录及文件在NFS 存储层上产生了大量的元数据, 这个规模的元数据量远远超过了超过了NFS 存储层的缓存上限,导致每次招聘请求会上传都包含多次I/O操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么 Facebook主要依赖 CDN 的原因。为了解决这些问题,他们做了两项优化:

Cachr: 一个缓存服务器,缓存 Facebook 的小尺寸用户资料照片。 NFS文件句柄缓存:部署在照片输出层,以降低 NFS 存储层的元数据开销。

新的 Haystack 照片架构

新的照片架构将输出层和存储层合并为一个物理层,建立在一个基于HTTP 的照片服务器上,照片存储在一个叫做haystack 的对象库,以消除照片读取操作中不必要的元数据开销。新架构中,I/O 操作只针对真正的照片数据(而不是文件系统元数据)。haystack 可以细分为以下几个功能层:

HTTP 服务器 照片存储 Haystack 对象存储 文件系统 存储空间

在下面的介绍中,我们会对于上述的每个功能层做详细的讲述。

存储空间

Haystack 部署在商业存储刀片服务器上,典型配置为一个2U的服务器,包含:

两个4核CPU 16GB […]

互联网推荐系统比较研究

互联网规模和覆盖面的迅速增长带来了信息超载(information overload)的问题:过量信息同时呈现使得用户无法从中获取对自己有用的部分,信息使用效率反而降低。现有的很多网络应用,比如门户网站、搜索引擎和专业数据索引本质上都是帮助用户过滤信息的手段。然而这些工具只满足主流需求,没有个性化的考虑,仍然无法很好地解决信息超载的问题。推荐系统(recommender system)作为一种信息过滤的重要手段,是当前解决信息超载问题的非常有潜力的方法。推荐系统与以搜索引擎为代表的信息检索(information retrieval)系统最大的区别在于:

搜索注重结果(如网页)之间的关系和排序,推荐还研究用户模型(user profile)和用户的喜好,基于社会网络(social network)进行个性化的计算(personalization); 搜索的进行由用户主导,包括输入查询词和选择结果,结果不好用户会修改查询再次搜索。而推荐是由系统主导用户的浏览顺序,引导用户发现需要的结果。高质量的推荐系统会使用户对该系统产生依赖。

因此,推荐系统不仅能够为用户提供个性化的服务,而且能够与用户建立长期稳定的关系,提高用户忠诚度,防止用户流失。

推荐系统最典型的应用是在B2C电子商务领域,具有良好的发展和应用前景,商家根据用户的兴趣、爱好推荐顾客可能感兴趣或满意的商品(如书籍、音像等)。顾客的需求通常是不明确的、模糊的,如果商家能够把满足用户模糊需求的商品推荐给用户,就可以把用户的潜在需求转化为现实需求,从而达到提高产品销售量的目的。目前,几乎所有的大型电子商务系统,如Amazon、eBay等,都不同程度地使用了各种形式的推荐系统。其中Amazon研究电子商务的推荐系统长达10年时间.各种提供个性化服务的Web站点,如电影、音乐网站,也需要推荐系统的大力支持。表1中按照应用领域分类列举了一些典型的商用推荐系统。

在学术界,自20世纪90年代中期出现第一批关于协同过滤的文章[1−3]以来,推荐系统在电子商务、网络经济学和人类社会学等领域一直保持很高的研究热度并逐渐成为一门独立的学科。各种推荐算法涵盖包括认知科学、近似性理论、信息检索[4]、管理科学[5]、市场营销建模[6]等在内的众多研究领域[7].近几年来,国际学术界针对计算机网络信息整合的推荐相关的研究大量出现:

ACM设立推荐系统年会(ACM recommender systems); 计算机领域的人机交互、数据挖掘和机器学习顶级会议(SIGCHI、KDD、SIGIR、WWW等)中,推荐算法的文章逐年增加; 国际数据分析领域的高阶期刊(如IEEE Trans. on Knowledge and Data Engineering,ACM Trans. on Information System等)刊载数篇推荐系统方面的文章。

信息领域做推荐系统领先的研究单位(学者)包括:纽约大学(Alexander Tuzhilin)、明尼苏达州立大学的GroupLens研究小组(Joseph A. Konstan,John Riedl等)、美国密歇根大学(Paul Resnick)、卡内基梅隆大学(Jaime Callan)、微软研究院(Ryen W. White)等。其中,美国密歇根大学在2006年开授了由Paul Resnick主讲的推荐系统的课程。推荐系统,结合社会网络和语义网络的研究,面向互联网发展中出现的新问题和新技术需求,具有广泛的研究和应用前景。

本研究调研了推荐系统在计算机网络和信息领域的主流研究与应用进展。本文第1节中给出推荐系统的形式化定义。第2节根据推荐算法的类别分类陈述最新的学术进展。第3节讨论使用的数据集以及实验评测方法,对当前推荐系统的研究难点进行归纳并对比各种推荐方法的优、缺点。第4节对推荐系统有待深入的研究点和发展趋势进行初步预测。

1 推荐系统概念和形式化定义

目前被广泛引用的推荐系统的非形式化概念是Resnick和Varian在1997年[8]给出的:“它是利用电子商务网站向客户提供商品信息和建议,帮助用户决定应该购买什么产品,模拟销售人员帮助客户完成购买过程”。推荐有3个组成要素:推荐候选对象、用户、推荐方法。通用的推荐系统模型流程如图1所示。用户可以向推荐系统主动提供个人偏好信息或推荐请求,或者用户不提供,而是推荐系统主动采集。推荐系统可以使用不同的推荐策略进行推荐,如将采集到的个性化信息和对象数据进行计算得到推荐结果,或者直接基于已建模的知识数据库进行推荐。推荐系统将推荐结果返回给用户使用。

此外,文献[7]给出了推荐系统的形式化定义:设C是所有用户(user)的集合,S是所有可以推荐给用户的对象(object)的集合。实际中,C和S集合的规模通常很大,如上百万的顾客以及上亿种歌曲等。设效用函数u()可以计算对象s对用户c的推荐度(如提供商的可靠性(vendor reliability)和产品的可得性(product availability)等),即u: C×S→R,R是一定范围内的全序的非负实数,推荐要研究的问题就是找到推荐度R最大的那些对象s*,如式(1)。

用户和对象的度量与采样可以使用不同的属性和特征,这根据实际面对的问题不同而不同。推荐算法研究的中心问题是效用度u的计算,并非遍历整个C×S的整个空间,而是分布到一个流形子空间(manifold)上。对于某个数据集而言,必须先对u进行外推(extrapolation),也就是说,对象必须具备用户以前作的评分(rating),未评定(unrated)的对象的评分必须先根据已标注的对象进行标注外推后才可以使用。各类推荐算法在外推和评分预测(rating propagation)上采用了不同的策略,设计了不同的效用函数,这些将在下一节中分类介绍。

2 现有的推荐算法

推荐算法是整个推荐系统中最核心和关键的部分,在很大程度上决定了推荐系统类型和性能的优劣。目前,对推荐系统的分类并没有统一的标准,很多学者从不同角度对推荐方法进行了不同的划分[9−11]。但主流的推荐方法基本包括以下几种:基于内容推荐、协同过滤推荐、基于知识推荐和组合推荐。本节我们将分类讨论推荐算法的研究成果,下一节我们将讨论这几类推荐算法各自的优、缺点和推荐系统研究的重点、难点问题。

2.1 基于内容的推荐

基于内容的推荐(content-based […]

十年程序员(三)

经验是什么?有一段时间,我一直在问自己这个问题。

许多所谓有着“相同工作经验”的人,表现的差异却极大。即便在ThoughtWorks,一同起步的毕业生,几年下来,个人的差距也是非常明显的。有人已经可以带团队了,有人成为了技术专家,有人却只能在团队里低着头忙活着自己的一亩三分地。

面对一个问题的时候,我所能想到的就是我的经验。

我所能想到的,取决于我做过的事情。习惯于在舒适区练习的人,因为做着本质上类似的东西,面对问题时,脑子里想到的东西只会局限在很窄的范围内。很多貌似工作了很多年的人,其实,只是在不断重复最初一两年的事情而已,唯一的差别或许只在熟练程度而已。所以,工作经验和工作年限是截然不同的两个东西。

只有跳出自己的舒适区,尝试一些不同的东西,才会打开一个人的思路,让人得到真正意义上的提升。

ThoughtWorks的经历让我开始把目光投向代码以外的许多东西,事实上,在ThoughtWorks里,凡是代码写得好的人,几乎都是具有多方面技能的:能写代码,能设计架构,能分析业务,能做测试,能带团队,能面试,能做咨询,甚至能建设新办公室。

正是因为能做的事情很多,所以,再坐回到计算机面前写代码时,想到的就不仅仅是局部的一点点代码,而拥有的是更好的大局观:

我要知道Story的价值所在,保证我写的东西真正有意义 我要多从各个角度考虑一下这个问题,以免出现bug 我要写出干净的代码,以便其他人更好维护 我做出的设计要让团队成员都能更容易的理解 我要让团队成员更好的成长 我要站在的客户的角度思考这个问题 我要在客户面前更好的维护团队利益 我需要考虑整个办公室人员的成长 ⋯⋯

记得有人对我说,你做了很多有意思的事:从最早的Ruby on Rails交付项目,到后来的咨询,再到现在基于DevOps on Cloud的持续交付。在我看来,得到这些机会,恰恰是因为我具备了做很多事情的能力。

能做的事情越来越多,路也就越来越宽,得到的机会也就越来越多,得到锻炼也就越来越多,能力也就越来越强,能做的事情也就越来越多。不知不觉中,一个人就会进入到一个正向反馈循环中。

幸运的是,十年来,我一直在成长,不管是主动还是被动。

十年程序员(二)

随着自己在ThoughtWorks经历的事越来越多,对这个曾暗自困扰我许久的问题,我也有了新的思考:真正可怕的不是X岁后能不能编程,而是X岁后只能编程。

为数不少有工作经验的人进入到ThoughtWorks之后,会感觉很不适应,因为这里很多刚刚毕业工作一两年的小朋友写程序都很厉害,他们自身在写程序的优势就不那么明显了。结对的时候,他们不断被这些小朋友们挑战,有些人就会很郁闷,因此离开ThoughtWorks的例子也是有的。

单就纯粹的代码输出能力而言,经过一段时间的刻意练习,人和人之间往往不会相差很多,相比较而言,在编写一段代码时,可以考虑到的方面,不同人会因为经验和视野差异极大。比如,要一个新手实现一个需求,他就会奔着代码直冲过去,而一个有经验的人,则会考虑许多方面,为什么要做这样一个需求,实现这样一个需求有哪些技术方案,实现这样一个功能是不是会对现有架构有什么影响,写这样一段代码是不是需要对现有代码进行某些重构,等等。

如果一个人具备的所谓工作经验,仅仅是所谓代码输出的经验,那他的实际价值就会大打折扣。

事实上,在ThoughtWorks的开发团队里面,我们也是鼓励一个人尝试不同的东西,比如,有人可以帮助QA做测试,有人可以去尝试去做业务分析,有人会在公司内部做分享等等。做这些工作本身并部能让我们的开发技能得到大幅度提升,但这些不同的尝试会让人不同的看问题的角度,如果我没有了解过业务分析,我就不会考虑一个事情本身的价值,倾向于别人告诉我做什么,我就去做什么。如果没有带过团队,我就不会考虑,怎么把一个设计做得简单,让别人更好理解和接受。

道理说白了很简单,一个人的价值取决于他有多大的不可替代性。如果一个人只能按照别人的要求写代码,他的技能就是很容易替代的。

十年程序员(一)

2012年,终于可以和人家说,我有十年工作经验了。幸运的是,十年后,我还在写代码。

十年前,促使我选择写程序作为一生追求的是我对写程序的好奇以及实现功能后的成就感,但那时,在对自己未来充满信心的同时,内心深处依然惴惴不安。萦绕心头的乌云是所谓30岁程序员的说法。

那时,很流行的一个论调是,程序员只能做到30岁。人到30岁之后,智力在下降,体力在下降,再加上家庭的琐事,人很难再写程序了。

那时的自己尚年轻,没有体会到30岁后的状态,很难知道这种说法的真伪,所以,内心里还是会有一丝丝恐惧。有时,我会假想,29岁的最后一天我还能写程序,30岁生日一觉醒来,我的编程能力便烟消云散了。

大概当我有5年工作经验时,那个扰人的论调依旧,只是年龄上,从30岁变成了35岁。我暗自庆幸,我又可以多写五年程序了。也是那一年,我进入了ThoughtWorks,在这里,我遇到了一群疯狂热爱代码的人,我所能做的就是暗自打磨自己的编程技艺。

在ThoughtWorks几乎五年了,这期间,我跨过了30岁的门槛。时至今日,我依然能写程序,我最担心的事情没有发生,而且,我写程序的能力似乎还在提升。相比于刚开始写程序的小朋友,

我在动手之前,就可以对自己要实现的内容有个更好的理解 我的解决方案会更简单,更容易理解 我分解出的任务步骤更小,更容易实现 我写程序时考虑的方面会更多 我会更多的考虑写出的程序对于全局的影响

在这期间,我也逐渐释然。其实,不是30岁能不能编程,而是那个时候,30岁的程序员本来就没有多少,这也是我5年的时候,论调成了35岁,是因为这一代人已经长过了30。这不,今年就有人开始讨论一些40岁程序员的问题了。

进度报告——Programmers(33)

载于《程序员》杂志2012年第1期。

这个系列的漫画讲述程序员——这种神秘人类的囧事,故事多来源于我身边的程序员朋友,且以互联网开发背景为主。

如果你有什么可乐的关于程序员的故事、对话、代码,愿意通过漫画的形式分享,请给我发邮件。arthur369@gmail.com。

小米手机教会我们的四件事情

小米手机已经注定成为一个热门话题,无论是从无到有打造一个广为人知的消费数码品牌,还是首批获得30万台预订,两轮共计20万台机器均在三个多小时内疯抢一空。雷军跟小米已经创造了足够多的话题,小米手机的百度指数一直在10万左右徘徊,媒体也逐渐从旁观、质疑向主动关注转变。

现实无时无刻在向我们证明:小米手机真的火了。在小米手机从研发、推广、营销、生产、销售的过程中,有什么是值得互联网从业者或者创业者学习的?这篇文章总结四条经验可能会帮到大家。

1、通过讨好发烧友去赢得市场

这里的发烧友通指那些了解市场、产品、趋势的领先消费者,他们通常热衷于追逐最新的产品趋势,他们会在传统电视时代花费数倍的价格尝试平板电视,他们会花费一个通宵的时间去研究两款手机操作系统的区别,然后通过日志或帖子的方式分享给圈内用户。在外人看来他们是疯子,但这些领先消费者是客观上推动创新进步的力量。

全球知名传播学大师Everett M. Rogers在其所著的 “创新的扩散(Diffusion of Innovations)” 一书中指出,优秀的创新总是能首先搞定仅占社会总数2.5%的领先消费者,他们将会通过更高的传播能力帮助产品覆盖13.5%的早期接受者,以及占比高达68%的主流消费者。

而小米正是通过提供极高的性价比,还算过得去的产品,成功赢得发烧友人群的青睐。而这些发烧友通常是影响周围朋友、家人选择手机的重要参考,侧面推动了小米手机在主流消费人群中影响力的提升。

小米现在通过发烧友人群获得的影响力,如果采用传统的广告营销宣传策略,投入的成本可能将超过亿元,而效果可能远远不及。

2、突破新市场的最好办法是打破现有规则

如果小米手机只是一款价格略具优势,而外型、设计、功能毫无新意的产品,那么即便雷军万般鼓吹,也绝对无法达到市场如此热烈的回应。

小米手机成功的关键,是把其它厂商卖3000元、4000元的智能手机,以前所未有的1999元销售。包括华为、中兴这样的新兴终端厂商,也默认了智能手机市场的利润、成本、收益规则,而小米的“破盘价”成功满足了消费者以其它品牌中低端智能手机的价格获得顶尖的智能手机体验,包括屏幕、处理器、电池、内存等重要配置。

而看起来小米手机的媒体评测、用户试用体验好像也不赖,这样消费者的最后一道心理防线也被攻破了,剩下的只是疯狂的抢购了。小米手机留给我们的经验是:想要在一个不熟悉的新兴市场获得快速突破,最好的办法就是毫不留情地彻底打破现有规则。

根据行业、产品的不同,这个规则可能是价格、功能、定位等各种各样的因素。

3、适当的饥饿营销有利于整体计划推进

不论有意无意,饥饿营销已经变成了小米手机的重要关键词,或是因为真实的产能不足,或是因为营销力量的推动,在正常情况下大多数人无法通过正常渠道买到小米手机。

饥饿营销跟放风筝原理很类似,通过有计划的放货节奏控制,造成市面上大面积缺货的现状或假象,物以稀为贵,进而引发消费者的大规模追捧。如果同步配合适当的媒体宣传策略,能够有效带动产品销售。

互联网产品的邀请注册也是属于饥饿营销的一种,在产品销售、宣传、营销中加入并良好控制饥饿营销的节奏,将会有利于产品整体计划的推进。

4、做好充足的准备

在小米手机出现的前半年时间,准备不足一直是小米手机所面临的问题。产能预估不足导致了产品的大面积缺货,从刚开始的5000台再到最近两批的20万台,小米手机似乎永远是买不到的,当然也可能是饥饿营销的选择。

在线业务支撑也成为小米的软肋,从第一批小米抢号开始,再到第一批、第二批正式产品的在线销售,永远是伴随着宕机、访问慢、页面出错各种层出不穷的问题。初期的估计不足是可以理解的,但是接二连三在同一个地方出现问题实在让人难以理解。小米如果需要的话,并不难获得大流量、大负载的服务器支撑。

小米手机给我们的负面教材是,永远要为你的产品准备足够多的余量,以备用户增长带来的资源消耗。如果可以的话,尽量选择高扩展性的软硬件支撑体系,当然国内云计算服务仍然出于初始阶段。

在RTdot的原创:http://www.rtdot.com/others/109

© XJP for XJP的碎碎念, 2012. | Permalink | 9 名群众围观了该文 | Post tags: 小米手机

[…]

Category

Archives