之前看过一个创业者写的文章，文章里主要是在吐槽找到合适的技术合伙人是如何的困难。这事情确实困难，一旦当事人失去对人或事的基本判断能力，随便什么事情都会变的比较困难。而随着互联网对传统行业的冲击，这类不懂技术的创业者应该也会越来越多，这样一来探讨下不懂技术的创业者如何解决技术问题就会比较有现实意义。

解决技术问题的人员模式

找能和自己配合的程序员有两种基本模式：

第一种模式就是大多数人总想用，但进展艰难的。很多人都想找一个或多个很牛的人来搞定自己的所有问题。这能找到合适的当然比较好，但出问题概率其实很高，可执行性并不好。这方法性价比更可能是非常差，而不是非常好。首先你不一定找得到，其次你找到了不一定负担的起，负担得起了又不一定合得来，合得来他还不一定做的很爽，因为这工作他做过，很大程度是在重复自己。总而言之，这条道路虽然看着美好，但只要用心一想，满眼全是坑。

这里容易出问题的原因在于，如果创业者失去了基本的判断能力，那彼此间就必须非常了解和信任，而不懂技术的创业者往往不在这个圈子里，找到这样合适的人其实挺难。

在陌生人之间培养信任这事历来很难，尤其这两个人背景又不一样。在陌生人之间确定利益分配就更难，多少是多呢？所以除非有种特别的缘故，发小、同学、多年同事等，否则这条路出奇的艰难，算是看上去很美，其实不太好用的方法。

但我们得承认虽然实现艰难但这个方法本身没什么限制，真能找到合适的人，确实什么都能搞定。关键就是你找不到合适的人。

第二种模式是找到基础好、潜力好（尤其是学习能力）与自己搭的人。当前他可能不完全满足需求，但他有很好的成长性，这样正好在事业的成长中实现自己的价值，同时报价也不会太高。简单来讲这和第一种模式的区别就是找成名前的张小龙还是找成名后的张小龙。成名后的张小龙只有一个，但其实具有张小龙潜质的人还是很多的。在我的感觉中，这类技术人员在大学里还是很多的，只要你用心去找。

这个方法对产品类型有点额外的要求，它更适合非技术密集型的产品。这和特定技术的学习曲线有关，如果你非要做个科大讯飞那类语音项目，那学习曲线就太陡了，即使个人成长性比较好，但这类产品技术人员必须要花很多的时间才能搞定，并且挫折太多，容易激发各种矛盾。

反过来如果是非技术密集型的创意，那么只要这个人是愿意学习的，那就可以基于现有开源产品迅速完成原型（36kr那种），接下来迅速开始迭代，在用户增长这类压力下，这个人也会迅速成长，这种成长本身也可以成为对个人的一种激励。

国外有个很有名的技术网站叫：http://highscalability.com/ ，上面列举了很多有名网站的技术架构，就我观察很多情形下是产品成就了技术人员的威名，而不是现有很牛的技术人员再去打造一个很牛的产品。这网站上的文章往往会很详细的记录某个产品的技术变化，记录这些变化实际上也等价于记录了当事人自己的成长过程。

这个模式之所以能成立，也和编程这项工作的技术特征有关，这里就说两点：

第一，编程这事入门起点不高，同时由于开源的发展，大多时候可参照的东西很多，能帮助人的社区也比较多。所以持续学习与成长性比经验重要。

第二，开发产品这事大多数人都能做，难的部分往往是渐进的。阿里双十一问题是不好解决，可也不是创业公司上来就有机会有那么大流量的。

这里的关键是要找到潜力好、能自我提升的，这样一来对程序员个人会有比较好的成长机会，做产品的同时他可能会成长为以一顶十的超级程序员；对于创业者而言，在技术人员的成长过程中也可以收获逐步改进的产品。

把握基本原则，避开显然的陷阱

如果能完全彼此相信，那所有技术决策都叫技术人员下就可以了，但如果还达不到那种程度，那创业者自己就需要把握一点基本的原则，来避开显然的陷阱，而这些陷阱往往纯技术人员是不会去识别的。这里所谓的避开陷阱主要是为了避免掉到大坑里彻底无法翻盘那类陷阱。

第一是在最开始阶段避免技术创新，尽可能随大流，用极为成熟的方案。原因很简单，在产品和个人的双重成长期不适合太折腾，要尽可能把变数控制在某一个方面上。而所谓随大流有两个具体要求：用有活跃社区的开源技术，用有类似的产品用过的技术。说到这里岔开一句找人的时候英语好是一个硬性条件，因为英文不好，可能就不愿意读英文资料，而以分享的深度来看现在英文世界仍然有非常明显的优势，比如highscalability，stackoverflow等。不读这类网站上的内容，眼界就窄，随大流可能都随不好。

第二是用开源技术。这又可以分两个层次，一个层次是选开源技术栈比如Linux， Apache，MySQL，PHP；一个是直接选开源项目的代码做开发基础。只要你的产品不是过于另类，在Github这种地方总是可以找到合适的项目作为代码基础，这与国内很多网站是基于WordPress的是一个道理。从开局的角度看，显然后一个更实惠些，前提是能找到合适的备选方案，比如Github上很多星星，又有很多人在维护的。

第三是要认识到到有钱后，要还技术债务。这时候要预测技术上可能出现的限制并及早进行解决。技术上的事情总是容易在开局时最重视，越往后重视程度越差。除非发生什么灾难性的事情，否则不懂技术的创业者容易认为都能用不就行了么，可这是不合适的。软件产品这东西，除了可见部分比如实现了某些功能之外，还有很大一块东西是没法直接看到的，比如代码的质量，架构的质量等，而匆忙推出的产品总是容易在这些不可见的地方欠下巨额债务。在产品发展过程中总是可以找到些时间来还之前欠的债，开发环境上的、结构上的、代码上的等等。这事属于重要不紧急的事情，如果不找空挡处理掉，很可能在未来成为瓶颈。

结束语

上面说的方法，是让人有个成本低廉、大致不差的开局，但并不是说可以一直这样；当你想做的事情越来越独特，这类方案一定会产生某种限制，这类限制也许暂时能对付，但是如果有长远眼光，则要在有钱后系统做点分析，看看能不能找到这种瓶颈，及早应对。江湖传说中京东是吃了点没有及早处理技术债务的亏的。

另外，对之前在《畅言》上发的文章其实我是比较自信的，事实上也没怎么看到过有力的批评，发癫的倒是有几个。可这次我是有点不自信的，很希望听到更多实践者的声音，来完善自己的认知。

原文：http://bbs.9ria.com/thread-406581-1-1.html