互联网智能硬件产品的项目管理你得这样做

　　本文主要阐述对于项目管理来说，智能硬件产品跟普通互联网产品的研发有什么不同，又有哪些地方是需要特别关注的。
　　近年来，市面上涌现出大批智能硬件产品，按照功能场景可以分为智能穿戴、智能家居、智能健康等多种类型，具体到智能手表、智能手环、智能摄像头、智能音箱等多种产品。
　　笔者有幸加入智能摄像头团队一年多时间，根据自己浅薄的经验来简单谈谈：对于项目管理来说，智能硬件产品跟普通互联网产品的研发有什么不同，又有哪些地方是需要特别关注的。
　　首先：硬件产品的迭代成本远远高于软件。
　　体现在两方面：一方面是硬件产品的研发周期较长，另一方面是硬件产品的研发成本高。主要原因是：硬件产品整体的设计是牵一发而动全身的，即使做到模块化，如果对功能设计做一些改动，例如把某硬件设备的连接方式从蓝牙改成wifi，也很可能会涉及到pcb板的改动，需要重新设计和制作，然后才能检验效果；对于软件来说，即使是全局的变更，修改成本也相对较小，而且没有等待生产的时间。
　　因此互联网产品开发中常用的小步快跑思路在硬件研发中不一定适用，笔者的经验是尽可能在研发初期能尽量完善的考虑硬件的设计的合理性、精确性和后续生产效率，而不要在研发过程中多次对设计稿进行修改。
　　其次：基于以上情况，软件研发的版本节奏和功能安排都需要充分考虑与硬件的配合。
　　对于纯软件的互联网产品来说：只要梳理出目前的需求，并按照优先级排序，就可以逐步按照团队的开发节奏来固定版本周期（比如两周一个迭代），按照规模和优先级把需求排列到一个个版本中去，按照固定的节奏交付。
　　但涉及到硬件的软件开发，很可能会因为硬件的交付时间和版本而受到影响，原本计划的一些功能和接口也可能发生变化，因此版本交付的内容、版本周期都需要根据硬件的情况灵活调整，可以考虑把相互依赖的功能单独管理，或者根据需要调整版本交付的范围和时间。对于智能硬件开发团队，拥抱变化是更加需要的。
　　此外：版本排期需要考虑软硬件联调的时间和风险。
　　此处特别要提到的一点是：智能硬件产品涉及到软硬件接口，需要提前定义接口规范，才能避免因为接口问题导致联调出问题。
　　但即使做到了这一点，软硬件联调依然存在比较大的风险，是否兼容、固件（即硬件设备中的软件系统）是否会导致软件崩溃等诸多方面，都需要充分测试。因此在版本排期时也需要充分考虑联调的风险和影响，留足处理问题的时间，也尽可能准备好风险应对。
　　最后：智能硬件产品的功能定义，通常都会同时影响软件和硬件。
　　定义产品功能，或变更一个功能，需要从整体上考虑它对于软件和硬件两方面的影响，做出关联的调整和变化。
　　例如在智能摄像头中如果去掉夜视模块，看起来是只对硬件做了改动，但实际上软件上就需要考虑，没有了这个功能那么夜视相关的界面、此功能的开关按钮和操作提示，是否都需要做相应的调整，并且对于不同功能的摄像头版本进行识别，这样才能更好的配合不同版本硬件的功能。
　　再比如，智能硬件产品的固件升级，看起来只需要在硬件中加入OTA（自动升级）模块，但是app上也需要增加对应的升级页面，如果没有整体考虑，就会出现问题。
　　其实还有最重要的一点：细节决定成败。
　　这一点跟软件产品或许是共通的，但是对于硬件产品，它有更多的解读。
　　硬件产品涉及到的细节实在是太多了，不仅限于软件按期交付，还会存在硬件质量和生产等问题，会经历非常多的打磨和踩坑，因此智能硬件的项目管理，需要关注方方面面的细节。无论是主机还是配件，都需要确认细节。
　　例如：我们在生产某个小配件时，发现由于内结构生产时开模没有检查好，原本应该是直角的位置，做了圆角，导致原本可以装进去的东西无法装配，但是交付在即，大家手工修整，完成了几百个样品的装配。
　　可能有些人会觉得配件跟智能硬件本身没有太大关系，我们只要做好主要这部分就问题不大，但是作为一个产品，我们要把它完整的交付给用户，就需要连哪怕一个螺丝钉的设计都考虑周全。
　　除了以上提到的这些，还有很多值得关注的点。
　　从技术上考虑，软件版本的升级需要考虑硬件产品的兼容性，固件的升级要考虑设备和app的兼容性，在定位设备问题时，根据表象如何判断问题来自硬件还是软件，如何确保用户数据的稳定和安全性等。
　　从团队上考虑，怎样让硬件研发团队跟软件研发团队更好的协作。做一个智能硬件产品并不容易，除了研发过程，我们还需要关注硬件的质量、生产、产能、供货等方方面面的问题，关于这些以后再具体展开。
　　以上这些列举并不完善，只是个人工作中的一些粗浅总结和思考，大部分都是从一次次踩坑中得到的经验教训，希望对同样奋斗在智能硬件产品中的同学有一些借鉴意义。