最近公司在搞一个 AI + 无人机的新项目。
老板找到我问：“这个系统，能不能让它自己决策、自己飞？”
我想了想说：“完全自主还有点远，但做辅助决策、自动化任务执行是没问题的。”
他点点头：“行，那方案里先写‘智能决策’。”
干这行久了，我有个特别深的体会：很多时候我们反复讨论、字斟句酌的，其实不是功能本身怎么实现，而是在界定一旦出了问题，责任该由文档里的哪一行字来承担。
有一次去客户现场做演示，偏偏那地方网络信号特别差。无人机死活连不上我们的控制平台。
老板和客户都盯着大屏幕，然后他转过头看我。
我赶紧解释：“老板，这主要是现场环境问题，网络不稳定。”
他回了我一句，我至今记得：“客户未来也在这个环境里用。”
在设计调度系统时，我特意花了一整页 PRD 来写“异常处理流程”，列举了十几种可能出错的场景。
开发同事看完直挠头：“你这异常是不是列得太多了？有些情况概率极低。”
我很无奈：“不多，这都是之前被客户一个个问出来的。咱们先想到，总比现场被问住强。”
客户提了个需求：“我能不能在后台实时看到每一架无人机的状态？比如位置、电量这些。”
我说：“当然可以，我们设计的就是实时监控。”
他接着问：“那这个‘实时’，延迟具体是多少毫秒？”
我：“这得看实际网络环境…”
他立刻摆手：“看环境？那就不叫实时。”
在一次需求评审会上，我提出：“这个自动航线规划功能，我们得考虑一些极端情况下的处理。”
开发同事问：“比如？”
我说：“比如无人机正在执行任务，飞了一半，突然断网了，它该怎么办？”
会议室顿时安静了几秒钟。
做无人机管理系统时间长了，我养成了一个“好习惯”：开始把所有的“失败”和“错误”，都叫作“安全降级”或“优雅回退”。这么一说，听着就专业、稳妥多了。
客户调研时问：“你们这个系统，理论上一台服务器最多能管理多少架无人机同时飞行？”
我照着方案里的数字回答：“理论上，支撑几百架没问题，架构是弹性的。”
他不放心，追问道：“那实际上呢？你们实测过多少？”
我笑了笑：“实际上…得看当时服务器的‘心情’和负载。”
有一次重大更新上线前，我有点紧张，跑去问负责核心模块的开发大哥：“这次更新的稳定性，你觉得怎么样？会不会有隐藏bug？”
他信心满满：“从我这边看，代码逻辑肯定没问题，测试都通过了。”
我还是不放心：“那…到了客户那个复杂的现场环境呢？”
他拍了拍我：“那个啊，那就不是代码能决定的了，那是‘玄学’范畴。”
最尴尬的一次是在客户现场。演示时无人机出了点小状况，有点偏离预定航线。
客户看着屏幕，突然提议：“对了，你们这个系统有没有‘一键紧急返航’功能？这种时候应该用得上。”
我赶紧点头：“有的有的，这个功能我们做了！”
他马上反问，眼神里带着疑惑：“那刚才情况发生的时候，你们为什么不用呢？”
我沉默了两秒，诚实地说：“因为…当时紧张，一下子没想起来。”
这些让人哭笑不得的对话，是不是也让你感同身受？无论是需求博弈、方案评审还是现场救火，都是产品经理成长路上的必修课。如果你也有类似的故事想吐槽，或者想看看同行们如何用Axure画出精妙的解决方案，欢迎来云栈社区逛逛，这里有一群和你一样在需求、开发和老板之间“穿梭”的同行者。
发表于 2 小时前
|
查看: 6|
回复: 0
