谈谈那些非技术问题

在前端工作中，除了实现产品需求，谈得最多的就是怎么提升开发效率和代码质量，各种工程设施和开发模式都在为这个目标不断进化。

具体到一个团队，真正产生价值的不是工具本身，而是运用工具的过程，这个过程就涉及到人和业务，相比于工具，人和业务是在动态变化的，怎么把人、业务、工具有效的串起来，持续推进团队成长，首先是个管理问题。

科学管理

来自生活经验的思维方式习惯用『除法』来看待人与事的关系，有多少事 / 多少人，需要多少时间 / 多少人，关注点在于把事做完。产品迭代中很少有一次性的事情，开发新功能、改进现有功能都会在已有的资源上进行，写完的代码会对未来的工作、业务持续产生影响，产出质量决定了未来是站在更高的基线上工作、还是跳到坑里工作。

『除法』带来的风险是，每件事都存在不确定性、每个模块都可能出问题。 团队成员的技术能力有差别、不同模块的重要性和生命周期也不一样， 人与事的关系需要通过『分级』来区别对待，让每个人 cover 在合适的事上。

『分级』

产品层面，划分出核心功能、关键的用户流程、访问量最大的页面，比如电商网站的购物车、视频网站的播放器、百度的搜索结果页等等，确保用户核心体验的稳定。

技术层面，重要的资源包括两个部分，产品核心体验对应的业务组件，以及影响范围大的技术元素，包括：基础 UI 组件、代码的组织结构、开发模式、工程工具的配置等等，确保重要资源的高质量产出。

人员层面，能写出满足指定执行逻辑的代码，是对编程的基本要求，具备基础编程能力的人总归是能做到把产品需求实现出来。开发一个需要持续迭代的产品，做到这点还远远不够，对工程师的要求还包括编程的基本抽象能力、对开发模式的掌握、对技术栈上各个元素的掌握、业务理解能力等等，团队成员在这些方面的水平决定了团队的整体研发能力。把不同的人对应在合适的事上能保障团队整体产出的稳定性，这种稳定性包括效率和质量。

目标因素

行动总是由目标驱动，行动中的关注点会映射出对人对事好与不好的标准，团队目标往往来自于直接收益，完成某个业务 KPI、实现几个产品功能等等，关注点自然就会放在把事做完上。眼前的代码和产品功能都有生命周期，在未来的某个时间点总会被迭代掉，把时间线拉长看，还有更多影响深远的目标，产品体验、性能，开发效率、质量，把某项技术做深、新技术方向的探索等等。

团队资源总是不够的，看待问题的时间线、对短期目标和长期目标的权衡决定了资源的分配，资源的分配决定了团队的关注点和做事方式，也决定了团队的整体气质。