"压力山大，谋定而后动", 基于业务，权衡利弊，发现风险，积极沟通，设计方案而后动。
需求变更通常有三种原因：
- 源于竞争态势的变化，战略的快速调整。
- 敏捷的产品开发实践，小步快跑，渐进明细。
- 产品设计人员没有想清楚。
眼光放在项目目标，思考自己能做些什么。大家需要的不是你的抱怨，而是你的“补位”
- 项目确实过于紧急，基于目前的人数，无论什么样的开发者都会吃不消。
- 业务频率正常，团队生产力低下
对于1, 暴露的问题在于内和外
内： 对业务的增量没有充分预估，做好人力储备，或技术架构对人力内调不支持。 外： 缺乏跨团队借调人力的能力。
对于2，需要定位原因，是前端团队自身工作流问题，还是与其它团队配合问题。分而治之。此时最好不要再抱怨“缺人手”，以免更加被人“不看好”。
- 精益求精永远是没错的，但还是要从项目的紧急程度来看问题。好的FE需要一定的沟通能力。
- FE需要协同UI，UE 制定组件化视觉规范。
- 移动时代虽然让FE脱离了恼人的各种IE，却又带来了更多的平台的兼容问题。我们希望通过一个个可复用，经过测试的组件来减少日常开发的跨终端的测试。
- 试想，如果每次开发，80%以上的模块都是复用可靠且兼容的组件开发，那么这些兼容性问题，将会随着组件库的丰富，越来越少。
毫无疑问，无论“是谁说”，最后都得听领导的，别问我为什么！（但又不能事事都问领导，轻重请自行把握）
- 要解决这个问题，首先我们必须承认，根本不存在完美的技术方案和架构。我们需要拥抱变化，为向未来的技术和架构过渡做好准备。 渐进式架构与技术债务
- 基于团队的不同形态设计适合不同阶段的架构与技术堆栈。同时，需要以开放的心态看待
- "技术债务"，就像我们通常不喜欢欠债，但有时候贷款也是为了创造更大的利润。关键在于管控和权衡。
- 对于不重要不紧急的产品
- 如果没有，就在组内做技术驱动的技术产品，比如团队网站，以此来打磨新技术或架构。然后选择一个恰当的时机在新项目里推行。
满满的负能量，自以为嘴上爽了，你可知被你吐槽的人是怎样看待你？你又何曾把他看做是你团队里面的"自己人"?
是的，当你带着抱怨离开这个团队，你可能会发现又跳进了另一个坑。 其实，也许你原本可以改变，但你选择了放弃。 当你能为团队做更多事，更多补位，那你的价值也就提升了。 而"走"往往只是一种无奈的回避。