V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
eric614802
V2EX  ›  程序员

一个技术创业者的自白:三条关于 “选择” 的建议

  •  
  •   eric614802 · 2022-09-21 14:55:20 +08:00 · 1413 次点击
    这是一个创建于 823 天前的主题,其中的信息可能已经有所发展或是发生改变。

    本文作者 Wyze CTO 刘天强。内容源自「声网开发者创业讲堂第一期」的演讲分享。

    创业方向:兴趣 VS 趋势

    大家在创业的时候首先要选择的是 “做什么”?如何平衡个人特长、兴趣以及风口是创业者面临的难题。

    我在第一次创业的时候,做了一家主打图像识别 API 的公司 Orbeus ,这家公司做了 4 年,在拿到 A 轮融资之后被 Amazon 以当时不错的条款收购了。外界看起来,结果可以说非常圆满,但这并不代表我们的实力和眼光。原因是 12 年到 15 年这 3 年,正好赶上了深度学习这一波浪潮,虽然我们并没有想清楚商业化的方向,但仍然得以全身而退。然而,最初选择这个创业方向,却并非因为我们提前于时代洞见了风口,仅仅是因为我和我的合伙人在学生时代多年前就接触了这个领域,根据自身技能和特长做了一个简单的选择而已。

    所有人都希望有洞悉风口的能力,但现实中往往还是跟随内心居多。后来在机缘巧合下我选择了第二家公司,也就是 Wyze ,智能家居方向业界提了多年一直不温不火,算不上热点(甚至今天也不是)。我几年前做选择的逻辑也很简单,没有太多对市场业界的分析,主要还是感兴趣,专业也对口。最初的起点,是我在买家装材料的时候发现联网控制的设备比普通设备贵了好几倍,进而考虑是否这是个能做出来的机会。那时 Wyze 刚成立,还没有发布产品,但是商业逻辑切中我的痛点,于是我找到创始人,在近一年多的接触和考察后,决定正式加入。

    可以说我的每次“误打误撞”下都带着必然,都在做我个人感兴趣、比较擅长,同时比较符合发展趋势的产品。因此对于创业,我的看法是一定要找到同时契合自己兴趣特长,而且也有发展潜力的行业。只要不是太差的行业,是不是风口真的不那么重要。如果没办法两全其美,那可能现在还不是最好的创业时机,如果有条件可以再等等。如果想要赶热点,也可以先入行学习。从工程师的角度理解技术的出发点、长处,过程中可能会遇到挑战,然后再去突破创新。

    商业模式:B2B VS B2C

    我第一次创业是做 B to B 的,为企业提供图像识别的 API ;现在这家公司是做 B to C 的,面向大众卖智能家居设备。所以我对这两种不同模式都有比较深刻的认知。

    我是技术出身,刚创业的时候走的是典型的工程师或科学家的创业路径:我有独门绝技,看看能不能提供一些服务和产品帮助客户,顺便赚点钱。这种路径大概率是 B2B 的公司,也就是卖解决方案。这类公司本质上是从技术出发去找市场,所以技术合伙人在团队内的地位是绝对强势的。

    和绝大多数公司 CEO 在团队拥有最高话语权不同,技术导向的公司的 CEO ,作为业务合伙人,常常会忽略了一个问题:业务是否可行,从客观上面来讲 CEO 说了不算,CTO 说了算。如果这位 CEO 无法意识到微妙的区别而调整预期的话,一定会为将来的冲突埋下伏笔。一个简单的例子:业务场景技术无法实现怎么办?因此,相比强推自己的路线政策,这位 CEO 必须学会倾听和获取信任。

    如果你自己是一个公司的技术合伙人,一定要找性格互补的业务合伙人,做事的态度比经验重要,如上所述,能不能把你的想法给听进去是最重要的。业务合伙人冲在和客户对接的第一线,技术合伙人平时都在做技术研发,对于客户需要什么,业务合伙人肯定比技术要清楚得多。所以相对的,你要求人家倾听,你自己就不能刚愎自用,毕竟技术再强也不代表能成功落地。但是,当你选定了业务合伙人,一定要给他足够的空间,全心全意信任他,涉及到客户和业务,多想,多理解,这对你本身也是个学习的过程。

    从 B to B 到 B to C 的心路历程

    B to C 的出发点跟 B to B 的思路不一样。B2B 是从技术找市场,B2C 是颠倒过来,要从市场和产品来决定技术。事实证明,B to C 技术合伙人的视角跟 B to B 是完全不同。最大的一点在于技术从主导公司发展的方向下来,把位置让给了产品。最近十年大家经常谈到 growth hacking 也就是增长黑客,就是 ToC 的公司要增长,产品必须自带一些病毒扩散的属性。这些属性往往技术实现可能都不是很复杂,但这些功能在公司的成功中扮演了举足轻重的作用。很多技术出身的同学不屑做这些简单的事,这是十分不可取的,毕竟再简单的事,量大了,几百万,几千万用户来用,都会变成一个很有挑战的事情,更何况许多简单的事本来也是基本功。ToC 公司本身涉及到的内容和技术栈要比 ToB 技术型公司复杂,如果量做大了,绕不开做高并发,但就某项单一技术而言,往往并不深入。

    综合以上,如果大家喜欢自己主导事情,最求深度,那就去做 B to B 的生意,一定要找志同道合的合伙人。如果大家喜欢扩展自己的视野,追求广度,就去做 ToC 的方向。

    创业态度:工匠精神 vs MVP

    技术同学肯定经常面临产品上线压力,几乎每次都觉得在赶鸭子上架,有时候为了赶上线的时间,做出产品的质量之低恐怕都过不了自己的灵魂拷问。如何在妥协和坚持中找到一个合理的度呢?

    MVP 性质产品,需要强调后台服务可扩展性吗

    我在 Wyze 的时候也犯过和所有硬件公司一样的错误,我们在设备数目高速增长的基础上,也在尽一切可能性扩大软件收入和利润。2020 年,团队决定做一款极致性价比的安防系统,投入了大量的资源,花了半年的时间做了至少能支持百万用户的系统。上线后第一年也只有 2 万的用户。

    这是一个严重的错误,产品和技术团队各背 50 大板:产品团队花了半年时间定义出一个并没有简化到极致的 MVP 。技术团队又花了大量的时间和资源过度施工( overengineering ),做完了一个不算简单的第一版 ,最终证明在开始时大家对增长曲线的预期是错误的。

    我们从中得到的教训是:当产品本身定位就是 MVP 的时候,千万要谨慎的管理资源。如果 MVP 都没人用,就算在上面欠再多的技术债,也没有解决的必要,反之,即使是个满是 bug 的 MVP ,只要用的人够多,我们也终将获得修复 bug 的预算。

    有已知缺陷的产品,最好的上线策略是什么?

    举一个我经历过的例子:近年来我们公司推出了不少摄像头产品,其中有一款方案交给了方案商去做时,方案商当时定的内存分区存在问题。最后由于视频数据留的分区过大,但是程序 runtime 运行的 memory 留的分区过少,造成了因为内存不够,新的功能加不上去。

    我们复盘总结出来的结论是:当产品有已知缺陷时,需要区分是什么性质的技术债。技术债分单向门和双向门,不是说不能欠,但当你遇到可能的单向门技术债时,你就要小心了。我的建议是,对于产品发出去就很难改的严重问题,如果一旦发现,不要怂,技术部门不惜一切代价都要阻止产品上线。比如刚才的例子,系统内存分配就是典型的单向门类技术债,设备发到用户手上,改业务逻辑可以做 OTA ,但修改系统分区将变得异常困难。

    资源压力大,如何说服产品和业务匀出资源解决技术债

    在创业公司资源通常会比较紧张,但是业务负责人通常不理解技术的复杂性。虽然大家都知道技术债不好,但因为没办法量化,所以产品功能和技术债之间经常纠结。技术债的修复经常被降低优先级导致降低系统稳定性,增加研发的难度,可能带来更多的 bug 甚至产品的体验降低、用户口碑下滑等等。这个情况下如何说服产品和业务呢?根本的办法,就是量化技术债,而且尽可能映射到财务上,帮助团队其他成员从投资回报比上理解技术债的实际代价,但这并不容易。

    我自己的做法是,先对不同研发团队的规范和开发流程进行统一,在此基础上尽可能的做量化。如果你能量化工作量,就能够量化工程人员开销,进而根据项目超过预期的时间来量化多花的工程成本,这部分就是对技术债需要赔付的溢价。

    我在中国和美国大概管理有十多个研发团队,每个月我会把所有研发经理聚到一起开一次例会。除了我和大家更新公司目前正在发生的大事甚至一些财务数据之外,会以抽签的形式由两个到三个研发经理汇报他们团队的工作,并且展示自己团队的运营和项目管理数据。这个会上,所有团队及项目负责人都在, 这个流程开始执行的时候确实有各种不规范的现象,但几个月下来,因为大家之间有同伴压力( peer pressure ),并且都能够在现场看到各类不规范的问题被强调和纠正,几个月以后,所有团队在项目管理的流程上就趋于一致了。

    此外,我还做了一件事:在团队中安插熟练掌握敏捷开发流程的项目经理。一方面是督促项目的进度,协调团队的合作,另一方面也会监督并且完善各个团队执行的流程,并且把情况反馈到我这里。这样双管齐下,我们整个团队的流程就逐渐趋向统一了。

    但统一流程是不够的,只是确保了工程量化数据的准确性。在时机差不多的时候,我开始用系统记录各个项目的计划时间和实际的延误,我发现所有的项目都比预期的时间高出 30%,实际原因可能很复杂,但即使不细致展开,也能知道整个技术债对开发资源影响差不多是 30% 左右的研发成本,进而大致能够算出技术债所对应的金额,从而说服整个公司投入资源来解决技术债。

    作为创业公司的技术负责人,资源永远不够,所以如何能够保护好你的工程师,也是一个十分重要的问题。我的办法是将需求变成队列,并且定义好工程团队被允许接收任务的最低门槛。具体一些,产品团队约定必须所有任务都得进队列,并且要有具体的 ROI 计算和 UI 设计稿。只有这些条件都达成了,开发团队才能接单。每个周期接单的逻辑都有限,先到先得。如果你来晚了想插队,是不可以的。需要和排在前面别的产品经理商量。这也会倒逼产品经理更加谨慎地做出产品的决定。

    最后,我想用古希腊哲学家的话作为结束,对于不可控的事情,我们要保持乐观和自信。对于可控的事情,我们要保持谨慎和节制,焦虑和恐惧都于事无补。

    活动预告

    9 月 24 日下午,声网开发者创业讲堂 • 第 5 期将以「技术创业者如何做好技术团队管理?」为题,邀请 翟佳、杨帆、史海峰 三位资深的技术专家为大家带来精彩的分享,欢迎感兴趣的伙伴报名~

    活动报名

    微信扫描下方二维码或点击链接即可报名: https://www.huodongxing.com/event/7665949006823

    声网创业讲堂交流群

    当下是一个人人可创业的时代,对技术人来说,更是一个创业友好的时代。如果你懂技术,会比其他人更容易将自己的创业想法和梦想付诸实践。但创业意味着要从 0 到 1 ,意味着要持续的创造和创新,意味着创业者和团队需要不断的成长和突破。只有这样才能打造出满足市场需求的、有价值的产品,逐渐形成企业的优势和壁垒,成长为一家成熟的企业。

    声网关注有创新能力、开发能力和创业意向的开发者,并希望为开发者提供相应的支持和服务。为此,我们推出了“声网开发者创业讲堂”系列创业分享,以便为大家在成长和创业路上提供更多的帮助。欢迎扫码申请加入我们的创业开发者社群!

    2 条回复    2022-09-23 10:32:27 +08:00
    azhi
        1
    azhi  
       2022-09-23 10:32:04 +08:00
    仔细看下来,大佬说的挺好
    azhi
        2
    azhi  
       2022-09-23 10:32:27 +08:00
    北京招人吗[呲牙]
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   837 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 21:08 · PVG 05:08 · LAX 13:08 · JFK 16:08
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.