Benking

关于桌面软件取名问题

三 14

Ben产品设计, 投资理财, 项目&管理 取名, 数米基金宝, 软件 No Comments

数米基金宝2009

数米基金宝是我们公司的一大特色软件，可以理解为“基金业的同花顺”。记得07年底，公司决定开发一套客户端基金理财软件（大众型），项目落在我头上，具体开发外包给一个专业的C++外包人员（此人现在已经是基金宝的项目负责人）。公司要求在08年初就要看到产品，并正式发布给用户使用，当然我们也不负众望于08年第一季度发布正式版。

第一个正式版叫“数米基金网基金投资分析决策管理系统1.0”，是不是很土？我也觉得很土。当时取这个名字的目的貌似为了申请专利，但的确不好听。

不好听就得改，于是针对取名问题，公司举行各种大大小小的会议，最后确定为“数米宝”（因为当时网站叫数米网）。

后来数米宝又经历过一次改名，原因是咱们软件里没有“基金”两个字，于是更名为“数米基金宝”。如此频繁的改名自然对用户也会有一些影响，于是就有用户问我们客服人员：

数米宝、数米基金宝、数米基金网基金投资分析决策管理系统有什么区别？

当然，没有任何区别，就是一个东西。由于个人精力以及公司战略的考虑，我把项目移交给另一位负责人，并成立独立产品部门，持续的做下去。

08年下半年，我们发布了“数米基金宝2.0”，项目组开始筹划下一个版本，如今2.0发布了，下一个版本较啥名呢？于是大家就在想，2.1、新春版、2009，由于2009年是牛年，似乎应该考虑和“牛”扯上关系，又想了很多与“牛”相关的名字，但都被否决了。最后确定为2009版，登录界面做的喜气洋洋，整体界面也有调整，并于2009年上半年发布。

这个名字似乎也合情合理，2009年发布的软件叫2009也无可厚非。但还是有些有趣的用户提出一些有意思的问题：

“请问，咱们这个数米网的基金宝2009版是不是只能在2009年使用啊？”

无语中……“不是的，一直都可以使用的，2010年也可以使用”

“那既然2010年可以使用，为什么叫2009呢？”

客服一阵狂汗！！继续无语中……

这里要说明一下，有一段时间服务器不太稳定，导致数据更新有些迟缓。用户没有及时获取到最新数据，加上这名字，不免会提出这样的疑问。

其实名字也就是一个代号，叫什么都无所谓，关键在于能够容易被大家熟知，利于品牌推广就行。但如果名字一直改个不停，我想未必是什么好事情。

如今已经是2010年，我们还没有发布下一个版本，于是产品负责人就在会议上提：“什么时候发布2010版啊？这2010年都已经来了，再晚恐怕不是很好”。

领导们开始深思，大家也开始讨论，有人开始发问：“为什么一定要跟年份扯上关系呢？人家国外的软件都叫1.0、2.0升，而且上升的幅度非常小”。的确有道理，没有必要和年份扯上关系，但如果已经扯上关系了，就应该继续下去，腾讯就是一个很好的例子。

那到底我们下一个版本应该叫什么呢？3.0  or 2010 or 2011 ….

虽然名字只是一个代号，但也不是拍脑袋拍出来的，频繁的改名实际上对用户也是一种折磨，最后搞不清楚叫啥名儿。回头用户打开软件，一自动更新，名字变了、桌面上快捷方式的图标也变了，东西不见了，这下该咋整呢?

闷骚一把，关于Logo

三 08

Ben产品设计, 技术相关 flickr, xpress, xpressr No Comments

刚设计好的Logo

是不是发现拼错了，之所以拼错，也是无奈之举啊。同样的例子

同样的故意拼错，会不会当年flickr注册域名时和我遇到同样的问题呢？
顺便通知一下，DsJian2.1.0 更名为 Xpress 2.1.0

3月份DsJian 2.1beta会正式和大家见面

二 07

Ben产品设计, 技术相关 ASP.NET MVC, DsJian2.0, Wordpress, 开源博客 5 Comments

经过了很长一段时间，DsJian2.1终于接近尾声了（特别说明，中途重构了一次，因此版本 +0.1 ）。

这个版本是全新开发的版本，除了基本架构保留1.0的之外，其他几乎所有东西都重构了。期间认真学习并参考了WordPress的设计理念，受其影响，以至于后台管理布局也有很多雷同之处。并吸取到一条教训：以后若要做产品，记住，先自己想，不要一开始就去看一些优秀的产品，否则你的设计思路会不知不觉的跟着这些优秀的产品走，且一发不可收拾，

更多信息，可以点这里看看

简单列一下features:

• 基本博客功能（文章、页面、链接、评论等）
• trackback 发送
• 内置邮件发送
• 自定义文章伪静态地址
• 附带数据缓存，提高访问速度
• SEO相关（sitemap、rebots等）
• 文章、评论 Rss 等
• 支持完全自定义主题
• 多作者撰写支持
• 数据导入与导出
• 便捷安装
• IIS6与IIS7经典模式支持
• Gravatar 身份认证
• 多种数据库支持（Sqllite, MySql, MSSql, Access等）
• …

show 一些截图：

管理后台

分类管理

前台仍然保留 iNove 这套主题，后面可以自己做一套默认主题

我们是如何做产品的

一 01

Ben产品设计, 投资理财, 项目&管理 产品设计, 原型设计, 基金比较, 基金筛选, 用户调查, 竞争对手分析, 需求分析, 项目管理 No Comments

最近刚完成基金筛选器、基金比较，这两个小产品。但其实在我的构想中，她们俩是同一个产品一下的子功能（这个产品我称她为“选基平台”），只是由于时间、资源等因素，目前仅实现这两个功能。

由于“刚出炉”，放在手头还比较热，于是趁热用她来做一个例子，谈谈我们是如何做产品的。

1、思路思路

如何确定要做一个产品，理由可能是多种多样的，这里就不再详细叙述了，留在以后的篇幅中。而我们确定要做选基类产品是在年初定下来的，相关人员聚在一起讨论今年的KPI，这个时候就会定下来今年大致的产品发展思路。

到了具体要做的时候，就会想了，咱们的选基平台到底会实现什么样的功能？在设计之前，我通常会首先做几件事情：

• 用户调查：目前这是最弱的部分，仅收集与总结用户的反馈，看看这方面的需求情况；
• 竞争对手分析：这一步比较重要，我会把所有对手的类似产品都看一遍，找出他们的优缺点，该吸取的吸取，该抛弃的抛弃。当然也得结合自己的特色；
• 大量广泛的查阅：如果在你要做一个产品之前，对她的概念比较模糊或根本不知道应该怎么做，你应该大量、广泛的查阅。并适当的做记录，对以后的设计阶段会有帮助；

当然还有很多工作，如需求分析、可行性验证等。一边做这些准备工作，一边整理这些思路。准备工作做好后，产品构想大体就完成了：

这个时候，可以把大大小小的相关人员聚在一起，谈谈你的构思。大家会对的构思提出各种各样的建议与意见，如果顺利，差不多这样一次会议就确定了。

2、原型设计

大家对你的构思认可后，接下来基本上是真刀真枪的干活了。大一点的公司，通常是一组人一起做设计（这些人我们称为PM）。像我们这样的小公司，没实力请这么多人一起做，通常由内部人员兼任。

由于前期已经有了很好的构思，这个阶段基本上就是按照你的构思做设计，在设计的时候会考虑到很多问题，比如：

• 整体布局应该怎样：两栏、三栏，还是其他。通常在这个问题上会纠结很久，确定以后，接下来的事情就好办了；
• 如何布局页面元素：例如，如何合适的摆放大量的筛选条件，这成了这次设计的难点之一。当然最终还是解决了，具体解决的好与不好，需要看上线后的反馈；
• 以使用者的角度来思考：易用性的好坏实际上大多数取决于设计者所处的角度。我是从技术出身的，在设计的时候一些技术上的事情难免会左右我的想法。但我还是会尽力以用户的角度去思考如何设计；
• 商业价值思考：这一点也应该考虑。在一个初期版本中，也许不会有这些内容，但在设计阶段至少应该考虑一下，留一些口子；
• 结合推广的一些思路：对于初始版本的产品，通常这一步比较困难，记得我们在开产品设计PK会的时候，运营负责人就会想是不是应该加入一些有利于推广的内容在里面。但由于这样一个产品功能性太强，不便于在这个版本上实现，因此也暂时搁浅了，留在后期版本上实现；

整个原型设计阶段，可能都需要你全身心的投入进去，以至于达到“走火入魔”的状态最好（开玩笑的，呵呵）。最终完成原型设计：

+ 

接下来可以开展原型讨论会，这是比较“痛苦”的一个环节，大家会提出各种各样的需求与建议。你会根据这些建议进一步的思考是否或应该如何改善设计，并找时间再次组织讨论。

通常这类会议进行2～3次，具体最终什么时候能够敲定，就看你在做产品原型演示时的忽悠功底了。最后老板发言：“好，就这样做吧”，得到这样的信息后，说明你的产品原型设计阶段顺利完成，可以正式开工了。

3、项目排期与开发

这个阶段，你需要一个或多个Excel表格，或者Project文档，来分解出产品的Features。然后找到相关人员（通常为开发、测试与UI设计人员）一起开会，大家一起来评估时间。比如本文中的基金筛选器，我们就用一个project文件就足够了。

这个过程基本上是一个协调与驱动的过程，协调各种人员的配合，如开发、美工等。适当的给相关人员一些培训，让他们深入理解你的设计理念，这样才能更好的发挥他们的想象力，尤其是美工设计人员。

最终，美工会根据你的设计完成UI美化，开发人员会根据你的设计完成程序开发。这其中有一个度，也许你的想法还有很多，想实现更多更实用、更酷的功能与技巧。但需要把握一下时间与工作量，优先实现核心功能，锦上添花的功能可以安排的后期完成（如Alpha测试期、Beta 测试期）。

4、测试与上线

待开发完成，总得测试一下吧。对于网站而言，需不需要测试人员也是一个争论的焦点，同样在我们公司也有这样的问题，某些产品负责人认为根本不需要测试，有测试也不一定能帮你测试出Bug。

当然他们说的也有道理，毕竟我们网站的行业性比较强，是有点难上手。但产品开发完成总得还是要测试一下。

没有测试人员，怎么办呢？只能发动全公司人员一起测试了，虽然不能保证最终完全没有Bug，但好歹还是测试过。

最后，我们发出Beta版，正式和用户见面：

+

有兴趣的朋友，可以点击这里、那里看看效果。

我们为什么要改版

十二 14

Ben产品设计 产品设计, 改版, 用户体验, 需求管理, 需求采集 No Comments

前段时间收到用户的站内短信，内容是这样的：

为什么总是更换或升级？给我们的工作带来了很多的麻烦！！！

当天的确是服务器故障，导致部分用户访问受到影响。从短信内容中可以看出，用户已经忍了一段时间，实在忍无可忍，于是发短信向我们抱怨。

我们必须勇于承认错误与不足，看来是某个环节有问题，导致这样那样的问题，而原因可能是多种多样的。尤其是针对大用户量产品的改动，更要慎之又慎。

回到为什么要改版这个问题上来，如果单纯回答这个问题，不外乎有以下几点：

• 页面调整，为了更利于SEO；
• 为了提升用户体验；
• 为满足更多的用户需求，不断对功能点进行改进；
• 构架性调整，如将产品推向一个更高的层次；

总而言之，世界在发展，我们也得发展，改版是为了提供更好的服务。要不然怎么会有人说“政府工程是拉动中国经济的三驾马车之一”呢。

但是，有几个问题得首先想想，你新增的功能一定是用户想要的吗？或者大部分接受。是不是应该先考虑习惯性这个问题？你的用户群体有什么样的特点？

过去一年，我们对若干产品进行升级改版，不断的满足用户的需求，也得到了一些好评。但后来我们分析，其实有些得不偿失，新增的功能在一定程度上影响了一些老用户的使用。虽然这样情况不可避免，但如果影响的群体过大，可能就有问题了。

于是我们开始对提出抱怨的用户进行调查，接受调查的用户几乎都有同样的回答：“目前的功能已经够他们用了 or 习惯了”。我们也对比了竞争对手的同类产品。不客气的说，其中某些产品其实做的很烂，但还是有很多用户使用，而且这些用户不会因为你的用户体验好，功能多就转过来用你的。

通过分析这些的现象的背后，我们似乎可以得出一些结论。

• 需求：从需求的层面上说，目前的需求已经满足用户的需求，而且这些需求是刚性的。对于锦上添花的需求，用户貌似漠不关心。
• 用户：只要你满足了我的需要，而且这些都是我必须的（刚性的），就算你的UI做的再烂，我也不会轻易放弃使用你的产品。久而久之，用户已经习惯于你的产品。
• 既然用户已经“习惯了”你的产品，因此你对产品的任何改动，都会对用户产生影响。

那么，还要不要改版呢？还是那句话，由于这个世界在永不停息的发展，因此改版也要继续。但不是盲目的改版，而是要找准用户的真正想要的需求，且应满足绝大多数用户的需求，要摸清用户的习性与特点。做到有的放矢，应该就没问题了。

利用MVC UserControl实现博客自定义主题

十二 12

Ben产品设计, 技术相关 ASP.NET MVC, DsJian2.0, 博客引擎, 开源博客, 自定义主题 No Comments

前面谈到完成DsJian2.0的前端开发，其中有一点，使用ASP.NET MVC View UserControl来做博客模板，对于这一点，我自己也感觉有些别扭，今天在这里单独谈一下，这到底是怎么个情况。

背景

根据我对ASP.NET MVC的了解，项目中所有的ViewPage都必须放在Views文件夹内，Views文件夹内的每一个子文件夹对应一个Controller。不得不说这样的设计有一定的局限性，因此ASP.NET MVC 2.0才有Area这样的概念融入其中。

谈到局限性，具体表现在当我需要创建主题文件夹的时候，应该怎么弄呢？我想要的效果是这样的：Views > themes > default > All View Pages，在themes这个目录下，允许有若干个子文件夹，每个子文件夹就是一个主题包。主题包里面包含系统所需的所有View Pages，当然，共用的页面及用户控件除外。

也许由于对ASP.NET MVC的了解不够深入，存在有别的解决办法，只是我没找到而已。

解决思路

于是我就在想应该如何实现“自定义主题”，了解到View User Control（下称UC）可以放在任何目录里，只要在Render时指定好路径即可。因此我开始尝试用UC来做主题文件。

由于采用UC做模板文件，因此我的View文件就只有这样一句话：

<% Html.RenderPartial(this.CreateEngine().GetThemeVirtualPathWithPartial(“ListByCategory.ascx”)); %>

CreateEngine 是我在 ViewPage 上增加的扩展方法，即返回所谓的博客引擎（Engine），通过这个博客引擎可以完成所有博客业务数据的提取，甚至包括生成部分简单的HTML代码。

通过这样一段代码“this.CreateEngine().GetThemeVirtualPathWithPartial(“ListByCategory.ascx”)”，我可以得到当前系统指定的主题文件夹下的ListByCategory.ascx这个主题文件。

这样的话，我所有的View文件不包含任何实质性的HTML标记，所有的HTML标记应该由主题制作人员完成。我只需要在引擎上提供足够用的数据接口供制作主题时调用。

于是，我的目录结构变成如下这种形式：

Views > View Folder > View Pages

Themes > Theme Folder > All Theme Files（CSS、脚本、图片、图标、主题文件：UCs）

如果，某某人有兴趣自己开发一套模板，他只需要遵循我的规范，做一个主题包，然后放在网站的 Themes 文件夹下，就可以在后台配置使用这个新主题。类似于wordpress，我想用过wp的朋友都理解。

存在的问题

本文开始我就说了，这样的设计还是感觉有些别扭。ASP.NET一些比较好的特性好像就不能使用了，比如Master Page。我自己在尝试开发主题包时就想使用Master Page，因为这样会方便许多，但是用不了（UC 无法使用 Master Page）。

大量使用UC会不会有其他问题，比如执行效率上，目前还不得而知。所以，如果有其他更好的形式，我想我会考虑考虑，只是到目前为止还没有想到更好的办法。

完成DsJian2.0前端开发

十二 10

Ben产品设计, 技术相关 DsJian2.0, 开源博客 3 Comments

完成博客程序前端的开发工作，今天在这里留个笔。到目前为止，已完成如下功能：

• 博客安装（包括数据库、系统初始化等）
• Smtp邮件发送与配置
• 基本博客功能（文章、页面、评论、链接、分类、存档、Tag等）
• 自定义主题功能
• 数据引擎API搭建（前端模板数据获取与交互）
• 自定义文章URL
• 多数据库架构支持
• Rebots、Sitemap生成
• Rss、Atom（文章、评论等）
• Trackback接受与发送
• Scheduled Tasks（类似于Background Services，为以后的插件功能做准备）
• Gravatar 头像应用

其他不想多说，感觉最近自己忙麻木了，因此写不出什么东西出来。对于以上Features中的一点：自定义主题，我现在还对我的设计持怀疑态度，感觉使用Mvc UserControl来做模板页面有些别扭，但到现在为止还没想好替代方案。希望能得到网络上的朋友们的帮助。

贴一下博客项目结构：

四象限基金分析法

十二 06

Ben产品设计, 投资理财 信息展现, 四象限分析法, 基金, 基金分析, 基金筛选, 夏普比率, 展现设计, 标准差 No Comments

关于基金类文章，这是第一篇。我的个人介绍里也说了，我就职于国内某知名基金门户。所以自己多多少少有些这方面的行业知识，对于此类文章，以后会陆续写在投资理财这个分类中。

最近在做基金筛选，于是自己也在思考如何筛选基金、如何比较基金的优劣。在国内这方面内容都很平淡，没什么指望（不好意思地说，我们算是领头羊）。自己分析也不靠谱，毕竟不是金融行业出身，对基金了解也不深入。于是把目光投向国外市场，毕竟国外的资本市场已经很成熟了。

对于如何展现基金的收益性与波动性，本文会提到国外较流行的四象限分析法来表现这两种指标。什么是四象限分析法呢（她还有一个名字叫波士顿咨询集团法），简要描述一下，即用一张二维坐标图来分析两种指标，并以一定的规则将二维图划分为四个象限，也可在图中融入更多维度的分析指标的一种分析法，看下面的草图：

我们的横坐标为标准差（考察收益波动性），纵坐标为回报，落在图中的某个点就是一只基金，比如图中的“华夏大盘精选”。对于如何划分象限，我们可以用大盘指数作为基准，也可以用国内所有基金的收益与风险平均数来做这个基准，姑且我们就统称为基准线。

通过基准线，我们将图分成了四个象限，对于这四个象限，到底有啥意义呢？

• 第一象限（右上角）：风险高于基准线，收益高于基准线，即高风险、高收益类型的基金，落在此区域的基金适合于比较激进类的投资者
• 第二象限（左上角）：风险低于基准线，收益高于基准线，即低风险、高收益类型的基金，不用说，一定是好基金，大家不是都在追求这种基金么？
• 第三象限（左下角）：风险低于基准线，收益亦低于基准线，即低风险、低收益类基金，适合于稳健、保守型投资者
• 第四象限（右下角）：风险高于基准线，收益低于基准线，即高风险、低收益的基金，这也不用说，尽量回避此类基金。当然也有例外，对于喜好风险的投资者，这也许还是一个不错的选择

那么，图中的三角形、方形、圆形有表示什么呢？为了能够使投资者选出更好的基金，我们在图上额外增加了一个指标：夏普比率（扫盲阅读），并将夏普比率的值分成三个区间（sharp<0, sharp>1,0<sharp<1）。分别用三种图形来表示这三种区间，这样我们可以从超额回报的角度来分析图上的基金。

• 三角形：sharp>1（最优的基金，往往比较少）
• 圆形：0<sharp<1（较好的基金）
• 方形：sharp<0（表现差的基金）

最后，回到信息展现这个问题上来，风险与收益的展现形式可以有很多种，最直接的，用表格的形式展现，但这未免显得太平淡。而我们换用上面这种形式来展现，就形象了许多，也容易理解。所以往往我们在做数据展现设计时，可以尝试用多种表现形式来展现数据，需要不断的优化表现形式。一个好的展现设计与差的展现设计往往在最终效果上会有很差的差别，对于用户的体验来说，也会存在很大的差别。

我们是如何作需求管理的

十一 11

Ben产品设计, 项目&管理 产品设计, 特性列表, 需求分析, 需求管理, 需求评审, 需求采集 No Comments

毫无疑问，需求管理在产品设计中占有非常重要的地位。那到底有多重要呢？回答这个问题之前要先反问自己，你为什么要做这个产品？而你可能有如下回答：

• 老板项目，不做也得做
• 我们觉得这个值得做，因为有很多人需要她
• 我们的用户对我们产品提出了更多的要求
• ……

就是说，因为有需求，所以我们才做这个产品，她是一切产品产生的源头。既然这么重要，对于需求的管理就显得更加重要了。首先来看一张图：

看上去东西挺多的，实际上可以把图分成三部分：

1、需求采集

需求采集包括需求收集与提交，需求收集的渠道可能很多，最直接的就是和用户交流，比如用户调查、意见征集、网站论坛、站内短信（实践证明，这是比较高效的收集用户需求的方式之一）等。

客服也是一个比较重要的渠道，如果你有时间，也可以自己去冒充客服人员。另外，某些需求也来源于团队、公司内部，比如用户数据分析衍生的需求，老板的直接需求等，总的来说，需求的途径可能有：用户、公司or团队内部、客服、市场等。

在提交需求时，需要记录好需求来源，原始需求人，原始需求，提交人，提交时间等。这个阶段，需求的状态应该是“待讨论”。

2、需求评审

在一定时期内，应该开需求评审会，参与人员可多可少，视需求、团队的情况而定。做需求评审时，参与人员可以对需求发表意见，大家一起讨论这个需求值不值得做，实现难度等。纳入评审的需求的状态一般会有如下变更：

• 接受：当然，这需要综合考虑这个需求能给我们带来什么样的价值，也要考虑实现这个需求的成本
• 暂缓：暂缓的需求可能由于此阶段还不适合实现，或者在资源分配上存在问题，又或者启动的条件尚不成熟
• 拒绝：拒绝的需求可能是一些和我们的目标价值相背离的需求

在需求的状态变更时，我们会记录下变更的原因，比如“暂缓”的需求，我们还应该记录下重启的条件。完成需求评审后，我们会对需求进行分析。

3、需求分析

为什么要进行需求分析，一个原始需求应该代表原始需求人内心的欲望，需求人只是向你提出他所需要的东西，需要达到的目的。而我们做需求分析就是要从这个原始欲望中挖掘出用户真正想要的东西，也许是一个功能，也许是一个产品。我们还应该考虑怎样实现这个需求才能满足大部分用户的需要，或者不影响大部分用户的使用等。

待需求分析完成，会产生一个或多个产品特性，这时需要把特性录入至特性列表，最后我们会实现需求，包括特性分析、设计、开发、测试、发布等。

这样，我们满足了用户的需求，并实现与需求对应的功能特性或产品，提供给用户使用，用户在使用产品时，可能又会产生新的需求，而我们又开始想办法满足这些新需求…..基本上就是从用户中来，到用户中去这样一个周而复始过程。

工具方面，想起以前团队培训时用过的一句话：什么是最佳项目管理工具，excel, excel, excel。个人认为，这些工作用Excel就可以搞定了。当然也有一些其他很好的工具，具体用什么，跟很多因素有关，比如个人偏好、文化、团队大小、环境、心情……总的来说，最适合自己的就是最好的。

可用性的前提条件

十一 08

Ben产品设计, 项目&管理 UCD, 产品设计, 以用户为中心, 可用性 2 Comments

额～我承认，可用性很重要，一个完全没有任何可用性的产品是没有必要发布的，因为它只会给用户增加烦恼，不能解决用户的问题。

因此，可用性就变得更加重要了，为了解决这个问题，某些公司专门成立了UCD部门，这些人专门干一些与用户相关的一系列事情（如上图），比如用户调查、访谈；用户行为、需求分析等。当然也直接参与产品设计，因为在以用户为中心的设计上他们最有发言权。

显然，成立这样一个部门或团队，需要大量的投入，需要成熟的企业文化与管理制度。

对于一些尚不成熟的中小企业来说，摆在他们面前的问题是生存问题，需要快速盈利。没有精力与金钱投入去解决可用性这个问题。于是在这些企业中，由于没人专职研究，也没人懂，就是说，大家言论自由，人人都可以谈可用性咯。

如果你是产品设计者，那你要小心了。因为人人都可以用可用性的眼光来批判你，大家可能群起而攻之。最后，妥协吧，OK，咱们推翻重新做吧。

也许，设计者的确设计的很烂，这是能接受的，咱们改进就是。但可怕的是，设计者往往不知道烂在哪里？导致改进的余地都没有。

要谈可用性吗，行，请给我资源吧。