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

号外: 最近整理了之前编写的一系列内容做成了PDF,关注我的公众号"程序猿DD"来领取吧!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

alt