Q: 当我们发现产线问题的时候，受影响的团队跟进不及时，此时总是需要我们来不断催促提高问题的优先级。
A: 在工作中，如何评定问题的优先级决定了各个团队采取的不同应对措施。在我们眼中的高优先级的事情，如何成为对方眼中重要的事，这一点要客观地看待。首先这是不是的确很重要，会不会是个影响面很小的问题。从这点上来说，如果能有数据支撑是一个非常有效的方式。只是口头上一再单方面强调问题的重要性并不能对信息接收方形成太大的影响，而数字比较容易让对方与自己的职责产生关联。比如这个问题会在多少个数据中心出现，在哪些版本中会有影响。有时候的确没办法所有事情都有现成的数据来表达，这时候一方面要给自己留活，因为从产品角度来说，你做的东西为什么是重要的，这本身就需要有指标来加以说明，另一方面看能不能有第三方数据或者可以平移的数据加以辅助说明。有理不在声高，特别是职场，很多时候数字能帮助我们解释很多问题。
Q: 作为产品的开发者，却不知道用什么来监控自己的产品，哪怕手头有很好的工具。
这个问题就好像家里有个钉子需要敲一下，而且工具箱命名有榔头，却还是选择螺丝起子来敲而不愿去工具箱找找有没有更好的工具。有时候使用新的工具的确需要一点时间，但在我看来阻碍大家的是思考，是好奇心。现在的产品诊断数不胜数，有基于数据的，也有基于探针式的，还有基于事件捕捉的。各种工具都有自己擅长的一面，而作为产品的开发者，也许只关注自己开发的那款产品以及技术栈，但如果挑出这个定位，把自己作为一个线上服务的运维，那么眼界就要放的更加开，只要能帮助到自己检测服务的工具，都应该尝试。无论白猫黑猫，能抓到老鼠的就是好猫。作为技术人员，更加不能长期囿于一地，要保持好奇心，看看有没有更好更合适的。明明可以开车，为什么非要骑独轮车呢？学习工具的时间，一定会被后期维护的便捷给予偿还的。
Q: 对于用户故事的描述，部分人员依旧填写的过于简单，觉得是个可有可无的任务。
用户故事本身是为了让开发人员清楚地知道交付什么。虽然也有指定的格式，但是在我看来最重要的内容就是怎么界定完成。 如果能用SMART的标准写清楚那就是最好的，否则就容易在Sprint结束的时候无法验证，无法衡量是否完成，甚至无法交付给客户。