如何成功管理硬件开发计划并按时发货
如何成功管理硬件开发计划并按时发货
由山姆康，VP，mind tribe
在获得资金的过程中，许多公司制定了积极的产品开发计划。通常，这个时间表是与风险投资家和客户共享的，当产品可能上市时，人们会不经意地设定很高的期望。不幸的是，由于各种各样的原因，许多公司最终都很难按时交付产品。
在与数百家硬件和软件公司合作后，我们发现构建正确的产品并将其推向市场的秘诀是调整您的产品必须具备的基本、关键功能，然后逐一严格测试每个功能。
下面的几个问题有助于确定你是否有可能完成计划，或者你是否正走在一条充满延迟和挫折的痛苦道路上:
- 对于每个主要的设计-原型-构建阶段，你都有一个明确的问题要回答吗？
许多开发计划都有类似这样的结构:
- 体系结构
- 台式原型
- 集成原型 1 (EVT1)
- 集成原型 2 (EVT2)
- 设计验证测试
- 生产验证测试(PVT)
虽然这对您的开发来说可能是好的，但是团队经常陷入这样的陷阱，即考虑他们试图构建什么，而不是他们试图学习什么。
例如，假设我们正在开发一款名为 FruitMeter 的产品，它可以使用一种新型的糖传感器来测量水果的甜度。面向编写软件的团队可能会说这样的话，“我们有一个传感器，让我们构建定制的电子设备，通过蓝牙将其连接到微处理器，并在手机上显示血糖水平。”
然而，如果关键风险是如何处理水果样品，使其不会随着时间的推移而污染传感器呢？在这种情况下，你最好原型化如何从水果中提取样本以及样本之间的有效清洁。
如果一个团队只考虑构建而不学习，原型将不会减轻关键风险。此外，某些风险比其他风险更重要。明确地说出你想要学习的是第一步，下一步是确保时间表和原型对那些风险进行了正确的排序。
2。是否有基于用户需求的可客观验证的成功或失败标准？
另一个错误是在原型和测试阶段没有为成功和失败设定明确的标准。如果不这样做，您的团队可能会构建出一个很少(如果有的话)有帮助的原型。
例如，在水果计的情况下，你如何定义传感器对污染的弹性的成功标准？一个糟糕的标准是告诉工程团队:“传感器必须能够抵御污染。”太多的团队在这样的需求下运作。
更好的方法是运行一些财务模型或用户测试，以显示在维修设备之前进行 100 次读数的价值。然后团队可以被告知“该设备必须对至少 100 个水果样本起作用。”
更好的方法是与您的目标客户一起定义真实生活场景，并选择最困难的场景(即可能造成最多污染的场景)。也许这就是人们因为无花果含糖量高而取样的情况，但样品相隔一小时，果汁在传感器上变干。所以最好的要求是“100 个无花果样品，样品之间有一个小时的等待时间。”
现在，我们并不是建议您需要一个详尽的 PRD。一份列出所有需求的 20 页的 PRD 是不必要的，尤其是在设计的早期阶段，当你正在减轻关键风险，甚至不清楚关键风险是什么的时候。坚持特定原型的要求，但确保这些要求植根于关键的客户期望和主要的技术限制条件。
3。每一轮测试中是否只测试一个或两个主要假设？
一个好的时间表的另一个关键标志是，它将学习过程分解成小块，而不是在最后依赖于一个大的整合。
根据我们的经验，每一轮原型构建测试应该只验证一两个主要的假设。这是因为从这些测试中获得的知识会对设计的其他部分产生影响，当它们相互依赖时，试图并行化太多的开发是非常低效的。取而代之的是，计划序列化开发，并加快完成阶段的速度。
总的来说，我们发现在超越概念阶段之前，执行和工程团队在时间表上保持一致是非常有帮助的。你的团队相信这个时间表吗？他们觉得这是乐观还是保守？
从现在开始，错误只会越来越多。尽早意识到你的计划有多大风险，有助于建立一个更现实的奋斗目标，更好地洞察关键挑战，以及在出现不可预见的计划失误时起到缓冲作用。
