We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
作为一个互联网前端老鸟,这么些年下来,做过的项目也不少。从最初的我的QQ中心、QQ圈子,到后面的QQ群项目、腾讯课堂。从几个人的项目,到近百号人的项目都经历过。
我的QQ中心
QQ圈子
QQ群项目
腾讯课堂
这期间,实现了很多的产品需求,也积累了一些经验。这里稍作总结,希望能给新入行的前端小伙伴们一些参考。
要说如何做好一个需求,展开来讲,可以写好几篇文章,这里只挑重点来讲。
最基本的,就是把握好3W:what、when、how。
3W
what
when
how
为了下文不至于太过枯燥,这里进行需求场景的模拟,下文主要围绕这个“需求”,从what、when、how 三个点展开来讲。
假设现在有个论坛的项目,产品经理小C提了个需求 “给论坛增加评论功能” 。作为 前端工程师 的小A接到需求后,该如何高质量的完成这个需求。
备注:此时我们脑海里浮现的应该是下面这张图。
可能有同学要拍案而起了:Are you kidding me?不就加个评论功能吗,我还能不知道该做啥?
答案很残酷:是的。
根据过往经验,不少前端同学,包括一些前端老司机,做需求的时候,的确不知道自己究竟要做什么。导致这种情况发生的原因有哪些呢?
说到产品需求不明确,前端的兄弟们估计可以坐一起开个诉苦大会,因为实在太常见了。典型的有“拍脑门需求”、“一句话需求”、“贴个图求照抄需求”。
回到之前的例子:给论坛增加个评论功能。
别看连原型图都贴出来了,其实这就是个典型的“需求不明确”。比如:
也许经过一番确认,最终的需求会是下图所示。遇到这种情况,一定要做好需求确认,避免后期无意义的返工和延期。
再次强调一下,无论何时,一定要做好需求确认。再有经验、再负责的产品经理,也几乎不可能提出“100%明确”的需求。
同样,回到上面的需求。
现在已经确认了,需要支持富文本输入、需要展示评论,这就够了吗?其实不够,还有很多需求细节需要进一步确认。比如:
可以、需要确认的内容太多,这里就不赘述。
看到这里,读者朋友们应该明白,为什么前面会说,几乎不存在“100%明确”的需求。
很多需求细节,同时也跟技术实现细节强相关,不能苛求产品经理都考虑到。这种情况下,作为开发者的我们应该主动找出问题,并与产品经理一起将细节敲定下来。
一个同时有前端、后端参与的需求,精简后的需求生命周期,大概是这样的:
需求提出-->开发-->联调-->提交测试->需求发布
一个需求的实际发布时间,大部分时候取决于实际的开发工作量。如何评估开发工作量呢?最基本的,就是明确“做什么”,这也就是上一小节强调的内容。
这里我们假设:
3
9月1号
那么,是不是9月3号下班前需求就可以发布了?
9月3号
答案显然是:不能。
要得出一个靠谱的完成时间,至少需要明确以下内容:
最终,需求的完成时间点可能如下:(跟预期的出入很大)
对于需求完成时间的评估,实际情况远比上面说的要更复杂。比如需要考虑节假日、成员休假、多个需求并行开发、需求存在外部依赖项等。以后有机会再展开来讲。
完成需求容易,如果要高质量完成,那就需要费点功夫了。同样的,只挑一些重要的来讲
这块的重要性,再怎么强调也不为过。前面已经讲过了,这里不再赘述。
作为一名合格的前端工程师,对自己的开发质量负责,这是最基本的要求。
要时常问自己:
严格把控开发、自测、提测质量,这不但是能力,更是一种负责任的态度。如果能做到这点,不单节省大家的时间,还可以让其他人觉得自己比较“靠谱”。
备注:以下截图,是笔者之前一个需求的自测用例(非完整版)。同样是评论功能,自测用例将近50个。
风险意识非常重要。在需求完成的过程中,经常会有各种意外的小插曲出现。对于前端同学,常见的有:
上面列举的项,都可能导致需求发布delay,要时刻要保持警惕。一旦出现可能可能导致delay的风险,要及时做好同步,准备好应对措施。
打个比方:
前面说到,小A 评估了3天的开发工作量。等到开发的第2天,发现之前工作量评估少了,至少需要4天才能完成。
这个时候,该怎么办呢?
相信不少同学都是这样处理的:咬咬牙,加加班,4天的活3天干,实在完不成了再说。
这样处理潜在的问题不小:
更好的处理方式是:及时跟项目组成员同步风险,并落实确认相应解决方案。比如适当调整排期、砍掉部分优先级不高的功能等。
对于一个职场人能力的评判,“解决问题”的能力,是很重要的一个评估标准。解决问题的能力如何体现呢?
举个例子,提测过程中,出现了不少bug,对于小A来说,该怎么办呢?这里分两种情况:
第一种情况很简单,自己的坑自己填,抓紧时间改bug,并做好事总结,降低后续需求的bug率。
第二种情况呢?如果小B比较配合,主动快速修复bug,那没什么好说的。但万一不是呢?
遇到这种情况,小A可能会想:“又不是我的bug,干嘛操那份闲心,需求如果delay的话,那也是小B的问题,跟我无关。”
可能不少同学的想法跟小A一样,这在笔者看来,略显消极,处理方式显得不够“职业化”。
为什么呢?
同在一个项目组,得要有团队意识、整体意识。需求延期,首先是所有需求相关人的责任,是要一起打板子的。然后,才会对具体的责任人进行问责。
回到前面的场景,小A更好的处理方式是:做好沟通工作,主动推进问题解决。
这一点非常重要,但又是容易被忽略的一点。需求发布上线,是个重要的里程碑,但并不意味着需求的终点,还得时刻关注以下事项:
只管功能开发,一旦需求上线,立刻做甩手掌柜,同样是缺乏责任意识的表现。试想一下,如果你是团队的老大,你会放心把重要的需求交给一个“甩手掌柜”吗。
本文中,笔者主要从一个前端工程师的角度出发,谈了一些“高质量完成需求”的经验。里面提到的不少内容,放到其他岗位也是适用的。鉴于篇幅原因,很多细节都是点到为止,并没有深入展开。
方法论再多,最终还是需要人去落实。作为一名前端工程师,加强责任意识,主动承担,勤于总结,做社会主义合格的接班人。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
写在前面
作为一个互联网前端老鸟,这么些年下来,做过的项目也不少。从最初的
我的QQ中心
、QQ圈子
,到后面的QQ群项目
、腾讯课堂
。从几个人的项目,到近百号人的项目都经历过。这期间,实现了很多的产品需求,也积累了一些经验。这里稍作总结,希望能给新入行的前端小伙伴们一些参考。
做好需求的关键点
要说如何做好一个需求,展开来讲,可以写好几篇文章,这里只挑重点来讲。
最基本的,就是把握好
3W
:what、when、how。what
:做什么?when
:完成时间?how
:如何完成?需求场景假设
为了下文不至于太过枯燥,这里进行需求场景的模拟,下文主要围绕这个“需求”,从what、when、how 三个点展开来讲。
备注:此时我们脑海里浮现的应该是下面这张图。
What:做什么?
可能有同学要拍案而起了:Are you kidding me?不就加个评论功能吗,我还能不知道该做啥?
答案很残酷:是的。
根据过往经验,不少前端同学,包括一些前端老司机,做需求的时候,的确不知道自己究竟要做什么。导致这种情况发生的原因有哪些呢?
情况1:产品需求不明确
说到产品需求不明确,前端的兄弟们估计可以坐一起开个诉苦大会,因为实在太常见了。典型的有“拍脑门需求”、“一句话需求”、“贴个图求照抄需求”。
回到之前的例子:给论坛增加个评论功能。
别看连原型图都贴出来了,其实这就是个典型的“需求不明确”。比如:
也许经过一番确认,最终的需求会是下图所示。遇到这种情况,一定要做好需求确认,避免后期无意义的返工和延期。
情况2:未做好需求确认
再次强调一下,无论何时,一定要做好需求确认。再有经验、再负责的产品经理,也几乎不可能提出“100%明确”的需求。
同样,回到上面的需求。
现在已经确认了,需要支持富文本输入、需要展示评论,这就够了吗?其实不够,还有很多需求细节需要进一步确认。比如:
可以、需要确认的内容太多,这里就不赘述。
看到这里,读者朋友们应该明白,为什么前面会说,几乎不存在“100%明确”的需求。
很多需求细节,同时也跟技术实现细节强相关,不能苛求产品经理都考虑到。这种情况下,作为开发者的我们应该主动找出问题,并与产品经理一起将细节敲定下来。
When:完成时间?
一个同时有前端、后端参与的需求,精简后的需求生命周期,大概是这样的:
一个需求的实际发布时间,大部分时候取决于实际的开发工作量。如何评估开发工作量呢?最基本的,就是明确“做什么”,这也就是上一小节强调的内容。
这里我们假设:
3
天,小B的开发工作量是3
天。9月1号
投入开发那么,是不是
9月3号
下班前需求就可以发布了?答案显然是:不能。
要得出一个靠谱的完成时间,至少需要明确以下内容:
最终,需求的完成时间点可能如下:(跟预期的出入很大)
对于需求完成时间的评估,实际情况远比上面说的要更复杂。比如需要考虑节假日、成员休假、多个需求并行开发、需求存在外部依赖项等。以后有机会再展开来讲。
How:如何完成?
完成需求容易,如果要高质量完成,那就需要费点功夫了。同样的,只挑一些重要的来讲
明确需求/关键时间点
这块的重要性,再怎么强调也不为过。前面已经讲过了,这里不再赘述。
严控开发、自测、提测质量
要时常问自己:
严格把控开发、自测、提测质量,这不但是能力,更是一种负责任的态度。如果能做到这点,不单节省大家的时间,还可以让其他人觉得自己比较“靠谱”。
备注:以下截图,是笔者之前一个需求的自测用例(非完整版)。同样是评论功能,自测用例将近50个。
及时暴露风险
风险意识非常重要。在需求完成的过程中,经常会有各种意外的小插曲出现。对于前端同学,常见的有:
上面列举的项,都可能导致需求发布delay,要时刻要保持警惕。一旦出现可能可能导致delay的风险,要及时做好同步,准备好应对措施。
打个比方:
前面说到,小A 评估了3天的开发工作量。等到开发的第2天,发现之前工作量评估少了,至少需要4天才能完成。
这个时候,该怎么办呢?
相信不少同学都是这样处理的:咬咬牙,加加班,4天的活3天干,实在完不成了再说。
这样处理潜在的问题不小:
更好的处理方式是:及时跟项目组成员同步风险,并落实确认相应解决方案。比如适当调整排期、砍掉部分优先级不高的功能等。
推动解决问题
对于一个职场人能力的评判,“解决问题”的能力,是很重要的一个评估标准。解决问题的能力如何体现呢?
举个例子,提测过程中,出现了不少bug,对于小A来说,该怎么办呢?这里分两种情况:
第一种情况很简单,自己的坑自己填,抓紧时间改bug,并做好事总结,降低后续需求的bug率。
第二种情况呢?如果小B比较配合,主动快速修复bug,那没什么好说的。但万一不是呢?
遇到这种情况,小A可能会想:“又不是我的bug,干嘛操那份闲心,需求如果delay的话,那也是小B的问题,跟我无关。”
可能不少同学的想法跟小A一样,这在笔者看来,略显消极,处理方式显得不够“职业化”。
为什么呢?
同在一个项目组,得要有团队意识、整体意识。需求延期,首先是所有需求相关人的责任,是要一起打板子的。然后,才会对具体的责任人进行问责。
回到前面的场景,小A更好的处理方式是:做好沟通工作,主动推进问题解决。
关注线上质量
这一点非常重要,但又是容易被忽略的一点。需求发布上线,是个重要的里程碑,但并不意味着需求的终点,还得时刻关注以下事项:
只管功能开发,一旦需求上线,立刻做甩手掌柜,同样是缺乏责任意识的表现。试想一下,如果你是团队的老大,你会放心把重要的需求交给一个“甩手掌柜”吗。
写在后面
本文中,笔者主要从一个前端工程师的角度出发,谈了一些“高质量完成需求”的经验。里面提到的不少内容,放到其他岗位也是适用的。鉴于篇幅原因,很多细节都是点到为止,并没有深入展开。
方法论再多,最终还是需要人去落实。作为一名前端工程师,加强责任意识,主动承担,勤于总结,做社会主义合格的接班人。
The text was updated successfully, but these errors were encountered: