| 可实现性 |
研发评估后能真的做出来，而不是只能想一想、做不出来。提需求前先确认技术能不能落地，免得白忙一场。 |
技术可行性 |
| 使用场景 |
用户到底在什么情况下用这个产品：是坐在电脑前办公时打开网站，还是出门在外用手机刷 App。先把场景想清楚，功能才不容易做偏。 |
用户场景 |
| 迭代 |
产品上线不是终点，而是根据用户反馈一轮轮地小步改进：加功能；优化体验；修 bug。每一轮都让产品比上一轮更好用。 |
敏捷 |
| 技术债 |
为了赶进度先把功能凑合实现，留下迟早要还的隐患。当时省了事，后面往往要花更多力气补。 |
技术债务 |
| 重构 |
功能不变的前提下，把代码内部结构重新整理干净，让它更好维护、更好改。 |
代码优化 |
| 解耦 |
把原本缠在一起的两块功能分开，各自独立，改一块不容易碰坏另一块。 |
耦合 |
| 耦合 |
两块功能互相依赖得太紧，动一处另一处就跟着出问题，是维护时最头疼的情况。 |
解耦 |
| 兼容性 |
同一个功能在新旧设备、不同系统或浏览器上都能正常用，不挑环境。 |
浏览器兼容 |
| 性能 |
系统跑得快不快、稳不稳，比如页面多久打开、请求多久返回。用户对慢特别敏感。 |
响应时间 |
| 并发 |
同一时间有很多人一起来访问，系统要扛得住这种同时涌入的压力。 |
高并发 |
| 可扩展性 |
现在够用，将来业务变大时也不用推倒重来，加机器或加模块就能接着撑住。 |
扩展性 |