智能硬件项目创业的陷阱

最近Techrunch上一篇:Hardware Case Study: Why Lockitron Has Taken So Long To Ship又戳中了我的G点,于是我抖擞精神,再度提起笔来写写关于Lockitron的文字。这是我第三篇关于Lockitron的文章 —— 之所以对其这么感兴趣,是因为我一直坚定地认为智能硬件是 next big thing,可以媲美互联网和移动互联网这两波浪潮。雷军说「在风口上,台风来了猪都能飞」,创业如果能够顺势而为,可以获得意想不到的巨大发展。

所以我找到了lockitron这样一个非常适合研究的项目来观察它的发展,这是因为:

1) 整个项目的技术特点和难点是我能够理解的(参见我的博文)

2) 创始人非常愿意分享他们的开发过程,以及遇到的问题

3) 他们一直在遭遇各种各样的问题,而且往往旧的问题解决了,又出现新的问题,以致于总是miss deadline。从2012年初开始做这个项目,到如今,两年过去了,当初的backers大部分还没有拿到产品。

关于lockitron项目的介绍和技术分析,可以点击「阅读原文」参看我之前的文章。

我想从创业的角度来纸上谈兵地讨(yi)论(yin)一下,lockitron究竟犯了哪些错误。

团队

首先从团队的角度来看,lockitron究竟缺了什么样的人才。我们知道,lockitron由两部分组成:控制门锁的智能硬件(门锁控制器),和手机上的app,用以控制门锁控制器。其门锁控制器由两节5号电池驱动,带一个机械马达,可以控制旋转门锁达到开关的目的,此外,有一个electric imp的wifi模块用来接受来自互联网的信号,从而控制机械马达。

手机上的app可以放下不提 —— 只论prototype,不考虑多用户使用的场景的话,app只需提供lock/unlock功能,也就是一个简单UI,然后能够发送对应的json message给electric imp cloud service就可以。electric imp cloud service会把收到的message用你预先在electric imp IDE里写好的代码去执行,从而控制设备。

只要有一个app开发者(甚至,在早期阶段,最快的方式是Meteor/Cordova),这些东西都能搞得定,至于electric imp的代码,有一点learning curve,在硬件工程师的帮助下,知道需要如何操作管脚的电平来控制马达,这部分代码写起来也不是太复杂。

复杂的是门锁控制器。虽说使用arduino + 马达 + electric imp就可以快速做出硬件的原型,但真正在用户场景下跑的系统和原型有巨大的差别。这里至少需要一个硬件工程师可以画PCB板,把几个组件连接起来;还需要一个机械工程师来负责机械设备及有关零部件的图纸设计,安装和试运行。我不太清楚这两个职位是否可以由一个人兼,但懂行不懂行差别很大 —— 不要指望一个软件工程师能够快速学习到做硬件和机械设计的知识,学会用arduino和会做产品是两码事;也不要指望深圳代工厂能帮你解决问题 —— 即使你能找到靠谱的OEM/ODM团队,产品在硬件上的迭代也会被拖累。如果有自己的硬件/机械工程师,可以在几个月内迭代多次;而如果外包给深圳的团队,那么,很多idea,bug fix,verification不见得会那么快落实。

虽然没有具体的数据,我猜想Lockitron在团队这里吃了亏。在hacker news的讨论里,很多人也指出lockitron的团队在硬件上犯了不少很初级的错误。我了解过lockitron两位创始人的背景,Cameron Robertson的LinkedIn的profile显示他2010年拿到BA和BS,学的分别是History和Business Administration,而他和Paul 09年就创建了Apigy做Lockitron,所以他一无经验,二无技术背景;而Paul M. Gerhardt看上去和Cameron同龄,可能也就是大学毕业的样子 —— 由于他没有LinkedIn profile,从他在Quora上和hacker news上的表现来看,他应该是个通吃hardware和software的家伙,或者至少通晓hardware —— 一个技术合伙人。

一个合格的软件工程师是可以在实践中培养出来的,犯错的成本并不算太大,弥补的机会也很多,所以刚毕业的学生经过历练,便能成为一个好的软件工程师;但在回归Juniper的这一年,和硬件团队打过多次交到,我意识到,一个好的硬件工程师,必须要在合适的公司,在合格的师傅的帮带下,花费公司不菲的「试错费」,完整地做过一款或者多款真正的硬件产品后,才历练地出来。硬件工程师需要经验,需要经历很多沟沟坎坎 —— 用arduino或者raspberry pi攒个有意思的小东西,算不得产品级的历练。

所以我猜想Lockitron的团队的问题出在了两位年轻的创始人对真正的硬件产品缺乏经验。这也是一款这样理论上并不算复杂的产品,从12年正式announce起,两年时间,还有大量的硬件问题在不断修正,仅仅ship了几千台产品给backers的主要原因。而当年热血沸腾的backers在各种场合表达着对产品的失望。

一个看上去比较懂行的人批评lockitron在早期阶段将硬件交给supplier去做的方式:

IF (and this is a HUGE if) you already know EXACTLY what your product is going to be THEN you MIGHT be able to save a bunch of money using Chinese suppliers and factories. But when you're doing a hardware Kickstarted kind of product you don't necessarily know exactly what the product is and how it will work. You might well be inexperienced too. Manufacturing in-house gives you the ability to rapidly iterate and close the feedback loop (which any good software engineer will tell you is critical) so that you can go from sorta-working to working to working perfectly.

另一个硬件expert列出了lockitron几大问题,其中一个是「不够懂行」:

Knowing how to use an Arduino doesn't make you a product developer, just as knowing Javascript doesn't mean you can deploy a backend that supports 1M users and you only get to deploy it once. Pay an experienced EE or consulting company for 20, 30, 40 hours of work to review your design, plan, and feasibility.

所以一个做智能硬件的团队,必须有一个非常资深的硬件专家,能具体开发硬件的人作为合伙人。这就跟做一个互联网产品,必须要有一个懂互联网技术栈,能写代码的技术合伙人一个道理。而且,硬件合伙人的要求其实远高于软件合伙人。因为他除了能够开发(或者指导开发)硬件外,还要对物料(BOM)供应商(Vendor),对生产等等非常了解并且能很好地管理vendors。

产品

拿到并使用lockitron的backers对其产品的诟病主要集中在电池上。一个哥们绝望地写到:

After owning it for nearly a year and having it only work reliably probably 20% of the time I had one galvanizing experience with it that made me arrive at the realization that it is fundamentally flawed. It is a motorized lock connected to WiFi with a back up of a standard key lock. As it turns out, if the Lockitron runs out of battery mid way through actuating the lock it will freeze the lock in that position. No amount of manual force though just the key backup will work. I spent several hours locked out of my apartment one night requiring emergency service from my complex management and asking a guy to wake up my neighbor so they could climb a ladder and break into my apartment via my balcony. Cameron and the Lockitron staff I interacted with was very good and understanding at all times- but I just could not trust the Lockitron any more. Since it was a battery hog and the battery dying midst turn is a critical problem and there was no notification whatsoever of the battery condition (at the time) AND I couldn't use the manual back up, I had to return it.

当电机工作到一半时电没了是最恐怖的经历,因为锁转动到了一个中间状态就 "freeze" 了。但这个问题其实在产品设计或者测试地阶段应该能考虑到。作为一款硬件产品,应该写足够充分的diagnostics程序,让硬件脱离软件环境,仅仅测试硬件本身地各种性能和状态,尤其是在压力下的表现。我觉得lockitron的团队起码应该能精确地给出以下数字:

1) 全新的电池究竟能够支撑多少次马达带着真实负荷(门锁)的转动。500次,1000次,还是一个什么数字?

2) 没有马达的负荷,保持WIFI一直开着,但没有数据传输的情况下,全新的电池能支撑多久?两天?五天?十天?

3) 没有马达的负荷,开着WIFI,并一直传输数据,全新的电池能够支撑多久?半天?一天?

4) 使用electric imp的节电模式一直开着,看看全新的电池能够支撑多久?

5) 模拟最常用的使用场景:马达每24小时转动六次(开关门三次),每五秒钟electric imp从睡眠模式切换到工作模式,收包,然后再度入睡。看看全新的电池能够支撑多久。

同样的,如果把所用的技术切换到ZigBee,BLE(Bluetooth Low Engergy)又是什么样的功耗?(当然,单纯使用ZigBee或者BLE可能无法完成某些功能,但起码应该考虑这些技术作为辅助方案,并且测试对应的数据)。

我相信,在做这样的测试时会暴露很多问题,比如说马达转动一半的时候卡住不动了。硬件和软件的巨大不同在于,当软件发布后有重大问题时,大家都能理解,而且团队能够在线修复,尽可能把损失弥补到最小;但硬件发布后人们会倾向于认为:「这是硬件,不会有问题的」。

我之前在分析lockitron所有技术的博文中曾经写道:

看了下Imp的手册,idle状态下10mA以内,rx/tx状态会最高到250mA。10mA只能算是中庸,对于AA充电电池(一般2500mA左右)来说,能待机250小时,10天左右。然而Imp还支持deep sleep,在此状态下只需要6uA的电流,不考虑电池自放电,可以待机47年。。。所以,在Imp的帮助下,Lockitron controller能够使用两节AA电池,待机至少1年。

事实上,这个推断太太太乐观了。不少人实际使用后发现,电池连一个月都达不到,而且,由于没有在app里做电源监控,用户都不知道究竟还有多少电。所以说,真实场景下的测试非常有必要。Lockitron团队在没有做足这些功课的前提下就把产品贸然ship给用户,感觉不那么负责任。

为电池省电是门学问。考虑到开门关门这样的操作是「准」实时的,WIFI要随时待命以接收app发过来的指令;但WIFI随时开着会大大降低电池的寿命 —— 自动开门关门再方便,一想到每十天就要换两节电池,头就大了。所以这里要做出一些妥协。比如说允许用户设置一些时间段是自己不可能开关大门的 —— 假设是晚上12点到第二天早上6点间。那么可以让electric imp一直处在deep sleep中,每隔一分钟醒来一次接收和处理开关门请求 —— 之所以这么做,是万一哪天晚上自己回晚了,顶多等一分钟就可以开门了;而其它时间,可以每隔五秒醒来一次接受和处理开关门请求。假设每次处理需要100ms完成,那么每小时大概会让WIFI待机72s,每天待机0.48小时,而非24小时,这样能大大提高电池的寿命。当然,5s左右的延迟会让用户不爽 —— 但开门的动作可以在电梯里,或是在通向大门的小路上完成。

结语

lockitron的营销做得太好了,一系列youtube的视频里生动地描绘了一种美好的生活方式。甚至,ycombinator都成为其早期拥趸,在他们的某间office使用lockitron的产品。在video里,产品被描述得过于完美,功能强大,但真正上手之后,用户才发现,很多功能并未实现,产品还有诸多瑕疵。

这似乎也是所有众筹项目的通病,尤其是硬件项目。产品被吹得天花乱坠,至于实际做成什么样,天知道。当然,lockitron的创始人还算是有责任心的,两年以来一直不离不弃,在努力改进产品。就像一个backer在批评其团队 unaware of the environment / lack of specific knowledge之后,话锋一转:

These guys are going through an awesome trial by fire. They have a well funded, very public, product that they are trying to turn out and they should be commended for sticking with it for that last two years, and for being willing to talk about their challenges. Just like any other start-up, succeed or fail, they're going to be a better position when they do it again.

另外一个backer就毫不留情地质疑去做一件你根本不能胜任的事情是浪费生命的:

As a backer myself: this reads like someone who quite literally no idea what they were doing or getting into in the first place and likely doing it for all the wrong reasons. How did they not know the difference between building a single prototype by hand and manufacturing thousands of units? It sucks to think these people have now devoted a few years of their lives, likely stressful years at that, to general incompetence.

创业需要激情,勇气,对大势的判断,还需要有对自己和团队能力的清醒认识和把握,尤其是犯错成本高,容不得糊弄的硬件创业。

原文发布于微信公众号 - 程序人生(programmer_life)

原文发表时间:2014-07-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏张俊红

拆掉你思维的8堵墙

来源:书籍《拆掉思维的墙》 总第43篇 ▼ ? 所谓思维的墙就是使我们我们思维局限东西,本篇从安全感、有趣与无趣、心智模式等8个方面具体阐述了我们在思维方面的一...

3666
来自专栏腾讯大讲堂的专栏

打车的江山 马蹄声狂乱 ——帝都滴滴抢修记

锲子 和滴滴团队一起战斗的日子已经过去半年了,但那场没有硝烟的战争,至今仍记忆深刻。特作余作文以记之,权作回忆,也当是滴滴打车系统优化经历的一个见证。 那时“...

19810
来自专栏大数据文摘

现实黑镜 | 面对死亡,你愿意将意识上传 获得“永生”吗?

2229
来自专栏JAVA高级架构开发

IT公司老板落水,各部门员工怎么救?

公司专聘高级管理专家:作为公司高管,听到公司老板落水,第一时间电话秘书部预定会议室,紧急召集公司全体会议。会上先摆明问题,说明事情严重性,要求大家集思广益,头脑...

400
来自专栏Java学习网

从 .NET 和 Java 之争谈 IT 行业

一、有些事情难以回头 开篇我先表明自己的立场:同时使用 .Net 和 JAVA,但更加偏爱.Net。原因很简单: .Net语言更具开放性,从开源协议和规范可以...

2328
来自专栏python开发者

网络验证码--你到底是爱它还是恨它?

网络验证码--你到底是爱它还是恨它? 互联网安全防火墙(1)--网络验证码的科普 1   戏言部分 为了在网络上吸引大家读这个文章,在想标题的时候,也是够了。本...

2400
来自专栏mathor

“洛必达”or“伯努利”法则

2124
来自专栏AI科技大本营的专栏

全网首发 | 告别语言交流,欢迎来到意念传输的时代(下)

这几天,我们在以全网最完整的编译、全网最迅速的动作,为读者带来科技人气王Tim Urban的Neuralink长文。 第一篇我们仔细剖析了神经网络的进化史; ...

4416
来自专栏新智元

马斯克加入 #删除Facebook 阵营,销号特斯拉和SpaceX

【新智元导读】“Cambridge Analytica数据门” 丑闻对Facebook的影响不断升级,国外社交媒体声势浩大的 #deletefacebook 运...

3579
来自专栏java一日一条

一个五年 Android 开发者百度、阿里、聚美、映客的面试心经

先简单说说我最近的面试经历吧。面试的公司很多,其中有让我心血沸腾的经历,也有让我感到失望到无助的经历,我将这些体会都记录下来,细想之后很值得,面了这么多公司,要...

1391

扫码关注云+社区

领取腾讯云代金券