抽空读完了多看版的《创业36条军规》，有不少可以借鉴的，在此做一些书摘吧。

1. 暴风影音的冯鑫的创业四原则：(1)凡事只能靠自己。(2)万事皆有解且有唯一正解。(3)凡是你担心的事一定会发生。(4)享受创业过程。

嗯，可能有时候我们会说，放权给我们的队友、相信团队成员的能力、扬长避短之类的，这不是和“凡事只能靠自己”的说法矛盾么？其实在读这本书的时候，有各种观点会充满矛盾，但实际上最核心的也是这些矛盾，我理解的即是在创业过程中不断地自省以及直面自己内心的独立思考的能力，像“凡事只能靠自己”这句话应该是在自己有逃避责任的倾向的时候需要告诉自己的。同样，万事皆有解且有唯一正解，如果脱离提出它的场合，很容易被理解为独断专行的绝对主义，你也可以说万事万物皆有无穷可能、参差多态乃世界美的本源，但实际上我理解孙陶然老师引用这句话的核心观点是：需要相信你手上的问题能够被处理掉，是坚持做下去的动力。“凡是你担心的事情一定会发生”更是一句自省的话了，如果真要学院派的去做一个统计，你可能会说我担心的事情65.74%都没有发生，这句话是错的，但实际上这是一句让你随时清醒与保持冷静的说辞，得这样来理解。最后“享受创业过程”，是帮助人缓压的办法，既然是你自己喜欢的事情，好好享受就行了，得之我幸不得我命。所以下面的书摘也需要考虑实际的上下文来理解，不然扣上“心灵鸡汤”、“打鸡血”的帽子是最简单和没成本的。

2. 心力强大就是活得明白，能够快速调整自己的心态，一味放纵自己的情绪不但会让情绪在放纵中放大，还会影响到自己身边的人，其结果必然与你的愿望适得其反。如果把自己的心态和心情建立在需要别人怎么对自己的前提下，别人会很累，自己的心态和心情也永远无法和谐，必然陷入永无止境的纠结之中。

这些年最大的感触是，我们心理上的不安的核心来自于对欲望的迫切要求，想要尽可能快的获得‘成功’或‘自由’，就像我们糟糕的教育经常宣传的那种非黑即白的人生观一样，我们有时候会对一些没得到的东西充满贪欲，但实际上首先我们的追求本身不会是完美的，其次我们很多时候又像是在活别人的生活，我们看到的一些书、一些人，很崇拜，所以就去让自己做一些那些人做的事情，把自己的情绪模仿成他人的情绪、移情，核心仍旧是自己对欲望的强烈渴求，但是不管欲望的目的是‘自由’还是‘财富’，也即是不管欲望的目的是所谓崇高的还是所谓功利的，如果太迫切的放任自己以及太过于认真，都会导致心态的失衡。这个时候最重要的应该是‘认识自己’，崔卫平老师有篇文章叫《需要一个低版本的人性观》写得很好，经常翻出来看看，杀菌消毒。

3. 绝大多数情况下，绝大多数人是没有主意的，谁能提出建议并且能够自圆其说，谁的主意就会使团队的主意。

嗯，我经常觉得“我所说的都是错的”，那是因为我从来不相信一个人能够通过逻辑来彻底理解哪怕是世界上最小的一个现象，很多事情无法被证明，就像非常简单的你无法证明眼前看到的世界是‘客观存在’的一样，所以这样的理解带来两个观点，第一是所有的权威都是臆想，特别在我们这个本来就很落后的国度，所以我们都不是精英，做的决策一定不会完美，因此试错是允许的也是合理的，在一个落后的地方建设要从基础开始，所以团队的leader一定不要害怕决策错误，大家又不是在赌命，心态宽松一些，包括在决策没有太好的市场反响的时候，心平气和的改良和复盘，好过苦逼兮兮的抓耳挠腮手足无措。嗯…好像说偏了哇….你看嘛，我说的都是有问题的。

4. 所谓机会就是别人不看好的时候你去尝试了，所有的成功者都是敢于冒险的人。实际上，行动本身就创造了最大的成功机会。所以后来者有六成把握的时候就应该扑上去，小公司只有更多地冒险才能换来更多的机会。

“行动本身就创造了最大的成功机会”，和上一点的观点类似，谁能参透事物的本质呢？无非是走得多了，经验更丰富罢了，像天才一万小时的理论一样，挖掘出来的常识就是，联系得多的人渐渐变成了“天才”，而真正的天才也许存在，但是和我们有啥关系呢，世界上所有美与好的东西又不是全靠真正的天才建成的。所以带着独立思考和自省的态度放心去做即可。

5. 团队成员需要协同作战，有三个原则非常重要：(1)共同的愿景和价值观。(2)彼此信任。(3)注重沟通技巧。

孙陶然老师说注意沟通技巧尤其重要，深以为然，我认为沟通有两点必须做好，一是公开，二是理解，公开无需多说，如果不公开自己内心所想，那还沟通个屁，前提都不成立。其次是理解，核心是能够换位思考，特别是在持不同观点的时候，如果能稍微踩一脚刹车，试着换到对方的角度和思维习惯去理解他说的话的意思，这样能避免由于观点不同导致激烈冲突，而且如果能真正理解对方的观点，在说服对方接受自己的观点也会顺利一些，成功率更高。

6. 西方人习惯用契约来解决问题，先小人后君子。中国是一个喜欢将人情与商业、政治与经济混在一起的国家，中国人喜欢用情义来解决问题。事先你好我好大家好，而一旦出现分歧，这个不行那个不行怎么都不行。你和我讲契约，我和你讲感情，你和我讲承诺，我和你讲道理，纠缠不清。

切记，所有的分歧和意见最后需要形成契约和规定，人人都有选择权，参与还是不参与，但是一旦选择了就按照契约来，把自己讲得很崇高很有理想太容易了，占这样的小便宜真是心头又爽又划算，还可以到处吹嘘，但真要做好事情得都和规矩较真，包括和这个社会的规矩较真。

7. 如果可能，创业要选择最肥的市场入手，在一个大市场中占有一个小份额就了不得了。选对创业方向事半功倍，不要会啥做啥，要抓住用户的强需求来创业，在个人爱好、个人特长及市场需求之间找到一个平衡点。

个人觉得，社团和公司最大的区别在于‘爱好’、‘特长’和‘需求’的顺序，做社团，最大的选择依据是爱好，喜欢什么就扑上去做吧，这样才能慢慢把爱好培养成特长，需求可以最次之，随缘。但是公司得反过来，首先得考虑的是需求，其次是特长，最后才是爱好，要由自己的性子喜欢什么做什么那还是别创业了，那叫求生活，自己一个人玩就行了，一帮人在一起，彼此都是负有责任的，这在我们这样的小年轻居多的创业公司尤其需要多多思索。另外关于需求，书里面有些观点摘抄一下：“什么是需求？用户愿意支付代价的取药就是需求”，但是根据需求做出来的东西不一定能叫“产品”，“如果只是少数人在少数时候才会需要的，趁早别做，那叫概念不叫商品”，“也许用户今天会在网站上停留三小时，但三周不来，他也无所谓”，“需要和购买是两回事，有些需求其实不存在，例如那些可有可无的需求，那些用户根本不愿意为之付出代价的需求，以及那些可以被替代的需求，都属于锦上添花的需求，对消费者而言有了更好没有也无所谓”。

8. 所有的成功都是因为啃下了必须啃的骨头而不是捏到了捏得动的软柿子。

别畏难。

9. 创业期的公司大多业务未定型，核心任务是找方向，寻求业务突破。任何一级领导都不能只管人不管事，尤其是核心高管，不懂业务和不参与业务的高管必然被淘汰。

创业团队没有人能够做到脱离于具体的事物运筹帷幄，有这样的人的话也只说明他是多余的，因为创业初期一切未定的时候，哪里有什么好运筹的，相反最关键的倒是去深入团队所做的每一件事情里面，不是干预，而是深深的了解每一个项目的进程、每一个成员的进度、每一个产品的细节和功能，这些其实是给定方向提供足够的参考，参考越多、越细致的话，决策失败的几率可能越小。

10. 一个被彻底贯彻了的战略好过朝令夕改。

彻底贯彻这几个字本身就是一个不断提高执行力的过程，也是杀怪吃分升级的过程，现在砍不翻大boss没关系，怕的是畏首畏尾，大的吃不下来，小的又不想吃，自己手里的没做好就望着其它地方去了，做项目也是一样，复盘留到项目结束后再来，做项目的过程全部精力都应该是：搞定它。

11. 一个团队的战斗力不是由队伍中最聪明的那个人决定的，而是由战略的正确性和团队的齐心协力决定的。尤为值得关注的是队伍中的“聪明人”，他们是队伍中的危险分子。登山时他们总想抄近路，游戏时他们总想去守株待兔，时不时就脱离预定位置让同事踏空。聪明人总认为自己聪明，所以贯彻领导指示之前总要评估一下领导对不对，往往不会去理解领导的意图而是沉湎于自己的意图。聪明人对团队的贡献在于其创造力带来的鲇鱼效应，但鲇鱼只能敲边鼓不能挑大梁。

两点：团队的核心成员需要重视大局多余重视自己的才能的展示和发挥，因为核心成员是挑大梁的，要更有责任心。其次，我认为这里所指的聪明其实并不是真正的聪明，就像我之前听人说的某种“中国式的智慧”，去你妈逼的智慧，既短视又自以为是还他妈的不反省，有哪个聪明的人会这么做呢？真正聪明的话，多多考虑别人，多多付出结果才会双赢。

12. 不要认为你自己是产品的用户，当你研发产品的时候你已经不是用户了，因为你每天沉醉在产品里边，对产品的熟悉程度已经远远超过普通用户，你已经不可能理解普通用户的使用体验了。

这又是一个不结合上下文理解的话容易误解的观点，自己做的产品自己不是用户的话也趁早别做了，这句话的意思是这样的一个反省：当自己太熟悉自己的产品的时候，可能对普通用户对产品的需求、体验上的判断容易错误，比如一些功能因为是自己设计开发的，可能自己很清楚，但是看普通用户的使用才发现不是这样。举个更远的例子，我发现我们长时间使用电子类产品所以对它们建立起来的各种理解在那些不常用电子设备的人身上是完全无效的，一个很简单的小叉按钮我们看着明白是取消、删除之类的意思，但是不怎么使用电脑的用户就可能不知道，所以核心还是，别自以为是，多留一些余地，多思考多实践来找方法。

13. 人生最关键的是两件事：想清楚和坚持住。想清楚两点：(1)根本目标–你想过什么样的生活。(2)最高准则–你想成为一个什么样的人。坚持住两点：(1)上进心–立志让自己成为同学之中的出色者之一。(2)执着劲儿–坚持自己的追求，遇到任何苦难都不放弃。

一直以来觉得人生本质是很荒诞的，因为面对“既然我们都会死亡，那活着有什么意义”这个问题的时候，所有的答案从某些方面来讲都是虚无的，但实际上我们在生存的时候依然具有喜怒哀乐之类的情感，是因为我们天生的会喜欢高帅富真善美，所以我们为什么每天兴致勃勃的做着做那，充满希望的生活下去，无非是舍不得那些让我们感到充满欢喜的事物，而我个人想要的，无非是自由的在一个拥有这些美好体验的环境中生活，而我也期待能在这个环境中创造出一些美好的事物来，这是我的最高的生活目标。

我们在做一些网站项目的时候，可能会遇到需要把某个全局变量注入到所有页面的情况，比如我们做一个在线商城，那么可能需要将用户的资料：比如用户的账号、用户的姓名等注入到每个页面里面。

TeamCola中每个页面右上角都会出现的用户名

但是如果用常规的方法，也就是在每个views方法中通过render_to_response方法注入用户数据的话，这样就会做非常多的重复工作，就像下面这样：

def views_meth1(request):
    return render_to_response('template_1.html', {'user': request.user})
 
def views_meth2(request):
    return render_to_response('template_2.html', {'user': request.user})
 
def views_meth3(request):
    return render_to_response('template_3.html', {'user': request.user})
 
# ...剩下的N个方法

这在需要传入的变量比较简单、数量较少的时候还行，一旦需要注入的变量多一些，或是需要经过一些额外的计算才能生成的时候，那就麻烦大了。所以如何避免这种repeat yourself的2B模式呢？我们可以选择如下的一种模式：

在每次创建新的django项目的时候，一般来说我们都会在根目录中创建一个类似名为utils.py的工具module，在这个module中，我们可以通过定义一个自己的render方法，来为每次模板的渲染注入指定的全局变量：

# in utils.py:
def mp_render(request, template, context={}):
    context['user'] = request.user
 
    return render_to_response(template, context)
 
# in views.py:
from utils import mp_render
 
def views_meth1(request):
    return mp_render(request, 'template_1.html')
 
def views_meth2(request):
    return mp_render(request, 'template_2.html')
 
def views_meth3(request):
    return mp_render(request, 'template_3.html')

很好理解吧，这样以后有新增加的全局变量需要注入的话，只需要修改mp_render方法就行了。嗯，这是很普通的方法，既然是普通方法，那就再来个文艺点的吧。

先来看看django文档里面对于render_to_response这个方法的定义吧，在’Required arguments’里面，有提到这个方法的第三个参数，叫context_instance，对于这个参数的说明如下：

The context instance to render the template with. By default, the template will be rendered with a Context instance (filled with values from dictionary). If you need to use context processors, render the template with a RequestContext instance instead. Your code might look something like this:

return render_to_response('my_template.html',
                          my_data_dictionary,
                          context_instance=RequestContext(request))

大意是：“默认的，render_to_response方法的第二个dictionary参数会被填充为一个Context对象注入进html模板文件里面。如果你需要使用context processors，那么需要使用一个RequestContext对象来渲染模板。”

那么什么是context processors呢？看完这一段文档的定义以后，应该一切就很明了了。

首先需要明白在django模板系统中，有两种封装模板变量的类，一个是django.template.Context，这是最常用的，我们在使用render_to_response方法的时候传入的第二个dictionary参数，就会被这个Context类封装一次，然后传到模板当中；另一个是django.template.RequestContext，它和Context类相比有两个不同之处。第一个不同的是，在生成一个RequestContext变量的时候，需要传入一个HttpRequest对象作为它的第一个参数：

c = RequestContext(request, {'foo': 'bar', })

第二个区别是，它会增加一些自动注入模板的变量，这些变量从哪儿来呢？在django的settings.py里有一部分是配置TEMPLATE_CONTEXT_PROCESSORS的，这个配置中的那一个个的tuple元素其实是一个个可以被调用的方法，而这些方法都会接收一个HttpRequest对象作为参数，而最终return一个dictionary，这个dictionary里面的元素就会成为RequestContext中自动注入模板的变量。我们看看settings.py中TEMPLATE_CONTEXT_PROCESSORS的某一个元素 django.contrib.auth.context_processors.auth 对应的代码吧:

# in django/contrib/auth/context_processors.py
def auth(request):
    """ ignore doc string """
    def get_user():
        ....
 
    return {
        'user': SimpleLazyObject(get_user),
        'messages': messages.get_messages(request),
        'perms':  lazy(lambda: PermWrapper(get_user()), PermWrapper)(),
    }

可以看到，auth方法最后返回的一个字典中，包含了三个元素，所以如果在使用render_to_response方法时，传入了第三个RequestContext参数，那么在它所渲染的模板中，就可以获取到对应的user、messages、perms变量了。

所以最后文艺解决方法是，在每一个需要注入全局变量的views方法中，调用render_to_response的时候，都传入第三个RequestContext对象参数即可：

def views_meth1(request):
    d1 = {'method': 1}
 
    return render_to_response('template_1.html', d1, context_instance=RequestContext(request))
 
def views_meth2(request):
    d2 = {'method': 2}
 
    return render_to_response('template_2.html', d2, context_instance=RequestContext(request))
 
def views_meth3(request):
    d3 = {'method': 3}
 
    return render_to_response('template_2.html', d3, context_instance=RequestContext(request))

这样需要注入的全局对象，就可以通过扩展TEMPLATE_CONTEXT_PROCESSORS来实现，灵活性更高，更易扩展。当然，在一般的项目开发中，个人觉得普通方法也足够用，所以就根据项目来做取舍吧。

最近在做的一个项目中需要使用到HTML5中引入的WebSocket技术，本来以为应该很容易就能搞定，谁知道在真正上手开发了以后才发现有很多麻烦的地方，虽然彩程是一个以前端开发和设计见长的团队，而且作为一个二手程序猿又长期不被待见，但是为了让有同样需求的朋友少走些弯路，我还是决定把实现方法贴在这个地方。

关于WebSocket的基本概念，维基百科上解释的很清楚，而且网上也能搜出来一大把，这里就略过不表，直接进入正题。

这次的问题首先有一个前提，就是得用Python来实现这个服务器，如果对具体语言没有限制的话，推荐大家首选Node.js的一个第三方库：Socket.IO，非常好用，10分钟不打针不吃药搞定WebSocket Server，而且用JS来写后端，相信也能对上很多文艺开发者的胃口。

但是如果选择用Python，google搜索的结果几乎都不能用，最要命的问题是，WebSocket协议本身还是一个草案，所以不同浏览器支持的协议版本有所不同，Safari 5.1支持的是老版本协议Hybi-02，Chrome 15以及Firefox 8.0支持的是新版本协议Hybi-10，老版本协议和新版本协议在建立通信的握手方法还有数据传输的格式要求上都有所不同，导致网上大多数实现方式只能适用于Safari浏览器，并且Safari和C&F浏览器之间无法互相通信。

首先第一步需要解释的是新、旧版本WebSocket协议的握手方式。我们先来看看三个不同浏览器发送的握手数据的结构：

Chrome：

GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: 127.0.0.1:1337
Sec-WebSocket-Origin: http://127.0.0.1:8000
Sec-WebSocket-Key: erWJbDVAlYnHvHNulgrW8Q==
Sec-WebSocket-Version: 8
Cookie: csrftoken=xxxxxx; sessionid=xxxxx

Firefox：

GET / HTTP/1.1
Host: 127.0.0.1:1337
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive, Upgrade
Sec-WebSocket-Version: 8
Sec-WebSocket-Origin: http://127.0.0.1:8000
Sec-WebSocket-Key: 1t3F81iAxNIZE2TxqWv+8A==
Cookie: xxx
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

Safari：

GET / HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: 127.0.0.1:1337
Origin: http://127.0.0.1:8000
Cookie: sessionid=xxxx; calView=day; dayCurrentDate=1314288000000
Sec-WebSocket-Key1: cV`p1* 42#7  ^9}_ 647  08{
Sec-WebSocket-Key2: O8 415 8x37R A8   4
;"######

可以看出，Chrome和Firefox实现的是新版协议，因此只传输了一个”Sec-WebSocket-Key”头以供服务端生成握手Token，但是遵循老版本的Safari的数据中有两个Key：”Sec-WebSocket-Key1″和”Sec-WebSocket-Key2″，因此服务端在生成握手Token的时候，需要做一次判断。先来看使用老版本协议的Safari，Token生成算法如下：

取出Sec-WebSocket-Key1中的所有数字字符形成一个数值，这里是1427964708，然后除以Key1中的空格数目，这里好像是6个空格，得到一个数值，保留该数值整数位，得到数值N1；对Sec-WebSocket-Key2如法炮制，得到第二个整数N2；把N1和N2按照Big-Endian字符序列连接起来，然后再与另外一个Key3连接，得到一个原始序列ser_key。那么Key3是什么呢？大家可以看到在Safari发送过来的握手请求最后，有一个8字节的奇怪的字符串“;”######”，这个就是Key3。回到ser_key，对这个原始序列做md5算出一个16字节长的digest，这就是老版本协议需要的token，然后将这个token附在握手消息的最后发送回Client，即可完成握手。

新版协议生成Token的方法比较简单：首先把Sec-WebSocket-Key和一串固定的UUID “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”做拼接，然后对这个拼接后的字符串做SHA1加密，得到digest以后，做一次base64编码，即可获得Token。

另外需要注意的是，新版本和老版本握手协议回传给Client的数据结构有所不同，在附件中的server源码中写得很清楚了，看看就能明白。

完成握手只是WebSocket Server的一半功能，现在只能保证这个Server能够和两个版本的浏览器建立链接了，但是如果试着把Chrome中的消息发送给Safari，会发现Safari无法接收。导致这个结果的原因，是因为两个版本的协议的Data Framing结构不同，也即是在握手建立连接后，Client发送和接收的数据结构都不一样。

首先第一步需要获取不同版本协议下Client发送过来的原始数据。老版本协议比较简单，实际上就是在原始数据前加了个’\x00′，在最后面加上了一个’\xFF’，所以如果Safari的Client发送一个字符串’test’，实际上WebSocket Server收到的数据是：’x00test\xFF’，所以只需要剥离掉首尾那两个字符就可以了。

比较麻烦的是新版本协议的数据，按照新版draft的解释，Chrome和Firefox发过来的数据报文由以下几个部分组成：首先是一个固定的字节（1000 0001或是1000 0002），这个字节可以不用理会。麻烦的是第二个字节，这里假设第二个字节是1011 1100，首先这个字节的第一位肯定是1，表示这是一个”masked”位，剩下的7个0/1位能够计算出一个数值，比如这里剩下的是 011 1100，计算出来就是60，这个值需要做如下判断：

如果这个值介于0000 0000 和 0111 1101 (0 ~ 125) 之间，那么这个值就代表了实际数据的长度；如果这个数值刚好等于0111 1110 (126)，那么接下来的2个字节才代表真实数据长度；如果这个数值刚好等于0111 1111 (127)，那么接下来的8个字节代表数据长度。

有了这个判断之后，能够知道代表数据长度的字节在第几位结束，比如我们举得例子60，这个值介于0~125之间，所以第二个字节本身就代表了原始数据的长度了（60个字节），所以从第三个字节开始，我们能抓出4个字节来，这一串字节叫做 “masks” (掩码?)，掩码之后的数据，就是实际的data…的兄弟了。说是兄弟，是因为这个数据是实际data根据掩码做过一次位运算后得到的，获得原始data的方法是，将兄弟数据的每一位x，和掩码的第i%4位做xor运算，其中i是x在兄弟数据中的索引。看得眼花是吧，看看下面这个代码片段也许就能明白了：

def parse_data(msg):
    code_length = ord(msg[1]) & 127
 
    if code_length == 126:
        masks = msg[4:8]
        data = msg[8:]
    elif code_length == 127:
        masks = msg[10:14]
        data = msg[14:]
    else:
        masks = msg[2:6]
        data = msg[6:]
 
    i = 0
    raw_str = ''
 
    for d in data:
        raw_str += chr(ord(d) ^ ord(masks[i%4]))
        i += 1

至此，已经可以顺利取出两个版本浏览器发送来的原始数据了。接下来，就是将这个原始数据封装成不同协议版本的需要的Client数据，发送给对应浏览器就可以了。支持老版本协议的Safari还是很简单，如果从Chrome或者Firefox发送来的原始数据是字符串’test’的话，按照之前解码的方式，前面加上一个’\x00′，最末加上一个’\xFF’，变成’\x00test\xFF’就可以发送给Safari接收了。如果是从Safari发送来的原始数据’test’，同样需要做解码的逆运算，唯一简单的，是不需要再用一个masks来生成一个兄弟数据了，从Server端发送原始的数据给Client就可以了。

还是来模拟这个过程，首先数据的第一位仍旧是1000 0001(‘\x81′)，接下来获取原始数据的长度data_length，根据长度是否超过125位，来生成1个字节或是3个字节的代表长度的位数（附件中的源码省略去了使用9个字节表示数据长度的情况，因为实际的Server不会传输那么大量的数据），最后再将该字节串和原始数据拼接起来，就可以了，代码片段如下：

def send_data(raw_str):
    back_str = []
 
    back_str.append('\x81')
    data_length = len(raw_str)
 
    if data_length < 125:
        back_str.append(chr(data_length))
    else:
        back_str.append(chr(126))
        back_str.append(chr(data_length >> 8))
        back_str.append(chr(data_length & 0xFF))
 
    back_str = "".join(back_str) + raw_str

这样生成的back_str，就能够发送给使用新版协议的Chrome或是Firefox了。

至此，这个简单的WebSocket Server就完成了，能够同时兼容老版协议和新版协议的Socket连接，以及不同版本之间的数据传输。该Server的源码请点击这里下载，需要注意的是里面用到了twisted框架来跑TCP服务，代码写得不怎么样，仅供大家参考。

参考文档：

1、The WebSocket protocol draft-ietf-hybi-thewebsocketprotocol-17
2、How to (de)construct data frames in WebSockets hybi 08+?
3、基于Websocket草案10协议的升级及基于Netty的握手实现
4、ABC of WebSocket

是的，我们决定不顾一切的发布TeamCola了。

在之前的一周里，我们试图调整栏目结构、试图改进工时展示、试图优化日志录入… 但是就在前几天，我们突然反问自己，我们这是在瞎折腾什么呢？这已经是一个完整的、正式的TeamCola了，它并不完美，但是这又何妨？当我们的邮件列表每天涌入大量的订阅者，当我们每天都花很多时间在给申请内测的朋友开通账号的时候，我们突然意识到，发布TeamCola的时间到了。

感谢参加TeamCola内测的所有朋友，谢谢你们给我们的所有意见和建议，是你们让他更快的成长。在TeamCola发布之后，我们还会持续、快速的改进他。

最后，欢迎你使用可能是目前最好的工时记录软件 — teamcola.com。

在我们公布TeamCola产品化的消息后，有不少朋友通过网站(http://teamcola.com)、新浪微博(@teamcola)、邮件(m2@teamcola.com)等找到我们，询问有关测试账号申请和邀请码的问题，这里给大家做一个解答。

TeamCola是一个小团队工作日志工具，虽然作为个人使用也没什么问题（事实上有人就是这么干的），但是TeamCola的定位还是在于记录和展现小团队的工作，所以我们只会给那些愿意以小团队规模（3-20人）参与试用的朋友发放独立账号，并且需要提供一些必要的信息以完成账号的建立，当然，也不存在所谓的邀请码了。

而在此之前，我们会让申请测试的朋友亲自试用一下TeamCola以后，再决定是否让自己的团队加入到试用中来。具体的方法是，我们会建立一个用于测试的团队，然后邀请各位希望参与试用的用户到这个测试团队中来进行试用和评估，稍后各位会收到我们发出的邀请邮件。

如果在个人试用后，决定让自己的团队也试用TeamCola，请给m2@teamcola.com发送申请邮件，我们会和你联系，并为你创建独立的团队账号。

最后想说的是，TeamCola还是一个开发中的产品，基于我们自己和一些兄弟团队的使用情况来看，它的核心功能没有问题，所以我们愿意拿给各位朋友来试用，也很希望能听到你们的意见和建议，以帮助我们完善它的设计。

谢谢 ：）

“一个国家，就业的65%到80%是由小企业解决的，发达国家，每千人口一般有45个到50个小企业，中国目前每千人口的企业数量，将平均2人的个体户5个折成一个企业，加上注册登记的其他全部企业，拿全部人口除，我国为12人不到，因此就业困难，实际失业率较高。一定要让大家创业办小企业，以解决就业问题“ — 周天勇

今天是新版TeamCola正式上线，给我们团队那些自诩为水手、船长、船员、船工…的家伙们使用的日子，在这个时刻，我的14位伙伴分布在这个城市的5个不同的地点，他们有的在咖啡馆里抱着电脑喝着咖啡编写着代码，有的在自己的家里刚刚练习完一副书法，准备开始今天的视觉设计，而我们的CEO，目前正在市中心的一家医院里照看着他刚出生的宝贝女儿。

嗯，对于一个创业团队来说，这样远距离的办公难道不会出问题么？我们的答案是：不会。除了我的同伴们基本闪亮的人格外，TeamCola确实帮助了我们。

在09年的时候，当我们这群创业的家伙们找到了比较稳定的客户和收入来源，并且组建了一个基本成型的团队后，面临的最大的问题是怎么减少我们工作中那些麻烦的事情。在当时，让我们最头疼的问题是每个月发给我们客户的工作记录，我们需要让每个项目参与者使用规定的格式提交他们的工作记录，但是，我们发现除非每天发日报，否则过个两三天，没人能想起来之前自己做过什么。于是我们想使用一些现成的web app来解决这个问题，但是在搜遍了整个互联网之后，我们失望的发现，那些给小团队使用的工具，要么就是复杂得让我们望而生畏，要么就是粗糙简陋得让人用起来就觉得恶心。

真的这么难么？我们只是需要一个做工作记录的软件，仅此而已。所以一怒之下，在09年的10.1长假，我们花了几天时间自己搞了一个小工具：PowerMatrix，也就是TeamCola的前身。

PowerMatrix在之后很长的一段日子里，很好的完成了工作记录的使命，但是它也有不尽如人意的地方。其中最大的问题在于，PowerMatrix只是一个个人工具，为了让我能“偷窥”到别人的工作记录，我们故意不提供修改各自账号密码的功能，每个人的密码都很容易记住，所以….是的，我们也经常犯傻。

到了后来，我发现不仅仅是我有“偷窥”的怪癖，更多的家伙们喜欢去偷窥别人干了啥，于是我们觉得是应该把PowerMatrix做得更好一些了，于是在2010年的最后一个月（一般来说，一年的最后一个月会比较轻松，我们也有更多的时间来开发这些part-time tools），我们开始了新版PowerMatrix的设计，并给它取了个新名字 —— TeamCola。

这个时候的TeamCola，我们仍然只是把它作为一个自用的工具，在TeamCola上面记录我们的工作，能够看到别人的工作，以及看到项目的进展情况，甚至还做了一个简单的任务模块来做任务分派功能。但是在几个月的使用过程中，我们渐渐发现，我们在TeamCola上真正离不开的，仍然是工作记录，而工作记录，成为了我们团队凝结在一起的一个基点。透明和一目了然的工作记录，构成了我们成员彼此信任及帮助的基础，我们再也不需要每天的daily meeting就能清楚的知道我们的同伴们在做什么，我们也能从彼此的记录中，检视各自的工作；也不会让我们团队的成员像完成家庭作业一样编写工作周报、月报，心得体会、工作感想…每天的工作内容汇聚在一起，能自然呈现出自己或成员工作上的问题，而愿意真情流露的家伙们自然会乐意多写一两句。这样的模式，简单，却真有帮助。

因此，在短暂几个月的内部使用后，我们花了三周时间重新设计并开发了目前这版TeamCola，一切围绕工作记录。日历模式方便所有成员记录工作，而基于成员记录的工作内容，我们能关注到团队每个项目和成员的工作时间趋势，知道哪些项目和成员忙得”吐血“，哪些成员最近比较清闲。

使用TeamCola查看团队工作情况

在医院的那位CEO童鞋这么评价它：“支持iPad的TeamCola，让我可以在医院这样的环境，也能随时随地的掌握团队动态，不用离开家人，能安排更多的时间照顾女儿，更不用跑去办公室当工作狂。TeamCola还减少了很多内部的工作邮件往来，让我可以有更多的时间照顾家人。”

嗯，一切都很简单。

对iPad示好的TeamCola

在创业的这几年里，我见到过很多同行的伙伴，他们有的壮硕一些，有的还比较瘦小，但是让我觉得真正难受的，是在一个恶心的环境里，能够帮助到包括我们在内的小团队的东西太少了，而我不明白的是为什么我们有些牛逼同行们能很快的拿一些国外的产品来做微创新，却不愿意做一些真正能帮助小企业工作的工具；也不明白这个娱乐至上的时代，还有多少人在努力着并无愧于自己的工作，而每次这样想的时候，就会由衷感谢那些和我们同行的伙伴。

现在，我们决定把TeamCola产品化，把这个对我们团队有些帮助的工具提供给所有愿意提高自己工作效率和为自己工作负责的小团队使用，希望能帮助你们从那些笨重而复杂的OA系统、协同办公软件中释放出来，别让本就复杂的工作环境里再多一台压死骆驼的起重机了吧。

我们还会在接下来的一个多月里对TeamCola进行调整，欢迎关注TeamCola，也欢迎和我们多多交流。

2010年，是我们团队驶向移动互联网的元年，在这一年里，我们为大家带来了“牛壹周”、“百家”、“冯唐文字”、“小鸡快跑”等作品，而在2011年的开年，我们想用一枚“拜年财神”带给大家来自彩程的新春祝福：

爱心厨艺大师Fish给您拜年了～

愤怒中年老妖给您拜年了～

交互帝多发给您拜年了～

来自传说星球的Shawn给你拜年了～

快要当爹而经常迟到的S给你拜年了～

喜欢小猫及beky的小滨滨给你拜年了～

愤怒的小马给你拜年了～

外星人给你拜年了～

卖萌王小龙给你拜年了～

闷骚男aben给您拜年了~

川大的给你拜年了～

考勤王+流程王古灵给你拜年了～

——————————————————–我是分割线——————————————————-

我们的拜年财神带给大家的第一份礼物，是来自全国各地的祝福话语，晃晃手里的拜年财神，他就会选择一种他认为足够搞笑的方言为您送上新春祝福，当然，您也可以在您的亲朋好友面前晃动财神，把这份祝福送给他们。

晃动财神，即可用66种方言为您拜年~

我们的拜年财神带给大家的第二份礼物，是能够让您获得成为财神本身的能力。点击左下角的拍照按钮，您可以使用设备自带的拍照功能将您或者您的朋友变成拜年财神，给大家拜年。当然，成为拜年财神是有代价的，您需要接受一副香肠嘴，才能获得给大家用不同方言拜年的能力，嗯，您就忍忍吧～

把你或你的朋友变成财神，然后让他/她传播新春祝福吧～

我们的拜年财神带给大家的第三份礼物，是分享功能。点击右下角的钱币按钮，您可以将您的拜年财神通过Twitter、新浪微博、Email三种方式分享给您的亲朋好友，让也许不在您身边的他们也能收到2011兔年的您的祝福。

多种渠道传递你的新春祝福～

拜年财神已在App Store上架，请点击购买。也欢迎您关注我们的Twitter或新浪微博，获得拜年财神的最新消息。

最后，让我们来看看在2011年新春，谁的拜年财神拜年次数最多吧～

截止2010年1月15日，使用google搜索“用户体验设计”，返回1千3百万条结果。

“用户体验设计”无疑是这两年互联网行业最炙手可热的话题，而从我们成都UCD书友会火爆的现场来看，也的确如此。那么“用户体验设计”为什么会如此火爆呢？这需要从互联网的Web2.0革命说起。
这场革命，代表了互联网应用关注焦点的变迁，从以内容为王的门户型网站时代，转变为以用户为中心的互联网服务时代。以用户为中心的互联网服务，自然就需要以用户为中心的设计。但是要做到真正的以用户为中心的设计却并不简单。

这是什么意思呢？我想用彩程的实际经历对这个问题做出解释。和很多其它软件企业一样，彩程也是从一些中小型的企业网站、电子商务网站开发业务启程的。当时我们开发一个电子商务类网站的流程是什么样的呢？

首先会由超级打杂老妖出马，跟客户沟通，套出用户的需求，然后由费西或是老妖自己，三下五除二的搞一个首页出来，拿去给用户确认，用户如果点头，那么ok，开始做首页的html切图，然后丢给程序员开始开发，同时，美工继续孤军深入，出各种特征内页，切html，交给程序员开发，如此循环往复。而一旦整个项目开始进行，客户就很少再参与其中了。
于是，这个项目持续运行，直到某一天，程序员说：“好了”，这样，老妖满怀希望的冲到客户那里，很想听到客户对网站认可，但实际的场景往往是：
客户抱怨说，这里我明明是想要个Flash广告，但是却只有一张图片；这个订单系统怎么不好用，为什么不参考淘宝来做呢？我还想要个会员系统，每个会员有自己的个人页面。
这个时候，可怜的老妖只能作出两种选择，要么照单全收，ok，哪里有问题我给你改哪里，要么就是耍死皮，但是后面一种情况一般不会出现，因为老妖不愿因为得罪客户而丢掉奶粉钱。所以，这个原本大家都认为很简单的网站项目就这样被delay下去了。

这样的情况出现的次数多了，让公司首脑小s同学很不满意，于是他开始召集大家思考，这是为什么呢？让我们来看看之前我们的流程:

经过对这个流程的几个痛苦的日夜思索之后，我们发现了如下几个凄惨的现实：
1. 用户其实并不知道他到底需要什么，就算用户知道，你也别想知道他究竟知道什么；
2. 美工都以为自己只是画画的，而无需去考虑整个产品的设计思想，包括用户角色是什么，商业定位是什么，所以你说你想要个新闻栏目，ok，我照着163画一下就了事了；
3. 程序员都是脑残，只关注用什么设计模式或是用什么框架，美工的设计图对他们来说不值一提，不就是一个for循环生成li标签而已嘛；
4. 客户始终置身世外，他给钱了，只想你干好活，最后一手交钱一手交货罢了，但最关键的是，“货”这个东西，大家除了在最后一霎那能看到它的模样，其它大部分时间它都异常神秘。

很多时候，最大的问题往往在于我们不愿意去面对问题。所以当我们能把问题找到，并敢于面对问题的时候，解决办法的出现就只是时间而已了。这个解决办法，当时我们认为最优的，就是强化设计，最后发现，其实就是引入了“用户体验设计”。

从何入手呢？我们都知道，一般的软件开发流程中，PM会根据用户需求出产品需求分析报告，然后美工介入，出一些视觉界面，然后程序员根据有限的设计图连蒙带猜的进行实际开发。但在这样的模式下，产品会出现几次偏离。

PM只有几十页的文档，而这样的文档传递实际需求的效果极差，不能让用户确认需求，于是出现整个流程中的第一次产品与需求的偏离。美工在做视觉设计的时候，就可能按照他自己的想法天马行空，最后出现整个流程中的第二次产品与需求的偏离。程序员在拿到美工有限的设计图后，大概想了想，觉得自己明白了，然后就开始写代码，但是由于没有完整的产品模型到程序结构的映射，最终导致第三次产品与需求的偏离。这样带来的致命后果就是：用户明明想要个美女，但是最终实际交付的却是个如花。

这样的流程最大的问题在于，缺少一个能够聚焦各方的核心，几十页的文档无法胜任，而原型却可以。

我们认为原型会很重要，于是我们首先引入了原型设计。在这个设计过程中，我们使用Axure作为辅助工具，它的好处在于，能让任何一个PM很容易的上手，并能把需求书中几十页的文字落地为实际的界面。

在PM快速完成原型设计之后，PM会带着原型去和客户讨论，客户由于能有实际的使用感受，所以能够很快的分辨出设计与他需求之间的偏差，然后PM根据用户的反馈修正原型。

接着，美工上场了，注意，这个时候，美工不再是美工，他有了新的title—视觉设计师。有什么新的要求呢？他需要仔细的去评估原型，从设计师的角度出发，对原型提出意见。接着，才是用PS将界面画出来，然后根据设计图制作另外一份原型—高保真原型。

高保真原型和之前的原型—也就是低保真原型–的差别在于，低保真原型着重完成信息元素的组织以及概念模型的搭建，目标定位在为产品搭框架，填充素材。但是高保真原型会完成对框架的装修以及对素材的组织。这样得到的高保真原型和实际交付的产物就几乎是100%趋近的了。

然后，产品经理会带着这份珍贵的礼物再次走访客户，根据客户的使用反馈做最后的原型调整，至此，整个原型设计阶段结束。

接下来，根据高保真原型，我们给出了整个原型的HTML代码，包括规范的CSS样式表以及JS接口，都由我们的前端工程师定义并实现。

最后，我们交到产品实施人员手里的就有两样东西，一是高保真原型，一是HTML框架代码。我们希望高保真原型能真实反应用户需求，并且让实施者知道开发出来的东西是一个什么样子的。其次，通过提交高质量的html代码，减少普通程序员的工作量，因为不可否认的是，如今复杂的前端技术不是一个普通的java程序员能短时间掌握得了的。

所以，最后我们的第一版用户体验设计流程就是这样的：

这样的流程解决了我们之前的哪些问题呢？

首先，原型能够成为客户和项目经理之间的沟通媒介，极大地降低沟通成本；其次，美工获得了解放，从被动画图，转为通过原型真正的参与到了产品设计的流程中来；然后，程序员能通过原型知道自己要做出来的东西究竟是什么样的；最后，再通过提交完整的前端代码，把传统程序员的前端短板一并解决了，这个流程就似乎已经非常完美了。

那么实际情况呢？首先需要承认的是，这确实是一个飞跃。我们自己的网站项目都得以顺利的实现，不再有delay的情况，而客户的反馈也非常良好。但是当我们想以外包服务的方式将用户体验服务提供给客户的时候，就出现了问题。
首先的问题是，外包形式的用户体验服务，我们的服务对象从最终用户变成了外包服务购买者，这使得和有效用户进行沟通的成本上升了，在需求调研的时候，感觉难以对最终用户进行定位。
其次是，我们发现低保真原型和高保真原型极有可能变成内部的闭门造车活动，拿出一个完善的原型往往持续很长的时间，而客户的产品经理或者项目经理没有在设计途中参与进来，所以当拿出最终的高保真原型的时候，我们自己的设计师就变成了客户的产品经理。
最后的问题是，我们交付给程序员的前端代码太多，导致这样的朴素的心理问题出现：我是程序员，如果我拿到一份不是我写的代码，我就有很强的畏惧心理，不愿意去看。这样，实际的开发过程中，有很多前端的问题会压到我们团队头上，因为任何一个前端功能的开发，客户的程序员都可以说，前端代码不是我写的，我不会。

好吧，问题当然是不会结束，但我们还是选择解决问题。

关于难以对最终用户进行定位，我们在做需求分析的时候加入角色分析环节来帮助我们完成这个任务。在《设计沟通十器》这本书中，罗列了角色分析文档所需的各个要素，我们选择其中最重要的，用户基本信息、动机、场景、对应需要实现的产品功能来完成角色分析文档。这份文档帮助我们建立起了最终的用户模型，因此我们在做原型设计时，就有了最终用户的标准参照物。

其次，我们在设计原型时，尽量和客户一起设计，也即是用很高的迭代频率和客户交流，甚至时常驻点在客户那里进行设计，让客户随时了解到我们的原型长成什么样了。

然后，在原型设计阶段加入了可行性分析这一环节，提前将程序员拉入设计。和把客户拉入设计一样重要，需要程序员在早期就介入到对设计的评估，包括对后端数据以及前端逻辑实现难度的确认。这个环节确保在后期开发的时候，程序员能有所准备，杜绝了推卸责任的现象。

最后，我们拆分了前端代码开发部分，将前端开发工作改为提供两份文档，一份是视觉规范文档。这份文档详细的提供了视觉界面设计的规范，比如字体规范、是否自适应宽度，各种配色组合等等。另外一份就是开发指南，包括在可行性评估中得出的有难度的前端部分的示例代码，和相关的接口文档。这两份文档主要在于鼓励程序员真正介入前端开发。有问题也不要紧，我们会按项目的实际情况，为客户提供不同时间的现场技术支持。

这样，就得到了目前我们使用的流程：

彩程UED流程图

那么，这样的流程实施的效果怎么样呢？我们来实际看一个例子。这个例子是给四方科技的一款网络优化平台提供用户体验设计服务。

首先是对产品进行商业目标需求调研，在了解到这款产品的基本商业目标定位后，我们便开始了用户角色分析。我们首先把产品的最终用户分为两类，一类是管理层，他们最大的愿望是，一眼掌握自己企业的网络使用情况，想知道自己为什么发封email都会这么慢。当他们一眼发现自己企业网络出现异常后，接着他们需要把优化网络的任务下派给一个下级，这个下级可能就是人事部经理或一个网管。他们的最大愿望是，确保公司网络的正常运行，完成老板下达的任务。

角色分析

有了这样一份角色分析文档，接着我们的低保真原型设计就会围绕角色的动机和场景来进行。下面我们来看看首页设计：

低保真原型

可以从这个流量监控的首页看出，如果我是老板，很容易掌握的几个信息是：今天公司网络的整体流量情况，现在哪个员工的流量最高，是否正常。有了这几个信息，我就大概知道我自己发邮件，之所以慢，是不是由于内部网络原因引起的。如果是，这时候我就会抄起电话打给人事部经理或是网管，让他给我解决问题了。

人事部经理得到这个任务后，就会通过平台的流量实时监控页面，找出究竟是哪部分的流量出现了问题。然后在上网控制页面，修改对应的网络策略即可。

围绕角色文档的低保真设计之后，我们的视觉设计师会基于低保真原型出视觉设计图，并将其作为素材制作高保真原型。最终的高保真原型就是这样的：

高保真原型

高保真原型结束后，紧接着是两份文档的编写，一是这样的一份视觉规范文档，我们看到这份文档中包含了页面布局定义、字体的字号以及颜色、所有控件的颜色定义等。

接下来是一份开发指南文档，其中给出了一些复杂控件的前端代码实现参考，供程序员在实际开发时使用。

最后，我们在用户现场完成了4个工作日的现场技术支持服务，解决了一些html框架搭建，切图等前端技术问题。

这就是我们的用户体验设计流程以及方法。它并不是完善的，甚至可能全盘错误，比如在如何为用户提供更好的前端开发的帮助方面，我们还在进行各种尝试。没有不变的流程，只有不断探索。

最后，我想回归到“用户体验设计”本身。用户体验设计的出现，只是代表传统软件行业在互联网时代开放、共享、自由的氛围中的一种进化需要，而它最终会和整个软件产品的研发流程融为一体，成为无论是从需求分析、到界面设计再到开发到运维的一部分，因为我们随时都需要将用户置入服务的核心，用我们的爱来浇注产品本身。

第三届成都Ria Meeting上周日在Jex的公司还算顺利的举行了，这是我第二次参加这种民间自发活动，和上一次中途参与临时上阵不同，这次彩程做了首个presentation，分享了我们这两年在用户体验设计服务方面的想法和感受，也展示了一些我们认为有价值的案例，个人感觉效果还算不错。综观这次聚会，觉得有些零碎的想法值得记录下来，供大家推敲一番，以便作为下次活动的经验及参考。

最大的思索是，成都的RIA Meeting如何找到自己的”卖点”来适应本土的受众群？

不同于北京或上海，成都的RIA领域还在起步阶段，聚会的话题无法走高端路线、搞小众的技术粉丝沙龙，但是在基础部分，我感觉我们也还没有定位到最合适的主题。

上一次的RIA Meeting给我们的感觉是，对技术细节的讨论太多，而对于成都主要的听众—那些尚未真正入门只是对RIA技术感兴趣的朋友们帮助不大，这部分听众要么就是来自高校的学生，或者是来自于一些公司的决策者，前者是兴趣驱动，后者是市场引导，所以对高校学生来说，可能他最想知道的是，我如果玩RIA，能做出什么牛逼的东西来吸引女童鞋/男童鞋的注意，而对于公司的决策者来说，他可能想知道，RIA在哪些领域已经有了比较成熟的案例，以及这些案例的实现代价，好做商业评估。而要达到这样的目的，只有放弃技术为中心，选择实际的案例展示做主题，成都的RIA Meeting可能才会收到好一些的反响。

因此，上一届的RIA Meeting结束后，我们和发起人Shawn都觉得应该以”案例”为核心，做围绕RIA技术的Case Show，而不再做一些看似很高端的路演类型的宣讲。而这次的Meeting也就按照总结，主要围绕case来进行，当Shawn播放那段视频的时候，我相信在场的各位童鞋都会觉得比较震撼，这比冷冰冰的流程图或算法要吸引人至少1万倍吧。

我们经常看到北京、上海等大城市有组织各种类似的技术沙龙，像Python聚会、RIA Meeting、UCD书友会等等，成都本土的却寥寥无几，而我们能想到的原因是，成都本地的IT行业的整体成熟度还没有达到相应水平。

交流会现场

RIA Meeting 发起人之肖轶翔（Shawn）

RIA Meeting发起人之陈显军（Jex）

彩程精彩的案例吸引了众多目光

恶搞的风格也赢得了不少笑声

自由讨论期间老妖在胡喷

成都也有很多优秀的IT企业，但是比起北京、上海等大城市来说，这些企业的软件开发模式还很保守，就如我在PPT里讲到的一样，这样的企业还属于未完成互联网进化的传统IT企业，所以也许当前我们的Meeting应该引导的方向，首先应该是定位于如何将互联网的软件文化传播出去，RIA只是这种文化中的一种，同样的还有敏捷开发、移动互联网、用户体验设计等等WEB2.0概念下的互联网文化，能给这些相关领域的同仁在成都找到一个共同分享的环境，给在这座城市里孤军奋战的IT宅们找到个靠得住的组织，把开放的互联网精神传播出去，可能更重要些吧。

最后附上这次Meeting彩程的演讲PPT，供大家参考。

10月10日，彩程工作平台软件PowerMatrix(以下简称PM)正式发布，很高兴看到我们的工作流程和资源能够渐渐沉淀下来，最终变成这样一个可爱的小东西，而PM的诞生过程，给了我一些启示，原本应该明白的东西，如果不能时时提醒自己，很容易就因为自身的懒惰而忘记。

一个多月前的某一天，老s说，“有一点我一直搞不明白，有时候你像个设计师，可有时候你又变得像个程序员了”。这是什么意思呢？先来看看PM的前身：

看上去貌似还不错呢，但是：

这个版本的问题太多，完全无法使用，比如工作记录的信息显示区太小，输入不方便，像是个客户管理系统而不是个工作平台软件，色彩搭配一塌糊涂等等。而我在开发这个版本的PM的时候，正是陷入了老s所说的程序员的状态中。这种状态最大的特点是，远离设计，闭门造车。

在给很多软件开发客户提供服务的过程中，我常常遇到这样一个场景：无辜的程序员承担了软件不好看、不好用的全部责任，而产品经理和设计师却不知所踪，或者干脆就是这些可怜家伙中的一员。为什么开发出来的东西会和用户实际需求的差距如此之大，原因在于在产品开发的初始，项目经理或产品经理并不知道原型设计的重要性，没有原型设计，对产品的功能需求不能落地，因为人的本质是热爱偷懒的，大概知道需求了，便以为对产品了然于胸了。结果在后续的开发过程中，项目经理、产品经理、客户、程序员A、程序员B所理解的，完全不一样，最后导致产品落入失控的地步。通过完整的设计流程使产品落地，本来是我们之所以做服务性质的用户体验设计的初衷，结果这回我自己反倒客串了一把反面角色。

好在能“每日三省吾身”，想明白这个道理之后，就能从程序员的执迷不悟回归设计师的思路了。根据产品的定位，刘竞同学完成了低保真原型设计，累计耗时3天：

根据低保真原型，费西同学花了2天时间搞定了视觉设计和高保真原型：

根据高保真原型完成开发，最终耗时6天。而闭门造车的那个版本，没有客户管理、项目管理、网站租用管理等模块，只有一个最最简单的工时输入功能，都花去了5天的开发时间，如果执迷不悟的做下去，就算给1个月的时间也别想交出个令人满意的东西。

有些时候，我们总是把最正确和轻松的方法放到一边而去选择最累的方式工作或生活，除了自己的思维惰性而外，还真找不出合理的解释。无论怎样，这次的开发说明的，任何产品，无论是我们自己的，还是客户的，绝不能脱离设计，而设计本身，才是PowerMatrix的动力之源。