第八章 惊喜09 运维支持VS产品迭代
本周发生了几件事情：
亮亮最近产品工作很多，所以自己产品的运维支持都不响应了
小枫的一个产品数据核对中，需要不断处理用户对数的运维工作
莹姐的一个产品方案中，用户期望系统记录数据变化过程，莹姐觉得不值得做，我提议通过一个低成本的查看日志能力来解决
首先我还是非常高兴大家愿意和我分享这些困惑和问题。
这些问题，有其复杂度，我思考后觉得有一定共性，把我的思考在周会分享给大家，并鼓励大家讨论：
产品经理，尽量通过产品化来帮助客户，降低运维；
每一次运维支持的工作量不大，但产品化会比较复杂，觉得性价比不高；那么我们可以把一件运维拆解成多个步骤，一次产品化拆解为多个小的产品优化，不断给用户提供产品能力的微小提升，加强用户自查的能力，逐步降低对我们的依赖。有点像亚马逊的飞轮，通过这个循环来提升产品化解决用户问题的能力；
尼尔森十大原则中，排名第一的是“状态可见性原则”，包括以下3点：
①合理的位置：界面要引导用户操作，让用户清楚当前位置及所需信息。
②合适的时间：系统根据不同时间场景给予反馈，确保反馈及时性。
③适当的反馈：用户能清晰感知已发生、正在发生及即将发生的事情，系统对用户操作给予反馈，减少不确定性。
我们可以深化下，提供用户易读的操作日志的能力，来记录数据变化的全过程，供用户和产品调查问题使用。
产品化和运维是一件事的两面，在不同规模的企业，应对方式会有不同，严格来说是ROI的价值评估问题。作为一家中型企业的信息化团队，因为用户有限，所以有时候产品化的诉求不高，如果产品经理没有自我驱动的意识，那么会陷在运维中无法解脱出来。但也不是所有的事情都要产品化，对于发生率很低，但开发工作量很高的事情，运维支持更经济。所以这件事需要平衡。
我们团队的同学大都不是专业产品经理出身，有产品顾问、也有运维和测试，大家对于产品的极致追求会差一些，产品的能力也在提升中，反而都兢兢业业，甘愿做一些运维的事情，也会更多考虑开发成本。其实这样对产品经理的个人成长是不利的。
果然，我提出的观点也没有得到大家特别高的认可，但比较好的一点，大家也没有否定，了解后提出了自己的意见。我也在不断思考，怎么去更好的理解大家并能够帮助到大家；每个人的成长都受限于自己的经验，我愿意做那个打开窗的人。