接到需求任务,我们就开干吗?

你好,我是张飞洪,本文共2094字,预估10分钟读完。

冲突是怎么产生的?

我们见过很多类似的场景:

小飞:流程引擎做得咋样了?(和颜悦色)

小洪:做完了,我给你演示一下。(心情愉悦)

小飞演示了一遍自己做的功能,小洪看上去很满意。

小飞:不错。不过,怎么没有支持流程审核?(质疑)

小洪:为什么要做这个?(质疑)

小飞:这不就是流程的一部分吗?(不舒服)

小洪:哪里规定要做流程审核了?(不舒适)

小飞:现在做流程哪有不用审核的?(火药味)

这个时候如果双方都不能很好地控制自己的情绪,那接下来一场体力的较量可能就一触即发了。

分歧

为什么会出现这种分歧呢?其中一个重要的原因是,开始实现这个需求之前,任务双方都没有清晰地定义好边界,没能把需求描述清楚。

需求规格

不知道大家接受的需求说明文档都长成什么样,有没有固定规格。我这里先罗列我见过的需求文档大纲:

需求大纲

我们再看看部分截图:

功能描述

大概总结一下,有几个核心内容是我们重点要关注的:

业务流程图(数据流图)

界面原型图(静态和动态)

原型图功能描述

有些文档还会提供用户故事或者用例图来辅助说明,总之对开发者来说,保证核心内容的基础上,需求越规范当然是越好的,我们最不希望看到的是模棱两可、碎片化的需求清单,因为,通常这种功能列表只是一些简单的描述,你并不能看到全局。

用户故事

除了关注流程、原型和描述之外,用户故事(User Story)是我喜欢的一种方式。它是站在用户的角度来描述了一个用户希望得到的功能,关注用户在系统中完成一个动作需要经过怎样的路径。既然它是“故事”,它就需要一个完整的场景。

用户故事

相比较需求列表清单,不知道你对用户故事的感受是什么?列表是一种碎片化的内容,内部逻辑和全景图都是不清楚的;而用户故事有角色,有流程,有因果链,逻辑性更加强烈。

在前面的例子中,小张和小王之所以会对需求是否完成产生分歧,是因为大家对于需求完成的定义不同。

用户故事采用的是以终为始的交付方式,用户故事的核心是验收标准,它清晰地定义出产品的边界。

验收标准非常重要的一环是异常流程的描述。大部分程序员都擅长解决正常流程,而异常流程则是最容易忽略的,也是产生扯皮的关键环节。既然容易扯皮,我们就在一开始把它定义清楚。怎么才算做完需求呢?验收标准说了算,达不成就不算任务完成。而且验收标准可以由开发、测试、产品共同使用而不会产生歧义。

如果你的团队采用用户故事的格式进行需求描述固然好,如果不能,在功能列表中,补充验收标准也会极大程度地改善双方协作的效率。

用户故事

角色定位

也许你会感慨需求规格和用户故事很好,但是“臣妾做不到啊,我们是小公司”。首先我们要明确自己的定位,我是一个产品经理还是开发人员,还是无所不能的全栈人员,不要做越界侵权的事情。

产品和开发是两种不同的角色,但是对一些小公司可能分得不是那么清楚,开发会兼职产品经理的角色,产品经理也会兼职开发。对一些大公司来说,产品经理也会有技术背景。总之,这两个角色分分合合,统一于软件的生命周期。

用户故事的验收标准主要是业务上的,程序员最后不要越界,徒增浪费,我们的发挥空间应该是在技术实现上。

然而,在现实情况中,很多团队做不到这种程度。

假如你们团队没有产品经理,用户故事验收标准来写?

没办法,答案只能是你自己。虽然你名义上是程序员,但当拿到一个需求的时候,你要做的事不是立即动手写代码,而是扮演产品经理的角色,分析需求,圈定业务范围。相信我,事前分析绝对比你拿一个写好的系统给老板,而他却告诉你这不是他想要的,好太多了。

另外我想提醒你注意的是,扮演不同角色的时候,我们的思考模式是不同的。产品思考的是做什么(方向),开发思考的是怎么做(手段)。

另外,如果你要兼顾两个角色,建议你先扮演好产品经理,多花点时间把验收标准制定好,再回到开发人员的角色上去写代码。毕竟,最容易维护的代码是还没写出来的代码。

角色定位

总结

最后,我们总结一下:接到需求立刻开工是不成熟的表现,因为你可能会南辕北辙,交付的产品是有歧义的,最后导致的结果是扯皮和争吵,白白浪费资源。

在向目标行进的过程,我们要先想清楚自己想做什么,先明确需求规格和用户故事,特别是验收标准,最后还要知道自己的角色分工和定位,避免该越界的不越界,不该越界的乱越界的混乱。

如果今天的内容你只能记住一句话,请记住:在做任何需求或任务之前,先定好验收标准。最后,我想请你回想一下,在实际工作中,你接到需求后是如何开展工作的,或者你希望的需求规范应该长什么样?欢迎在留言区写下你的想法。

感谢阅读,我是张飞洪,如果你觉得这篇文章对你有帮助的话,也欢迎分享给你的朋友。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,254评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,875评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,682评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,896评论 1 285
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,015评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,152评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,208评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,962评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,388评论 1 304
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,700评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,867评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,551评论 4 335
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,186评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,901评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,142评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,689评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,757评论 2 351

推荐阅读更多精彩内容

  • 在辅导团队实践敏捷的过程中,用户故事的使用经常是面临的第一个问题,也是一个很难解决的棘手问题,究其原因就是很多团队...
    话痨张阅读 1,242评论 0 1
  • 讲一个小王跟小李的故事,小李是程序员,小王是产品经理。当小李接到一个新的需求,让他开发一个单点登录。经过几天的奋战...
    七夜98阅读 1,713评论 1 0
  • 不少开发同学应该在工作中都曾面临过需求模糊这个令人头疼的问题。产品经理在口吐莲花地讲述需求,你却听得一脸懵,...
    10世界阅读 572评论 0 1
  • 第十二章 验收标准和理由 我们这里所说的验收意味着:解决方案完全满足或符合需求。也就是说,解决方案准确的实现了需求...
    颜小婧阅读 937评论 2 11
  • 本文为学习笔记 目录 基本概念与软件需求概述 定义 通俗定义 待开发软件产品的目标用户对该产品的功能,性能,设计约...
    妮儿_smile阅读 2,357评论 1 0