简单设计，是敏捷里的一项重要实践，也是非常难掌握的一个，难就难在“度”上，很难把握，这里分享一下我们项目的实例。 至少有这样几种方式： 这是一个现实的简单设计的案例，然而它是由项目经理提出的，为什么不是其他角色？因为产品经理会自然倾向思考正常逻辑和一些表面的异常场景，所以只有少数非常有经验的能够想的非常周到。而技术人员有会很自然的从技术实现角度考虑，而不是用户使用场景。这是习惯思维导致的正常问题，不容易纠正，因此PM作为一个中立的角色，出于风险的考虑不能只考虑正常逻辑，同时出于降低风险的考虑也不会考虑复杂的实现方式，因此PM通常能给出较为合理的建议。当然项目经理也需要培养自己的产品意识。 然而PM常常忽视掉自己在这方面的价值，殊不知，这对产品对用户对项目都是作用巨大，希望PM们都能开始关注需求的简单设计。
QT语音，有一个需求——实现对当前房间播放语音进行录音，并自动保存为本地MP3文件。听起来很简单，但那是正常逻辑，异常逻辑很多，例如如果用户忘记关闭录音功能，那么硬盘可能会被录音文件占满，这种情况应该如何处理？
因为在不同场景下，你的“度”的选择都不相同，因此这里没有标准答案。分享一下我们的选择。最初产品经理没有考虑到这种场景（这种情况常常存在），开发工程师想到了，他们的建议方案是1（技术化的思路）。然而我并不希望是这种方案，因为方案1并非用户正常场景，这种技术化的实现方案是最为常见的“过度设计”（与简单设计相对），它并没有从用户价值角度出发；方案2也未必是合理的用户场景，因为在此功能上线前，是无法预知常见录音时长的；方案3是一种中断性提示，影响用户的当前操作，而且如果用户在游戏中也会被这种提示所干扰，而且如果选择继续，那么一定还需要实现一系列后续选择新位置的操作，这使得整个功能变得更加复杂；方案4是我推荐的方案，也是最终的方案，它足够简单，也满足了大多数正常用户（会主动停止录音）的需要，对于占满后的操作可以由用户自行决定，你只要通过非阻断式提示告知用户已经停止即可。