互联网落伍者

在优酷上搜索Google的Zeitgeist 2011得到的结果

落伍者 — Wed, 18 Jan 2012 23:48:05 +0800

看看世界上的人们都在Google’s 2011 Zeitgeist上搜索什么:
http://googlezeitgeist.com

下面是Youtube上的Google Zeitgeist 2011完整版，BGM是: “Sooner or Later” by Mat Kearney，制作：Whirled Creative，导演：Scott Chan

另外我从优酷上也试着搜索了一下这个视频，关键字是google zeitgeist 2011，结果很有趣，如下：

Google Zeitgeist 2011 – Year in Review(中文字幕和谐剪辑版)	发布:17天前	播放:443,645
Google Zeitgeist 2011 – Year in Review (Edited)	发布:1月前	播放:2,493
Google Search Zeitgeist offline in Shanghai	发布:2年前	播放:289
Google Zeitgeist 2011(中英字幕)	发布:13天前	播放:178

很显然，第3条不是我们想找的结果，无论从名称上，还是发布时间上看。
在我们想要的结果中，可以发现，发布时间最早（第2条）与最晚（第4条），其播放次数都远远不如第1条，这也许是因为第1条刚好把握了发布的最佳时间？于是我瞅了一眼日历，发现17天前刚好是2012年的元旦；也许就是那一天，优酷的编辑刚好发现了这个视频，觉得比较应景，就顺便把它推荐到了首页？不晓得是不是这样，但至少提醒我，有些东西，考虑一下时间是不是最合适是很重要的。
3个正确结果的名称上，虽然都有括号，但我们能很容易看出，对于英文标题的视频，中文说明显然更容易吸引到目光。
同样是中文说明，那个“中文字幕和谐剪辑版”是不是更吸引人？这是因为我们从说明文字的多少，可以感觉出作者所花心思的多少。于是我点开看了一下，确实如此：第1条视频有一段说明，而第4条视频没有任何说明。

最后把优酷上第一条视频的说明贴给大家看：

这几天才想起来想在人人上给朋友分享下，但再找的时候都是各种打不开（你懂得）。看过一个中文字幕版的也是到一半就看不了了。于是就自己做了一个字幕版+和谐剪辑的，借鉴了另一个中文版的一些字幕，感谢。。。。。。纪念2011，这是最坏的时代，也是最好的时代。

Youtube:

Youku:

谈谈点点网的时间线设计

落伍者 — Wed, 18 Jan 2012 22:54:48 +0800

点点（diandian.com）是一个轻博客社区。用许朝军的话说，国内社会化媒体经历BBS、BLOG、SNS、Twitter等发展阶段后，用户习惯将趋于碎片化内容和高质量整合内容的双轨道发展。

点点网基于几大特点：

“轻博客”概念：抛弃了传统博客繁冗复杂的形式和单一的产品体验，点点网采用简洁的设计哲学，杂志设计风格的模板体验和自定义的系统配合为用户带来视觉冲击；
支持一个账号下建立多个主题博客：轻博客的概念在于用户可以完全根据自己的兴趣、爱好、习惯等生活各个维度编辑主题内容，每一个主题都可以形成独立的博客页面，并且支持多人编辑、分享功能。
投稿功能：每一个博客页面都开设了“投稿”功能，如果每一个博客就是一本精美的杂志，那么基于拥有同样兴趣爱好的网友就是这个杂志社的创作者。投稿功能将内容的编辑和创作完全开放给每一个志同道合的网友；
完全的内容和兴趣导航模式：传统模式基于人际交互传播，强调的主体是个人，而点点网打破了人的局限，将每一个人关注的内容变成交互和传播的主体，成为一个全新的、真正致力于“高质量内容发布和传播”的轻博客社区。

这里写一些对点点网的时间线（也就是登录点点后，在“首页”中显示的“动态”）设计的想法：

目前写文章有自动摘要功能，不管我写多少字，系统会自动截取前面一定长度的内容做摘要，超过部分会显示“未完，继续阅读”。但是，有些文章字数虽然少，换行却很勤快，所以在我的时间线上仍然占了很大一片（一屏的样子）。这让人读起来很不方便，能不能提供功能，让这些文章的摘要短点儿？或者不按字数截，而是按高度截？BTW:有朋友给我留言说，写文章时用分页功能就能控制摘要字数了。
既然是摘要，那不如给作者一个写摘要的功能，而不是让系统自动截。应该有不少文章，需要写一个好的摘要来吸引人。当然，写作时多一个摘要框就显得不够“轻”博客了，那能不能在字数或高度少时隐藏摘要框，而字数多或高度太高时才提示作者加摘要呢？
也许@许朝军大大骨子里是追求“轻”的，不想给作者任何写摘要的压力，那就干脆把时间线上每篇文章的高度交给读者来定义好了嘛！BTW，我觉得300个像素已经够高了。
也许许大会说，这里不是微博，时间线上并不是为了获取轻博客文章的实时发表信息，主要目的是为了让人获得自己关注的轻博客作者的最新文章，从而进行互动。如果真是这样，那就列出所有关注的人，以及他们的3～5篇最新文章的title就OK喽！

对于一个用惯了blog的人，也用惯了微博的人来说，用点点就是这样，看不懂时间线的设计，也看不完时间线的内容，更看不惯忽长忽短莫名其妙的摘要。

点点的“自动发布列表”

落伍者 — Tue, 17 Jan 2012 08:52:29 +0800

原来在点点上写文字贴的时候，右侧的“加入到自动发布列表”，就是定时发文的意思啊，那为什么不叫定时发布呢？

试用了一下。点选右侧的“加入到自动发布列表”后，文章不会马上发布，而是被放在了一个列表中，只有作者本人可以看到。而这个列表还可以加入更多文章，同时，用户能够进行这样的设置：从8:00到22:00之间，发布2篇文章。这意思就是说，你如果来了兴致，可以一下子写很多文章，并让他们排队发布，每天只发布2篇。而对读者来说，就好像你每天都能抽出时间来写轻博一样。

可是，为什么不用“定时发布”这样的功能？而只是提供自动发布的功能？

如果自动发布，那究竟是什么时候？是在线用户最多的时候？还是最少的时候？

假如是最多的时候，那我的自动发布的文章被别人看到的机会就很大，这也算帮我推广了；

假如是最少的时候，那这个列表就像一个缓冲池，可以使点点的更新频率变得很稳定，而这似乎能让点点更受搜索引擎的关注。

也许哪个都不是，也许点点打算刚开始在人少的时候发布，吸引搜索，等用户量上来了，再在人多的时候发布，提高用户的互动性。

不过不管怎样，这都让我想起了麦田和韩寒，也许韩寒自己就有这样的一个自动发布列表，提前写好文章，放进去，合适的时候就拿出一两篇给大家看。

轻博客的时间线

落伍者 — Mon, 16 Jan 2012 15:02:41 +0800

在点点上关注了36氪，本想能读到一些网站外的内容，但是看来我想错了。这个帐号只是把网站上已经发布的内容搬到点点上来，而且一下子发布了很多文章，结果就是我的时间线上只有36氪了，而且全都是我在我的rss阅读器上看过的文章。

轻博客虽然可以像微博一样关注别人，但这个关注究竟是为了什么？

微博上关注了某人后，他的140字信息就会出现在我的时间线上。关注的人越来越多以后，时间线上也会逐渐丰富起来。因为关注人群的多样性，时间线上的信息也基本始终保持在流动、刷新的状态。但是即使如此，每个消息只有140字，这让读者能够很快获知每条消息的重点，并且选择其中最有价值的进行互动。

在轻博上就不一样了。关注某人后，对方的整篇文章就全部出现在时间线上了。且不说这么多文字如何占用注意力，单单是一两个关注，就可能把整个时间线挤满，这可是和我最初的愿望不一样——我想了解很多人，看看他们都在干什么，而不是只有一两个人。

所以我决定取消关注36氪了，假如点点再不作出什么改变的话——比如只把我关注的人的前140个字显示出来，并且显示地紧凑点，就像微博那样！！

[译文]首先满足客户，然后让他们高兴起来（二）

落伍者 — Sun, 15 Jan 2012 20:15:10 +0800

However, when companies attempt to add delights to a product or service without first satisfying the basic needs and expectations of customers, the extra add-ons have the opposite effect. When customers see a company putting effort into neat/cool/unnecessary features or benefits but ignoring basic fundamental aspects, it implies that the organization is either (a) trying to cover up their faults, or (b) oblivious to customer needs. Either way, it does not send a positive message to the market and is likely to backfire.

Simply put, you can not exceed the customer’s expectations without first meeting them. Furthermore, to paraphrase Dan Pallotta (from his excellent blog post I Don’t Understand What Anyone Is Saying Anymore), it is so rare that a customer actually has their expectations met, much less exceeded — a problem caused by companies not having any idea of what the customer’s expectations are in the first place, or forgetting basic tenants of customer service. This lack of customer understanding can have disastrous results.

然后，当公司尝试给产品或服务添加亮点，而没有首先满足客户基本的需求和期望时，这些额外的工作会有相反的效果。当客户看到一个公司把精力放在简洁/酷/不必要的特性上却忽略基础的方面，这说明这个组织要么正努力掩盖他们的失误，或者正在忽视客户需求。不管是哪个，这都没有给市场发出积极的信息，并且很可能出意外。

简单地说，你不能不首先满足客户期望，然后再超越这些期望。更进一步，解释Dan Pallotta说的（参考他的精彩博文《我再也不能理解人们说的是什么》），完全满足一个客户的期望是很罕见的，更不用说超越——要么把对客户期望完全没有思路的公司的问题放在首位，要么忘记客户服务的基本承担者是谁。这种对客户理解的缺失会造成很糟的结果。

[译文]首先满足客户，然后让他们高兴起来（一）

落伍者 — Sun, 15 Jan 2012 15:38:02 +0800

英文原文：

If you want to be a bad product manager, hope that cool unexpected aspects of your product or service will make up for deficiencies in other areas. Sure, your product has some flaws, but it’s easier to add some neat features than fix the parts that are broken. Enough attention-grabbing items will draw attention away from the problem areas, and the positive feedback you get from the nice-to-haves will make people forget what’s missing.

If you want to be a good product manager, satisfy customers first before attempting to delight them. There is a lot of talk lately about how to “delight the customer,” and organizations are attempting to do this through exceptional customer service or unexpected product features. This likely driven by an attempt to generate buzz and goodwill by customers raving about these delights, often on social media. When done well and appropriately, the benefits of these delighting product aspects can truly differentiate an offering and an organization.

译文：

如果你想成为不好的产品经理，那就寄希望于你的产品或服务上突然增加的酷的东西能弥补其他方面的不足吧。当然，你的产品有一些瑕疵，但增加一些简洁的特性总比修复坏掉的部分来的容易。足够多的能抓住眼球的东西，是可以把注意力从有问题的区域引开的，并且你从那些好的特性中收到的肯定的反馈，将使人们忘记什么东西不见了。

如果你想成为好的产品经理，那就在让客户高兴之前，先满足他们。后面会有很多关于如何“让客户高兴”的讨论，并且很多组织正在尝试通过优秀的客户服务或出奇的产品特性来做到这点。通常在社交媒体上，人们欣喜若狂地讨论这些亮点，可能正是这种制造口碑和声誉的尝试驱使产品经理们这么做。当做的恰好时，这些令人高兴的产品特性的好处就能真正地区分出一个谢罪礼和一个组织。

产品经理要多问“为什么”

落伍者 — Thu, 15 Dec 2011 16:15:11 +0800

产品经理一定要追求细节，完美的细节。

曾经有一款产品，有这样的功能：一个用户登录到系统中以后，按部就班进行各种工作；当工作处理的数据发生问题时，产品后台通过逻辑运算把出错的信息返回给用户。按很多人的理解，这个返回信息的部分应该就是一个messagebox，或者一个alert这么简单。

开发工程师可以这样去组织思路，但产品经理却不行。后者的思路应该是：

出错的信息应该如何组织？标点如何加？才能让用户更容易读懂？

出错信息应该在什么时机弹出来，才更能让用户注意到？

出错信息出现的概率有多大？会不会太频繁，像中病毒了一样？

出错信息应该显示多久？让用户手动关闭？还是5秒钟后自动关闭？

如果自动关闭的话，假如用户当时AFK，那怎么办？

假如总是出现相同的出错信息，用户会想怎样？

出错的提示应该通过弹出对话框提示？还是气泡？还是任务栏闪动？

如果出错的内容太多怎么显示？

如果出错内容中包含一些特殊字符，应该怎么办？

用户看到出错信息后，是否应该提示用户如何做后续处理？

假如用户正在全屏工作，如何进行提示？

假如一个流程中遇到了5个错误提示，是逐个显示？还是凑齐了统一在一起显示？

假如出错时，用户还有未保存的工作怎么办？

出错信息只需要提示一下？还是需要保存下来让用户查看？

是给用户提供保存的操作方式？还是自动保存下来？

是否应该把出错信息完整的保存在服务器上，供管理员查看？

……

等等等等，这样的考虑或许可以数上100条！

每一个产品经理或许都无法把所有问题考虑全，但保持这种“多问几个为什么”的好奇心，是把产品细节做好的条件。

也或许在产品实现过程中，根本没必要考虑太多的为什么，只需要抓住主要的。但究竟哪些是主要的？还是要用户说了算。如果抓不准用户怎么想，那自己就多想想！

微信：那些看起来有用，用起来却无用的功能，是怎么有用的？

落伍者 — Tue, 15 Nov 2011 17:14:13 +0800

有些产品有这样的功能：看起来新奇好玩儿，让人巴不得赶快试用一把；但试用完了发现，也就是好玩儿嘛，没什么实际用处！

微信的产品经理就设计了这样的功能，它的漂流瓶，摇一摇，初看上去，很新奇，用户能够随机获得一个未知的“陌生人”发来的信息，信息是好是坏也是未知的，许多的未知就让人充满了好奇。于是就忍不住下载下来用。

刚开始是充满惊喜的，因为有很多用户怀着同样的心理在使用微信，我也是其中一员。这个过程中，我找到一个留学日本的，一个留学澳大利亚的（留学生很多啊），一个生病住院的，还有一个在EA公司任职的员工，等等。大家刚开始都好奇地交谈，发文字，也发语音，但用不了一天，就无话可说了。慢慢地，发现这个所谓的陌生人交友，就是图个好玩儿，对我来说却没什么实际用处。

这让我也想到了QQ。oicq最初的时候，我也是怀着上网与陌生人聊天的心理开始使用的。渐渐地，用久了，真正留在QQ里的却是那些同学，熟人，而陌生人被一个不落地删掉了，就像微信一样。

但是，从产品角度讲，这个陌生人交友的功能是无用的吗？我看到很多人因为这些功能开始用了这些产品，然后又抛掉这些功能却又继续用着这个产品，所以，这功能看起来有用，用起来无用，但实际上还是有用的。

产品经理应该给产品加上一些新奇的功能，有时候并不是产品的核心功能，但却可以吸引大量的用户。而很多时候，只有有了足够量的用户，产品才能走上正轨。

敏捷软件的十二条原则

落伍者 — Sat, 15 Oct 2011 15:48:10 +0800

update1:关于working的含义，官方是“可工作的”，意在描述软件的一种状态，即能在一定程度上满足用户需求并可以正常运行。而在机械制造行业，working用来描述一个零组件的设计状态，凡是没有经过审核发布用于实际生产的零组件，都可以称为working part。而这篇宣言里的working，我想也包含了两层意思，一是可工作，二是仍然处于设计状态中的，没有最终确定的阶段性的一个版本。

在阅读这十二条原则的时候，我参考官方的中文翻译版本，对英文的原文有些不同的理解，于是对照如下（未加粗字体是官方的中英文）

We follow these principles:
我们遵循以下原则：

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
我们最要紧的事，就是尽快和不断地向客户交付有价值的软件，使他们满意。

Welcome changing requirements, even late in development.
欣然面对需求变化，即使在开发后期也一样。
Agile processes harness change for the customer’s competitive advantage.
为了客户的竞争优势，敏捷过程掌控变化。
为了客户的竞争优势，通过敏捷过程把控这些变化。

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
不断地交付可工作的软件，可以是一两周或者一两个月，周期要尽量短。

Business people and developers must work together daily throughout the project.
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
项目自始至终的每一天，业务人员和开发人员都必须通力合作。

Build projects around motivated individuals.
激发个体的斗志，以他们为核心搭建项目。
围绕积极的团队成员，构建项目。
Give them the environment and support they need, and trust them to get the job done.
提供所需的环境和支援，辅以信任，从而达成目标。
为了达成目标，给他们提供所需的环境和支持，并充分信任。

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

Working software is the primary measure of progress.
可工作的软件是进度的首要度量标准。
不断改进的软件是进度的首要度量标准。

Agile processes promote sustainable development.
敏捷过程倡导可持续开发。
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
责任人、开发人员和用户要能够共同维持其步调稳定延续。

Continuous attention to technical excellence and good design enhances agility.
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

Simplicity–the art of maximizing the amount of work not done–is essential.
以简洁为本，它是极力减少不必要工作量的艺术。
必须简洁，它是挖掘未完成的工作的一种艺术。（从另一个角度看，只有减少了不必要的工作量，才能发现更多需要完成而未完成的工作）

The best architectures, requirements, and designs emerge from self-organizing teams.
最好的架构、需求和设计出自自组织团队。

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
团队定期地反思如何能提高成效，并依此调整自身的举止表现。
团队定期反省怎样提高成效，并相应地调节和校正自身的表现。

从FireFox升级看敏捷软件（二）

落伍者 — Thu, 15 Sep 2011 15:52:21 +0800

面向互联网的软件研发有很多特点，例如：

1. 面向的用户不是某个人或组织，而是整个互联网的所有网民；

2. 软件的研发工作总是由研发单位自行发起，而不是软件的用户，所以不需要双方订立研发合同；

3. 软件的需求仍然由用户决定，但用户很多时候并不知道自己有哪些需求；

4. 用户多种多样，互联网应用水平参差不齐；

5. 不仅要满足基本的应用需求，还需要具有易用性，美观，轻量，易获取等潜在需求；

6. 最终用户无法直接面对面和研发单位沟通功能需求，而需要通过其他有效渠道进行反馈；

7. 用户需求多样，容易变化，部分有时效性，受舆论、文化、时事、金融等各行各业的影响，新需求层出不穷，总之非常复杂；

8. 大多数用户需求均来自个体，很少有专业领域的软件研发；

9. 同样需要专业的项目管理控制研发，在保证软件质量的前提下，协调周期、范围、成本等各方面的平衡；

10. 软件发布后，必须根据用户的反馈不断进行修正，并尽快发布新版本；

11. 软件需要适应多种系统平台；

12. 软件需要遵守法律法规；

13. 软件研发完成后，需要公开发布，无法保密，因而也很容易被拷贝；

14. 软件的公开发售以及开源组织、黑客组织的努力，使竞争门槛降低，促使大多数软件低价甚至免费；

15. 通常都要求用户接入互联网才可以获得与使用该软件；

16. 用户根据软件的实用性等因素判断是否愿意使用该软件，是否愿意遵守软件使用协议；

17. 软件的使用率不再由使用合同来保证，而需要通过专业的运营来维护；

18. 软件的价值不是简单地以软件的功能来衡量，而是以软件用户的数量、粘性等其他多种指标来衡量；

19. …。

这种状况使得软件研发必须积极面对需求变化，响应及时，快速迭代。

在敏捷软件的概念里：

个体和互动高于流程和工具

流程和工具是为了提高多人协作的效率和改善工作效率，降低沟通成本；而在实际工作中，当需求变化的不确定性导致很难提炼固定不变的流程，以及很难保证团队成员随时拥有统一熟练的工具时，或者流程经常被打乱，以及使用工具的操作时间大于直接沟通的时间时，成员个体的自动自发的积极态度和成员之间的快速互动就成了重点。如果想到流程和工具的设置，起初也是为了个体间能积极快速互动的话，就不难理解了。

工作的软件高于详尽的文档

编写文档通常要占用很大一部分时间。为了快速将可使用的软件交付用户，并使用户快速上手，编写一份详尽的使用文档并不是明智之选；相反，能让用户在无需阅读文档的情况下，就能一目了然地明白和掌握软件的使用方法，是软件是否可工作的一个重要目标。同时，这里的用户还包括团队内的测试人员等人。

客户合作高于合同谈判

没有研发合同，也没有使用合同，一切全凭用户自愿来使用软件。当出现问题时，解决问题的方法不是拿合同上模棱两可的词语互相推诿，而是和用户共同积极地面对问题，分析和解决掉。尤其对于一些非常热心主动帮助测试bug的用户，研发人员花费时间与其交谈，了解和确认bug，这是经常发生的事情。

响应变化高于遵循计划

互联网的信息快速传播的特性，使得网民对于信息的快速更新也表现出很多集体无意识、盲目崇拜、一窝蜂等无法预测的行为，而这些行为里潜藏了很多需求。把握这些需求和变化的能力极大地影响了软件的使用率，也就是软件的价值；因此，研发计划虽然仍然会有，但及时响应各种变化的能力却更为重要。

由此可见敏捷之重要。