本文作者为怀泽CTO刘天强。内容来自《声网开发者创业讲座第一期》的演讲分享。创业方向：兴趣VS趋势创业时，首先要选择的是“做什么”？如何平衡个人的优势、兴趣和出路，是摆在创业者面前的一道难题。刚开始创业的时候，我建立了Orbeus，一家专注于图像识别API的公司。这家公司已经经营了4年，在获得A轮融资后被亚马逊以优惠条件收购。从表面上看，结果可以说是非常令人满意的，但这并不代表我们的实力和愿景。原因是2012年到2015年这三年，我们正好赶上了深度学习的浪潮。虽然我们没有想清楚商业化的方向，但我们还是可以打退堂鼓的。不过，当初选择这个创业方向并不是因为我们看到了超前时代的趋势，而是因为我和我的伙伴多年前在学生时代就接触过这个领域，并根据自己的想法做出了简单的选择。自己的技能和专长仅此而已。每个人都希望有见风使舵的能力，但现实中，大多数人还是随心所欲。后来机缘巧合，我选择了第二家公司，也就是Wyze。智能家居行业多年来一直被业界提及，一直不温不火，算不上热点（甚至今天也算不上）。几年前我的选择逻辑也很简单。我对市场和行业没有太多的分析。最开始的出发点是在买安装材料的时候，发现网控设备比普通设备贵了好几倍，然后就考虑这是否是一个做的机会。当时Wyze刚刚成立，还没有发布任何产品，但是业务逻辑切中了我的痛点，于是我找到了创始人，经过一年多的接触和考察，我决定正式加入。可以说，我的每一次“失误”，都是在做出自己个人感兴趣、擅长、更符合发展趋势的产品。所以，对于创业，我的看法是，一定要找到一个符合自己兴趣和特长，同时也有发展潜力的行业。只要不是不好的行业，是不是趋势真的没那么重要。如果没有办法两全其美，现在可能还不是创业的最佳时机，有条件的可以再等等。想追热点，也可以先学。站在工程师的角度去理解技术的起点和优势，过程中可能会遇到挑战，进而进行突破和创新。商业模式：B2BVSB2C我的第一笔生意是做B2B生意，为企业提供图像识别API；现在这家公司是一家B2C企业，向公众销售智能家居设备。所以我对这两种不同的模式有着深刻的理解。我来自技术背景。刚开始创业的时候，我走的是典型的工程师或者科学家的创业路子：我有独特的技能，我想看看能不能提供一些服务和产品来帮助客户，顺便赚点钱。这条路最有可能是B2B公司，也就是卖解决方案。这类公司本质上是从技术着手寻找市场，所以技术合伙人在团队中的地位是绝对强势的。与大多数公司的CEO在团队中拥有最高话语权不同，技术型公司的CEO作为商业伙伴，往往会忽略一个问题：业务是否可行，客观来说，CEO说什么并不重要，CTO表示最终决定。如果CEO未能认识到其中的细微差别并调整预期，那肯定会为未来的冲突埋下伏笔。一个简单的例子：如果业务场景技术实现不了怎么办？因此，CEO必须学会倾听并赢得信任，而不是推行自己的政策。如果你是一家公司的技术合伙人，一定要找一个性格互补的商业伙伴。做事的态度比经验更重要。上面说了，能不能听懂你的想法是最重要的。业务合作伙伴处于与客户对接的第一线，技术合作伙伴通常从事技术研发。业务合作伙伴必须比技术合作伙伴更清楚客户需要什么。所以相对来说，你要别人听，你就不能任性。毕竟，技术再强，也不代表就能成功实施。但是，在选择事业伙伴的时候，一定要给他足够的空间，全心全意地信任他。对客户、对生意，多想，多懂。这对你来说也是一个学习的过程。BtoBtoBtoC的心路历程BtoC和BtoB的出发点是不一样的，B2B是从技术上求市场，B2C是反过来的，技术要从市场和产品来定.事实证明，BtoC技术合伙人的视角和BtoB完全不一样，最大的一点就是技术已经从主导公司发展的方向让位给了产品。近十年来，人们常说growthhacking，即growthhacking，即ToC公司要想成长，产品必须具备一些病毒扩散的属性。这些属性通常在技术上实现起来可能不是很复杂，但这些功能对公司的成功起着举足轻重的作用。很多技术出身的同学不屑于做这些简单的事情。这是非常不希望的。毕竟再简单的东西，如果被几百万、几千万的用户使用，就会变成一件很有挑战性的事情。更何况，很多简单的东西也是基本功。ToC公司涉及的内容和技术栈比ToB技术公司复杂。体量大，就无法避免高并发，但就单一技术而言，往往不够深入。综上所述，如果你最喜欢自己带头做事，最求深度，那就做BtoB的生意，一定要找到志同道合的伙伴。如果喜欢开阔眼界，追求广度，那就往ToC方向走。创业态度：工匠精神vs.MVP技术同学要经常面对产品上线的压力。几乎每一次他们都觉得自己快要上架了。如何在妥协和坚持中找到合理的度？MVP类型的产品，是否需要强调后台服务的可扩展性？我在Wyze的时候犯了和所有硬件公司一样的错误。在设备数量快速增长的基础上，我们也在千方百计扩大软件收入和利润。2020年，团队决定打造一套性价比极高的安全系统，投入大量资源，用半年时间打造了一个至少可以支撑百万用户的系统。推出后的第一年只有20,000名用户。这是一个严重的错误。产品组和技术组各带50块板子：产品组花了半年时间定义了一个没有简化到极致的MVP。技术团队在过度工程上花费了大量的时间和资源，完成了一个并不那么容易的第一个版本，最终证明一开始大家对增长曲线的预期是错误的。我们从中得到的教训是：当产品本身被定位为MVP时，必须谨慎管理资源。如果没有人使用MVP，无论我们欠下多少技术债务，都没有必要解决它。相反，即使是一个满是Bug的MVP，只要有足够多的人使用，我们最终也会拿到修复Bug的预算。对于存在已知错误的产品，最佳发布策略是什么？举一个我亲身经历的例子：近几年，我们公司推出了很多相机产品。其中一个方案交给方案商的时候，当时方案商指定的内存分区出现了问题。最后，为视频数据预留的分区太大，而为程序运行时预留的内存分区太小，导致内存不足，无法添加新功能。我们从审查中得出的结论是：当产品出现已知缺陷时，需要区分是哪种技术债。技术债分为单向门和双向门。不是说不能欠，而是遇到可能的单向门技术债时，就得小心了。我的建议是，对于产品发布后难以改正的严重问题，一旦被发现，不要懦弱，技术部门会不惜一切代价阻止产品上线。比如刚才的例子，系统内存分配就是一种典型的单向技术债。当设备交付给用户时，可以通过OTA来修改业务逻辑，但是修改系统分区就会变得异常困难。资源压力大，如何说服产品和业务分配资源解决技术债在初创公司，资源通常很紧张，但业务负责人通常不了解技术的复杂性。虽然大家都知道技术债不好，但是因为没有办法量化，所以产品功能和技术债经常纠缠在一起。技术债的修复往往会降低优先级，降低系统稳定性，增加研发难度，可能带来更多bug甚至降低产品体验、用户口碑下降等。在这种情况下如何说服产品和业务？根本的办法是将技术债量化，尽可能映射到财务上，帮助其他团队成员从投资回报率上了解技术债的实际成本，但这并不容易。我自己的做法是先统一不同研发团队的规范和开发流程，然后在此基础上尽可能量化。如果可以量化工作量，就可以量化工程人员的成本，然后根据项目超过预期时间的时间来量化额外的工程成本。这部分是技术债务需要支付的溢价。我在中国和美国管理着十多个研发团队，每个月我都会召集所有研发经理开例会。除了我和大家更新公司目前的大事甚至一些财务数据外，还会有两到三位研发经理以抽签的形式汇报他们团队的工作，展示他们团队的运营和项目管理数据。这次会议，所有团队和项目负责人都出席了。在执行过程中确实存在各种不规范之处。现场看到了各种不规范的问题被强调和改正。几个月后，所有团队在项目管理过程中趋于一致。此外，我还做了一件事：把精通敏捷开发流程的项目经理放到团队中。一方面是监督项目的进展，协调各团队的配合。另一方面，它也会监督和改进每个团队执行的流程，并将情况反馈给我。通过这种双管齐下的方式，我们整个团队的流程逐渐趋于统一。但统一的流程还不够，它只能保证工程量化数据的准确性。时间差不多的时候，我开始用系统记录每个项目的计划时间和实际延期。我发现所有的项目都比预期的时间高了30%。实际原因可能比较复杂，但即使不详细，也可以知道整个技术债对开发资源的影响大约是研发成本的30%，然后粗略算出技术债对应的金额，从而说服整个公司投入资源来解决技术债务。作为一家创业公司的技术总监，资源永远是不够的，所以如何保护自己的工程师也是一个很重要的问题。我的做法是把需求变成队列，定义工程团队可以接受任务的最低门槛。具体来说，产品组约定，所有的任务都要排队，要有具体的ROI计算和UI设计稿。只有满足这些条件，开发团队才能接单。每个周期的接单逻辑是有限的，先到先得。如果你迟到了并且想插队，这是不允许的。需要和前面的其他产品经理商量。这也会迫使产品经理更加谨慎地做出产品决策。最后，我想用古希腊哲人的话作为总结，对于不可控的事情，我们要保持乐观和自信。对于可控的事情，我们需要谨慎和克制。焦虑和恐惧无济于事。活动预告9月24日下午，声网开发者创业大讲堂第五期将以“科技创业者如何管理好自己的技术团队？”为题，翟佳、杨帆、史海峰三位资深技术专家将进行演讲。应邀讲学。大家带来了精彩的分享，欢迎有兴趣的小伙伴踊跃报名~点击活动报名链接：https://www.huodongxing.com/e...
