Re: FDD——天才的灵感

阅读更多
ozzzzzz 写道
partech 写道

1.在我参与开发的项目中,绝大多数决策,都是有充分理由的;

有充分的理由你还需要决策吗?如果决策真的是一件简单,明显,不需要费脑筋权衡的事情,这个东西还能叫决策吗?

这个观点,让我有点吃惊。难道决策就是绞尽脑汁,最后凭着直觉得到的东西?
那么,那些做“决策支持系统”的人,岂不是都在瞎搞?提供那些有用的信息干嘛?
举个例子:
标准化的英语考试:
如果懂了,那么答案的选择,确实是件简单,轻松的事情;
如果不懂,那么选择题的答案,确实会成为你所理解的伤脑筋的“决策”。

有人看来必然的东西,另外一些人就是不得要领。

ozzzzzz 写道

partech 写道

2.如果出现决策信息不充分的情况,如果不是必须决策,那么,就等条件成熟了再决策,如果不得不作出决策,那就选择最简单,最容易的。

既然是必须做出的决策,你还这么选择?
而且作为一个项目自始至终都存在一个最大的决策,那就是这个项目是不是还有必要和可能进行下去。你是如何得到这个决策的。

前面一句没看懂。

后面一句。
首先,我不知道你关于“项目是不是还有必要和可能进行下去,是一个项目自始至终都存在的一个最大决策”的证据是什么?
做个类比“人在什么时候,会做出关于自己生死的决策?”,难道我们每天都要思考这个决策麽?“生存还是死亡,这确实是个问题?”

如果项目中出现了你说的这个决策,那么,这个项目一定是遇到了什么不可克服的障碍,至少参与者这么看。

ozzzzzz 写道

partech 写道
3.我相信“快速决策,痛苦执行;缓慢决策,迅速执行”,不无道理。与其乱动,不如不动;

决策并不是说不能更改,这一点是瀑布和迭代的根本区别。同时我十分不明白为什么会快速决策,痛苦执行?是因为决策有错误?你不好修改这个错误吗?你不

好快速验证你的决策吗?
缓慢决策,迅速执行?本身软件开发就是一个充满决策的权衡利弊的过程,所谓的执行其实就是以系列的决策。
什么叫乱动?没有目标,没有方法,没有步骤,就是乱动。而很多不动,往往就是因为没有目标,也不知道如何应对的方法,还没有可以操作的步骤,这本身就

是一种乱动。

决策可以更改,但有成本问题。如果你认为大多数决策的执行成本,都比决策成本小的话,确实可以完全不用决策了,因为即使遍历所有可能也不花费多少精力.
但这个假设成立麽?

快速决策对比缓慢决策来说,可能有信息不足,思考不周全,大家未形成共识等等问题。正因为快速决策的这些弱点,所以,采用这种方法的过程,看起来
更象精力充沛的乱动。相反,缓慢决策虽然在决策上面花费了更多的时间,但是由于理由充分,思考周全,大家意见统一,执行起来反而更迅速,效果更好。
ozzzzzz 写道

partech 写道
4.对客户有价值,并不等价于“客户说有价值”;

那么这个价值是谁去判断的呢?

判断权在客户手中,但是开发人员可以提供帮助,比如提供捕获需求的技术支持,问一些开放式,无假设的问题。
客户拥有需求的决策权,开发人员拥有实现需求的评估权。

ozzzzzz 写道

partech 写道
5.我不认为“难于解决的部分往往就是项目是不是可以真正的构建起来的关键”(这倒可以成为开发人员研究新技术/难技术的借口);


首先你的理解就有偏差。难于解决不仅仅是技术问题,还有业务流程问题,法律问题,社会反响问题等等。比如一个客户需求做一个网上支付,那么他们是不是

就有能力构建这个平台呢?这个问题,恰恰应该在早期进行决策(技术的、法律的、业务的、社会的等等多种因素的权衡)。任何一个项目都会面对一个最大的

决策,那就是这个项目是不是有必要做,是不是能够做。这个决策不仅仅是开发者面对的,而且也是甲方最关心的。

我理解错了?下面是你的原话。
ozzzzzz 写道

而客户价值的判断是不是就只能依靠客户自己来判断呢? 显然如果客户能够明了软件的结构和技术的风险,他们对于价值的判断,同他们不明了这些风险做出的判断是不同的。因为收益总是等于收入减去支出,而难于解决的部分往往就是项目是不是可以真正的构建起来的关键。 客户是希望你今天就告诉他,你的这个项目不可能成功,还是你几个月之后才告诉他?


如果这里的“你”,指的不是“开发人员”,哪又另当别论。

就算你的意思是广义的风险。我也不认为“做还是不做?”,会是任何项目最关心的问题,某些处于开创期和消亡期的项目,思考这个问题会更多,但这不代表所有的项目。现在银行的人还会问“我们有必要开发网上银行系统么?”?

ozzzzzz 写道

partech 写道
6.别“越俎代庖”,客户固然有他的弱点,但人家也不傻,不要认为开发人员恰恰就能弥补这些弱点;

这不是越俎代庖,而是客户协作。客户有弱点,这就如同开发者也有弱点一样,大家都要承认都不是完人,这才是合作的基础。而协作需要我们互相理解,并且

努力为对方的完成工作多做一些事情,而不是被动的坐在那里等待。因为本身agile强调的就是客户协作,而不是开发者和客户的对立。

我觉得你已经不可能提出新的观点了,散会了。

但已方不能替甲方做需求决策。

你可能感兴趣的:(fdd)