产品设计 day2 2016.01.07

2016.1.7 晴 大风无霾

昨天设计了门户的架构体系，其实没什么架构，只是几个栏目板块和需要展示的一些内容而已，今天主要侧重的是用户中心的设计，开始的时候考虑到比较复杂，光导航菜单就设计了一堆，然后开始考虑菜单处的内容，例如业务本身是构建在以用户中心为核心轴展开的，所有的资源以及服务的流程都集成到了用户中心，其体系模式更像支付宝，而非淘宝那种开放的市场资源都暴露在公众面前。

接下来，由于涉及到金融业务，就用户的安全以及认证方面也做了很多的思考。例如：在操作敏感数据（修改手机号或者银行卡）时是否需要二步验证这个问题上就做了无数的假设，是仅仅使用手机验密的形式还是其他都做了考虑。有朋友推荐不同的模块使用不同的安全级别，最终安全方案的结论是找保险公司，公司为用户的资产进行投保，这样增加了企业及产品的可信度又对用户的资产进行了有效保护，当然必要的验证手段还是要做到。

然后就技术选型进行了一系列的考证，例如选择php、python还是Java做了很多的讨论，就开发效率、扩展、安全性方面都进行了很多的思考，思考方向主要有php方面开源的优秀项目太多，可以很快的构建业务；而python则纯粹属于个人情结，且成熟度方面跟php也差不多，但存在的问题同样突出，工程师比较难找；而Java，Java这个问题市场很成熟，很多人，但也同样是因为人数太多，造成工程师在能力方面悬殊度会更大，这层面的担忧也是存在的，而且Java的概念太多，很容易出现很多靠忽悠的人，虽然号称是平台级、企业级的语言，但也有自己的弊端吧。有一个可用链接是关于知乎上关于php\python\ruby 比较的

那些认为php只能做web的人其实真的是不太懂php的人，这里请允许我“呵呵”一下，早在2008年的时候，就已经开始用php去做分析和遍历文件系统了，虽然效率方面…（这里不谈效率）。

最终技术选型的结论是使用php构建最初的业务系统，等资源到位后，或采用Java重写。

接下来是商户端的产品设计，第一期的产品应该不会嫁接很多资源进来，以完成流程为主。用户系统资源审核会放到系统后台进行，还有一些工作，例如和用户签订电子合同及服务有效期的问题，是在设计管理系统时需要考虑的；此外，关于支付和结算的业务也需要补一下课了，关于结算还有朋友说使用人工，其实在这个层面上我更愿意相信机器。

最后，就关于grails.org遭遇GFW发出一些声讨吧，技术类型的站点也受如此待遇实在是有些想不明白了。