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

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

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

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

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

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

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

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

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

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

–EOF–

Paypal，最初并非是针对 Web 用户提供支付解决方案的公司，最初的产品是面向手持设备(Palm Pilot)提供支付解决方案以及安全加密技术的，甚至最初的一笔投资也是通过 Palm 来进行演示如何进行转账的。后来，Paypal 认识到了来自 Web 用户的需求，在恰当的时机调整了产品方向，否则或许不会有现在的 Paypal。如果你是 Paypal 最初的创业者（Max Levchin，Peter Thiel 或是 Ken Howery ），你有可能做出这样的选择么？

Flickr，最早是 Ludicorp 公司为 Game NeverEnding 游戏研发的附属产品，甚至最初是以多人聊天室的形式呈现的，而 Flickr 发布后大受用户欢迎后反而让 Ludicorp 最终放弃了研发三年多的 Game Never Ending。如果你是 Flickr 最初的创业者(Stewart Butterfield 与 Caterina Fake)，你有可能做出这样的选择么？

豆瓣，创意来自阿北最初打算创立一个”驴踪”的网站，做一个”互相推荐非主流旅游点的网站”，不过阿北后来发现文化类的产品更适合这样互相推荐的形式，所以，才有了现在大家看到的豆瓣。如果你是当时的阿北，你会继续做”驴踪”，面向旅游这个遍地是钱的大市场，还是选择放弃最初的想法而做豆瓣这个面向小众的市场？

迅雷的创始团队最初的想法是做一个分布式电子邮件系统，利用互联网分布性空间来存储邮件。后来，偶然意识到这套系统的原理完全可以应用在下载上面，后面的故事我们都知道了。如果是你，是去继续找识货的买家继续做分布式电子邮件，还是做下载，和已经占据市场份额 80% 的领跑者(领跑者还不赚钱)竞争？

最近热火朝天的 Instagram，最初创建人 Kevin Systrom 要做一款基于位置的服务相关的应用，但是应用程序开发一定阶段后，发觉功能太多反而失去重点，砍去了大量功能后才变成了现在的 Instagram ，结果是取得了空前的赞誉。如果你是当时的 Kevin Systrom，你会舍得砍去那么多功能么？会不会随着今后的发展而继续把这些功能再加上来？

类似的案例还有很多，我不确定这些例子有多少演绎的成分，不过这些案例能否给我们一点启示呢？很多人都诟病我们的互联网环境缺乏创新，因为大家上来都直接跟进那些成功者的模式，但缺少了一步人家做取舍的过程。或许，没有这一步取与舍的抉择，就会缺乏创新的动力，因为少走几步路实在是太有诱惑力了。

另外一个方面，不少人开始都是靠着一个点子而杀到创业者这个行列中，有一个好点子、好的创意，或是看到一个好的商机，夜不能寐，激动不已，感觉冥冥之中有一种力量驱动你要去做这件事情… 坚持，的确是一种力量，是一种美德，但毫无疑问，不能守着一个点子一条道跑到黑，必须要随时随地根据用户的需求与环境来做取舍，在合适的时候或许要放弃你原来的很多努力。否则就是缘木求鱼。

–EOF–

顺便说一下：如果你看了这篇文章，回顾一下自己的产品，也要动心思做点取舍，我劝你还要慎重。抵制忽悠的诱惑也是创业者应该持有的美德，关键是你是否真的想明白了我要说的是什么意思。