10x 程序员工作法
郑晔
火币网首席架构师,前 ThoughtWorks 首席咨询师 ,TGO 鲲鹏会会员
52720 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 61 讲
思考框架 (1讲)
10x 程序员工作法
15
15
1.0x
00:00/00:00
登录|注册

17 | 程序员也可以“砍”需求吗?

你好,我是郑晔。
我们前面讲的任务分解,主要是在讲开发任务的分解。今天我们换个角度,看看需求的分解。是的,需求也要分解。
有一次,我和一个做开发的同事聊天,他给我讲了他近期的烦恼。
同事:我们现在就是需求太多,开发的人太少,再这么干下去,哪天觉得自己抗不住了,我就拍拍屁股走人。
我:你没尝试着砍砍需求?
同事:怎么没尝试?产品的人都不同意。这批功能他们都说是关键功能。
我:你有没有尝试把需求拆开了再砍呢?
同事:还可以这样?
同事很惊讶,我一点都不意外。我们都是在说需求,但彼此对需求的理解却是大不相同。我先来问个问题,提到需求这个词,你会想到什么呢?
以我们用了好多次的登录为例,如果我问你这个需求是什么,大多数人的第一直觉还是用户名密码登录。
基本上,闯入你脑海的需求描述是主题(epic),在敏捷开发中,有人称之为主用户故事(master story)。
如果你对需求的管理粒度就是主题,那好多事情就没法谈了。比如,时间紧迫的时候,我想砍需求,你问产品经理,我不做登录行不行,你就等着被拒绝吧。
但是,如果你说时间比较紧,我能不能把登录验证码放到后面做,或是邮件地址验证的功能放到后面,这种建议产品经理是可以和你谈的。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《10x 程序员工作法》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(24)

  • 最新
  • 精选
  • 西西弗与卡夫卡
    需求管理中印象最深的是刚进入开发行业时的一段经历。当时要显现某种单据,单据本身还嵌套子单据,原始需求是单据按层次显示,但某变量等于某个值时,某层次的单据就隐藏,但它的再下一层子单据需要显示。解决方案简单可以理解成页面要用递归方式才能正确显示。当时一心想显示自己牛鼻,因为无法用通常的页面模版机制,就自己写工具递归生成页面代码,看起来代码很巧妙,但别人难以维护。后来有段小插曲,若干年后项目移交到另外一个研发中心时,还需要有人专门去讲这段代码,否则接手人很难理解。再说回到之前,开发完后有一次和业务分析员再次聊起,说这个很不好实现但我啃下来了等等,他说那可以不用隐藏,显示空白层也可以,真如果这样实现就简单多了,也好理解多了。事不大,但在职业生涯里印象深刻。需求不光是拆解,更可以讨论后寻找简单解决方案,而不是用自以为牛鼻的代码实现。以更合理的成本实现需求交付价值,这其实是用户故事里Negotiable的意义所在

    作者回复: 多谢大年初二的学习与分享! 程序员的锤子是代码,到处找钉子是直觉。

    3
    24
  • Jerry Wu
    工作中,我也砍过不少的需求,和老师的思路类似,就是拆细需求,一个个地去砍。 比如,上节课的登录注册。我会这样说,如果完全按着这个需求来的话,肯定是完不成的,即使加班加点,最后也是一堆bug。 不如这样,图像验证码前期就够用了,短信验证码放到后一个版本吧?还有前期用户量不多,分布式也就放到下一个版本吧? 这样的话,我们的工作就是XXX,在这个时间内,还是能赶出来的。

    作者回复: 是这个味道。

    11
  • 行与修
    我对需求的理解分两个层面:用户需求和开发需求。在尽可能全面了解客户意图的基础上突出价值,通过开发需求框定范围。以往会形成两份不同的文档,主要是考虑到双方的知识背景不同而有针对性的准备,至于开发需求的误差程度往往得不到客户的有效确认,因为客户不习惯以程序员思维和工作模式去阅读开发文档,常常会给基本上是这样、差不多吧、先这么着看看这样的反馈。所以我在想应该可以用一种更“活泼”的方式去提高双方的沟通效率,如果能够以故事的方式去撰写用户故事,把问题拆分說透,用一个个能让对方身临其境界的场景故事去沟通,而非格式化的冷冰冰的文档去消除双方认知上的不足与分歧,这样除了可测试之外其他方面应该都能兼顾了吧。

    作者回复: 程序员喜欢活泼点的东西 :)

    7
  • 陈斯佳
    愿上帝赐予我能拆分需求的智慧……

    作者回复: 嗯,得练。

    6
  • helloworld
    进行开发之前先把需求理解好,也就是要做什么,然后进行需求的拆分,也就是怎么做,到这时候有些用户故事肯定会由于某些原因做不了,就砍掉,再然后对需求进行排期。所以拆分需求的过程也是梳理项目的过程。

    作者回复: 这个理解的角度很不错!

    5
  • Phoenix
    要看公司,很多公司很多需求是老板提的,老板和产品都是强势方,这种情况是没法砍需求的

    作者回复: 你“认为”没法砍,那就真的没法砍了。

    3
  • Stephen
    “很简单,把它拆分成多个小任务,这样一来,每个小任务都可以在一个迭代中完成了。”这句话没看太懂,拆分完之后需求并没有减少,为什么说小任务可以在一个迭代中完成呢?

    作者回复: 数量没减少,但每个小任务都是一个原子,可以在一定时间内完成。小任务可以跨迭代调度。

    2
    2
  • 一个帅哥
    拆分业务需求有3个好处:砍掉实现成本高及体验不合理及价值不高的小点;方便后面的开发任务的排期;加深对需求的理解

    作者回复: 这个理解很到位!

    2
  • 杨鹏Geek
    砍需求非常不错,扩展我的知识的广度。谢谢!

    作者回复: 思路不受限,能做的办法就很多。

    2
  • 老师,今天的内容,能不能理解为需要先将用户故事切分的足够小,然后以此来做需求合理性、工时评估、需求的降低标准等事情呢?

    作者回复: 先将需求分成用户故事,只有到达可以评估的大小,你才能更好地理解,才能开始做后续的工作。

    2
收起评论
显示
设置
留言
24
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部