2016-2-16 2015 CUF Team 总结

[hjzheng]

关于 2015 CUF Team 总结

背景

• Common Team (CUF Team): 2个前端工程师，有 Java 开发能力。
• Product Teams: 40多个 Java 工程师，没有独立前端开发能力，当UX设计出新页面的时候，需要 Common Team 进行支持（如果现有的CUF JS库可以满足，就不需要，如果不能满足，就需要提供组件或者直接帮着做）。
• 面临前端技术全面更换的问题。

前端新技术调研 (已经完成)

• 关注业界流行趋势，结合团队实际情况，选择技术进行调研。
  • 前端开发中存在哪些问题
  • 新技术用来解决哪些问题
• Common Team 内部自己先实践，出 demo 和最佳实践。
  • 如何更好的应用新技术
  • 新技术的最佳实践

新技术落地问题 (目前最大的问题)

• 与 Product Team 工程师合作。
  • 培训
• 设计端到端的完整工作流。
  • 参与到产品开发中去，整合前后端资源，设计完整流程和方案

目前的现状

当前已经有一个 Product Team 在使用我们的成果，但是只是将最佳实践的代码拿过去用，并没有结合自己的实际情况去设计完整的方案，还是旧的手工开发模式，没有将gulp等自动化方式整合进去。

产生这样情况的原因：

第一，是 Common Team 的定位问题，我们将自己定义为一个辅助角色。而不是主导角色，很难将前后端资源整合到一起，只是出了问题，帮忙解决问题。

第二，Team 内部缺乏具有前后端架构能力的人。 我们最初设计是前后端分离，后端使用标准 RESTful API 的形式，通过 gulp 针对不同的环境进行API切换，但现实的问题是，Product Team 没有时间或者不愿意将后台修改成标准 RESTful，这个完全是 Common Team 自己闭门造车的造成的结果，没有结合后端实际情况的设计，这也是为什么需要 Common Team 的人参与到实际产品中，并主导产品端到端的设计的原因。

第三，缺少 Manager 强有力的支持。这是这种以 Business 为导向公司的通病，产品经理不会在乎产品架构设计，一旦新需求来临，产品经理们只在乎能否以最快的速度做完，要求工程师给出 plan，再加上某 UX 的奇葩的设计，所以也导致了 Product Team 直接将代码拿过去用的结果。

另外据说还有两个 Product Team 准备去用最佳实践。

下一步，如何做

如何做，其实不难:

首先，Common Team 需要重新定位自己，扩大 Team 影响力，具有一定的自主能力，不能再和之前一样，受其他因素的干扰，比如，其他 team 缺人，被借去帮忙，再比如，某 UX 竟然都可以干预实现，决定用何种技术：必须用 SVG ,不能用 iconfont 。

第二，如上面所提到的落地问题的方案，对 Product Team 的工程师进行培训，让他们体会到新技术的好处，这样日后在产品中使用新技术，不会有畏难和抵制的情况。（人面对未知事物时，或多或少会有抵触心理）

第三， 一定要参与到产品的实际架构中去，结合实际情况去主导整个架构的设计，不要闭门造车。(这样做，显然是有难度的，具体原因就不明说了)

第四，提高自身的技术和业务水平，具备前后端架构的能力，影响更多的 Product Team 的工程师，让他们具有独立架构前端基本能力，因为现在的前端技术发展速度之快，是任何人都无法想象，再也不能像以前一样，一种技术吃好几年。

[mayufo]

厉害！