因为今天在微博上抱怨支付宝在Mac下控件的问题，又想起了「用户是上帝」这句话。恐怕每个人都听过这句话，也有很多人、很多公司将这句话写入公司章程，写在墙上，甚至挂在嘴边，但是很少有人真的把这句话放在心里。

静下心来仔细想一下，发现自己过去可能没有明白「用户是上帝」这说法到底有什么含义。

用户是上帝，不是说对于上帝的所有需求或是要求，你都去满足，那样你无形中在心里将上帝当作了魔鬼，切记不要轻易出卖自己产品的灵魂，不要动不动被用户所驱使。对于上帝，我们要有敬畏心，不要欺骗上帝，不要取悦上帝，按照正确的方式去做事情，遵从你的内心，就是最虔诚之举。对于上帝，不要将其当作观音菩萨，不会有求必应；也不要将其当作泥菩萨，初一十五拜一拜草草了事。而有些公司将用户当作砧上鱼肉，肆意宰割，纵使称霸一时，无法横行一世，早晚会被用户抛弃。

上帝说：「我要恩待谁，就恩待谁；要怜悯谁，就怜悯谁。」

而作为用户的我们，作为某种意义上的「上帝」，倒是应该起码有点同理心。你是服务提供者的上帝，但不要将服务提供者当成孙子，他们更不是你的奴仆。现在用户容易形成当爷爷的的心态，动不动就将「坑爹」的话当口头禅，其实也是不尊重别人的表现，尤其容易形成心态上的对立。如果作为用户是这样的心态，那么也很难服务好别人。

「仁慈的主啊，请您宽恕我们这些无知的罪人吧」

–EOF–

Updated：张小龙认为无论将用户捧为上帝还是贬为仆人都是不公平的。「我们应该是朋友，这一点会在我们的产品里体现出来。」此言深得我心。

Updated: 以开发人员的思维评估产品，落眼点很容易在产品缺陷上，进而忽视产品的核心功能。记住，「好的产品不等于是没有缺陷的产品，好的产品不等于是面面俱到的产品」.

越来越多的做技术的朋友开始加入互联网创业的大军。这几年来，的确见到过不少技术人员创业的成功典范，但没见到没听到过的创业不成功的案例应该更多，所以，先别受那些成功故事的蛊惑，从那些失败的项目或是创业人身上吸收经验和教训更让人受益。

作为一个技术出身的创业者，其长处当然是技术，对自己如何运用技术做出自己心目中的理想产品有把握和信心。不过你的项目能否成功，并不只看你的能力最强那一部分，还要看你的短板是什么，这短板，可能是市场、可能是运营、也可能是组建团队的能力… 总之，技术之外，或许都是你的短板。

很少有人想过，这个短板是怎么产生的。我在这里想说的是，你的短板恰恰因为你你的技术背景形成的，短板就在于你对技术的过度迷恋和自信。这么说肯定很多人不服气，好吧，你是否觉得花一周时间解决一个技术问题远比花一个小时向别人介绍你的产品更加容易 — 而后者是你不想做也不屑做的事情。每当看到别人做到产品不如你居然还超过了你的时候，可能多数技术出身的创业者想到的是: 我再开发一个更牛的功能或许就让对手望尘莫及了。

自身短板的问题，相信不少技术创业者偶尔自己也会想，但做起来就是觉得心有余而力不足，而且一旦做起事情来，慢慢还是向技术那头使劲儿，可能就是”路径依赖”使然吧。要想避免这个问题，不妨就把你最不愿意做的事情列出来，执行得最差的几件事列出来，看看自己是否有能力学习这些”技术含量很低”得东西，是否有耐心将这些事情搞定，如果不行的话，除非你团队中有人和你的能力互补，可以更好的负责这部分的事情，否则，还是找个大公司打工吧。

技术人员创业，应该适当的时间忘掉技术。

–EOF–

不管技术团队规模如何，总要在内部用一些工具来支撑日常工作。这些工具的选择会影响整个团队的效率，不可不慎重。如何做这类产品的评估与选型？每个人都会有自己的方式，这里说说我在丁香园技术团队遇到类似场景的时候，一般会参考的几个维度和评估方法。

活跃分析

目前来看，Google Trends 是个不错的分析产品活跃度的工具，只是有些关键词选择需要注意一下，不要迷惑于表面的数据。

产品特性

一般来说，WikiPedia 的对同类产品的功能比较是非常详尽的。如果是一个相对陌生的产品，无论如何要看一下。真的佩服这些编辑者的水磨功夫，相比之下，国内的有些类似网站，没办法看。

主观评价

通过 Twitter 进行提问，可以收集到很多技术同行的反馈与评价。另外，如果没有候选产品，通过 Twitter 也可以征集产品列表，前提是平时要有不错的互动。

通过搜索引擎可能会找到一些评测文章，一定要注意各自的场景和团队规模以及技术风格，一般来说，此类文章参考价值不是很大。

国外技术人员接受程度

参考一些问答网站，比如 Stack Overflow 的讨论，一些产品的优缺点，几乎都会涉及到。

国内技术人员接受程度

通过新浪微博进行关键词搜索可以基本获知国内技术人员对某技术或者产品的使用与接受程度。比如，搜索一下 “Trac” 这个话题看看。

多方面沟通

尊重内部同事意见与建议，咨询一下更大规模的团队负责人的经验。有句话说得好，”听多数人的意见，和少数人商量，自己做决定”，对于这个场景，也是适合的。

我吸取的一个教训是要让相关的同事有”知情权”，避免黑箱操作。

选择与风险

团队负责人做最后的抉择，并且承担后续风险。如果经过一段时间，证实判断有问题，别硬着头皮往死胡同走，承认错误，尽快调整。

工具用不好或是不好用，团队效率可能会骤降许多，不得不重视。类似的惨痛教训还是不少的。

没错，我说的没有什么新奇的内容，都是常识。有时间我再改改。

–EOF–