Skip to content

mishe/blog

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

8 Commits
 
 
 
 
 
 

Repository files navigation

项目破题,时时牢记

项目之初,需求不明,死线(dead line)已定。

"压力山大,谋定而后动", 基于业务,权衡利弊,发现风险,积极沟通,设计方案而后动。

需求改动频繁,排期总是被压缩。

需求变更通常有三种原因:

  • 源于竞争态势的变化,战略的快速调整。
  • 敏捷的产品开发实践,小步快跑,渐进明细。
  • 产品设计人员没有想清楚。

眼光放在项目目标,思考自己能做些什么。大家需要的不是你的抱怨,而是你的“补位”

总是缺人手,加班不断,且代码质量差。

  • 项目确实过于紧急,基于目前的人数,无论什么样的开发者都会吃不消。
  • 业务频率正常,团队生产力低下

对于1, 暴露的问题在于内和外

内: 对业务的增量没有充分预估,做好人力储备,或技术架构对人力内调不支持。 外: 缺乏跨团队借调人力的能力。

对于2,需要定位原因,是前端团队自身工作流问题,还是与其它团队配合问题。分而治之。此时最好不要再抱怨“缺人手”,以免更加被人“不看好”。

前后端联调环境搭建耗时,且定位问题麻烦,导致联调时间不可控。

UI过于纠结界面细节,导致交付时间不可控。

  • 精益求精永远是没错的,但还是要从项目的紧急程度来看问题。好的FE需要一定的沟通能力。
  • FE需要协同UI,UE 制定组件化视觉规范。

移动端,设备多,兼容问题多,导致自测时间不可控。

  • 移动时代虽然让FE脱离了恼人的各种IE,却又带来了更多的平台的兼容问题。我们希望通过一个个可复用,经过测试的组件来减少日常开发的跨终端的测试。
  • 试想,如果每次开发,80%以上的模块都是复用可靠且兼容的组件开发,那么这些兼容性问题,将会随着组件库的丰富,越来越少。

领导说,PM说,UI说,UE说。信息不对等,到底听谁说?

毫无疑问,无论“是谁说”,最后都得听领导的,别问我为什么!(但又不能事事都问领导,轻重请自行把握)

基于历史原因,总是无法采用更恰当的技术方案,导致团队技术脱节。

  • 要解决这个问题,首先我们必须承认,根本不存在完美的技术方案和架构。我们需要拥抱变化,为向未来的技术和架构过渡做好准备。 渐进式架构与技术债务
  • 基于团队的不同形态设计适合不同阶段的架构与技术堆栈。同时,需要以开放的心态看待
  • "技术债务",就像我们通常不喜欢欠债,但有时候贷款也是为了创造更大的利润。关键在于管控和权衡。

何时可以启用新技术与架构?

  • 对于不重要不紧急的产品
  • 如果没有,就在组内做技术驱动的技术产品,比如团队网站,以此来打磨新技术或架构。然后选择一个恰当的时机在新项目里推行。

一边加班,一边吐槽,一边被吐槽。

满满的负能量,自以为嘴上爽了,你可知被你吐槽的人是怎样看待你?你又何曾把他看做是你团队里面的"自己人"?

走人了,换了个团队,问题依旧。

是的,当你带着抱怨离开这个团队,你可能会发现又跳进了另一个坑。 其实,也许你原本可以改变,但你选择了放弃。 当你能为团队做更多事,更多补位,那你的价值也就提升了。 而"走"往往只是一种无奈的回避。

About

前端碰上的问题或体会

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published