有些朋友,我真的感谢,他们会不嫌你白痴地耐心地指教你. 和这样的人交流,遇到问题时,他不会是以"你反正不懂,你不要管"这样的态度对待你.而是尽量用深入浅出的一些词语讲解给你听.或者指点你自己去了解一些概念. 比如,今天让我看用例图的人. 他是真的有些耐心.
虽然,我绝对不会真正去按技术人员的标准去学习,也绝对不会以外行的身份,真正对技术人员去指手画脚,但对一些基本技术概念的了解,还是非常需要的.
因为,我是在做自己想要做的东西,我并不是一个外包公司的客户,也不是一个所谓大公司的领导.不能简单地以外行的身份和人家讲完需求就了事. 你自己是创业者,是要把自己想要的东西和懂技术的人一起实现出来. 以我现在对互联网行业的了解,在具体这个项目实现的过程里,我的角色应该是产品经理. 我感受是,一个好的创业者,一定得是一个好的产品经理. 而一个好的产品经理,一定不能完全对技术毫无所知,否则,你没有办法和程序员很好地合作.你会经常在和他们的交流里,出现"神马"问题.你会完全不知道,技术对你项目的支撑度.你在产品设计时,也会受到很多因为自己不懂技术,而对产品设计思路带来的禁锢.
我现在,就是一个初入道还不太合格的产品经理.我需要一步步提高自己.
总有人和我说,人过30不学艺. 那是胡说,任何时候,学任何东西都不晚.只要,你心里有梦.
说起用例图,我百度后看到的一个帖子,和iteye里nkshan的跟贴,真的是很深入浅出地做了描述.我很吃惊地发现,原来,有些问题也不难啊,我大多都能看懂嘛. http://www.cnblogs.com/chenqingwei/archive/2010/07/01/1769361.html
比如,第一段,描述什么是用例图的.
用例图是用来描述什么角色通过某某系统能做什么事情的图，用例图关系的是系统的外在表现，系统与人的交互，系统与其它系统的交互。
下面逐一说明用例图中各种符号的意义：
一\小人：
对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。
例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。
关于这段,我的感受和疑问是:
1.微博里用户关注的人,用户的粉丝这些,算不算不同角色呢?没有注册的用户,就是仅仅浏览的用户,算不算一种角色呢?注册了没有登录的用户算不算一种角色呢?
我好像设计的时候,一直都是直接以自己是一个用户,进入网站后,如何操作这样的流程在写需求文档,同时设计界面.好像,没有想象过很多角色的问题.
2.角色可能不算人,是另外的一个系统,这个,没例子,我还不太能理解.
3.呃,那个小人咋画出来的?
二\圈圈：
圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。按着这样的读法，我们可以得到两句完整的句子：
“一般员工打卡”
“一般员工查看自己的考勤情况”
大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。
这段我理解起来,没问题.
三\大框框：
在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。
系统边界能清晰表达出系统的范围，并不是所有的用例图都需要画出系统边界的，一般只需要在全局用例图中画出系统边界，当对用例进行细化时，不需要画出系统边界。
这段我理解起来好像也没问题.
四\线条：
线条是指角色与用例之间的线条，线条有三种：无箭头的，指向用例的箭头，指向角色的箭头。无论是否有箭头，这些线条是用来联系角色（小人）和用例（圈圈）的，表示某某角色能“做”什么用例。
有箭头的线条，表示角色与系统交互的过程中，数据的流向，如果箭头指向用例，就说明角色需要往系统输入数据，如果箭头指向角色，说明系统往角色输出数据。
而没有箭头的线条，则没有明确表示数据的流向，一般情况下不需要明确表示数据的流向，只需要画无箭头的线条就可以了。
这段里面,我的感受和疑问是:
"数据的流向，如果箭头指向用例，就说明角色需要往系统输入数据，如果箭头指向角色，说明系统往角色输出数据。"我觉得解释的很好,可是,我一下没想出 系统往角色输出数据是什么意思.是不是,比如 ,在我这里,一个用户,输入了一个旅行的数据, 这个数据,就和这个用户建立了某种关联,这个数据就属于这个用户的? 就是系统往角色输出数据?
第二段,是讲解用例图中的Extend、Include、继承
一\“打印报表”这个用例有一条指向“查看一般报表”用例的虚线，虚线上有“<<extend>>”的字样，这表示“打印报表”扩展了“查看一般报表”，用户可以在“打印报表”的基础上做“打印报表”的工作，这就是Extend的意思。如果“打印报表”这个用例不存在，是不会影响“查看一般报表”这个用例的，而“查看一般报表”这个用例如果不存在，则用户无法在“查看一般报表”的基础上做“打印报表”的工作了。
我的感受和疑问:
我发现,程序员和外行的思维看来真的不一样, 要是这个“打印报表”扩展了“查看一般报表",在我,就会是把箭头反过来画,是从"查看一般报表"指向"打印报表",因为,我会认为是 先"查看"了,再继续"打印". 箭头指向的,肯定是从箭头这边延伸出去的嘛.
哎呀,来自火星的程序员们.唉,他们先制定的规则,你就只有记住的份,不能改变那些约定俗成.
二\“管理数据”有三根虚线，箭头分别指向“查看数据”、“新增数据”、“修改数据”，虚线上有“<<include>>”字眼，这表示“管理数据”包含“查看数据”、“新增数据”、“修改数据”三个子用例，这就是Include的意思。在以下情况下，会用到Include：
1)某些用例的其中一些步骤可以单独抽离出来，成为一个子用例。
2)以“树”的方式条理化各种用例，用Include来组织好父子用例，子用例可以再次Include自己的子用例。
上图中将“管理数据”进一步分解为子用例，其实是没有必要的，实际项目中数据的查看、增加、修改、删除操作是很常见的，我们在描述用例的时候一般只需要将这4种操作说成“管理XX”就可以了。
我的感受和疑问:
啊,我明白了一个,刚刚我前面的疑问,那个虚线箭头虽然是方向和我想的相反,但人家是标了extend这词的.
唉,这个,分解子用例的例子,谁说没必要? 我之前,写需求时就没写这个.我也觉得这是理所当然地,根本就只顾写一步步主要的业务流程去了,就忘记写这个具体添加一个数据后,还需要编辑,删除,和继续添加了.等兼职的程序员做了后,我发现,.他没给我地方去编辑,也没删除.
还有感受,就是,这些类似的东西,我都用word文档写过的.我不会画表,采取的方式就是,用级别不同的标题来区分. 我自己要是在word里点文档结构图,觉得很明白. 可是,程序员们好像就是看不明白.看来,对他们来说,还是图表比word的文字容易明白.
三\细心的朋友可能会发现，角色与角色之间怎么会有一个类图中的“继承”符号呢？从上图看来，就是录入员继承一般用户，领导继承录入员，什么意思呢？
无论是录入员还是领导，都需要先登录系统，才能使用各种功能，我们是否需要分别在“登录用户”与“录入员”、“领导”之间各拉一条线？
一般用户可以查看一般报表、打印报表，那么录入员、领导是否也可以呢？
录入员这个角色继承了一般用户，其实就是表示一般用户能做的事情，录入员也能做，同意道理，录入员能做的事情，领导也能做，这个“继承”符号就是这个意思。在实际工作中，我们往往需要用好这个“继承”符号，将角色进行适当的抽象。
我的感受和疑问:
啊,刚刚看了半天,没看出这个"继承"和之前用例图里,描述角色和系统关系中的一种,有箭头的线条有什么区别,现在仔细看,这个"继承"的箭头,是一个空心的三角形的箭头.那个是一般的箭头.
这个东西好像用处不错,现在想起来,我之前学习使用mindmanager时,就遇到过,不同的角色和某个用例都有相同的关系时,就是很老土地每个角色都去和那个用例连起来.
不过,程序员们,是不是真的也懂这个符号啊? 不然,我懂,他们不懂,不也是白搭?
我的总结是,其实,画这图也好,我那样的word结构图也好,对于单方,比如我自己也好,程序员也好,如果自己思维清楚的话,其实都是一样能表达明白自己的需求和自己理解的需求的,本质区别其实不大. 在自己,也都只是起理清思路的作用,不是真正最后实现的效果.
如果,双方对对方word文档结构的表达方式的理解一致,用word,也一样能得到一样的交流和表达效果.
如果,对用例图的表达不熟悉,表示错误,可能双方一样沟通不好.
目前,在我自己,用这个用例图的意义,是,它从形式上看,可能会更抽象一些,更清楚一些,照我目前的理解是,也许程序员更习惯这样的方式一些. 我也许真要试着这样画画.
但最关键的是看,和自己准备合作的技术人员是不是真的也熟悉这个. 技术人员,也应该看自己团队的产品经理和其他产品经理是不是熟悉这个.
以前,我不熟悉这个,我其实应该也是看到过人给我画的类似的图的,我就是处于那种状态:看起来好像觉得人家表示的是对的,实际不知道人家是不是真的清楚和完全地表达了我要表达的东西.
所以,用双方都能懂的东西在图表和文字上交流. 然后,当面语言沟通说明.及时修改可能是最重要的.实在不行,就是各自用自己的表达方式表达,然后交流,然后接着用自己熟悉的方式记录. 交流明白,最重要.这个东西本身的表达方式,在你自己的记录那里,其实可能还没那种重要的意义.
四\用例图何时需要分解、何时不需要分解？
也就是分解的粒度通常情况下是多大呢？
用例的表达粒度是由自己控制的，以下几点建议供参考：
1.在客户能准确全面理解的基础上，用例约精简越好。
2.重点难点用例，应详细去描述。
3.用例需要开发人员去实现，要让开发人员能看懂。
4.用例图不是万能的，也不是表达需求的唯一方式，我往往会以用例图为主同时附加其它的表达方式来表达，某些特殊项目，我甚至不用用例图来描述需求。
我基本赞同理解这段. 不过,我在描述需求时,有时真不知道哪些该精简,哪些不提示程序员,他就会忘记,所以,写的杂而碎.
总之,在我, 自己理清思路时,这个图,意义还不算太大,但和程序员交流时,如果他们不能很好明白自己写的东西,或者因为,不太理解,而不能把我的需求自己比较清楚地转化成他们习惯的这种用例图,那么,我就应该尽量迁就他们, 由我自己尝试去画.毕竟,这可能是和行业内人士打交道通用的方式.
所以,我要试着学习画一下.
不过,希望,我不要因为不会画图,而弄错了一些真正自己想表达的东西,反给程序员带来误导.
所以,沟通,还是很重要.在沟通里,让他们修改图也行的.
下周,再表述一些片段时,我可以试着画这样的图.
虽然,我绝对不会真正去按技术人员的标准去学习,也绝对不会以外行的身份,真正对技术人员去指手画脚,但对一些基本技术概念的了解,还是非常需要的.
因为,我是在做自己想要做的东西,我并不是一个外包公司的客户,也不是一个所谓大公司的领导.不能简单地以外行的身份和人家讲完需求就了事. 你自己是创业者,是要把自己想要的东西和懂技术的人一起实现出来. 以我现在对互联网行业的了解,在具体这个项目实现的过程里,我的角色应该是产品经理. 我感受是,一个好的创业者,一定得是一个好的产品经理. 而一个好的产品经理,一定不能完全对技术毫无所知,否则,你没有办法和程序员很好地合作.你会经常在和他们的交流里,出现"神马"问题.你会完全不知道,技术对你项目的支撑度.你在产品设计时,也会受到很多因为自己不懂技术,而对产品设计思路带来的禁锢.
我现在,就是一个初入道还不太合格的产品经理.我需要一步步提高自己.
总有人和我说,人过30不学艺. 那是胡说,任何时候,学任何东西都不晚.只要,你心里有梦.
说起用例图,我百度后看到的一个帖子,和iteye里nkshan的跟贴,真的是很深入浅出地做了描述.我很吃惊地发现,原来,有些问题也不难啊,我大多都能看懂嘛. http://www.cnblogs.com/chenqingwei/archive/2010/07/01/1769361.html
比如,第一段,描述什么是用例图的.
用例图是用来描述什么角色通过某某系统能做什么事情的图，用例图关系的是系统的外在表现，系统与人的交互，系统与其它系统的交互。
下面逐一说明用例图中各种符号的意义：
一\小人：
对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。
例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。
关于这段,我的感受和疑问是:
1.微博里用户关注的人,用户的粉丝这些,算不算不同角色呢?没有注册的用户,就是仅仅浏览的用户,算不算一种角色呢?注册了没有登录的用户算不算一种角色呢?
我好像设计的时候,一直都是直接以自己是一个用户,进入网站后,如何操作这样的流程在写需求文档,同时设计界面.好像,没有想象过很多角色的问题.
2.角色可能不算人,是另外的一个系统,这个,没例子,我还不太能理解.
3.呃,那个小人咋画出来的?
二\圈圈：
圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。按着这样的读法，我们可以得到两句完整的句子：
“一般员工打卡”
“一般员工查看自己的考勤情况”
大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。
这段我理解起来,没问题.
三\大框框：
在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。
系统边界能清晰表达出系统的范围，并不是所有的用例图都需要画出系统边界的，一般只需要在全局用例图中画出系统边界，当对用例进行细化时，不需要画出系统边界。
这段我理解起来好像也没问题.
四\线条：
线条是指角色与用例之间的线条，线条有三种：无箭头的，指向用例的箭头，指向角色的箭头。无论是否有箭头，这些线条是用来联系角色（小人）和用例（圈圈）的，表示某某角色能“做”什么用例。
有箭头的线条，表示角色与系统交互的过程中，数据的流向，如果箭头指向用例，就说明角色需要往系统输入数据，如果箭头指向角色，说明系统往角色输出数据。
而没有箭头的线条，则没有明确表示数据的流向，一般情况下不需要明确表示数据的流向，只需要画无箭头的线条就可以了。
这段里面,我的感受和疑问是:
"数据的流向，如果箭头指向用例，就说明角色需要往系统输入数据，如果箭头指向角色，说明系统往角色输出数据。"我觉得解释的很好,可是,我一下没想出 系统往角色输出数据是什么意思.是不是,比如 ,在我这里,一个用户,输入了一个旅行的数据, 这个数据,就和这个用户建立了某种关联,这个数据就属于这个用户的? 就是系统往角色输出数据?
第二段,是讲解用例图中的Extend、Include、继承
一\“打印报表”这个用例有一条指向“查看一般报表”用例的虚线，虚线上有“<<extend>>”的字样，这表示“打印报表”扩展了“查看一般报表”，用户可以在“打印报表”的基础上做“打印报表”的工作，这就是Extend的意思。如果“打印报表”这个用例不存在，是不会影响“查看一般报表”这个用例的，而“查看一般报表”这个用例如果不存在，则用户无法在“查看一般报表”的基础上做“打印报表”的工作了。
我的感受和疑问:
我发现,程序员和外行的思维看来真的不一样, 要是这个“打印报表”扩展了“查看一般报表",在我,就会是把箭头反过来画,是从"查看一般报表"指向"打印报表",因为,我会认为是 先"查看"了,再继续"打印". 箭头指向的,肯定是从箭头这边延伸出去的嘛.
哎呀,来自火星的程序员们.唉,他们先制定的规则,你就只有记住的份,不能改变那些约定俗成.
二\“管理数据”有三根虚线，箭头分别指向“查看数据”、“新增数据”、“修改数据”，虚线上有“<<include>>”字眼，这表示“管理数据”包含“查看数据”、“新增数据”、“修改数据”三个子用例，这就是Include的意思。在以下情况下，会用到Include：
1)某些用例的其中一些步骤可以单独抽离出来，成为一个子用例。
2)以“树”的方式条理化各种用例，用Include来组织好父子用例，子用例可以再次Include自己的子用例。
上图中将“管理数据”进一步分解为子用例，其实是没有必要的，实际项目中数据的查看、增加、修改、删除操作是很常见的，我们在描述用例的时候一般只需要将这4种操作说成“管理XX”就可以了。
我的感受和疑问:
啊,我明白了一个,刚刚我前面的疑问,那个虚线箭头虽然是方向和我想的相反,但人家是标了extend这词的.
唉,这个,分解子用例的例子,谁说没必要? 我之前,写需求时就没写这个.我也觉得这是理所当然地,根本就只顾写一步步主要的业务流程去了,就忘记写这个具体添加一个数据后,还需要编辑,删除,和继续添加了.等兼职的程序员做了后,我发现,.他没给我地方去编辑,也没删除.
还有感受,就是,这些类似的东西,我都用word文档写过的.我不会画表,采取的方式就是,用级别不同的标题来区分. 我自己要是在word里点文档结构图,觉得很明白. 可是,程序员们好像就是看不明白.看来,对他们来说,还是图表比word的文字容易明白.
三\细心的朋友可能会发现，角色与角色之间怎么会有一个类图中的“继承”符号呢？从上图看来，就是录入员继承一般用户，领导继承录入员，什么意思呢？
无论是录入员还是领导，都需要先登录系统，才能使用各种功能，我们是否需要分别在“登录用户”与“录入员”、“领导”之间各拉一条线？
一般用户可以查看一般报表、打印报表，那么录入员、领导是否也可以呢？
录入员这个角色继承了一般用户，其实就是表示一般用户能做的事情，录入员也能做，同意道理，录入员能做的事情，领导也能做，这个“继承”符号就是这个意思。在实际工作中，我们往往需要用好这个“继承”符号，将角色进行适当的抽象。
我的感受和疑问:
啊,刚刚看了半天,没看出这个"继承"和之前用例图里,描述角色和系统关系中的一种,有箭头的线条有什么区别,现在仔细看,这个"继承"的箭头,是一个空心的三角形的箭头.那个是一般的箭头.
这个东西好像用处不错,现在想起来,我之前学习使用mindmanager时,就遇到过,不同的角色和某个用例都有相同的关系时,就是很老土地每个角色都去和那个用例连起来.
不过,程序员们,是不是真的也懂这个符号啊? 不然,我懂,他们不懂,不也是白搭?
我的总结是,其实,画这图也好,我那样的word结构图也好,对于单方,比如我自己也好,程序员也好,如果自己思维清楚的话,其实都是一样能表达明白自己的需求和自己理解的需求的,本质区别其实不大. 在自己,也都只是起理清思路的作用,不是真正最后实现的效果.
如果,双方对对方word文档结构的表达方式的理解一致,用word,也一样能得到一样的交流和表达效果.
如果,对用例图的表达不熟悉,表示错误,可能双方一样沟通不好.
目前,在我自己,用这个用例图的意义,是,它从形式上看,可能会更抽象一些,更清楚一些,照我目前的理解是,也许程序员更习惯这样的方式一些. 我也许真要试着这样画画.
但最关键的是看,和自己准备合作的技术人员是不是真的也熟悉这个. 技术人员,也应该看自己团队的产品经理和其他产品经理是不是熟悉这个.
以前,我不熟悉这个,我其实应该也是看到过人给我画的类似的图的,我就是处于那种状态:看起来好像觉得人家表示的是对的,实际不知道人家是不是真的清楚和完全地表达了我要表达的东西.
所以,用双方都能懂的东西在图表和文字上交流. 然后,当面语言沟通说明.及时修改可能是最重要的.实在不行,就是各自用自己的表达方式表达,然后交流,然后接着用自己熟悉的方式记录. 交流明白,最重要.这个东西本身的表达方式,在你自己的记录那里,其实可能还没那种重要的意义.
四\用例图何时需要分解、何时不需要分解？
也就是分解的粒度通常情况下是多大呢？
用例的表达粒度是由自己控制的，以下几点建议供参考：
1.在客户能准确全面理解的基础上，用例约精简越好。
2.重点难点用例，应详细去描述。
3.用例需要开发人员去实现，要让开发人员能看懂。
4.用例图不是万能的，也不是表达需求的唯一方式，我往往会以用例图为主同时附加其它的表达方式来表达，某些特殊项目，我甚至不用用例图来描述需求。
我基本赞同理解这段. 不过,我在描述需求时,有时真不知道哪些该精简,哪些不提示程序员,他就会忘记,所以,写的杂而碎.
总之,在我, 自己理清思路时,这个图,意义还不算太大,但和程序员交流时,如果他们不能很好明白自己写的东西,或者因为,不太理解,而不能把我的需求自己比较清楚地转化成他们习惯的这种用例图,那么,我就应该尽量迁就他们, 由我自己尝试去画.毕竟,这可能是和行业内人士打交道通用的方式.
所以,我要试着学习画一下.
不过,希望,我不要因为不会画图,而弄错了一些真正自己想表达的东西,反给程序员带来误导.
所以,沟通,还是很重要.在沟通里,让他们修改图也行的.
下周,再表述一些片段时,我可以试着画这样的图.