前端进阶之路：如何高质量完成产品需求开发

写在前面

做为一个互联网前端老鸟，这么些年下来，作过的项目也很多。从最初的个人QQ中心、QQ圈子，到后面的QQ群项目、腾讯课堂。从几我的的项目，到近百号人的项目都经历过。

这期间，实现了不少的产品需求，也积累了一些经验。这里稍做总结，但愿能给新入行的前端小伙伴们一些参考。

作好需求的关键点

要说如何作好一个需求，展开来说，能够写好几篇文章，这里只挑重点来说。

最基本的，就是把握好3W：what、when、how。

• what：作什么？

• when：完成时间？

• how：如何完成？

需求场景假设

为了下文不至于太过枯燥，这里进行需求场景的模拟，下文主要围绕这个“需求”，从what、when、how 三个点展开来说。

假设如今有个论坛的项目，产品经理小C提了个需求 “给论坛增长评论功能” 。做为 前端工程师 的小A接到需求后，该如何高质量的完成这个需求。

• 项目名称：兴趣论坛。

• 项目组主要成员：前端工程师小A，后台工程师小B，产品经理小C。

• 产品需求：给论坛增长评论功能。

备注：此时咱们脑海里浮现的应该是下面这张图。

What：作什么？

可能有同窗要拍案而起了：Are you kidding me？不就加个评论功能吗，我还能不知道该作啥？

答案很残酷：是的。

根据过往经验，很多前端同窗，包括一些前端老司机，作需求的时候，的确不知道本身究竟要作什么。致使这种状况发生的缘由有哪些呢？

1. 产品经理：提的需求不明确。

2. 前端工程师：没作好需求确认。

状况1：产品需求不明确

说到产品需求不明确，前端的兄弟们估计能够坐一块儿开个诉苦大会，由于实在太常见了。典型的有“拍脑门需求”、“一句话需求”、“贴个图求照抄需求”。

回到以前的例子：给论坛增长个评论功能。

别看连原型图都贴出来了，其实这就是个典型的“需求不明确”。好比：

• 是否须要支持富文本输入？

• 是否须要支持社会化分享？

• 发表评论后，评论怎么展现？

• 。。。

也许通过一番确认，最终的需求会是下图所示。遇到这种状况，必定要作好需求确认，避免后期无心义的返工和延期。

状况2：未作好需求确认

再次强调一下，不管什么时候，必定要作好需求确认。再有经验、再负责的产品经理，也几乎不可能提出“100%明确”的需求。

一样，回到上面的需求。

如今已经确认了，须要支持富文本输入、须要展现评论，这就够了吗？其实不够，还有不少需求细节须要进一步确认。好比：

• 评论最大支持输入多少个字？（很是重要，关乎后台存储方案的设计）

• 1个中文算1个字，多少个英文字母算1个字？（产品语言、技术语言 之间的沟通转换）

• 输入内容过长，如何进行错误提示？（交互细节）

• 输入内容过长，是否容许提交评论？如容许，是对评论内容进行截断后提交？（容错）

• 用户未输入内容的状况下，评论框内默认提示文案是什么？（交互细节）

• 。。。

能够、须要确认的内容太多，这里就不赘述。

看到这里，读者朋友们应该明白，为何前面会说，几乎不存在“100%明确”的需求。

不少需求细节，同时也跟技术实现细节强相关，不能苛求产品经理都考虑到。这种状况下，做为开发者的咱们应该主动找出问题，并与产品经理一块儿将细节敲定下来。

When：完成时间？

一个同时有前端、后端参与的需求，精简后的需求生命周期，大概是这样的：

需求提出-->开发-->联调-->提交测试->需求发布

一个需求的实际发布时间，大部分时候取决于实际的开发工做量。如何评估开发工做量呢？最基本的，就是明确“作什么”，这也就是上一小节强调的内容。

这里咱们假设：

1. 需求已经明确，小A的开发工做量是3天，小B的开发工做量是3天。

2. 假设小A 9月1号投入开发

那么，是否是9月3号下班前需求就能够发布了？

答案显然是：不能。

要得出一个靠谱的完成时间，至少须要明确如下内容：

• 前端、后台 各自的工做量。

• 前端、后台 投入研发的时间点。

• 前端、后台 联调的工做量、时间点。

• 需求提交测试的时间。

• 需求测试的工做量。

最终，需求的完成时间点可能以下：（跟预期的出入很大）

对于需求完成时间的评估，实际状况远比上面说的要更复杂。好比须要考虑节假日、成员休假、多个需求并行开发、需求存在外部依赖项等。之后有机会再展开来说。

How：如何完成？

完成需求容易，若是要高质量完成，那就须要费点功夫了。一样的，只挑一些重要的来说

• 明确需求、关键时间点

• 严控开发、自测、提测质量

• 及时暴露风险

• 推进解决问题

• 关注线上质量

明确需求/关键时间点

这块的重要性，再怎么强调也不为过。前面已经讲过了，这里再也不赘述。

严控开发、自测、提测质量

做为一名合格的前端工程师，对本身的开发质量负责，这是最基本的要求。

要时常问本身：

• 开发：是否严格按照需求文档完成功能的开发。

• 联调：在与后台同窗联调前，是否已经对照测试用例，对本身的模块进行了严格的自测。

• 提测：提测前，是否已自测、联调经过；测试正式介入前，产品是否提早部署到测试环境，并进行初步的验证。

严格把控开发、自测、提测质量，这不可是能力，更是一种负责任的态度。若是能作到这点，不单节省你们的时间，还可让其余人以为本身比较“靠谱”。

备注：如下截图，是笔者以前一个需求的自测用例（非完整版）。一样是评论功能，自测用例将近50个。

及时暴露风险

风险意识很是重要。在需求完成的过程当中，常常会有各类意外的小插曲出现。对于前端同窗，常见的有：

• 视觉稿/交互稿未按时提供。

• 需求变动。

• 工做量评估不足。

• 后台接口未按时、按质完成。

• bug有好多，但修改不及时。

上面列举的项，均可能致使需求发布delay，要时刻要保持警戒。一旦出现可能可能致使delay的风险，要及时作好同步，准备好应对措施。

打个比方：

前面说到，小A 评估了3天的开发工做量。等到开发的第2天，发现以前工做量评估少了，至少须要4天才能完成。

这个时候，该怎么办呢？

相信很多同窗都是这样处理的：咬咬牙，加加班，4天的活3天干，实在完不成了再说。

这样处理潜在的问题不小：

1. 给本身增长了太重的负担。

2. 没能让问题及早的暴露解决。

3. 可能打乱项目的总体节奏。

更好的处理方式是：及时跟项目组成员同步风险，并落实确认相应解决方案。好比适当调整排期、砍掉部分优先级不高的功能等。

推进解决问题

对于一个职场人能力的评判，“解决问题”的能力，是很重要的一个评估标准。解决问题的能力如何体现呢？

举个例子，提测过程当中，出现了很多bug，对于小A来讲，该怎么办呢？这里分两种状况：

• bug主要是小A的。

• bug主要是小B的。

第一种状况很简单，本身的坑本身填，抓紧时间改bug，并作好事总结，下降后续需求的bug率。

第二种状况呢？若是小B比较配合，主动快速修复bug，那没什么好说的。但万一不是呢？

遇到这种状况，小A可能会想：“又不是个人bug，干吗操那份闲心，需求若是delay的话，那也是小B的问题，跟我无关。”

可能很多同窗的想法跟小A同样，这在笔者看来，略显消极，处理方式显得不够“职业化”。

为何呢？

同在一个项目组，得要有团队意识、总体意识。需求延期，首先是全部需求相关人的责任，是要一块儿打板子的。而后，才会对具体的责任人进行问责。

回到前面的场景，小A更好的处理方式是：作好沟通工做，主动推动问题解决。

1. 了解小B没有及时改bug的缘由：有可能太忙、bug很差改、没有意识到那是本身的bug。

2. 如可能，提供必要帮助：好比跟项目经理申请，这段时间小B集中精力改bug，暂不开发新需求

3. 风险同步：若是小B真的不称职，尽快知会项目负责人，对小B进行批评教育，实在不行就换人。

关注线上质量

这一点很是重要，但又是容易被忽略的一点。需求发布上线，是个重要的里程碑，但并不意味着需求的终点，还得时刻关注如下事项：

• 功能是否正常运行？

• 各项指标是否正常？好比产品上报数据、性能监控数据、错误监控数据等。

• 有哪些能够优化的点？优先级多高？

• 。。。

只管功能开发，一旦需求上线，马上作甩手掌柜，一样是缺少责任意识的表现。试想一下，若是你是团队的老大，你会放心把重要的需求交给一个“甩手掌柜”吗。

写在后面

本文中，笔者主要从一个前端工程师的角度出发，谈了一些“高质量完成需求”的经验。里面提到的很多内容，放到其余岗位也是适用的。鉴于篇幅缘由，不少细节都是点到为止，并无深刻展开。

方法论再多，最终仍是须要人去落实。做为一名前端工程师，增强责任意识，主动承担，勤于总结，作社会主义合格的接班人。