`
zwchen
  • 浏览: 785038 次
  • 性别: Icon_minigender_1
  • 来自: 成都
社区版块
存档分类
最新评论

寻找技术合伙人的那些坑

阅读更多
对于非技术出身的创业者,往往有一种幻觉,比如:我们创业就差一个CTO了,再或者,就差一个程序员了。如果你是那个CTO或程序员,你会去吗?如果一开始就给你很丰厚的报酬呢?我的建议是:最好别去,因为不多久你就会出局。
创始人的不成熟,以及在团队的强势地位,会让一位优秀的技术合伙人也无所适从。

销售出身的创始人
这类人的几个典型特征:
业绩导向,工作成果和薪水挂钩,低底薪;
对技术认知度低,对工作量和技术难度缺乏判断能力;
对人缺乏信任,更相信博弈和制衡,而不是信任和合作;
做事没计划,一天一个点子;

和这类人合作,太考验情商了。
先说业绩导向吧,这个在技术领域基本上行不通。因为从技术到销售业绩有一个很长链条,中间有运营、营销、推广等环节。技术人员即使很有主人翁意识,也往往爱莫能助,搞不好还会被说成:多管闲事。
现在很多互联网项目,开始几年都不挣钱的(走渠道模式-积累用户的项目都是这样),更不好和业绩、营收挂钩。
技术人员的考核,我一般倾向于以按时按质按量完成分配的任务,而这个任务往往可能细化到一天或一周:随时沟通和跟进,而不需要一个明确的量化指标。
因为创始人是规则的制定者,技术人员只得去适应,技术人员的不满积累到一定程度就会撒手不管走人。

对技术认知度低,这个是普遍现象,我一开始举的那个例子:就差一个CTO,主要指这种人。
比如,电商的订单管理系统,如果按订单价格区间查询很容易,但如果按订单所属用户的等级查询,技术难度就陡增;再比如,在商品数20万以下时,商品展示和搜索很简单,但如果超过100万,这块得全部重写,原来只需2天的工作任务,可能变为2个月。
还有像秒杀活动这种促销,如果不考虑负载,技术难度和工作量只有考虑负载时的10%都不到。
不懂技术的老板,可能会这样和技术沟通,你看这个优惠券功能,电商网站都有了,你们怎么两周还没搞定?对技术人员的缺乏尊重和信任,是很多年轻创业者容易犯的致命错误。

你让老板无条件信任你?除非你当雷锋。
如果一味去满足老板的进度要求,加班加点,很可能欠下一推技术债务,过不了一年,系统就维护不动了,没有人敢对系统动刀,整个系统得全部重来。这时候,老板可能想换一批人了,开发2.0版。

对于那种一天一个点子的销售人员,与其说是快速的市场反应能力,不如说是对市场缺乏前瞻性。因为这种拍脑袋导致的需求变更,技术人员往往也是怨声载道。在IT行业,听说离职的几大原因之一,就是业务需求的反复变更。

我再来批驳下技术人员吧。

技术人员出身
可以按公司类型划分:
来自外企的;
来自大型民企的;
来自中小型民企的;
来自国企的;
还可以分,来自互联网技术公司的,来自传统行业IT部门的。

先说外企吧。
很多外企都说自己是设在中的研究院、研发中心。就像IBM几年前在成都双流机场打了几年的广告:智慧的地球,不过是一种营销手段。其实,他们也就是忽悠下那些毕业生。
外企在中国的开发中心,一般主要是三种:海外外包(客户是欧美日)、国内外包(做项目)、企业内包(比如IBM内部的OA系统,非公司核心产品)。
如果是海外外包,这种活一般是从详细设计开始做,也就是说架构设计和概要设计这种有技术含量的别人都做完了。
如果是碰上对日项目,就直接编码了,包括方法命名别人都写好了,纯粹沦为软件工厂-代码工人。当时,我见到一个日本项目,文件命名是201.jsp、202.jsp,我顿时石化了。
但你不得不佩服日本人在软件工程领域的造诣:能够将工作分解到大学毕业生就可以做,而且项目进度控制到10%以内,目前只有制造业可以做到啊。
而这些项目经理,每天主要工作职责就是更新Excel进度表,然后邮件提交到客户方。
你说,要是遇到这些顶着光环的技术人员或项目经理,你还能抵制住诱惑?而且对方还是名校出身哦,因为这些外企一般只去名校校招。

想想国内的软件项目外包,甲方告诉你,我要xx功能,你yy周给我做出来,要多少银子?双方价格勾兑好后,乙方开工,其间不过问,yy周后甲方验收,傻眼了吧?
软件本质上是对业务的一种抽象,如果甲方对业务都不梳理,乙方如何抽象(转化为软件模型),更不要说后面的技术实现了。
很多甲方(创业公司),就以为软件外包和做SPA一样,交钱后躺在那里,就可以爽歪歪了。如果这样,基本上失败概率在90%以上。

一般软件开发报价有两种模式:
按软件开发过程报价:需求文档+效果图+功能开发量
按功能需求报价:功能开发量*2
一般来说,前一种要稳妥些:通过分阶段交付来化解项目风险。
但问题是,没有看到可运行的程序,甲方一般把需求文档和效果图不当回事;
另外,有些乙方,将需求文档写得很抽象(找一个普适的需求文档模版抄),核心需求都散落在巨幅冗余文字中,甲方也很难判断文档中需求是自己想要的。

按功能需求报价=功能量*2,这也表明了,开发只占工作量的50%左右,另外50%是业务调研、需求分析、产品设计、测试等。

上面还说到一种:软件内包,以及外企的国内外包,而做好它,除了有优秀的技术人员,还需要优秀的技术管理人员:精通软件过程管理。
下面我多啰嗦点软件过程管理,因为它就是软件管理的孙子兵法。

CMM5(软件开发能力成熟度模型),以及和CMM3匹配的RUP软件过程管理方法论。这种业外人不好理解,你就当成制造业的SOP(标准操作流程)吧。
国内软件外包巨头,一般要花钱做这种认证,就像现在的农产品要搞个绿色食品认证,才能卖个好价钱。

先不说CMM5规范吧,它的规范文档大概可以打印成几本教材。RUP流程是IBM的一套软件开发SOP,也是恢弘巨制,反正我研究了3年还没有完全摸透。后来IBM在推Agile RUP,也就是剪裁过的RUP。问题是,有几个人有能力剪裁。
RUP我还是很喜欢的,对于某些传统行业的复杂业务,目前我没有看到更有效的方法学(不要和我谈SCRUM,这个不是用来管理需求的)。
软件工程的成熟度,比起建筑业差远了,每年估计提升不到3%。我从业10年来,没有感觉到开发一个模块以前10天现在5天。软件生产力的瓶颈,在于业务需求的非标准化。

还有一种人,说自己会敏捷过程,其实还是在用瀑布开发过程。
是不是用敏捷过程,看他发版时是不是追求完美主义:必须等这个功能开发完毕才能上线。很多人有这种类似情结:没有在线支付、没有退款功能、没有在线客服,怎么算一个电商系统呢?
敏捷讲究的是迭代开发,但这种人一看就懂,一做就忘。会站立晨会、纸贴todo,那不叫敏捷。
敏捷过程建立在信任、合作的基础上,否则晨会就成了批斗会。
还有,团队1个高级,2个中级,10个初级,就别强调敏捷了,那些新人会逼得吐血。

我谈了这么多的软件过程管理(注意:不是项目管理),其实就是想说,一直在用这种重型软件开发方法学的,或是专业软件公司那一套方法学,你让这种技术管理人员来到创业型公司就自废武功,放弃飞机加大炮,换成小米加步枪的作战方式,容易吗?
而且,项目开始时,你一看到那些高大上的文档,可能还会有这种错觉:我终于找到技术大牛了,虽然你基本上看不懂。

还有一点不能忽略的,就是大型软件公司出身的,以前面对的是一批既懂业务又懂技术的需求分析师,他们负责将客户需求收集整理回来。现在面对的各部门同事都是电脑盲,而且对业务基本上没有软件抽象能力,沟通会非常考验技术合伙人的智商和情商,如果缺乏同理心,技术人员会在心里抱怨:这群SB。久而久之,部门冷战一触即发。之所以我特别提出来,是因为技术大牛普遍情商都不高。
把技术牛人提升为技术管理者是创始人最容易犯的严重错误之一。

还有,对软件公司这种知识型员工,如果用传统行业普遍采用的泰勒管理方法(工业管理),如严格的考勤、请假制度,会严重挫伤技术人员的工作热情和创造性,要知道很多技术大牛就是夜猫子。如果创始人不了解技术型公司文化,很容易和技术合伙人产生沟通隔阂。

还有一种人,比较受创业公司欢迎,就是BAT出身的。
听说前两年,只要是BAT的,投资人就会追着问,我先给你300万,你出来创业吧。大家当个笑话就行了。
现在BAT的技术人员都是多少万了,随便一个产品线就是几百人,除了几个总监、高级经理、技术经理,大多数人都是螺丝钉,对某块可能确实钻得很深,但技术广度不够。
这些技术大牛习惯于技术实现思维(执行者),而不是解决方案思维(管理者)。如果不搞出点有技术含量的,或是用别人现成的云服务,那是一件多么没成就感的事情。

我前段时间看到一个猎聘上成都地区简历,里面一位25k的CTO,上个创业项目是社区O2O,其中有一个功能是小区交友,在谈到技术可行性时写道(原话):论证移动即时通讯、文字、图片、语音、视频方案;论证LVS在项目中的作用,确定服务器数量和成本。
要是我们Boss遇到这种技术负责人,估计要哭了。幸好别人只是论证了,而不是开发了。反正这些功能,我用10万就可以搞定(有对应的SAAS和IAAS云服务)。
我估计这就是BAT那种高端人才:做过大型高负载、高可用、海量用户的即时通讯解决方案。

小型作坊式的民企,我就不吐槽了。这类企业不乏技术大拿,但都是草莽英雄。如果还在大公司呆过,那就完美了:能屈能伸。
国企我就不谈了,技术人员受国企官僚影响应该不算严重。但有这种习惯:啥屁点需求都要把运营、市场、客服部门拉在一起,看起来是群策群力,实则推卸责任。
其实有一种破局方法:做了再说,错了再改;在关键需求上主动征求相关部门建议,注意是当面,不是邮件+CC。
大家知道,国企生存法则是,不求无功但求无过,说白了还是怕有人整你。

我上面说的似乎有些专业性,再谈几个比较通俗易懂的坑。
猎头推荐
猎头推荐,对于一些成熟企业可能是最好的选择。如果是给创业型企业推荐CTO,小心他会把你带到坑里。
猎头能够做的,就是推荐一批候选人,能否从中找到真正适合的那一位,前提是创业者对CTO的合理定位,然后才是匹配识别。就像知名企业的HR,能做的只是搜集简历,还得需要面试官来甄别。

如果一个创业者在早期,也让猎头找一位高大上的CTO,可能会让公司死的更快:成本超支,进度超期。
做三年后1000万用户的规划,但公司第一年10万用户、能否存活还是一个问题。
我暂时还不谈找到一位自认为适合的CTO后,所可能出现的问题:
产品开发期,CTO的技术视野和管理能力有限,从而没法在有限的资金、人力、时间下达成实现产品目标;
业务运营期,技术处于维持状态,因为前期对技术不合理的定位导致股权比例授予不当,一直寻思怎么让CTO出局;
很多创始人过了很久才想明白,自己公司原来不是技术驱动的;
同时,因为业务稳定,原来的技术团队成本过高,想开始对技术部动手,而缺乏团队支撑和技术挑战的CTO,职业发展就到尽头了。

技术合伙人的经济状况
技术做得好的,大多数都来自农村,家境贫寒。而且,因为自己的圈子和社会阶层,找的对象家境也不会好到哪里去。工作5年后一般到了买房的年龄,存款买房或月供都是实实在在的压力。
而创业者这种励志男,一般经济状况也好不到哪里。王健林做电商时是说过自己在创业吗?。创业者给的也就是一个空头支票-股权,这个套现的几率大概5%都不到,技术合伙人平时也就拿着1/3到1/2的薪水。如果项目半年一年都看不到希望,就要开始考验技术合伙人的人性了。
再说,别人挪个地方,可能薪水翻三倍,又稳定又有身份,马上可以解决现在的燃眉之急。另外,你怎么知道别人当职业经理人就一定不能获得股权或期权呢?
很多技术合伙人,在看不到项目前景或经济压力过大,都有过退却的打算。

所以,找技术合伙人,如果主要目标是拥有优秀技术资源,而不是降低成本,我建议钱给够,别让他分心。
如果资金充裕,而合伙人也乐意不要股份,就给高工资、当雇员好了。

把技术合伙人当产品经理用
从软件开发过程角度,业务调研、需求分析、原型设计,以及其交付件概要设计和原型文档,都是产品经理应该干的活。技术人员拿到这些交付件开始开发功能。而完成这些交付件,大概要占去项目工时30%以上。
应该有80%以上的技术合伙人不具备产品设计能力,这不是问题,问题是没有意识到自己的能力短板,导致想不到或不愿意去招一位产品经理。

我非常不建议CEO去找一位和技术合伙人平级的产品总监,沟通和协作会是一个大问题。另外,因为产品和技术很难合理分工,产品决策权之争会导致严重内耗。比如,UI设计师是属于产品部还是技术部?还有,大数据分析师呢?
如果创始人是产品出身,产品定义后,可以暂时不找技术合伙人,找个程序员干活就行了。

技术合伙人的能力瓶颈
并不是所有技术人员都能跟上公司的成长,在公司发展的不同阶段,对技术合伙人的能力要求不同。
在初创阶段,技术合伙人是个会写代码的就够了。随着用户的快速增长,对其软件架构设计能力开始有要求;
随着公司业务的壮大,对其技术前瞻性,以及中型技术团队管理能力有要求,这时候姑且称为技术总监吧;
当公司发展到需要一位真正的技术副总裁时,需要对行业格局有前瞻性,比如在什么时间点投入怎样的资源强化哪块技术,以及优秀的商业/技术平衡能力,可能原来的CTO/CIO角色也无法胜任;

当然,每个阶段,技术合伙人可以去物色比自己更优秀的技术人员,但管理工作还是无法找人替代的,难道指望他让贤?
在引入技术合伙人时,创始人就应该意识到可能会有这种问题,并制定双赢的技术退出机制。否则出现那种CTO走后,代码被删、数据库被销毁、服务器被格式化,那就悲剧了。

如果对技术合伙人能力没有把握,并且在退出机制上比较顾虑,找一个临时技术团队-提供技术孵化服务的公司,可能更靠谱。
在发布产品初版,并且引入资本后,你有足够的筹码吸引到优秀的技术合伙人。
当公司还是一个屌丝时,不要期望引来白富美;当你成长为参天大树时,凤凰自飞来。

转载请注明作者:
陈志武 http://weibo.com/zwchen
个人微信号:zhiwuchen




分享到:
评论
1 楼 Yano_nankai 2016-01-30  
特意注册了账号来回复楼主。

我是看到《如何阅读Java源码》这篇文章关注楼主的,进而发现楼主从06年到16年都在坚持写博客,阶段性回顾和年回顾。我花了大概4天时间,按照时间顺序,把楼主的文章看了60%。

我也是南开研究生,今年毕业。得知南开BT是楼主写的服务器,很激动~还看到您写的一篇关于中年危机的文章,那年(楼主40岁时)应该正好是百年校庆吧!

感谢楼主的分享,其中很多思考、处事、经历都很受益!

相关推荐

Global site tag (gtag.js) - Google Analytics