前端进阶之路！如何高质量完成产品需求开发？
扫一扫 
扫一扫 
扫一扫 
扫一扫
陈映平：作为一个互联网前端老鸟，这么些年下来，做过的项目也不少。从最初的我的QQ中心、QQ圈子，到后面的QQ群项目、腾讯课堂。从几个人的项目，到近百号人的项目都经历过。 这期间，实现了很多的产品需求，也积累了一些经验。这里稍作总结，希望能给新入行的前端小伙伴们一些参考。 做好需求的关键点要说如何做好一个需求，展开来讲，可以写好几篇文章，这里只挑重点来讲。 最基本的，就是把握好3W：what、when、how。
需求场景假设为了下文不至于太过枯燥，这里进行需求场景的模拟，下文主要围绕这个“需求”，从what、when、how 三个点展开来讲。
备注：此时我们脑海里浮现的应该是下面这张图。
What：做什么？可能有同学要拍案而起了：Are you kidding me？不就加个评论功能吗，我还能不知道该做啥？ 答案很残酷：是的。 根据过往经验，不少前端同学，包括一些前端老司机，做需求的时候，的确不知道自己究竟要做什么。导致这种情况发生的原因有哪些呢？
情况1：产品需求不明确 说到产品需求不明确，前端的兄弟们估计可以坐一起开个诉苦大会，因为实在太常见了。典型的有“拍脑门需求”、“一句话需求”、“贴个图求照抄需求”。 回到之前的例子：给论坛增加个评论功能。 别看连原型图都贴出来了，其实这就是个典型的“需求不明确”。比如：
也许经过一番确认，最终的需求会是下图所示。遇到这种情况，一定要做好需求确认，避免后期无意义的返工和延期。
情况2：未做好需求确认 再次强调一下，无论何时，一定要做好需求确认。再有经验、再负责的产品经理，也几乎不可能提出“100%明确”的需求。 同样，回到上面的需求。 现在已经确认了，需要支持富文本输入、需要展示评论，这就够了吗？其实不够，还有很多需求细节需要进一步确认。比如：
可以、需要确认的内容太多，这里就不赘述。 看到这里，读者朋友们应该明白，为什么前面会说，几乎不存在“100%明确”的需求。 很多需求细节，同时也跟技术实现细节强相关，不能苛求产品经理都考虑到。这种情况下，作为开发者的我们应该主动找出问题，并与产品经理一起将细节敲定下来。
When：完成时间？一个同时有前端、后端参与的需求，精简后的需求生命周期，大概是这样的：
一个需求的实际发布时间，大部分时候取决于实际的开发工作量。如何评估开发工作量呢？最基本的，就是明确“做什么”，这也就是上一小节强调的内容。 这里我们假设：
那么，是不是9月3号下班前需求就可以发布了？ 答案显然是：不能。 要得出一个靠谱的完成时间，至少需要明确以下内容：
最终，需求的完成时间点可能如下：（跟预期的出入很大）
对于需求完成时间的评估，实际情况远比上面说的要更复杂。比如需要考虑节假日、成员休假、多个需求并行开发、需求存在外部依赖项等。以后有机会再展开来讲。 How：如何完成？完成需求容易，如果要高质量完成，那就需要费点功夫了。同样的，只挑一些重要的来讲
明确需求/关键时间点 这块的重要性，再怎么强调也不为过。前面已经讲过了，这里不再赘述。 严控开发、自测、提测质量 作为一名合格的前端工程师，对自己的开发质量负责，这是最基本的要求。 要时常问自己：
严格把控开发、自测、提测质量，这不但是能力，更是一种负责任的态度。如果能做到这点，不单节省大家的时间，还可以让其他人觉得自己比较“靠谱”。 备注：以下截图，是笔者之前一个需求的自测用例（非完整版）。同样是评论功能，自测用例将近50个。
及时暴露风险 风险意识非常重要。在需求完成的过程中，经常会有各种意外的小插曲出现。对于前端同学，常见的有：
上面列举的项，都可能导致需求发布delay，要时刻要保持警惕。一旦出现可能可能导致delay的风险，要及时做好同步，准备好应对措施。 打个比方： 前面说到，小A 评估了3天的开发工作量。等到开发的第2天，发现之前工作量评估少了，至少需要4天才能完成。 这个时候，该怎么办呢？ 相信不少同学都是这样处理的：咬咬牙，加加班，4天的活3天干，实在完不成了再说。 这样处理潜在的问题不小：
更好的处理方式是：及时跟项目组成员同步风险，并落实确认相应解决方案。比如适当调整排期、砍掉部分优先级不高的功能等。 推动解决问题 对于一个职场人能力的评判，“解决问题”的能力，是很重要的一个评估标准。解决问题的能力如何体现呢？ 举个例子，提测过程中，出现了不少bug，对于小A来说，该怎么办呢？这里分两种情况：
第一种情况很简单，自己的坑自己填，抓紧时间改bug，并做好事总结，降低后续需求的bug率。 第二种情况呢？如果小B比较配合，主动快速修复bug，那没什么好说的。但万一不是呢？ 遇到这种情况，小A可能会想：“又不是我的bug，干嘛操那份闲心，需求如果delay的话，那也是小B的问题，跟我无关。” 可能不少同学的想法跟小A一样，这在笔者看来，略显消极，处理方式显得不够“职业化”。 为什么呢？ 同在一个项目组，得要有团队意识、整体意识。需求延期，首先是所有需求相关人的责任，是要一起打板子的。然后，才会对具体的责任人进行问责。 回到前面的场景，小A更好的处理方式是：做好沟通工作，主动推进问题解决。
关注线上质量 这一点非常重要，但又是容易被忽略的一点。需求发布上线，是个重要的里程碑，但并不意味着需求的终点，还得时刻关注以下事项：
只管功能开发，一旦需求上线，立刻做甩手掌柜，同样是缺乏责任意识的表现。试想一下，如果你是团队的老大，你会放心把重要的需求交给一个“甩手掌柜”吗。 写在后面本文中，笔者主要从一个前端工程师的角度出发，谈了一些“高质量完成需求”的经验。里面提到的不少内容，放到其他岗位也是适用的。鉴于篇幅原因，很多细节都是点到为止，并没有深入展开。 方法论再多，最终还是需要人去落实。作为一名前端工程师，加强责任意识，主动承担，勤于总结，做社会主义合格的接班人。 「前端好文合集」
原文地址：imweb.io/ 【木子设计网 原创文章 投稿邮箱：yuan@uisdc.com】 ================关于木子设计网================ 手机扫一扫，阅读下载更方便˃ʍ˂ |
@版权声明
1、本网站文章、帖子等仅代表作者本人的观点，与本站立场无关。
2、转载或引用本网版权所有之内容须注明“转自(或引自)网”字样，并标明本网网址。
3、本站所有图片和资源来源于用户上传和网络，仅用作展示，如有侵权请联系站长！QQ: 13671295。
最新评论
