转载

如何正确地看待技术合伙人

“我有一个特别好的互联网创业想法，就缺少一个程序猿帮我实现了”。

这句话去年很火，相信不少搞技术的朋友也都现实经历过，知乎上也有关于这个话题的帖子。拿出来说还是因为最近又碰到这样的类似问题。当一个非技术创业者有一个不错的想法的时候，且不论想法到底是不是好，假设它是极好的，那么下来他真的只是缺少一个程序猿吗？

情况一：当你碰到了一个程序猿，你开启了画饼模式，“我想做的产品，XX牛叉……市场XX亿……A轮、B轮、C轮、上市……迎娶白富美……人生赢家，还等什么就差你的代码了！”。然而程序猿的内心可能是这样的：“哥，我是程序猿不是产品汪，你说的是啥？需求文档呢？原型呢？你到底是要做啥啊？能不能先给我迎娶白富美啊？”

原因分析：很多程序猿并不具备分析业务并转换成互联网产品的能力，尤其在大型机构或是外包团队中，由于细致分工之后，他们只是按照设计去实现具体代码的人，就像水电工按照设计师的水电线路图去布线而已。你的想法无法直接同他进行对接，所以你需要的程序猿要能同时干了产品。

情况二：假设该程序猿具备产品能力，业务的理解问题能妥善解决。到了开发阶段，程序猿童鞋又罢工了，“哥以前是做后端的啊，前端实在搞不定啊，技术栈太长啦，不知道用什么框架好啊，给我1个月时间学习一下如何？” “不行啊，投资人要见东西啊！”加班搞搞搞，终于完工，交给你一看。“这里改一下，那里不要了，这地方布局不太好嘛，应该不是很难，明天再过一下？” 程序猿，“……”。

原因分析：很多程序猿的技术栈并不丰富，一款产品涉及的前后端技术有太多内容需要去Cover。当技术面单一的工程师面对一个跨前后端技术栈的项目时，由于一些技术细节的不了解，对于进度预估和质量控制就很难做到，当然也是可以边学边卖的，我也经常这么干，但是对于不可控的部分不能占比太多，不然当多条技术线同时崩溃的时候，相信你的心情也是崩溃的。所以你需要的程序猿必须是全栈的，能cover所有技术线。

情况三：假设你找到了能做产品、又懂全栈技术的程序猿，完成了开发，产品上线了，随着用户的增加，获得了不少用户反馈，各种bug爆出，社区开始吐槽制作之烂，怎么不好用啊，设计好差啊。“你怎么做的东西啊，怎么问题这么做？”“没有时间做足够多的测试，有些情况没有想到……ToT……设计方面也没有专业的设计师，都是我YY的，可能不太符合用户的审美吧，你也懂我只爱二次元嘛^_^”。“好吧，那快把测试弄起来吧！”“我的睡眠时间已经赶上周总理啦，时间实在不够用啊……”。“那我们招个设计和测试吧”。“好啊，招两个妹纸吧~！”

原因分析：很多创始人一味的在意开发进度，但是忽略了设计与测试的重要性，忘记了产品是给用户用的，必须要以用户的角度去考虑功能该如何实现，同时对于产品健壮性对于用户的使用体验也是至关重要的。对于设计，我们需要考虑我们的对象是谁，他们是挑剔的还是可容忍的来决定设计的要求；对于健壮性，谁都不愿意在使用的时候产品出现崩溃，所以测试是必须的。

情况四：最新加入了设计美眉和测试姐姐，终于不是一个人干活了，好开森啊，开发更有动力啦！！！然而两周后问题又来了，设计如何介入开发流程？测试问题如何管理？开发版本与修复版本的并行问题？“哥，我要疯了，这些要怎么管理啊，怎么样才能让大家高效率的协作啊？”

原因分析：一款互联网产品在初期开发时候可能没那么复杂管理问题，主要在设计与开发之上，但是一旦上线后，运维压力、对于严重问题的及时修复同时要兼顾当前的迭代进度，技术管理不得不引入的团队协作中去。很多程序猿在工作中，往往处于既有公司流程中的螺丝钉，对于更全局的技术管理并不理解，这时候要做一个适用于当前团队的管理流程，既要配合得当，又要减少内容是非常有难度的。

所以，当你有一个不错的想法的时候，找一名程序猿是远远不够的，你更需要的是一位全面的技术合伙人，为你从零开始筹建整个技术团队，当人员不整的时候，他能cover不足的地方，当人员齐备的时候，他能将团队有机的协调起来。他还需具备强大的学习能力，随时准备应对新的技术变革。

对爱思考和想颠覆传统的朋友，我完全是支持的。但是在找技术合伙人的时候，要记住一点，真正热爱技术的人往往并不善于沟通，他们心里都有自己驻守的一块区域，也许是一个崇拜的人，也许是信任和尊重等等。老罗曾经说过他们的招聘经历，工程师们就是妖魔鬼怪，软硬不吃，加钱不来，不加钱更不来。

如果你有幸找到了一个不错的技术合伙人。请尊重技术人在为你服务时付出的劳动，其背后的付出内容往往是你想象不到的。也许你还没考虑要招聘一名架构的时候，他已经为你做了从0到100万用户的技术预案，但是你却不知道，只是因为你不懂。也许你还没打算扩展一些团队成员的时候，他已经为你准备好了从X个团队成员-XXX个团队成员的协作方案，但是你却不知道，只是因为你不懂。也许你正觉得技术团队怎么开销这么大还不产出价值，打算把他踢出局的时候，他顶着运维和开发压力，还谋划着利用如何利用新技术降低当前的技术成本，但是你却不知道，只是因为你不懂。

对于那些小有所成就开始质疑技术团队价值问题的创始人，这里不展开了，就说一句，请思考一下当初没有他们的劳动，你能忽悠到投资吗？

如何正确地看待技术合伙人