关于EcommerceAll
Posted on | June 7, 2008 | No Comments
EcommerceAll是一个致力与电子商务技术开发、外包与IT咨询的网站。我们交付客户定制的电子商务软件，上门提供注重实效的电子商务咨询服务，为企业开发商务软件，帮助企业敏捷开发。我们拥有非凡的、经验丰富的电子商务专家、前端架构师、开发团队，因此客户聘请我们为他们解决最棘手最紧迫的问题。我们满怀信心和激情，以现场或分布式的形式为客户提供高质量的服务。
网络电话的电子商务运作手段
Posted on | December 3, 2008 | 1 Comment
最近想帮一个电子商务网站客户搭建一个简单的客服中心，客户处于创业阶段，一分钱想掰成两半使，但是电子商务中，贴心的服务质量都是非常重要，当用户在网站上下单成功或购买成功后，及时的与用户沟通，反馈，非常非常重要，这个操作步骤, 需要一个回访电话来完成，英文叫Happy Call, 很多小企业主并不懂得这个重要性或者担心一个单本来就不赚钱，在搭进去话费，不值。
其实电话沟通是非常非常方便、温暖、安抚消费者、增加回头客的有效手段，对于很多消费者来讲，更喜欢和客服中心打交道，而不是和冰冷、操作繁琐的网站打交道。
携程号称在线旅游的霸主，可是在网上的交易，只占了不到1/3的量，而通过打400、800客服电话的交易则占了一半还要多。
所以电话非常非常的重要，但是对于中小网站，客服中心的造价太高，量又充不起来，实在不值，使用网络电话不仅可以打手机，还可以打固话，话费很低，是一个非常经济的手段。是一个有效的经济手段。
我试了是skype和国内的UUcall、阿里通，等等，通话质量，都基本上差不太多，还比较清晰，但很难保证一个稳定的水准，比较依赖于网络的环境。最后盘算了一下，选择了国内的UUCall.
VOIP技术算是比较成熟的技术，一个小的企业都可以买几个交换机，扯旗子做网络电话，但为什么有的做的好，有的做的不好，无非是推广运作手段的高明和力度不一样。我大致总结了网络电话的运营手段：
1.概念运作
skype最流行，不过是市场的先如者，号成通话质量最好，不过是典型的概念营销手段而已，在Ebay上欧美的中小企业主喜欢用，从而会带动和影响中国客户。
在国内恶劣的宽带环境下，通话质量的瓶颈很明显在于网络的环境质量，网络电话运营商不可能去投资改造网络环境，这一点不同于电信运营商对于基础设施的巨额投资。
2.价格战
对与客户来讲，使用网络电话，就是图省钱的，在通话质量都差不多的情况下，谁最便宜，就要谁的。但如果搞价格战，大家赚不到钱。所以大家的话费收费都差不多，都在每分钟一毛和一毛二之间。对于用户来说，似乎没有选择的余地。
UUCall的话费一毛二，看似没有恶性竞争，但充值送话费，一下子将话费打到每分钟6分钱的价位上 。
3. VIP客户
这一个手段，只有阿里通使用，但用的十分愚蠢，没有一点实惠，又不打折，只是让客户顶个虚名，拿客户当傻姑。
4. 积分
还有一个比较好的手段就是积分，可以牢牢的将使用者黏在自己的网站上，UUCall的积分手段比较多，只要在线和充值，就会有积分，而积分反过来可以换话费，进一步降低成本。
5. 联盟推广
这个是个常用的推广手段。
6. 免费软件捆绑
和flashget， 迅雷等捆绑下载，推广。
7. 投放广告
8. 免费体验，送体验话费
一般都送几块钱话费，体验一下，只要把耳机上的麦调好，会体验到比较好的效果的，通话质量还是不错的。为了防止小人频繁的注册新用户盗用话费，服务商都不傻，一般都要求用你的手机号绑定注册，送体验话费的。但是现在Taobao上，有很多卖5分钟、10分钟话费的门店，不知道他们是用什么手段盗取到的。
本文来源于http://www.blogjava.net/oneeyewolf
项目管理之能不能不要再说完成了90%？
Posted on | December 3, 2008 | No Comments
当别人给我说他的任务完成了90%的时候，我总是要反思我是不是给他造成了压力，我喜欢别人明确的告诉我他的问题在那里，这样我可以去帮助他，coach他，但当别人总是和我说没有问题的时候，我总是有种恐惧，我知道其中一定有问题，但我想帮忙都没办法帮。
我以前曾带了一个分销系统的项目，同时并行的还用另外的一个配合的项目，每周GM会review我们的工作，其实和过堂差不太多，气氛太紧张了，冷冰冰的，很不舒服，再加上两个PM一起被review，有点暗暗较劲的意味，我当时深深迷醉与项目管理的可视度的概念，就是增强透明度，我希望把我项目中的Issue尽早的暴露出来，评审的人可以看到，或可以帮助我一起解决，或了解项目的Risk和真实的Progress，真实的理解我的处境，给我必要的Resource支持。
另一个项目经理则圆滑多了，review时，总是说，没问题，还行，快完成了，基本完成了，完成90%了。
两下强烈的对比，反而显得我的项目问题多。搞的我处处被动。
我虽然知道他那个项目总会有纸包不主火的一天，但至少他得过且过的每周5挺过去了。他给我说，他的压力也很大，很讨厌那种review的风格，就像悬崖上一个人老是站在他的背后说：“你的任务完成了没有，没有完成，我就推你下去”。
我看到过两种人，一种是领导，最不能容忍的就是听到有问题，因为他比你还没办法。一种是新上任的、没经验的Leader，责任心强，完美主义，喜欢遮掩问题。这两种人最容易能走到一起，在项目的初期，大家其乐融融，一片喜庆的气氛，最后在Deliver Result的那一天，一起走向毁灭。
如何避免这一点：
1）做项目，就像在铁轨上骑自行车，一路，肯定是颠簸不定的，leader关键要把握方向正确，虽然有问题出现，照样会到达目的地。
2）leader不是commander，而是要扮演coach的角色，要营造出宽松、敢于直面问题、敢于说真话的气氛。滥用权利，滥使淫威，过于强势，是最最粗浅的、最无知的领导风格。
3 ）列出项目中所有没有Close的Issue, 对每一个加上Reason, comment，回报给自己的上司，获取必要的资源支持，让别人理解你的处境。
4）设定切实的 check point，而不是80%、90%之类的废话。
本文来源于http://www.blogjava.net/oneeyewolf
从Jquery Grid ( jqGrid )谈前端框架设计
Posted on | December 3, 2008 | No Comments
设计框架，和使用第三方框架，都基于一个很朴素的目的，Productivity.
首先就要思考的是什么造成了开发效率的低下：
1）重复
2）繁琐、耗时
3）复杂度太高
4）容易出错，不统一，难以维护
解决问题的手段就是：
1）封装
通过不断的封装，信息隐藏，降低复杂度。
2）重用
通过重用，来降低工作量，提高代码质量。
3) 分离
将不稳定的，可变的、同稳定，很少变化的部分分离出来，减少需求变化的冲击。
所以第一步，要分析问题域，去结构化它，然后一条一条的解决：
1）不复杂，但是重复、繁琐
2）复杂，而且重复。
无论怎样都是要命的，都要去设计者尽量去解决。
以前端页面开发为例，我们在前端开发当中，都会遇到一个看似通用的工作，分页查询和表格表现。
这是一个重复、繁琐、耗时的工作，但是不复杂，人人都会做，但要命的是，每个人的做法都不一样，所以造成了不统一、不一致。
分析问题的过程，是一个结构化的过程。我们可以对Grid的工作，做一个结构化的分析，可以将繁琐的问题，变成清晰的结构。
1）分页操作：next, prev, last, first, go to, 自定义显示行数，总页数，总条数，总
2）分页参数传送与状态保持：POST、GET、AJAX
3）斑马条
4）事件: load, mouse over, click
5) 列操作：sort(服务器端排序、客户端排序)、 resize column, 自定义显示列。
6) 行操作：add row, delete row, edit row, select, muliselect, edit, query,
7）数据传输： json, xml, array,
高级功能：subgrid, master/detail 多表关联
9）扩展：Call back function.
10）布局与风格统一：Theme的设计，Caption, title, 查询区，数据区，按钮区
Jquery Grid (jgGrid) 相对比较好的，解决了这些问题，但框架毕竟是框架，
没有最完美的，只有相对合适的，使用者需要分析知道自己的问题在那里，然后去设计开发、使用合适第三方的框架，或直接使用、或二次封装、开发、修改源代码，来解决自己的问题，总之，不要做一个问题的抱怨者，等着别人煮米下锅。
点这里，可以下载 JqGrid JQuery Grid
网址是（可能需要代理)：
http://trirand.com/jqgrid/jqgrid.html
本文来源于http://www.blogjava.net/oneeyewolf
纸糊的架构设计
Posted on | December 3, 2008 | No Comments
最近，负责客户的一个项目设计的审计工作，是一个短信平台的项目，上行和下行通信都有，之所以叫平台，是想将客户的很多的业务系统，涉及到短信的部分都统一挂接到者一个服务平台当中，只要一家服务提供商，量大从优，避免各自为战，浪费资源。业务系统多是遗留系统，当中对短信需求各不一样，客户从自己的vendor List中找了一个短信服务提供商（SP）。一般的要是能进入vendor list中，说明实力还是有的。
由于项目设计多个系统，前期投入就要10K$，还不算后期的按条计费的短信费用，我是参与项目技术方面的审核工作，客户不懂技术，很信任我，我是不敢怠慢。
SP派了客户经理和项目经理及几个技术人员，来开了几次会，双方一起制定了协议格式、接口功能，考虑到遗留系统，提供多种业务接入方式如WS、socket等方式。
同时对于目前的流量和未来的增长，也做了分析，对方做了最终的设计方案，漂亮的powerpoint展示出平台的几个feature：与业务无关的松耦合接入、跨平台、可扩展、Scalability，似乎都很完美。
SP很得意，会议现场充斥者“没问题”的论调。现场中提出的其他的附加功能，如手机身份验证、日志、费用对账等，都一一答应下来。
客户象征性的问了我的意见，我说还是要做一个POC（proof of conecpt)，来验证一下，这个POC相当一个Demo了，就是要验证设计，只实现核心的功能就可以了。
双方讨价还价，POC制作的费用是2万元，结果噩梦就从这个POC开始了。
1）2个星期后，对方来部署POC，忙到天黑，未果，说是短信猫与服务器的端口有冲突，工程师走了，没说什么时间再来。
2）又过了几周，在反复打电话，催促下，工程师来了，终于搞定，通知客户说可以测试了，结果只用一个手机，都没有测试通过。对方有走了，说是短信猫没充值，没钱了，把客户都气死了，没充值，让客户测个屁啊。
3）第三次测试，个别的手机，能测试通过。非常不稳定，一个机票申请、审批流程，要半个小时走完。
4）拖了一个月，对方要修改设计方案，将上行的短信猫方式，修改为WS方式，定时调用，获取信息。
5）最后，对方信心满满的，拍着胸部说，没问题了，可以了。
6) 我设计测试案例，手机分为联通手机、移动、繁体手机、英文手机等，测试流程是模拟真实业务的机票申请、审批的流程。客户开始召集10几部手机，开始人肉测试，还有人在外地测试。
测试目的，初期并不以压力测试为主，而是测试infrastructure，诸如上下行通道畅通、通信制式、编码、协议、业务流程为主。
测试结果非常失望，繁体不支持，联通通过率很低，移动很慢，上行和下行通道都不稳定。
7）这样的测试很累，我们调整了策略，让SP按照我们的测试案例，提供测试报告。SP不愿意，说没有那么多人，我对他们说，你们傻啊，客户是黑盒测试，你们有源码，可以有更灵活的测试策略啊，比如Mock Test之类的白盒测试啊，对方没反应，可能是他们没有正规的测试平台。
8）最后，4个月过去了，客户还是客气的给了2万元钱，双方各自散去，无疾而终。
教训：
1）一定要用POC来验证华丽的设计方案，避免看上去很美(参见 用代码来推动设计）。
所谓的UML、PPT、方案书，其实都是一种Presentation, Not Validation。
2）底层的平台设计的稳定性，很重要，再好的function, 性能不行，白扯。如果想不出办法来验证，就不要上马，不能用时间和Money来验证，时间比钱更重要！
3）对于vendor的服务行为一定要在合同中注明，避免出现不规范的现象：
1.技术工程师是个性情中人，没有服务的意识，说来就来，说走就走，还经常不耐烦，发飙，真拿自己不当外人。没有时间观念，自己说周二来，结果没来，也不解释一下，还要客户主动打电话问为什么不来。
2.没有规范的测试流程，直接在现场边修改代码，边测试。
3.对于客户的不满，没有及时的响应，仍然是老一套的能拖就拖的现象，典型的有中国特色的软件公司，邮件发到老板那里，才有效果。
4.过度承诺，对客户的承诺不负责，说话不算数。
4）客户是无辜的，做人要讲诚信，特别是搞技术的人，设计绝对是要负责任的，现在越来越觉得一些所谓的设计师，跟江湖郎中没有区别。
本文来源于http://www.blogjava.net/oneeyewolf
为什么要使用JBoss Drools
Posted on | December 3, 2008 | No Comments
我在项目中一直使用JBoss Drools 这个开源的规则驱动引擎， 为什么要用它？ 我要想出个一二三来说服别人。
对于business rule, 一般的情况是， 好的BA，可能更善于发现、抽取business rule ，并用结构化的方式描述、记录下来， 普通的BA可能更是一种流水账式的、吃那拉那的描述方式。
不管怎样，BA在写文档，use case的时候，那些business rule被分布在文档中不同的部分，然后这些rule，在分工时，有被理所当然的分给不同的开发人员来开发。
好的开发人员会刻意的使用各种手段剥分离、封装、结构化他们，并积极的重构他们，以防止规则的变化，冲击到设计或代码的结构。
而普通的开发人员则极有可能硬编码写死在代码当中，完成coding 任务，草草了事。
可以看出，这种方式，随意性太大，不可控的风险也随之增大。后果是，开发人员总是抱怨需求的变更，殊不知，合理的设计手段，在一定程度上，可以缓冲需求的变化。
JBoss Drools, 它在一定程度上解决了上面的问题：
1）规则首先应当是可管理的
规则是相对灵活、复杂的，我们要控制、管理它们，而不是直接暴露给开发人员，愿意怎么搞，就怎么搞，一个人一种style。
Drools使用script，将rule集中写在规则库文件当中， 使得设计人员更容易管理。同时可以设计复杂的业务规则，并在没有编写任何代码的情况下自动绑定企业数据。提供带有菜单提示和下拉列表的向导来帮助用户完成设计过程。
2）我们则设计是，总要遵循一些原则：
将易变的和不变的分离出来
封装可变的规则， 避免硬编码编程
将多源的规则，合并、整理成单源的规则，一进一出，降低复杂度。
Drools将规则写在配置文件当中，以集中强制的方式剥离了规则，而不是写死在代码当中。在规则变化而修改脚本文件时，不用重新部署系统。
3）规则应当使用一种清晰、易懂的方式记录下来，并明确下来，无论是汉语还是英文句子，都不是表达规则的好的方式。大段大段的文字，往往让人发晕。
伪代码、script语言反而时表达规则的一种极好的方式， 结构化的表达方式，让开发人员觉得非常亲切，更加平易近人。
Drools 引入了更为强大且的业务行为脚本语言（MVFlex表达式语言）。用户会发现脚本语言的引入使得代码变得更为简明且可读性更好。
本文来源于http://www.blogjava.net/oneeyewolf
从用户的角度看待BA
Posted on | December 3, 2008 | No Comments
关于BA，很多人写书为了谋取利益，极力和UML、UseCase扯上关系，误导了很多努力向上的人，把工具当成了能力。很多公司在面试BA时，也非常看重你会不会UML，无疑是添乱。
BA其实要处理两层关系，上游是用户了，下游是开发团队了。
两层关系对于BA来说都很重要，但要排个序，上游用户当然要排在第一位。没有用户，软件公司都不会存在， 一些BA甚至承担者marketing 的重任，和用户关系融洽了，下个单可能还是你的。
我长期是Onsite的方式与用户打交道，可以强烈的感觉出用户需要什么样的BA：
1）Smart
客户的时间很宝贵，节省时间成本是很重要的，每个人都喜欢那种一点就透，举一反三，防缺补漏的人。那种三拳砸不出闷屁的人，能让客户急得拿头往墙上撞。
2）礼貌
尊重客户的Priority list, 客户都会有自己的的任务，完不成也会和我们一样打板子，关于IT的事情一般都会放在最后，所以不要无规律的骚扰客户，好的BA善于和客户预约时间，并高效的在约定的时间内搞定事情。
尊重客户的意见，不要直接反对，采用各种委婉的方式。
尊重客户的budget，不要动不动，都提出复杂的解决方案，想办法给用户省钱，在公司利益和客户利益之间做个balance，你又不是只做这一单，建立长期的关系更重要。
出现偏差，无论如何都要先承认，“sorry, 是我自己没说清楚”。
善于用邮件、电话、小礼物、吃饭等各种方式表达对客户的感谢。
在邮件当中，出现“必须，要求，在规定的时间内”之类的字眼，都会冒犯到客户。想想别人（不是你的上司）给你发这样的邮件，你的情绪是什么。
3）处理政治
用户是个抽象的概念，实际的人，只要有Relationship的地方，都会有政治，当用户内部出现分歧或者其他摆不上桌面的事情时，要能够觉察出来，想办法中和，或者回避，不要傻傻的只顾向前冲，得罪一大片人。
4）反馈
每一次的交流、沟通，都尽量用文字记录整理，并反馈给用户，不仅仅是确认，更重要的是重视客户的姿态。
5）解决问题的高手
客户是问题方，无论用何种方式，能够快速的帮助客户解决问题，提供简洁的解决方案，都会深得客户的芳心。
6）超前的业务理解
在进入新的、陌生的business domain时，能够主动的学习、钻研客户的业务知识，在成熟的行业中，能够成为领域专家。能够超过用户对你的期望，好评不言而喻。
本文来源于http://www.blogjava.net/oneeyewolf
struts 2依然坚挺 Seam前景不明
Posted on | December 3, 2008 | No Comments
如今Java的Web MVC框架，夹在RIA和Ruby on rails、PHP之间，疲态尽显。
看图说话：
struts2还在攀升，spring MVC 缓慢增长，seam不温不火
最好的态度就是观望，不要在下面这些技术直接换来换去，而是以提高设计思想、加强积累、纵深发展为主。
本文来源于http://www.blogjava.net/oneeyewolf
不要被牛粪糊住双眼
Posted on | December 3, 2008 | No Comments
人们在走上管理职位时或者被赋予超越自己目前现状的角色时，精神状态陡然发生了变化，工作更积极了，主动性加班也多了，说话的声音也大了，语速也加快了，总带着居高临下的语气，不说教一下别人总是不爽。
总之像吃了药一样。
职位升迁后的权利的假象使人们误认为那是别人服从自己，是自己的领导能力使然，意识和责任心急速的膨胀起来，害怕出问题，当有不同的声音时，视为挑战自己的威信。
局面其实恶化起来：
1）不要把职位变成套在头上的紧箍咒，那是你自己的悲哀
我见过一些leader，不过是一些弼马温和九品芝麻官之类的角色，他们的责任心确实很强，格局却小的跟娘们似的，总有者强烈的command and control的欲望，好好的一个团队，搞的跟殡仪馆一样，一片肃杀之气。
IT的工作很枯燥、抽象、繁琐，项目管理，就是问题(issue)管理，不可能不出问题的，所以leader要尽量保持一个好的心态，不要像没见过世面的似的，咆哮嘶吼，反而让人觉得没水平。
其实，幽默一点，工作间，发个搞笑的视频，讲个笑话趣事，出去抽根烟，take it easy, 把氛围搞得融洽一点，多好啊。
看看新东方，招老师，其中一个条件，就是幽默，为什么，课堂太枯燥了，板着脸讲课，没几个人愿意去上课。
觉得项目经理这个职位很NB？看看Thoughtworks的一个咨询师，看看google中国和上海贝尔的一个soft engineer，看看IBM的那些consultant，把自己的薪水和他们比比吧，可能是你的两倍甚至N倍奥。
2）不要试图控制别人和忘了自己姓什么
在英语里，有两个词，lead 和 admin, 一些所谓的manager，不过是个管理员而已。
在团队当中，一些人不见得比你差，很多manager总是抱怨，牛人不好管，你凭什么要管（command)人家？你是要去利用别人！在JavaEye的论坛里，曾有个关于此话题的热帖子，很多人竟然认为，要把牛人，赶出团队，认为没有团队精神。
真他妈的傻B到家了，我的团队里要有个牛人，我做梦都会笑出声来。我做过的很多的项目，异常艰辛，一个牛人，顶几个开发人员，开发速度快，考虑全面， BUG又少， 还能带开发人员，除了脾气大点。能力强，自然傲气，这是非常正常的，难道还要人家，故意装出低三下四、谦虚谨慎的样子，你才爽？
04年，在做海南航空的一个项目时，我的团队里有这样一个人，叫周，水平高，算计精深，我们一块打升级，经常被他打的落花流水，和一般的开发人员在一起，他的思想确实有点曲高和寡，我做项目经理后，他基本上很沉默，不理不睬的，我找领导商量后，提他为项目副经理，工资也涨了，这下他爽了，话也多了，开会讨论时，总是语惊四座， 可以说没有他，项目就不可能成功。
再讲个例子，Windows NT 4.0是个非常成功的、里程碑式的OS了，当时主持设计的架构师，曾经设计过TCPIP协议栈，脾气异常暴躁，开会时，经常拍桌子，fuck声不绝于耳。虽然没有事实证明没了他不行，可是有了他，确实软件很成功。
3）金字塔的层级控制架构对生产率是最大的伤害
人们对职位的名称有着强烈的兴趣和偏执，我曾见过北京的一个软件公司，规模不大，五脏俱全，组织架构图里，有总裁、总监、副总，还有一个总督！真是有趣。
时代变了，敏捷、XP、WEB2.0，等等，把Collaboration和Contribution提到了很高的层面，那些僵尸般的头脑该换换思维吧。
4）做一个独立思考的人
有一个清醒的头脑，保持一个阳光的心态，不要看重那些龌龊的东东，做人要不卑不亢。做事要像下围棋一样，不计一地得失，重势和厚度，看重积累的力量。
本文来源于http://www.blogjava.net/oneeyewolf
多背一公斤
Posted on | December 3, 2008 | No Comments
在旅行的途中，为山区的孩子们多背一公斤的捐赠物资，这样的idea，平凡又伟大。
旅游区的普通百姓其实很苦，外地人的蜂拥，抬高了物价、房价，而大部分本地的人收入确非常的低。
人们看到了四川、贵州、云南、海南旅游风景的美丽，却看不到山里的茅草屋里的贫穷。
关注公益网站，1kg.org, 提供了这样的活动平台，很不错，我在我的博客上特意把他们的Logo放了上去。
我觉得程序员特适合参加这样的活动，平常鳖居子小格子里，多出去走走，结伴出游，开阔视野，非常好。
多背一公斤的成员，来自五湖四海，有很多的很有创意的想法，但只有一个人在负责IT的方方面面，不容易啊，1kg.org在招程序员，有兴趣的可以看看。
下面是他们的要求，很有意思：
下面的内容你了解的越多越好：
Ruby on Rails
XHTML, CSS, Javascript, 写浏览器兼容的用户界面
AJAX, jQuery, Prototype, script.aculo.us
MySQL，了解数据库优化
Nginx, Lighttpd, Apache，web server 的维护与调优
Linux，系统配置和维护
我们接受全职和实习生的申请，实习生每周需要工作 3-4 天。
本文来源于http://www.blogjava.net/oneeyewolf
About
EcommerceAll是一个致力与电子商务技术开发与IT咨询的网站。我们交付客户定制的电子商务软件，上门提供注重实效的电子商务咨询服务，为企业开发商务软件，帮助企业敏捷开发。客户聘请我们为他们解决最棘手最紧迫的问题。我们满怀信心和激情，以现场或分布式的形式为客户提供高质量的服务。
