有PM提出过这样的问题：

刚负责的一个产品，需求方一直着急上线，用了一个多月加急开发出来，最后试用几天后被告知由于产品稳定性太差，容易出意料之外的bug（试用过程中遇到的问题都有第一时间找技术解决），不用了。。。好受挫233333

做产品半年不到，希望各位大牛指点：产品设计之初的流程跑通了、测试也没问题，但是试用过程中各种奇怪的bug粗线……作为产品汪如何解决甚至避免这个问题呢？

造成产品稳定性差有许多原因，这是和产品业务流程（包括视觉、交互、功能等）上的设计没有太大关系的。一个产品的稳定性，其实可以从内部条件、外部环境两个角度来评价。

内部条件：

1. 系统架构

架构的合理性，彼此的耦合程度等等。这就是为什么架构师现在变得尤为重要。优秀的架构师剖析可行性、技术需求以及权衡取舍等因素，设计出合理的思路后，再交由（或一并）开发的兄弟们干活。而不会出现不可预期的短板，或者功能模块的相互牵制，导致了稳定性很低。

2. 开发框架

任何开发框架都不完美，也有各自的适用的范围。最好选择合理且稳定的，这会直接影响到整个系统的稳定性和效率。（最新的未必好，除非技术负责人勇于尝新，让自己和团队成员获得紧跟时代的编程能力。但这仅可以用在某个项目上）。

3. 代码质量

代码在人为，这和开发人员的经验，责任心有关。如果没有造过大量的轮子，或者拿来主义的随便糊弄过去，运行起来也肯定是磕磕绊绊。

外部环境（支撑环境）：

1. 网络环境

测试环境到UAT再到生产环境，是否存在因线路变化，端口/防火墙限制，服务器部署方案不合理造成的卡顿或掉线。

2. 硬件环境

是否遇到未考虑到的流量高峰（比如限时抢购，大促）或者系统承载之外的访问量导致硬件不足，必须以扩充解决。

3. 软件环境

软件都拥有多个版本，检查当前版本中是否对存在对平台平台的牵制或影响。可以升级/降级软件版本已让平台发挥出最大的效应。

其他情况（相关辅助工作）

1. 测试用例欠缺

测试用例不完善，测试只是走个过场，很容易造成在正式使用时出现『未知』的Bug

2. 测试人员只看问题表面，不寻求关联

使用 – 记录Bug，这是普通测试；

使用 – 记录Bug，分析Bug，这是好的测试；

使用 – 记录Bug，分析Bugs找出这些问题的关联，这是优秀的测试。

测试人员绝不仅仅是把产品走一遍，然后记录下Bug反馈给开发修改。如果能试着找出其中的关联（需具备一定开发知识，或精通测试工具），将问题归类合并反馈给开发，不仅可以帮助开发同学大大减少工作量，也有助于让开发找到在Coding时忽略的问题。减少出错几率。

所以优秀的测试和开发一样重要。具体什么标准？我放个图大家斟酌：

以上提到的这些，实际上都不是作为产品经理的你可以掌控的。作为产品汪（尤其是不懂技术的产品汪）来说，还是诚恳一点，拉着技术负责人一起按照这个框架，从头到尾的分析问题，把专业的事交给专业的人去做，并且给出解决问题的方案时间。而自己则需要安抚好需求方，这才是王道。