本次对话讨论了业务建模和用户业务的关系以及我书中的方式为什么更实用的原因。最后谈到我的培训和中国企业的无奈。
北京-FireSpider 男 11:42:09
老师,您好。
北京-FireSpider 男 11:43:42
我翻阅很多书,好像所有的“业务建模”阶段都是针对“已经有信息化需求”的。“业务建模”阶段体现出了“系统”概念。
北京-FireSpider 男 11:44:49
所以,才有我之前所不能理解的“业务用例”。如此一来,“业务用例”一词和“系统”有关就可以理解了。
青润 11:45:03
嗯。
北京-FireSpider 男 11:46:34
呵呵,这样看来确实可以理解了。我之前一直不能理解,是因为把“业务用例”放在“纯粹描述客户业务”的角度来看了。但现在看,不是这样的。需求阶段,就已经有需求输入了。
青润 11:48:48
业务建模是针对用户业务的建模。
这个过程可以有过去的历史系统的痕迹,也可以是全新建设的系统。
北京-FireSpider 男 11:50:50
但是,还像我在张老师哪个群里说的,缺少“描述客户业务”的环节,并且我买的这些书里,都没有描述阶段。
青润 11:52:05
我的书中对于业务用例的描述会用到状态活动图或者泳道图,这两种图就是用来绘制用户实际的手工业务操作或者现在的业务操作方式。
然后从这里分离出来系统可以实现的,系统不能实现的,系统需要从外部获取的,三个部分的元用例。
这三种元用例通过组合拼接,形成实际的用例。
青润 11:53:15
这个描述在我的书中提到了,但是没有写的特别仔细,因为展开,会是一个很大的话题,而且我提出的元用例的概念并没有得到业界的统一认可。
北京-FireSpider 男 11:53:26
嗯,您说中确实在需求这块有状态活动图或者泳道图,这个图看上去与系统没有任何关系,感觉是在描述客户当前的业务。
其他的书也有,只不过和用例建模混在一起,看不出来一个独立的阶段。
青润 11:54:28
这是我认为在rup中描述不清楚的,我把它用于对业务用例的细节描述,我认为这样可以表述的更清楚。
青润 11:55:32
另外对于用例,也就是元用例组合后需要在项目中实现的功能性用例和非功能性用例(也就是你说的系统用例),我也用状态活动图来替代用例阐述,实现完整的模型化开发,全面脱离文档。
北京-FireSpider 男 11:55:40
嗯,还得读者根据自己的实际情况去灵活运用才行。
青润 11:56:53
我只能把相对比较合适的全面地框架给你们,针对具体项目是需要具体考虑的。
北京-FireSpider 男 11:57:08
嗯,是的。
我现在特别希望有一个新的项目,小一点的,最好客户什么系统都没有的,从头做一遍。
北京-FireSpider 男 11:58:22
否则这样思考,还是有很多问题无法弄明白。
青润 11:58:36
我曾经的培训,就是现场提出一个项目,我边讲边做,培训结束的时候可以看到部分代码的导出效果。
北京-FireSpider 男 11:58:53
以前做的很多适合分析的项目,一直没用过这种思路,可惜了。
青润 11:59:03
呵呵。
北京-FireSpider 男 11:59:36
嗯,真希望您能给我们培训一下。不过这个公司无望了,连一点培训的钱都舍不得花。
很多企业搞不起来,也确实是上层思路有问题,“该花的钱不花,不该花的钱乱花”。
搞不清楚这些老板是怎么想的。
北京-FireSpider 男 12:01:27
这些年,我一直在小公司干了,开发流程混乱,也没学到什么不标准,完全依靠自己的总结、经验去发挥。
青润 12:02:38
呵呵,没办法
中国的老板都担心自己培养的人跑了。因为培训了,就要给高工资,不给就走。
也都想坐吃现成,觉得挖人最快,成本低,时间快。
北京-FireSpider 男 12:02:46
呵呵
牛人跑到新公司去,其实也是新公司用最低的成本招到人。
青润 12:03:37
所以,都不想培训或者通过咨询的方式得到企业的发展。
加上国内的培训鱼龙混杂,泥沙俱下,谁也说不清楚为什么好为什么不好。
我这种靠信誉生存的,不懂得市场运营,所以,就比较艰难了。
北京-FireSpider 男 12:04:42
老师,您还是想想运营一下,在中国这个环境里,得以赚钱为第一动力,以培养人为赚钱的工具。
呵呵
理念变味了,也是很无奈的。
北京-FireSpider 男 12:05:48
午休了,您也去吃午饭吧。回来再聊。
青润 12:06:15
呵呵,我就是个做技术或者技术管理的人,让我去做运营,虽然懂一些,但是却是不想投放什么经历在那上面,不是自己感兴趣的事情。
甚至一些我能做的培训,因为觉得没有技术含量,我都会拒绝。
我做培训的文字你可以去看看,就明白我为什么用我的这种完全实例化培训方式来讲课了。