嵌入式软硬件项目外包心得

时间：2023-04-20 11:36:01 | 来源：网站运营

时间：2023-04-20 11:36:01 来源：网站运营

嵌入式软硬件项目外包心得：

前言

我们是一家做物联网软硬件技术的公司，成立于2018年底。由于行业竞争激烈，我们公司的业务一直没有明显起色，为了保证公司有一定的营收，从2020年7月开始，我们决定接收外包项目。截止目前刚好一年，我们一共接洽了31个项目，完成7个，4个在做，其他的未与客户达成合作。值此之际，我想还是有必要做一些总结的。

不同于网页应用和PC应用项目，嵌入式项目除了需要开发软件外，还会涉及硬件开发。为此，我们接下来将从项目前期、中期和后期来讨论嵌入式软硬件项目的开发经验。

结论与建议放在最后。

前期对接

1. 首次电话由工程师沟通

一开始收到外包项目线索后，我们一般会安排销售人员联系客户，确定基本信息后，再由该销售人员拉微信群引入工程师一起探讨项目。本以为很合理的流程实际效果并不理想，能够谈下项目的概率很低。因为我们发现，电话另一端的客户很多都是懂技术细节的，就算是不懂技术细节也都是提前做过功课的，这些客户往往需要有个工程师可以和他们探讨、交流以及验证他们的构想和思路，而这往往是销售人员很难做到的。可以毫不夸张的讲90%都是这样的客户。

首次印象很重要，由工程师打第一通电话是非常有必要的。目前我们只有1个项目是由销售人员达成合作的，客户是某公关顾问公司，而负责对接的是一位公关顾问人员。

2. 确定商务信息，越快越好

商务信息指：“项目预算”、“项目工期”、“知识产权归属”，如果涉及硬件开发还要考虑“客户可接受的单机成本”、“是否需要贴片、测试、组装生产等额外服务”、“出货量”等等。

在前言中汇总的项目数据中我们可以看到，从项目接洽开始到达成合作，这个转化率大概是35%。这个数据之所以这么低，很大一部分原因在于这个首次沟通的工程师（即我本人），往往会忽略商务信息。

电话里听完客户的构想之后，工程师常常会扎进系统设计与实现的技术细节中去。电话结束后，两边都聊的很嗨，工程师也自信满满、跃跃欲试。等工程师设计完大概框架并交由客户确认之后，结果却发现“预算不够”、“工期太长”、“单机硬件成本太高”等等。双方耗费了大量的时间与精力，最后却只是覆水东流。由于本身思维模式的限制，工程师往往都不是很擅长商务内容的对接。关于这个问题的改进多亏合伙的销售人员对我的反复敲打才渐渐改善。

以下这些方案设计书以及截图均是由于前期商务信息不明确，而导致最终无法达成合作。配图于此，时刻提醒自己。

3. 合同重要吗？不重要？

问：合同重要吗？

答：很重要。最初电话沟通的商务信息以及合作模式可能还只是宽泛的概念，但是到了签订合同的阶段，甲乙双方将会很重视的考虑到到每个可操作的细节单元。双方都会再一次确认自己的权利、义务和风险，从而使得在项目中途出现任何问题的时候，双方可以迅速达成一致意见保证项目进展。当然，合同还有一个最基本的作用，那就是从法律意义上对合同双方提供了保障。

问：合同不重要吗？

答：合同不是太重要，对于项目推进来说，合同很多时候都是没有任何意义的，尤其是只做软件的而硬件是由客户提供的项目。在签订合同前，哪怕是一天两天，客户都会和我们在工期上周旋；可一旦签订合同后，要不是电路板还在打样、要不是配件不齐，总之有各种原因致使硬件无法到位。这时如果我们按照合同来约束自己和客户，那么结果不是憋死自己就是憋跑客户。比起合同，这时对我们来说最重要的是要有“服务理念”（“中期推进”中再细说）。

中期推进

1. 时常汇报项目进展或展示阶段性成果

我们知道，现在基本没有银行抢劫案发生，但是每个银行还是都会配备足够的保安和监控。既然没有银行抢劫案了，那么银行的安保也没有用了，是不是可以省去了呢？这个当然是不能省的，个中道理大家也都是懂得。

那么经常性的项目进展汇报就如同银行的安保一样：客户看到之后往往只是回一句“好的”，它不一定会排上用场，但一定不能少。虽然客户要的只是最终的一个结果，但这些项目汇报却是大有意义的。

第一，客户因为了解项目进展而对项目本身更有把控力，尤其是针对第一次合作的客户。毕竟一个项目不是一个简单的小事，通过了解项目的稳步推进，客户也会对项目更有信心并且对我们更加信任。

第二，客户通过了解项目进展，可以修正一些项目前期无法沟通的内容以及双方沟通上的偏差。举个实例，硬件工程师都知道，PCB设计大致可分成画封装、布局和走线这3个递进依赖的步骤，当我们为客户设计一款PCB并最终给出结果的时候，客户告诉我们“电源接口要放在下方”、“接头要插口的不要拧螺丝的”、“SMA接头不能靠得太近”等等，也就是说硬件布局需要修改，这就意味着之前的走线工作全都白费了。但凡我们在中途将布局的结果提前反馈给客户，也不会出现这样的结局。

2. 按需提供服务胜过扣合同的标准

之前我们提到了“合同不重要”，这是因为在前期对接的时候，很多内容是难以界定的，而此时客户怀抱的多半是个构想，期待通过前期沟通而把所有需求都明确下来那只能是强人所难。我们之前有个很仔细的客户，在我们接手项目前他已经把项目内容以文档的形式全部设计完了，并且还包含操作界面原型图。即便如此，项目推进过程中依旧还是有很多需求需要修改。

这里我们需要引入服务的理念，当我们遇到什么问题的时候，先别考虑“解决它”，而是先“确定它”，和客户沟通一下，说明一下问题现象、问题产生的原因、了解一下具体使用场景等等。如此可以让最终的功能更贴合用户需求，同时也会减少需求变更的次数。

3. 遇到技术死局时想想第三方

做嵌入式项目常常会碰到一些死局问题：某个芯片或者器件无法驱动，而这个芯片或者器件的资料又少的可怜。这时应该怎么办呢？第一，我们可以去找芯片或者器件的原厂寻求技术支持。但是有时候原厂不会搭理我们这样的外包服务商，怎么办呢？第二，到某宝找同款器件或者芯片的产品或者供货商，他们一般是芯片或者器件代理商或者是中间开发商，通常都会有一定的技术能力，对我们来说是死局的问题，对他们来说可能是举手之劳。

我们之前做过一款蓝牙手环的案子，其中使用的血氧检测模块的资料非常少。而开发过程中又始终无法调通这一功能。最终是通过供应商转介供应商，于是才找到了解决方案。

后期交付

1. 督促客户反馈

由于我们的客户来自全国各地，很多时候都不具备现场交付的条件。于是在交付时产生的疑问和问题往往都是通过消息、电话或者视频确认的。当我们把产品快递（硬件产品）给客户或者发电子档（软件产品）给客户时，客户有时候会很多天没有回复。这时不妨多问一句。

还有一种情况是客户发现问题后往往会“无法描述问题”，听上去似乎很不可思议但这确实会发生，尤其是在开发体感类产品时更是如此。客户很可能跟我们反馈的问题是“产品用起来有点不舒服”。我们是不可能期待客户能够给出“电流”、“电压”这类的技术性反馈的。这时候我们最好多问问客户说的“不舒服”具体是怎样一种不舒服的体验，然后再修改的过程中尽力去排除和避免这种体验就可以了。

交付过程可长可短，长的甚至比研发周期还长，短的也就一两天的功夫。持续并且及时的和客户交流与反馈问题是交付过程顺利的保障。

2. 合作一定要包含维护期

我们知道BUG这种东西对于软件来说真的是防不胜防，当我们在交付的时候，即便所有的功能都通过了测试，想必客户心里依旧会犯嘀咕：万一产品最后卖出去又出现其他问题了怎么办呢？无论是付费维护（长期维护）还是免费维护（短期维护），一定得给产品界定一个维护周期。给客户一定的缓冲期来检验产品。

结论与建议

按照项目进展，此处给出以下结论与建议：

前期对接：

1. 首次沟通由工程师对接；

2. 尽早确定商务信息；

3. 在合同签订过程中，重视对双方权利、义务和风险的澄清。

中期推进：

1. 经常性汇报项目进展与展示阶段性成果；

2. 项目开发过程即提供服务的过程；

3. 技术难题多多寻求第三方帮助；

后期交付：

1. 督促客户反馈；

2. 合作一定需要包含维护期。