科学观察/评测/NEW WORLD

    “用户体验”目前一直是很流行的，早上在公车上突然想捣鼓一下这个词。用户体验，首先得有用户，为什么不是客户呢？有人曾经和我聊过这个，我依稀记得“客户”是付钱的那位，是能带来收益的。用户这个词来定位为该产品的最普遍使用者是最合适的。

    小公司需要做“用户体验”么？要的。新产品需要做“用户体验”么？不一定，为什么这么说呢？首先新产品还没有稳定的用户群，这时候做得所谓的“用户体验”也是按照自己的框找一帮人来验证自己是对的、或者验证自己是有些问题的。新产品应当尊重设计者的意愿，而不应当强行推行“用户体验”，其实用户自己也不知道自己需要什么，也不明白新产品到底是怎么回事，这个时候他们是最容易被调教的，也许你的产品就成为了用户永久的习惯。GOOGLE为什么页面很简单？他的设计者据说是不太懂HTML，所以做的那么简洁，于是简洁就成了搜索引擎的标准。WINDOWS的窗口标准也是很强势的，其实大家用习惯了也就好了，有人觉得VISTA很难用，其实也是习惯问题。

    当你的产品有了一定用户之后，然后尝试做做“用户体验”，当然你在设计初期也可以别出心裁去调教你的用户。用户群体是会变的，由男人变成女人，有青年变成老人，所以“用户体验”也应当是一个长期的实施过程。

    周四周冲同学分享了正则表达式的知识，还讲到了一个他们教授获金奖的研究课题，今天我突然就这些想到了点东西：

    1、一般学校学的都是用单线程来遍历图或者树的，如果用多线程速度将更快，即效率将更高，双核多核的机器现在很流行。

    2、金奖研究课题：一个大圆盘里面最多可以放多少个小圆盘的课题也可以用多线程来开发，每个小圆盘都是一个线程，具有互相碰撞互斥的属性，最后趋于稳定。其实现实生活中都是多线程的，米篮子满了只要斗一斗又可以腾出空间来装更多的米，如果是单线程的，这米要互斥碰撞到什么时候都不知道了。我想他们那个算法最后应该也是多线程的吧。

    在多线程下的程序开发和算法和单线程都有些本质的区别了。如：搜索引擎用的爬虫程序其实就是在多线程的情况下遍历一个有向图。P2P软件也是多线程的应用，具体算法啥的那就不太了解了。

    在做项目的时候我是一个乐观主意者，太乐观了对项目不大好。但是乐观对于一个创业型团队来说却是必不可少的。

    唐僧团队是最经典的团队，其中唐僧就是一个乐天派，对前途很乐观，一心瞄着美好的结果，猪八戒应该属于悲观派，动不动就说打击团队的话，什么散伙啊，分家当。沙僧是老老实实做事情的，没有太多主观倾向。孙悟空是斗战圣佛，哪个最难的就攻哪个，乐观不乐观真看不出来，不过人家有本事，感性和冲动要多一点。

    项目开发中的各位可以对号入座，唐僧是比较少的，做唐僧的人肯定会自动被当作是小团队中的精神领袖了，切记不能盲目乐观，要鼓舞士气，有谋有略才能成功。

    上周SAVIO来到华洋宾馆（原招商宾馆）给我们分享了阿里巴巴的成功秘密。

    其实SAVIO和马云一样也是一个很会说话的人，有些提问最后他在做解答时并不深入细节，而是点到即指，单单要做到这点就够我学很久很久了。生活中很多事情并不能用简单的是非观来明断，夫妻之间的相处就是典型的例子。

    “目标、使命、价值观”是阿里成功的要素，我丝毫不怀疑假如老马不是从事互联网行业的能不能成功。就像中国共产党领导的部队，不论是打战还是开荒还是支援地方经济建设，都能众志成城、万众一心。

    大灰也写了一些有意思的话，其中我也看到了一些更有意思的东西，比如老马、蔡崇信、SAVIO三人当年讨论要不要给回扣的事情，在很多公司看来是见很不起眼的小事，而老板们却兴师动众一起花两个多小时来讨论。可见世上无小事、要做好、做对一件小事就等于做了一件大事。我们就是在不停的做好小事情而成功的。

    看了winnerzone随笔的一篇文章：http://www.cnblogs.com/winnerzone/archive/2007/08/13/853336.html 给他评了评。

    就我自己对项目管理的认识来说两句：一年半前我还真不怎么重视项目管理的，我这个人开窍总是比较慢的。以前杨老大和TOMMY一天到晚跟我们说流程，总是没有从骨子里和他们达成共识，最后直到听了PMP的项目管理培训、并且临时做了几天项目经理随后才产生了共鸣，理解了何谓三边六拍：“边计划、边实施、边修改，拍肩膀、拍胸脯、拍脑袋、拍桌子、拍屁股、拍大腿”

    项目流程不是所有路径都是关键路径，形式化的东西能省则可以省，以下是我给出的一个步骤：“1、需求分析，2、系统分析，3、Kick Off，4、详细设计，5、制定项目计划，6、开发编码，7、测试验收，8、功能测试，9、业务测试，10、业务验收，11、发布计划，12、发布”，完全是凭理解记忆想出来的，不是书上抄来的，要是在一年半以前我真的是很能混淆这些东东。每次都要问问别人现在到哪一步了。形式化的东西可以省，但是要做的事情是绝对不能省的。

    我在这里真的不是在说教，只是想和大家分享一下自己的经验之谈。需求分析阶段会耗时，值得么？你和对方热火朝天的讨论需求，对方是求之不得的，会有一框框货倾倒给你。而系统分析阶段将会是你将这些货吃下去并消化的过程，其中需要和需求方确认分析是否准确，是否有遗漏（沟通很顺畅则需求最终评审可省）。

    摊开来一个个讲太大了，就讲讲需求分析和系统分析阶段吧，在这两个阶段同需求方亲密的接触，深深的挖掘，只会让对方感觉到痛快，比给他一个“原型”去提意见再去挖需求什么的效果要好得多，当然以上前提是需求分析和系统分析能力要很强，否则只能希望用“三边六拍”能成功了。

    很早以前有朋友有单子接了找我做的，我都会帮帮忙的，后来和MMTEA做过一个网上机票销售平台之后就没有啥兴趣了，原因很简单：怕对不住人家。因为是网上接单，沟通又不是很通畅，按照对方的需求做好了之后，又提出这个那个需求的，维护实在是麻烦。

    现在从事系统分析工作，对需求啥的都比较敏感，像他那种平台真的算算嘛需求点真蛮多的。以前年青，不就是PHP搞搞么：“三下五除二一个网站嘛搞搞定了，一条订单嘛和一个帖子是一样的原理的”都抱着这种思想做的。很多程序员也都抱着这种思想在做事情。其实一种业务你把他分析透，吃透，就够你一身受用了！“恒生”就是专门做银行业务的外包，银行业务其实没有多少神秘，你深刻的理解业务并参与过一次之后，真的是终生受用。像这种机票订购平台，如果你吃透了他的业务，不是像我这样做一个临时的可用的，那么你可以把这个软件做成通用平台，可以免费，可以赚钱，你想怎么样就怎么样，甚至可以去开源。

    我参与过的项目绝少有延期的，这点很让我骄傲的，哈哈。最近的目标是把系统分析做细致，项目计划制定合理，尽量做到不让开发人员加班。