面向个人的互联网财经服务产品的思路

春节前和老友胡吃海噻了一次,中间谈了谈面向个人市场的财经类服务产品的想法。这几天仔细想了想,特记录在此,权当一家之言,供老友参考,也供自己沉淀。

 

I 首先要确定产品的vision。

有句话说的好,”Good products have focus. Great products have a vision”。在细节争胜之前,我想先确定产品的境界品味是什么。眼界有多高,才能走多远。目前在未来几年内的时间,可以看到的理念,就是“帮助更多的人更方便的理财”。

原因有这么几个:

1) 经济大环境的影响,使得越来越多的人重视理财。中科院预测2011年CPI约3.7% 房价增幅12.77%

2) 网民年龄层次的变化,20~39岁这个年龄层次所占的比例已经在50%以上,且在不断增加中。(CNNIC报告)。对资金/资产的保值增值的需要会越来越强烈。

3) 在2009年末到2010年末这一年当中已经有超过40%的比例会通过互联网方式进行理财交易。并且储蓄、股票、基金的投资在2010年有较大幅度下降。而更多会投向在黄金、外汇这几个市场。(金融电子化趋势明显)

 

II 其次是提供什么功能的产品:

如何帮助人更方便的理财,首先先分析个人理财操作的环节:

我将个人投资者的投资行为按照时间顺序分为事前(发现)、事中(交易)、事后(服务)三个阶段进行分析:

A) 发现:通过自己的投资分析也好、别人的指点也好,结合自己的实际情况,找到适合自己的投资品种和点位。

B) 交易:通过网上交易、电话交易等手段实现交易。

C) 服务:接收人工或者自动的提示,交易后获利或者止损。

用以上的标准来衡量一下当前市场的产品服务,以和讯为参考样本,有以下几个特点:

1  产品侧重于发现环节,有两大类基础实现模式:

a) 自动化工具,侧重于金融品(物)数据的整理和分析,大致分为2个等级:数据的积累和简单分析再包装,例如资讯栏目、研究报告、资金流向、行情中心等,属于免费级别;数据的深度分析,例如和讯的A股超市、行情分析系统等。

b) 人工互动,侧重于提供交流平台,推出理财顾问。有博客、VIP圈子、微博的实现途径。通过理财顾问(带头大哥)的推荐,来发现投资品种。

2 交易环节的缺失:连简单的web交易网页导向的链接也没有提供,这也可能和以往的用户习惯有关。但是在web交易量占网上交易总量的10%以上的今天,不能不说是件憾事。

3 服务环节的简单化:通过我的股票、我的基金等自选股的方式,实现对用户在交易系统中自选股/持仓股方式的模拟,和股吧关联网友讨论。使用过程中依赖用户自我完善,无股价提醒、相关资讯更新,以及收费产品服务的推荐。

 

了解as-is之后,结合产品的vision,to-be的产品应该有这么几种功能:

1 更方便的使用发现环节:由用户自动挖掘变成被动接收。增强财经特色的个人门户,以关注股/交易品种为核心,将人和对应的股评师、资讯、资金流向变动、博客、微博进行串联,降低发现环节的使用难度。这是自动化工具可以提供的。备注,这也是我目前研究的方向。

2 更有效的发现理财顾问:形成统一的理财达人名片,整合微博、博客、圈子、股吧等数据,并提供分类、排名、推荐等多种排行榜。

3 建立多维度上的综合理财账本。跨越股票、基金、外币、黄金、银行、现金、虚拟币等交易品种。提供记账功能和虚拟币的交易功能。备注,虚拟币用于各种服务产品支付。在理财账本基础上,推出自动化理财目标分解工具或建议,向方便理财的目标前进,并为引入更多品种的理财规划师做好准备。

4  完善交易、服务环节:引入自动化服务工具(手续费率计算器、价格预警、持仓分析);人工介入的团购应用。

 

III 产品意犹未尽的细节:

1 虽然我是一个微博控,但在特定行业内,除了人和人做节点外,还多了一些物(股票、圈子、股吧)做节点。我不单单会关注人发出的信息,还会将更多的注意力放到股票等节点发出的信息。目前看到这些信息串联方式的展现,更好的是SNS平台的feed机制。

2 如何更好的发现,是一个有意思的问题。传统的方式是对股票数据本身进行充分的挖掘,形成各种指标和交易方法,自动化最厉害的莫如Auto Trading System,如jsystemtrader海洋部落等。现在由于互联网的介入,尤其是web2.0的参与,通过金融心理学的方式去研究股市,也慢慢地变成了一个热点,如基于复杂网络的证券投资行为扩散研究玩聚之股市风向标Twitter情感词预测3天后的道琼斯指数等。如何将这种方式更好的与发现环节互动,值得玩味。

 

 

 

Advertisements
Posted in Uncategorized | Leave a comment

《社交网站界面设计》读书笔记

就是这本书,http://book.douban.com/subject/4909176/

这本书针对现在网络上比较流行的社交功能,做了归纳总结,“ 首先谈到了和“自我”有关的模式(用户身份ID、在线、约会、声誉)和社交对象有关的模式(收藏、分享、广播、出版/发布、反馈、沟通、协作、社交搜索),以及和社交图谱、地理位置有关的模式(个人关系网、社区管理和地理定位);

同时也探讨了有关社区管理、许可以及开放标准方面的模式。提供了一些指导所有模式的原则:a)像人一样交谈;b)为每个人设计;c)要开放的考量。

最后提到,由于不同的传播机制、应用背景和用户种类,社交设计会显得非常复杂。即使是非常简单的界面(BBS),它所产生的社交体验也是非常寻常的。作为设计师,我们真正能做的,通常就是为某事的发生构建一个空间,然后默默离开。” 我很欣赏最后的这句。

书中除了谈到很多有趣的模式之外,还对“零启动状态”做了一番建议:“ Onboarding 可以帮助用户克服零状态启动的问题–空白的个人资料、陌生的界面、接下来我该干什么的感觉。许多网站强迫用户独自从社区广场开始,逐渐构建内容(和价值)。” “让用户适应你的网站,就要在网站上给他们想要且需要的工具。同化,就是要帮助用户吸收网站的文化,并且,从某种程度上说,就是要让他们变得与网站的现有用户类似。提速,就是要将网站的产品理念在用户身上得到体现,并且发扬光大。”

总结了这些模式,就是为了建立用户的心智模型(心智模型是用于解釋個體為現實世界中之某事所運作的內在認知歷程。 from 维基百科),让用户拥有像汽车心智模型一样的计算机心智模型。出现问题时,用户就不会手足无措。

在这本书里,除了对模式的总结外,吸引我的还有一些关于社交网络的思考:

“社交网络:专注于构建在线社区的一种服务,社区中的用户有着共同的兴趣或活动,或者他们都想探索新的兴趣和活动。

社交媒体:利用数字化、网络化的工具来达到与他人共享、讨论信息和经验的目的。

社交对象:简而言之,只是两个人对话的缘起,而与其他无关。人类是社会性的动物。我们喜欢社交生活。但是如果你思考一件事情,首先就需要一个话题让人们开始对话。这个话题,就是社交网络中的一个结点,我们把它叫做社交对象。

作为社交网站的设计师,首先需要定义在网站上所提倡的活动类型。你是想让人们收藏信息,还是共享信息?你是否对用户贡献内容感兴趣?或者你是否想围绕某种特殊类型的用户原创构建一个框架?它将是整个社交系统的核心。

当你着手处理某种社交活动及其相关子活动时,你需要定义与此活动相关的社交对象。

没有社交对象时,你也可以与他人进行对话,但是你却不能只有社交对象而没有对话。只有通过对话才能让社交对象有社交基础。

对话围绕着社交对象展开。非常像珍珠是包裹微尘而生一样。社交对象是会成长的。

一个成功的社交对象是逐层附着在对话之外的,它是围绕对话而生的;随着参与者的增多,社交对象也会从网络本身的优势中受益。

社交对象的元数据:采用HTML标记结构、人为标签、电脑标签、网址、网页标题、导航结构和内部链接的应用程序创建的对象。”

的确,社交对象和元数据给我很多启发,人和人之间的互动,尤其是跨越单层联系网的人之间的互动,严重依赖与社交对象和其中元数据的抽取。基于地理位置、工作单位、兴趣爱好的这样标签形成的元数据,对于促进社交网络的扩展,有较大的帮助。

更有效更直接的,是针对对话,提取元数据来形成社交对象,更直接地扩展接受信息的深度和广度。目前正在尝试做一个股市的信息收集器--股蚂蚁,将股票代码做为元数据,把微博做为社交对象,通过对微博元数据(股票代码)的扫描和计算,分析目前正在热议的股票,做为投资者的选股的一个自动化参考工具。

下一步将会继续针对社交对象、元数据的分析和集合,继续尝试社会化自媒体的实验之路。

Posted in Uncategorized | Leave a comment

开放平台的思考

今年花了大半年的时间,参与了一个网上开放式平台的建设。其中有很多值得反思的地方,趁着年末做个总结。

1 首先,值得反思的地方,就是什么是开发式平台?

在网上查了查定义,

百度百科:开放平台(Open Platform) 在软件业和网络中,开放平台是指软件系统通过公开其应用程序编程接口(API)或函数(function)来使外部的程序可以增加该软件系统的功能或使用该软件系统的资源,而不需要更改该软件系统的源代码。

wikipedia: 在软件和基于Web的体系结构,描述了一个开放式平台的软件系统,已发布的软件的功能在其他方面比原来的程序员打算源,而无需修改代码的外部编程接口,允许使用。 使用这些接口,通常是被称为应用程序编程接口 (API)的,一个可以整合第三方的平台添加功能。 开放式平台并不意味着它是开放源码 。 开放式平台可以由软件组件或模块,是商用或开源或两者兼而有之。

这个和我年初的理解是相近的,经过半年多的建设工作和思考,觉得这个定义太技术化,最重要的平台性质反而没有揭示出来。

分析开放平台的参与角色来看,会有这种几种角色:平台本身、用户、APP开发厂商,另外还有一个重要角色,Ad投放商。

这样就可以看到一个完整的利益分配链条,平台和APP开发厂商做为利益接收角色,用户、Ad投放商作为利益投放角色(有时平台本身也可以做为利益投放角色,比如Sina,一般在平台建设的前期常见)。

开放平台不仅仅是一个技术平台,是一种商业生态环境。它能吸引其它角色进入平台,要么做为利益输入方,要么做为最终用户价值实现方,一起在平台上运作,一起增值,使平台具备完善和发展的能力,形成一个正向回馈的循环。

没有利益做为引导,单单靠自我的产品包装和开发,很难走远。

2 开放式平台的核心问题是什么?

我觉得有两点,1是最终用户的价值实现,2是利益输入输出通道。重中之重是第一点的建设。用户上facebook,了解朋友动态;上新浪微博/Twitter,了解发生了什么事;用iPhone,满足自己的心理需要。这些都是用户价值实现的体现。

回本朔源,就是平台为用户提供了怎样的核心用处。这是用户用这个平台的出发点,有了这个出发点之后,才能谈上平台的建设。盲目地堆砌功能,通过面的覆盖来留住用户,经常听到外面的朋友说,“综合现在所有的功能,这个功能你不用,还有那个功能,反正估计总有一个功能适合你”,“别的网站有这样的功能,赶紧抄一个“。(专门注明:非原来所在的平台团队说的)。Google wave已经证明了这条路是很难走通的。核心价值的缺少,只能通过人工方式的弥补,如果再加上人工的不专业性,平台化的这条路会走得比较艰难。

利益输入输出通道,这个不想多说,也说不出来。难点在于1)如何以小博大,赢得广泛的合作伙伴;2)如何将获取的利益进行合理的分配。

整理了份PPT,放到了http://www.slideshare.net/sfwfree/ss-6388481

声明一下,很多内容都是从网上摘录,非常感谢开放的互联网。

关于离职,也许这句话很合适,”当你无法通过提升自己的能力来打破环境限制时,就可以辞职了。” from http://firecacada.blog.163.com/blog/static/7074376201011266453740/

Posted in Uncategorized | Leave a comment

软件架构的魅力6–读书笔记

最后一篇了。这本书 http://book.douban.com/subject/3669563/ 反反复复读了三遍。其实读到最后一遍,已经不关注书里在说什么了,而是关注作者为什么这样说,他们的理念是怎么得来的?

从中感悟出一些方法论上的东西:进入一个领域,先要理解概念,然后抽取共性,形成全局运转图,从顶到下,共性归类,建立起隔离带,再逐步细化,形成整个的系统概念。

软件产品线架构:

何谓软件产品线?SEI的定义:A software product line is a set of software-intensive system that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

软件产品线的几个重要特征:

1 有产品家族,一系列的产品成员。

2 所有产品都是服务于一些特定相似的领域。

3 成员有相同或相似的功能,这些功能来自一些公共的、固化的、并且是受严格管理的核心软件资产。这个应该是软件产品线的核心。

4 产品是在一种严格规划和管理的有序状况下系统化进行的工作。

将多个产品整理为产品线架构,有个产品线架构变革过程模型PLAEM供参考:

PLAEM:Product Line Architecture Evolution Model

需求分析阶段->系统架构阶段->构件设计阶段->测试及配置管理->产品线演化阶段->技术及管理因素

其中最重要的就是产品间的共性和可变性分析:Commonality Analysis和Variability Analysis。

1 共性和可变性分析,会在产品线的应用领域内界定公共词汇,奠定公共的沟通基础。

2 分析结果有助于界定一个产品家族可能的范围。

3 分析结果最终严格确定了产品家族中每个成员所具有的相同的功能或特性,这是产品线的共性部分。

4 精确定义产品家族每个成员所具有的独特的功能或特性。这可以包括使用环境、组成结构、功能行为、控制流程和逻辑的各异性等,这组成了产品线的可变性部分。

5 产品线中各个产品的各异功能或特征的变化范围,需要严格定义,这将最终定义成为一个变化区间。这是系统的弹性,演化的范围。

共性/可变性分析流程:

识别和划分领域->单个领域共性分析->单个领域可变性分析->将一些可变性化为共性->可变性可变范围参数化->设定可变性的绑定时间(注:指在空间/范围维度、时间维度的变化可能性,以便设计人员能够应用不同的绑定方式来应对每个可变性的发生。)

在分析过程结束后,进入构建阶段。参考业界产品线的实践,有两种方式来构建自己的产品线架构:

1 框架风格的产品线架构(Framework):构建一个通用、可靠的整体产品的总架构,一个其领域内的应用框架(非公共开发框架),类似J2EE这样风格的。

2 标准产品风格的产品线架构(Standard Product):采用一个标准产品作为应对变化的基石,所有的各异性要求都是在对该标准产品客户化定制的基础之上进行应对。

一点感悟:框架风格的产品线架构,一般是国际大公司的价值基础,像国内的小公司是很难支撑起这样的工作量和难度。

しゅうりょう

Posted in Uncategorized | Leave a comment

软件架构的魅力5–读书笔记

在实际工作,我们往往不会从头构建一个新系统,而是接手老的系统,进行重构升级。在这种情况下,掌握一些重构的模式有助于提高工作效率:

1 统一全局命名规范和编码规范,搭建共同的沟通标准。(非常重要)

2 识别公共功能,转移封装到统一的系统元素中。

3 采用LSP原则定义层次结构。

LSP原则:Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. (采用OO原则)

4 以适配(Adaption)方式替代中介(Mediation)方式。其实就是以谁为主的问题,如果能找到一个总线,那采用适配方式是不错的。适配方式的一个典型应用就是ESB,Enterprise Service Bus。

5 合并子系统。“子系统间松耦合,子系统内紧耦合”

6 强化层间调用,避免跨层调用

7 以Message通信替代RPC。(不错的点子)异步处理能较好的提高系统的响应能力。典型的例子就是北京奥运会的订票系统。

8 以Caching方式优化资源利用。(不错)这个不用多说,cache是什么方式都无所谓,我曾经直接生成文件做cache。

9 避免构件Interface的膨胀,这样的膨胀可能会导致系统代码的混乱。解决办法,可以引入一个接口的层次结构关系,进行再次分包。这点挺有意思的,可以避免我原来的很多坏习惯。

10 使用配置,管理子系统和构件。

つつぐ

Posted in Uncategorized | Leave a comment

软件架构的魅力4–读书笔记

构建一个系统架构,最终极的目标就是要让它完美无瑕。美是一种和谐,体系中的每一部分都是有机的组合,增一分则长,减一分则短,可是要做到这一点,绝不是一件容易的事情。

如何保证和提高软件系统的质量,首先要解决的问题是定义和度量问题:
1 软件系统的质量包括哪些方面?
2 如何将质量的各个特性转换为可度量的要求?

1 质量考虑哪些方面:
首先参考文献和通用定义,SEI将一个系统的质量分为Level 0和Level 1两级层级,Level 0分为5大类:Need Satisfaction Measures, Performance Measures, Maintenance Measures, Adaptive Measures, Organizational Measures。
而在实际工作中,可以将质量聚焦在两个大的方面:
A 系统运维质量:当系统运行时的质量要求。包括Functionality, Concurrency, Performance, Security, Availability, Fault Tolerance, Usability, Interoperability, Resource Management等。
B 系统演化质量:系统发展演化所要求的质量。包括Modifiability, Portability, Reusability, Configuration等。

将质量进行分类后,可以将各种分类的处理机制进行归纳总结,形成特定的指导准则,作为”点”上的质量战术,比如Architecture Principle,Design Principle等,以Concurrency为例,指导规则就有以下几个要求:
a Client/Server之间的关系:长链接 or 短链接
b 服务请求的处理:同步 or 异步
c 服务请求的顺序:优先级处理
d 服务种类:服务间依赖性
e 服务时限:无要求 or 有要求
f 服务与资源

解决一系列质量方面的要求时,并非一蹴而就,通常要从”面”上的核心功能与”点”上的质量战术设计上,进行相互结合印证,才能得到一个高质量的架构。

核心功能由于和系统建设要求密切相关,给出一个通用的质量保证流程:
a 清晰界定系统的核心功能
b 界定实现核心功能而必须提供的系统级基础框架
c 清晰构建核心功能之间以及核心功能与基础框架之间的协作与交互
d 综合考虑系统质量的要求,从而使系统核心功能的分布、系统基础框架的分布以及核心功能的协作与交换能够满足系统质量方面的要求

2 衡量系统架构的质量:
衡量质量方面,虽然有DESSA五维模型做参考,但基本上靠系统工程师的个人经验做保证。
A 架构和设计模式的密度(Density)
设计模式的密集度,而且是用得恰到好处。

B 架构的匀称性(Symmetry)
代码的味道

C 架构的简洁性(Simplicity)
KISS, Keep It Stupid Simple.

D 架构的表述能力(Expressiveness)

F 自适应能力(Adaption)

つつぐ

Posted in 读书笔记, 技术思考 | Leave a comment

软件架构的魅力3–读书笔记

由于现成的框架往往局限于特定的知识领域,在不同的领域中,引用同样的框架指导就会存在一定的风险。所以还有一种方式指导架构师工作,就是对架构过程进行抽象的流程化、规范化。

其中来介绍一种流程模型,系统架构BABSC流程模型,(BABSC Architecture Process Model),主线流程有5个核心阶段:

B 构建商业架构概念 Business Architecture Concept

A 构建应用架构概念 Application Architecture Concept

B 确立和稳定架构基线 Architecture Baseline

S 子系统架构及设计 Subsystem Architecture and Design

C 构件与单元设计 Component / Unit Detail Design

通过商业架构概念,来了解清晰所要构建的系统是什么,以及怎么运作。

通过应用架构概念,清晰系统边界,让所有人对系统有一个稳定、清晰、准确的认识和概念

通过确立和稳定架构基线,从技术上阐述系统的结构、接口、部署方式、通讯方式、质量规则和约束等。

子系统架构及设计和构件与单元设计,为系统的设计细化和实现。

------------------------------------------

Step 1 构建商业架构概念

主要是建立一系列的系统化概念:

what 系统的要求

when 实现的时间

who 负责的角色

how 实现的方法

why 实现的目的

即”利用各种商业建模手段,全面清晰地构建商业领域内的组织结构关系、商业功能、商业流程、信息交互、商业结构地理分布、商业规则和约束条件、商业目的、战略决策等商业概念”。

其中产出物很多,重要的有术语字典(统一概念)、商业运作图、组织结构、事件模型、流程模型、商业数据模型、规则和约束。

Step 2 构建应用架构概念

系统化地规范:当新系统投入使用后,构想其商业运行的各种重要环节及信息交换发生的变化,清晰定位系统边界,建立系统基线架构的工作基础,架构远景(Architecture Vision),让架构人员、设计人员等对未来投产的系统有一个稳定、清晰、准确的认知和概念。

商业架构定义了现在的商业运作情形和运作时的结构,应用架构则定义了设想中的情形和结构。

产出物和商业架构的类同。

Step 3 建立和稳定架构基线

整体工作的重中之重,要求规划出整个系统的切分,系统的功能划分,切分系统的分布,系统间的接口及交互,系统间物理通信结构,系统间功能协同,系统物理数据模型,整个系统及各个子系统的质量要求,系统功能演化计划,系统架构/设计/实施所参考的标准。

这是最考验系统架构师功力的一个重要方面,要求面面俱到。

Step 4 子系统架构及设计

子系统架构师成为主角,进行架构设计的迭代工作。

Step 5 构件与单元设计

Detail Design

更多的细节见这本书: http://book.douban.com/subject/3669563/

等我们做完系统架构的工作后,必然有一个问题,怎么验证质量?

つつぐ

Posted in Uncategorized | Leave a comment