接到需求任务,我们需要做哪些事情?
你好,我是张飞洪,本文共2094字,预估10分钟读完。
冲突是怎么产生的?
我们见过很多类似的场景:
小飞:流程引擎做得咋样了?(和颜悦色)
小洪:做完了,我给你演示一下。(心情愉悦)
小飞演示了一遍自己做的功能,小洪看上去很满意。
小飞:不错。不过,怎么没有支持流程审核?(质疑)
小洪:为什么要做这个?(质疑)
小飞:这不就是流程的一部分吗?(不舒服)
小洪:哪里规定要做流程审核了?(不舒适)
小飞:现在做流程哪有不用审核的?(火药味)
这个时候如果双方都不能很好地控制自己的情绪,那接下来一场体力的较量可能就一触即发了。
分歧
为什么会出现这种分歧呢?其中一个重要的原因是,开始实现这个需求之前,任务双方都没有清晰地定义好边界,没能把需求描述清楚。
需求规格
不知道大家接受的需求说明文档都长成什么样,有没有固定规格。我这里先罗列我见过的需求文档大纲:
需求大纲
我们再看看部分截图:
功能描述
大概总结一下,有几个核心内容是我们重点要关注的:
-
业务流程图(数据流图)
-
界面原型图(静态和动态)
-
原型图功能描述
有些文档还会提供用户故事或者用例图来辅助说明,总之对开发者来说,保证核心内容的基础上,需求越规范当然是越好的,我们最不希望看到的是模棱两可、碎片化的需求清单,因为,通常这种功能列表只是一些简单的描述,你并不能看到全局。
用户故事
除了关注流程、原型和描述之外,用户故事(User Story)是我喜欢的一种方式。它是站在用户的角度来描述了一个用户希望得到的功能,关注用户在系统中完成一个动作需要经过怎样的路径。既然它是“故事”,它就需要一个完整的场景。
相比较需求列表清单,不知道你对用户故事的感受是什么?列表是一种碎片化的内容,内部逻辑和全景图都是不清楚的;而用户故事有角色,有流程,有因果链,逻辑性更加强烈。
在前面的例子中,小张和小王之所以会对需求是否完成产生分歧,是因为大家对于需求完成的定义不同。
用户故事采用的是以终为始的交付方式,用户故事的核心是验收标准,它清晰地定义出产品的边界。
验收标准非常重要的一环是异常流程的描述。大部分程序员都擅长解决正常流程,而异常流程则是最容易忽略的,也是产生扯皮的关键环节。既然容易扯皮,我们就在一开始把它定义清楚。怎么才算做完需求呢?验收标准说了算,达不成就不算任务完成。而且验收标准可以由开发、测试、产品共同使用而不会产生歧义。
如果你的团队采用用户故事的格式进行需求描述固然好,如果不能,在功能列表中,补充验收标准也会极大程度地改善双方协作的效率。
用户故事
角色定位
也许你会感慨需求规格和用户故事很好,但是“臣妾做不到啊,我们是小公司”。首先我们要明确自己的定位,我是一个产品经理还是开发人员,还是无所不能的全栈人员,不要做越界侵权的事情。
产品和开发是两种不同的角色,但是对一些小公司可能分得不是那么清楚,开发会兼职产品经理的角色,产品经理也会兼职开发。对一些大公司来说,产品经理也会有技术背景。总之,这两个角色分分合合,统一于软件的生命周期。
用户故事的验收标准主要是业务上的,程序员最后不要越界,徒增浪费,我们的发挥空间应该是在技术实现上。
然而,在现实情况中,很多团队做不到这种程度。
假如你们团队没有产品经理,用户故事验收标准来写?
没办法,答案只能是你自己。虽然你名义上是程序员,但当拿到一个需求的时候,你要做的事不是立即动手写代码,而是扮演产品经理的角色,分析需求,圈定业务范围。相信我,事前分析绝对比你拿一个写好的系统给老板,而他却告诉你这不是他想要的,好太多了。
另外我想提醒你注意的是,扮演不同角色的时候,我们的思考模式是不同的。产品思考的是做什么(方向),开发思考的是怎么做(手段)。
另外,如果你要兼顾两个角色,建议你先扮演好产品经理,多花点时间把验收标准制定好,再回到开发人员的角色上去写代码。毕竟,最容易维护的代码是还没写出来的代码。
角色定位
总结
最后,我们总结一下:接到需求立刻开工是不成熟的表现,因为你可能会南辕北辙,交付的产品是有歧义的,最后导致的结果是扯皮和争吵,白白浪费资源。
在向目标行进的过程,我们要先想清楚自己想做什么,先明确需求规格和用户故事,特别是验收标准,最后还要知道自己的角色分工和定位,避免该越界的不越界,不该越界的乱越界的混乱。
如果今天的内容你只能记住一句话,请记住:在做任何需求或任务之前,先定好验收标准。最后,我想请你回想一下,在实际工作中,你接到需求后是如何开展工作的,或者你希望的需求规范应该长什么样?欢迎在留言区写下你的想法。
感谢阅读,我是张飞洪,如果你觉得这篇文章对你有帮助的话,也欢迎分享给你的朋友。