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

活跃分析

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

产品特性

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

主观评价

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

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

国外技术人员接受程度

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

国内技术人员接受程度

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

多方面沟通

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

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

选择与风险

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

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

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

–EOF–

最近问答类网站相当的热门。说起问答(Question & Answer)网站，很多人会第一反应想起 Quora ，实际上，这类网站中 Quora 并非做的最好的(但或许是借了 Facebook 的风头)，最为成功的要数 Stack Overflow 。更为准确的说，是 Stack Exchange Network，Stack Overflow 现在只是 Stack Exchange network 的子站点而已。

Stack Overflow 由 Jeff Atwood 和 Joel Spolsky 这两个非常著名的 Blogger 在 2008 年月创建，7月小范围的进行 Beta 测试，直到 9 月份才开始公开的 Beta 测试。Joel Spolsky 大家应该熟悉，国内已经引进了他的数本大作，影响力最大的应该是《软件随想录》，此外，Joel 还拥有 Fog Creek 这家运转得不错的软件公司；Jeff Atwood 是著名技术技术 Blog Coding Horror 的作者。有趣的是，这两个人过去还 打过嘴仗。Stack Overflow 面向编程人员群体，在其推出一年之后，又推出了面向系统管理员的 Server Fault ，2009 年8月正式面向一般计算机用户的 Super User。用这个方式不断进行横向扩展，到现在为止， 旗下已经有 43 个问答站点，甚至包括英语和烹调这样的主题。到2010年年末，Stack Overflow 单个站点在 Alexa 的 Rank 是 160 ，月度独立访客超过 1600 万，每月Page View 超过 7200 万 (refer)。Stack Exchange Network 在 2010 年 5 月接受了来自 Union Square Ventures 的 600 万美元的投资，在 2010 年扩大并完善了整个团队，从三个全职工程师发展到了 20 多人的队伍，搬进了 7500 平房英尺的豪华装修的办公室（当然每个人都坐着1000美元一把的椅子）。从各项指标来看，同样作为 Startup，Quora 距离 Stack Overflow 的还差得很远，虽然拿到了更多的钱、吸引了更多眼球。

Stack Overflow 为什么会如此成功？

你当然可以说是众包(Crowdsourcing)的功劳，但哪一个成功的社区能少了众包的功劳呢？如果实际一点说，不可或缺的因素我想是两个创始人的技术和社区基因。作为两个著名的 Blogger，没有人会质疑 Joel 和 Jeff 在 目标用户(开发人员)需求的精准把握。何况在上线前后，Jeff 通过技术社群又进行了大量的调研和反馈（Joel 倒是似乎第一次做 Web 项目，Fog Creek 主要是软件开发)。此前市场上已经有 Experts-Exchange 之类的老牌产品，Stack Overflow 则反其道而行之(Anti-Experts-Exchange)，作为技术人员，你一定遇到过搜索技术问题到了 Experts-Exchange 网站，但是你发现问题下面并没有合适的解答，仅仅有人提问，但是没有有效的激励回答者则是没有价值的。Stack Overflow 参考 Reddit 等网站的用户激励机制，关注问题质量，其做法是通过威望值(Reputation Point) 与徽章(Badge) 建立起信任评价体系，并且做到对参与者的有效激励。我是否说过技术人员都是”好面子”的？没有，那么现在记住这句话吧。

此外，秉承独特的设计理念。Stack Overflow 绝对没有多余的或是跟风的功能(比如一些不必要的 Social Network 特性)。如果看过 Joel 的书或是订阅他的 Blog，你应该知道他是个相当偏执的家伙，尤其是在产品设计方面，他认为对的事情绝不会妥协，参见他在《软件随想录》中的《别给用户太多选择》以及《用软件搭建社区》等章节。我不知道究竟团队在功能设计上是怎么分工的，但 Joel 一定是毫无质疑的植入自己的设计理念。另外要补充的是，Stack Overflow 重新将”标签”化腐朽为神奇，也是相当值得称道的。

横向的业务扩展模式。与 Quora 综合性的问答不同的是，Stack Exchange network 采取攻其一点，再进攻其余的方式。在面向开发人员的 Stack Overflow 获得验证并且成功之后，向类似话题领域扩展；然后与不同团队进行合作，逐渐引入更多的主题（比如 Ubuntu、面向物理学的话题等等）。最后，如果把几十个话题合起来，恰好是一个庞大的 — 论坛。Stack Overflow是否重新”改造”了论坛这个古老的交流模式？

技术？是个关键因素，但不是主要因素。作为 Startup，罕见的使用微软了技术体系进行开发，但也用开源软件。观察 Stack Overflow 所用的技术方案，会觉得是个大杂烩，除了 C# 、ASP.net 、SQL Server 等，也有 HAproxy、Redis 这些解决方案。 据 Joel 说，效率和成本也还不错。扩展模式上则首选 “Scale Up”, 总之，就是有点特别。但是，用户体验相当好，这个是最难模仿的一个地方(另一个是运营套路)。

或许，Stack Overflow 的成功因素不止这些，你认为呢？

补充，来自霍炬 (@virushuo) 的观点：首先工具本身非要重要。有足够好和专注的工具。其次，种子用户非常重要。So，小范围测试的时候奠定了基础，之后始终按照这个确定的方向积累。

补充， Joel 的说法是”push for high-quality content and its decision to segment the service into well defined verticals”。

延伸参考：

• Stack Overflow Architecture
• Stack Overflow 架构(评论)
• Stack Exchange’s Architecture in Bullet Points

–EOF–

看到微博上《程序员杂志》在征集”一分钟先生”的话题：如何做好公司/团队的技术选型？其实大公司或者大一点的团队选型几乎不需要太多讨论的 — 最后会不可避免的绕到技术官僚的话题上去。这里我想简单说说技术型创业团队技术上的选型问题。

拥抱开源技术

如果只能选择微软的技术路线，比如团队几个人只会用微软的技术做开发，甚至也不想学别的，那么似乎没有别的办法，将就一下吧。如果还有的选择，尽量选择使用开源技术。这样的好处是你不但可以有效的降低软硬件成本，还有更多的部署方案供选择，服务器上线甚至还能避免病毒的侵袭。开源技术的好处是出了问题，你总有办法可以找到答案，避免再次犯类似的错误。而用了微软的产品之后，可能平时不出问题，但一旦出了问题，你根本没什么办法，实际上，微软的产品使用门槛倒是低，但是复杂度可是一点都不小，而且随着发展，成本越来越高。国内有几个大中型网站，比如天涯、5173、大众点评、京东等，怕是深有感触吧，有的因为成本太高而继续被捆绑在贼船上，有的则破釜沉舟要摆脱这种束缚，但不管怎么说，总要付出一定的开销才可以掉头了。

好了，恭喜你选择了红色药丸，现在选择开源技术路线了，离开了微软的专卖店，进入到一个超级庞大的百货商店，这里还有数种分支供你选择呢，然后怎么办？选择大路货，选择可以掌控的技术产品，开源语言、开源程序、开源框架，乃至开源的解决方案。比如 PHP，比不上 Ruby 阳春白雪，但是用户基数大，你总能找到不错的工程师。PHP 虽然粗糙，但是管用。以 PHP 作为开发语言的成功产品不计其数，甚至很多东西根本不需要你再开发了，稍加定制即可使用。技术本身没有高下之分，差别在于使用技术的人。

Note：Paypal 和 X.com 合并之后，果断的将整个架构从微软的平台迁移到 Unix 平台；用微软技术体系构建的 MySpace 至今还在用微软的平台，被全面使用开源技术的 Facebook 短时间内全面超越。技术体系的选择是成功与否的唯一因素么？肯定不是。但至少是因素之一吧。

避免过度炫技

技术人员创业最容易犯的一个错误就是”炫技”。什么新用什么，使用最时髦的开发语言、部署的软件产品、调试最新版本的开发工具… 没错，用最新的东西容易给技术人员以满足感，但也很快会将你的时间资源消耗进去，除非你准备做的是一款基础产品。否则的话，你要花时间去学新的规范、熟悉新的功能、对付新出现的软件BUG… 可是这时候，最需要你做的是开发你要开发的产品，而不是捣鼓其它东西。一些新的技术或者方案，可以花一些时间分析一下但没必要立刻就用，确保将来有一天能真的使用上的时候，对一些重大的陷阱或是缺陷能够了然即可。

很多人神往 37Signals 的成功，但你一定要知道类似 37Signals 的团队，默默无闻的夭折掉的不知道有多少。每当我看到创业团队的就那么一两个人还整天在捣鼓 Go 、Erlang 这些东西，并想硬生生的用到他们的产品中去，我就知道，这样的团队要悬了。有这些精力，有这样的能力，应该想办法尽快让技术变现，研究一下怎么改进产品，怎么给用户带来更大的价值，这些不一定用最好的技术才能做出来。想办法尽快让产品发布，尽快接受更多人给你第一轮反馈，只凭创业团队几个人闭门冥想是很难出来好产品的，有的时候，产品推出的时机比完备的功能更为重要。要知道 GroupOn 最早也不过是搭建在 WordPress 上的几个页面，而阿里巴巴网站最初也不过是一个论坛，你又何必等到所有细节都打磨好呢？

拥抱开源技术，避免过度炫技，如果技术型团队创业(做互联网)，这两条都能坚持的话，我想你已经抓住了问题的 80% 的部分，基本上你不会做太多的无用功。

再说说如何找到合适的技术伙伴，刚刚启动的时候不要直接上来就找什么技术总监、技术经理、架构师这些看起来级别很高的人，因为这样级别的人未必认同你的想法和你的现在的团队，相反，我建议找能实现你产品想法的人。找一个合作者要比找一个管理者更为重要。最后有一点必须要说一下，不要因为一个人的技术喜好而舍弃整个技术团队，在任何时候这都是很愚蠢的事情。

这篇文章是比较有针对性写的，所以不具有普遍性，路过的朋友不要挑刺。

–EOF–

Updated：留言中有网友质疑”技术型团队”该怎么定义，按照他的说法，他心目中的技术型团队应该是”天才团队”，就这样。

曾经有不少人对我问过类似的问题：作为技术人员在创业团队(或是小公司)工作，技术上没什么挑战，觉得自己得不到锻炼，我该怎么办？

的确，就说互联网这个领域吧，创业团队或是小公司的网站规模往往并不大，或者至少要从小做起，用户访问量和那些大型网站在当下自然没法比，从这个角度上看，很多中小网站的确暂时面临不到这些高并发、大流量、高可用的这些”严峻挑战”，另外，团队的职能岗位甚至也没有大型公司那么齐全，人家连做配置管理的团队规模甚至都比你整个公司人多，似乎在小团队作技术的出门都低人家一头，见面不好意思打招呼，真的有必要妄自菲薄么？

首先要说明的是，在大一点的公司里面，最不缺的就是解决复杂技术上的资源，但是有意思的是，遇到技术”挑战”的其实是极少数的一部分工程师，大多数工程师做的都是相对可以规范起来的事情。或许有人不信，但是你要知道在团队有了一定规模以后，很多技术人就会形成路径依赖，一遇到稍微复杂一点的问题就去请教那些比较资深的同事，往往放弃了自己动手解决问题的机会，有些情况甚至他们也不敢承担风险，那么，你认为这种情况对他们会有多少挑战？

我们前面说到了复杂技术，以前关于网站架构设计、大规模集群、海量数据处理等主题，多少都还有一些神秘感，但是最近几年来，相关技术文章带来的信息越来越全面，越来越开放，不夸张的说，构建一般的大型网站的技术，你可以通过公开技术信息获得所有的细节内容。当然，有了这些，就好比你已经有了一份蓝图，具体的施工还是要自己控制。不要误会，我不是说创业团队的技术人不会遇到技术难题，如果真的遇到目前能力无法逾越的技术障碍怎么办？我的回答是：求助于社区，利用群体智慧。和那些封闭的大公司的技术团队所拥有的资源相比，这是更为辽阔的空间。注意，解决了问题不是最后一步，要把解决问题的能力逐渐培养起来。有若金庸小说中的北冥神功，要善于化为己用。

有些人把挑战等同于自己想做的事情，有些人把挑战看做一种憧憬，想象那些没有做过的事情，在我看来，真正的挑战恰恰是你不愿意做、不愿意改变、当前做不好的一些事情。

在创业团队你可以做的一些更有挑战的事情：

• 重构自己的代码 如果是开发人员，随时要记得的事情是如何改善自己的代码质量。要让自己成为更好的技术人，重构或许是是随手可作的并且切实可以提高自己能力的一件事情。有好的代码为基础，才有可能随时面对更大的系统压力。要记住小网站有可能发展为大网站，技术人需要的是提前做好准备，为你的代码，为你自己，为你的团队。
• 自动化日常工作 有人说，萝卜快了不洗泥，团队什么事情都要我做，我怎么有时间去搞什么重构？那么，是否可以将一些日常需要重复做的事情尽可能的自动化，比如日常发布是否可以自动化？测试工作是否可以自动化？安全检查是否可以自动化？有了这些为前提，你肯定有足够的时间去做你想要做的事情。
• 良好的开发习惯 在一个团队中，如果养成良好的开发习惯会让你节省时间和精力。比如对版本工具的掌握程度，如果连 SVN 都缺少使用意识的话，很难想象团队协作开发的时候会搞成什么样的局面。也不要抱怨团队的同事没有好习惯，他们或许正需要你的帮助呢…用你的行动，去带动他们。顺便问一下，你平时为代码写注释么？
• 改进自己的产品 复杂未必是最大的竞争力，细致和精致有的时候是更好的竞争力。很多技术人员做到最后发现自己做了很多对用户并不重要的功能和产品，而最重要的产品反而疏于改进。这未必都是别人的错，如果自己能够对产品和业务有足够的了理解的话，你或许会驱动团队少走弯路，做更正确的事情。
• 提高资源使用率 别人用数台机器支撑的访问量，换了你，能否用更少的硬件支撑？这些方案是可扩展的么？是可验证的么？遗憾的是，我看到多数小团队硬件利用率甚至比一些大团队更低。如果听任低效的代码、冗杂的产品功能不去改变，那么可能的确要面临资源利用率相对较低的窘境。
• 规划资源的能力 团队小的时候，整个产品架构、整个网站架构的信息收集并不难，让你建立起一个全局的观念相对更为容易一些。注意分析整体架构的演变，根据自己的理解，一步一步预期将来可能出现的问题。这是非常难得的锻炼自己的机会。顺便问一下，你给自己的网站画过架构示意图么？
• 保持学习的热情 我在前面说到了网络上的技术资源的丰富性，你是否能够持之以恒的去学习、吸收这些技术经验，是否养成了评估某项技术成熟度的能力? 什么，学了用不上？问题是再大的公司在技术上也是要有取舍的，更多的时候都是在用更为合适的技术而不是看起来更”先进”的技术。

这个清单肯定可以列得更长，至少还应该包括沟通技巧的改进、传授技能给他人、塑造技术影响力… 看似都是一些平淡无奇的事情，其实在大的团队大的公司，我觉得有挑战的也都是类似的事情，我也不确定哪一个对你来说更难做到。不过真的能把这些都做好的话，或许蓦然回首，那些所谓的挑战对你来说已经是浮云。

说到底，不能靠环境改变自己，如果你自己要改变自己对你收益是最大的（当然挑战也大），而要环境改变你会让你更为痛苦。只要你愿意。而且，在规模较小的团队中，你的改进会直接体现到团队的整体上，不要忘了，你是这个团队的一份子。团队越小，你的影响力就会越大，等到团队壮大起来，不就是你有更大职能的时候么？从经济学的角度上看，团队虽小，但是人均产出未必不如那些大团队的成员。正好比做手表的做到巅峰，不比造飞机的少赚多少。总有一天，很多技术人会以在小团队工作为荣。

挑战不在河对岸，就在你面前。

–EOF–