说说长篇文档的评审

对于长篇文档的评审,其实结果是很滑稽的,往往是通过稍作修改。很少有不通过的。而稍作修改就是随便改改。最终文档质量是没有保障的。因此现在条目化文档处理成为了新常态。比如需求是分条起草并评审的,通过就是通过。

      diabloneo确实是这样,我还没遇到完全重写文档的情况

因此,有效评审长篇文档的办法就是把长篇文档拆短。

需求被分解为小颗粒度的条目,请产品经理或者产品主管逐条确定,让各方理解。user story,use case是最好的载体。把长篇大需求文档的评审分解为多次小颗粒度的评审。更加有针对性,更准确,更高效

对有些条目,同意就通过,对有些条目如果不同意就不通过,同意的条目就往下流转。不同意的条目就请原作者修改整改。

因此当今需求工程的发展,已经有明确的趋势,就是抛弃长篇大文档,改为短篇条目来处理。

建议政府工作报告采纳在软件业界得到了这些经验。把报告分成一条一条的,让人民代表们逐条来表决。更加体现人民代表大会是全国最高权力机关,真正的为人民的利益说话。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值