夜幕
2010年9月3日
没有评论
分类: 黑白盒子
国产开源在线HTML编辑器 xhEditor v1.1.0正式发布
2010年9月2日
没有评论
xhEditor是一个基于jQuery开发的简单迷你并且高效的轻量可视化XHTML编辑器，基于网络访问并且兼容IE 6.0+,Firefox 3.0+,Opera 9.6+,Chrome 1.0+,Safari 3.22+。此次v1.1.0版主要变化在于提升编辑器用户体验，在修正大量问题的基础上增加了各种提升用户体验的实用功能，例如HTML5功能支持下的直接将文件拖入编辑区域上传功能，就能极大的提高用户操作效率，改善使用体验。
查看最新版演示：http://xheditor.com/demo
更多官方在线演示：
1. 默认模式：http://xheditor.com/demos/demo01.html
2. 自定义按钮：http://xheditor.com/demos/demo02.html
3. 皮肤选择：http://xheditor.com/demos/demo03.html
4. 其它选项：http://xheditor.com/demos/demo04.html
5. Javascript交互：http://xheditor.com/demos/demo05.html
6. 非utf-8编码网页调用：http://xheditor.com/demos/demo06.html
7. UBB可视化编辑：http://xheditor.com/demos/demo07.html
8. Ajax文件上传：http://xheditor.com/demos/demo08.html
9. 插件扩展：http://xheditor.com/demos/demo09.html
10.iframe调用文件上传：http://xheditor.com/demos/demo10.html
11.异步加载：http://xheditor.com/demos/demo11.html
最新v1.1.0下载地址：
http://xheditor.com/download
是谁杀了网页设计师
2010年8月27日
没有评论
原文标题：网页设计师是怎样下地狱的
把这个送给曾经接过活的设计师，或者有过类似经历的设计师们。阿门。
刚开始的时候，一切都很棒。客户提出他们的需求，你也满怀期望。充满激情和兴奋感。
客户：新的网站一定会很棒。
设计师：岂止很棒？肯定会难以置信地棒。它会像遨游在外太空的雄鹰一般不可思议。
客户给你看他们现在的网站，你们一起嘲笑它是如此糟糕。
客户：哈哈，这都是什么烂玩意！我们上次请的设计师简直是个白痴。
设计师：是啊！怎么可能做成这样？！简直就是在对全人类犯罪。
于是，你重新设计了网站。新网站看上去美观，用起来也很好。这简直就是完美设计的最佳范例。
设计师：噔噔噔噔！看！
客户：我喜欢！看上去太棒了！但是……
还需要做些“小”调整
客户（想）：这个设计很完美，但我作为CEO，有责任提点改正意见来让自己感觉自己的工作做到位了。同时，我得用“用户体验”，“转化导向”这样的术语来显得自己聪明些，尽管我几乎都不大会用电脑。
客户：你能设计得更“跳”一点么？它需要更“鲜明”些。看上去感觉好像不太对。
（作者注：客户确实跟我说过这样的话。直到今天，我还是不太理解在网页设计上“跳”和“鲜明”到底是什么意思。我也不知道怎样以他人的感受来设计网页）
所谓的小调整开始变多，很快就变成不那么小了。
客户：我想了一下，决定把字体调回Comic Sans. 另外，你能搞一个镜头光晕效果么？它们看上去非常Web2.0. 另外，这个网站绝对不能太“线条化”了。当我看这个网站的时候，我看到的都是一行一行的。你能处理一下么？
（作者注：确实有个客户这么对我说过。这个设计里绝对没有任何水平标尺或者线条之类的东西。事实上他说的是<div>啊<p>啊之类的代码生成的矩形区域）
客户让别的人参与了进来。
“看上去不错，不过我还想听到更多的意见，朋友，同事，叔叔甚至是我的宠物仓鼠”。
客户：我让我母亲也加入讨论。她在1982年设计过一张面包促销宣传单，所以你可以说她也是有设计的眼光。
客户母亲：你排的这个设计需要点亮色，看上去太暗了。加点粉色怎样？再放上一只小猫。人人都爱小猫。
（作者注：我确实曾经遇到一个客户让他的母亲也参与到设计流程里，好让她提出批评和建议）
所有希望都破灭了。
你开始幻想别的职业，比如靠挖沟来生存或者给老人搓澡。
客户：好的。现在是这样，我的狗Miffles可是个关键人物。它可以说是我生命中最重要的部分。我希望你能加上狗的“意识流”，这样看上去就像是Miffles在和来访的用户说话。我会给你几页Miffles可能会说的话，比如“我喜欢美食”，还有“嗨！欢迎访问我的网站，我是一只小狗，你可以和我握手^^”
(作者注：这绝对不是我编的。就有一个客户这样要求过。我还从来没有像那会一样那么想用车用蓄电池敲一个人的头)
你再也不是一名网页设计师。
你现在变成了一只绘图程序里的鼠标，而你的客户可以通过语音，email或者聊天软件来直接控制你。
（作者注：我曾经遇到一个客户拿走我的设计稿后，自己直接在Photoshop上进行修改，然后把改过后觉得是他们想要的效果再发给我。在我收到他的第13个修正版后，我炒掉了他。）
怨念就此诞生。
客户完全忘了，他们是雇佣了你，网页设计师，来帮他们设计一个好产品。想象一下，如果你是一个设计商业飞机涡轮的工程师，他们还敢掺和进来么？
客户：现在这个设计终于称得上是“跳”出来了！
设计师：饶了我吧……
NoSQL数据库探讨之一为什么要用非关系数据库
2010年8月25日
没有评论
随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付 web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：
1、High performance -对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到 每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的 BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当 普遍的需求。
2、Huge Storage -对海量数据的高效率存储和访问的需求
类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到 了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登 录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。
3、High Scalability&& High Availability-对数据库的高可扩展性和高可用性的需求
在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展 是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？
在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：
1、数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。
2、数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说我（JavaEye的robbin）发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
3、对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，现在这两年，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。前不久国外刚刚举办了NoSQL Conference， 各路NoSQL数据库纷纷亮相，加上未亮相但是名声在外的，起码有超过10个开源的NoSQLDB，例如：Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB，
……
这些NoSQL数据库，有的是用C/C++编写的，有的是用Java编写的，还有的是用Erlang编写的，每个都有自己的独到之处，看都看不过来了，我(robbin)也只能从中挑选一些比较有特色，看起来更有前景的产品学习和了解一下。这些NoSQL数据库大致可以分为以下的三类：
一、满足极高读写性能需求的Kye-Value数据库：Redis，Tokyo Cabinet， Flare
高性能Key-Value数据库的主要特点就是具有极高的并发读写性能，Redis，Tokyo Cabinet， Flare，这3个Key-Value DB都是用C编写的，他们的性能都相当出色，但出了出色的性能，他们还有自己独特的功能：
1、Redis
Redis是一个很新的项目，刚刚发布了1.0版本。Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统 统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是我知道的性能最快的Key-Value DB。
Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存List链表和Set集合的数据结构，而且还支持对List进行各种操作，例如从 List两端push和pop数据，取List区间，排序等等，对Set支持各种集合的并集交集操作，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的memcached来用。
Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生的可扩展机制，不具有scale（可扩展）能力，要 依赖客户端来实现分布式读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。目前使用Redis的网站有 github，Engine Yard。
2、Tokyo Cabinet和Tokoy Tyrant
TC和TT的开发者是日本人Mikio Hirabayashi，主要被用在日本最大的SNS网站mixi.jp上，TC发展的时间最早，现在已经是一个非常成熟的项目，也是Kye-Value 数据库领域最大的热点，现在被广泛的应用在很多很多网站上。TC是一个高性能的存储引擎，而TT提供了多线程高并发服务器，性能也非常出色，每秒可以处理 4-5万次读写操作。
TC除了支持Key-Value存储之外，还支持保存Hashtable数据类型，因此很像一个简单的数据库表，并且还支持基于column的条件查询， 分页查询和排序功能，基本上相当于支持单表的基础查询功能了，所以可以简单的替代关系数据库的很多操作，这也是TC受到大家欢迎的主要原因之一，有一个 Ruby的项目miyazakiresistance将TT的hashtable的操作封装成和ActiveRecord一样的操作，用起来非常爽。
TC/TT在mixi的实际应用当中，存储了2000万条以上的数据，同时支撑了上万个并发连接，是一个久经考验的项目。TC在保证了极高的并发读写性能 的同时，具有可靠的数据持久化机制，同时还支持类似关系数据库表结构的hashtable以及简单的条件，分页和排序操作，是一个很棒的 NoSQL数据库。
TC的主要缺点是在数据量达到上亿级别以后，并发写数据性能会大幅度下降，NoSQL: If Only It Was That Easy提到，他们发现在TC里面插入1.6亿条2-20KB数据的时候，写入性能开始急剧下降。看来是当数据量上亿条的时候，TC性能开始大幅度下降，从TC作者自己提供的mixi数据来看，至少上千万条数据量的时候还没有遇到这么明显的写入性能瓶颈。
这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考
3、Flare
TC是日本第一大SNS网站mixi开发的，而Flare是日本第二大SNS网站green.jp开发的，有意思吧。Flare简单的说就是给 TC添加了scale功能。他替换掉了TT部分，自己另外给TC写了网络服务器，Flare的主要特点就是支持scale能力，他在网络服务端之前添加了 一个node server，来管理后端的多个服务器节点，因此可以动态添加数据库服务节点，删除服务器节点，也支持failover。如果你的使用场景必须要让TC可 以scale，那么可以考虑flare。
flare唯一的缺点就是他只支持memcached协议，因此当你使用flare的时候，就不能使用TC的table数据结构了，只能使用TC的key-value数据结构存储。
二、满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB
面向文档的非关系数据库主要解决的问题不是高性能的并发读写，而是保证海量数据存储的同时，具有良好的查询性能。MongoDB是用C++开发的，而CouchDB则是Erlang开发的：
1、MongoDB
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似 json的bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几 乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。
Mongo主要解决的是海量数据的访问效率问题，根据官方的文档，当数据量达到50GB以上的时候，Mongo的数据库访问速度是MySQL的 10倍以上。Mongo的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万－1.5次读写请求。对于Mongo的并发读 写性能，我（robbin）也打算有空的时候好好测试一下。
因为Mongo主要是支持海量数据存储的，所以Mongo还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储，但我也看到有些评论认为GridFS性能不佳，这一点还是有待亲自做点测试来验证了。
最后由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎，很多项目都考虑用MongoDB来替代MySQL来实现不是特别复杂的Web应用，比方说whywe migrated from MySQL to MongoDB就是一个真实的从MySQL迁移到MongoDB的案例，由于数据量实在太大，所以迁移到了Mongo上面，数据查询的速度得到了非常显著的提升。
MongoDB也有一个ruby的项目MongoMapper，是模仿Merb的DataMapper编写的MongoDB的接口，使用起来非常简单，几乎和DataMapper一模一样，功能非常强大易用。
2、CouchDB
CouchDB现在是一个非常有名气的项目，似乎不用多介绍了。但是我却对CouchDB没有什么兴趣，主要是因为CouchDB仅仅提供了基于 HTTP REST的接口，因此CouchDB单纯从并发读写性能来说，是非常糟糕的，这让我立刻抛弃了对CouchDB的兴趣。
三、满足高可扩展性和可用性的面向分布式计算的数据库：
面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样，它首先必须是一个分布式的数据库系统，由分布在不同节点上面的数据库共同 构成一个数据库服务系统，并且根据这种分布式架构来提供online的，具有弹性的可扩展能力，例如可以不停机的添加更多数据节点，删除数据节点等等。因 此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java开发的：
1、Cassandra
Cassandra项目是Facebook在2008年开源出来的，随后Facebook自己使用Cassandra的另外一个不开源的分支，而开源出来 的Cassandra主要被Amazon的Dynamite团队来维护，并且Cassandra被认为是Dynamite2.0版本。目前除了 Facebook之外，twitter和digg.com都在使用Cassandra。
Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会被复制到 其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情，只管在 群集里面添加节点就可以了。我看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。
Cassandra也支持比较丰富的数据结构和功能强大的查询语言，和MongoDB比较类似，查询功能比MongoDB稍弱一些，twitter的平台架构部门领导Evan Weaver写了一篇文章介绍Cassandra：http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/，有非常详细的介绍。
Cassandra以单个节点来衡量，其节点的并发读写性能不是特别好，有文章说评测下来Cassandra每秒大约不到1万次读写请求，我也看到一些对 这个问题进行质疑的评论，但是评价Cassandra单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是n多个节点构成的系统，其并发性能取 决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。
2、Voldemort
Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统，Cassandra来自于Facebook这个 SNS网站，而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了n多的NoSQL数据库，例如 Cassandar，Voldemort，Tokyo Cabinet，Flare等等。Voldemort的资料不是很多，因此我没有特别仔细去钻研，Voldemort官方给出Voldemort的并发读 写性能也很不错，每秒超过了1.5万次读写。
从Facebook开发Cassandra，Linkedin开发Voldemort，我们也可以大致看出国外大型SNS网站对于分布式数据库，特别是对 数据库的scale能力方面的需求是多么殷切。前面我（robbin）提到，web应用的架构当中，web层和app层相对来说都很容易横向扩展，唯有数 据库是单点的，极难scale，现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一条很好的方向，这也是为什么现在 Cassandra这么热门的主要原因。
如今，NoSQL数据库是个令人很兴奋的领域，总是不断有新的技术新的产品冒出来，改变我们已经形成的固有的技术观念，我自己（robbin）稍微了解了 一些，就感觉自己深深的沉迷进去了，可以说NoSQL数据库领域也是博大精深的，我（robbin）也只能浅尝辄止，我（robbin）写这篇文章既是自 己一点点钻研心得，也是抛砖引玉，希望吸引对这个领域有经验的朋友来讨论和交流。
从我（robbin）个人的兴趣来说，分布式数据库系统不是我能实际用到的技术，因此不打算花时间深入，而其他两个数据领域（高性能 NoSQLDB和海量存储NoSQLDB）都是我很感兴趣的，特别是Redis，TT/TC和MongoDB这3个NoSQL数据库，因此我接下来将写三 篇文章分别详细介绍这3个数据库。
成功产品经理的七个特征
2010年8月25日
没有评论
一个成功的产品经理必然是一个沟通专家。产品经理是一个跨团队的协调者催化剂，他需要与各种各样的产品干系人进行沟通来推动或者促进产品工作。这就要求了产品经理能够高效表达或者倾听。
在一个跨团队的产品团队中。存在专业的技术人员和专业的市场人员，这两种人思考问题和表述问题的方式完全不同。产品经理需要用一种他们听得懂和能够理解的表达方式进行沟通。
2：非职权的影响力
很多产品经理和他的产品团队成员并不具有职能上的上下级关系。产品经理甚至不具有对产品团队成员的考核权利。但是产品经理作为一个需要对产品的市场成功负责的职务，必然需要各种专业人员的帮助才能成功。如何去影响这些产品团队成员以及产品的干系人。都要求产品经理具有很强的影响力。大家可以去参考《影响力》这本书。
3：学习能力
如今的市场是一个快速变化的市场，技术的发展日新月异。一个只依赖工作经验的产品经理是无法胜任的。这就要求了产品经理必须具有快速的学习能力，及时这些新兴事物跟产品经理之前的知识架构没有任何联系。
在这里，经验不是一个优秀产品经理的充分条件。一个能够快速学习的产品经理要远远优于一个具有工作经验的产品经理
4：商业分析能力
成功的产品经理必须能够掌握商业的游戏规则。他们理解如何分析市场机会，差异化竞争，制定产品战略，定价和促销，盈亏分析等等。
5：热爱他的产品
一个成功的产品经理需要象对待他的孩子一样对待产品。
他们是产品的设计师和体验师，不断的设计体验改进自己的产品。为产品的成功做出自己最大的努力。
6：关注细节
细节决定成败，有效的产品经理需要贯穿产品的各个阶段。他们不仅仅要关注产品的功能，市场，还要关注产品的开发，测试，发布等细节。
7：产品管理的基本技能
一个成功的产品经理需要具有产品管理需要的基本技能。包括但不限于编写MRD，PRD。执行竞争力分析，制定产品的RoadMap，定义产品功能，优化用户体验，定义产品的界面设计等。总之你要很强大。
马化腾在腾讯产品峰会上关于产品设计和开发的内部讲座
2010年8月25日
没有评论
背景：pony是公司的首席体验官、首席产品经理。这次在产品峰会上pony将自己平时经验的积累与大家交流，体验较细。这次分享研发管理部，设计中心整理了些材料。主要的案例是qqmail和qq影音的内容。以此为demo来讲解。
pony的讲解主要分为三大部分：产品设计、产品运营、交互设计。
在开场首先提到，互联网同类产品竞争激烈，只有抓住用户的心才能持续走下去。产品要赢得用户的心，要从一些小的点来赢得用户。
第一部分：产品设计
这个部分，感受最深的是两个词：核心能力、口碑。这部分还着重提到了pony对产品经理素质、开发人员心态的期望。
核心能力
任何产品都有核心功能，能帮助到用户，解决用户某一方面的需求，如节省时间、解决问题，提升效率等等。
很多产品经理对核心能力的关注不够，不是说完全没有关注，而是没有关注到度。核心能力不仅仅是功能上也，也包括性能上的。对于技术出身的产品经理，特别是做后台出来的，对于性能的关注，如果自己有能力、有信心做到对核心能力的关注，肯定会渴望将速度、后台做到极限。现在很多产品都没做好，一抓问题一大堆。如，前阵子网页速度优化，好多东西可以优化，一下提速好多，之前不知道都做什么去了。之前用户忍受了很久，同时浪费时间、浪费我们的资源。不抓，都没人理，很说部过去。要在性能方面放入更多精力。
谈到核心的能力，首先要有技术突破点。如做影音的时候，不是要做人家有我也有的东西。以前公司做的你有我有的东西，总是排在第二第三，虽然也有机会，但缺乏第一次出来亮相失去用户的认同感。
第一要关注你的产品的硬指标，在设计和开发的时候要考虑到外部会将对它与竞争对手做评测。如播放能力，占用内存。qq影音的核心性能和速度直接超越暴风影音。这样就能看到用户很多的好评和口碑。所以之后如果qq影音不出大问题，发展的势头将会很好。
硬指标评测cpu占用、高清加速，当时也有很多发展方向，如网络播放啊、交流啊、分享啊，也是思路。现在都砍掉，就是要做播放器，是用户的需求，纯用户需求不需要多少钱的。高清的，并不是很多人需要的，但是是高端用户的需求（这个后面口碑创造会再提到）。只有硬指标满足了，用户说，我这个破机器，暴风影音不能放，qq影音能放。这句话说出来，这样口碑就出来了。用户知道你行，差异化出来了。口碑要有差异性。
核心能力要做到极致。要多想如何通过技术实现差异化，人家做不到，或者通过半年一年才能追上来。
如，用户总评论qq的时候说用qq唯一的理由是传文件快，有群。于是这些就是我们的优势，那我们就要将优势发挥到极致。我们需要更加深入的去想，要想到要不要做传输速度、中转啊。离线传文件在邮件体现就是一个中转站，超大文件，也不难，就是要去做。产品部门很快的去做，去测试。用户用的量也不一定大，但几个月用一次，口碑就来了。用户会说，我要传大文件，找了半天找不到可以传的地方，万般无赖之下用了很烂的qqmail，居然行了。于是我们的口碑就来了。做了很多测试、逐步放量，看变化，因为到期就删掉，成本也没提升多少。
要做大，要考虑到如何做到极致让人家想到也追不上，我们这么多年在idc上的功力不能浪费，需要我们去做。高速上传、城域网中专站，支持高速地上传……，又发现问题，如不在邮件，在im做怎么体验，这个我们在后面要逐步考虑到做起来。我们的目的是要让用户感到超快、飞快，让用户体验非常好。这些都需要大量技术和后台来配合。
产品的发展都需要产品经理来配合。现在我们产品经理有是做研发出身的不多。而很多产品和服务是需要大量技术背景的，目前我们希望的产品经理是非常资深的，做过前端、后端开发的技术研发人员晋升而来的，刚毕业的人员来做产品经理很人担心。好的产品最好交到一个有技术能力的、有经验的产品人员手上，会让大家更加放心。如果产品人员太烂，让很多兄弟陪着干，结果发现方向错误是非常浪费和挫伤团队士气的。
产品最难的是订优先级和先后次序。要看哪个是用户最核心的。功能好不好不是说有用户用了，用量多少了，写个报告统计下流量证明是好。这个是很错误的，好不好要看用户是不是要用这个功能，用户要用的实时出现。腾讯很多产品经理的激情还不够，做出来的产品比较大路货。虽然挑剔不出很不对的东西，但放出去用户也没有感觉，最后就不了了之。pony有时候很痛心，希望大家在产品设计之初就想的透彻一点。产品经理需要投入更多的关注度，关注度不一样，结果出来的很不一样。
口碑
做产品要做口碑，要关注高端用户、意见领袖关注的点。以前的思路是抓大放小，满足大部分小白用户的需求。但是高端用户这块是真正可以拿口碑的。
如何提高口碑，看最高端用户的关注，这个是在基础功能比较好的情况下考虑。如邮件搜索啊，rss啊，这些是很炫的用户会在博客和论坛里面提及的。做起来也不难，在有能力的情况下保证。在产品已经成型的情况下，要考虑到，对高端用户的心态要不一样。如果想要获得高端用户的口碑，还需要在产品的设计上大气些。如，让用户在我们的qqmail上使用别的邮箱的地址，而不带任何自己qqmail的尾巴。之前我们做的时候不会自动保存别的邮箱的地址，自己心里打个小九九，让别人不方便使用外部邮箱地址，好使用我们的。这些小九九，高端用户都是看的出来，反倒不好。所以要改掉，要做到真正的方便到用户。 改变用户习惯要让他信任你，改变有过程的，需要通过我们的努力让用户慢慢改过来。如，关闭数字帐号，发现很多bug，拍拍都不知道改。如，独立密码，之前不是双密码，而是改整体密码。
需要满足高端用户，让他不要怀疑你、bs你。如浏览器到兼容，可能你会考虑很多浏览器的覆盖率不高而不去做，但在高端用户来看，这是个态度问题，如果你的产品连这个都没考虑，其他的我就都怀疑了。你这个产品团队的意识好不好。再如同文件夹是否对齐，是否会引起杀毒软件的报警，都是小事但要关注。
个性化服务，并不是大众化服务，也是拿口碑的。
一个产品在没有口碑的时候，不要滥用平台，如要im带呀，投入营销资源呀，要marking联系pr公司投放广告呀，广告位提要求……等着人家砍，想一半也够了。产品经理精力好像分布的很好50%产品、30%营销、 20%……。如果你在基础处控制的好，也可以。但90%的时候第一点都做不好。如果你的实力和胜算不到70-80%，那么把精力放在最核心的地方。在已经获得良好口碑，处于上升期的产品才考虑这些。
产品经理关注最最核心、获得用户口碑的战略点，如果这块没做透，做营销只是告诉用户过来，失望，再花更多的精力弥补，是得不偿失的。当用户没有自动在增长（用户会主动给朋友推荐来使用我们的产品的时候），看着用户的增长，否则不要去打扰用户，否则可能是好心办坏事。这个时候，每做一件事情，每加一个东西要很慎重的考虑，真的是有建设性的去增加产品的一个口碑。当用户口碑坏掉后，再将用户拉回来很难。
加功能，在管理控制功能上也要有技巧。在核心功能做好后，常用功能是要逐步补齐的。产品在局部、细小之处的创新需要永不满足。作为一个有良好口碑的产品，每加一个功能都要考虑清楚，这个功能给10%的用户带来好感的时候是否会给90%的用户带来困惑。如果有冲突的要聪明点，分情况避免。每个功能不一定要用的多才是好，而是用了的人都觉得好就是好。
做产品开发的时候需要有较强的研发机制保证，这样可以让产品开发更加敏捷更加快速。有些需求，提一下都可以得到很快反应。 qqmail也会每天排好规划，为什么能很快反应，如文件加锁。有些产品做个东西写ppt、做汇报……，人家顺手就做了。很多产品不敏捷，大家要敏捷点、就算是大项目也要灵活。不能说等3个月后再给你个东西看，这个时候竞争对手都不知道跑到好远了。
开发人员的心态要关注产品，不要是公事公办的态度。你要知道用户、同行会关注你的产品，在这种驱动下开发人员要自动去完成。不能说什么都要产品做好后，流水线样的送过来我才做。开发人员要参与，40-50%左右的产品最终体验应该是由开发人员决定的。产品人员不要嫉妒有些工作是是开发人员设计的，只有这样才是团队共同参与的。如果都是产品想的就完蛋了，那么这个team做这个产品没有什么机会，必然会产生产品迭代慢的效果。这样一个格局太不行了。
运营式管理
这个部分感受最深的一个词：天天用。这部分还谈到了pony眼中产品经理的一些基本要求。
我们的产品不是单机版，需要有强的用户感和技术功底外，很重要的是服务。我们要关注很多很复杂的内容，如架构啊，应用啊，产品需要有更好的架构，这个是需要花很多精力，常态下可能看不出来。所以需要高层从kpi上考虑。这个是考功力，谁做的好，总办领导是看得到的。设计的好的架构不会手乱脚乱。如把核心的东西做成组件模块分发。
发现产品的不足，最简单的方法就是产品天天用。天天去看，去论坛，去博客、去订阅。产品经理要敏感点，找出你的产品不足之处。有的产品经理说找不出来很奇怪，上线的时候坚持三个月天天用，问题是有限的，一天发现一个，解决掉，这样慢慢的已经开始逼近你那个很有口碑的点了。不要因为工作没有技术含量就不去做，很多好的产品都是靠这个方法做出来的。对于高层来说，不仅仅是安排下面的人去做就可以了，一定要自己做。这些都不难，关键要坚持。意识要提高。你要做到每个周末，都心痒痒要去做。心里一定要想着，这个周末不试，肯定出事。这样坚持，到一个产品基本成型，就可以去看下个产品了。
从哪个地方找，论坛啊、博客啊，rss订阅啊。高端用户不屑于去论坛提，在博客提，需要产品经理自己去追出来。如qqmail、影音的产品经理自己去查、去搜，然后主动和用户接触，解决，有些确实是用户搞错了，有些是我们的问题。产品经理心态要很好，希望用户能找出问题我们再解决掉。哪怕再小的问题解决了也是完成一件大事。有些事情做了，见效很快。运营方面要天天去看的，产品经理要关注多个方面，比如说你的产品慢，用户不会管你的idc烂或者其他原因，只是知道你慢。产品经理要全面，服务器端哪个方面的问题能找出来。跟踪用户定位问题。如果pony都能搜索到的问题，没看到产品经理出现，那么就是你没做到位。
交互设计
交互要求我们细致，视觉简洁清爽。
产品经理要想到自己是个挑剔的用户，想像自己是个笨用户，复杂的看不懂。
产品人员的精力有限，交互内容很多，所以要抓最常见的一块。流量、用量最大的地方都要考虑。规范到要让用户使用的舒服。要在感觉、触觉上都有琢磨，有困惑要想到去改善。如鼠标少移动、可快速点到等等。
像邮箱的一个按钮“返回”放在哪儿，上线测，放右边还是左边，大家都会多放琢磨，怎么放更好，并上线尝试，现在的方案折中比较好。如输入邮箱密码出错，输入框内的内容select上，不用用户清楚可以直接输出。这些都是对用户体验的优化。
如对同个用户发信，在此用户有多个邮箱的情况下会默认选最近用的一个帐号。这些需求都小，但你想清楚，用户就会说好，虽然用户未必说的出好在哪儿。
产品的使用要符合用户的习惯，如写邮件的时候copy东西，更多人习惯用键盘来操作。虽然有些技术难度，但也可以解决。交互，对鼠标反馈的灵敏性，便捷性。
不强迫用户，如点亮图标。如qqmail，不为1%的需求骚扰99%的用户
操作便利，如qq音乐，新旧列表，两者都要兼顾到，如qq影音的快捷播放，从圆形到方形，最后因为影响性能而放弃。
美术、淡淡的，点到即止，如qqmail，qqmail在ui上的启发，不用太重也能做的很好。后来用在大量的产品，如hummer、影音。有图案和简洁不矛盾。
重点突出，防止不必要的低龄化，还提到了一些内容，如产品成功关键点等等，这些在pony的ppt上有，没有记下来，大家可以在之后腾讯峰会吧（http://km.oa.com/group/forum）直接看pony的ppt。
最后pony谈了一下有些产品的态度问题——态度很好，不解决问题。只做表面功夫，与其花一段时间写个长长的报告，不如实实际际的去解决问题。
外部也有很多优秀的产品可以学习，学习不是学皮毛，学样子，要学会。
外部可以学习的优秀产品，web类的，google、yahoo、facebook、apple，非web类的没有记录下来。
总结一下：
1、核心功能要做透，做的人家追不上，自己的优势要尽量的发挥；
2、产品口碑要建立，要关注高端用户，要调整自己心态；
3、敏捷、快，产品迭代要快，快速实现、快速响应，要做到真正的迭代；
4、产品人员要全面，要能找出核心需求，要关注技术（架构、服务是不是好），要关注产品（天天用），要关注用户（还需要出去寻找问题并解决）；
5、开发人员心态要好，要有参与感，不要被动的等；
6、交互设计简洁，关注要点，当自己是个挑剔的、笨的用户；
7、想办法利用公司的资源，如pony等人都是大家的公共资源，要争取到pony对自己产品的关注，会给你的产品带来很多好的指导和创意。（这个不是pony说的，是后来jeff提到的，不过很实在，pony做过这么多的产品，有这么好的产品感觉，如果给你的产品提出建议，是对产品很大的帮助）
本文转自互联网，转载的转载文章，原出处不详！
“最牛家访老师”的意外思考
2010年8月21日
没有评论
今晚贵州台一档谈话节目采访了网络上很火的最牛家访老师，高贵华老师的崇高我不想多说，但节目中请来的几位学生却让人不得不去思考一些另外的问题。一位叫莫显梅的女孩因为家里拿不出钱供她上学，她不得不为了每周能节省7.5元而天天吃家里的咸菜和辣椒，这样的食物她坚持了一年多只是为了凑够学费。看完这一段真不知道该怎么说，教育资源的严重不平衡和教育机会的不平衡让这些处在底层的人们怎么去改变命运？当贪污腐败的新闻已让人麻木的时候，每每看到这样的资讯，多多少少让人内心还是很心酸。
分类: 黑白盒子
最新评论