硕鼠的博客站

1 、缘起

2011年11月，我们举办了“盛大云计算创意&开发大赛”，意在吸引国内的开发者来了解什么才是真正的、开放的、适合他们的云计算，因为此前“云计算”的概念在国内已经被严重误导——就连淘宝上搜云计算也能搜出一大把来——而我们认为，只有IaaS（平台即服务）才是真正的云计算。

为了让大赛更刺激更有趣，我们决定增设一个名为Cloud Jam的挑战赛，要求开发者在33小时内当场完成基于云计算的项目创意、开发、部署。其刺激之处在于对开发者的实力有要求，面对面的较量和对着屏幕较量是完全不同的感觉；有趣之处则在于，参赛者还可以现场寻找志同道合的人进行组队，隐有人潮人海觅知音的感觉。

最后，比赛的时间定在了2012年4月7日至8日，周末两天，33小时，现场组队，现场开发，现场评审，现场发奖。

2、 准备工作

其实决定办Cloud Jam的时候距离比赛只有一个月左右，时间非常紧迫。

我们最开始选择新浪微博的“微活动”作为活动平台，并在17StartUp、ITEye及iWeekend等社区进行宣传。结果后来才发现微活动的功能不够完善，很多必须的统计信息无法收集，于是又重新设计了比赛页面（http://v.to/cloud）并新增了抢座网的报名通道。事后来看，选择活动平台的失误还是对大赛造成了一定的影响。

在线上紧锣密鼓宣传的同时，我们也利用IT龙门阵、CTO俱乐部、PMI项目经理活动、Cloud Foundry等 线下活动进行了现场的宣讲，效果也非常不错。这也算是一种O2O吧？

为了让参赛者能够心情愉悦地参赛，我们准备了独立的WiFi网络，采购了大量的食品和饮料，甚至还准备了一些舒缓轻松的音乐和搞笑的视频短片，以便选手们短暂休息之需。

3、 激情33小时

Cloud Jam的开始时间为4月7日上午10点，但是早在8点半，就有一位参赛者从天津赶至会场；10分钟后，上海也有选手到场。

活动正式开始时，北京赛场已有30多位参赛者。比赛进行中，有些团队呼叫了场外支援，其中还有一位美女设计师……这是后话，暂且按下不表。

开场演讲由气场十足的范路（@LukeFan）主持，他向参赛者介绍了盛大云、盛大云计算创意&开发大赛、Cloud Jam规则与日程以及注意事项等。

随后是参赛者进行自我介绍。他们中有来自百度、雅虎、IBM等 大公司的，也有在校学生，当然还有一些创业者；其中多数人是程序员，前端技术以AIR和HTML5为主，后端则有PHP、JAVA和Ruby on Rails等，此外还有QA、PM、UI等 角色。

个人介绍之后，我们留了5分钟时间让参赛者以“组队”为上的进行沟通。事实再度证明，程序员其实一点儿也不宅，和陌生人“搭讪”的能力还是相当强的。 ^^

再接着就是有项目的人介绍项目，并且进行现场招募——这也是Cloud Jam有趣的地方之一，比赛结束后，很多人都很兴奋在这里找到了新的队友，而且有些项目就是在组队后才经过讨论最终确认成型的。

最后，北京一共组成了15个团队，最大的一个团队有5个人，而“个人团队”竟然有6个！

上午11点，各团队已进入开发状态。

下午一点半，来自五道口“奥巴巴”的比萨终于送到，所有参赛者再次聚到一起，一边吃饭一边交流问题，其乐融融的景象很有几分学校的感觉……

吃饭的同时，有团队开始呼叫场外支援，参赛者总人数再度增加。

期间发生了两个小插曲：一是有个团队使用C#，但盛大云没有提供C#的例程和相关文档，盛大云的志愿者斯文同学帮助解决了；二是有个团队的云主机重启后发生问题，于是我们找盛大云24小时在线客服进行解决，得到迅速解决，也让参赛者意外体验了一下盛大云的服务。

第一天晚上，一部分参赛者回家睡觉，而一些项目紧张或者离家比较远的参赛者决定留下来通宵工作。我们的志愿者也有一些留下来陪着大家，在办公室的沙发上过了一夜，也算是体验了一把创业的艰辛。

虽然当时不是很冷，但是为了大家的健康着想，我们还是要求所有人都睡觉，结果有个参赛者说，这是他最近一段时间睡的最早的一天了……当时已经过了凌晨12点。

我们真心地劝慰每一位朋友，身体永远是本钱，即使是创业，要是把身体拼垮了也是一件得不偿失的事情，身边已经有太多的案例。

好在第二天，所有参赛者都又生龙活虎地上场了。

经过一天一夜，大家都互相比较熟悉了，于是第二天出现了一些跨团队、跨项目的合作，这让我们非常开心 ，“友谊第一比赛第二”的口号在这个物欲横流的时代、在一群成年人身上得到体现，真的很难得。

评审环节从第二天下午3点开始。这个环节采用了类似比赛中少见的异地视频同步方式，上海和北京的参赛者同聚一堂，向其他参赛者和5位评委老师介绍项目并作现场演示，并回答评委提问，由评委和其他参赛者共同打分，最后选出优胜者。

这个时候，团队架构是否完整的差异就体现出来了。一些配置比较齐全的团队，比如产品经理、设计师、程序员等角色完备的团队，产品的完成度和完美度要更好一些，在讲解和演示时也更从容一些。相比之下，一些纯工程师组成的团队在讲解环节就吃了亏。

令人感动的是，有些参赛者在最后离场之前还主动和志愿者们一起清理了这两天留下的生活垃圾，相信这种细微之处的责任心，一定会在未来帮到他们。

4、 获奖项目

整体而言，很多项目都做得非常不错、非常有创意，参赛者也都竭尽可能地利用33小时做出尽可能完善的作品。当然，每次比赛总会有一些团队准备得更加充分，比别人更加努力，这也是比赛的意义所在。这并不是说那些没有得奖的项目不好，但总会有些人做得更好一些。

北京的获奖项目：

冠军：泡泡大对战。一个结合LBS的移动端游戏，让一定范围内的用户自动组合在一起，进行跨平台的点泡泡比赛。他们准备在这次比赛之后继续完善项目，并争取尽快将其推上AppStore，然后通过道具付费的方式实现盈利。值得一提的是，这个团队的成员在参加比赛之前很多人互不相识，却在比赛后走上了共同创业的道路。

亚军：猎影。一个使用AIR平台开发的跨平台MMORPG游戏引擎。团队利用两天时间完成了这个引擎，但是没来得及开发出第一款完整的游戏。这个项目向大家展示出，现在完全可以在各种移动平台上，做出以前只有在PC上才能实现的重型MMORPG游戏。使用这套引擎，再做一些设计，就可以得到一个完整的跨平台移动端MMORPG。这个项目也会在比赛之后，继续向着商业化的道路前进。

季军：云端纪念册。这是一个利用云存储技术，将某一类特定人群的某一类特定信息进行聚合的SNS项目。这是一个由年轻人组成的团队，他们中大部分人都是刚刚走出校门的学生，他们希望能将在校期间很多难忘的回忆记录下来，于是就做了这么一个项目。

上海的获奖项目：

冠军：V2EX。一个开源问答、论坛平台，这个项目提供了一套基于云的开源社交平台，任何人都可以使用这套源代码，在盛大云上部署出自己的社交平台来。V2EX和传统的论坛以及问答网站的差异就在于，可以在内容和用户比较少的时候得到很好的聚集，并通过一些算法和策略，自动提升内容的质量，让优质内容可以被更多的人看到。

亚军：Weipage，将微博内容进行聚集。微博中存在海量内容，但是用户希望找到自己想看的内容还是有一定难度，毕竟微博中的信息流是以人为单位的单向关注为基础。这个项目要做的就是将内容以事件分类，然后放置在其他网站上，让用户能够集中看到一类信息，而不用管这些信息是由谁产生的。

季军：Do Him，一个有趣的HTML5小游戏。在移动互联网时代，很多应用都不赚钱，特别是Instagram被成功收购之后，移动互联网应用不赚钱好像更加成为了天经地义的事情。不过Instagram毕竟只有一个，大部分应用和服务还是需要靠自己赚钱养活自己的，而最清晰的移动互联网商业模式莫过于游戏。HTML5游戏的最大优势就在于，可以跨平台，可以在不同的移动客户端上运行。

5、 经验教训

我们经常说，所有的事情都是看起来容易做起来难，但这不应该成为我们没做好一件事情的理由。这次比赛中的亮点不少，但是经验和教训也一样很多，将之罗列出来以自勉。

a. 报名平台。对于一个偏技术的活动，新浪微博可能并不是最佳的平台，抢座网相比之下要好很多，如果条件允许的话，做一个自己的活动报名网站更理想。

b. 宣传渠道。之前太过侧重网络宣传，而从这次的比赛来看，借助各种与比赛目标人群相吻合的线下活动进行宣传，可能带来意想不到的宣传效果。

c. 评审环节。对于一些Cloud Jam的参赛者而言，33小时开发出作品可能不是很难，但是要在5分钟内清晰地讲解、演示作品就不是那么容易了，以后的活动中应该适度增加讲解时间，并且提前组织参赛者排练讲解环节。

d. 项目太多。应该在比赛开始的阶段，狠心砍掉一些项目，建议参赛者组队来实现完成度更高、价值更高的项目。

6、活动的意义

举办这次Cloud Jam的初衷有两点：一是让大家知道真正适合创业者和中小团队的云计算是什么样子，在比赛的过程中进行体验；二是提供一个让开发者互相认识、交流的平台，一个面对面交流的机会，如果能够找到未来创业路上的同伴则是再好不过了。

从结果来看，这两个目的都达到了，这就是这次活动的意义。

好奇怪的一个标题啊？事情是这样的，几个月前，我进行了一次工位的调整。在这个过程中，遇到了一些不是很爽的事情，虽然过去了这么长的时间，但每次想起还是觉得不爽。最近看了很多的产品，感觉有些很有趣，也有些看起来很不爽。看着看着，就想起了我那次不爽的工位搬迁经历了，并在其中找到了一些共通之处，在这里写一写。另外，可能和某些社会现象也有一些共通之处，如果有人看到了，觉得有所触发，那么很好；如果有些人看到了这篇文章，觉得不爽，那么只能说：如有雷同，纯属偶然。

首先还是先来介绍一下事情的经过吧。

几个月前，被通知需要调整工位，在大公司里面这是很正常的事情，长期不动地方，说明公司缺乏活力。好了扯远了，我接到了通知，于是就进行了搬迁。但是调整之后，却发现，我的分机号码变了。办公室购买的是昂贵的avaya IP电话机，电话号码是跟着电话走的，只要把电话从这边网线上拔下来，到那边插上，号码是不会变化的。但是在搬迁了工位之后，却被告知，我一定要更换一个分机号码，感觉非常的不解、不爽。

我已经将这个分机号码印在了名片上，印着原来那个分机号码的名片已经发掉了一盒，还剩下一盒。我还将这个分机号码标注在了我的邮件签名里面，应该也发出了几百上千封的邮件了吧。在我将那么多带有分机号码的邮件和名片发放出去之后，在保留分机号码那么方便的情况下，为什么一定要挑换呢？由于工作的需要，我们需要挑换工位，这没有问题。外面那些需要联系我的人，并不知道我的工位在什么地方的，但是分机号码就完全是另外一个问题了。需要联系我的人，是需要打那个分机来找到我的。

我感觉非常不爽，于是我就去抗争了。我先找到了行政人员，行政人员告诉我，这是IT部门的规定，于是我就又找到了IT人员，他们一开始告诉我，为了他们自己管理方便，所以才这么规定的。然后，我说，现在的设备，只要每个人抱着自己的电话机换工位，就不会有问题了啊，不会有任何不方便的地方啊？然后，IT人员又告诉我，这个规则是以前在行政岗位上的一个人，和他们一起商量确定的，就一直这么执行下来了。然后，我又找到了以前的那位行政人员，她告诉我说，她也没有此类的经验，这个规则是在办公室装修，设备还没有采购回来之前制定的，她也不了解现在话机的功能。而且，她已经离开了原来的岗位，如果其他人发现现在情况变化了，完全可以进行调整啊。最终，IT和行政人员还是在我的抗争下屈服了。但是，只有我一个人得以保留了原来的分机号，其他参与那次工位调整的同事，都换了新的分机号。以后再有调整工位的同事，我没有询问他们的情况，估计那个莫名其妙的规定应该还在执行着吧。也许部分去抗争了的人，能够保留自己的分机号码吧。

故事有些绕，但基本就是这样的了。在这个事情中，有人有错误吗？有那种需要承担责任的错误吗？应该说没有，但又应该说所有参与这个事情的人，都有一定的责任。

现在的行政人员，在发现情况发生了变化的时候，为什么没有去调整政策呢？也许他们以前并没有发现情况发生了变化，但是在有人抱怨了之后，他们选择了维护那个谁也搞不清怎么回事的规定继续运行下去，当有人来抗争的时候，就小范围的调整一下，息事宁人之后，继续保持原有政策的运行。

制定这个规则的时候，首先应该考虑的肯定是办公方便，业务方便。毕竟大家坐在这里是为了做事情，做业务的，那些管理部门存在的原因是维持业务的运转。而不是反过来，我们所有人坐在这里是为了被管理的。这里并不是要求完全不顾管理难度，一味的追求业务方便。而是应该达到一个平衡，在管理服务能够支撑的范围内，最大限度的为业务提供方便。至少在这一条规则的制定上，考虑管理方便的因素就大大的超越了业务方便。我以前的公司，换座位的时候，就会去调整程控交换机，最大限度的保证业务的连贯性。而在这里，在设备升级换代，大家只要抱着电话换工位，就可以达到不换分机号的情况下，制定规则的人，已经完全忘记了他们存在的意义是服务于业务，而是将自己摆在了一个管理者的位置上，为了管理方便而牺牲业务连贯性的需求。而且制定这个规则的时候，当时的行政人员没有经验，但是IT人员却是一个老IT了，他不可能没有相关经验的。

这里不是写批判文章。让我们看看在产品开发过程中是不是也会出现类似的问题呢？

一个产品的设计，目的肯定是要解决用户的一些需求。然后，还会有很多其他需求，比如做产品的人需要吃饭，需要有下载量，需要有点击数。需要用户支付等等。这就是其实也是一个平衡。前面的人可能还在做平衡，当团队大了之后，是不是会有人为了盲目的维护原来的一些策略，而放弃用户需求呢？会不会有人将产品本身的生存需求，放到了比用户需求更高的位置上了呢？

一个产品，其实有两块需求，用户需求和产品生存发展本身的需求。这就像是刚才说的例子一样，应该在保持产品生存和发展的条件下，尽最大可能的去满足用户的需求。而且，应该在做出每一个判断的时候，进行每一项功能取舍的时候，都从这个最原始的出发点来考虑问题。时时刻刻的反省，是不是条件发生了变化，在新的条件下，是不是应该调整原来设定的一些策略？

先举几个例子吧。

第一，原来一个sns网站，开放了API，让其他人在上面做游戏。他们看到那些用户做了游戏，赚到了钱，于是他们自己也开发游戏。然后，他们发现自己开发的游戏，没有用户开发出来的同类游戏赚钱，于是他们封闭了同类的游戏。后来，他们发现好像还是不怎么赚钱，于是他们就再去抄袭另外一个他们认为赚钱的游戏。周而复始，很快他们的平台上就没有人在上面开发游戏了。

第二，另外一个sns项目，运营的人发现互动太少，里面的游戏没有什么人玩儿，于是就不断的发大量的游戏信息出来，并且不断的提醒用户你的好友在邀请你玩儿什么什么游戏。很快这个平台上面的信息流就被游戏信息给淹没了，用户也快速的流失掉了。

第三，一些做电子阅读器的人，为了能够让用户购买他们的阅读器设备，不在客户端软件上放置阅读功能。他们担心如果用户在pc端软件上阅读了，就不会再购买阅读器了。其实他们要解决的问题不是买阅读器，而是让用户在任何时间和环境下都可以阅读。后来他们还是推出了一个单独的pc端阅读器软件，生生的将用户割裂开来。

第四，一个用户多媒体内容分享和传播的应用，在用户希望进行微博分享的时候，为了迫使用户点击微博中的链接，故意将某些内容截留下来，最终阻碍了用户希望信息得到传播这个需求的满足。发出去的微博本身的感染力也下降了，被转发和引起互动的能力下降。

上面都是一些反例，也有做得很好的。

第一，facebook为了保证用户收到信息的质量，限制了广告。

第二，google将广告放在搜索结果的外面，决不让广告污染搜索结果。

第三，一些轻博客网站，在分享内容到微博的时候，会按照最有吸引力和表现力的方式来摆放图片，从而提升微博的传播力。只有在需要的时候，才放链接进去，比如内容超过了微博允许的范围的时候才放链接，其他时候就不放链接。

关于如何区分不同的需求之间的平衡性的问题，故事讲了，道理也讲了。

下面讲另外一些故事。

当项目中发生争执的时候，经常会听到这样的话。这个事情是以前就是这么定下来的（虽然我说不清为什么），所以就是不能改。当有人要求修改的时候，，他会告诉你，以前出过故事的，你会比以前那些人更加了解情况吗？你会比以前那些人更聪明吗？而这个时候，以前那些人往往已经身居高位了。这就像上面那些人做得事情一样，规则有了，虽然我们搞不清当初为什么制定这个规则，那么好吧，让我们将这个规则执行下去吧。

不记得是在哪篇古文里面看到过这么一句话：上胡不法先王之法。意思就是说，国君为什么不取法古代帝王的法今制度呢？ 以前旧的规则，肯定是会有人去维护的，有些人是从自身利益出发，或者经过反复思量之后决定保留那些古法的。但是也总是有些人，会无条件的遵循固有的东西。并不是说打破古法就是对的，而是说一定要经过自己的思考，再决定是不是要执行还是改变固有的规则。

现在是互联网时代，各个团队的发展速度都是很快的。如果一个团队突然成功了，那么这个团队可能还没有来得及去总结到底哪些策略带来了他们的成功，他们所经历过的一切就都会变成先王之法。而很多曾经从不同的侧面了解到这些内容的人们，就会把这当作先王之法认真的执行下去，但这些人又往往是瞎子摸象、管中窥豹。现在流行的一种说法，说某某公司具备或不具备什么什么基因，这些基因就是这么形成的。

复制别人的成功为什么那么难？由此可见一斑。这个法先王之法的现象所造成的另外一个结果就是富不过三代。还有一个典型的例子就是邯郸学步了，现在copy to china蔚然成风，但是又有多少人真的学会了邯郸人走路的姿势了呢？

故事讲得差不多了，希望以后做产品的时候，能够时刻清醒的认识到，到底哪些需求是产品生存的需求，而哪些才是真正的用户需求。时刻注意自省每一个功能或策略到底是在满足用户需求，还是满足产品生存的需求。满足产品生存需求的时候，是否伤害了用户的根本需求。在当前的生存环境下，产品是不是已经最大化的满足了用户的需求，是不是可以做得更好一些。过去制定的各种策略和措施，在当前环境下，是否还适用，是否需要做出调整。如果需要的话，就及时的进行调整。

标题里面还有“其他”。那么最后讲一点点其他吧。涉及这个话题的社会现象通常都比较敏感，这里就讲一个比较不那么敏感的。

我们的手机号码是属于移动运营商的，不属于我们这些出钱的人。我们不能将号码从一个运营商转到另外一个，这就是一个典型的产品生存需求侵占用户需求的案例。当然，这还不算过分的，我们在同一个运营商那里，不可以将一个地区的号码迁移到另外一个地区去，这是一个典型的法先王之法的案例，以前由于计算能力有限，对号码进行了分地区的限定，为每个地区分配号段，现在技术进步了，计算机的运算能力增强了，既然我们能够实现手机的漫游，那么为什么不能实现跨地域的手机号码迁移呢？最后一个案例，是这两种弊端的结合，我们没法使用一个传统2G的号码，在同一个城市的同一个运营商那里开通3G服务。如果要使用3G号码，就必须要换一个3G的号码。这是当前技术无法解决的问题吗？很显然不是，那么为什么要这样做呢？理由很可笑，第一、以前就是这么干得，第二、这样可以发放出更多的3G号段的号码。

这个“其他”肯定还包含很多很多社会上的东西。这里就不列举了。我上面的那个亲身经历的故事里面，肯定还有很多其他有趣的东西值得挖掘，比如当发现问题的时候，私下向喊得最大声的那个低头，将事态控制在最小范围，维持大范围的稳定等等。以后有空再拿出来写吧。

2012年的3月20日，是IT龙门阵第一次走进盛大创新院。也是IT龙门阵的技术专场的第一次活动。这期活动，演讲的嘉宾，分别是来自盛大多媒体创新院，负责人脸识别技术开发以及应用的单霆先生和来自腾讯研究院的负责手机人机交互方面研究的陈波女士。这一期活动的主题，是移动终端上多媒体模式识别技术的应用。

在开始之前，主办方先请单霆先生和陈波女士这两位来自不同公司的多媒体模式识别和人机交互方面的专家，做了一个小范围的沟通会。他们交流了一下各自在这个领域中的一些经历和看法。

这次的活动还是吸引到了不少专业技术人员的参与。IT龙门阵已经很久没有做过这么技术的话题了，平时很多都是媒体方面的人来听一听各个公司的大佬们来讲故事。据说还有人是专门从南京过来这边参加活动的。我在现场还碰到了专门赶过来的天津大学老师。看来纯正的技术话题，对专业人士的吸引力还是很大的啊。

我作为这次活动的主持人，也是倍感荣幸。可以主持这么专业的技术研讨，感觉压力还是很大的。

讲演过程中，单霆先生回顾了他的创业经历，他很早就开始从事人脸识别技术在应用方面的尝试，以及投资界对于这个领域是多么的热切。然后又讲解了人脸识别的具体算法和这些算法的演进历史。很遗憾，算法的这一部分我没怎么听懂，这 一部分的内容确实有太专业了。不过看样子其他的那些听众还是听得很有感觉的。希望他们能够从中有所收益吧。

单霆先生在讲完了技术之后，还介绍了两个应用人脸识别的技术的产品。其中F ace-API是比较有趣的，直接将人脸识别技术封装成API放在云端，提供给那些想要使用这个技术的团队或个人使用。现场就有不少听众找他们要邀请码，希望进行尝试。

在正式的IT龙门阵活动之前的小范围沟通交流会上了解到，腾讯的陈波女士和他们的团队，也已经申请了Face-API的试用邀请码，并在Face-API的即时通讯群组中潜伏一段时间了，当天其实是单霆和陈波以及腾讯研究院的这个团队里面的一些成员的第一次线下网友见面，这个圈子看来还真是小啊。

陈波的演讲范畴要更加宽泛一些，包含多媒体模式识别和人机交互的很多领域。这位腾讯研究院的美女专家，首先纠正了大家的一个误解，她说腾讯现在已经改变了很多，现在腾讯已经是一家非常开放的公司了，愿意开放出很多的资源和数据，和大家一起创造财富。以前创业者总是担心会遭到腾讯同类产品的竞争，现在这种状况已经发生了变化，腾讯正在逐渐向着开发者和创业者的朋友的方向转变。

在陈波的演讲中，介绍了模式 识别和人机交互的发展历程，以及腾讯在这方面的一些尝试。她反复的强调，很多人现在对于模式识别的应用抱有过高的期望，这是不正确的。模式识别技术，还远远没有达到能够让计算机或智能设备达到人类识别事物的能力，在短期内，这还是很难实现的。但是，现在，特别是元计算的到来，为模式识别带来了重大的发展和机遇。使用现有的技术，已经可以做出很多有趣的，改变人们生活的应用了。腾讯利用这些技术，实现了手写和语音的输入，并通过图像识别技术，开发出了QQ慧眼这种有趣的产品。这个产品可以让人们在旅游的时候，看懂外文的路牌。QQ慧眼就是陈波女士的团队自主开发的。他们还有很多技术，被应用到了腾讯的其他产品之中。腾讯也会逐步的将这些技术，开放出来供更多的开发者使用。

两位专家结束了演讲之后，会场上的听众们向他们提了不少问题。这里面有些非常专业的技术问题，更多的则是现有技术的一些应用前景相关的问题。过程非常热烈，由此可见，大家对于多媒体模式识别技术在移动互联网领域的应用还都是非常感兴趣的。

最后单霆先生做的总结是：多媒体模式识别技术，可以是人机交互摆脱语言和文字的束缚，重新回归的更加贴近自然的状态。这就是在这个领域里面努力着的人们的共同目标。

IT龙门阵下一场的技术活动还在规划之中，现实增强、虚拟现实，或者云计算等主题，还没有确定下来。请大家拭目以待吧。

好像有很长一段时间没有更新博客了。

最近在忙着一些社区活动的事情。后面的社区活动会越来越多。而且，周末时间还需要陪儿子玩耍，是不是能够抽出时间来写博客，还不一定。抽空写吧。

今天下午有PMI项目管理俱乐部的活动，上午就跑来办公室，趁着这一点点的时间，写一些吧。

最近组织、协办、参加了一些社区活动。也有了一些想法。现在先来写其中的一个。

所有公司里面和宣传，公共关系相关的部门，都刚刚度过了我们一年之中最重大的一个节日，这个节日是所有做公关的人都是又狠又爱的，那就是315。所有的中国公司，对于315这种东西的心态都是非常矛盾的。既希望315能够搞定竞争对手，同时也害怕315找上自己。这就体现了一个问题，所有公司都知道自己在诚信方面有所亏欠，但又都寄希望与老天睁一只眼闭一只眼放过自己，或者想着，我们只是为了一些小恶，社会上比我们罪大恶极的家伙多去了。这次不会轮到我头上的。

315也算是一个大话题了，这里要阐述的是另外一种比较小的诚信问题。那就是个人诚信、个人信誉。

诚信问题，分为很多方面。特别是有一些银行方面的信息，属于个人隐私，是不适合进行公开的。所以我所设想的个人信誉追踪系统，所追踪的也仅仅只能是个人或一些机构发表的公共言论，以及向公众所表达的一些观点的追踪和回溯。机构可以通过换人来快速的改变其信誉，但是个人不论走到什么地方，其信誉状况应该是不会发生跳跃性的变化的。所以我感觉，个人要比机构的信誉状况更加值得追踪。

记得很早以前在电视上看过一位大神级人物，讲解什么是诚信，那位大神讲道：为了远期利益，而放弃近期利益的方式，就是诚信了。诚信归根结底还是为了利益，并不是为了什么道德或真理、正义之类的东西。现在，很多的专家、学着、名人，在利用他们的声望，说着或做着一些事情，即使事后被证明了，这些事情可能有问题，他们也会放出，人总是要犯错误的之类的言语，来为自己辩解。甚至还有些可笑的人，做了不诚信的事情之后，堂而皇之的说，这是在牺牲小我，成就大我；牺牲个人荣誉，成就更大的利益。

这是为什么呢？为什么我们感觉有越来越多的个人或机构，变得不诚信了呢？我们无法相信社会，无法相信专家，无法相信其他的那些机构或管理者呢？当然，信任都是相互的，我们不信任别人，也不指望别人相信我们。归根结底，不诚信的成本太低了。诚信是为了远期利益，而牺牲近期利益的行为。那么不诚信就应该是不顾远期利益，而争取近期利益。但是如果人们在不择手段的获得近期利益的时候，对其远期利益基本没有损害，甚至还有所帮助，那么就不会有人选择去遵守诚信了。因为那是非常不划算的一件事情。

社会为什么需要诚信，这里就不讲了，相信大多数人都非常清楚。那么我们怎么得到一个诚信的社会呢？大的方面肯定轮不到我在这里胡说，那是党和政府考虑的事情。我们只能从一些小处着手，增加一部分人不诚信行为的成本。

我的想法是，建立一个跨平台的网络应用，能够让所有的用户讲他们看到、听到的事情记录下来。然后利用语义分析工具和人脸识别技术、声纹和语音识别等技术，对这些凌乱的信息进行整理，将信息以人为单位，以时间为顺序，进行归并。系统仅分析和记录那些公众场合发表的信息，图片、视频和语音信息，用户可以从各种新闻媒介摘要上传信息到系统中来。

对于一个事件，在系统的数据模型上，会形成一个节点。各个专家和学着、机构对于这个事件的观点会汇集在一起。系统可以自动的筛选出一些对于这个事件比较热心的用户来维护这个节点。并使其具备比较高的可读性。以方便其他用户的阅读并进一步的补充内容进来。用户可以在不同的时间段，对同一个事件，同一个人在这个事件中所起到的作用进行评判。社会大众在不同的阶段，对于同一个事情有不同的看法也是正常的，毕竟通常是需要日久见人心的。

人们也可以自己去上传一些自己的事件。大家可以去纠正那些错误的信息，这需要共识，然后找到一些共同关心这个事件的用户认可之后，才可以进行修正。被修正的内容，也不会被删除，而会作为被证实是虚假的信息，存放在系统中，用户仍然能够看到。

这个系统会通过众包的形式，搜集社会新闻媒体上面的公开新闻，然后让人们在不同的时期对新闻人物在新闻事件中所起到的作用进行评判。当事件随着时间的发展，前面那些人所说过的话，发表的意见，做过的事情，旁观者可能会给出不同的评价。这个系统存在的目的，就是为了让大家记住。记住那些人，在过去的那些事情上都做过些什么，让这些人的远期利益和他们现在的一些作为挂钩，让他们在做事情的时候，能够有所顾忌。让那些有信誉的人，能够享受他们牺牲掉近期利益所博得的远期利益，让那些没有信誉的人，在远期利益上能够受到相应的损失。

这个系统，是很理想化的，是否可行，是否有可能在现在的社会形态下出现，这都很难说。至少从技术上，是没有任何问题的。现在的微博数据，就完全可以支撑这种系统的运转。但是微博做得是严格的恪守时间线，如果出现了什么不好的事情，就可以通过另外的一些更加热点的事情，来增快用户遗忘的速度。只要将吸引力转移了，大家很快就会将事情忘掉的。当然也有一些认真的人，喜欢抓住别人的小辫子不放，比如方舟子之流。

我所设想的这个系统，就是希望能够有更多的人，能够通过系统来部分的实现方舟子那种很有研究能力的人才能实现的事情。方舟子在打假的时候，还是很有选择性的，这没有什么可批评的，毕竟他也要在这个社会下生存的。有了一套系统之后，大家通过众包的方式来搜集信息，搜集信息的时候，可以使用实名用户或匿名用户提交的信息，但信息必须是在公共媒体上发表的内容，或者是实名用户自己相关的内容。这样的话，那些提供信息的人们也就没有什么风险了。很多考证的事情，可以等到信息搜集起来之后再说，具体是采用人肉的方式，还是计算机算法，或者最有可能的是计算机算法和人肉相结合的方式，都是可以的。

那些曾经不诚信的人，或者是被其他人误解了的人，也可以到系统里面来解释，或者找其他人来帮其证明。

知错能改善莫大焉，总要给大家改过自新的机会。系统存在的目的不是为了让那些不诚信的人永远不溶于社会。而是希望能够起到一个威慑的作用，并能够告诉大家，善有善报恶有恶报。

此类系统到底有没有社会需求，这个事情很难说，但是从商业模式上来说，肯定是比较麻烦的。也许，能够用来作为某些诚信者记录自己工作生活状态的地方吧。最终成为一种媒体。

这个系统，只是我的一个设想，是不是有过类似的东西，本人不考证。设想这个系统的目的就在于：首先将现在发生的事情，记录下来。以后这些内容就是历史，不可磨灭的历史。让后人可以通过这些历史的记录来对参与到现在这些历史事件中的人们进行评判。

RSS阅读，对于我们这些人来说肯定是一天都离不开的，但其实这也是一个小众应用。
我个人对于RSS阅读的需求是这样的：

• 多平台的书签同步，标记那些读过，哪些未读。
• 不论源提供的是什么样的，所有的内容都分为标题、简介和全文三种状态，也就是说对于那些不提供简介的，要自动生成简介，对于那些不提供全文的要自动提供全文。
• 移动端的图片，进行预先的处理，下载的内容预先压缩，比如生成类似于epub的格式。
• 自动去重，如果我订阅的各个源之间，都报道了同一事件，那么就要去除重复的内容。
• 智能内容推荐，推荐那些热门的内容，推荐那些我好友关注的内容，推荐那些有趣的，新的源。
• 智能过滤，当我的时间比较紧张的时候，按照优先级和重要度，筛选比较重要的内容发给我。
• 提醒，当某些特殊事件发生时，主动的提醒我。
• 归纳总结，定期，比如一天、一周、一个月，出一份总结性的杂志。可以离线阅读。
• 分享和关注，分享我的阅读体验，关注我好友的阅读过程
• 将所有源的所有内容，按照类别进行分类、去重，然后按照类别进行阅读

我目前主要在使用Google Reader，IOS端使用的是Reeder。主要的功能是可以满足的。但是Google Reader是按照时间和源为基础来管理内容的。我希望能够安装状态和优先级、类型来进行组织和排列。

希望能够有跨平台的RSS离线阅读工具。
较为重度的RSS阅读者，对RSS阅读提出的想法。

书接上文。任务管理系统中的很多特性都是从复杂的工程管理软件中借鉴来的。那么在探寻任务管理系统的设计时，最好能够先来看看工程管理软件都有哪些常见的特性；然后再看看对于个人使用的任务系统来说，对于这些特性的需求会有什么样的变化；最后，阐述一下我个人对任务管理系统的一些看法。

• 工程管理软件分析

工程管理软件中的任务，是有相互的依赖关系的。有些是由于后续任务需要使用前置任务的成果，有些则是由于后续任务需要使用前置任务所占用的有限资源。工程管理系统，在进行计划制定的时候，首先要将完整的工程划分为不同的任务。然后，再根据这些任务之间的依赖关系，来排定这些任务的先后执行测序。以求在最短时间和最小资源消耗的情况下，完成整体工程。

工程虽然并不像日历那样，是以时间作为根本特性的，但是一些关键时间点对于工程来说也是至关重要的。比如天朝经常会出现献礼工程。以及工程进行过程中的各种公休和节假日也都是需要计算在内的。通常一个工程里面会有若干个工程关键时间点。这些时间点通常是工程自然节点附近的一些特定的日期。比如工程可能在某个节假日附近完整一个功能节点，那么通常的做法是将这个节点直接设定在那个节假日之前，这样大家做完一个阶段的工作之后，正好可以休息几天。有时候一些为公众服务的系统，也喜欢赶在节假日之前上线，以便能够在节假日获得更好的收益。工程管理系统，会根据这些关键时间点，对任务的排列进行适当的调整，即使这些调整会使得工程所耗费的时间和资源有所上升。

工程管理系统中所管理的最重要的东西，就是资源了。这里所说的资源，指的是工程过程中不得不用，而数量又有一定的限定的东西。比如工作人员的工时、场地、各种仪器设备、零部件等。小型的工程管理软件只需要计算出完成工程所需、或所能调用的资源总量，然后根据这个资源总量进行任务调度和安排就好了。所需或所能够调用的资源总量，是根据工程的进度要求，平衡得来的。有些资源增加了之后，是可以提前项目进度的，有些则不行。通常的做法，是根据所有能够使用的资源总量，先预估工期；然后在根据工期进行任务资源分配；最后再根据任务资源调配情况，对工期和所需资源进行调整。

大型的工程管理系统会复杂得多，这些系统还需要考虑很多资源的建造、购买、仓储、领用等过程。比如航天卫星发射的工程管理系统中就需要考虑火箭发动机的生产，每个批次生产出来的火箭发动机，都需要拿出一枚来进行测试。而这个测试验证试验是一次性的，也就是说做实验的那个火箭，试验之后就废掉了。那么系统就需要考虑“组批生产”的问题，比如一个批次最多可以生产十枚火箭，那么最好能够将火箭发动机凑成十个一组来生产，否则的话，如果只生产两三枚火箭也需要多做一个出来做实验，那就太浪费了。大型的工程管理系统，通常还需要考虑分里程碑验收和支付的问题，每一个里程碑需要完成哪些任务，这些完成的任务如何验收，以及如果验收出现什么问题，怎么办。验收之后，通常是需要进行里程碑付款，我还见过一些系统，在里程碑付款和购置设备等过程中还考虑汇率波动风险和银行账户利息等因素的。比如别人付过来一笔美金，工程方直接将其都兑换成了人民币，但是工程中又需要以美金再去购买什么设备或零部件那就亏了。总之，资源管理根据工程管理软件的规模和行业差异，也会存在巨大的差异。但这肯定都是各种工程管理系统中最重要的一个部分。

工程的任务细分，并不是一次完成的。这个过程通常是逐层细化的，所以就会出现任务和子任务的概念。一个任务对于承接这个任务的团队来说就又成了一个工程，这个团队会将其再次划分为子任务。或者是完成一个大的任务，需要多个团队协同工作，也可以将这些团队所完成的共组划分为子任务。这个划分的过程，是有很多模板和定式的。比如，盖房子必须先画图纸，然后打地基，从下向上一层一层的盖，封顶之后先做外墙装修，然后做内墙装修和强电弱电工程。就算是家庭装修，也需要考虑先做墙面，在做墙面的时候要预留强弱电的线槽和开关接插口面板的位置；在做墙面的时候可以进行门窗油漆等工作；墙面和油漆的工作完成之后， 才能进行地面施工；再然后才是家电和家具的购置和摆放。地面工程的时候，是不会将墙面和油漆过的门窗搞脏的，但是墙面粉刷和油漆的时候会把地面搞脏的。强弱电线路的布设和接插口面板的设置，是需要破话墙面的。家具和家电是要放在地面上面的，所以一定要在地面施工完了之后才能做这些事情。这个过程是无法打破乱来的。

任务和资源，都是有状态的。工程管理系统就是通过对这些状态的管理来实现任务和资源的调配和管理的。简单的状态有：资源被占用、资源被闲置、任务可以开始、任务等待关键资源到达后可以开始、任务进行中、任务完成、任务暂停等。在资源不冲突的时候，工程管理系统会尽可能的安排并行任务以节省工程时间。比较复杂的状态管理，可能会包括仓储物流、人员培训、期货购买和交割等复杂过程，这里就不讨论了。工程管理系统的工作方式，基本上可以被看做是一种状态机的工作方式。

任务之间的等级并不是平等的，因为很多资源是无法进行分割和隔离的，所以很多任务是必须在共享资源的情况下并行进行的。在并行执行的任务之间就会存在优先级的差异，哪个任务需要占用更多的资源，在时间节点上更加紧迫，其优先级也就更高一些。

在任务完成了某个里程碑之后，或者是工程完成之后，工程管理系统是需要对工程的完成情况进行审计和评估的，是需要出具工程完成状况报告的。这个报告包含任务完成状况以及任务完成过程中资源使用的情况，任务完成状况和资源使用的情况和原计划之间的差异，这些差异产生的原因，以及针对这些差异，需要对后续的计划做出哪些调整等。

• 对于个人使用的任务系统，在用户体验上所需要特别注意的地方

规划系统不能太过复杂，工程管理软件，根据自身的复杂度，提供不同复杂度的规划和录入系统。有些工程系统光是录入初始的数据就是一个庞大的工程。甚至会有专业的咨询、规划、设计机构来完成这些工作。这个过程对于个人使用的系统来说是必须要简化的。

个人任务系统和工程管理系统有一个最本质的差异。那就是工程管理系统是在一个封闭的时间段上来规划工程的，而个人任务系统是不可能从一个人出生一直规划到死亡的，所以个人任务系统通常都是在一个开放的时间段中规划任务的。而且，很多任务之间没有那多多的相关性。对于个人任务系统来说，相关性比较强的任务之间是可以有一定的依赖关系的，但是从整体来看各项大任务之间是没有紧密关系的。

个人任务系统中的资源管理是一个很麻烦的东西，有些资源在一个任务中起到一种或几种作用，但是这些特性对于其他任务来说可能就会发生变化。用户自己的时间也是一种资源，而且是关键资源。不同的个人之间也都互为其他人的资源。对于跨越任务和工程，散布在整个人生之中的任务管理系统，其所管理的资源只能是针对特定任务的。也就是说资源是任务相关的，规划一个任务或由一系列子任务构成的主任务时，可以涉及各种资源，但是这些资源是限定在任务内有效的。离开了这些任务，资源就需要重新定义了。

个人使用的任务系统，肯定需要包含能够通知到个人的各种通知手段。所以这个系统比如需要一个跨平台的通知子系统。工程管理软件中通常不需要这个东西，相关人员会主动的去查询任务分配和进展情况的。

工程管理系统中的那些复杂的审计和评估报告，对于个人任务系统来说也是不适用的。普通用户是读不懂，也没有耐心去读那些复杂报告的。而且，由于个人任务系统是在开放的时间段上进行规划的，所以这种系统更需要的是能够在任何一个时间点去检查过去任意时间段的任务完成情况和资源使用情况。并根据统计的结果，对后续的任务进行调整。

工程管理系统中所使用的语言和文字，都是在其特定行业和环境下使用的正式书面语言。个人系统完全可以使用一些个性化的、生动的生活语言、口头语言、网络流行语言来进行语言和文字描述。

用户选择了任务管理系统，通常是希望能够尽可能的按照计划完成任务的。工程管理系统是依靠契约、特定团队组织架构和制度来保证任务的完成的。那么个人系统能够依靠什么来促进任务的完成度呢？除了前面提到的提醒系统之外，应该再加入一些游戏性的鼓励和成就分享和刺激在里面。

• 关于个人任务系统的一些设想

规划和任务执行情况反馈合一，随时规划新的任务，随时查看近期任务的执行情况，并对任务进行调整。

完善的通知和提醒系统，使用生动的生活语言通过各种平台和方式，通知用户启动、推进或完成任务。

通过各种各样的平台，接受用户的反馈，并记录任务完成的进度和状态，以及用户在完成任务过程中的各种相关信息，最终形成完整的报告，比如装修笔记、旅行路书等。

增加任务状态，一个任务可以有多个状态，将状态机的机制更多的引入任务系统。提供尽可能多的状态机模板、子任务划分模板，供用户套用。

加强资源和资源状态的管理。用户自己的时间，出现在任务中其他人的时间，以及参与任务的其他资源（包括资金）的规划、分配和调度。

在任务系统中添加游戏性，鼓励、激励、刺激用户按照计划完成任务。并将用户完成任务的状态和成就，分享到Social平台上，让整个social平台上的人都来一起见证和激励用户完成任务。

如果说现代生活中，有什么东西最宝贵的话，那无疑就是时间了。我们总会觉得时间不够用，有很多愿望没有时间去完成。

于是，就涌现出了大量的，以时间管理为目的的工具，希望能够帮助人们更加合理的运用时间。

这些工具包括：

日历系统，通常提供约会、提醒、周期重复等功能。现在很多软件都提供日历的功能，我们使用比较多的有微软的Exchange Server和Outlook、以及Google Calendar。苹果好像也有自己的日历工具，但由于使用的不多，所以不是很熟悉。

任务管理系统，通常包含任务的归属、任务的场景和标签、任务的优先级等。为大家所熟悉的任务管理系统有：Things、Google Tasks、ToDo、Doit等。按照我接触和了解的情况来看，这一类工具是从工程管理工具中简化而来的。要比工程管理工具来得简单，主要是适合个人使用、而不是供工程项目使用。此类工具近些年来颇受大家的喜爱。

工程管理工具，现在很多时间管理工具上的特性，其实都是从工程管理工具中简化剥离而来的。这种东西顾名思义，并不是为个人设计的。工程管理工具，即使是比较简单的，也是为了几十人甚至是几百人协同完成一个工程项目而设计的。工程管理软件强调的并不是通知和周期性的变化，而是任务之间的依赖关系，任务所需要调用的资源，以及如何调度，以实现在要求的时间内，使用最少的资源完成任务。此类软件中，被使用得最广泛的，就要算是微软的Project，还有简化一些的XPlanner了。有些庞大的、运用于特定领域的工程管理类软件，其购置、维护的成本是非常恐怖的。这些软件通常是以咨询服务的形式进行销售的。我就曾经见过一款用于核电站建设的工程管理软件，其软件规模异常庞大，光是用于存储数据的实体，就有近万个，可见其内部业务逻辑之复杂。

这里要讨论的并不是庞大复杂的工程管理工具，而是供个人使用的时间管理工具。之所以将工程管理工具列在这里，是因为其中拥有很多时间管理的功能，很多供个人使用的时间管理工具正在不断的从中吸收各种有趣的特性。

工程管理软件的目的，是使得工程项目在占用最少资源的情况下，按照要求的期限完成。对于这种软件来说，不容角色的人和其他的各种设备或服务都被抽象成了不同种类的资源，其最终的服务对象是工程本身而不是作为资源的人。工程管理软件的工作过程大概分为三个环节：规划工程的实施过程和实施过程中的资源占用和调配；将规划通知所有和规划相关的人或机构，接收项目各个分支与环节的执行结果，以及各种相关资源的使用状况，并将这些数据汇总，以便对项目的执行过程或结果进行评估；根据项目期间，各个分支执行的情况和资源使用的情况，对项目后期的规划进行调整。这样看来，工程管理的过程就是一个规划过程和一个反馈过程的循环往复。

现在，人们越来越希望能够像管理复杂的工程项目那样规划和管理自己的人生。

从现在流行的这些时间管理工具来看，日历管理方式实在是太粗糙了，其中缺乏资源的概念。一些内网或组织内使用的日历工具，比如Exchange、Lotus Notes等，是允许查阅相关角色的日历的，可以帮助使用者，人工的在对方空闲的时候创建约会或会议。但是对方是否接受，还是需要对方人工确认的。工程管理过程中，规划者和被作为资源分配的人之间并不是平等的。规划者是可以决定某些人什么时候做什么事情的。而在日历工具中，人们的位置是平等的。

日历的另外一个缺陷就是，其中的事件，缺乏状态。一个约会、会议或提醒，对于日历系统来说都只有两个状态，到期或未到期。日常生活中，很多事情并不是这样的，很多事情从开始规划到最终完成，其中是要经历很多个状态和过程的。这对于日历系统来说，是很难表现的。

任务管理系统，就要比日历系统更近了一步。在任务管理系统中，原来日历系统中的事件，变成了任务。这其中的差异在于：事件的基本属性是时间，我们约定了周三晚上吃完饭，那么如果时间已经是周四上午了，对于日历系统来说这个事件的状态就是到期或过期。日历系统缺乏工程管理系统中的反馈环节，所以日历系统并不知道一个事件是否被执行了。任务系统就要好很多，任务的基本属性并不是时间，而是状态。一个任务是否被执行了，或执行到一个什么状态了，到达这个状态之后，下一步应该怎么办。任务也可以有时间属性，而且通常都是有这个属性的。但是即使约定的时间已经过去了，任务系统也不会直接判定任务已经完成了，而是需要通过反馈系统，让用户手工的录入任务的执行状态。如果任务尚未完成，那么任务系统会提醒用户对任务的时间属性进行调整或尽早完成逾期任务。

现在的个人任务系统还不够完善，有着工程管理系统的榜样树立在那里，个人任务系统的产品经理们肯定不会不知道应该如何将其完善起来的。现在的任务系统是在工程管理系统的基础上根据个人使用的特性做减法得到的。那些复杂的统计分析和资源调配，以及任务依赖关系，对于普通用户来说确实是难以理解了一些。现在的任务系统本身就是一种平衡，在用户体验和功能完整之间的一个平衡。依靠增加功能来使个人任务系统进一步的完善起来，至少在目前来说，对于大多数用户来说是不现实的。

如何进一步的完善任务系统，以便更好的帮助人们规划他们的时间，这个我想以后再在其他博文中慢慢阐述我的个人观点。这是关于时间话题的第二篇博客了。这个话题我想至少还能再写个两三篇吧，不着急，慢慢来。