技术人员的通病——缺乏市场观念
　

---

自从用了RUP，我才发现技术人员的通病——缺乏市场观念，其实对理解和运用RUP产生很大的障碍。
比如：实际操作时，对业务建模的目的的理解，对业务分析员和系统分析员的分工协作关系认识混乱等等，根源就在与技术人员的视野局限于技术领域，而没有扩展到整个业务领域。
传统的需求获取概念是系统分析员一个角色的使命，传统意义的系统分析员被要求成为业务领域和软件领域的双料冠军，致使大部分的系统分析员对自己在业务领域的作用认识不清，以为就是要熟悉业务，精通业务流程，把自己培养成业务专家。传统的系统分析员由于一般是业务的外行，他很容易把自己在业务领域的职责定位为“精通业务”，并以此为自豪，确实，做到这一点，对系统分析员实在是太不容易了。
事实上，这种对“精通业务”的强烈追求，有时会让系统分析员忽视一个简单的事实：我们要做的软件只是一个业务工具，是工具就要有价值，就要解决用户的问题。因此，我们常常会看到长篇地对业务流程的平铺直叙的业务分析报告，报告能清楚地证明分析员对业务流程的精密理解，但不直接暴露太多的业务问题和业务机遇。甚至，我们会发现系统分析员有时会用自己对业务的准确理解和客户代表大争“业务应该是这样的！”。
对于做软件来说，只有问题和机会才是值钱的卖点。找不到问题和机会就启动软件开发是盲目的投资。很多老板在这点上吃亏不小，总是把原因追究在开发过程上，是个遗憾。
RUP和UML是怎么表现市场观念的？下次接着说。

但是不精通业务又怎么可能发现"业务问题和业务机遇"呢? 我认为精通业务知识是基础,但只熟悉业务知识还不能算是一个好的SA.

这种理解正是可能掩盖市场意识获取条件的原因之一，以为发现市场机会一定要精通业务流程，这正是传统SA的症结所在。
你可以抱怨出境签证处效率低下，但你不一定要知道出境签证的详细流程。
业务分析的目的是发现问题，而不是培养业务工作的合格员工。
你发现了问题所在，就发现了价值，业务分析的任务就完成了。
传统的SA总是喜欢把业务问题和系统问题搅在一起说明，一方面扩大了系统分析的战场，二一方面使目标涣散，浪费投资。但传统的SA对此津津乐道，以为自己就是“复合型”人才了。这是反分工，也就是反工程化的思路。

你的想法是空想，自相矛盾。

您的例子有客户代表，有用户业务，应该还是属于系统集成的范围。原来客户不应该知道自己的需求和业务流程，非要伟大的系统分析员来指点。系统分析员不是把客户的需求转化成便于程序员能理解的形式，而是咨询。
业务问题和业务机遇，原来如果给客户定制一套库存管理系统，系统开发商应该帮客户找出订货触发点的客户初始设定有问题，或是在客户没有需求的情况下，追加特别大量订货的触发点给客户一个惊喜。或者给客户开发一套销售系统时就要设计一套完整的销售战略，帮助客户抓住业务机遇。切实提高销售成绩。
原来技术人员能够精通业务流程还不够，看来以后非要让铅球冠军能同时拿下游泳冠军，否则就是作为铅球运动员只追求会游泳，没有同时成为游泳冠军的努力是游泳队不能获得奖牌的原因。

 但这可是大利好消息
　

---

发现业务问题和抓住业务机遇原本来都是咨询专家的业务范围，现在居然发现是技术人员应该承担的责任。怪不得前面说被咨询的大型企业都倒闭了，原来是这些专家不懂RUP和UML的缘故。我们应该向安达信之类的咨询企业强烈建议，用UML作为咨询人员的上岗考试。钱途一片光明啊

 需求分析和系统分析是两个完全不同的工作......
　

---

需求分析和系统分析是两个完全不同的工作，目标不同，要求的skill set也不同。如果要同一个人完成，那对这个人的要求会很高。
另外，技术人员首要要解决的是技术问题，然后才是其他的。对于技术人员，市场观念是nice-have的东西，不是must-have（当然，你可以抬杠说每个人都要有市场观念:)）。
“对于做软件来说，只有问题和机会才是值钱的卖点。”，我很同意这个观点。做软件是帮客户解决问题的，所以，首要的是要知道问题是什么。
关于需求分析，有一篇文章可以分享一下：
http://www.pmtsolution.net/articles/se/有效的需求分析员.pdf

没看到那么多人自命为 OO 咨询专家, UML 专家吗?

老实说, 我最不明白的就是国内的 IT 咨询在做什么

至少不会误人子弟
您老没见项目开发估算误差达到数量级级别的专家都要培训别人正确的开发方法吗？
估计接受培训后误差就能从原来的50%提高到500%了。呵呵。

不收取学费，管饭就行。

顾客不能进行系统分析，这是很常见的事。一个是因为“只缘身在此山中”，另一个是因为缺少系统的观点。

参见《第五项修炼》关于系统分析的描述。

系统分析员要如实描述业务问题或业务机遇，勾画出工作的边界和产品的边界，评估开发的时间费用和可行性，为系统地解决业务问题提供机会。系统分析是客户价值和技术开发之间的纽带。

所以我提供系统分析培训，呵呵

同意您的标题说法,不同意您的内容.

这里的讨论中已经反映出两种层次的问题:
1.发现问题
2.解决问题
这正是争论的焦点,如果没有分析的分工,传统的SA很容易把发现问题的任务也挑在自己的肩上.还有的SA根本不管什么是问题,认为这是客户代表的任务,于是,产生局部思维.

当然,你完全可以认为这是空想,这样只能使您少一个开阔思路的机会.
谢谢您的提醒,我会尽量减少空想的成份.

培训好赚钱啊. 所以大家一起搞培训啊.

如果我是公司客户，我认为目前库存管理成本太高。于是找了一家系统开发商，告诉它我打算开发一套库存管理软件，然后需求分析时告诉开发商我发现了库存管理有问题，于是问题发现了，轮到开发商解决问题了，我什么脑筋都不用动就应该是软件开发商替我分析设计新的库存管理流程？
再过几天，我又发现公司盈利不足的问题了，于是再找一家开发商。。。？

这究竟是软件开发公司还是咨询公司？

UML中的一句经典名言是:"用例驱动".

请思考一下:经济社会的驱动力是什么?是价值.
软件是经济社会的产物,是什么驱动软件的研发?当然离不开价值.
所以,挖掘软件需求是挖掘什么?就是挖掘软件的价值.

这和用例有什么关系?
大有关系!
用例有主角,用例的主角是用例的外部驱动者,而不是内部操作者.
用例为主角而存在,主角通过用例的执行获得所需,并愿意为用例的执行付出.
业务用例正是业务生活中这种供求关系的反映,业务用例模型正是一个企业的价值链模型.
这正是"用例驱动"的经济学含义.

做软件的人(尤其是软件企业老板)如果不把这个经济学模型装载头脑中,银子打了水漂都不知道是为什么.

 不错，有新意
　

---

看来我要扛着用例去赚钱了，呵呵

如果这个开发商的定位就是专门做库存管理软件的，那么他的产品中应该包含控制库存成本等方面的功能、算法、逻辑。专业的开发商应该不仅能提供客户软件，也能提供客户一定的管理方法。因此这样的开发商内部应该有咨询部门或咨询人员，或是有固定的管理咨询的合作伙伴，他们知道如何解决客户库存管理方面的管理问题，并能把这种know-how做到软件里去。这样的软件生命力才强。
当然具体到开发商内部分工来看，这样的咨询显然也不是系统分析员的工作。系统分析员只是负责在软件中实现上述的know-how。

但......现实是，国内很多开发商规模小、生存压力大、很难做到如此专业，也就不可能发展出咨询能力。也可能有些开发商认为自己软件开发能力很强，认为这是自己的核心竞争力，不想再发展管理咨询的能力，怕干扰自己的focus。此时，如果客户没有找管理咨询的意识，开发商又没有这样的能力，在两者之间就会缺少一个环节。我认为这是很多项目失败的原因。

所以有"软件就是服务"的说法.
你是不是老要找商店买点这,买点那,你对此感到希奇吗?
客户的需求会成长,考虑客户需求成长的软件我已经研究了五年,这需要发展OO的一些理念.很困难,一个人做下来需要很长时间,也可能一个人做不下来.
在这种软件开发出来之前,社会分工的趋势是明显的,不在于您对外宣称是软件公司还是咨询公司,两种事情适合不同的人做是事实:发现问题和给出问题的解决方案,这两种人还得密切配合才行.回到整体来看,你会知道价值所处的位置,这才是最重要的.

解决问题必须先要理解问题,而理解问题则必须理解用户的业务.否则解决起来就会顾此失彼,按倒葫芦起个瓢.如果用户可以积极参与你的工作,还可以帮你纠正不少错误,但即使这样,你的工作效率也会很低,最终会失去用户的信任.而如果用户不积极参与,那么项目一定会毁在你的手上(如果项目组其他人也不懂业务的话).我猜你要不是刚参加工作,要不就是学生,不要紧,大家讨论讨论,别着急.

我的发言是有些学究气，谢谢指点。您的估计有一些偏差。
我尽量找些实际的比喻。

我并不是反对那些真正精通业务的SA，我只是提醒：时代在进步，SA人才的培养困难是大家公认的软件行业瓶颈问题，如果固守传统观念，会尚失很多机会。

真正精通业务的SA实际上能够胜任发现问题和给出问题解决方案的两种职责，
对于前者，需要熟悉业务，还更需要经济学背景，系统科学的背景，当然少不了计算机科学背景；
对于后者，也需要熟悉业务，还更需要系统科学的背景，计算机软件的背景。

你的观点本身没有错，只是少看到了一些机会。

谢谢您的捧场，您的意见很好！
我主要针对大部分软件企业搞需求获取的都是从SA转行过来的，或者是在不够成熟的SA的“指导”下进行的。这种现实现象把对不同种类的技术人员的要求给搞混乱了。何况国内一般的软件公司更本花不起设立专门的BA人员的代价，自然用SA代替，甚至连SA都不成熟。
所以，搞清楚各环节目标及其内部关系才是重要的。

您推荐的文章需要入会才能看，我想一定不错。可惜我没有精力入太多的会。

开发这种专业软件当然需要找出价值链中关键的部分作为卖点。要找出流程背后真正的重要价值。但在本体开发过程中系统分析员好像不用和客户代表争论业务问题，只要学习业务知识，归纳总结，毕竟目标不是仅仅一家客户，行业通用性更为重要。如果要成功，业务专家不必懂任何技术，但必须是业内经验丰富的老法师。和客户代表争论具体业务应该如何进行是二次开发时的事，这时候软件已经定型了，恐怕也没有多少用例之类的要考虑，只是设置的问题了。
至于“客户没有找管理咨询的意识，开发商又没有这样的能力，在两者之间就会缺少一个环节。我认为这是很多项目失败的原因”，那是合同的问题，定好只做开发的话，软件开发商去多做什么咨询的工作，运气好和客户密切了关系，但亏本可能也大增。开发商没去做被客户遗漏的咨询，项目失败也是客户的问题。如果合同定好是包括咨询，咨询工作难道是软件技术人员的责任范围吗？那么只能说项目的管理有问题

先问谁要一件事被做?
接着问为什么要做?同时问要做什么?
后者为前者服务,交替进行,直到前者完全搞清.
以上过程就把有什么有更价值的事值得做排序出来了(其中免不了要打算盘).

这到底是件什么事?
谁来做这事?(请注意和谁要一件事被做是不同的)
要得到什么东东?
这事是怎么配合进行的?
问题是怎么解决的?
有什么更好的办法没有?

前者就是业务分析,后者是业务设计,前者显露价值,后者把价值搞得清清楚楚,以找到提升价值的手段.

这里,根本没有谈到系统分析设计的事,但系统分析设计的方法,当然可以用在此处.

有趣的管理思维。

 to bubituo:
　

---

《有效的需求分析员》可以自由下载的，不需要入会。可能因为你的IE设置不支持中文文件名。

这些步骤应该是“业务分析员”和“业务设计员”的任务，使用的方法是从软件的分析设计方法中演变过来的。
这两种人员是否应该纳入软件技术人员的范围来理解？
从现实角度来看，大量的是SA被赶鸭子上架，也有SA初生牛犊者。他们是软件技术人员。
从发展趋势上看，业务分析和设计和业务专家，管理咨询师也有区别，很少有咨询师会掌握前沿的业务分析设计方法的。业务的分析设计会成为一个专门的软件研发的技术。
从问题的本质看，软件开发的根本难度在于软件的复杂性，软件的复杂性在于业务的复杂性，解决了业务复杂性问题，软件复杂性问题迎刃而解。
这能说，业务分析设计师不是软件技术人员吗？

他们是同一类型的人,却有微妙的区别.
BPR/BPI是商业管理人员向软件领域融合的概念
而BA和BD人员则是从软件领域向商业管理融合的概念.

他们的思想相同,当方法和手段上有所不同.

要开发一个财务软件，系统分析员得有会计师资格。如果接下去开发一个法律咨询软件，又得去考一个律师资格。
原来我错了。您是说如果找了一个会计师分析财务业务，找了一个律师分析法律问题，哪怕他们对计算机一窍不通，也算软件专业技术人员。因为他们从事了业务分析业务？
“很少有咨询师会掌握前沿的业务分析设计方法的”？我怎么听说咨询业的公司提出过不少分析理论，那个什么产品分析的四象限法就是某家咨询公司的成果被业界普遍接受的结果。倒是软件行业在本行的软件开发中还有80%到90%被评价为混乱。业务分析会不会比本行作的更好我不知道。但您这里的软件技术人员最好还是加个定语。
最后问一声，如果开发一个电子公文系统，究竟是开发员当官僚还是官员也加入了软件开发人员的行业？

许多BA或称当BA的SA试图用业务用例模型来表达所有的业务逻辑，这事不恰当，也是招致许多不明真相者（如某高先生）指责UML的原因之一，因为，在他们的头脑中，还没有建立迭代演进的观念，而这种迭代演进的驱动力，就来自用例模型。用例模型就是靠它所饱含的商业价值来驱动的。
既然只是驱动力的提供者，就只能把它当驱动者用，才能把价值挖掘到及至。如果硬要用他来说明逻辑，当然会是舍本逐末还怪家伙不好使。

本来,万物的本质规律是相通的,您非要把他们割裂开来理解,然后用来和我辩论,实在可惜.
不过,我要检讨的是,标题太一棍子打死了,我已经改过了.

难道说同一件事要两批人各作一遍。结果冲突怎么办？谁负责审核，由哪一批负责？

是不是有点抬杠的感觉了,如果是,我就此打住.

1，您的业务分析人员和BPR人员是同一个概念的两个名词吗？
您说有微妙的区别，就是说两个概念了。算是回答了。
2，一个项目组内是否能同时有您的业务分析人员和BPR人员
3，如果同时可以存在的话，负责的业务有无重叠的地方
根据您的定义描述，同时存在的话业务基本重叠，但想确认是否真的如此。
4，重叠的业务两组人如果有不同结果，如何取舍，谁为主，谁为辅。
没有人关心这两组人的来源，手段，只看任务，结果。
您是认为两组人对同一个问题的回答必然相同？

我不在乎天上有几架飞机在飞，如果您给我安排了两架飞机，飞往不同的目的地，我当然要问该乘哪一架，只要能送到正确的目的地，没有人在乎飞机的厂商和型号。

哲学起指导作用不等于只要有了哲学就够了。哲学本身是完不成项目的

那就是误解,
我的意思是说,BPR/BPI人员和BA/BD人员是从不同领域向同一个方向发展的产物,并不意味着一个项目同时需要两种人员参与,也不是说同一个项目项目需要设立两种角色,只是说这两种人都能胜任业务分析的工作.如果一个项目出现这两种人同时存在,这是项目的幸运,异道同归的感觉会让他们密切配合,更加完美地完成业务分析的任务.我就有这种经历.
再次感谢您的批评,我尽量减少一些简单的道理说法.
　

基本上都是这样的，至少我参加过的不少都是这样。

土话说法就是
用叉子吃了一个土豆。

我们要说新话，与时俱进。哈哈。