Graph架构图

 -----------------------------------------------------------
  |                       URL Routing                       |
  -----------------------------------------------------------
  -----------------------------------------------------------
  |                    Controller Routing                   |
  -----------------------------------------------------------  

  -----------------------------------------------------------
  |                       Controller                        |
  -----------------------------------------------------------
 -----------------------------------------------------------
  |                     View Dispatcher                     |
  -----------------------------------------------------------
  ---------  ---------  ----------  ------ -------- ---------
  |View Ad|  |Listing|  |Homepage|  |User| |Search| |Payment|
  |View   |  |View   |  |View    |  |View| |View  | |View   |
  ---------  ---------  ----------  ------ -------- ---------
  -----------------------------------------------------------
  |                    Template Engine                      |
  -----------------------------------------------------------
  -----------------------------------------------------------
  |                   Model (Data Binding)                  |
  -----------------------------------------------------------
  -----------------------------------------------------------
  |                  Model/Graph Integration                |
  -----------------------------------------------------------
 ------------------  -----------------  --------------------
  | HTTP Transport |  | PHP Transport |  | Socket Transport |
  ------------------  -----------------  --------------------
  -----------------------------------------------------------
  |         Security/Prettifier/Limit Control               | 
  -----------------------------------------------------------
 -----------------------------------------------------------
  |                      Graph () API                       |
  -----------------------------------------------------------
  -----------------------------------------------------------
  |                          Node                           |
  -----------------------------------------------------------
 -----------------------------------------------------------
  |                          Edges                          |
  -----------------------------------------------------------
  -----------------------------  ----------------------------
  |            ID             |  |        Connections       |
  -----------------------------  ----------------------------
 -----------------------------  ----------------------------
  |           Data            |  |   Algorithm Dispatcher   |
  -----------------------------  ----------------------------
  -----------------------------  --------- --------- --------
  |   Global/Local Namespace  |  |Listing| | Plain | | User |
  |           Conversion      |  |Logic  | | Logic | | Logic|
  -----------------------------  --------- --------- --------
 -----------------------------  ----------------------------
  |     Storage Dispatcher    |  |    Search Dispatcher     |
  -----------------------------  ----------------------------
  -------- --------  ----------  --------- -------- ---------
  |MySQL | |Mongo |  |External|  |Elastic| |Solr  | |MySQL  |
  |Driver| |Driver|  |Driver  |  |Search | |Search| |Search |
  -------- --------  ----------  --------- -------- ---------

Database Driver 完成所有与具体的数据库服务器之间的接口。 这一层以上不会再出现任何babel_topid,tpc_bak2, attributeData这样的字符串了。

Storage Dispatcher, Search Dispatcher根据对象类型分配driver.
这一层以上不应该有任何地方知道数据存在哪里,如何存储。

Global/Local Namespace Conversion层,保证之上所有的对象都是用GID访问。
这一层以上不应该有任何地方能够看到lid(Local ID),所有ID都是唯一的。
这一层一下不应该知道有global ID的存在

Data层,基础数据类,所有数据从它而来。完成Versioning等

Algorithm Dispatcher层,根据不同上下文选择合适的connection逻辑
这一层之上不应该知道任何业务逻辑(这里使用Strategy设计模式,并不产生混乱)

Listing Logic等层,提供置顶,排序,去除等各种listing业务逻辑

Search Dispatcher层,把Query分配给合适的Search提供者
这一层以上不应该知道搜索由谁提供
这一层以下不应该知道任何逻辑

Edges层,解析id,和id的各种连接。
这一层之上把conn就应该当作数据的一部分,不作区分。

Node层,Graph的基础数据层

Graph层,提供graph()函数调用,以及对于Graph的命令解析,提供斜线分割的语法。

Security层,保证API的调用安全性,访问次数,对象组装等最后包装工作

Transport层,提供各种连入Graph API的方法。

Transport层以上是示意图,并没有仔细推敲,大概描述使用Graph API的场景

我思考的百姓网类目用户模型

我把用户分类三大类,并使用如下态度

* 坚决保护熊猫用户

* 允许核心用户发展

* 收费限制污染用户

(骗子违法坚决打击,不在用户模型里面)

熊猫用户是我们想要的用户。

* 在二手里面,就是哪些处理东西的宅男,卖宝宝东西的妈妈等等;
* 在二手车里面,卖自家二手车的车主;
* 在工作类目,直招的50人以下的小企业;
* 在房屋类目,房东直接租房,卖房的用户;

实在找不到一个更好名字,来表达,姑且用熊猫来代指。他们是相对弱小的群体。

在未来,我们有可能会为了收入等压力转变我们专注的重点,我们现在就要想好去除这种可能性。

这些本地的,个人化,社区化的熊猫用户是我们的根基,服务他们是我们建立百姓网的原因。我们需要尽一切我们可能去保护他们,让他们享受到我们能够提供的最好的服务。这包括:

* 用户产品以这些用户为原型,为这些用户优化;
* 市场上把这些用户作为目标用户,获取和激活这样的用户;
* 销售原则上不需要打扰他们,通过在线自助完成;

另外一类是污染用户。这部分用户是会威胁到其他用户生存的那种类型。

* 在二手里面,就像回收,全国卖山寨电脑等商家意味非常浓的商家;
* 在二手车里面,是高危的黄牛(??需要确认)
* 在工作里面,是职介,这类高危
对于这部分用户,哪怕他们全都消失,我们问题不大(但没必要有洁癖和人家作战);他们如果过于繁荣,其他用户的生活空间将被污染。对于他们,我们将进行限制,并且大胆的,大力的收费,通过收费控制污染。

中间的核心用户层是仔细考虑过的。我们必须在清晰的内外两圈内设置足够大的一个缓冲区间,以避免非此即彼;如果没有这个区,就会出现只要确定不是我们要的熊猫,就一定污染这样的问题。核心用户是生态系统中必然存在的。我们不为他们优化,但必须允许他们生存。

* 二手车里面,他们是车商
* 工作里面,他们是中大型企业,连锁企业,派遣公司
* 房屋里面,他们是中介
对于核心用户,我们的态度是“允许核心用户发展”,但一定不是“专注核心用户”。我们所有的优化,应该以熊猫用户为主。

我们在用户和listing层面,不再做角色划分,不分为“个人,商家”,或者按入上三者分层。拿出一个用户辩论到底是三种情况的哪一种是没有意义的。我们实施的方法是按照每一类用户的喜好做产品,做市场,设计规则。比如按照熊猫用户的使用来限制总发帖数让他们正好很好用。就好像我们只管扔竹子,而不用区分下面的是狼还是熊猫。

这个层次对于各个组织的影响:

* 战略组:断分析市场情况,确认我们的三层各是哪些人,确认我们战略正确
* 市场组:获取和激活熊猫用户;吸引核心用户;忽略污染用户
* 产品组:为熊猫用户做产品
* 营收组:对污染用户重度收费;对于核心用户收费;对于熊猫用户,自助收费

百姓网对开发者的风水

经过一段时间观察,我发现百姓网的办公室对于开发者来说,风水不好,需要改变。

如果不信,问大家一个问题:如下两个场景更接近于你的工作状态

1)自己坐在竹林里的亭子里,小风在吹,我在写程序;

2)自己坐在人民广场地铁站里放了一张桌子写程序。

我觉得我们有变成第二种的倾向。如果一个开发者认为自己心神不宁,惶惶不可终日,就是开发的风水不好了。如下是我认为风水的问题:

1。会议。这个在《入境和入世》里面提到了。中途打断的会议一定要干掉。不仅仅是有形的,我们为了沟通把人放在一起,有的时候需要阶段性的把人分开。

2。上线。我忽然发现一个比会议更加吓人的打断大家工作的事情了,就是下午5点的合代码时间。到了接近下午5点的时候,大家就开始心神不宁了,因为即使和自己没有关系,5点的时候也要去看一下,看自己有没有被影响。我们必须把合case这个步骤干掉,用Git等持续集成的办法,没有集中的合代码操作。

3。邮件。我看到发到All@baixing.com,youqu@baixing.com,还有engineer@baixing.com的邮件大家回得都很及时。这是严重的分心的东西。以前在公司只有二十个人的时候,online的异步的沟通方式其实活不下来的,一周没有新帖子的论坛是没人看的,没人看的论坛更不会有新帖子的,所以用了邮件这种几乎是唯一可行的工作方式。现在是时候改动了。我们必须开始用相对更现代的沟通方式来做事情了。

4。开放的座位。同理,这个也是对于小公司合适,在人多的情况下就没法用了。原来听一耳朵的声音是信息,人多了就已经成为噪音;原来随便抓一个人是最有效的沟通方式,现在人多了,变成持续的抓人,且方向不同。不规律的不同方向的信号叫做噪音。重要的打断不仅仅是打断,雪上加霜的是因为人多导致的打断的不规律性。

5。工具。当工具不顺手的时候我们常常以为工具是不必要的。我们现在做很多东西不是最简单的,比如必须有bugfree才能上线等等,都是工具束缚了生产力。我们不然大家直接拿手抓吃的,但也不能给人家两个榔头让大家夹菜呀。工具是程序员风水很重要的部分。

让我们一点点的把这些风水改变。如下是我的解决方案:

1。对于工具组,一周正式会议必须不多于两次,工作方式灵活。
2。率先使用git,不参与上线。
3。设立公司内blog,用blog代替all
4。座位隔离,在1801办公
5. 工具组做足够好的工具,给大家用。

建硕

为什么大家都在加功能

小排问了我一个问题,为什么各个创业公司的产品都要拼命加功能。我当时还没有特别好的回答这个问题。现在我有了更完整的答案。
说到功能,我们先要从技术开始。技术就是做事情的方法。如果你找到了一种比大多数人更好地做事情的方法,你就有了更先进的社会生产力。比如1200年的佛罗伦萨,它的财富就是由发明了一整套的先进的纺织机开始的,作为一个城市,他们比欧洲全球任何国家都能够更便宜的织出更好的布;1500年的荷兰,开始仅仅因为发明一个小刀可以一刀切的剖开鲱鱼的肚子,去除内脏并且直接放到盐里保存;之后他们又发明了肚子大,甲板小,不带火炮的专用商船,把运输成本降低到英国人的一半,成为海上马车夫;更不要说1700年以后英国的以蒸汽机为代表的工业革命,以及以电气为代表的第二次工业革命,以及发端于美国的以计算机信息技术为代表的第三次工业革命。简而言之,科技不断发展,生产率逐渐提高,就是过去发生的事情。

但问题时,技术的前沿移动得非常快,非常非常快。在过去曾经让自己占据先机得技术,很快就会成为社会的平均生产力。现在有一台蒸汽机,或者大肚子商船仅仅是复古,而不是科技得象征。科技不断向前飞奔,这就要就大家都要努力向前跑,不断寻找现在最难的问题,应用最广泛的问题,去解决它。这个竞赛中,跑在最前面得一定是创业公司,不是因为他们小,是因为他们快。

在互联网领域,技术的前进更加明显。越来越多的高科技在几年里面就民用,现在一个iPhone的技术能力和存储空间几乎是互联网开始时候的一台服务器,以前公司起家的核心的技术,非常快的变成大家都能用的东西,比如搜索,比如数据库,比如BI,比如前端框架。

以存储为例。原来有一个数据库(FoxBase啥的),先进得不得了了,现在普通的MySQL,NoSQL存储已经司空见惯,连上T的存储都易如反掌了,我们必须努力去解决更难的问题,无论是更大还是更快,或者更方便。以分类为例。

作为中国第一家,建一个网站,让大家可以在网上自己交易已经远不是什么新的生产力了,大数据量的时候保证信息质量,同时又可以最简单的发布,这是难题,需要解决;我们不断的面临以前从来没有人解决过的问题。不持续解决这个问题,其实就是把科技前沿让出来给别人解决。

技术的前进,就是做事情的方法的提高是必然的,而这种必然常常以功能表现出来。有大量的提高时没有界面的功能,比如Google的搜索,百姓网的骗子比例减少,的;还有大量的更好的做事情的方法是有界面的功能,比如按地域产照等等。加功能后面,必须是更好的做法来给用户他们要的东西。

理解这点,我们需要做到:1)挑难的做。有两件事情可以做,一件相对容易,对用户的帮助也小一些;一件相对难很多,对用户的帮助也大很多。我们一般情况下应该挑更难的。难的常常就是技术发展的地方。2)加没界面的功能也是加功能。3)从这个角度来说,的确我们需要不断的添加功能。创业公司如果不往前冲,很快会远离生产力最高的前沿,离开了这个阵地,创业公司就没有什么活路了。毕竟,创业公司有些象荷兰的商船,或者动物界的蚊子,是放弃了所有的武装,为了更快的速度而选择没有任何自卫能力,如果速度也没有了,就什么也没有了。

开发者的办公环境

一个好的开发者的办公环境是什么样子的呢?

  1. 安静的。安静的要死的那种环境。我不介意要戴上耳机听听音乐,但背景一定要安静下来。
  2. 风水好。所谓风水里面让人心里安静的那些因素都需要有。背后最好有柱子,有屏风可以看不到别人,可以安静的自己呆着。最好的状态是一人有一个办公室,隔离起来,但如果达不到也要有独立的空间。用盆栽的小树把自己围起来是一个好主意。(Amy,我决定用9盆我旁边的那种小树把我的座位围起来。请帮忙)
  3. 一流的网络环境。网速要快,默认翻墙,稳定。
  4. 有饮水机,有沙发,可以发呆,可以睡觉。必须有窗户,但要有完全遮光的帘子,以遮挡外面的光线。同时走路10步以内必须有一个可以向远处眺望的地方,让自己的眼睛可以休息一下。
  5. 不规律的时间。一定要故意做出点不规律出来,不规律不是重点,重点是不要让规律阻挡思考的自发节奏。当自己在努力写一些东西的时候,应该让自己写完,而不管是不是午饭时间。如果自己在一个地方卡住的时候,不要等到下班再休息,就应该在沙发上躺一下。如果需要,晚上晚点走,早上晚点来也是好主意。
  6. 耳机。耳机是一个非常好的表达不要让大家打扰的办法。在工作的时候必须尊重戴耳机的人的选择,并且形成一个惯例。
  7. Herman Miller Aron椅子。这是必须的。必须的,不要试图争辩。
  8. 两个屏幕?这个我还不是很确信。在我变成的年月里面,从来没有用过两个屏幕,但是或许有人需要。硅谷三个屏幕似乎是标配。
  9. 可调节的大桌子。桌子的高度如果可以调节最好。毕竟在全世界那么多的参数中间,这个和自己的关系最为紧密。
  10. 台灯。这个可能会被忽略,但是在晚上非常有用。如果房间的灯光关上,把台灯打开,这是一种非常好的入静的状态。放心,对于正在写东西的developer来说,这个状态决不会睡着。
  11. 无数的插座。没有比临时找不到地方插一个新的充电器更浪费程序员时间的了。

最后,这个办公室必须至少比程序员的家里舒服。必须的。所以按照一个最舒服超越自己在家里办公的规格设计就好了。

Baixing Graph API 0.2 发布

各位Hacker们,

今天乐高时间,我们将要发布一个还没有成型,但是可以初步展示我们要做的东西。大家可以自己先玩一玩。在给大家尝试的地址之前,我先说一下背景。

程序员的工作其实是增加社会财富。

社会财富的增加 = “效率提高” x “杠杆”。

“效率提高”是指是不是有更好的方式解决问题;“杠杆”是指这个提高会被多少人使用。单纯的提高效率如果没有足够长的杠杆,就像自己把自己的自行车洗干净,并没有对社会产生太大的影响;而在百姓网写一段程序,劳动量和洗自己一辆自行车一样,但杠杆长得多。这个杠杆,就是百姓网工程师每一个改动会被成几千万人使用。我们的一个小时劳动会带来几千万人每人节省或者浪费一分钟,这是巨大得社会财富的增加或者浪费。

而还有一个杠杆,就是我们的程序员的工具。工具的每一点提高,就会带来二十几个开发人员的效率的提高,再乘以几千万人,这个杠杆非常的长,产生的影响非常大。这就是工具组的产生的原因。

工具组小排和Hax花了一周的时间,把我们的第一个产品,Graph API的Alpha版本推出。这就是让大家用更加容易的方式访问到百姓网的所有数据和所有功能,且开始尝试建造新的语言,让大家更快的表达要表达的东西。

说到表达,更大家分享一个有趣的例子。前天学会一个新单词:Gape。原文是”I stood there gaping for a few seconds”。 Gape啥意思呢?一查字典,意思是:Stare, with mouth widely open。其实,如果学过编程的话,你会发现这是一个函数定义,

function gape() {

Stare();

Mouth_Widely_Open()

}。

如果你继续查Stare这个函数,定义如下 :

function stare() {

return directly(fixedly(look());

}。

也就是说,语言本来就是不断的定义,产生新的语言。如果小学生,会说look,或者会说“look fixedly and directly”, 如果啰嗦一点的小学生或许会精确的描述为: “look fixedly and directly, with mouth widely open”。但会用gape这个已经定义好的语言,就比啰哩啰嗦的说一大堆是更高级的语言,更加高效的表达了意思(风险是语言版本比较低的人会在脑子里蹦出来undefined function错误)。你会发现当一个人开始用成语和典故的时候,他的表达能力在加强。刚才的例子,gape是比stare更高级的语言,stare高于look,而look高于更底层的,大家没有听说过的语言,叫gaze。

而我们现在的语言,每一个函数,之所以那么长,那么恶心,那么读不懂,就是因为我们只会用php给的那些语言,那些语言不足以让我们表达。我们需要不断的定义class,就像miniChaoge一样,而且要让其他人使用这些class,功能,工具,我们的效率才会提高,才会往高级语言方向前进。

工具组要做的事情就是造语言,造函数,造工具,让大家能用一个词表达,就不要用那么多的词。

好,下面开始讲Graph API.

造语言,一定从最简单却最常用,且最麻烦的地方开始。这就是我选择了数据。如果有统一的方法访问到百姓网所有数据,以及他们之间的联系,大家说话一定会简洁很多。Graph API的一个绰号叫“百姓网数据解放运动”。

在Graph的世界里面,任何对象都是平等的,有一个唯一的ID,叫做gid (Global ID),只要知道gid,就可以用如下两种方式访问:

PHP里面,用graph($gid);

在外面,用http://graph.baixing.com/gid (返回JSON格式)

返回的对象包括所有的属性,并且描述了这个对象的所有属性(包括程序定义的,和Meta里面定义的),以及这个属性的所有的连接(比如Ad就有user,category这样的指向另外一个对象的连接,也有comment,log这样的返回一个数组的连接)。

为了更好的理解Graph,你可以想像百姓网的任何一个对象都是一个八爪鱼,向四面八方伸出触角。这些触角写在connections里面。通过在id后面添加触角的名字,你就访问到了另外一个对象(或者一组对象),从那里又是一个起点,可以继续访问。。。

举一个例子,我们从一个广告开始,227812140。

graph(227812140)

返回这个广告所有的属性。它还有如下的edge:

user -> 连到一个用户对象。

category -> 连到category对象

area -> 连到area对象

ip -> 连到一个关于这个ip信息的对象上。

user, category, area, ip等大多数对象有一个ad连接,可以返回一个数组,包含所有的ad

category,area等树状结构有parent,children等连接,还有一个特殊的path,返回从根到自己的所有对象的一个数组,用户拼面包屑用。

未来,会支持百姓网所有的信息,比如

mobile会支持call,就是呼入call centre 的所有log,通化时长,以及接线员工号等。

ad会支持付费的log

user会支持过去7天内,14天内,一年内的pv,pv在各个类目的分布等等飞哥那里有的所有信息,甚至每一行的访问log

这些只需要一些配置和数据准备工作。

大家应该可以看到这个graph的潜力。我们要让所有百姓网有的数据,和互联网上的数据,用统一的方式访问。比如刚才的ip对象,数据是来自于淘宝的,不是我们自己的数据库。比如:wiki:上海,就指wikipedia上面的上海的文章。通过统一了数据,我们让百姓网的开发速度大幅增快。

好了, 现在大家就可以测试了,请从这里开始,随便点击任何的可以点击的连接,并且注意URL的变化。

http://graph.baixing.com

建议大家用Chrome的Json View来看。Graph API Explorer Has正在写。同时很快大家就可以在chaoge代码里面开始使用

来访问数据了。graph的数据比JSON的数据完整很多。

未来:

在这里一定要强调一下,就是这一层仅仅是整个技术架构中间最最底层的一层,叫做数据层。它仅仅代表数据,但是不代表业务逻辑,不代表前端的展示。还有很多这一层之上的东西。我们需要在这一层之上不断的建设新的层,供上层来用。

工具组会在接下来的一周把这个Alpha变成production级别,可以在线上使用。写操作设计数据一致性,会跟随业务重构一个对象一个对象的支持。

jianshuo

百姓网Graph API 9月6日全国公测

工具组做了一个决定,在9月6日公开发布一系列产品和计划。

  1. Baixing Graph API
  2. Graph数据访问工具集的开源代码
  3. Jedi模版语言以及开源代码
  4. 手机客户端天使投资计划

我们会根据成熟程度在9月1日决定是否邀请媒体。

挨个解释如下:

1. Graph API和工具集

百姓网会公开Graph.baixing.com给外部访问。这仅仅是一个preview,会简单的根据IP限制每天千次请求,提供有限度的数据。这是让百姓网数据公开化的第一步。

同时,支持graph.baixing.com的所有源代码都将开源。我相信我们遇到的问题:大量数据无法用统一的办法访问,是一个中国互联网界比较普遍的问题,我们希望提供一些工具让大家可以每个人都很容易的搭起来自己的Graph,如果使用的人可以用类似的方式互通信息(在百姓网的Graph设计中,节点是不限于graph.baixing.com域名下的)。比如每个人可以简单的把自己的blog变成一个Entry/Category/User的graph。

2. Jedi模版语言。

解决以最快的方式书写前段,并且在服务器和浏览器都可以访问生成的HTML的问题。这也是一个业界的问题,我们把我们的成果开源,供所有人使用。同时我们那时候也应该在自己的环境中开始生成了自己的编程环境,供我们的Developer/PM写出更好的View Ad。

问题:为什么要开源?

一个公司要解决一个问题,百姓网解决的问题是“找工作,找房子,买卖二手”的问题。而技术人员解决的问题要具体的多,就是刚才提供的数据无法简单访问和连接,前端代码过乱等问题。技术人员的解决方案如果让更多的技术人员使用,会产生大得多得社会财富。Hacker的精神是在于让社会更高效,产生更多的社会财富,而不是挣钱(虽然对社会财富的增加的贡献,必定转化为自己的回报的信心)。我们愿意无偿给大家使用,因为捂在自己手里也是浪费。

另外一个目的,我们希望工具会变的更好。开源就有了不断变得更好的可能性,就会有外部的人参与维护(我是说长期,我是说有可能,不是必然)。这也敦促我们写更好的代码。

问题:百姓网为什么要开放数据?

其实对于Graph.baixing.com的对外开放,它仅仅是一个技术上的决定,并不会影响业务。真正的API,需要解决的不仅仅是技术上的“可以访问”,还要解决经济上的“愿意访问”。仅仅开放数据本身,几乎可以断定,没有人会有兴趣使用的。

历史上有一个很近的例子。Facebook曾经把自己的所有数据开放,就像现在的graph.facebook.com的样子,结果几乎没有developer理它,因为这个互联网上到处都是数据,拿到Facebook的数据本身不是一件让人有动力的事情。他们试了很多办法,直到做了一件事情:他们更改了逻辑,开始用Like按钮,用户按了以后,这个网站的地址将出现在News Feed里面。这也就意味着加了这个东西,网站的流量就会长。结果用疯了。不会有人会为了数据做事情,但有人会为了流量做事情。

在互联网上只有两种硬通货,一个是流量,一个是钱。百姓网只有有了很强的散布钱或者流量的能力,才有人会用我们的API.

先说钱。其实百姓网的所有的API的对象,一定是mobile developer。钱又有两种。一种是用户的钱,一种是百姓网的钱。用户的钱很有可能是让用户在移动应用里面购买该应用中的置顶,或者百姓网全系统的置顶,获取收益。这个稍微有些远。另外百姓网的钱,就是为了鼓励开发者,我们可以给出10万元的激励资金,占1%的股份的天使投资方式,在早期促进应用的开发。这就是我们说的天使投资计划。

第二部分,就是流量。如何通过用户发帖, 能够在百姓网上带流量给开发者,这是另外一个需要探讨的问题,很有可能使用发布信息加脚注的办法(类似于现在“使用iPhone客户端发布”那样的,但是更结构化,可点)。这样也是一种经济的促进方法。

这是一个以时间为限制的项目,工具组在看在这个时间前能够高质量的发布哪些东西。

百姓网Mobile的定位

在伟力展示手机组的数据的时候,我在想一个问题:如果这是家独立的移动互联网公司,他的估值是多少?

这个问题在整个review期间持续的萦绕在脑子里。我问的问题是:百姓网手机组到底在解决什么问题?

有两个可能的答案。

答案一:百姓网手机访问不方便的问题。
答案二:百姓找工作找房子买卖二手不方便的问题

这是两种完全不同的思路。

如果把手机组当做一个公司的话,解决第一个问题的公司是一家软件外包公司,是为了一个客户(比如说百姓网)而做手机客户端,WAP产品的一家软件公司,这家公司的最终客户是百姓网,这家公司的业绩是功能的完整度,软件质量等等指标。

但解决第二个问题,视野完全不同了。比如如果手机要解决的找工作的问题,这个问题的三个重要的子问题都需要解决:1)可以发可以看而且很顺畅 2)有足够多的人在这个市场里 3) 内容使用户要的,包括质量和信息组织(就是类目)。

我坚定的认为手机组不是一个软件开发公司,是一个解决用户需求的公司。从这个角度上说,手机组的使命和百姓网一样。

百姓网提供了一个基础的数据,但手机需要站在这个数据的巨人的肩膀上再进一步。手机必须解决类目结构不合理,名字不好的问题;手机也要解决质量问题。手机完全可以自主的更改类目名的mapping,可以率先把中介信息不显示,可以做数据的任何处理,只要这是围绕着通过连接生活需求帮用户解决问题的主线就可以。我不仅同意,且支持手机组拿到数据后大跨步的往前走,在现在的百姓网的高度上,无论从功能,还是数据上有一个大的提升。

Mobile团队可能会因为百姓网好的地方而成功(比如大的数据量),也会因为现在的差的地方而失败(比如类目,质量等),我希望手机组可以拿出创业家精神,继续使用好的地方,剪断和坏的地方的联系,象黑客和海盗一样,不遵循规则,做自己需要做的事情。

对于和其他团队的合作,我希望把手机组和网站,质量等各组之间的关系看作几个开源项目之间的关系,互相依赖。如果可以方便的开一个bug,并且很快可以被修复,就让另外一个开源项目的人修复(最好的状态)。但如果不是另外一个项目的重心,但极大的影响了自己的使用,请按照开源项目的规矩办:把代码拿过来,自己改掉。自己动手丰衣足食是hacker文化的核心,在此基础上的协作才叫interdependant,而不是independent。

很快百姓网的数据就会开放,会有一些软件开发公司涌现,而Mobile团队不是软件开发公司。你们是一家为用户解决问题的公司,使用百姓网优秀的地方,大胆的反抗百姓网不好的地方。手机不仅应该,而且必须有不同的功能,更好的数据(mobile团队自己的数据),更好的用户体验。

我理出来一些付费需求

  1. Ding(类目,Tag,全省,全国)
  2. 价格(置顶竞价,配置配置)
  3. 端口(发帖限制,刷新次数,显示不同)(名字有房,车,招聘,服务)
  4. 刷新(5元一次)
  5. 跨城市发布(10元一条)
  6. 要按天的责权发生制记帐
  7. 送天数
  8. 退款
  9. 自动发票/合同
经销商系统需求
  1. 可以代付款
  2. 可以设指标
  3. 可以算业绩
  4. 可以自动分成

真的那么难吗?

百姓网Mobile的定位

在伟力展示手机组的数据的时候,我在想一个问题:如果这是家独立的移动互联网公司,他的估值是多少?

这个问题在整个review期间持续的萦绕在脑子里。我问的问题是:百姓网手机组到底在解决什么问题?

有两个可能的答案。

答案一:百姓网手机访问不方便的问题。
答案二:百姓找工作找房子买卖二手不方便的问题

这是两种完全不同的思路。

如果把手机组当做一个公司的话,解决第一个问题的公司是一家软件外包公司,是为了一个客户(比如说百姓网)而做手机客户端,WAP产品的一家软件公司,这家公司的最终客户是百姓网,这家公司的业绩是功能的完整度,软件质量等等指标。

但解决第二个问题,视野完全不同了。比如如果手机要解决的找工作的问题,这个问题的三个重要的子问题都需要解决:1)可以发可以看而且很顺畅 2)有足够多的人在这个市场里 3) 内容使用户要的,包括质量和信息组织(就是类目)。

我坚定的认为手机组不是一个软件开发公司,是一个解决用户需求的公司。从这个角度上说,手机组的使命和百姓网一样。

百姓网提供了一个基础的数据,但手机需要站在这个数据的巨人的肩膀上再进一步。手机必须解决类目结构不合理,名字不好的问题;手机也要解决质量问题。手机完全可以自主的更改类目名的mapping,可以率先把中介信息不显示,可以做数据的任何处理,只要这是围绕着通过连接生活需求帮用户解决问题的主线就可以。我不仅同意,且支持手机组拿到数据后大跨步的往前走,在现在的百姓网的高度上,无论从功能,还是数据上有一个大的提升。

Mobile团队可能会因为百姓网好的地方而成功(比如大的数据量),也会因为现在的差的地方而失败(比如类目,质量等),我希望手机组可以拿出创业家精神,继续使用好的地方,剪断和坏的地方的联系,象黑客和海盗一样,不遵循规则,做自己需要做的事情。

对于和其他团队的合作,我希望把手机组和网站,质量等各组之间的关系看作几个开源项目之间的关系,互相依赖。如果可以方便的开一个bug,并且很快可以被修复,就让另外一个开源项目的人修复(最好的状态)。但如果不是另外一个项目的重心,但极大的影响了自己的使用,请按照开源项目的规矩办:把代码拿过来,自己改掉。自己动手丰衣足食是hacker文化的核心,在此基础上的协作才叫interdependant,而不是independant。

很快百姓网的数据就会开放,会有一些软件开发公司涌现,而Mobile团队不是软件开发公司。你们是一家为用户解决问题的公司,使用百姓网优秀的地方,大胆的反抗百姓网不好的地方。手机不仅应该,而且必须有不同的功能,更好的数据(mobile团队自己的数据),更好的用户体验。