本文探讨了软件开发过程中的决策制定，包括决策的依据、时机选择及执行效率等问题。文章还讨论了客户价值判断、需求决策等方面的内容。
[quote="ozzzzzz"][quote="partech"]
1.在我参与开发的项目中，绝大多数决策，都是有充分理由的；[/quote]
有充分的理由你还需要决策吗？如果决策真的是一件简单，明显，不需要费脑筋权衡的事情，这个东西还能叫决策吗？
[/quote]
这个观点，让我有点吃惊。难道决策就是绞尽脑汁，最后凭着直觉得到的东西？
那么，那些做“决策支持系统”的人，岂不是都在瞎搞？提供那些有用的信息干嘛？
举个例子：
标准化的英语考试：
如果懂了，那么答案的选择，确实是件简单，轻松的事情；
如果不懂，那么选择题的答案，确实会成为你所理解的伤脑筋的“决策”。
有人看来必然的东西，另外一些人就是不得要领。
[quote="ozzzzzz"]
[quote="partech"]
2.如果出现决策信息不充分的情况，如果不是必须决策，那么，就等条件成熟了再决策，如果不得不作出决策，那就选择最简单，最容易的。[/quote]
既然是必须做出的决策，你还这么选择？
而且作为一个项目自始至终都存在一个最大的决策，那就是这个项目是不是还有必要和可能进行下去。你是如何得到这个决策的。
[/quote]
前面一句没看懂。
后面一句。
首先，我不知道你关于“项目是不是还有必要和可能进行下去，是一个项目自始至终都存在的一个最大决策”的证据是什么？
做个类比“人在什么时候，会做出关于自己生死的决策？”，难道我们每天都要思考这个决策麽？“生存还是死亡，这确实是个问题？”
如果项目中出现了你说的这个决策，那么，这个项目一定是遇到了什么不可克服的障碍，至少参与者这么看。
[quote="ozzzzzz"]
[quote="partech"]3.我相信“快速决策，痛苦执行；缓慢决策，迅速执行”，不无道理。与其乱动，不如不动；[/quote]
决策并不是说不能更改，这一点是瀑布和迭代的根本区别。同时我十分不明白为什么会快速决策，痛苦执行？是因为决策有错误？你不好修改这个错误吗？你不
好快速验证你的决策吗？
缓慢决策，迅速执行？本身软件开发就是一个充满决策的权衡利弊的过程，所谓的执行其实就是以系列的决策。
什么叫乱动？没有目标，没有方法，没有步骤，就是乱动。而很多不动，往往就是因为没有目标，也不知道如何应对的方法，还没有可以操作的步骤，这本身就
是一种乱动。
[/quote]
决策可以更改，但有成本问题。如果你认为大多数决策的执行成本，都比决策成本小的话，确实可以完全不用决策了，因为即使遍历所有可能也不花费多少精力.
但这个假设成立麽？
快速决策对比缓慢决策来说，可能有信息不足，思考不周全，大家未形成共识等等问题。正因为快速决策的这些弱点，所以，采用这种方法的过程，看起来
更象精力充沛的乱动。相反，缓慢决策虽然在决策上面花费了更多的时间，但是由于理由充分，思考周全，大家意见统一，执行起来反而更迅速，效果更好。
[quote="ozzzzzz"]
[quote="partech"]4.对客户有价值，并不等价于“客户说有价值”；[/quote]
那么这个价值是谁去判断的呢？
[/quote]
判断权在客户手中，但是开发人员可以提供帮助，比如提供捕获需求的技术支持，问一些开放式，无假设的问题。
客户拥有需求的决策权，开发人员拥有实现需求的评估权。
[quote="ozzzzzz"]
[quote="partech"]5.我不认为“难于解决的部分往往就是项目是不是可以真正的构建起来的关键”（这倒可以成为开发人员研究新技术/难技术的借口）；
[/quote]
首先你的理解就有偏差。难于解决不仅仅是技术问题，还有业务流程问题，法律问题，社会反响问题等等。比如一个客户需求做一个网上支付，那么他们是不是
就有能力构建这个平台呢？这个问题，恰恰应该在早期进行决策（技术的、法律的、业务的、社会的等等多种因素的权衡）。任何一个项目都会面对一个最大的
决策，那就是这个项目是不是有必要做，是不是能够做。这个决策不仅仅是开发者面对的，而且也是甲方最关心的。
[/quote]
我理解错了？下面是你的原话。
[quote="ozzzzzz"]
而客户价值的判断是不是就只能依靠客户自己来判断呢？[color=red]显然如果客户能够明了软件的结构和技术的风险[/color]，他们对于价值的判断，同他们不明了这些风险做出的判断是不同的。因为收益总是等于收入减去支出，而难于解决的部分往往就是项目是不是可以真正的构建起来的关键。[color=red]客户是希望你今天就告诉他[/color]，你的这个项目不可能成功，还是你几个月之后才告诉他？
[/quote]
如果这里的“你”，指的不是“开发人员”，哪又另当别论。
就算你的意思是广义的风险。我也不认为“做还是不做？”，会是任何项目最关心的问题，某些处于开创期和消亡期的项目，思考这个问题会更多，但这不代表所有的项目。现在银行的人还会问“我们有必要开发网上银行系统么？”？
[quote="ozzzzzz"]
[quote="partech"]6.别“越俎代庖”，客户固然有他的弱点，但人家也不傻，不要认为开发人员恰恰就能弥补这些弱点；
[/quote]
这不是越俎代庖，而是客户协作。客户有弱点，这就如同开发者也有弱点一样，大家都要承认都不是完人，这才是合作的基础。而协作需要我们互相理解，并且
努力为对方的完成工作多做一些事情，而不是被动的坐在那里等待。因为本身agile强调的就是客户协作，而不是开发者和客户的对立。
我觉得你已经不可能提出新的观点了，散会了。[/quote]
但已方不能替甲方做需求决策。
1.在我参与开发的项目中，绝大多数决策，都是有充分理由的；[/quote]
有充分的理由你还需要决策吗？如果决策真的是一件简单，明显，不需要费脑筋权衡的事情，这个东西还能叫决策吗？
[/quote]
这个观点，让我有点吃惊。难道决策就是绞尽脑汁，最后凭着直觉得到的东西？
那么，那些做“决策支持系统”的人，岂不是都在瞎搞？提供那些有用的信息干嘛？
举个例子：
标准化的英语考试：
如果懂了，那么答案的选择，确实是件简单，轻松的事情；
如果不懂，那么选择题的答案，确实会成为你所理解的伤脑筋的“决策”。
有人看来必然的东西，另外一些人就是不得要领。
[quote="ozzzzzz"]
[quote="partech"]
2.如果出现决策信息不充分的情况，如果不是必须决策，那么，就等条件成熟了再决策，如果不得不作出决策，那就选择最简单，最容易的。[/quote]
既然是必须做出的决策，你还这么选择？
而且作为一个项目自始至终都存在一个最大的决策，那就是这个项目是不是还有必要和可能进行下去。你是如何得到这个决策的。
[/quote]
前面一句没看懂。
后面一句。
首先，我不知道你关于“项目是不是还有必要和可能进行下去，是一个项目自始至终都存在的一个最大决策”的证据是什么？
做个类比“人在什么时候，会做出关于自己生死的决策？”，难道我们每天都要思考这个决策麽？“生存还是死亡，这确实是个问题？”
如果项目中出现了你说的这个决策，那么，这个项目一定是遇到了什么不可克服的障碍，至少参与者这么看。
[quote="ozzzzzz"]
[quote="partech"]3.我相信“快速决策，痛苦执行；缓慢决策，迅速执行”，不无道理。与其乱动，不如不动；[/quote]
决策并不是说不能更改，这一点是瀑布和迭代的根本区别。同时我十分不明白为什么会快速决策，痛苦执行？是因为决策有错误？你不好修改这个错误吗？你不
好快速验证你的决策吗？
缓慢决策，迅速执行？本身软件开发就是一个充满决策的权衡利弊的过程，所谓的执行其实就是以系列的决策。
什么叫乱动？没有目标，没有方法，没有步骤，就是乱动。而很多不动，往往就是因为没有目标，也不知道如何应对的方法，还没有可以操作的步骤，这本身就
是一种乱动。
[/quote]
决策可以更改，但有成本问题。如果你认为大多数决策的执行成本，都比决策成本小的话，确实可以完全不用决策了，因为即使遍历所有可能也不花费多少精力.
但这个假设成立麽？
快速决策对比缓慢决策来说，可能有信息不足，思考不周全，大家未形成共识等等问题。正因为快速决策的这些弱点，所以，采用这种方法的过程，看起来
更象精力充沛的乱动。相反，缓慢决策虽然在决策上面花费了更多的时间，但是由于理由充分，思考周全，大家意见统一，执行起来反而更迅速，效果更好。
[quote="ozzzzzz"]
[quote="partech"]4.对客户有价值，并不等价于“客户说有价值”；[/quote]
那么这个价值是谁去判断的呢？
[/quote]
判断权在客户手中，但是开发人员可以提供帮助，比如提供捕获需求的技术支持，问一些开放式，无假设的问题。
客户拥有需求的决策权，开发人员拥有实现需求的评估权。
[quote="ozzzzzz"]
[quote="partech"]5.我不认为“难于解决的部分往往就是项目是不是可以真正的构建起来的关键”（这倒可以成为开发人员研究新技术/难技术的借口）；
[/quote]
首先你的理解就有偏差。难于解决不仅仅是技术问题，还有业务流程问题，法律问题，社会反响问题等等。比如一个客户需求做一个网上支付，那么他们是不是
就有能力构建这个平台呢？这个问题，恰恰应该在早期进行决策（技术的、法律的、业务的、社会的等等多种因素的权衡）。任何一个项目都会面对一个最大的
决策，那就是这个项目是不是有必要做，是不是能够做。这个决策不仅仅是开发者面对的，而且也是甲方最关心的。
[/quote]
我理解错了？下面是你的原话。
[quote="ozzzzzz"]
而客户价值的判断是不是就只能依靠客户自己来判断呢？[color=red]显然如果客户能够明了软件的结构和技术的风险[/color]，他们对于价值的判断，同他们不明了这些风险做出的判断是不同的。因为收益总是等于收入减去支出，而难于解决的部分往往就是项目是不是可以真正的构建起来的关键。[color=red]客户是希望你今天就告诉他[/color]，你的这个项目不可能成功，还是你几个月之后才告诉他？
[/quote]
如果这里的“你”，指的不是“开发人员”，哪又另当别论。
就算你的意思是广义的风险。我也不认为“做还是不做？”，会是任何项目最关心的问题，某些处于开创期和消亡期的项目，思考这个问题会更多，但这不代表所有的项目。现在银行的人还会问“我们有必要开发网上银行系统么？”？
[quote="ozzzzzz"]
[quote="partech"]6.别“越俎代庖”，客户固然有他的弱点，但人家也不傻，不要认为开发人员恰恰就能弥补这些弱点；
[/quote]
这不是越俎代庖，而是客户协作。客户有弱点，这就如同开发者也有弱点一样，大家都要承认都不是完人，这才是合作的基础。而协作需要我们互相理解，并且
努力为对方的完成工作多做一些事情，而不是被动的坐在那里等待。因为本身agile强调的就是客户协作，而不是开发者和客户的对立。
我觉得你已经不可能提出新的观点了，散会了。[/quote]
但已方不能替甲方做需求决策。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
