写点什么

接到需求,你要先做哪件事?

用户头像
熊斌
关注
发布于: 2021 年 01 月 22 日
接到需求,你要先做哪件事?

郑晔老师在《10x程序员工作法》中给了一个例子,程序员小李接到一个单点登录功能的需求,小李经过几天的奋战写完了代码。


在给产品经理小王演示时,小王对整体很满意,就是觉得不支持验证码不太符合常规设计。但是小李觉得这个需求里面没有提,就没做......


小李觉得很辛苦,小王觉得没做完。我平时接一些私活儿时,也会处于这种局面,根据前期讨论的需求,我很快就做完了,然后拿给用户演示,发现这不是结束,而是刚刚开始。因为用户在一开始并不能把自己的实际需求想得很明白。

描述需求的方式


不同需求的描述方式,可能会影响程序员对需求的理解。

信息传递会衰减,如何传递,直接决定了衰减的比例。

基于功能列表的描述方式


我们公司以及在平时私活儿中,开发模式都是基于功能列表的。

公司项目中负责需求的同事,先会跟用户讨论需求,整理出需求文档,项目经理根据需求文档中的功能点拆分开发任务,开发领到任务开始写代码;私活儿中,我自己扮演了需求与开发兼项目经理的三个角色,干的事情都差不多。功能列表其实只是一些简单的描述,并不能看到全局。这种功能列表式的需求描述方式,将一个完整的需求敲成了碎片,只有所有功能完成时,才是破镜重圆的时刻。


开发过程中,大多数人都无法看到完整的图景,项目会在最后遇到很多意料之外的事情,让大家都手忙脚乱。我们现在公司的项目就出现了这种情况。


如果时多个组协同工作时,这种基于列表的需求描述方式的弊端更加明显。每个组都会按照自己的理解排列开发任务。当你所在的组完成了某功能的开发任务时,却上不了线,因为还要依赖别的组。像之前我做过的一个项目里面 n 个子项目,每个子项目之间会互相依赖,如果还按照基于列表的需求拆分,工作安排,兼职要令人抓狂啊。

“用户故事”需求描述


它需要一个完整的场景,将用户的需求将出来。


一个完整的用户故事包含以下几部分:

  • 标题


  • 概述

一般的描述格式:As a(Role),I want to(Activity),so that(Business Value)


  • 详述


  • 验收标准

这里会描述系统的正常操作流程,以及各种异常流程系统的响应。大多数情况,我们都是流程跑通,结果发现要么是正常操作流程不完善,要么异常流程处理不到位。就是因为在写代码之前没考虑清楚。在这一环节给出了本次需求最基本的测试用例,保证了开发人员完成需求最进本的质量。


如果在基于列表的描述方式中,加入验收标准的描述,也会提高协作效率。

关于角色


拿到一个需求后,先分析清楚比蒙头就做好太多。分析需求时,你需要学会扮演各个角色,比如假设自己是用户、是产品经理、是测试,这样你才能分析得更透彻。做出来的东西质量会更高。


发布于: 2021 年 01 月 22 日阅读数: 373
用户头像

熊斌

关注

心中有月亮,手中有六便士 2017.12.01 加入

程序员|得到大学6期学员|极客大学算法训练营5期学员|宅男 公众号:大熊出没

评论 (2 条评论)

发布
用户头像
你们没有需求内外审或者宣讲阶段吗
2021 年 01 月 26 日 10:42
回复
该评论已删除
2021 年 01 月 26 日 10:46
回复
你好 有需求评审,只是在项目初期会有。到后来就没有了,仅限于团队内部小范围讨论一下实施方案

2021 年 01 月 26 日 10:49
回复
没有更多了
接到需求,你要先做哪件事?