1. 过去我也曾经跟着大家一起说，因为确实，腾讯没有创新，跟百度，google比起来，确实不行~
2. 上面的现象（跟着大家一起），余世维称之为“群体偏移”：人聚在一起容易发生群体智商低下及方向偏移的现象
3. 最近在读关于博弈论的书《策略思维》，里面描述了很多方法和问题
4. 有一种现象叫做跟随策略：假设两个帆船在比赛，第一名领先第二名20米，因为是帆船，所以决定船速的因素只有“风”。第一如何能够保证自己赢过第二？跟随第二的策略，那么他永远不可能输，记住是永远（刨除任何抬杠的因素）
5. 这种跟随策略能够确保第一名的领先优势及最终的地位，所以对于第一来说，这种策略是最正确的
6. 对于第二，唯一也是最应该能做的就是：创新，创出会有效果，会有作用的新，同时也是第一不能全力跟随，甚至不敢跟随的新~ 看看IBM和DELL？ 大部分书都说DELL挖掘了需求，但是从博弈论的角度讲，如果IBM全力跟随DELL（虽然有品牌啊，定位啊等周边因素的影响），格局则不见得是这样~
7. leopoard 里面太多的东西是vista跟随不了的~
8. 我的视觉设计，页面结构设计能力太差，自己来考虑如何帮助自己成长，试试吧~
需求应包括对象和动作以及上下文。
————出自《about face2.0》
一个从脚本提纲及用户角色中提炼出来的需求（针对系统）应该包括哪些内容？
1. 首先，需求不等于任务：任务必须是通过用户手工完成，而需求则只是暗示特定对象需要存在，及特定的动作及特定的场景。
2. 数据需要： 任务角色的数据需要是必须在系统里被描绘的对象和信息，如文档类型，状态标记等。
3. 功能需要：功能需求是针对系统对象必须进行的操作，最终会转换为界面控件
4. 上下文需要和要求： 即场景需求，需要描述对象集合内对象之间的关系，以及对象和控件之间的可能的关系（应该也是其他需求文档规范中提到的：系统反馈/运行结果）
5. 其他需求：商业需求/技术需求/顾客和伙伴要求
跟传统的需求文档相比，这里主要强调的是上下文，即功能的环境（上文）及系统的反馈（下文）
有人需要一起网或者百度HI的邀请可以留言，留下邮箱
一起网：谢文的理论实践性产品
百度HI：百度的IM软件…
用例是什么？不了解的看这个：了解用例-编写有效用例
用例的作用？
不同的环节，用例起到不同的作用。其实外国人很会挖掘及利用工具，这点比国内的人专业好多。好像千鸟说的日本人的excel都用到很深入，同样，国外对用例的使用方法也是很多样化的。这可能也跟中国的互联网环境有关：一切都是免费的，我不用太珍惜及挖掘。
从工作的经验来看，在现在的流程中，用例主要可以用来描写业务流程，让技术及设计人员对产品的业务流程达成共识，从而认识到产品应该如何与这些业务流程更好的结合，并通过用例的讨论来挖掘需求。同时使用范围来确定产品应包含的功能，来保证开发工作的高效，没有多余的工作。确立范围的方法可以看这个：通过用例确定系统的功能范围
而用例的格式又可以保证在具体功能需求中进行功能，逻辑，现象的穷举，以保证需求的完整性及可实现化。
而产品设计中也有同样的工具：脚本提纲。虽然在国外用例也可以用来描述相似的内容，但主要都是在业务描述及功能描述上。而脚本提纲主要描述的内容是从具体用户的角度定义产品的行为，不仅包括功能（概述），也包括功能的优先级，以及用户看到的，与系统交互的方式等内容。同样也可以迭代：从最初的目标描述，到任务分解后的任务描述，同时包含进去具体使用产品的场景描述，心态描述，用户行为描述，从而用来进行设计及检验产品的功能结构，具体功能交互，用户使用方式等。
这个工具过去没有了解过，感觉确实是一个必要的环节，应该加以重视和实践。
最近有空常翻翻这本书，中文名叫软件观念革命，确实是一本很实用很精彩的书，里面同时提到了很多过去没有想过的方向和观点。
1. 软件的设计与开发是完全两个独立的过程，同时分离这两个部分的工作会提高软件的质量
2. 决定一个软件的成功与否不是一个软件有多少功能，而是功能是否有用及好用（注：有用排在前面）
3. 设计软件，重要的是设计用户的行为：界面不是静止的，是活得行为。即用户如何使用软件是完全依照你的设计来决定的。
4. 交互设计的定义： 交互设计是对人工制品，环境和系统的行为以及传达这些行为的外形元素的设计与定义。
5. 设计具有三个维度： 形式，内涵，行为，分别突出表现在不同的行业。
6. 交互设计师首先要做的，是理解使用他们设计的人们的目标，动机和期望。
7. 什么是产品设计？ 理解用户的期望，需要，动机和上下文（情景）；理解业务，技术和行业的需求及限制；将这些所知道的东西转化为对产品的规划，使得产品的形式，内容和行为变得有用，能用，令人向往。
其中最让我惊异和佩服的理论是： 一个成功的产品诞生于业务领域，技术领域及设计领域三个领域的交集。业务保证生存，技术保证实现，设计保证能用，可用。
在业界的例子是： Novell，专注于技术；微软，更擅长业务；苹果，出众于设计；
先来看几个情景：
1. 上网，登陆邮箱，撰写邮件内容，发送邮件，发现网络故障（用户机器/网络服务器等因素）
2. 上google，输入关键词，获得搜索结果，对结果不满意，调整关键词，重新获得搜索结果
3. 上豆瓣，查找书，看看书评，确认要买，右侧有各个网络书店的购买链接，点进去购买，看见此书是缺货
4. 上迅雷，找电影，下载，等了两个小时，发现是枪版，迅雷标题是DVD高清版
……….
从上面的例子你能看出来什么？
目标和任务是区分的，而真正影响最终目标及体验，无论是商业或是用户的，都是目标大于任务。 而关于这方面的文章也有很多，比如白鸦的保证整体体验,千鸟读书后与angela的讨论，最终的结论都是：保证用户目标的完成才是产品（商业）体验所追求的最终效果。
而在用例分层撰写及产品设计中也有相关的理论指导。这方面的内容国外要比国内的丰富许多。所以时刻铭记用户的最终目标，在保证各个“任务”环节的体验友好型、流畅性的同时，确保最终产品的设计宗旨与用户目标的最大化重合，才能真正做到产品的有效性及可用性。
所以即使任务分解了，辅助用户完成任务了，别忘了最终的目标。
原创： 猪猪经验分享
首发： 猪窝
PHP学习已经有半个月的时间了，总得来说掌握的知识还只是小基础。如果看成是学英语的话那现在就是26个字母基本掌握，掌握了几种简单的语法，同时记住了一些单词。同时我不是一个真正的产品设计，所以大部分工作及精力是放在需求，业务方面，而学了技术，至少是学到现在（可能我学的还不够深入）对我的帮助远远大于对我的限制，确实没有像其他人说的，技术限制了思路。
工作中能体验到的好处：
需求文档中，逻辑的问题少了：不会把多个数据盲目整合，看着整体结构简单了，实际上功能的使用繁琐了，逻辑复杂了，同时有可能会出现矛盾。
对进度的安排及功能的分配心里有些框架了：知道了大概哪些是大工作量，哪些是比较容易实现的，同时平衡业务用户的需求侧重点，从而更合理的安排项目的工期及功能的分配，同时最大化的满足双方的需要。
问题考虑更全面了：一个简单表格，一般我们需要提出的需求需要包括的点有“字段数量，字段定义，字段顺序，表默认显示数据，数据行的排序依据，是否翻页，翻页条件，是否允许查询，查询条件与逻辑”等等类似的功能说明。
歧义句少了： 明白了参数，属性，字段的含义，不会再乱用会误导技术理解的词汇。
文档力求统一，需求分层： 文档同样是一个“产品”，他的面向用户群就是开发人员或设计人员，所以同样需要有概念统一，词汇统一，功能统一的要求，包括各种细节，尽量不要在功能需求中体现表现层的东西，同理在设计建议文档中也少提到逻辑概念。
类似的好处还有不少，总之感觉到是质的变化，再有体会继续整理。
台式机成功安装leopard，速度还可以，效果也都很好，现在系统是xp，leopard双系统
刚装上，但是很多东西还都有问题，驱动，使用，配置都不是很熟悉，明天需要仔细研究一下。开心ing！！
弄完会上经验！
产品经理的一个主要职责及工作内容：沟通，翻译。
跨部门的沟通协调要求一个合格的产品经理可以充当技术，销售，市场，客户等不同群体的“翻译”，所以有必要了解各方面的知识及术语，今天分享一部分数据库的术语，可以跟技术更好的沟通或者听懂技术之间的讨论，不会被当作“棒槌”，囧….
内容参考自PHP & MySQL Web数据库应用开发指南
数据库（database）：存储数据的仓库，就是常说的数据库。
表（table）：数据库的一部分，仅存储与单一目标，事物，行为相关的数据。
字段（field）：也称为属性，表里的纵向数据域。每一条数据记录都有相同的字段。
记录（record）：也称为“行”，表里的数据实体。每个记录均包含对应于每个字段的值。
关系模型（relational model）：使用数据库，表，字段存储数据及管理表之间关系的模型
（关系型）数据库管理系统（DBMS）：管理数据库的应用软件，即我们平时说的mysql，sqlserver等类似的
SQL：用以和数据库服务器交互的标准查询语言
约束（constraint）：对表和字段的限制。比如用户名要求唯一，没有客户不会有订单数据，邮箱必填等等。
主键（primary key）：用于唯一标识各条记录的一个或多个字段。
索引（index）：是种快速访问表中记录的数据结构。
实体-关系模型（ER模型） ： 利用实体，字段，关系表描述真实数据的技术。
规范化的数据库（normalized database）：根据ER模型设计的数据库。
原创： 猪猪经验分享
首发： 猪窝
转载请注明链接
