| 建胜（Dabao） 的个人资料☞Dabao·清香居：金融理财 & 电子商务 ...照片日志列表 |  工具  帮助 |
|
|
淘宝产品设计师：把“规范”当作“产品”来设计这次我要谈的是规范而不是产品设计。一直都在说设计需要规范，各大公司团队都有自己的规范，也会不断地更新和制定新的规范，但是执行难，效率低，力度弱却是规范的弊端。Angela提出了“理想设计规范的三条状态”，她指出规范的作用是满足使用者需要、满足协作需要以及提高团队效率，但是通常这些是制定者的理想，却是执行者的痛苦。
规范越复杂，流程就越复杂，执行起来就越困难。为什么会缺乏执行力？反过来想想，是不是我们制定的规范缺乏用户体验，让执行规范的“用户”感觉很难用。所以我提出来，要把规范当作产品来设计。
先分析一下现状。
现在的规范不外乎时间上的控制、流程上的把握、人员上的配合以及看上去的可行性。所以规范不是来制定某个设计需要多少注释和说明，而是让使用者能够有更多的时间关注更重要的东西，能够让协作来的更加轻松甚至是能够提高整个团队的效益比。如果你的规范是要求你的产物需要用绿色框来做标注，那么请停止，你的规范只会让使用者叫苦，却不会给团队带来太大的效益比。
再从执行方面来讲，规范是制定容易执行难。通常管理者和制定者不是同一个人，所以管理者会忽视制定者的主要意图，最后使规范荒废掉。之前提过的DQA的角色，TA是控制质量和效率的重要角色，TA是规范的执行者。但不是有了DQA我们就高枕无忧了，而且实际上DQA的角色对于很多公司来讲是一种负担，很多公司都把DQA的责任交给了设计总监，毕竟是总负责人，即有权又有能力。也就是说在没有规范的时候，设计总监就是规范！但我觉得把规范应该交给人文环境进行控制，而不是某个人来亲自执行。就像国家的禁塑令，在推出前很多人报以怀疑的态度，但是现在你去超市看看，大部分人都拎着自己的袋子，你还好意思去买塑料袋吗？这就是人文环境的影响。
最后现在的规范有一大块是关于文档等的记录。至少我就有很多文档模板，而且在做每件事的时候都会想到在文档里面应该怎么记录。周报日报一大堆，说是记录你所做的事情，但是回头看看，写了也就写了没有什么大的作用，最后久而久之就慢慢荒废了。文档要用的恰当好处，有些实在无法描述的说明还是需要进行相应的沟通，就好比网站的某些功能实在没法使用的时候还是需要客服电话，如果这时硬要用户去发邮件描述并安静等待的话，用户肯定会发疯。规范不是需要刻意记录的文档，大部分文档是在执行规范时的产物，类似于日志一样，只有部分输入输出物必备的文档才是需要去关注的。
现在我再次提出，把规范当作产品来做。通过分析使用人群和应用场景，对其进行投入产出比的配置规划，并且合理设计流程上的体验，在规范上线之后有效地制定升级包的计划和远期规划，以此来得到对执行者有更好体验的规范。
那么我们来试试看吧！拿我们的团队作为背景来进行规范的设计。
一、分析用户群
按照横向维度分，使用人群主要有产品设计师、视觉艺术家、内容策划师、前端开发工程师、用户测试员以及团队管理者，外围人群包括产品业务经理、需求分析师、系统分析师、系统开发工程师、项目经理、测试工程师、系统平台发布管理员等等。
按照垂直维度分，可分为被动接受（新手）、被动接受并有反馈（熟练）、主动执行（精通）、主动执行并推动产品升级（高级）、全力推行并负责升级（管理）。
二、应用场景
主要有业务相关项目、自发项目、日常需求三个。
三、需求分析
工作中每个角色间都有互动的关系，但并非是如下图的垂直传递互动。
图 1-1 垂直传递互动的关系
角色间的关系应该是互补的形式，下图是在业务相关项目下的范例：
图 1-2 互补型的互动关系
图中蓝色文字是互动的内容，蓝圈是UED团队的开发核心，红圈是业务方，黄圈是系统地层，橘圈是测试及产品发布服务。
从上图可以看出在完成一个项目，产品设计师是产品的核心，也就是说产品设计师是最终产品的决定者，TA除在完成本职任务以外，还肩负着协调和执行各方角色工作的任务。所以从规范来看，应该从产品设计师入手，并且散发到和每个触角的互动中去。
下面简单分析一下团队里面的产品设计师角色需求如下：
1、 根据项目（需求）的大小来灵活控制输出物；
2、 能够及时了解发展规划方面的行为动向；
3、 输入物的格式能够成为设计师的资源而不是阻碍；
4、 输出物可以让其他角色一目了然，尽量减少沟通的成本；
5、 在申请资源的同时希望能够及时落实并得到资源的反馈；
6、 能够清晰明确项目的进展等相关情况；
7、 对于产出物可以得到合理的评价体系支撑；
8、 对产品的远期有规划和标准执行方案；
9、 其他。
四、流程设计
这一步在传统的产品设计中是主要部分，当然在设计规范时也是最重要的部分，它决定了最后规范如何被执行，也预见了规范在执行时所遇到的问题和解决办法。
这里要做的就是把产品设计师的互动流程进行规范。分为三大块，分别是产品业务项目、自发项目、日常需求。
1、 产品业务项目：
由业务方发起的互动中需要包含一些市场数据和业务分析以及期望值，有明确的产品规划和目标，最后需要有BRD和详细产品描述资料。
接着在产品设计师的互动中，需要明确设计资源和时间点，明确产品内容、视觉以及前端的需求，并有能够直接指导开发工程师来完成产品概念的指导文档。最终要得到可用性评估测试的反馈和改进方法，以及产品规划方向的标准制定。
2、 自发项目：
由产品设计师自主发起的项目，在与业务方互动时，主要是得到一些现有数据，并且得到一些业务支持，在和其他角色合作时与产品业务项目时类似。
3、 日常需求
由需求方发起的日常需求，互动时需要双方遵守传递统一化的方式，并且在和前端、视觉、内容策划互动时，主要是确定资源和时间点的问题。
这里的流程没有细讲，主要是把关系和内容简单的整理了一下，在设计具体规范时还需要细化每个点的流程，特别是遇到问题的解决方法。
五、原型设计
这一步就是实施规范的撰写，方法有很多，但是我建议先从全局的出发，通过发散思维和流程设计的结果，再慢慢细化每个环节。除了文档以外，规范还需要角色间的培训和认知，并由管理者统一进行意见反馈和收集。
六、测试
也就是规范的试运行，尽量不要大面积使用，会使执行者产品疲倦感，最好使用AB test进行测试，得到较好的测试用例。
七、上线
经过一系列的反复测试和修改，最终的规范就发布上线，并由管理者来监督规范的执行情况，但管理员并不是来执行规范的主要角色，执行规范的永远是使用规范的“用户”以及相应的人文环境。
通过产品设计的方法出来的规范是符合个性化团队需求的，它也会像很多互联网产品一样成为每个公司团队独特风格的产品。百家争鸣只是第一步，最终的目的是希望能够在众多产品化规范中有一个能够成为整个行业的规范，把难执行的规范从封闭的团队中释放出来，让更多的人参与并得到行业标准解决方案才是产品化规范的最终目的。
评估UCH类型的SNS网站的传播性质/价值的技术路线目前，但凡说到SNS，就会联想到传播，甚至病毒式传播。但是，无意有意地忽略了一个事实，传播是有阻尼的。即使是病毒式传播，也有一个边界。以前采用了有高度指向性的APP建立一个便于内容传播的数据结构。但是，对于5G这样的SNS网站，这种方法不再适用。 UCH采用的是mysql数据库。不像其他商业化数据库，mysql没有数据挖掘功能，需要采用其他方法。 1、开发语言的选择 考虑到平台无关性，选择java语言进行开发。 PHP可以调用java类库与自定义类库。可以在UCH的数据处理那个PHP文件中增加调用。但是java类需要自己写的。 2、数据挖掘工具/方法 JDM API和Weka。 3、数据挖掘的目标 主要是评判SNS网站的传播特性，建立传播动力学模型。例如，什么样的内容更容易被传播。而且当用户的活动、内容与垂直SNS网站的主题无关时（出现水化现象），评估是否对SNS网站的运营造成影响，这个影响是正面的，还是负面的。需要注意的是，可能会受到突发事件、重大事件的影响，这属于稳定性的范畴。除此之外，还要找出相关的活跃社区及社区中心。通过量化SNS网站的传播特性，评估SNS网站的价值。通过发现相关的活跃社区及社区中心，可以帮助SNS网站的运行。 以上是第一步工作，后继包括关联挖掘，发现不同主题的传播方向与途径的交汇。根据SNS网站的发展方向（协作平台，或B2C平台），可能还有其它工作，有待以后进一步讨论。 4、小结 这里面有两个重要工作，一个数据挖掘的编程与数据处理，一个传播动力学的理论模型。两者缺一不可。由于数据挖掘的理论已经成熟，数据挖掘主要是编程这一块。传播动力学，主要是为SNS网站的经营者提供决策依据。 为什么要建立一个面向应用的拓扑结构层所谓面向应用的拓扑结构层，实际上是一种由SNS平台为特定APP开发的数据结构。这个数据结构维持了数据挖掘之后的结果。
一、观察
观察当前国内外的开放性的SNS平台/网站（以后简称为SNS网站），可以发现： 1、对于个人来说，SNS网站目前提供两种网络：一个是与好友形成的网络，一个是加入的群组。（本文把群组与好友形成的网络都简称为网络，除非特别说明） 2、个人用户还有两个隐性的网络：一个所在学校、公司、地区；一个是与其它安装同一个APP的用户。 3、个人用户也可以发起一个活动（Events），因而创建了一个网络。 4、这些信息都可以通过API获取（有些部分的）。
二、问题
那么，现在就有一个问题，APP开发者如何利用信息？目前可以调用的API： 1、friends.get，friends.getFriends，得到用户的好友列表。在整个好友网络中，是第一跳的（采用IP路由的术语）。 2、groups.getMembers，得到一个群组的成员列表。显然，这个群组是完全图。 3、users.getInfo，得到用户所在学校、公司、地区。 4、friends.getAppUsers，得到一个用户的指定APP的好友ID列表。 5、events.getMembers，得到一个活动的成员列表。
目前国内SNS网站只提供了三个API，分别是1、3、4。即使是facebook，也还在不断的改进中，例如，networks页不再提供，与中国文化不同。（对于中国的SNS网站，group相当于BBS的版块，而在中国，group有几个极需解决的问题，一个是水化，一个是潜水，一个是枪手）。（friends、group、app都是一个图，这三者属于重复定义，用户群交叉，容易使app开发者和用户感到困惑。事实上，目前SNS网站的大部分群组都极不活跃，目前的app的交互能力非常弱，关于这些问题的解决，有必要在数据结构与逻辑上重新定义，以后有时间再专门分析。）
我在5G上写过一个极其简单的脱离SNS平台的挖掘用户数据的方法： 1、数据准备，构建一个稀疏矩阵 2、进行连通性分析，将用户划分为子图。 3、补足，取得每个用户的好友信息，例如用户A的好友A1认识用户B的好友B1，则人为添加一个链路（方法1）。 如果用户A与用户B或者他们的好友同属于一个网络（目前SNS网站的叫法）或者群组，则作为一个连接（方法2）。 4、计算介数，并通过介数发现社区与社区中心。 5、为每一条边赋值（以相互浏览的和为权），构造一个无向图。 6、计算最大流/最小割，分析传播阻尼。
但是，这种方法对于用户数量较少的APP还可以。如果用户数量很大，这种方法就非常的不经济。虽然APP开发者自己可以缓存数据，由于用户关系等数据经常变动，如果还需要对用户日志等数据作进一步分析，那么就无法保证结果的精确性与有效性。因而对于用户数量巨大的APP，这种方法事实上不可行。偏偏这种APP的商业价值可能非常大。
三、分层的重要性
因此，只有由SNS网站进行数据分析和提供分析结果（姑且不论所用到的数据分析方法）：
1、建立一个数据结构
SNS网站如何向APP开发者提供分析处理之后的数据？单纯地提供几条API能够反映所得到的数据吗？对于一个APP而言，它的用户本身就构成了一个网络（图）。在进行用户分析后，所得到的数据的组织形式应该更进一步地体现网络（图）这种特性，并满足传播、交互、查询、用户加入、可扩展等相关的需求。
可以看到，APP用户是SNS网站全部用户的子集。当把这两个用户集合分别抽象为两个图时，为特定的APP建立的数据结构实际上就叠加在SNS层上。这也符合目前的三层架构。（本文暂且不讨论这个数据结构的具体细节）
2、这种数据结构的优势
相对于群组与好友网络，面向应用的拓扑结构具有这样一些优势。如果某个APP具有很强的粘性，可以说明这个APP的用户有很强的指向性。SNS之所以被广泛地关注，在于它形成一个泛化的全局好友网络，从而有可能用于消息传播与网络营销。哈佛大学的社会心理学家Stanley Milgram所设计的连锁信件实验常常被用来说明SNS的传播能力。但是，这是一种盲目搜索方法，开销大，代价高，过程不可控，用户需要花大量时间处理消息。与此相反，如果APP具有很强的粘性，并且在为APP建立数据结构时就考虑到这些情况，那么就可以实现有信息搜索。
3、视图的一致性
之所以单独列出这一条，是发现，当前的SNS网站有5种网络定义。虽然这5种网络定义，提供了更多的选择，但是，也造成一定的混乱。有的正在消失，例如，facebook不再提供network pages。据说国外BBS并不是太流行。并且在国内某些SNS网站上，绝大部分群组极度不活跃。目前，好友网络的活跃程度最高，压制了其它类型的网络。但是，由于好友网络的传播过程的不可控，直接商用难度很高。甚至有隐私之患（facebook因而取消了一个广告项目）。这里，并不是反对好友网络，相反，这正是SNS的来源。对于APP开发者来说，足以造成不必要的混乱。所以有必要提供视图的一致性。作为个人观点，不赞成APP主要地直接地依赖好友网络。
这一点还没有完全想好，应该与业务逻辑、代码复用有关，先放在这里吧（以后找机会再讨论）。
四、小结
本文主要讨论了在应用层与当前的SNS层之前建立一个面向应用的拓扑结构层的必要性。这个拓扑结构层实际上是一个数据结构。目前的SNS网络提供了5种网络，其中以好友网络最为活跃。但是，好友网络的传播过程的不可控，使得直接商用比较困难。而围绕粘性强的APP建立传播网络，可以利用APP的方向性。在建立这个数据结构时就考虑传播、交互、查询等要求。本文没有涉及到这种数据结构的具体细节，也没有包括建立这种数据结构所需的数据挖掘算法，有待以后进一步讨论。 简单的脱离SNS平台的发掘用户数据的方法1、数据准备，构建一个稀疏矩阵 2、进行连通性分析，将用户划分为子图。 3、补足，取得每个用户的好友信息，例如用户A的好友A1认识用户B的好友B1，则人为添加一个链路（方法1）。 如果用户A与用户B或者他们的好友同属于一个网络（目前SNS网站的叫法）或者群组，则作为一个连接（方法2）。 4、计算介数，并通过介数发现社区与社区中心。 5、为每一条边赋值（以相互浏览的和为权），构造一个无向图。 6、计算最大流/最小割，分析传播阻尼。 另眼看SNS的商业模式1、 我看SNS的商业模式 目前的SNS APP自发地而非自觉地利用社会网络的性质（邀请好友）。 所以，利用商业模式的要素论，假设开发这样一个SNS APP——为女性开发的瘦身APP工具（其它，旅行）： ² 价值主张：分为两个部分，一个是APP界面与功能，作为瘦身辅助工具；一个是理论部分，利用复杂网络与数据挖掘为APP用户建立社会支持。 瘦身辅助工具，包括APP界面与功能，比如瘦身日记、经验交流、心理互助、食品热量、团购服务等等。然后进一步提供其它信息，比如婚恋、服饰、家居、旅游，建立产品与服务的数据库等等。 而社会支持这个理论部分，是根据APP用户的特性，例如年龄、职业、性格、地域、爱好、阶段、体质等等，将特性相同或近似的用户形成一个簇群（性格可以互补），建立社会支持。为什么要提供社会支持，因为瘦身是一项长期的、艰苦的行为，很容易半途而废。虽然现在有学术论文对此作了研究，但目前的网络社区只有圈子功能，交流的效果非常有限，更谈不上社会支持。 ² 消费者目标群体：想瘦身的女性。从瘦身开始，然后是身体塑形，然后是健身等。因为她们自身有强烈的诉求，但是瘦身过程漫长，容易失去信心。所以不仅仅是要提供APP的界面与功能，更需要建立一个良好的社会支持。 APP的目标群体定位为需要瘦身的女性，这些用户的需求和特性也未必相同。SNS如何精确投放广告？是采用分类还是聚类进一步划分用户群？如何利用小世界网络的长程连接、得到的簇群如何组织，使得传播的阻尼更小？ ² 分销渠道：对于APP用户来说，APP的分销渠道当然是SNS平台。 但是对商业客户而言（从瘦身的产品和服务开始，逐渐进入其它领域），是采取点评网的加盟方式，还是采取代理方式，还是采用SaaS（提供CRM），根据发展阶段与时机而定。可以多准备几个方案。 ² 客户关系：如果客户指的是APP用户，那么APP开发商通过SNS平台与客户进行联系。而且SNS平台根据APP的需求对用户进行分析。这部分功能可以运行在SNS平台，或者运行在APP公司。从原则上，应该由SNS平台作为CRM提供给APP开发商及下游企业。 如果客户指的是那些提供产品或者服务的企业，可以由APP开发商自行解决，也可以由SNS平台提供。但是，从SNS平台与APP开发商的实力与整体利益出发，应该由SNS平台建立一个类似于阿里巴巴、阿里妈妈这样的体系结构。SNS平台及之上的APP应该逐渐发展成为SaaS。 ² 价值配置：即资源和活动的配置。这个我不懂，在商业模式这个语义中，资源与活动指的是什么？ ² 核心能力：前面把价值主张分为两个部分，一个是APP功能与界面，另一个部分是社会支持的建立。 APP功能与界面对于APP用户的体验非常关键。但是，APP功能与界面很容易被抄袭。这种情况的避免，依赖于SNS网站的用户聚集与挖掘的能力。按照APP用户的特性和需求，这些用户形成不同的簇群，从而获得社会支持。 ² 合作伙伴网络：自然，APP开发商与SNS平台成为合作伙伴。至于其它公司，比如广告设计、产品设计、生产厂商、服务商、各级代理等，也是合作伙伴网络的一部分。可以直接套用现有的成熟形式，不过更倾向于SaaS这样的形式。 ² 成本结构：即所使用的工具和方法的货币描述。这个我不会。 ² 收入模型：收入最终来源于相关产品和服务提供商。如何与APP开发商分成？APP开发商应该为这些高级功能付费？或者采用类似于现在的salesforce或阿里软件？ 如何将CRM、B2C、SaaS和广告这几种收入来源组合起来，保证可操作性？应避免分类信息网站的覆辙。
2、 理论部分 为SNS建立一个抽象的逻辑体系结构。第一层为SNS层，第二层是面向应用的拓扑结构层，第三层是应用层。
集中式SNS的抽象逻辑体系结构 2.1 应用层 在上面的示意图中，顶层为应用层。UGC、APP、游戏、娱乐、视频、文件共享等都在这一层。在应用层中实现社区的外在表现，如下图（不完整）。社区的定义等机制放在面向应用的拓扑结构层中实现。
瘦身APP的外观示意图（不完整、非正式） 2.2 SNS层 SNS层负责个人用户的信息的存储与维护，一般不直接用于各种应用的消息传递。考虑当前架构的兼容性，可以直接将既有的基于Web的SNS作为底层。
2.3 面向应用的拓扑结构层 所谓面向应用的拓扑结构层，在集中式的SNS网站中，是一个为APP创建的描述社区的定义与划分的数据结构。这个数据结构可能是一个层次结构，也可能是平面结构。 在拓扑结构层中，为每个APP选择/设计的一个聚类器和分类器，或关联等数据挖掘，将特性相近的用户形成不同簇群，并统计运营性数据： ² 满足用户社会性需求：通过APP表现出来的社会性用户需求各种各样，需要在拓扑结构层解决。例如，“坚持不下去了。继续寻找身高165CM/60-65KGS 的姐妹一起相互监督”。在形成簇群时，情况可能非常复杂。例如，有的人要求性格相同，而有的人可能要求性格互补。 ² 簇群尺寸：簇群的成员数量为N，而簇群为K连通，N大于等于K。也可以用簇系数来描述。簇群尺寸过小，可能没有足够的活跃用户。簇群尺寸过大，可能消息过多。 ² 静态还是动态：现有的APP可能有许多用户，那么对于已有的用户，簇群划分是静态的。如果是新加入的用户，是批量处理，还是实时处理？ ² 是否可以调整？用户是逐渐是增加的，而且用户可能自已迁移到另外一个簇群，如何利用这种自组织性？ ² 聚类与分类算法的选择、聚类器与分类器的设计，两者的结合使用。增量聚类与精度的权衡。算法的并行化、分布式化？ ² 在簇群划分过程中，如何利用小世界现象的长程连接？连通性如何保证（用户可以属于多个簇群，或者共享）？ ² 连通支配集如何用于簇群划分？是否采用权值，如果设定权值？ ² 最大流/最小割，是否可以有效地发现最佳传播通道？ ² 如何利用集中点？ ² 是否采用关联分析发现APP之间的关系？ ² 特定的消息组播？比如说，团购、聚会？ ² 查询/发现。在集中式的SNS，采用什么样的数据结构，包括内存与外存。 ² 围绕簇群，形成一个安全或隐私边界？ ² 运营性统计数据包括什么，类似于CRM？ ² 其它，包括营销手段？
2.4 基于P2P的SNS
分布式SNS的抽象逻辑体系结构 前面是集中式的SNS，或者基于Web的SNS。那么是不是可以考虑一下基于P2P的SNS（在IM客户端实现）： ² 用户习惯（在线用户数量与在线时长） 腾讯在2007年声称，QQ空间的单月活跃用户超过1亿，而QQ的同时在线用户量超过3000万。两者相差30倍。虽然没有两者在线时长的数据，但是大多数用户都是开机就运行QQ，因此有理由相信，QQ用户的在线时长也应超过QQspan Web 前端优化最佳实践Web 前端优化最佳实践之图象篇 http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_image.html
Web 前端优化最佳实践之 JavaScript 篇 http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_javascript.html
Web 前端优化最佳实践之 CSS 篇 http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_css.html
Web 前端优化最佳实践之 Cookie 篇 http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_server_cookie.html
Web 前端优化最佳实践之 Server 篇 http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_server.html
Web 前端优化最佳实践之内容篇 http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_content.html 网站建设项目流程概述一.概念
网站项目管理就是根据特定的规范、在预算范围内、按时完成的网站开发任务。
二.需求分析
项目立项
我们接到客户的业务咨询，经过双方不断的接洽和了解，并通过基本的可行性讨论够，初步达成制作协议，这时就需要将项目立项。较好的做法是成立一个专门的项目小组，小组成员包括：项目经理，网页设计，程序员，测试员，编辑/文档等必须人员。项目实行项目经理制。
客户的需求说明书
第一步是需要客户提供一个完整的需求说明。很多客户对自己的需求并不是很清楚，需要您不断引导和帮助分析。曾经有一次，我问客户：“您做网站的目的是什么？”他回答：“没有目的，只是因为别人都有，我没有！”。这样的客户就需要耐心说明，仔细分析，挖掘出他潜在的，真正的需求。 配合客户写一份详细的，完整的需求说明会花很多时间，但这样做是值得的，而且一定要让客户满意，签字认可。把好这一关，可以杜绝很多因为需求不明或理解偏差造成的失误和项目失败。糟糕的需求说明不可能有高质量的网站。那么需求说明书要达到怎样的标准呢？简单说，包含下面几点：
1.正确性：每个功能必须清楚描写交付的功能； 2.可行性：确保在当前的开发能力和系统环境下可以实现每个需求； 3.必要性：功能是否必须交付，是否可以推迟实现，是否可以在削减开支情况发生时"砍"掉； 4.简明性：不要使用专业的网络术语； 5.检测性：如果开发完毕，客户可以根据需求检测。 三.系统分析
网站总体设计
在拿到客户的需求说明后，并不是直接开始制作，而是需要对项目进行总体设计，详细设计，出一份网站建设方案给客户。总体设计是非常关键的一步。它主要确定：
1.网站需要实现哪些功能； 2.网站开发使用什么软件，在什么样的硬件环境； 3.需要多少人，多少时间； 4.需要遵循的规则和标准有哪些。 同时需要写一份总体规划说明书，包括：
1.网站的栏目和版块； 2.网站的功能和相应的程序； 3.网站的链接结构； 4.如果有数据库，进行数据库的概念设计； 5.网站的交互性和用户友好设计。 网站建设方案
在总体设计出来后，一般需要给客户一个网站建设方案。很多网页制作公司在接洽业务时就被客户要求提供方案。那时的方案一般比较笼统，而且在客户需求不是十分明确的情况下提交方案，往往和实际制作后的结果会有很大差异。所以应该尽量取得客户的理解，在明确需求并总体设计后提交方案，这样对双方都有益处。网站建设方案的包括以下几个部分：
1.客户情况分析； 2.网站需要实现的目的和目标； 3.网站形象说明； 4.网站的栏目版块和结构； 5.网站内容的安排，相互链接关系； 6.使用软件，硬件和技术分析说明； 7.开发时间进度表； 8.宣传推广方案； 9.维护方案； 10.制作费用； 11.本公司简介：成功作品，技术，人才说明等。 当您的方案通过客户的认可，那么恭喜你！您可以开始动手制作网站了。但还不是真正意义上的制作，你需要进行详细设计：
网站详细设计
总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化。详细设计主要是针对程序开发部分来说的。但这个阶段的不是真正编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该 包含必要的细节，例如：程序界面，表单，需要的数据等。程序员可以根据它们写出实际的程序代码。
四. 项目实施
整体形象设计
在程序员进行详细设计的同时，网页设计师开始设计网站的整体形象和首页。
整体形象设计包括标准字，Logo，标准色彩，广告语等。 首页设计包括版面，色彩，图像，动态效果，图标等风格设计，也包括banner，菜单，标题，版权等模块设计。首页一般设计1-3个不同风格，完成后，供客户选择。 记住：在客户确定首页风格之后，请客户签字认可。以后不得再对版面风格有大的变动，否则视为第二次设计。 开发制作
到这里，程序员和网页设计师同时进入全力开发阶段，需要提醒的是，测试人员需要随时测试网页与程序，发现Bug立刻记录并反馈修改。不要等到完全制作完毕再测试，这样会浪费大量的时间和精力。项目经理需要经常了解项目进度，协调和沟通程序员与网页设计师的工作。 调试完善
在网站初步完成后，上传到服务器，对网站进行全范围的测试。包括速度，兼容性，交互性，链接正确性，程序健壮性，超流量测试等，发现问题及时解决并记录下来。
为什么要记录文档呢？其实本软件工程本身就是一个文档，是一个不断充实和完善的标准。通过不断的发现问题，解决问题，修改，补充文档，使这个标准越来越规范，越来越工业化。进而使得网站开发趋向规范，趋向合理。 宣传推广
宣传推广的基本方法有：
1.网页里设置适当的META标签； 2.各搜索引擎优化登录； 3.准备新闻稿件在各新闻公告板发表； 4.合理使用Email邮件列表； 5.广告条交换； 6.付费广告。 至此，网站项目建设完毕，将有关网址，使用操作说明文档等提交客户验收。如果需要维护，另行签定维护项目。 维护
网站成功推出后，长期的维护工作才刚刚开始，我们需要做到的是
1.及时响应客户反馈；例如可以采取Email自动回复功能，然后在1-3个工作日里解决问题，再次回复； 2.网站流量统计分析和相应对策； 3.尽量推广和使用您的网址； 4.网站内容的及时更新和维护。 五.遵循的规范
1.网站建设目录规范 2.网站文件命名规范 3.网站建设尺寸规范 4.网站首页head区代码规范 5.网站连接结构规范 目录结构、文件名、URL、导航结构一般的网页设计都由网页设计师完成。设计师设计网站往往仅从美观、创意和易用的角度考虑，这对于一个期望获得搜索引擎排名优秀的商业网站来说，已经远远不够了，网站策划人员至少应该为设计师递交一份需求备忘录，提醒在设计中需要配合和注意的环节。 目录结构和URL
URL是统一资源定位，即每个网页的网址、路径。网站文件的目录结构直接体现于URL。清晰简短的目录结构和规范的命名不仅有利于用户体验和网址传播，更是搜索引擎友好的体现。
目录层次：
对于一个小型网站来说，一般只有一层子目录，如下：
http://www.12580.com/dir1/page.htm www.12580.com是域名，dir1是一级目录名，page是文件名。 对搜索引擎而言，这种单一的目录结构最为理想，即扁平结构（Flat）。 而对规模大一些的网站，往往需要二到三层子目录。象这样：
http://www.12580.com/dir1/dir2/dir3/page.htm搜索引擎还是会去抓取二到三层子目录下的文件，但最好不要超过3层，如果超过4层，象以下这个页面，搜索引擎就很难去搜索它了：http://www.12580.com/dir1/dir2/dir3/dir4/page.htm 当然，以下情况下，即使深入第四层甚至更深层次的页面，也同样能被搜索到：
1、如果该页提供了重要内容，有大量来自其它网站的外部链接（Inbound Links）；
2、如果在首页上增加一个该页的链接，可以通过首页直接到达，搜索Spider还是可以轻易地找到它；
3、如果有其它网站在顶级页面上链接了该页，其效果就好似你在自己的首页上做了该链接。
此外，图形、脚本、CGI-BIN和CSS样式表则各自建立专门的目录收入其中，一般不放在根目录下。
目录和文件命名：
根据关键字无所不在的原则,可以在目录名称和文件名称中使用到关键词。但如果是关键词组,则需要用分隔符分开。我们常用连字符"-"和下划线"_"进行分隔，URL中还经常出现空格码"%20"。因此，如果以"中国制造"作文件名,就可能出现以下三种分隔形式：
made-in-china.htm made_in_china.htm made%20in%20china.htm 但事实上，至少在目前Google并不认同"_"为分隔符。对Google来说， made-in-china和made%20in%20china都等于made in china，但made_in_china就被读成了madeinchina，连在一起之后，关键词就失去了意义。
因此，目录和文件名称如果有关键词组，要用连字符"-"而不是下划线"_"进行分隔。
URL应该越短越好。有人为了单纯增加关键字而额外建多一个带有关键字的子目录，改变目录结构。由于URL中含有关键字本身对排名提高帮助并不大，因而这种做法多此一举，也是搜索引擎反感的。
绝对URL和相对URL：
绝对URL：即网页路径使用包含顶级域名在内的完整的URL。
如：www.12580.com/page1/index.html是一个绝对路径，其中/page1/index.html则为相对路径，由浏览器自动在该链接前加上www.12580.com。 总体上，Google在排名时并不在意URL使用的是相对路径还是绝对路径。动态URL：目前很多网站都有数据库驱动生成的URL，即动态URL，往往表现为在URL中出现"?"、"="、"%"，以及"&"、"$"等字符。动态URL极不利于搜索引擎抓取网页，严重影响网站排名，通常是通过技术解决方案将动态URL转化成静态的URL形式，如：
将http://www.12580.com/messages.php?id=2&type=5 转化为http://www.12580.com/messages/2/5/ 下文将会专门提到动态URL的解决方案。 导航结构 网站导航是对引导用户访问网站的的栏目、菜单、在线帮助、布局结构等形式的统称。其主要功能在于引导用户方便地访问网站内容，是评价网站专业度、可用度的重要指标。同时对搜索引擎也产生诸多提示作用。概括地讲，网站在导航方面应注意以下几点：
1、主导航醒目清晰
主导航一般体现为一级目录，通过它们用户和蜘蛛程序都可以层层深入访问到网站所有重要内容。因此主栏目必须在网站首页第一屏的醒目位置体现，并最好采用文本链接而不是图片。 2、"面包屑型(Breadcrumbs)"路径
所谓"面包屑"是比喻用户通过主导航到目标网页的访问过程中的路径提示，使用户了解所处网站中的位置而不至于迷失"方向"，并方便回到上级页面和起点。路径中的每个栏目最好添加链接。 如下： 网信设计： 网信日志 > 技术资讯 > 网络营销
即使没有详细的路径来源，也至少应该在每个子页面提示回首页的链接，包括页面的LOGO作链接。
3、首页突出重要内容 除了主栏目，还应该将次级目录中的重要内容以链接的方式在首页或其它子页中多次呈现，以突出重点。搜索引擎会对这种一站内多次出现的链接给予充分重视，对网页级别（PageRank）提高有很大帮助，这也是每个网站首页的网页级别一般高于其它页面级别的重要因素，因为每个子页都对首页进行了链接。 12580.com路在何方？同质化时代的差异化源自什么？
持续创新！
我们需要杀手级的产品！
网站产品需求分析
【摘要】领导：“那个谁，我们要做一个全球最好的人肉搜索引擎。它不但能搜人，还要搜狗搜狐搜百度。你立刻组织人马大干一场！” 谁：“我顶——（你个肺）！我搜集具体的需求先。” 众所周知，网站的新产品或升级需求，通常是由领导者（CEO、COO、UFO……）提出的。而领导者一般只会给出目标和概念，无法提供细节描述。首先这不是他的职责，其次他没有时间，领导总是忙的（哦…哦…俯卧撑正做到第3个）。当然，最重要的是，他不是真正的用户。 作为产品经理、项目经理或需求分析师，需要与最初的构思人、实际操作者、面向用户群以及有类似产品经验的相关人员细致沟通。虽然你不一定在做爱做的事，但一定要交配交的人。这样才能了解到真实需求，设计开发出优秀的产品，打个漂亮仗。 一、地雷总埋在粗糙的需求中 为了节省时间不做详细的需求分析，往往会付出更多时间。由于敌情不明，设计开发过程中你会发现不断有新的需求冒出来，而且总是不停地在做修改。因为你不知道前面埋了多少雷，以及有多大，而且不是用鼠标玩扫雷可以解决的。 结果： 1、 你无法准确预估项目时间，老板对你很失望； 2、 你不能在规定的期限内完成，老板开始对你绝望； 3、 当你完成以后发现——其实一切才刚刚开始，上帝也绝望了； 4、 产品终于上线，需求方对你的满意度-100，信任度-150，合计250； 5、 最后一关，终极Boss（总是比你大很多倍那个）开始考虑该把你降职降薪还是炒个菜——鱿鱼； 6、 总之，你完了，你的团队也跟着你背黑锅。 唯一可以庆幸的就是，你不是炮兵炊事员，不用戴绿帽。不过，如果你经常为这个项目加班……咳咳，可能我没猜中结果。 二、你该侦查什么？ 知己知彼，百战不殆。你只有知道哪些情报对这次战斗是有用信息，才能打好仗。所以一定要施展你的三寸不烂之舌，把需求相关的问题重复一千遍，直到它变为真理。 情报： 1、 目标任务 领导者和构思人对这个产品的目标定义和期望，通常是概念性的需求，比如“为人民币服务”，好一点就是“我们要做一个人际关系社区”； 2、 用户需求 操作者和用户群肯定会用它做什么？可能做什么？和他们好好聊聊，确定他们不会在Twitter里面写Blog，做好任务分解； 3、 功能需求 需要开发人员实现哪些功能？一定要保证用户需求能够通过它们实现，往往操作方式和展现形式也要确定； 4、 非功能需求 除了功能性，产品需要达到什么标准，遵守什么规范？虽然我们不是性工作者，但总是不得不和性打交道，它们通常是—— 1) 可用性：某些时候可以叫易用性或者用户体验，比如它在不同浏览器能否正常显示？点击108次才能找到结果？等等 2) 可靠性：它会经常报错吗？有没有很黄很暴力的页面（比如.net开发的产品）？服务器宕机100遍啊100遍？硬盘挂了，你居然没有备份方案？故障转移方案需要手动还是自动？除此我们还需要考虑—— A. 安全性：每个用户都可以进行毁灭性操作吗？我们的核不扩散条约有否签订？来自外部的核客是否可以轻易的将我军消灭？ B. 事务性：是否需要让系统保存工作单元的 ACID 属性？ 百科一下：ACID，指数据库事务正确执行的四个基本要素的缩写.包含:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。一个支持交易(Transaction)的数据库系统，必需要具有这四种特性，否则在交易过程(Transaction processing)当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。 3) 有效性：你的任务可能是每天歼敌13亿，而现在只有两个编号8086的战场供你排兵布阵，年底的KPI肯定泡汤—— A. 性能：是否充分利用服务器资源？响应时间是多少（我们对上菜慢的餐馆深恶痛绝）？程序经过优化吗？有没有必要使用缓存？ B. 可伸缩性：一个人用就像在跑，十个人用就像在爬，它的设计是否支持高并发量？可以负载均衡或者复制系统线性扩展？是否存在瓶颈？ 4) 可维护性：是否需要建立维护规则？有升级的可能吗？潜在需求会改变现有架构吗？你确定不会因为一颗螺丝钉导致整台机器返工。 5) 可移植性：这个产品是否有特殊的部署要求，我们的山地步兵没法下海作战。 三、怎么做好侦察兵 沟通能力是优秀的产品经理和项目经理必不可少的一项能力。不过话说回来，力量越大，责任越大。你只有遵守以下军规，才能保证完成你的任务。 1、 尽量避免专业术语 你不是在构建巴比塔，所以在和需求方沟通时，必须使用他能听懂的语言。要假设他什么都不懂，包括你眼中的常识。但是，你必须能够听懂对方的专业术语，因为它们会在你的产品中用到。 2、 了解用户的专业领域和目标 你需要知道实际操作者是怎么工作的，以及为什么需要这个产品？尝试在他的岗位工作一段时间，恶补专业知识。如果有面向的用户群，就不能以单方面的需求为准，必须全面了解。 3、 合理的采纳需求 及时作出决定，对于用户的需求有条件要上，没有条件也要创造条件上。尽量不被客观理由限制，例如找技术上不能实现等借口。不过由于这是你和需求方达成的有效协议，所以对于不恰当的需求，要尊重技术做出的可行性分析和评估。 4、 实现功能的同时解决易用性 找出以前的产品（如果有）有什么优点和缺点，同类产品是怎么满足用户需求的。我们不需要“界面美观、操作方便、提高效率”这样的形容词，不能主观臆断，而是从用户哪儿了解他们对需求的具体定义及其特性。 5、 提供最好的解决方案 由于需求方对技术不了解，可能会提出一些错误的需求解决方法，例如逻辑上自相矛盾。你需要发挥专业优势，帮他找出最佳的产品设计、开发方案（可供选择），而不是一味地迁就。即便是你的领导，你也要敢于说不。 6、 划分需求的优先级 大部分产品最初的规划，都是庞大而复杂的。你需要配合需求方、开发人员对功能需求分级：必须的、重要且紧急的、紧急不重要的、重要不紧急的、不重要不紧急的。在没有足够的时间和人力来完成每个细节时，尊重开发人员的意见作出取舍。 7、 需求的变更要及时、谨慎评估 你应该预设规则避免或减少需求变更。越早发现需求的变更，带来的损失越小。因为夜长梦多……，而且用户在变更需求时，往往不知道会带来什么后果。你有必要跟他讲清楚利弊，包括时间、成本、性能、质量等等，帮助用户进行决策。 8、 沟通是个漫长的过程 要有足够的耐心和用户打交道，你可能随时需要他们的协助。只有保持不间断的沟通，才能减少不必要的修改。反复的修改原型页，就是最好的例子。 9、 做好需求分析报告 你搜集到的情报，要以多样化的文档形式来展现（包括原型页甚至设计稿），例如HTML、Word、PPT、PPG、LiuPP……它在设计、开发、测试等多个环节都会用到。 通俗易懂的文字和简洁明了的图表，能保证你的老板、老板的小蜜、设计制作、开发，以及智商低至25-高达250的用户都能看懂。 你必须保证图表上的每个元素都能被需求方理解，例如原型页的每块内容怎么调用，每个链接指向哪里，都做好详细说明。只有双方都能完全明白对方的意图，才能确保需求真实。 你还得保证报告中没有未知或待定的需求，一定要在第一时间沟通完毕。 10、评审需求分析 完成需求分析后，我们要请出需求方做出最后的确认。采用越正式的方式，需求方就会越认真的对待。当然最好的方式就是签字画押——拉勾，上吊，一百年不许变！ 四、侦察完成 当对方在需求分析报告上签字时，我们的侦查任务似乎就可以完成了。但不要忘记，军情瞬息万变，战斗才刚刚打响呢。 现实生活中，大部分签字者都不把这当回事儿。除非是有法律效应的文书，否则你就当他们在练习签名吧，如果可能的话还会附送唇印。 “你们需要我签，我才签的” “不签你们就不干活，我急着要呢” “我根本就没看懂，太信任你们了” 当然，你也可能反戈一击：“黑纸白字，再改我们可没门”。如果这是求你办事的兄弟部队，也许可以臭脸挡回去。换成是你的总司令呢？ 五千年的悠久历史告诉我们，如果你不能反抗，那么就默默的享受吧。签字的实质意义就是告诉你：“我认可当前的文档说明，如果有新的需求和更改，我们再一起商量时间、人力、金钱、美女吧”。 没有最好，只有更好。既然我们的目标就是满足用户需求，坚决完成任务。所以在产品上线以前，你仍然需要保持和用户的沟通，时刻通报最新进展。尽可能提供Demo给用户，让他们能够帮助我们完善需求和改进产品。 直到产品上线，我们才可以松一口气，高声大呼—— 改版尚未成功，同志仍需努力！ 什么情况下uv 会比ip少?IP：是指使用不同ip地址的用户访问网站的数量。同一IP不管访问了几个页面，独立IP数均为1，目前通行的做法是同一IP在24小时内访问只计数1次。这种做法是符合目前大多数广告投入者的计算习惯的； PV：页面浏览的人次计数，不同统计系统对此定义或多或少均不一样，主要是采取以下方法，即刷新一个页面即增加计数1，不管是否恶意刷新或连续刷新； UV：独立访客是指对不同用户计数，应该是只要被认定为不同的用户均应增加计数； 现在大多数的统计工具只统计到IP和PV的层面上，因为在大多情况下IP与UV数相差不大。但由于校园网络、企业机关等一些部门的特殊性，IP已经很难真实的反映网站的实际情况，所以引入了更加精确的UV这个概念。 所有UV与PV对于是使用真实IP上网的用户，数值是相同的。 但是如果访问你的站点中有通过“网络地址转换”（NAT）上网的用户，那么这两个值就不同的。 所有对于国内站长来说，这个UV值还是很有意义的。 什么情况下uv 会比ip少? 雅虎统计指数(YSR)：通过来源带来的pv、uv,ip，以及用户停留时间、访问情况、用户行为等因素综合分析按不同权重计算得到的，评判来源质量的指数，指数越高，表明来源质量越高。 57个常用GOOGLE 产品，你知道几个……谷歌的产品很多，有的真的没有听说过，你有多少个没有听说过的谷歌产品呢？ 必备
网站运营推广怎么做？
这是一个永恒的话题，也是最难解决的问题，其实大家完全可以静下心来，坚持做一些踏踏实实的工作的。 网站的定位是什么？哪些人应该是你的访客？你想让网民得到什么？有哪些内容会使得访客再次来？网站上有哪些内容会使得访客逗留？ 目前的网站有两种类型：第一种，为别人，即提供大多数人喜欢的内容；第二，为自己，即把自己喜欢的内容提供给别人。当你定位好自己的站点类型后，就要考虑哪些人该是你的访客。之所以要知道谁是你的访客，是因为在确定了访客喜好后，可以更有信心去提供合适的内容。 其实要让十万个人访问你网站，是很容易的，但想让这十万个人再访问你网站，就会很难。所以，我们必须思考，是什么会使得访客再次来。我总结了一些经验： 1.良好的用户体验 站在用户角度来体验一下自己的网站，看是否给用户提供了方便。不要狂热追求新技术，也不要懒的什么东西都不作，总之，用户至上。举了例子，对于网址站来说，通过Cookie记住用户常用的一些网站，这应该算一种很好的用户体验。 2.信息应随时更新 一个长时间不更新的站点，没有人会喜欢，搜索引擎也不喜欢。但对于有些站来说，首页不便于更新，但可以在内页进行更新，如RoyEC.com、shidaie.com,随即把用户需要的呈现给用户，从而留住用户。 3.提供有价值的内容 网络上，获取信息变得十分容易，所以如果你的站点能经常提供有价值的信息，将更能吸引访客，而如果你只是照搬别人的信息，时间长了，就会令访客感到厌倦。同样目前这点搜索引擎也很看重这点。 4.网站浏览速度一定要快 作为个人站点，在选择免费空间服务器时，要选择速度快的，而不是连接超时了，还没有见到半点动静的服务器。 5.网站设置一些交互的内容 越来越多的访客希望有互动的内容，他们不想只是看，还想动动手，在你的站点上加点什么，所以，增加一个BBS或者邮箱或留言簿，听听用户对您网站的看法，有可能的话可进一步和用户沟通。从而提供用户的黏性。 想要提升网站的流量，除了大力地砸钱做推广外，还有一种不花钱方法，也是一种网站运营推广永恒的方法：那就是SEO！很多人说起SEO，第一个直觉就是做“外部链接”。都认为SEO，很简单，不是门值得学习的网络学科。也有很多人反驳这样的说话，常说的一句话就是，“你自己去做个热门关键词试一试”。这就好比一部小说，喜欢这部书的人，疯狂的迷恋它，不喜欢它的人，网上发布条“不同的意见”，就会遭遇到大量“粉丝”抵制，说出他们戴在嘴边的一句话，“有本事你自己写一本啊”。 很多学科都这样，入门极易，想学精却很难，编程就是个很典型的例子。做SEO，就是研究搜索引擎的变化，摸索出搜索引擎的规律。尤其是国内的百度，他是抵制搜索优化的，他的算法也是变换最快的。 做搜索优化SEO的入门窍诀： 1.html 这是最基本的，必须要掌握的。了解Title，了解table，知道td和tr的区别，知道div为什么搜索会喜欢。它与table的区别在那(优化上)?对待关键词密度等方面各有那些优势。 2.页面设计 这里说的页面设计不是大家常说的美工，而是设计搜索的页面。当然了，你不能一味的迎合搜索，你还的考虑网站转换率(提高网站黏度，提高二次访问等)，用户习惯等。这些知识是必须的，一个合格的SEO从业者必须掌握的，也许你不会写代码，但是你得会画图，画一张你认为最合理的结构图，然后交给美工去做。 3.网站结构 明白域名的权重分布，树状目录合理分配。这里说的网站结构，特指用程序实现前台页面(如CMS)。对目录的命名的把握，对二级域名的合理选择，分类目录的名称，最终页面的内部互联等。全站优化，这方面是重点。 4.外部链接 记住，这是优化的根本之所在，也是搜索打击最严厉的。做优化，尤其是多个竞争对手也做了优化，那比的就是网站结构，网页结构以及高质量外链和内部互链等多方面因素。 SEO主要是和搜索打交道，所以你必须的会使用搜索引擎。很多人还局限在输入关键词直接搜索，找不到去论坛求救的阶段。
你得善于分析那些发布资料的人会怎么拟定标题，文章中一半包含了那些文字。慢慢研究，了解了用户搜索习惯，做优化会轻松很多，收入会高很多，公司不需要做外链的SEO，对那些会分析用户习惯的SEO，却是求知若渴。经常记录数据是个好习惯，以后你也可以“预言”。多观察，多对比，不要轻易下结论，有些时候个别现象很重要，更多的时候，它只是个“苦果”，正所谓尝过才知道，经验也是这样积累起来的。 6. 巧用META标签 META标签是HTML语言head区的一个辅助性标签，它用来描述一个HTML网页文档的属性，例如作者、日期和时间、网页描述、关键词、页面刷新等。它有两个属性，分别是HTTP标题信息(HTTP-EQUIV)和页面描述信息(NAME)。不同的属性又有不同的参数值，这些不同的参数值就实现了不同的网页功能。 我们在对网站进行搜索引擎优化(SEO)的时候，通常会用到name属性里的“Keywords”（关键词）和“description”（网页描述）两个参数。在主流的两个搜索引擎“百度”和“GOOGLE”中进行了长时间测试，发现百度搜索结果的排名和META标签中的内容有很大关系，在GOOGLE中也存在有一定的决定性作用，META标签在一个页面中的作用仅次于title。所以META标签的内容设计仍然是很重要的。 7.推广计划 推广本身也是一种策略，所以推广计划不仅是推广的行动指南，同时也是检验推广效果是否达到预期目标的衡量标准，建议大家做网站的时候要善于做计划，有了一份完善的推广计划，可以检查自己的策划能力和执行能力，在这过程当中自己会不断发现问题，不断解决问题，不断进步的。
12580.com又有新频道上线，欢迎使用！ 股市中人，对五月一般都怀着无数的憧憬，满眼尽是“红五月”、“5·19 ” ，职场中我也有了这种感觉：
职业很辛苦，但是我们很努力，而且一直在进步！
我很累，感觉给自己干也没有这么累，但是我很坚强。只有如此，日后才能从职业转变成事业！
同事其人：王兴华 老王——王兴华，为人谦和、低调。当然，也非常聪明。
在9588时，尽管不是我的直属领导，但是一起扛过枪——湖南银联手机钱包，一起奋斗过半年，取得了不俗成绩。后来，这个项目让老东家融资2000万美金。我们一分未得后，他去了51，我去了捷银，前后脚离开9588的。只可惜，身在上海的他现在非常成功：51的COO兼CTO。而我在捷银除了收获经验外，只能败回京城。
老王带兵的方法很好，人情味儿很浓。在我也充分学到了。
在长沙，身为湖南人的他带小弟我常逛长沙。去过橘子洲头，吃过洲中的农家菜；也爬过岳麓山，还在上面打过牌；去过千年书院——湖南大学，还“考察”了网吧渠道；当然，他还重点介绍“湘女多情”。
去南昌出差时，知道我那时很少出差，非要开南昌那时唯一的五星级酒店让我住，第二天还一起去过滕王阁。
老王技术出身，现在是COO兼CTO。当然，期间他也创业过。51看上去应该是接近成功了。
当以老王为榜样！
良禽择木而栖，良臣择主而事······
同一个行业·同一个梦想
谈论 话说产品经理
引用 话说产品经理 用例建模指南傅纯一, Rational中国区技术销售经理, IBM中国有限公司软件部 2004 年 11 月 01 日 用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。用例的使用在RUP中被推崇备至，整个RUP流程都被称作是"用例驱动"(Use-Case Driven)的，各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件，用例模型奠定了整个系统软件开发的基础。 在介始用例方法之前，我们首先来看一下传统的需求表述方式-"软件需求规约"(Software Requirement Specification)。传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。一个典型的软件需求规约可能具有以下形式： 采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。 功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。 从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。用例模型主要由以下模型元素构成：
这大三种模型元素在UML中的表述如下图所示。 以银行自动提款机(ATM)为例，它的主要功能可以由下面的用例图来表示。ATM的主要使用者是银行客户，客户主要使用自动提款机来进行银行帐户的查询、提款和转帐交易。 通讯关联表示的是参与者和用例之间的关系，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者；如果你不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。在参与者和用例之间的信息流不是由通讯关联来表示的，该信息流是缺省存在的（用例本身描述的就是参与者和系统之间的对话），并且信息流向是双向的，它与通讯关联箭头所指的方向亳无关系。 用例图使我们对系统的功能有了一个整体的认知，我们可以知道有哪些参与者会与系统发生交互，每一个参与者需要系统为它提供什么样的服务。用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流来描述这一对话的细节内容。如在ATM系统中的"提款"用例可以用事件流表述如下： 提款-基本事件流 1. 用户插入信用卡 2. 输入密码 3. 输入提款金额 4. 提取现金 5. 退出系统，取回信用卡 但是这只描述了提款用例中最顺利的一种情况，作为一个实用的系统，我们还必须考虑可能发生的各种其他情况，如信用卡无效、输入密码错、用户帐号中的现金余额不够等，所有这些可能发生的各种情况（包括正常的和异常的）被称之为用例的场景(Scenario)，场景也被称作是用例的实例(Instance)。在用例的各种场景中，最常见的场景是用基本流(Basic Flow)来描述的，其他的场景则是用备选流(Alternative Flow)来描述。对于ATM系统中的"提款"用例，我们可以得到如下一些备选流： 提款-备选事件流 备选流一：用户可以在基本流中的任何一步选择退出，转至基本流步骤5。 备选流二：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用例结束。 备选流三：在基本流步骤２中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三次输入密码错误后，信用卡被系统没收，用例结束。 … 通过基本流与备选流的组合，就可以将用例所有可能发生的各种场景全部描述清楚。我们在描述用例的事件流的时候，就是要尽可能地将所有可能的场景都描述出来，以保证需求的完备性。 用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者（抽象成为Actor），这些使用者与被定义系统发生交互；针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务（抽象成为Use Case），或者说系统是如何被这些参与者使用的。所以从用例图中，我们可以得到对于被定义系统的一个总体印象。 与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。用例方法比传统的SRS更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。 在RUP中，用例被作为整个软件开发流程的基础，很多类型的开发活动都把用例作为一个主要的输入工件(Artifact)，如项目管理、分析设计、测试等。根据用例来对目标系统进行测试，可以根据用例中所描述的环境和上下文来完整地测试一个系统服务，可以根据用例的各个场景(Scenario)来设计测试用例，完全地测试用例的各种场景可以保证测试的完备性。
使用用例的方法来描述系统的功能需求的过程就是用例建模，用例模型主要包括以下两部分内容：
在用例建模的过程中，我们建议的步聚是先找出参与者，再根据参与者确定每个参与者相关的用例，最后再细化每一个用例的用例规约。 所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手：
这些问题有助于我们抽象出系统的参与者。对于ATM机的例子，回答这些问题可以使我们找到更多的参与者：操作员负责维护和管理ATM机系统、ATM机也需要与后台服务器进行通讯以获得有关用户帐号的相关信息。 2.1.1 系统边界决定了参与者 参与者是由系统的边界所决定的，如果我们所要定义的系统边界仅限于ATM机本身，那么后台服务器就是一个外部的系统，可以抽象为一个参与者。 如果我们所要定义的系统边界扩大至整个银行系统，ATM机和后台服务器都是整个银行系统的一部分，这时候后台服务器就不再被抽象成为一个参与者。 值得注意的是，用例建模时不要将一些系统的组成结构作为参与者来进行抽象，如在ATM机系统中，打印机只是系统的一个组成部分，不应将它抽象成一个独立的参与者；在一个MIS管理系统中，数据库系统往往只作为系统的一个组成部分，一般不将其单独抽象成一个参与者。 2.1.2 特殊的参与者――系统时钟 有时候我们需要在系统内部定时地执行一些操作，如检测系统资源使用情况、定期地生成统计报表等等。从表面上看，这些操作并不是由外部的人或系统触发的，应该怎样用用例方法来表述这一类功能需求呢？对于这种情况，我们可以抽象出一个系统时钟或定时器参与者，利用该参与者来触发这一类定时操作。从逻辑上，这一参与者应该被理解成是系统外部的，由它来触发系统所提供的用例对话。 找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可以从以下问题入手（针对每一个参与者）：
综合以上所述，ATM系统的用例图可表示如下， 在用例的抽取过程中，必须注意：用例必须是由某一个主角触发而产生的活动，即每个用例至少应该涉及一个主角。如果存在与主角不进行交互的用例，就可以考虑将其并入其他用例；或者是检查该用例相对应的参与者是否被遗漏，如果是，则补上该参与者。反之，每个参与者也必须至少涉及到一个用例，如果发现有不与任何用例相关联的参与者存在，就应该考虑该参与者是如何与系统发生对话的，或者由参与者确定一个新的用例，或者该参与者是一个多余的模型元素，应该将其删除。 可视化建模的主要目的之一就是要增强团队的沟通，用例模型必须是易于理解的。用例建模往往是一个团队开发的过程，系统分析员在建模过程中必须注意参与者和用例的名称应该符合一定的命名约定，这样整个用例模型才能够符合一定的风格。如参与者的名称一般都是名词，用例名称一般都是动宾词组等。 对于同一个系统，不同的人对于参与者和用例都可能有不同的抽象结果，因而得到不同的用例模型。我们需要在多个用例模型方案中选择一种"最佳"（或"较佳"）的结果，一个好的用例模型应该能够容易被不同的涉众所理解，并且不同的涉众对于同一用例模型的理解应该是一致的。 应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述――用例规约所组成的。RUP中提供了用例规约的模板，每一个用例的用例规约都应该包含以下内容：
用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明。只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如活动图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的系统行为，序列图适合于描述基于时间顺序的消息传递。 2.3.1 基本流 基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。我们建议用以下格式来描述基本流： 1) 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。 2) 用一句简短的标题来概括每一步骤的主要内容，这样阅读者可以通过浏览标题来快速地了解用例的主要步骤。在用例建模的早期，我们也只需要描述到事件流步骤标题这一层，以免过早地陷入到用例描述的细节中去。 3) 当整个用例模型基本稳定之后，我们再针对每一步骤详细描述参与者和系统之间所发生的交互。建议采用双向(roundtrip)描述法来保证描述的完整性，即每一步骤都需要从正反两个方面来描述:(1)参与者向系统提交了什么信息；(2)对此系统有什么样的响应。具体例子请参见附录。 在描述参与者和系统之间的信息交换时，需指出来回传递的具体信息。例如，只表述参与者输入了客户信息就不够明确，最好明确地说参与者输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内，可以在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。 2.3.2 备选流 备选流负责描述用例执行过程中异常的或偶尔发生的一些情况，备选流和基本流的组合应该能够覆盖该用例所有可能发生的场景。在描述备选流时，应该包括以下几个要素： 1) 起点：该备选流从事件流的哪一步开始； 2) 条件：在什么条件下会触发该备选流； 3) 动作：系统在该备选流下会采取哪些动作； 4) 恢复：该备选流结束之后，该用例应如何继续执行。 备选流的描述格式可以与基本流的格式一致，也需要编号并以标题概述其内容，编号前可以加以字母前缀A(Alternative)以示与基本流步骤相区别。 2.3.3 用例场景 用例在实际执行的时候会有很多的不同情况发生，称之为用例场景；也可以说场景是用例的实例，我们在描述用例的时候要覆盖所有的用例场景，否则就有可能导致需求的遗漏。在用例规约中，场景的描述可以由基本流和备选流的组合来表示。场景既可以帮助我们防止需求的遗漏，同时也可以对后续的开发工作起到很大的帮助：开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。 2.3.4 特殊需求 特殊需求通常是非功能性需求，它为一个用例所专有，但不适合在用例的事件流文本中进行说明。特殊需求的例子包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性（包括可用性、可靠性、性能或支持性需求等）。此外，其他一些设计约束，如操作系统及环境、兼容性需求等，也可以在此节中记录。 需要注意的是，这里记录的是专属于该用例的特殊需求；对于一些全局的非功能性需求和设计约束，它们并不是该用例所专有的，应把它们记录在《补充规约》中。 2.3.5 前置和后置条件 前置条件是执行用例之前必须存在的系统状态，后置条件是用例一执行完毕后系统可能处于的一组状态。 用例模型完成之后，可以对用例模型进行检查，看看是否有遗漏或错误之处。主要可以从以下几个方面来进行检查：
RUP中根据FURPS+模型将系统需求分为以下几类：
除了第一项功能性需求之外的其他需求都归之为非功能性需求。 用例模型主要用于描述系统的功能性需求，对于其他的非功能性需要用其他文档来记录。RUP中定义了如下的需求工件集合。
在实际应用中，除了这些工件之外，我们还可以根据实际需求灵活选用其他形式的文档来补充说明需求。并不是所有的系统需求都适保合用用例模型来描述的，如编译器，我们很难用用例方法来表述它所处理的语言的方法规则，在这种情况下，采用传统的BNF范式来表述更加合适一些。在电信软件行业中，很多电信标准都是采用SDL语言来描述的，我们也不必用UML来改写这些标准（UML对SDL存在着这样的兼容性），只需将SDL形式的电信标准作为需求工件之一，在其他工件中对其加以引用就可以了。总之，万万不可拘泥于用例建模的形式，应灵活运用各种方式的长处。 补充规约记录那些在用例模型中不易表述的系统需求，主要包括以下内容。
记录系统性能相关的各种指标，包括：
定义所有与系统的可支持性或可维护性相关的需求，其中包括编码标准、命名约定、类库、如何来对系统进行维护操作和相应的维护实用工具等。 设计约束代表已经批准并必须遵循的设计决定，其中包括软件开发流程、开发工具、系统构架、编程语言、第三方构件类库、运行平台和数据库系统等等。 词汇表主要用于定义项目特定的术语，它有助于开发人员对项目中所用的术语有统一的理解和使用，它也是后续阶段中进行对象抽象的基础。
在一般的用例图中，我们只表述参与者和用例之间的关系，即它们之间的通讯关联。除此之外，我们还可以描述参与者与参与者之间的泛化(generalization)、用例和用例之间的包含(include)、扩展(extend)和泛化(generalization)关系。我们利用这些关系来调整已有的用例模型，把一些公共的信息抽取出来重用，使得用例模型更易于维护。但是在应用中要小心选用这些关系，一般来说这些关系都会增加用例和关系的个数，从而增加用例模型的复杂度。而且一般都是在用例模型完成之后才对用例模型进行调整，所以在用例建模的初期不必要急于抽象用例之间的关系。 参与者之间可以有泛化(Generalization)关系（或称为"继承"关系）。例如在需求分析中常见的权限控制问题（如下图所示），一般的用户只可以使用一些常规的操作，而管理员除了常规操作之外还需要进行一些系统管理工作，操作员既可以进行常规操作又可以进行一些配置操作。 在这个例子中我们会发现管理员和操作员都是一种特殊的用户，他们拥有普通用户所拥有的全部权限，此外他们还有自己独有的权限。这里我们可进一步把普通用户和管理员、操作员之间的关系抽象成泛化(Generalization)关系，管理员和操作员可以继承普通用户的全部特性（包括权限），他们又可以有自己独有的特性（如操作、权限等）。这样可以显著减速少用例图中通讯关联的个数，简化用例模型，使之更易于理解。 用例描述的是系统外部可见的行为，是系统为某一个或几个参与者提供的一段完整的服务。从原则上来讲，用例之间都是并列的，它们之间并不存在着包含从属关系。但是从保证用例模型的可维护性和一致性角度来看，我们可以在用例之间抽象出包含(include)、扩展(extend)和泛化(generalization)这几种关系。这几种关系都是从现有的用例中抽取出公共的那部分信息，然后通后过不同的方法来重用这部公共信息，以减少模型维护的工作量。 4.2.1 包含(include) 包含关系是通过在关联关系上应用<<include>>构造型来表示的，如下图所示。它所表示的语义是指基础用例(Base)会用到被包含用例(Inclusion)，具体地讲，就是将被包含用例的事件流插入到基础用例的事件流中。 包含关系是UML1.3中的表述，在UML1.1中，同等语义的关系被表述为使用(uses)，如下图。 在ATM机中，如果查询、取现、转帐这三个用例都需要打印一个回执给客户，我们就可以把打印回执这一部分内容提取出来，抽象成为一个单独的用例"打印回执"，而原有的查询、取现、转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动一个用例，而不用在每一个用例都作相应修改，这样就提高了用例模型的可维护性。 在基础用例的事件流中，我们只需要引用被包含用例即可。 查询-基本事件流 1. 用户插入信用卡 2. 输入密码 3. 选择查询 4. 查看帐号余额 5. 包含用例"打印回执" 6. 退出系统，取回信用卡 在这个例子中，多个用例需要用到同一段行为，我们可以把这段共同的行为单独抽象成为一个用例，然后让其他的用例来包含这一用例。从而避免在多个用例中重复性地描述同一段行为，也可以防止该段行为在多个用例中的描述出现不一致性。当需要修改这段公共的需求时，我们也只需要修改一个用例，避免同时修改多个用例而产生的不一致性和重复性工作。 有时当某一个用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。 4.2.2 扩展(extend) 扩展（extend）关系如下图所示，基础用例(Base)中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。对于包含关系而言，子用例中的事件流是一定插入到基础用例中去的，并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流，并且插入点可以有多个。 例如对于电话业务，可以在基本通话(Call)业务上扩展出一些增值业务如：呼叫等待(Call Waiting)和呼叫转移(Call Transfer)。我们可以用扩展关系将这些业务的用例模型描述如下。 在这个例子中，呼叫等待和呼叫转移都是对基本通话用例的扩展，但是这两个用例只有在一定的条件下（如应答方正忙或应答方无应答）才会将被扩展用例的事件流嵌入基本通话用例的扩展点，并重用基本通话用例中的事件流。 值得注意的是扩展用例的事件流往往可以也可抽象为基础用例的备选流，如上例中的呼叫等待和呼叫转移都可以作为基本通话用例的备选流而存在。但是基本通话用例已经是一个很复杂的用例了，选用扩展关系将增值业务抽象成为单独的用例可以避免基础用例过于复杂，并且把一些可选的操作独立封装在另外的用例中。 4.2.3 泛化(generalization) 当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。 以下是一个用例泛化关系的例子，执行交易是一种交易抽象，执行房产交易和执行证券交易都是一种特殊的交易形式。 用例泛化关系中的事件流示例如下： 用例模型建成之后，我们可以对用例模型进行检视，看是否可以进一步简化用例模型、提高重用程度、增加模型的可维护性。主要可以从以下检查点(checkpoints)入手:
一般小型的系统，其用例模型中包含的参与者和用例不会太多，一个用例图就可以容纳所有的参与者，所有的参与者和用例也可以并存于同一个层次结构中。对于较复杂的大中型系统，用例模型中的参与者和用例会大大增加，我们需要一些方法来有效地管理由于规模上升而造成的复杂度。 包(Package)是UML中最常用的管理模型复杂度的机制，包也是UML中语义最简单的一种模型元素，它就是一种容器，在包中可以容纳其他任意的模型元素（包括其他的包）。在用例模型中，我们可以用构造型(Sterotype)<<use case>>来扩展标准UML包的语义，这种新的包叫作用例包(Use Case Package)，用于分类管理用例模型中的模型元素。 我们可以根据参与者和用例的特性来对它们进行分类，分别置于不同的用例包管理之下。例如对于一个大型的企业管理信息系统，我们可以根据参与者和用例的内容将它们分别归于人力资源、财务、采购、销售、客务服务这些用例包之下。这样我们将整个用例模型划分成为两个层次，在第一层次我们看到的是系统功能总共分为五部分，在第二层次我们可以分别看到每一用例包内部的参与者和用例。 一个用例模型需要有多少个用例包取决你想怎么样来管理用例模型的复杂度（包括参与者和用例的个数，以及它们之间的相互关系）。UML中的包其实就类似于文件系统中的目录，文件数量少的时候不需要额外的目录，文件数量一多就需要有多个目录来分类管理，同样一组文件不同的人会创建不同的目录结构来进行管理，关键是要保证在目录结构下每一个文件都要易于访问。同样的道理存在于用例建模之中，如何创建用例包以及用例包的个数取决于不同的系统和系统分析员，但要保证整个用例模型易于理解。 我的系统需要有多少个用例？这是很多人在用例建模时会产生的疑惑。描述同一个系统，不同的人会产生不同的用例模型。例如对于各种系统中常见的"维护用户"用例，它里面包含了添加用户、修改用户信息、删除用户等操作，这些操作在该用例的事件流可以表述成为基本流的子事件流(subflow)。 维护用户-基本事件流 该基本流由三个子事件流构成： 1) 添加用户子事件流 2) 修改用户 子事件流 3) 删除用户子事件流 但是你也可以根据该用例中的具体操作把它抽象成为三个用例，它所表示的系统需求和单个用例的模型是完全一样的。 应该如何确定用例的粒度呢？在一次技术研讨会上，有人问起Ivar Jacoboson博士，一个系统需要有多少个用例？大师的回答是20个，当然他的意思是最好将用例模型的规模控制在几十个用例左右，这样比较容易来管理用例模型的复杂度。在用例个数大致确定的条件下，我们就很容易来确定用例粒度的大小。对于较复杂的系统，我们需要控制用例模型一级的复杂度，所以可以将复杂度适当地移往每一个用例的内部，也就是让一个用例包含较多的需求信息量。对于比较简单的系统，我们则可以将复杂度适度地曝露在模型一级，也就是我们可以将较复杂的用例分解成为多个用例。 用例的粒度不但决定了用例模型级的复杂度，而且也决定了每一个用例内部的复杂度。我们应该根据每个系统的具体情况，因时因宜地来把握各个层次的复杂度，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目。 用例图的主要作用是描述参与者和用例之间的关系，简单的系统中只需要有一个用例图就可以把所有的关系都描述清楚。复杂的系统中可以有多个用例图，例如每个用例包都可以有一个独立的用例图来描述该用例包中所有的参与者和用例的关系。 在一个用例模型中，如果参与者和用例之间存在着多对多的关系，并且他们之间的关系比较复杂，如果在同一个用例图中表述所有的参与者和用例就显得不够清晰，这时我们可创建多个用例图来分别表示各种关系。 如果想要强调某一个参与者和多个用例的关系，你就可以以该参与者为中心，用一个用例图表述出该参与者和多个用例之间的关系。在这个用例图中，我们强调的是该参与者会使用系统所提供的哪些服务。 如果想要强调某一个用例和多个参与者之间的关系，你就可以以该用例为中心，用一个用例图表述出该用例和多个参与者之间的关系。在这个用例图中，我们强调的是该用例会涉及到哪些参与者，或者说该用例所表示的系统服务有哪些使用者。 总之在用例建模过程中，你可以根据自己的需要创建任意多个用例图，用不同的用例来强调参与者和用例之间不同的关系。但是最重要的是要考虑整个用例模型的可理解性，如果可以用一个用例图把意思表述清楚，就不要再用第二个，因为越是简洁的模型越易于理解。
谈论 tx234
这位朋友给我发信息了，追踪后看了其SPACE，很不错。两篇文章中读出的是扎实的理论功底、很强的上进心、清晰的定位，更关键的是，他能发现了自己的不足。 希望此仁兄（正在想办法变为仁兄）日后能成为一位超级优秀的产品经理，毕竟TX给其一个非常不错的平台，他可以从很多优秀的团队成员学到更多知识、技能。
引用 tx234 转载：Web标准的web UIWeb标准的web UI——来源、谬误与个人理解 序 我从2004年末开始接触web标准，2005年5月正式采取完全的web标准方式的网页制作，2005年8月，第一个符合web标准的网站UI开发工作完成。直至今日，经历了无数的艰辛，也有过许多的困惑。所幸，我的瑞典籍的Project Leader是一个很有经验的人，他告诉了我很多关于web标准国内并不了解的东西，我这几年技术方面的成长离不开他的支持和引导，感谢Andreas Liljefilt！在这里，我把它们告诉大家，也希望能有更多的人来讨论。 Chaper 1 什么是web标准？Div+css的谬误。 提到web标准，就不得不先说一说国内业界非常流行的一个词——Div+css。这个词在国内简直是一个潮流，不仅互联网上一直在提，大量的教程中使用这个词，就连一些出版的书籍也是用了这个概念。然而，甚少人知道的是，这个概念本身是错误的。有好事的朋友不妨去google搜索一下（先调整到英文界面，这样可以强制让它搜索google.com而不是google.cn），"div+css"这样一个关键字是根本找不到任何一个英文网页，全部都是中文的。没错，其实所谓的div+css就是一个中国特有的理解和概念。我甚至不知道这个词是谁先提出来的，然而，它对web标准中xhtml/css的网页构建方法的理解几乎是完全错误的。 回归正题，web标准究竟是什么？Web标准是w3c组织规定的各种web上所使用的语言的标准和规范的集合。 我们目前究竟接触到了web标准的多少？打开 w3c的官方网站，我们在左侧可以看到如下列表： 引用: 全看下来后是不是觉得很晕？没错，这个就是web标准目前的全部技术规范。web标准包含了这么多的内容，而我们目前所说的div+css只是其中xhtml/css实现方式的不完整的一部分而已。 * 为什么是xhtml/css？ 其他的部分，我不想说的太多，第一是因为我也没办法全都弄懂，第二是其中有一大半浏览器支持不完全甚至根本就不支持。XML是web标准中对网页实现的最终目标。也就是web页面数据化和语义化，然而由于浏览器的支持不完善和兼容问题，目前优秀、兼容性强的纯xml网站只是停留在幻想里而已。因此，现在主流的网页实现方式就是xhtml/css。首先，xhtml与html大部分兼容，并且可以让目前大多数的浏览器直接阅读。css主流的几大浏览器也支持的非常完善。再加上ECMAScript(不说Javascript的原因是Javascript的概念中包含了很多与标准不同的浏览器私有定义)，已经足够实现web UI布局的大部分需要了。 Chapter 2 web标准真的是要完全不用表格？ 好像是在2005年的时候，一篇叫做《把表格从你的网页中扔出去》（找不到文章的链接了，但确实有这篇文章）的在线文章，似乎给了人们一个错觉，要符合标准，那么表格在网页中就完全不能使用了。必须用div来代替。也许div+css这个概念就是这样被想当然的创造出来的（源自表格布局）。但事实上，web标准并不是完全不允许使用表格。而是要求摒弃使用表格来布局的做法。同时，也不再使用布局这个概念。而是提倡结构与表现分离。这时，就有一些人会产生一个疑惑，如果说xhtml代表结构，css用来控制表现，那么，布局该如何解决？相信现在接触web标准的朋友不会再有这个疑惑了吧？结构和表现结合起来就形成了布局。既然不能用表格来做布局了，那么表格还有什么用呢？似乎很多人忘了表格在html中的原始定义——展现结构化数据表格。举个例子，某学校班级的期中考试成绩表，这种数据，就是一个非常明显的表格。web标准中绝对没有要求你用div来模拟表格，那是非常蠢的做法。这几天在经典论坛上还看到有人产生这样的疑惑，表格形式的格式化数据，用表格比用div要方便的多，他们搞不懂为什么一定要用div来表现表格，现在我告诉你答案了，该用表格展现数据的时候就要用表格。 Chapter 3 为什么要用web标准？怎么样才算是符合web标准？ 很多人会说例如兼容性好、代码易懂、代码量小、结构合理、甚至有人说使用标准可以实现比表格更丰富的样式等各种理由来支持web标准，而web标准也的确具有这些优点，然而，这些却并非web标准真正要做的。 并非把表格换成div就是符合web标准了。也并非使用xhtml和css就是符合web标准。甚至就算你的代码能够通过w3c的验证，也很难说它就完全符合web标准。事实上，web标准的最终目标不是为了让人容易看懂网页如果仅仅是为了让人容易看懂，那么表格布局已经足够了。它的最终目标是为了让计算机能够读懂网页。看下面几个例子： 表格布局的一段代码： <table width="50%"> web标准（XHTML/CSS）实现的一段代码： <h3><span>web</span>标准的概念</h3> web标准(XML)实现的另一段代码： <articles> 看过以上几段代码后，我们先来分析一下。第一段是表格布局的代码，它把整块分成了两行，第一行用了三列，第一列是空的用于缩进，后面两列分别放了两篇文章的标题。其中的英文文字采用了不同于中文的字号。第二篇文章的标题上还有一部分是加粗强调的。第二行则是一篇文章的标题占用了整行，并且以红色显示文章标题。在页面展现出来之后，我们能够明白下面的信息：第一篇文章是普通文章，第二篇文章中有一个概念是很重要的。而第三篇文章则非常重要。然而，在代码中我们却很难看出这一点。因为没有人说过加粗就一定是强调。也没有人告诉我们红色就一定表示重要（如果是在暗红色背景下，它甚至表示不重要，光看代码是不知道页面展现出来是什么样子的，是否重要自然无从判断），在这段代码中甚至没有告诉我们，这几段文字是文章标题。 第二段代码就要清楚的多了，首先，h3标签告诉我们，它是一个标题。span标签完全没有含义，会被分析器忽略掉。而em标签则表示强调。程序很容易明白它究竟是什么。最后一行指定的的类important则可以告诉分析器，这篇文章十分重要。 最后，我们再看第三段中的XML代码，首先，articletitle已经明明白白的告诉我们，它是文章标题，多余的信息没有了。事实上多数情况下是否强调一段文字中某一个部分对于分析器来说并不重要。因此，加粗强调被放到了属性里面。最后一条，level属性非常明白告诉分析器，这个属性定义的是文章的级别。而它的属性important则告诉分析器，它的级别是重要。将来采用这种结构，我们的网络将会更加智能，而搜索引擎的搜索结果也将会更加准确。当然，好处远远不只是这些。 直到现在为止，第三段代码要想真正完美实现并且兼容，仍然只能停留在我们的梦想里。 Chapter 4 web标准的局限 web标准并没有有些人说的那么天花乱坠无所不能。正如很多在学习web标准开发的朋友所体会到的那样，如果想要开发的产品完全符合web标准，它的局限性其实很大。举例来说，如果按照web标准的建议不使用空结构块(如空div)、不使用无意义块（如仅作为装饰边角的图片）、不做无意义的DOM结构嵌套，那么想实现一个可拉伸大小的园角块都是非常困难的。目前网上流行的几种做法都不符合这个要求。这就是为什么欧美的许多网站往往结构以方块为主并且非常干净简练，一个原因是他们习惯这样的风格，但更重要的原因是为了UI的可用性和符合标准而在牺牲了美观，因为网站的DOM结构越复杂，互动表现越复杂，触发BUG的可能性就越大，兼容性也越难调整，此外，这些效果往往还不能完善。有兴趣的朋友不妨仔细看看一直被设计人员称道的大多数韩国网站，这种类型的网站和欧美的主流风格正好完全相背，走了另一个极端，以界面华丽花哨著称，因此特别能获得美术出身的朋友的青睐，在使用过程中总会出现各种各样的小问题。在 FF下也没有几个可以完美表现的。此外，这类网站在中国也是行不通的。大家不妨想想，究竟有哪个模仿韩国的网站能够获得比较高的知名度的？原因嘛，第一是它们经常造成浏览器速度过慢，第二是在网络条件不好的情况下下载经常很慢，第三，对服务器的负载压力非常大，很容易提高服务器的投入成本，最后，带来高带宽成本。 Chapter 5 web标准的背后，企业该如何适应web标准？ web标准有诸多好处，也带来了美好的前景，应当普及和推广。然而，盲目地追随标准，却可能造成整个项目的失败。要知道，web标准并非孤立的产生，而是于整个软件工程和web项目管理的发展有关。下面，我们来看一下，在适应web标准的过程中，究竟有哪些问题会造成项目失败。 1. 对标准的理解错误 前面说了，国内其实大多数企业和开发人员并不了解web标准。甚至有很多连web标准这个概念都不知道。反而对div+css这个被人错误解释出来的怪胎耳熟能详。设计师在进行设计的时候，往往天马行空的去做设计，完全没有任何章法可言，同样的内容，甚至在首页是三个字的标题，到了二级栏目页就会变成五个字，从根本上破坏了结构的可重用性。而UI程序员（请原谅我使用这个词语，因为发展到现在的web标准网页开发已经不是美术出身的设计师能够完全掌握的了）为了适应设计师的设计，只好拼命叠加各种奇怪的DOM结构，结果使本来用十行html代码就能写出来的页面最后用了三十行甚至更多，结构也一片混乱。css就更不用说了，不仅乱，而且乱的毫无章法。这种开发的方式经常造成最后只要设计上修改一点，就要对代码作非常大的改动，甚至整个开发流程从头做一遍，根本没有做到web标准中宣传的改版成本小，正好相反，改版成本有时会被无限提高。而混乱的结构和样式也会引发浏览器更多的BUG，让UI程序员不得不花更多的精力去写hack。从而进一步提高开发成本。 2. 没有任何规划，上手就做 在早期，由于表格布局的完全可视化编辑，使网页开发是可以完全不需要规划，一边做一边修改的。而我们大多数企业目前的开发流程也是如此。往往网站开发接近完成，策划人员还没有完全确定网站要展示的内容和提供的功能。但欧美许多公司的做法却是先做一份十分完善的策划和需求描述，然后建立用例模型、分析网站需求、建立逻辑模型，规划UI模块、规划功能模块、定义UI和功能模块的接口（大多数情况下这个接口就是我们现在经常使用的各种模板标签，事实上在欧洲比较完善的团队，这些标签在开始设计前就已经规定好了）、定义 flash应用程序的数据接口（一般情况下是XML文档）、定义内容框架（以便设计师在设计网站时了解网站的每个页面上究竟应该放些什么），这一大堆的各种文档几乎可以让任何两个不同的团队做出功能一模一样的两个网站来，除了美术设计不同。我就见过一份不过二十多个模板的策划案，仅仅是涉及UI设计和开发的策划和分析文档打印出来有300多页，密密麻麻的几十万字！为什么要说中国和欧美企业的开发过程的不同呢？原因很简单。中国的流程随意性更大，而欧美的流程则更加系统。然而web标准在设计的时候却是以欧美的设计流程为主。这就是我上面说的，没有任何规划，上手就做经常会造成项目失败的原因。一个边策划边构建的开发流程，采用了一份为完善的系统工程要求订制的标准，不失败才是奇迹！ 3. 主导人员角色错误，外行管理内行 这几乎是中国百分之八十项目失败的主要原因！对比东西方的管理，会发现一个奇怪的现象，在西方一个项目是由专业的项目经理主导，而东方则是谁职位最高就由谁主导。总经理、部门行政经理甚至市场人员干预网站开发进程在中国屡见不鲜，甚至有向非web专业市场人员主导项目管理的倾向。在一个web开发团队中，有时起主导作用的项目经理或者策划人员并非专业的项目经理或者web策划人员，最夸张的，我目前在做的项目竟然是以设计师的设计稿为主导，设计成什么样子，就必须作成什么样子，并且整个网站的设计稿完全没有任何关于互动方面的说明（其实是绘图师，他们对web的结构和技术限制是完全懂的）。而我认识的很多朋友也都因为上级在开发进程中的胡乱干预（注意，是开发进程中，而不是策划过程）叫苦连天，甚至有时会造成整个项目必须彻底推翻重来的尴尬境地。不断延期或者推翻重来的项目开发过程，无限翻倍的项目成本，造成项目失败也就不怎么新鲜了。似乎这一点与web标准并没有关系，然而，在web标准化开发要求的团队和流程里，第一点要求就是项目经理和策划人员必须专业并且其技能范围符合项目规模！事实上这也是任何项目管理的必要条件。 那么，企业和开发人员究竟该如何适应web标准？以下几点注意事项仅供参考：
这篇文章到这里已经结束了，我不知道这篇文章究竟会不会让那些一意孤行的BOSS们看到，更不指望能给他们带来多少影响。如果哪个BOSS看到了，希望你考虑一下你的投资和钞票。我所说的这一切，不仅仅是为了减轻开发人员的负担，更是为了让开发人员能够实现一个赚钱的项目，从而在这个赚钱的项目中获得更多的金钱和良好的心情。而能够决定这一切的，并非开发和设计人员。 提高网站的信任度网站的信任度可以表述为：网站给访问者所带来的可信任程度。它是访问者访问网站时产生的一种心理效应，是人们根据网上冲浪经验和生活经验对网站的真实性，权威性等方面所产生的一种模糊评价。这种评价可以左右浏览者的浏览行为，对于任何一个网站特别是新闻网站，电子商务网站具有非常重大的意义。 虽然网站的信用度无法用具体的单位来衡量，可是它的的确确存在着等级差别。信用度高的网站能够赢的比较稳定的回访量和竞争优势。而缺乏信用度的网站很可能在非常短的时间倒闭。 那么怎样提高一个网站的信用度呢？下面我们从“网站设计”和“网络营销”两个方面进行归纳。 一、网站设计中提高信任度的技巧
二、网络营销方面提高信任度的技巧
提高网站信任度还有很多方式，如防止网站出错，减少负面新闻，负面留言，负面邮件等等，增加客户认可的评价等等，这是一项精细的工程，马虎不得…… |
|||||||||||||||||||||||
|
|
