千万不要把事情100%做完
2013-10-03 19:14
260 查看
http://www.danielteng.com/2013/10/03/optional-scope-thinking/
过去的半年多一直在一个客户那里辅导PO和团队。相对于那种比较传统的“国际”“大”公司客户,这个客户的接受程度以及对于市场的响应程度要高很多。可是尽管客户公司内不同团队的业务不同,有的是面向大众的网站、手机App,有的是主要针对公司后台和运营客户,大家的思维模式十分类似。具体表现是做一件事情,总想一下子全部做完、做全。但是我认为这样的做法是很危险而且不负责任的。导致的结果是加班多、质量降低、士气降低。
为了让大家更清楚的理解问题,先从一个具体的事例开始。两个月前,我听说以前辅导过的一个团队在那一段时间总是周末加班,想到一定是有交付压力,另外我也想看一下如何能够帮到团队,所以就和该团队的PO和ScrumMaster坐在了一起。为了近期的业务目标,团队正在忙于一个合同变更审批的功能,其实做的事情就是在客户要求合同变更的时候,实现自动的审批流程,让相关人等能够看到变更的内容以及能够自动上线。涉及的修改还是比较多,而且由于有业务目标的压力,团队“必须”要全部完成。
问题搞明白后,接下来看看团队的实现方案,大吃一惊,尽管已经做过MVP了,团队还是决定要一个工作流引擎,而且要实现一个类似于版本管理系统的内容比较系统(工程师总是喜欢引擎、框架、系统)。设想一下,工作流引擎光测试用例就会有很多种,如果像Git那样的版本管理实现和测试起来也不会特别快。但是这么多功能对于我们的业务来说需要么?团队是否有可能在几个sprint(每个sprint一个星期)内完成所有功能么?我们设想的这个方案能够解决业务目标的所有问题么?怎样能让我们的PO、客户以及团队感知到我们正在逐步解决问题而不是一口吃一个胖子?
有了大的业务目标,因此必须要把这个大的目标切分成几天可以完成的小目标就变得十分必要。下面是我们花了几分钟大体列出来的几天可以实现的目标。
合同变更直接上线(无任何审批流程;显示所有最新内容)
合同修改后只有一个审批节点,变更自动上线
只针对一个字段(比如合同延期)显示变更信息 (其实从业务角度来讲,90%的合同变更只涉及三五个字段)
实现两个审批节点、无分支的变更自动上线 (审批节点太多以及分支太多本身可能说明公司的业务流程出现了问题,太过于官僚)
针对第二个字段显示变更信息
如果实在有必要,根据一个字段(比如只针对于合同延期),实现工作流审批分支跳转 (当然也有可能不需要事先工作流分支)
这样看下来,每个功能只要几天就能完成,而且如果时间紧,我们甚至可以选择只实现1、2,让客户先用着,然后跟客户说下个星期就能实现3(也就是显示合同变更内容)。这样看来加班也变得没有必要了。
另外还有一个例子,另外一个功能,是把很多数据从数据仓库中读出,然后显示成表格,最后在显示成线图。工作量大约是四个星期。而且里面有一些技术难点,比如实现数据推送、大量数据的持久化以及复杂的图表。整个一个需求的工作量是四个星期,肯定很水,如何能让进度变得可见,而不是一个黑洞。最终大的业务目标被切分成如下的小目标。
用表格方式展示一个字段(比如是访问数),数据是hard code的 -> 主要目的是证明能够用表格方式显示数据
能把Hard code点评数,按照点的方式,暂时不用曲线的方式去展示1天的数据 -> 主要是证明能够把数据展示成图
能把Hard code点评数,按照点的方式,暂时不用曲线的方式去展示2天到7天的数据 -> 主要是证明能够把展示多个点,但是不要求连成线
能从数据库中读取点评数,并展示成表格和图表 -> 这时候数据已经不是Hard code的,而是动态的了
能从数据仓库中读取这个字段的内容,导入到数据库,并展示成表格和图表 -> 打穿了从数据仓库到图标的通路,系统基本框架已经成型
能把点图变成线图
把一个字段扩充成两个字段,能够展示表格
把一个字段扩充成两个字段,能够根据表格展示点图
两个字段用不同颜色展示线图
把7天扩充到30天,根据时间段不同显示不同的数据
数据持久化技术方案确定
大数据量推送、同步方案确定
说到这里,大家可能想到了,这个blog其实是关于需求切分的。我想强调的是,所谓需求切分其实更重要的是业务目标的切分。目标切分是敏捷团队和个人所必须具有的核心技能之一。几个月前我在微博上分享过,我们四个pair在5个小时内有过130次提交代码,很多人不理解,觉得是不是修改一个字母就提交了。其实背后隐含了绝大多数程序员缺乏切分目标、切分需求的能力。如何把一个比较大的目标变成一系列SMART(Specific, Measurable, Achievable, Relevant, Time)的小目标,从而从一开始就知道我们在哪里、我们的方向是哪里、我们的速度如何。。。对于业务成功十分关键。推荐一篇XP创始人Kent
Beck的文章Optional Scope Contract。
更深一步,有可能我们一开始的方向是错的,我们解决的是错误的问题,我们也就没有必要把问题完全解决,关键是做完一部分,扔到客户那里,然后跟着客户的反馈走。
突然想到敏捷宣言第四条其实很有道理:“相应变化 高于 遵循计划”。
过去的半年多一直在一个客户那里辅导PO和团队。相对于那种比较传统的“国际”“大”公司客户,这个客户的接受程度以及对于市场的响应程度要高很多。可是尽管客户公司内不同团队的业务不同,有的是面向大众的网站、手机App,有的是主要针对公司后台和运营客户,大家的思维模式十分类似。具体表现是做一件事情,总想一下子全部做完、做全。但是我认为这样的做法是很危险而且不负责任的。导致的结果是加班多、质量降低、士气降低。
为了让大家更清楚的理解问题,先从一个具体的事例开始。两个月前,我听说以前辅导过的一个团队在那一段时间总是周末加班,想到一定是有交付压力,另外我也想看一下如何能够帮到团队,所以就和该团队的PO和ScrumMaster坐在了一起。为了近期的业务目标,团队正在忙于一个合同变更审批的功能,其实做的事情就是在客户要求合同变更的时候,实现自动的审批流程,让相关人等能够看到变更的内容以及能够自动上线。涉及的修改还是比较多,而且由于有业务目标的压力,团队“必须”要全部完成。
问题搞明白后,接下来看看团队的实现方案,大吃一惊,尽管已经做过MVP了,团队还是决定要一个工作流引擎,而且要实现一个类似于版本管理系统的内容比较系统(工程师总是喜欢引擎、框架、系统)。设想一下,工作流引擎光测试用例就会有很多种,如果像Git那样的版本管理实现和测试起来也不会特别快。但是这么多功能对于我们的业务来说需要么?团队是否有可能在几个sprint(每个sprint一个星期)内完成所有功能么?我们设想的这个方案能够解决业务目标的所有问题么?怎样能让我们的PO、客户以及团队感知到我们正在逐步解决问题而不是一口吃一个胖子?
有了大的业务目标,因此必须要把这个大的目标切分成几天可以完成的小目标就变得十分必要。下面是我们花了几分钟大体列出来的几天可以实现的目标。
合同变更直接上线(无任何审批流程;显示所有最新内容)
合同修改后只有一个审批节点,变更自动上线
只针对一个字段(比如合同延期)显示变更信息 (其实从业务角度来讲,90%的合同变更只涉及三五个字段)
实现两个审批节点、无分支的变更自动上线 (审批节点太多以及分支太多本身可能说明公司的业务流程出现了问题,太过于官僚)
针对第二个字段显示变更信息
如果实在有必要,根据一个字段(比如只针对于合同延期),实现工作流审批分支跳转 (当然也有可能不需要事先工作流分支)
这样看下来,每个功能只要几天就能完成,而且如果时间紧,我们甚至可以选择只实现1、2,让客户先用着,然后跟客户说下个星期就能实现3(也就是显示合同变更内容)。这样看来加班也变得没有必要了。
另外还有一个例子,另外一个功能,是把很多数据从数据仓库中读出,然后显示成表格,最后在显示成线图。工作量大约是四个星期。而且里面有一些技术难点,比如实现数据推送、大量数据的持久化以及复杂的图表。整个一个需求的工作量是四个星期,肯定很水,如何能让进度变得可见,而不是一个黑洞。最终大的业务目标被切分成如下的小目标。
用表格方式展示一个字段(比如是访问数),数据是hard code的 -> 主要目的是证明能够用表格方式显示数据
能把Hard code点评数,按照点的方式,暂时不用曲线的方式去展示1天的数据 -> 主要是证明能够把数据展示成图
能把Hard code点评数,按照点的方式,暂时不用曲线的方式去展示2天到7天的数据 -> 主要是证明能够把展示多个点,但是不要求连成线
能从数据库中读取点评数,并展示成表格和图表 -> 这时候数据已经不是Hard code的,而是动态的了
能从数据仓库中读取这个字段的内容,导入到数据库,并展示成表格和图表 -> 打穿了从数据仓库到图标的通路,系统基本框架已经成型
能把点图变成线图
把一个字段扩充成两个字段,能够展示表格
把一个字段扩充成两个字段,能够根据表格展示点图
两个字段用不同颜色展示线图
把7天扩充到30天,根据时间段不同显示不同的数据
数据持久化技术方案确定
大数据量推送、同步方案确定
说到这里,大家可能想到了,这个blog其实是关于需求切分的。我想强调的是,所谓需求切分其实更重要的是业务目标的切分。目标切分是敏捷团队和个人所必须具有的核心技能之一。几个月前我在微博上分享过,我们四个pair在5个小时内有过130次提交代码,很多人不理解,觉得是不是修改一个字母就提交了。其实背后隐含了绝大多数程序员缺乏切分目标、切分需求的能力。如何把一个比较大的目标变成一系列SMART(Specific, Measurable, Achievable, Relevant, Time)的小目标,从而从一开始就知道我们在哪里、我们的方向是哪里、我们的速度如何。。。对于业务成功十分关键。推荐一篇XP创始人Kent
Beck的文章Optional Scope Contract。
更深一步,有可能我们一开始的方向是错的,我们解决的是错误的问题,我们也就没有必要把问题完全解决,关键是做完一部分,扔到客户那里,然后跟着客户的反馈走。
突然想到敏捷宣言第四条其实很有道理:“相应变化 高于 遵循计划”。
相关文章推荐
- Whonix - Things NOT to do 匿名上网的时候千万不要做的事情——摘要
- 谁的事情谁做,千万不要代劳
- Android开发之千万不要把数据存储在Application对象中
- 新人千万不要在 Windows 上使用 Ruby on Rails
- 继KB3035583后微软再发恶意补丁KB3123862、千万不要打!!!
- 组装电脑千万不要随便买
- 千万不要在程序员群问代码……
- 空主机头千万不要做CNAME记录,它会导致整个域名解析不正常。
- 提醒!比特币千万不要碰!?(附资源)
- 千万不要在Android的Application对象中缓存数据!
- 任正非:不要试图做完人(转)
- 千万不要在构造方法里写 Director::getInstance()->getScheduler();
- 千万不要读博士成为科学家
- 毕业5年决定人的一生-- 大家千万不要错过这篇文章
- 在职场中,千万不要当这两种下属,学会汇报,让领导刮目相看!
- 千万不要做一头在职场工作中的”驴“!
- 为什么程序员千万不要重写代码?
- [转]千万不要把灯泡放进嘴里
- 条款31: 千万不要返回局部对象的引用,也不要返回函数内部用new初始化的指针的引用
- COM+组件的私有方法里面不能用Setcomplete,千万不要以为写了无所谓