Group items tagged

网络社会中的诸多建设者们，更需要为每个个体在互动中提炼并维系一个群体的信仰、价值和规范。这样，每个生活于其中的人，才会将自己的认知和行为扩展到更加广泛的网络社会标准和观念上。

第一步，由产品管理者总结产品应该传达给用户的”形象和气质”，作为关于文字工作的基本准则。（比如，Robin提出百度的产品气质是”简单，可依赖”）。“负责人”根据这个准则，再去翻翻书或者看一些关于界面文字表达基础原则的文章，总结出自己产品一些大原则的”行文风格”。（因为是’行文风格’，所以无需太具体，一般在WORD上不超过二页即可，尽量简洁以免耽误应用的效率和质量）比如：（以下是某项目中的部分段落摘抄，切勿照搬）“说明性和提示性的语言不得超过两行，不超过50字”“界面上不得体现大片的专业术语作为帮助信息”“保持文字的一致性，本产品界面中所有和ID相关的信息都叫’帐户’，..”；“使用通用语言，不搞一些特殊化的文字，让用户一眼就能看懂”“保持语言的简洁，既定事实不做重复。如，’你的好友列表中没有好友，请立即添加’改为’立即添加好友’，….”；“如果系统出错，则明白准确表述错误，同时以积极的语调给出建议。如，’抱歉xxx，您可以xx再试一下’，….”；……..

第四步，经过一段时间的”审核”和”规范总结”基本上产品的文字就可以有完善的统一指南了。一般情况下，不超过一个月一个创业产品的系统性的文字风格和规范就可以形成了。这之后”文字工作负责人”的工作除了简单过一眼要展示出去的界面，基本山已经不需要做什么类似工作了。这个时候，其实规范不规范已经不是最关键的了，可贵的是”所有在界面上写字的人都有了统一的行文风格和习惯”，我们的界面文字越来越专业友好。。

最后，按照我上面的方法算一下成本：（创业团队里面，很多事情都牵连在一起的，这里未算管理成本）一个文笔好的女孩”负责”：假设她的薪水是4000，这个工作需要占据他20%的工作时间，那么是800；会直接在界面上写字的假设有4个（20人产品团队）：假设他们的薪水是5000，这个工作平均需要占据他们5%的工作时间，那么总共是1000。一个月的总共成本：1800。 6、文字是产品情感传达的一个重要因素，特别是互联网产品，需要保证用户在不同情景中的角色感，需要迅速高效的转达准确信息。中文的世界上一些糟糕的文字表达屡见不鲜，啰啰嗦嗦的风格尤为突出。

3．帮助设施： 系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。

4．合理性： 屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。

5．美观与协调性： 界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。

6．菜单位置： 菜单是界面上最重要的元素，菜单位置按照按功能来组织。

7．独特性： 如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。

8．快捷方式的组合 在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些 在西文Windows及其应用软件中快捷键的使用大多是一致的。

9．安全性考虑： 在 界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。 如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有 存盘而全部丢失。

10．多窗口的应用与系统资源： 设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。

Openworkbench（http://www.openworkbench.org ）也是一个开源的项目管理软件，其功能跟Project 2003相似，是一个值得大家去使用的一个工具，但对于中国很多软件公司，都是使用特别版的Project 2003。假如你很尊重版权，又不想使用Project 2003，那Openworkbench是一个非常好的选择。

第二、需求分析工具     需求分析工具用得比较多可能就是Rational Rose、MicroSoft Visio或MindManager，一般我们使用Rational Rose来进行用例分析，画用例图，画状态图；使用MicroSoft Visio来画出应用系统的结构图、流程图等。当然，对于MicroSoft Visio能画出来的东西，其实Rose也一样可以实现，只是，大家都是这么干，我们也没有必要专门去做一些特例的东西，特别是对于一些比较特殊的公司及行业。

二、系统设计阶段： 第一、系统设计工具     主流的系统设计工具有大家非常熟悉的Rose2003，不过，现在已经不叫Rose了，现在IBM最新的设计工具是RSA（Ration Software Architect），Borland Together，SyBase PowerDesinger，MicroSoft Visio，对于开源的系统设计工具也有很多，比如ArgoUML、DBDesigner等等。

第二、开发的技术框架     技术框架的选择是非常关键，一个好的技术框架，可以让我们的开发更加快速、团队的分工更加合理、系统能够支持多种数据库平台、我们的维护更加方便。     Web前端MVC框架是Struts 2。Struts 2可以说是Struts穿上了WebWork的外衣，其内核大部分都是采用了WebWork的技术，并且基于AOP的设计思想，让我们在软件设计上的能够更加多地体现“高内聚，低耦合”的设计思想。

第三、开发规范的定制     文件命名规范、数据库设计规范、编码规范、团队协作规定等等一些规范性的东西，需要在系统开发前就规定好，并且做相应的培训。QA也要做好监督的作用，定期做评审工作，对已发生的问题及可能出现的问题，及早发现，及早处理。

第四、开发工具的选择     团队一定要选择同样的开发工具，开发工具相同，软件版本相同。为什么要这样子做，其实假如你作为一个Team Leader，你会在管理你的团队的时候发现很多问题，而解决这个问题，那在项目编码前，就把什么东西都规定好，以免其中发生问题，影响整个团队的开发速 度。开发工具的选择也是非常重要的，目前企业用得比较多的开发工具有：Eclipse、Jbuilder、NetBeans、IDEA。

三、开发阶段 第一、配置管理工具 代码管理工具有很多，现在公司用得比较多的代码管理工具有CVS、VSS、SVN。 对于一个开发团队只有2-5个人，并且这两三个人是同一间办公室里，那使用VSS是一个非常不错的选择，个人觉得他小团队的管理方面非常好用。个人觉得 VSS唯一的缺点就是一个文件当被一个人锁定，那其他人就没有办法进行修改了，当一个文件为多个人所共用且开发团队人数较多时，这种问题将会显示非常严 重。VSS客户端跟服务器你都可以从Visio Studio里面找到。

对于一个开发团队有超过5个人，那此如选择CVS或SVN将是一个更好的选择，并且，假如你的团队是分散的，可能不在一间办公室或者根本不在同一个城市，那使用CVS或SVN是一个非常更想的选择。CVS的服务器一般是使用CVSNT或CVSServer。

四、软件测试阶段  第一、缺陷管理工具     软件你不能保证它永远不会错，只是，有些错误你暂时还没有发现而已；有些错误需要在某些特定的环境下它才会发生。就像Windows，时不时会有一些系统 更新文件要求更新。可能这些更新不是错误，只是一些系统安全方面的隐患。这些都可以算是软件系统的缺陷。那这些缺陷我们应该怎么进行管理？怎么进行跟踪 呢？现在缺陷管理用得比较多的有两个：第一个是开源的bugzilla，另一个是商业的JIRA。

六、软件维护阶段 第一、客户CASE跟踪管理工具     客户CASE跟踪系统相信很多做CISCO公司金牌代理的人都会用过。我们必须在公司内部建立相应的CASE跟踪制度。当用户使用系统的时候，发现一些问 题，那我们需要对这些问题进行录入并进行跟踪。像客户呼叫服务系统等等一些商业化的软件外面还是很多的，这些系统其实公司自己开发一个也是很快的。但必须 要有。这个也是提高整个公司整体服务形象的一种态度。

30个最顶尖的基于栅格系统的博客网站设计。

网页栅格系统的原理与应用：

我们把宽度为“W”的页面分割成n个网格单元“a”，每个单元与单元之间的间隙设为“i”,此时我们把“a+i”定义“A”。他们之间的关系如下： W =（a×n）+（n-1）i 由于a+i=A， 可得：(A×n) - i = W 这个公式表述了网页的布局与网页“背后”的栅格系统之间的某种关系

对于内容信息不确定导致高度不确定的页面，在高度层面上就无法做到栅格了。

下面我们列出当n等于不同数值时W变化的数值表格

yahoo首页的布局完全是按照栅格系统进行设计的，每个区块的宽度对应的n值分别为：4，11，9。在这里我们看到一个很有意思 的事情：只要保证一个横向维度的各个区块的n值相加等于24，则即可保证页面的宽度一定是950px。然而，950px的宽度也恰好就是当n=24的时 候，W的宽度值。由此我们得出以下的应用模式：

在栅格系统中，设计师根据需要制定不同的版式或者划分区块，他们的依据将是上面的那张对应表进行设计。这样，一个栅格系统的应用就从此开始了。

它给整个网站的页面结构定义了一个标准。对于视觉设计师来说，他们不用再为 设计一个网站每个页面都要想一个宽度或高度而烦恼了。对于前端开发工程师来说，页面的布局设计将完全是规范的和可重用的，这将大大节约了开发成本。对于内 容编辑或广告销售来说，所有的广告都是规则的，通用的，他们再也不用做出一套N张不同尺寸的广告图了……

yahoo的网站页面宽度为W=950px，每个区块与区块的间隔为i=10px；如果应用上面的公式，可以推出A=40px，既yahoo首页横向版式设计采用的栅格系统为： （40×n）- 10 = W

我们可以衍生出任何一种栅格系统，只要改变A和i的值，这个根据网站的实际情况来制定。那么如何选择合适栅格系统，主要通过“构成 要素与程序、限制与选择、构成要素的比例、组合、虚空间与组合、四边联系与轴的联系、三的法则、圆与构成、水平构成这些设计元素规划，来实现比例和谐的平 面设计”。

整个过程，信息流动并未因这些举措和功能的推出而阻断，反而很成功地和用户互动起来。豆瓣完成了从工具到社区的转化，同时能够保证其平滑程度，和人与信息之间的协调性，这才是其最出色的地方。 

再后来，豆瓣终于迈出了很关键的一步：人本的偏移。两个人间有哪些共同爱好，这个很小的应用似乎和以上的应用没有太大差别。真的这样么？如果真是这样，为什么这一个功能会放在我浏览他人profile时的最顶端？答案只有一个：豆瓣终于从信息中心转移到了人本中心。

豆瓣的群组上线，意味着社群化的正式展开。当然，群组的存在也并非由于其具有足够的人际liability，群组的基础也无非是一个组名。群组只是一个在item间信息整合的方式，我们可以随便从一个小组收藏的item中看到这个方式的效果。

观察豆瓣的举措。豆瓣的架构是一个矩阵。他们将高度结构化的items——书目、电影、音乐专辑等等——作为一个坐标，同时将完全去结构化的用户作为另一个坐标。我们可以看到这是两种规范方式，一种是信息至上主义，一种是人本主义。信息的管理需要高度的标准规范，而对用户的管理却必须更加敏捷。豆瓣在这一问题上处理得相当得当。

很严格的规范来完成，少任何一个element都无法建立起item的profile。同时为了提高其信息的liability，豆瓣也引进了wiki的思想：通过对item的信息投票来规约信息的准确性。又一个UGC的应用。我们需要注意到，这个投票和更改的过程本身就已经是信息在人们间流动的开始了。

社区的存在前提是信息的有效性和内涵价值，即一种综合意义上的liability。如果平台能够提供有价值的信息，或者平台能够激励其使用者提供有价值的信息，liability才会产生。社区的建立很大程度上取决于信息的liability。我们能够将社区的交际进行下去，是因为我们将信息的liability置换为其提供者的liability。只有这样，社区的诚信机制才有可能建立起来，人们间的关系才不会仍然松散。信息的价值成为社群性的粘合剂。

流动并未因这些举措和功能的推出而阻断，反而很成功地和用户互动起来。豆瓣完成了从工具到社区的转化，同时能够保证其平滑程度，和人与信息之间的协调性，这才是其最出色的地方。

：人本的偏移。两个人间有哪些共同爱好，这个很小的应用似乎和以上的应用没有太大差别。真的这样么？如果真是这样，为什么这一个功能会放在我浏览他人profile时的最顶端？答案只有一个：豆瓣终于从信息中心转移到了人本中心。为什么这么说？在这个应用中，item终于成为了彻头彻尾的工具，并且这个应用产生了一种精确的人际关系的定义。群组的确如此，但是我是否会和群组中的人们有相似的爱好，或者有相似的认知程度，这个无从判断。而共同爱好这一功能可以将这一问题完全解决。这是社群的基础，即信息的liability彻底转化为人际的liability的实际应用。从这一步开始，豆瓣正式从社区化工具转向了工具化社区。之后，广播的引入再次证实了社区化的判断。虽然广播仍然整合了用户与item之间的信息，比如“蟾宫读过《昌耀诗集》”等等；但是这一应用的产生的确促使社群化的瞬间加剧，同时也保证了item并不会被边缘化。相反，item的存在反而成为了人际间的加固栓，利用item定义的相似identity，将本应很松散的人群集合成为黏性极高的社群，并且长期相互加强。 

豆瓣的群组上线，意味着社群化的正式展开。当然，群组的存在也并非由于其具有足够的人际liability，群组的基础也无非是一个组名。群组只是一个在item间信息整合的方式，我们可以随便从一个小组收藏的item中看到这个方式的效果。比如拉康的小组中有很多拉康和关于拉康的著作，这首先是一个信息的重构过程。但是很快，重构的不只是信息，“人”这一坐标也由此产生集聚效应。这个效应的产生是由于人们在某一方面的属性类似甚至相同。豆瓣成功地利用其独特的个性和定位激励用户产生小组并为其添加内容增加收藏。一个社区化的良性循化就这样构成了。个人的社群性和信息的重构在这个循环中彼此加强。此后，九点、“去过哪”这些产品都是作为个人社群化和信息重构的标志。此时的豆瓣处于信息和人两种因素的中间地带。

PM是什么? 传统意义上PM就是一个产品的主管，为了方便讨论，我们这里将产品定义为软件、网站、网络应用、局域网或技术产品。 作为一名领导者，PM将对整个产品的成功负责，这其中包括用户体验。对技术产品而言，用户体验是产品成功中非常重要的部分，当然还包括其他方面，像产品的销售、技术、法律、商业模式、定位、品牌和营销等。 PM应该扮演一个领导者而非独裁者的形象，才能保证产品的成功，并得到各方的支持。像总统会与负责防务、交通、农业等的官员共事一样，PM团队也包括营销、技术、财务和其他领域的人。与票选民主不同，PM对用户和客户负责，通过收入、利润、用途和其他市场驱动因素来实行决定民主。 产品管理中涉及的各项任务和领域使得PM必须精通业务的方方面面。

产品管理与用户体验的冲突 最常见的UE与PM间的冲突就发生在该产品应该做什么与产品该怎么做的讨论上，双方经常辩论谁应该负责定义产品特性与需求。PM感觉应该由他们负责，因为他们管理产品，但是UE人员感觉应该由他们负责，因为他们花了时间来研究用户需求并直接与客户和用户互动。 最终由于PM对整个产品的成功负责，他们也就成了决定产品做什么的最后仲裁者。好的以市场为重点的PM应能理解市场背景和客户需求，并在第一手经验和已有研究的基础上决定合适的产品特性与功能。 然而UE人员常常对此非常光火，因为他们认为自己更贴近客户和用户，理应负责产品的需求收集和定义。好的PM应该象UE人员那样贴近自己的用户，否则就会脱离用户，只知道坐在办公室里开大会，让UE人员来做此类研究。 好的PM能深知用户体验这个角色并理解其重要性，重视他们的投入并利用他们的研究和建议来创造优秀的产品。正如总统需要从自己的内阁成员那里获得建议一样，PM也应该利用自己的"内阁成员" — 用户体验、市场营销、技术等 — 去做出决策。 从UE人员向PM角色的转换远不止去操作所有的界面设计， PM一项很重要也很有挑战的任务是负责确定产品的目标与策略，树立内在和外在的产品领导能力，创造商业模式及获得资本，从小事出发又能着眼大局，并协调市场、工程技术、财务、销售当然还有UE一起向成功迈进。 在第二章，我们将向你介绍迈向产品管理的方方面面，包括你在UE岗位上不可以做而在PM角色上需要做的事情、成为PM你必须做哪些准备、UE背景的人成为PM后常有的缺陷等，来帮助你作出这中转变。

在前一章中，我们勾勒了PM的职责、PM与UE人员的差异以及为什么两种角色之间会产生冲突等。 现在我们来介绍当UE人员成为PM后其思考重点、职责与挑战将会发生哪些改变，离开UE工作岗位后你将有哪些收获与损失以及如何为这种转变做准备等。 在你向PM的角色纵身一跃之时，最好清楚这次跳跃对自身的影响。 作为UE人员不可以做而作为PM必须做的事情 成为PM后，你每天的工作将会发生巨大的变化! 你必须运用你的全部知识投入到整个产品中。作为UE人员你也许能同样做到这一点，但是限于行政授权你未必需要和公司内的全部决策部门打交道，以下就是你的一些"新职责": 关注产品策略以及客户和终端用户的需求(这也是你做出转换决定的原因) 你必须长期地研究客户和用户，找出用户需求与商业目标的切合点。相应地了解这方面的知识并有意识地利用它。 从产品的整体性上协助确定用户的焦点，不只是设计 沟通、政策以及定价都必须整合成为"客户体验"的整体，过去我们常常对这些方面的重要性认识不够，成为PM后你就必须对关乎产品体验的方方面面负责了。

推广产品 你必须同时在内部(包括销售、市场、管理层、开发者等)和外部(包括客户、用户、业界分析员和媒体)取得支持。仅仅只是开发出一款好的产品还不够，你还必须让人们知道它，推广它的好处。 向组织中的其他产品提供策略投入 如果你是一间中型或大型公司的PM，你在这个位置上同样需要影响其他产品。你也会同其他公司内的其他PM交流，你需要考虑公司的全部产品线，并将你的产品融合其中。 你面临的挑战与压力 PM这个新角色会让你很有荣誉感和责权感，而且新头衔带给你的影响力可能会胜过其他，但它也是”带刺的玫瑰” — 你同样必须应付挑战和压力。

平衡各方力量 确保你的产品重点是客户和用户需求非常重要，但是其他方面同样值得关注，包括但不限于: • 销售目标 • 市场/品牌目标 • 技术趋势 • 文档管理 • 预算管理 • 市场趋势 • 竞争力 • 商业模式与回报 (可能的人员浮动、变局影响、价格杠杆等) 做好一款产品需要在商业目标、用户需求和市场效应之间进行一系列权衡，作为PM，你就必须在各方之间努力做好平衡。

学习并准备成为PM 因此，你想成为PM? 不知道从何做起? 除了上面提到的以外, 你还应该增加你在产品管理方面的知识，从中找到你为这一角色转变所需要的东西。 想想你迈向UE之路时候所做的事吧: 书、博客、会议、小组讨论、各种组织以及导师等，它们都发挥了很大的作用。如果你想成为PM，这些方式依然有效。 成为PM最好的条件是通过培训和会议。差点忘记提了，我们在IA 2007峰会: 你想成为产品经理 上有一个预备会议，这个半天的训练营上将会集中讨论如何从UE向PM的角色转变，包括如何更好地平衡你现有的技能以及怎样避免潜在的不足等。 还有其他组织提供类似的训练营活动，包括: • 实务营销 • 280小组 • Blackbot • ZigZag营销 • 硅谷产品小组 有大量非常好的Blog在讨论产品管理，你也可以从中选择: • Roger Cauvin的博客 • 实务营销的博客 • SVPG博客 • 产品管理观察 • Tyner Blain • Michael的产品管理与营销 • 如何成为优秀的PM (它的联合作者之一便是 Jeff Lash) 还有很多从UE角度来谈产品管理的书籍，这些都应该作为PM的珍藏: • 赢在新产品: 产品从创意到启动的加速实现, 作者Robert Cooper • 软件产品管理精华, 作者Alissa Dver • 产品经理手册, 作者Linda Gorchels 此外，有志成为PM的人还应该阅读一些综合的管理类图书，包括领导力、管理、市场营销、财务、技术、策略学等。 产品管理有两个主流的社团组织: PDMA (产品发展与管理协会)和AIPMM (国际产品营销与产品管理协会)。两者都提供培训、会议、本地讨论小组及其他产品管理资源。 同时，你还可以利用你的一些职业网络，也许能从类似LinkedIn — 帮你寻找能建立联系并回答有关产品管理问题 — 这样的服务中获得帮助。在你的公司里项目管理也能指导你，况且来自其他组织的产品经理也能给予你不同的或许更真诚的帮助。 正因为你学习产品管理并思考如何迈向这一步，可以找你的经理谈谈。优秀的经理会帮助你的职业化成长，即使这也许意味着你将进入公司的其他岗位。

作为PM，你的权力很有限 Guy Kawasaki形容PM是"一个背负全部职责却没有任何权力的人"。大部分为你的产品工作的人会向不同的管理层汇报，很少甚至没有人会直接向你汇报。你必须梳理这些分散的资源，指导他们的工作 — 尽管他们从各自的经理那里获得了不同的工作方向。 你必须做出决定并对此负责，而不仅仅是建议 事实上你必须做出很多的决定并为此负责，不是所有人都会认同(你的这些决定)。当然如果你的工作干的好，你可以向他们证明你的决定是正确的，明确解释你的原则，其他人也就不会显得焦急或轻视 — 但这并不容易! UE出身的PM会发现所创建的体验也许不是对用户"最好"的体验， 因为还需要考虑其他重要的因素(比如管理层的需求、商业策略、商业模式等)，让这些人理解做出这样的决定或许有损用户，但最终有益于产品往往需要时间。 你将经常处在利害分歧的中心 销售人员希望有不同的功能、开发人员将你制定的时间表往回推、财务人员需要新的后端功能、商业开发人员希望能为合作伙伴做一些产品调整、设计师希望更改一些功能的实现、用户希望增加一项你的竞争对手推出的新功能、管理层希望你的产品能与公司新产品进行整合… … PM就处在这样不同的竞争中心，在一些公司中这样的处境是很不妙的。你必须调节好这些冲突的想法，制定相互之间的优先级以推动产品策略并保证皆大欢喜(至少不能让某个人动怒)。 成功的PM总是围绕着整体的目标和策略来平衡各方的要求，决定做哪些可以最大限度地支持这些目标。PM对目标与策略的理解越深，就越能做出权衡考量。有时候一点小的让步能够得到更多的收益，有时候则需要更好地梳理目标。 管理层需要从你这里得到关于产品的信息 PM不只是产品开发团队的一员，你是整个产品的象征。无论你把事情做好了或搞砸了，也无论你是否真的能驾御局面，你都必须为此负责。 作为UE人员可以做而作为PM不可以做的事情 从UE岗位转换到PM岗位的人会对新职责感到兴奋和有挑战性，与此同时，他们也会失去一些UE工作的一些方面: PM不必插手过多细节 这是很多之前习惯过问小事的人面临的最艰难的挑战。作为PM很多具体的工作都应该是委派给其他人(来做)，一个花费太多时间去处理细节问题的PM注定没有做好他们的本职工作 — PM需要关注的是战略层而不是战术层。 PM并不追求尽善尽美和理论上的完美 有一个针对UE的笑话是UE人员经常回答问题的时候说"这个取决于…"。对PM来说，也许它确实取决于某件事情，但这不是紧要的。这并不是什么理论上应该发生的问题，而是在此情况下我们马上要做什么以及为什么做的问题。 你必须习惯够用即可的观念，做出在用户看来未必完美但在有限的资源下很受用的决定即可。 PM对产品的核心问题不只是建议 这一点和上面的有点背道而驰，UE实践者们提出建议，而PM需要决定策略、较高层面的用户体验、功能设置、市场规划、定价及其他方面。之所以又提到这一点，是希望促成你进行反省。如果你只是习惯建议或很难做决策，你也许不适合成为PM。 PM不是艺术家或专家型实践者 PM并不专注与产品的某个部分，而是知晓全局。他们有点类似船长或教练去驾御局面。在这个层面上，PM需要保障一起共事的人能将产品目标反映到方方面面，例如营销策略、界面设计、版权书写等。 由于不是专家，在各个方面进行调节是比较困难的，PM就必须在后面的工作中不断学习如何领导其他专家向一个共同的目标努力。 从现在起更好地配合你的PM 如果知道"幕后"产品管理，你可能已经动心了。有一条捷径能帮助你开始: 从现在开始更紧密和有效地配合你的PM! 这个办法即使对那些并没有这方面特质、技能或只是想成为PM的人来说都是值得一试的。作为一名UE实践者，更好地理解其他角色的同事所面临的责任与挑战可以帮助你调整与他人共事的方式，并且最终使你变得更有价值、更受尊敬、更有影响力。 有UE背景的人在某些领域是能够很好地与PM相处的，有些办法能很好地帮助你探路，而无论你是否迈出了这一步。 领导力 不要只知向PM或其他同事索要具体的研究和设计成果，在很多情况下，其他同事很欢迎你能有主动性和创意，不过同时他们也保留不同的观念，只要把事做起来就能迅速公开和集中地进行具体地讨论，总好过停留在理论和臆测层面。 向PM问清楚他们的产品目标是什么 问清目标非常重要，体现在两个方面：第一，PM自己有可能之前没有仔细想过产品目标，你这一问后，有可能让你成为最受信赖的顾问之一并帮助他们建立目标。 第二，如果PM已经有了目标，那么你也就能清晰地建立一系列的目标和预期。如果他们的目标存在问题，你还可进行澄清和确认，并决定怎样让它回到正确的道路上。 帮助PM评估设计的各方面因素 不要只是提出设计方案然后让PM做决定，要让自己准备好参与讨论特定设计选择的影响，向他人展现你的设计背后的原因已经他们在更广范围内与产品远景和目标的联系，聆听PM怎么说并搞清楚他们拒绝或认可的理由。 提出带有远期规划的强烈建议 你所能提供一些证据和经验将支持着你更紧密地成为产品的一份子，而不只是一个辅助的参考者。你也能从纷繁复杂的因素中做出决定的过程中得到锻炼，如果你立志想做PM的话这些很有帮助。 展现你对工作的远期规划将使你能成为团队中最重要的成员之一，并且能展现你有担负更多职责的潜力 — 不管你现在的角色是什么。 帮助PM走出办公室 PM不应该对客户和用户视而不见，尽管有人是这么干的。你应该通过询问他们最后一次见用户是什么时候来帮助他们，把他们带入到正式或非正式的用户研究中，或者给他们讲在用户访谈中的一些有意义的故事，邀请他们下次同去。如果被拒绝了，下次继续邀请。 如果PM能自愿去拜访用户，让他们带上你。除了了解用户需求之外，这也是一个你有时间向PM求教他们的观点、兴趣与目标的好机会。 如果你真的无法把PM带出办公室，那就把用户们带进来吧。在这种情况下，应该没有哪个PM(包括其他开发成员)能找借口拒绝和用户沟通。

这种方法不错,但也带来新的问题：增加了每一个页面的http链接数。对于大流量和中等流量的网站，每个页面增加5个以上HTTP连接数，系统管理员可能就麻烦大了。两个可能解决办法： 把所有样式都放到一个文件里，而不是分成多个模块。这里的问题是，失去了框架只包含特定文件的灵活性，而且维护也变得麻烦。 有一个服务器端程序,动态把多个单个文件处理成一个响应。我还没看到这种做法，但如果做好了应该是很有效率的。以我上面框架为例，当请求（Request）base.css时候，而不是请求（Request）type.css , grids.css 等的时候，这一动态处理过程触发。这样一来,单个文件仍然可用，而在平台版本上整个框架也有效的。 总之，我们目标不是尽可能的抽象，这点非常重要。相反,其目标是提供了一个快速启动和更有效率的设计过程，这是绝对有可能去做过的。如果你过于的抽象，事情会变得混乱，太多的HTTP链接数会影响你网站的性能。记住：一个好的框架不是把事情搞更难更复杂，而是一个简单的从零的开始。