# 前端工程师能力匹配
# 业务视角
# 需求评审
需求评审立足于两点：
- 只要需求评审之前有时间，强烈建议把需求文档浏览一遍，可以做到心中有数，有些疑惑或者问题，可以在评审中及时提出。
- 产品力作为通用能力，前端工程师肯定需要有一定的产品能力，要能够始终站在用户的角度思考问题，能够主动优化产品的用户体验。此处有个方法论：多问一下这个需求的背景是什么？能够带来什么样的用户价值？多思考需求到低有没有解决用户的痛点，或者说用户更深层次的需求是什么？（想要一匹更快马，还是需要的是一辆汽车）如果遇到经验欠缺的产品经理，做完这些往往可以砍掉很多不合理的需求。
需求评审环节前端工程师的能力简要概括如下：
首先如果是初级工程师，最基本的就是要准确理解需求，能够跟团队中的其他成员有效沟通。
在此基础上就要学会深入理解产品的需求和规划，做到能主动思考，可以对需求进行初步判断：需求是否合理，是否有更优的解决方案。
随着经验和层级的提高，有些情况下需要自己主导做一个产品，你的角色就从需求评审的参与者，转变为需求评审的主导者，这样就要求你能充分了解业务需求的目标，并且能够参与需求规划，发现业务痛点，甚至可以创造出一个新的可以给公司带来收入的产品。
# 需求排期
需求评审完后，在 UI 设计稿的出稿时间、后端接口文档的提供时间、后端接口联调提测时间等相关的时间节点确定后，就要及时的给出前端的较为准确的排期。
如果是复杂的大型需求，可能需要前端团队组内技术评审然后排期。
# 需求跟进
# 开发能力
需求评审完，也给出了排期，之后就是需求开发了：
初级前端工程师最基本的要求是能够独立、高质量的完成任何页面布局和交互开发。
随着技术的提高，会慢慢的开始负责业务需求的技术方案设计和规划，要有发现并解决风险问题的能力。就像之前需求排期中说的，这个阶段的工程师就是组内的中坚力量，需要给复杂的需求进行技术方案设计和之后的技术规划，以及想到会踩哪些坑。
然后随着经验的积累，做的项目多了，慢慢的可以有能力主导项目的技术架构设计，并且能解决核心的技术难题。
关于技术决策，可以看一下这篇文章：5 条做技术决策原则 (opens new window)
# 沟通能力
需求开发过程中肯定会碰到很多技术或者非技术的问题：
- 其他相关方在之前确定好的时间节点出现了延期
例如依赖的上游功能没有按照时间点完成，或者设计图晚给了一天，或者需要的物料迟迟没有给到。遇到这样的情况，首先要告知产品经理，让其协调资源，如果延期的时间不长，可以通过调整开发顺序等方式来进行过渡，如果延期时间长，需要让相关方再重新给出一个时间节点，然后再次进行排期，不管如何都要让产品经理和其他成员知晓需求有延期的风险。
- 多沟通避免返工
例如设计图给到后，要跟产品确认是否定稿。另外对于一些模棱两可的需求，一定要跟产品经理确认，不要想当然。
- 多跟相关方进行沟通
例如接口字段和结构，还有就是开发模块的先后关系等，多跟后端沟通，相互推动，然后根据大家的节奏来更有效率的开发。
此外需求内容和需求排期有任何变动，都要让团队成员周知。而且上面提到的所有沟通，尽量在项目群中沟通，避免私下交流。
以上所说的具体的点都是沟通能力的展示，相比于开发能力而言，初级前端工程师就要求从一开始就需要有较好的沟通能力，可以跟团队中的其他成员一起协同完成工作目标。随着做的项目越来越多，承担的责任越来越大，就必须要有较强的沟通能力，可以和上下游团队进行充分的沟通，取得对方的信任，高效率的完成工作。
# 项目管理
需求可能是一个一个零散的，但是我们要清楚需求的背后是整个产品，产品是需要像一个项目一样进行管理的。
前端工程师最开始就要有项目管理意识，可以使用项目管理的知识管理好自己的日常开发进度，并且还需要了解项目的目标和实施计划，确保按照项目进度执行开发任务。通常会使用一些项目管理工具，要主动及时的更新相关状态及重点细节描述。
慢慢的就能够识别、反馈并解决风险问题，从而保证项目落地。可以结合上面的沟通能力遇到的各种问题来看，大部分都是通过沟通来解决的。
随着经验的积累和项目的历练，承担的责任越来越多，就必须要有较强的项目管理能力，这里就包含有整合资源、团结人的能力，能够推动上下游形成合力，并且在项目的推进过程中，能依靠流程和规则保证项目成功，带领团队完成目标。
# 总结
在跟进需求的过程中，开发能力、沟通能力、项目管理并不是彼此独立的，沟通能力和项目管理能力属于通用型的能力，不只是在跟进需求过程中，它们在之前的需求评审和需求排期中也有影响，之后的复盘优化中也有关系。
例如，开发需求的过程中，在项目管理工具中发现某个需求的上游存在延期的可能，就可以主动沟通，并准备如果延期的处理方案。主动的沟通可以起到提醒和软压的效果，让他们在一声声的“大佬”中迷失自我，最理想的结果是上游按照时间节点完成了，我们就按照排期正常开发，如果大概率会延期，也能提前暴露出来，我们就可以提前准备好可能的开发节奏调整。到时候，真的延期了，我们就可以反馈产品然后调整我们后续的开发。
# 复盘优化
# 重视数据
一个需求做完上线，并不意味着整个需求流程就结束了。
最基本的要求是能够主动关注数据结果，由数据了解项目现状。
之后就需要培养起数据思维，能够通过数据定位问题并推动解决问题。
再然后就是能从数据中发掘业务的关键问题，并从中分析出如何进行项目优化。
# 后续优化
需求上线后，可能因为当时考虑不周全，或者工期紧张，有很多自己心里清楚的待优化的问题，例如复杂功能的模块和组件的耦合和抽离，公共依赖的维护。
也有可能是复盘的时候，其他成员提出来的各种问题和相关数据，例如测试出来的问题（bug reopen 数量和分类），需求开发过程中的沟通问题，项目进度的问题等。
每次复盘的时候，尽量有意识的提炼高效率和改进质量的解决方案，提高开发和交付效率。
# 团队视角
# 自身能力
对于一个新人来说，学习能力肯定是需要的，能主动的学习领域内的前沿知识，并积极与他人进行技术分享。前沿的技术文档一般都是英文的，所以最起码能够阅读基本的英文文章，以及英文技术文档。
慢慢成长起来后，就需要有技术领导力，在某个技术领域内有深入的研究，能够帮助团队解决疑难问题。
技术不是短板后，往往承担的责任会越来越大，就需要有团队领导力，不管是虚线的还是实线的，都要能赢得他人的信任，成为大家愿意追随的 leader。
# 团队贡献
当从一个新人成长为一个团队的中坚力量后，就需要主动参与到团建建设中。
首先要参与团队的基础设施建设，编写技术文档等，还要能辅导新人和初级工程师，并且能够参与到团队的技术文化培训中去。
到了团队大佬这个级别，就需要能够辅导团队核心人员，主导技术文化建设，组织团队技术培训。另外，对外能学习并借鉴行业经验，主动研究和解决技术领域的难题或者完善技术体系。
还有这个阶段的工程师肯定要有写作能力，能够通过文档和文章的方式清楚传达自己的思路以及思想，并能通过文字或演讲的方式影响团队。