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进行批评教育,实在不行就换人。
关注线上质量
这一点非常重要,但又是容易被忽略的一点。需求发布上线,是个重要的里程碑,但并不意味着需求的终点,还得时刻关注以下事项:
· 功能是否正常运行?
· 各项指标是否正常?比如产品上报数据、性能监控数据、错误监控数据等。
· 有哪些可以优化的点?优先级多高?
。。。
只管功能开发,一旦需求上线,立刻做甩手掌柜,同样是缺乏责任意识的表现。试想一下,如果你是团队的老大,你会放心把重要的需求交给一个“甩手掌柜”吗。
写在后面
本文中,笔者主要从一个前端工程师的角度出发,谈了一些“高质量完成需求”的经验。里面提到的不少内容,放到其他岗位也是适用的。鉴于篇幅原因,很多细节都是点到为止,并没有深入展开。
方法论再多,最终还是需要人去落实。作为一名前端工程师,加强责任意识,主动承担,勤于总结,做社会主义合格的接班人。