不好的需求设计，是程序员总是说 “实现不了” 和 “祭出菜刀” 的原因之一。
不好的需求设计，破坏程序整体架构，让程序员在没做之前就联想到即将到来的大量重构，感觉蛋疼头大，从内心深处反感抵触。
不好的需求设计，增加劳动量，让程序员996，干一堆没技术含量的杂活。
不好的需求设计，带来 “以后还要改” 的可能性。（程序经常会抱怨策划同学总是不提前多思考；而策划同学也确实总想着 “先这么做，做出来看看效果，不行再改”，不珍惜程序的劳动成果）。
-------------------------------------------------------------------------------------------
NRatel设想一下，
如果程序（客户端）能够为策划提出一些设计准则，一条一条明文地列出来，双方在早期达成共识，
就能有效地避免扯皮事件的发生。
-------------------------------------------------------------------------------------------
1、约定提前设计通用UE。
问题：UE风格杂乱、操作方式杂乱。总是因一些细微差别，让界面难以复用。浪费大量时间和精力。
推荐：设计通用的普通确认框（单按钮、双按钮、是否带叉关闭、是否点击空白处关闭）、设计通用的购买/消耗资源确认框（显示资源数量）、设计通用的奖励确认框（要考虑超多奖励的情况）、设计通用的Toast提示、设计通用的奖励Toast、设计通用的规则说明弹窗、设计通用的道具框。。等等
2、约定时间显示格式。
问题：格式不统一，表现在分隔符不同、精度不同。如：时而 YY年MM月DD日，时而 YY.MM.DD，时而YY/MM/DD，时而 MM月DD日 HH:MM:SS。
推荐：严格统一分隔符（有多语言需求的避免使用年月日时分秒）、固定1~3种精度供选择。
3、约定倒计时的显示格式（常见于活动）。
问题：格式不统一，表现在分隔符不同、时间较大时表现不同。如：时而 HHHHH:MM:SS，时而 MM月DD日HH时MM分SS秒。
推荐：严格统一分隔符（有多语言需求的避免使用年月日时分秒）、使用 HHHHH:MM:SS 的方式最简洁方便，使用自动切换显示当前前2~3位精度的方式最优雅（如 0年1月3天15时23分39秒，显示为 "3天15小时23分"，当倒计时至 0年0月0天10时20分30秒，显示为 "10小时20分30秒"）。