抱歉用了这条鸡汤风格的标题。
什么叫强悍的小团队?我带领的蝉小队在过去 4 年里,一共做了 7 个 APP(其中 2 个的难度中上),以及 5 个难度中等的网站,研发组长期保持 1 后端 / 1 iOS +前端 / 1 Android 的配置,也就是 3 位程序员。
根据我对同行的观察,同样的业务,正常情况下会用到 8-10 位程序员,然而这 3 倍的效率提升并不是靠加班换来的。如果不赶市场档期,我们从不安排加班,并且厌恶常态的加班。
本文会告诉你,怎样的组队方案才能实现超高的研发效率。
「老板」
令人遗憾的是,实现超高的研发效率,关键并不在程序员身上,而是在老板和产品经理身上。
先从老板说起。
首先,老板要制定正确的阶段性目标,不要搞大跃进,也不要异想天开。如果阶段目标弄错了,整个团队必然疲于奔命。随便举个例子,每个老板内心深处都有一个社区梦,管他妈什么产品形态,最后都会跑去做社区,花偌大的力气在盐碱地上开垦。
其次,老板一定不要插手细节。
我跟你们讲一个真理:“我知道我的广告费有一半浪费了,但遗憾的是,我不知道是哪一半被浪费了。”哦不对,应该是这句:“任何产品都有一半的需求对成败毫无影响,但遗憾的是,每个人都坚信自己提出的需求奠定了成功的基础。”
这句话翻译成大白话,就是“对产品设计有决策权的人越少越好。”因为过度设计是不可避免的,可抠的细节又是无穷无尽的,有话语权的人越多,则过度设计越发严重,最应该闭嘴的人就是话语权最大的老板。要知道,抠细节与产品成败没有一毛钱关系,而加功能——尤其是“比着竞品加功能”这么简单的事,如果老板和产品经理的意见相左, 99%的情况下是产品经理正确,连这个都判断不准还做个屁的 PM 。
精简需求,做好产品的减法,从老板学会闭嘴开始。
「产品经理」
继续上面的话题,产品经理越少越好。最好是两位,一主一次,既有得讨论,也能控制住过度设计带来的浪费。
很多团队是这样的,先招一个 PM 顶住,发现不够强,再招一个,还是不够强,再招一个……为了弥补缺口,制造更大的缺口。我们都知道产品经理扎堆会带来多么可怕的后果。
然而招到或培养一个“相当靠谱的产品经理”,目前还是小概率事件。
好的产品经理能够为提升研发效率做三件事情。
第一是头脑清晰,控制过度设计,至少一半以上的需求对“验证成败”这个终极目的是有帮助的。同时能复用就复用,能精简就精简,擅长从研发成本的角度出发去考虑需求,而不是因为“这个功能牛逼”“这个交互创新”,不会为了刷存在感而去做一些花哨的事情。
第二是划分清楚优先级,需求都重要,都重要就是都不重要咯。谁最重要,最优先,最紧急?第一个验证性的版本最小包含哪些需求?如果验证结果不够满意,再修改哪些需求可以快速验证第二轮?把优先级厘清楚,才能真正实现敏捷开发,否则就是瞎鸡巴折腾。
第三是有预见性,提出一个功能,构建一个页面的时候,预见到它在未来可能的几种进化。虽然这特别难,但能够有效减少代码上的推翻重来,算是老司机专用的橙卡。
显而易见,能做到以上三点的产品经理,年薪最低 60 万起谈,期权另计,有价无市。考虑到他为公司节约的研发成本, 60 万都是白菜价。
「后端程序员」
有一条微博评论质疑我:“你们只有一个后端?他得有多辛苦啊。”
哦……我的前技术合伙人 Quake 几乎从来不加班。
“但是 Quake 是大神啊!”
后来 Quake 心生退意,另一位只有 1 年经验的 Ruby 程序员农药接班, 92 年生。他一个人完整地扛下来了氢气球旅行的后端研发。前 3 个月摸熟业务,他倒是加了不少班,也积压了一些需求,但按照我的预估, 1.5 个农药就足以在不加班的状况下实现全部需求。
不要小看好程序员的潜能。
「客户端程序员」
最近招聘客户端程序员,我接触的所有人,之前都是 2-4 人研发 iOS 和 Android 的一端,而他们做的产品复杂度远不及蝉游记和氢气球旅行。
我来介绍一下蝉小队的两位客户端程序员。 iOS 端由凌晔,我后来的技术合伙人一人负责,他在 2013 年从资深前端零基础转 iOS ,一年后已经是一流的 iOS 程序员。
Android 端的程序员是毛毛, 93 年生,加入蝉小队时只有 1 年研发经验。加入两年后,他独自搞定氢气球旅行的效率和效果,几乎已经追上了老司机凌晔。
我们曾经短暂尝试过两位程序员同时做一端,的确会加快速度,但并没有到加快一倍这么多,即便只增加一个人,也会多出来若干沟通和流程成本。如果老板的阶段性目标和产品经理的需求优先级排得好,其实一位程序员也可以 hold 住——所以当有程序员离开时,并没有补位,而且真的一个人就 hold 住了。
当然,从项目安全性的角度出发,还是应该配置两位程序员同时做一端。但在产品尚未验证的早期,如果对项目管理能力有自信,一端一位程序员能够更敏捷地应对变化,同时也由于研发资源的减少,逼着产品经理更准确地划分优先级,进一步减少过度设计带来的浪费。
「 UI 设计师」
UI 设计的好坏和人多人少一毛钱关系都没有。
我们在 UI 设计上遇到了和客户端程序员同样的情况。一开始配置两位设计师,一主一次,当主设计师离开时,没能招到合适的替补,我犹豫了很久,问 2014 年毕业的应届生小宇,要不你来试一下主设计师?
随后的两年里,我们只有小宇这一位设计师,做了 5 个 APP4 个网站的设计。
而且她几乎没怎么加过班。
所以我这一次面试 UI 设计师,听说大部分人分配在 3-5 人的设计组,公司又只做一款产品时,我很惊讶,你们平时在干什么呢?
UI 设计是特别主观的事情,不会因为扎堆而提升质量。不过公司业务成长起来的时候,还是建议配置两位 UI 设计师,一位偏 UI 一位偏视觉,否则就太孤单了。毕竟产品经理可以跟产品经理聊产品,程序员可以跟程序员聊技术,设计师找谁聊设计呢?未免寂寞空虚冷。
「运营」
运营和其他岗位不同,无法自恃才华而做到以一抵三。优秀运营人员可以大幅度提升质量,但很难提升哪怕是一倍的效率。
即便如此,“堆运营”在项目早期还是个坏主意。刚才提到过,如果还停留在验证产品思路的阶段,人越少则越是敏捷应对变化。人员数量上来后,动作不可避免地变慢,这是其一。
早期运营要做的事情是“搭框架”,由少数精锐的人搭好运营框架,制定任务模板,根据不同的业务性质,框架也千变万化。直到产品思路和运营框架都得到验证,再往框架里边填人,所以只需要两三个核心运营来定方向,人多嘴杂反而内耗,这是其二。
「怎样鉴定强悍的小团队」
写到这里,也就解释了那句令人沮丧的话,提升研发效率与产品节奏,关键人物是老板与产品经理。如果在他们那里出了岔子,需求又多又乱,成天改来改去,其他人再强也只是擦屁股。
两年前我想总结蝉小队做产品的经验在业内推广,很快放弃了,因为身兼老板和产品经理的我是不可复制的。何况我还兼交互设计师和 QA ,为了追求极致的效率,测试的苦活累活我自己扛下来,一扛就是 4 年,没办法这样去要求别人。
在携程的时候,有次梁建章问我,怎样提高产品研发效率?
答:舍得砍需求。
与会人员纷纷点头称是,我却叹了口气,心想谁来砍需求呢?谁有这个权力和见地来砍需求呢?我当时是携程周末 SBU 的 CEO ,我是老板,也是主要的产品经理+交互设计+QA ,我知道怎样砍需求,其他人呢?
所以,鉴定强悍的小团队,首先要去了解它的老板,它的产品经理。其次要看团队里有没有技术大牛——即便有新人成长的环境,也需要大牛带路才能事半功倍,完全靠新人摸爬滚打还是不行的。如果没有 Quake 和凌晔一前一后两位技术合伙人,蝉小队必然做不到如此效率,而 UI 与运营的成长,也有我的指导功劳。
「为什么考虑加入小团队」
今年互联网转冷,资本寒冬到来,大量的创业团队倒闭,创业潮就此退却。即便如此,活下来的创业团队还在招聘,你有什么理由选择高风险的小团队呢?
答案当然不是“劈情怀”。
加入小团队主要的理由是“刷经验值”。
我刚才举蝉小队的例子,就是用实例来证明,如果它真的是一个强悍的小团队,即便是 1 年经验的程序员,应届设计师,新人运营(莱拉,从新人到我的运营合伙人),也能在一两年里,成长到极为惊人的地步。
我这次招聘程序员,遇到过很多四五年经验的人,并没有研发过比较复杂的产品,挑战过比较困难的功能,甚至因为程序员扎堆,自己未曾涉及技术架构,只是实现某些功能。坦率地说,这样的四五年技术积累,未必能和蝉小队工作一年的 92 后程序员相比。并非个人缺乏天赋与热情,但成长环境的 buff 的确差异极大。
就像你在武当派与崆峒派练功的区别。
因为只会劈情怀的小团队大量存在,现在一提到“小团队成长快”,立刻联想到低薪,联想到疯狂加班,联想到反复改需求经常变方向。但这些坏事情和成长快没有一毛钱关系,刷经验值不是因为你满地图打小怪,而是下副本打精英怪。
我把适合加入创业小团队的人,比如程序员,分成四类。
level 1 是没经验的非名校应届生,除了同样是 level 1-2 的创业小团队,没地方肯收留。
levle 2 是有一些经验的熟练程序员,还不能独当一面,加入 level 2-3 的小团队刷一两年经验值,快速刷到高级程序员,也就是 level 3 ,然后再换和 level 3 对等的工作。
level 3 是独当一面的高级程序员,加入 level 3-4 小团队的理由,多半是更深入地理解和影响一款产品,同时也为未来自己的创业打好基础。
level 4 是资深程序员,正常身价的年薪最低 60 万起谈。他们如果愿意加入小团队,就是单纯地喜欢创业的感觉,喜欢打磨自己的作品,喜欢自己制定规则而不是遵守别人的规则。比如这一次,我的两位技术合伙人已经拿到了 BAT 与华为的优厚的 offer ,但在接到我的正式邀请时,当天同意和我拍档,一点也不犹豫。
这也能解释很多人问我的问题:“既然蝉小队的程序员这么好,为什么你做短视频,他们没有继续与你同行?”回答是经验值已经刷满了,不妨换一个新鲜的环境,也换一个自己更喜欢的产品,毕竟并不是人人都爱短视频。所以他们更愿意作为技术顾问和兼职程序员来帮助我,而不是全职加入。
「我们需要怎样的程序员」
最后,我终于露出了狐狸尾巴。本文其实是一张招聘贴。
在请到了两位技术大牛合伙人之后,我的 UGC 短视频创业项目还在招聘客户端程序员,分别是 1 iOS 与 1 Android ,两端各自由一人 hold 住。
我曾经带领过业内最高效率的小团队之一,再加上曾以一己之力扛下来“ 2 万-2000 万激活量”全部后端工作的后端合伙人,以及“跨平台游戏引擎核心程序员,谙熟客户端底层技术”的客户端合伙人。由这个核心团队背书,你有没有想加入我们,刷满经验值呢?
必须提前声明的是,程序员薪资范围是 20-35K 。不算高薪,但也绝不低价劈情怀。我依然厌恶和排斥常态加班,虽然因为追赶市场档期或早期经验不足,早期加班难以避免。
因为我的招聘已经进行一个多月了,你肯定会想,标准是不是很高所以招不到人?
标准未必很高,刚才提到的 level 2 和 level 3 都满足要求。
这周联系猎头帮我找人, HR 请我给一些具体标准,不能泛泛而谈。我想了想,标准有三条:
第一,聪明。做产品这么多年,我身边的好程序员都是聪明人,聪明外露,绝对不是刻板印象里的技术呆子。虽然说聪明人未必是好程序员,但肉眼可见不够聪明的人,成为好程序员的概率更低。
HR 说这不行,聪明怎么判断?猎头可没法帮你找人。
我说,可以通过简历来简单判断。聪明人的简历绝对不是流水账,能够简明扼要,准确有力地说明自己的经验和技术优势,方便招聘方快速发现重点,萌生好感,甚至有漂亮的格式来自证审美。
第二,对技术的兴趣。 @Easy 说过一句话我很赞同,很多人只是喜欢做程序员,并不是喜欢写程序。如果缺乏发自内心的爱好,仅仅靠对工作的责任感,就很难和小团队同步高速成长。
然而在我之前的招聘中,几乎每个人都说,我对技术兴趣很大,热情很高。这件事怎么证明呢?包括有说服力的技术博客, Github 地址,尤其是主动学习与工作无关的语言,研究与工作无关的技术概念,小有成果而不是浅尝辄止。你说自己很有热情,却并没有为爱好付出多余的时间精力,学习技术停留在工作 8 小时内,这怎么能算是有热情呢?
第三,技术经验和我们的要求基本匹配。 2 年以上原生客户端编程经验,尤其对客户端的技术架构有经验——毕竟是“一人一端”,只懂得开发功能模块就太勉强了。我们希望他在小有名气的公司,比较成熟的产品工作过,因为完全无名无影响力的产品和团队,很难带给程序员足够的技术积累,成长离不开环境 buff 。
符合以上三点条件,都可以给我们来信。甚至是之前因为缺乏视频编辑经验(现在取消了这一条),或者因为别的什么原因,被我们回绝过的应聘者,也可以再次来信。我最近反省自己,认为之前一部分的回绝有偏差,应该更重视技术热情与成长性,而不是已有成熟的经验。毕竟产品从零开始,万物生长,强求 level 3 的高级程序员得撞运气,聪明又热情的年轻人与项目共同成长也是不错的选择。
「写在最后」
我知道,我知道创业风险很大。
我也知道现在是 12 月底,临近年终奖,是跳槽最困难的时刻。
但实诚地讲,从刷爆经验值的角度出发,目前可能很难找到比我们更好的小团队,而项目早期只需要唯一的 1 位 iOS 和 1 位 Android 程序员,下一次招聘可能在半年以后。你想想,在技术大牛的指导下从零搭建一款中等复杂度的应用,以及经常听我这个知名产品经理讲解产品设计与“产品玄学”,这并不是常有的职场机遇。
至于这款短视频产品本身,我不会向你夸耀产品前景,倾诉产品理想。但你再想想,合伙人阵容堪称豪华(他们都愿意信任我),在资本寒冬轻松谈下来一笔大天使(谈过的 6 家 VC 都愿意投),至少说明这不是一次裘千丈水上漂的冒险。
对于内容市场来说,短视频是未来,而短视频产品还处在早期市场阶段。如果有机会在面试中相见,我再来向你讲解这个有趣的产品计划。
废话不多的招聘贴原文: https://www.v2ex.com/t/323581
工作地点:上海-黄浦区-新装修独栋小楼
早期团队:全职 8 人(程序员 4 人)
技术标配: 27 寸 5K 屏 SSD iMac
联系邮箱: firecicada@gmail.com
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.