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

精选留言(11)

• 

  西西弗与卡夫卡

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

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

  2019-02-06

  

   9
• 

  毅

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

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

  2019-02-06

  

   3
• 

  陈斯佳

  愿上帝赐予我能拆分需求的智慧……

  2019-07-31

  

   2
• 

  helloworld

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

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

  2019-03-01

  

   2
• 

  稳

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

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

  2019-02-06

  

   2
• 

  Phoenix

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

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

  2019-02-15

  

   1
• 

  WL

  可衡量才可以讨论，跟老师学习受益匪浅

  2019-02-12

  

   1
• 

  丁丁历险记

  1 作者观点。绝大多数问题都是由于分解的粒度太大造成的，大块的需求不能谈取舍，但小的就比较合理。
  读后思考，（yy 个例子，和人讲把头发剃光是不好谈的，但是谈谈把哪里剃一下，可以换来xxx 这个是好谈的 ）
  2 INVEST 介绍。
  Independent，独立的
  Negotiable，可协商的
  Valuable，有价值的
  Estimatable，可估算的
  Small，小
  Testable，可测试的
  读后思考，天啊，这么多的单词，这么详细的解释（罗里吧嗦）， 我是记不住的，自己yy 个故事去记忆吧。（为了方便，直接借用作者昨天的例子来扯需求好了）
  google 整理术告诉我们，长期的记忆是一个encoding 过程，使用故事是一个非常好的套路（作者也同样说了这点，只是没站在大脑认知学的维度来谈而已）
  step1：在漫长的等待后，产品的用户登录登出需求出来了（出来了，出来了....）。 做为开发，我第一时间对他的需求做了梳理含以下内容, 基于(Independent 独立性的)分解如下 并且分解得很(small 小)
  手机号密码登陆（判断 （不能为空，手机号格式，密码长度校验））
  记住密码
  第三方登录（微信扫码，微博登录，qq 登录）
  登录时长为2小时
  。。。。。
  登出
  step2 : 我拉来了产品,协商。（便于简化 ，这里只谈记住密码，和第三方登录） 这写说明了，分解的粒度是（Negotiable 可协商的）
  2.1记住密码这事，其价值是用来方便用户的（Valuable 价值判断），但现在，chrome,ff,360se等浏览器 早以集成了这些功能，花了不少的时候，做出来的东西，并未额外给客户带来更多价值，所以，在我们这个mvp 版本中，这个先砍掉，我们多些思考，找出做这里的价值，再来开发如何。。。（small）
  2.2 第三方登录这事，（我们的客户特征，是一定有微信的，（在其它应用场景中，是直接使用了微信的例如群发通知，微信课评等...）） 所以，微博登录，qq 登录，对我们来说，是做了多余的事。
  关于微信登录呢，在沟通用说到 平台需要收集到用户的手机号，顺带方便客户手机登陆，所以在首次扫码时，提示下客户去做手机绑定，和直接使用。 (毕竟我们不是流氓平台，动不动强制用户绑了手机才能用)
  这个沟通， 我们先砍了价值 我们通过沟通发现，我们把微信登录后手机号绑定这个需求，单独给提了出来 （small） 并且把微信登录这事（Testable 可测试的） 的需求出来。
  step3 梳理玩需求后，开始估算进度了。
  微信登录这事吧 先拍脑袋 2 days (Estimatable) （ 我讲下如何拍出来的， 我看了下文档 https://developers.weixin.qq.com/doc/oplatform/Website_App/WeChat_Login/Wechat_Login.html 难度适中，考虑到开发之前没有做过类似开发，但这个早已被大量网站给实践出来了，先初步给两天吧。 （基于dod 原则，我和程序员聊了下，给这么多时间，主要是 1 完成pc 端扫码登录的任务，并测试完成【紧急】。 2 熟悉知识和习惯一种与第三方协同的开发模式【重要】 我为认工程师不能只限于事务（完成1 ），还需要能力成长 （完成2） （再讲个个人习惯 ，我会再预留半天时间，程序员写崩了后，我去快速填坑 ， 小概率事件，做一个合适的预留 ，这里我多扯一句，要基于库尔贝勒交叉熵去适当预留资源，项目开发需要鲁棒性，别让极小概率事件把整个项目搞崩） 其实这个 2days 的结论，也是由于分解的足够独立，且粒度足够小，才可以做出来估算. 所以，我在后续估算工做量发现蒙b 时，就会去思考是否分解到位了。
  3 作者推荐了两本书《User Stories Applied》和《Agile Estimating and Planning》。
  做以下操作， 复制 User Stories Applied 打开某东，搜索 User Stories Applied 先加入购物车
  由于价格很感人 User Stories Applied ￥571.00 Agile Estimating and Planning ￥620.00
  我登上download.csdn.net (vip ) 下载了对应的pdf , 然后再上传至百度网盘（还是vip）
   并分享出来 https://pan.baidu.com/s/1jWbXqUX2kXJGJcyurGDh4w 提取码： e28v
  

  2019-11-09

  

  
• 

  小马哥Mark

  开发估期不应该靠直觉，而应该基于可控的需求任务量，而要需求任务量可控，这个需求就应该足够小，足够明确

  2019-08-20

  

  
• 

  陈斯佳

  拆分需求，越小越好，这个是要不断打磨的一项技艺。做一个好的程序员，甚至一个好的项目经理，这应该是必不可少的技能。其实，这个方法都可以应用在我们生活当中。把我们生活看作一个个项目，把自己当作项目经理，去拆分一个个需求，慢慢的把它实现。

  2019-05-18

  

  
• 

  Sudouble

  这一节里介绍的用户故事，感觉和软件工程里的基于场景的需求建模很相似。明确需求是重中之重

  作者回复: 用户故事只是描述需求的一种方式而已。

  2019-02-15

  

  