产品设计团队协作 - UCD大社区

设计沟通的七条经验

CDCer — 2013-03-20 11:04:12

经常有新入职的同学，搞不清设计师和别的职位如产品经理，在工作内容上有什么区别。回答了几次之后，我总结出两方面的差别，简单概括为：技能和定位。

“技能”指的是设计师掌握了项目中其他角色都不具备的能力——画图。这么概括有点简单粗暴了，事实上设计师的专业能力远比画图两字涵盖的内容要广。但“画图”确实是更容易被所有人理解的说法（向家里长辈解释我干什么的时候，他们如果不理解我就会说是画图的，他们就会貌似恍然大悟地哦一声，终于听到一个他们想要的能听懂的答案了）。伴随着人机界面从命令行到图形可视化，再进化到哪儿哪儿都可以摸的触屏时代，用户对于“美”和“交互”的要求越来越高，设计师的能力和价值也愈发受到重视。

设计师的“定位”，是随着用户体验受重视而发展起来的。互联网产品有一个很重要的特点是免费。聊天是免费的，搜索是免费的，游戏是免费的，杀毒也是免费的。免费对用户来说当然是好事，但免费也意味着用户迁移的成本很低，特别是当产品同质化严重时。一款免费游戏，如果突然宣布收费，市场上又有同类游戏，结果很有可能是大规模的用户流失。和传统行业不同，在免费的商业模式之下，用户黏性、忠诚度对产品来说至关重要；而用户体验就是构成黏性的一个重要因素。于是伴随着互联网行业的蓬勃发展，用户体验设计师，以用户体验卫道者的姿态站了出来。

这么说不代表别的角色不用对用户体验负责。在一个优秀的团队中，从项目经理到开发测试，每个成员都会对最终的体验努力并负责。但设计师之外的其他角色会面临屁股决定脑袋的困境。比如产品经理除了用户体验之外，还要兼顾商业价值和老板需求；开发要考虑实现成本和技术限制；运营要负责营收和转化率等。而设计师的定位更纯粹，自身立场不存在矛盾和冲突：站在用户立场，坚持用户体验的价值，时刻提醒团队用户想要什么；同时负责设计细节的执行。

这样就引出正题了，一个项目团队中设计师和其他角色的矛盾冲突，本质上就是这层定位差异带来的。（开发：这里明明功能都实现好了，设计师你还老是要改来改去的，到底想搞哪样！）基于这种定位冲突，设计师不能简单地把自己定位在执行层面上，还要通过积极主动的沟通，推动用户体验的落地和实现。这就对互联网设计师的沟通提出了很高的要求。

实际工作中，我们每天也花大量时间在开各种会，各种讨论上。沟通的效率和效果都直接影响着最后产出的质量。但在我们看最终的工作结果的时候，沟通作为过程反而不那么直观，很难去评价和衡量。我试着列举设计沟通中容易犯的一些错误，并总结了7条经验，希望对同样在思考这些问题的同学有些帮助。下文主要拿产品经理和设计师之间的矛盾冲突来举例。

1. 避免鸡同鸭讲

双方都在说自己的道理，却不听对方是怎么讲的；或者因为沟通双方无法说出真实的想法，导致沟通停留在表面上无法深入。这两种情况下，沟通效率都很低，而且很难达成共识得到结果。

比如我有一次看到，产品经理在和设计师争执，一个在讲运营的事情，一个在讲设计规范的事情，都在尝试着告诉对方，从自己的专业角度来看，这个事情应该怎么做。讨论几乎无法进行下去，因为谁也不肯让步。这种沟通效率是很低的，双方压根就没有站在同一个层面讲问题，设计师不懂运营，产品经理不懂设计。

这种情况在新人身上更常见，因为新人刚进入工作岗位，只了解自己的专业和工作内容，还不太理解别的团队中其他成员的目标和立场，很容易出现鸡同鸭讲的情况。当发现自己和对方讲的不是一个层面的东西时，及时找有经验的同事来帮助沟通会是行之有效的办法。

另一种情况也很常见，就是沟通的其中一方不愿意或者不知道怎么说出自己真实的想法。如一个产品经理一定要设计师改一个东西，设计师怎么解释也没用，请来了有经验的同事看，也觉得这里其实不用改。沟通到最后才发现，原来是产品的老大说要这么改，产品经理在老大面前答应了要改，所以就跑来设计师这里软磨硬泡。产品经理如果可以从一开始就告诉设计师，这个需求是来自某某，我坚持是因为我答应某某说肯定可以改掉的，整个沟通就不需要耗这么久了，因为只要把这个某某也卷入一起讨论就可以搞定了。

设计师需要掌握更多跨专业知识，理解不同职位的立场；学会讲自己内心真实的想法，挖掘对方的表述背后真实的含义。只有当设计在同一层面上时，才能做更有效率的沟通。

2. 不要过早陷入细节

优秀的产品一定是有细节的产品，优秀的产品设计人员也一定是个对细节敏感而挑剔的人。但细节也同时意味着需要更多精力的投入。要让投入有性价比，就要把握好切入细节的时间点。做产品和画画的道理很像，先草稿，再勾线，再上色，是一个由粗入细的过程。草稿没画完的情况下，如果先上了一部分颜色，再要修改整体构图就非常困难了，或者就得换一张重画。

道理说起来很简单，但实际操作的时候，即便是有经验的设计师，有时也会不自觉地陷入细节。比如有次开会，会上需要确定产品的定位。偶然讲到一个遗留的设计问题，于是开始激烈地争论，直到开完会都没讨论出结果。这个设计问题重要么？应该说也是重要的，但是否应该在确定产品定位的会议上讨论，是否应该卷入这些人参与讨论？

3. 认真你就输了

团队每个成员掌握的信息是不对称的，而设计解决方案往往是综合了这些信息之后做出的判断。所以不管是谁提出来的方案，随着讨论的深入，都有可能被证明是错的，或者有更优的解决方案。

讨论中每个人都会有自己的赞成或反对的观点。见过一些人，会非常激动地维护自己的观点，和别人大吵什么是对的。他会陷入自己的思维，无法跳出来，甚至有时自己也觉着不对了，也依然为了面子而坚持。这种人往往特别喜欢坚持，和他们确定方案是件真心累的事情…

每个人都会维护自己的想法，但我们不用像捍卫尊严那样去捍卫它们。有经验的设计师会控制自己的情绪，平静而肯定地表达自己的立场；在发现自己错误的时候，能不失面子地向对的方向靠拢。做得更好的设计师还知道怎么控制别人的情绪，在轻松的气氛下把讨论搞定。每当有人很激动地表达的时候，我会笑笑跟他说，你认真了。

4. 同理心

做互联网的同学都知道要站在用户的角度看问题，最好能够一秒变小白，这就是所谓同理心。但同理心其实是典型的知易行难，不说一秒变小白了，一小时能变小白就不错了。而在做设计沟通的时候，是否能以同理心去沟通，也直接影响到沟通质量。

有这么个例子，A想了一个晚上的设计解决方案，第二天很开心地过来跟B一说，B说这个不行，我早就想过了。然后两个人就火药味很浓的吵起来了。表面看起来两个人在争论方案，其实是尊严之争。A一个晚上的思考，几秒钟就被B推翻了，B否定的不是A的方案，而是A的智商。A也不明白为什么自己火气就很大，就是要跟丫死磕。

这个例子中，B可以试着反过来想想，如果A在瞬间否定自己，自己会怎么反应，就能明白问题的症结了。这个例子给我们的启示是，永远不要第一时间否定对方，要说让我想想。即使第一时间就对是非有个判断，也要先拖一下，给自己点时间再仔细思考下方案的合理性，再给出答复。

能够想他人之所想，确实能够大大帮助到我们日常的沟通。但是和一秒变小白一样，这需要大量经验的积累才能达到收放自如的境界。不过我还是有个建议，可以帮助更好地沟通。就是当自己情绪波动的时候，可以直观地表达自己的感受给对方听，而不要防卫性地攻击。比如当对方说你的设计很丑的时候，你可以说“审美是主观的，每个人都有自己的评判标准，不过这个设计你觉得丑还是让我很沮丧”，而不要说”这个哪里丑了，这么上流的设计都看不懂你个土鳖，你倒是画个给我看看“。前者的表达直观地把自己的感受传达给对方，使得对方更容易“同理”你，后者只能使沟通变得更糟。

5. 认同“形式追随功能”

一些“有追求”的设计师经常容易犯形式大于功能的错误。

作为设计师，我们要明白，虽然界面表现很重要，但是形式是追随功能而存在的，不能为了追求表现形式而要求功能做妥协。好用和易用，都是建立在有用的基础之上的。当功能和界面表现发生冲突时，界面表现应该向功能妥协。比如要设计一款商务应用，如果为了体现设计师的成就感，非要把界面做得充满趣味性，那就违反了用户使用场景；反过来在游戏里，界面就不能设计得枯燥乏味。设计师要能够控制住自我表现的冲动，认真地理解产品定位和用户场景，然后做出好的设计。

形式追随功能，换个说法其实就是功能限制形式，设计是带着镣铐跳舞。前段时间听广研nico的分享，他对设计师的定义我很喜欢，他的定义是：设计师是有方法的人。这里引用一下再加个定语，所谓牛逼的设计师，是指在种种限制之下，依然可以用优雅的方法解决问题的人。

设计师要从内心建立起对这一理念的认同，转化到沟通中，就更容易和产品团队达成一致。

6. 引入外援

即便是富有经验的设计师，也难免会碰到在沟通中陷入僵持的情况，谁也说服不了谁。这个时候如果擅于引入外部的声音，会非常有助于打破僵持。

也许可以暂时搁下争议，回去做数据上报，一周后看数据大家再做决定？或者随机在周围找n个和项目无关的人，对目前的解决方案做个A/B test，用一场快速轻量的测试解决争议？或者找一个你们都信得过的权威来给点建议？看看置身事外且经验丰富的同事怎么看这个问题。

卷入更多的人，能帮助我们更全面客观地看待问题，跳出从“我”出发看问题时的局限。而在僵持不下时，第三方的介入也给当事人留出了一定的空间，双方退一步冷静看问题之后，更容易达成一致。

7. 教学相长

职业生涯中，什么样的队友都会遇到。神一样的固然要好好把握，猪一样的也要循循善诱。

好的设计师一定是个好学不倦的人，除了设计以外，积极地通过平时的沟通机会，了解和学习跨专业的知识。当你能理解开发是怎么实现的时候，就不会设计出开发无法实现的设计稿；当你能理解产品经理想的是什么的时候，设计返稿率一定会大大降低。

好的设计师一定也是个好的老师，潜移默化地影响身边队友的理念。把自己的设计思想和审美品味带到整个团队中来。当团队成员对设计理念的认同和审美品味趋同的时候，以上很多沟通问题就不成为问题了。是不是会“教”，或者说是否具有影响力，是高级设计师和普通设计师的一道分水岭。有影响力的设计师，能够更大程度发挥自身价值，进而影响项目结果。

严格来说，第7条已经和沟通本身无关了。持续学习并且善于总结分享，应该是每个优秀设计师的必备素质。在这个基础之上，影响团队，增强共识，才是从根源上解决了沟通问题。

(本文出自腾讯CDC博客: http://cdc.tencent.com/?p=7080)

相关话题：产品设计团队协作源地址：http://cdc.tencent.com/?p=7080

前端开发是产品设计么

千鸟 — 2010-11-08 08:52:39

前数日与最近名动江湖的UCDChina小女孩Angela及某圈内人士在某店内烤肉论道，偶然聊到此话题。换个更动听的说法，前端开发是属于“研发团队”还是“产品团队”？此问题涉及公司的职能架构体系，也就会牵涉到跨部门的团队协作。

产品质量有一定高要求，但没有专职前端开发工程师的产品团队里，常见工程师以需求难度工作量、项目进度等理由推翻设计成果。好点的反馈给设计师，设计师们重新降级设计再交付；差点的直接改掉设计，造成产品质量不可控。所以我一直的观点都是“前端开发”归属于“产品职能”范畴，Angela他们两位意见正好相反。包括用户体验的要素模型，我个人意见早就改成六层了，最表面再加个“语义层”，凑齐Strategy, Scope, Structure, Skeleton, Surface, Semantic共六个S，缘分啊（模型等想法成熟后再改）。

这是一段很有趣的讨论，上到前十年，下到后十年都有涉及。因为我不做“前端开发”并已远离互联网大公司很久，所以个人观点存在推论的假设，想听听前端开发工程师的切身体会，尤其各位还在江湖的同行。我的观点如下：

第一，交付物方面，我认为产品团队的最终产出物就应该是高保真的页面原型，而不是一堆图形，更不是一堆文档。注意，我说的是页面原型，而不是图形。另外，这个低保真、高保真业内并无统一规范，我所指的“高保真页面原型”是与线上流程无误、视觉无异、内容无错，并且代码可以直接嵌数据开发的版本。基于这样的标准，肯定需要专业前端工程师。

第二，团队协作方面，我认为前端工程师解决最多的应该是“交互”问题，前两年很火的一个词——AJAX便是例证。可以说AJAX重新让Javascript焕发了第二春，得到了重视，它最直观的价值便是改善了网民的交互体验，比如浮动层和无刷新调数据。也就是说前端工程师应该与“交互设计”职能紧密配合，当然不能跨部门了（海外很多交互设计师的职能列表里就有Javascript）。我知道前端不是只有Javascript，但我不认为只懂css,xhtml可以叫“前端工程师”，因为那是做web design的基本技能。

第三，管理方面，我认为产品方面必须有一位总头领（如产品副总裁、产品总监）全面负责产品质量，包括“前端开发”职能。因为产品设计的所有输出都必须经过“前端开发”表现出来，否则无法准确评估设计质量。如果“前端开发”是在“研发团队”并归属于另外位总头领（如技术副总裁、技术总监）负责考核，设计交付物很可能成为互相推诿的炮灰，反正我肯定不会干。一个职能归属于哪个体系，这个看似皆可的表象之下其实暗流涌动，具体诸位自己参悟吧，没法说太细。

基于以上见解，得提一下我是计算机背景，有编程功底，可以手写结构表现层xhtml,css代码，行为层jquery类似的类库略懂。对信息内容方面有感觉，图形化方面功底相对弱，纯逻辑层面的产品设计职能也算是实践了好几年。

十年前我们做网页设计都是可视化的，使用的不管Frontpage还是Dreamweaver基本与Photoshop无异，很少有人去关心什么代码。到后来Web Standard设计思想的引入，我们懂得了Web页面有结构、表现、行为三层之分，层次分明的种种好处，彻底颠覆了“页面仔（前端开发前身）”的价值。再后来就是上文提到的AJAX，促使市场更加重视“前端开发”这个职能职位，包括有独立的团队来做事。但长期以来，“页面仔”地位一直就是个玩笑，戏称为比设计师多懂点代码，比工程师多懂点设计。据我所知，目前几乎所有有实力组建“前端开发”团队的公司都把它归属于“产品”部门，或者“产品设计”职能体系之下。

十年之后预测我曾经提过，寄希望于HTML5和CSS3，可以直接承担大部分表现层“视觉设计”职能，只不过这两个家伙成熟差不多要十年，包括最近很火的移动互联网产品也离不了这两位。就目前CSS2的能量来说，我认为只要审美不太差的web designer也能做出“视觉效果”不错的页面。从事物发展规律来看，这个技术领域将来会很吃香，学这门手艺人会越来越多，相应的专业水准要求肯定会水涨船高。而在技术标准日趋成熟的将来，“前端开发”与产品设计其他职能会绑的更紧密，包括如果要做“敏捷设计”或“产品规范”，也必须“前端工程师”的紧密配合。

最后，对于认为“XX工程师”就是归属“研发团队”的观点我完全不认同，写代码就叫“工程师”理由有点牵强。目前我认为优秀的互联网产品设计师一定要懂得写html,css代码，而将来如果不懂html,css代码的新手会很难找到我们这行的工作（中国人多啊）。

相关话题：产品设计团队协作源地址：http://blog.rexsong.com/?p=11695

理想结构与无奈结局

纯银 — 2010-08-23 13:14:00

若干年前，曾见《霸王别姬》的一名主创人员接受采访说，这片子的编剧、美术、造型、化妆、摄影、剪接、音乐、演员、导演等等，整个主创班底都是当时业内最牛逼的人物，又能全情投入，不成功没有天理。即便换一个导演，电影也能同样放在殿堂里受后世供奉。

作为这句话的注脚，陈凯歌后来拍了《无极》。

在互联网上最重要的资源是什么呢？当然是人才。什么资源背景，市场先机，都扯鸡巴蛋。最重要的资源只有一项：人才。在项目需要的每个位置上，都有足够数量的，合适的，甚至是优秀的成员去履行好自己的职责。

拿产品项目举例，在中型以上的公司，中型以上的项目，通常需要哪些岗位配置呢？

首先是产品经理，或产品总监，他的主要工作有四项：
1、目标规划（研究市场，保证项目向着正确的方向前进，并有着合理的阶段性目标）
2、搞定资源（从人员到推广，向公司争取合理的资源供给）
3、协调配合（促使同部门、跨部门之间不同的职能单位紧密配合起来）
4、抓住重点（确定每个阶段每个模块的重点所在，调动力量，亲自督促集中突破）

其次是策划经理、运营经理、技术经理，他们的主要工作也是四项：
1、团队组织（进行合理的人员分工与任务分派）
2、需求管理（从多方面收集并整理需求，划分优先级）
3、计划进度（根据需求制定详细的分解计划，时间节点，监督进度完成情况）
4、品质保障（控制好每一项计划任务的完成质量）

在经理之下是执行层，执行层分为两级：高级与普通。高级策划/高级运营/高级程序员完成最重要的模块任务，经验不足的普通执行人员完成相对次要的部分。

按照以上的人员梯队配置，毫无疑问能保证良好的战斗力，但现实多半不这么完美。由于人才缺口，产品经理常常要兼任策划经理的工作，哪怕过多投入琐碎事务会挡住视野，降低市场嗅觉，干扰他对方向与重点的判断。在理想结构下，产品经理更应该多做全局性的观察和思考，而不是沉溺于每一个细节——当然，前提是有合适的人来管理好每一个细节。

与此同时，策划经理可能也有苦衷。由于属下缺乏高级策划，自己常常要兼任高级策划的工作，亲自攻克难关。这样的事情做多了，谁来牢牢抓住需求与进度？谁来承担复杂任务的组织管理？他同样也疲劳不堪。

再说到执行层，即便是优秀的策划人员也分很多类别。有人适合做需求明确的功能应用类产品，有人适合做需求模糊感性的社区类产品，有人适合做营销意识强的电子商务产品，有人适合做轻巧而灵活的移动产品。而运营工作更有着内容管理、活动组织、社区关系、资源协作等明显的偏向。你有一些很好的执行成员，并不意味着有一些很适合的执行成员，这个世界上没有万能侠，没有最好，只有最般配与最契合。

这样的一个产品项目，方向未必正确，重点未必清晰，组织计划未必严密，成员特长未必匹配，肯定走得一瘸一拐。如果在策划、运营、技术等层面上压根没有执行主管，那就更加糟糕，产品经理被无休无止的琐事困住，顾大局则失细节，顾细节则失大局，疲于奔命。

麻烦还没完呢，做好一款产品可不仅仅是产品部门内部的事情。如果策划人员的交互设计能力较弱，有没有一个专业的交互设计师专注、及时地配合？有没有适合这款产品美术风格的一到两个视觉设计师专注、及时地配合？有没有专门研究过这个产品市场的推广同事，商务同事专注、及时地配合？这些第三方支援对产品的进度、质量、成败也有决定性影响，但常常是产品经理无力把控的，只能对天哀嚎。

反过来看，如果在任何一个产品项目所需的全部岗位上，都有足够数量的，合适的，甚至是优秀的成员去履行好自己的职责，如果这个项目本身的定位又不算盲目，那么你已经有了70%的成功把握。

所谓成功，其实就这么简单。

当然，其实也最不简单。

最近听说毗邻的某公司，一下子又要招500人，深感我们这个行业处于高速扩张之中。这听上去让大多数人振奋，却使我苦恼。高速扩张意味着人才短缺，进一步引发各个项目内部的人才稀释。稍微培养起来一个高级职员，很快就跑去做执行主管了（不管适合不适合）；稍微培养起来一个执行主管，很快就跑去做产品经理了（不管适合不适合）。对人才的培养和发掘远远跟不上项目发展需求，更加跟不上跳槽转岗的速度。只要你真是个人才，工作机会无穷无尽，任挑任选；但对于我这样的部门主管，则很难攒到一支齐备而强大的团队。

此时只有三字真言可用：“抢”！去公司内部拼命争抢人才。“填”！自己分心去做其他岗位的工作，填上职能缺口。“拖”！无能为力的时候也只好放慢速度，无奈地拖过去，希望拖到转机出现。

之前我写过一篇日志叫《绑架》，其实，都是一个系列的故事。我在那篇日志里讲了一个“先人后事”的道理。如果一开始就缺乏某些核心岗位的人才，项目必定举步维艰。如果指望着项目启动后再招聘补充这些人才，残酷的现实多半要告诉你：这是一个妄想。最后自己被越走越累的项目拖住，前进乏力，又放不下来。瓶颈在哪里？就在“人才”这里。

我为此设想了一些解决方法。

首先，从现实的人力资源出发，包括现有团队的才能与偏好，个人的人脉资源，公司的招聘实力，数清楚手上的人才筹码后，再去考量自己有能力做什么样的项目。当然，你可能数了半天，发现自己只能做点小事，琐事，杂事，非常沮丧，又按捺不住野心。于是一急就要冒险，一冒险多半踩雷……

其次，在选择工作的时候不要被公司大小，职位高低，待遇好坏所迷惑。最重要的考量因素是，我将去的地方是否适宜自己发展？包括管理文化，项目定位，尤其是招聘实力与团队配置，是否能支持自己做一番响当当的事业？搞清楚，兄弟，你个人的才华在项目成败中影响甚小。不要以为自己了不起，没有人以一顶十。即便你在所处的位置上真是才华横溢，冠绝宇内，其他岗位如果缺乏必备的人才，任何一项重要职能的残疾都足以拖得整个项目歪歪斜斜。这时你能做什么？徒劳无功的 “抢”？三头六臂的“填”？唉声叹气的“拖”？还是望穿秋水，眼巴巴，可怜兮兮地等着一封闪光简历飞进邮箱。

招聘可不是一个靠时间流逝就可以解决的问题。

最近跟朋友聊天，扳着指头数，如果按照“较好的规模、品牌、受众影响力”为标准，在我们这个行业里，每年新进入成功队列的项目有没有5个？数了半天，似乎连5个都没有。天啦，每年新发起的项目起码有500个之多！如此高的失败率，只能证明合适的人走到一起齐心协力，这得有多难啊……真是三生修来同船渡。

我曾在微博上讲，最近6年来，我近距离所见大大小小的项目近百，而成功者仅四五例，究其根本原因，竟然全都是“人才缺口”四个字。不论你是VP、总监、经理，不论你有多么卓越的头脑与资历，在多么了不起的公司领多么丰厚的薪水，最终决定成就的，也只能是“人才配置”四个字。别指望靠一人之力组建一个彪悍团队，脱离了整个组织背景的人脉资源与HR支持，得不到均衡的人才供给，强龙也只是条志大才疏的虫子罢了。聪明人大都有舍我其谁，独领风骚的壮志，然而，同伴比职位薪水更重要10倍！

那么，聪明的你，接下来想拍《无极》还是《霸王别姬》？

这与你是不是陈凯歌全然没有关系。

关注前端开发流程

龙刚 — 2010-01-02 16:50:37

流程，通俗来讲，就是许多人，在做一系列的事情时，怎样相互协调，安排好这一系列事情的先后顺序，有什么事先的约定，需要达到怎样的预期目标。

在UED里，前端同学需要处理的需求比较多，早些时候，前端这里的开发流程还是比较模糊的，UED以外的同学也不清楚这边的工作具体是怎样进行的，所以难免会有需求插队的情况发生，打乱了大家的计划，因此今年Q3的时候，在与SCM团队同学的共同努力下，形成了一个前端的ASSETS发布流程。

这个流程主要针对ASSETS发布的需求做了一些约定，制定了相关的几个时间点，包括审核需求、提交代码、daily测试、预发测试、正式发布到线上确认的时间。

ASSETS流程简述

需求审核

在提需求之前，需求方一般都会先找PM或者相应产品线的前端咨询一下，如果可行的话就会在周四之前将需求提到平台上，到了周四的时候，前端会结合自身的工作情况，将平台上的需求接收并纳入自己的日程中，预估完成时间、发布时间以及相关的发布简述。

编码开发

周四需求评估完以后，就会按计划开始处理需求，将涉及ASSETS发布的需求优先处理，不涉及ASSETS的放在靠后的时间处理，一般这段时间是从周四到下一周的周二。SCM会在每周四开一个新的ASSETS分枝供前端在下一周开发使用。

提交代码，合并到daily测试以及预发测试

如果有涉及到与后台开发相关的需求，前端的同学会在周一就把代码提交，这一天会有一次合并代码，方便后台开发来测试。其他的同学一般最晚会在周二下班之前把代码提交，在周二，会有多次合并代码到daily的操作，每次操作完后，SCM的同学会在前端的群里通知到大家，方便大家测试。

周三早上，SCM的同学会将代码发布到预发环境，此时就可以在HOST中绑定IP，换用线上的地址来测试。

正式发布

周四上午，SCM的同学确认后，将没有问题的代码发布上线。

流程的作用

在团队不断成长的过程中，处理的需求数量也在增长，需要考虑到开发的效率、产品的质量以及团队协作间的配合等因素，这个流程能为我们解决很多相关的问题：

督促需求方做好相关的规划

有些时候，一些需求的细节还没完全确定，但需求方总希望能将他想到的各种细节都实现出来，然后再挑选其中一种做为他的方案，所以需求的变更会有些频繁，然而这样的成本有些高，一切应该在计划后再去实现，而非反其道而行。现在需求方会在提需求之前，会花时间地去考虑他们的需求，将尽可能多的情况都想清楚，做好必要的沟通工作，权衡各种利弊之后，再给出一个比较成形的方案。

保证需求安排的有序性

在一个大的团队中，不同部门的同学在一起合作，因为沟通及一些特殊情况，效率或多或少会受到一些影响，良好的规划能有助于提高开发的效率。

通过每周的需求审核，安排好下一周的日程，由于需求的优先级和先后顺序都已排定，工作的条理性会更加清晰，需求插队的现象也有明显减少。当然我们也有紧急流程，但是它仅限于处理线上bug以及一些经过多方确认的紧急需求，有其自己的适用范围。

统一测试，归避风险

之前的日常处理中，可能会遇到这样的情况：甲、乙两个同学分别需要处理两个日常需求，他们的需要改动到的代码会有重合的部分，如果他们并不知道这个情况，那么在他们本地的单独测试中，一切都是OK的，然而当发布到线上去时，发现出了bug或者一方的改动没有同步到线上，查原因后发现是提交的代码相互覆盖了。

现在要处理的需求数量越来越多，为了避免上述情况，新流程实行以后，大家会统一来做多次测试，这样就更容易发现bug，可以大大降低协作开发而产生的风险。

流程本身就是一把双刃剑，有利有弊。一方面，它使我们的需求变得有序，使前端能够在处理一个需求时，不会频繁被其他插队的需求打断。并且因为发布有时间点的设定，所以测试工作会更加严谨，这有助于提升代码的质量。因此对于我们来讲，流程带来的好处是显而易见的；但另一方面，它额外地增加了做事的成本，涉及ASSETS发布的需求，就像赶某班火车一样，错过了就只能等下一班，所以也给需求方带来了许多不便，有待改进，不过这可以通过长期的合作而慢慢被弱化，双方达成了一种默契以后，情况会好很多，现在这样的情况已经比较少了。

尽管在流程使用之初，会带来诸多不便，但是从长远来看，流程有助于使一个团队形成统一的工作方式和态度，将繁杂的事情化整为零，有条理地去处理它们。因为流程，每一个人的责任感都会增强，对风险考虑得会更多一些，这一切都会使产品有质的提升。而我们所有与这个流程有关的人，都会不断地去推动流程改进的工作，这其中还有很多需要思考的：

如何将我们的流程推广到整个公司，让大家都能了解我们的流程，这样在未来需要合作时，需求方需要注意些什么，相关的时间点以及开周时间的预估等，他们就会心中有数。
ASSETS的发布还不够灵活，如果把和应用相关的ASSETS独立划分出去与应用一起发布，这样剩下的需要发布的东西就会少很多。或者是按产品线来设计发布流程，根据实际情况来发布。
如何来简化流程上的一些细节，在保持效率的同时，降低实际操作中的成本。
每周二是一个特别的时间点，为了赶在这最后时间提交代码，之前的开发会有些紧张，这种情况也有待改善，比如未来可以一周有两次发布。

流程不是生来就完美，但从现在它带给我们的好处来看，遵循并使用它，对我们的开发会起到很大的帮助作用。我们对待它的态度，决定了它对我们会有怎样的反馈，如果觉得它不合适了，就发出自己的声音，想办法去改进它，不要只是被动地等待。

———————————-

部分名词解释：

daily环境：UED的一个日常测试环境
预发环境：外网IP，需绑定访问，供内部使用测试
ASSETS：脚本和样式存放的目录
SCM：软件管理配置
PM：项目经理

我们需要怎样的分享？

哈嘍柒柒 — 2009-12-30 20:33:08

杀了几轮三国杀，稍微缓解了上班的疲劳，回来路上和平四同学聊起了设计师的分享，或者說我们的分享机制。

早年间，大团队内部的分享更多是答疑解惑，每个人把自己工作遇到的问题抛出来利用团队力量解决，或是把自己的老经验小巧思介绍给大家。后来呢，分享这件事变成了工作的一部分，连话题也渐渐审慎起来，多少有点例行公事。

不少新来的同学都苦闷于不知道要分享什么主题，而自己费劲巴拉准备的PPT又能给别人带来多大的收益呢？我也时常为分享犯愁，所谓己所不欲，勿施于人，自己最怕听那些大道理，所以很想把写作或者演说内容搞得充分一些再分享给大家。无奈水平有限，尽管有时候用心准备了，对他人可能依然是无用之物。所以在闲聊时总结了下自己比较倾向的三类分享：

1.方法+贴士

新人和老枪差在哪儿？多数时候无非是经验的差异。提及体验啊、交互啊，从业的同学们都能说出个10条准则、5 个要素的，但真到了工作中又不知道怎么做才能达到那个高度。人人心中都个美好的愿景，只是没人提供那理想的阶梯。所以做事的方法和技巧很重要。方法也并非那种高深的方法论，而是着眼于小处，从实践中总结的步骤、手段，受众们只要照着去做再加上一点儿悟性就能提升自己的设计。以前从觉得老外啰哩吧嗦，总把几句话的道理写成一大本书，然后填充各色的举例证明、贴心提示，细致到不行，现在觉得这类书或分享才是最快受用的。

2.工作坊

小团队中流行一句话，做过就比没做强，理论需要实践的验证。对于我这样的懒人，工作坊算是寓教于乐的方式。一方面传达了方法，一方面又能让受众马上去实践一下这个方法。高度的参与感 UPA时参加两场工作坊，美国同学的风格热情，多在训练意识和表达；台湾同学的风格精细，意在快速上手掌握方法。两场下来倒是学习不少做分享的经验。

3.工作范畴外的知识

页面需要留白，工作也需要呼吸，所以分享可以涉及一些与日常工作和专业无关的话题，放松的讨论。而交互设计或者广义的设计本身就是很包容的学科，需要我们什么都知道一些，让自己的思维不会僵化。艺术不是来源于生活？可生活不只是原型+代码。

自己悟性较差，所以现阶段还是喜欢比较实用的分享。

相关话题：产品设计团队协作源地址：http://www.hello77.com/?p=194

用户体验与团队建设

Maison — 2009-09-08 18:23:36

很高兴很多公司能认识到用户体验的价值，甚至提升到了公司的战略高度来看待，而个人觉得这样的事有点悬。

用户体验的用户

用户体验一词应该来自于客户体验，CRM就是这样的一套系统来着。那么，客户或用户一定就是上帝么？他们所反应的问题或数据的反馈就一定是我们做任何产品设计的准则么？显然不是。如果一个产品设计师只会盯着数据看，他只能说做了一件没有错的事。从概率上来说，他只是能满足70%左右的需求。

所以，一味的追求数据和用户体验的公司，做出的产品只是能符合口味而已。就如同中国的游戏行业来说，很多游戏换汤不换药，只是换了一个噱头。那么这样的用户体验来说，只能让公司的运营们疲于奔命。因此，不能一味的把用户放在第一，因为UED部门也不能确切的告诉你每个用户想要的是什么。

客户和员工

在我所知的很多公司来说，面对公司生存，不断的压榨员工的公司不乏少数。很多公司自以为以价值观来约束或提升员工的归属感，在侃侃对外而谈自己的员工满意度和归属感的同时，其实员工都只是冷眼旁笑而已。或许在国内而言，这是必然。所以才想起海底捞擦桌子的服务员那种透露自豪的感觉，是能让很多国际巨头们都自叹羞愧。

面对于客户，其实员工才是公司最宝贵的资源。因为相比之下客户是最水性杨花的，只要那里服务好价格低，我就选择那公司。而员工呢？如果你有一群归属感和责任感的员工，那么再困难的客户我想都能谈下来。如果让员工感觉这公司和我无关或员工只是打工仔的话，我想公司的离职率很高或HR忙得不可开交的招人也是能够理解的了。我想很多读过EMBA的人都知道，但放到现实，都忘了，或蒙了。

面对团队管理

其实团队管理可以说是非常简单，也可以说是非常困难。简单的来说，管理只是对于人放在何处能发挥对公司的最大价值。而困难来说，管理最难的就是人。如果一个人的话只需要自己对自己的时间进行管理就足以，但两个且以上的人在一起做一件事，那么就应该有一个团队管理的认知。管理人的数量不是团队管理的难易的标准。且也不要认为价值观的统一就能让团队发挥最大价值。应该回归到每个团队成员，人的本身认知上。

浅谈5173

5173是一家明显的本土私人公司，虽然有IDG等风投的成分，但从管理上来说，IDG没有太多的过问和管理层的进入。为什么要在这里谈这家公司呢？因为我觉得具有一定代表性，在我之前待过或咨询过的公司来说。所以，所说的，都是一些创业型公司或者工作室团队也可能出现的问题。既然是浅谈，那么我就1234的来说吧。

1.用户体验的初浅认知，大多认为用户体验只是对于UI上的提升和帮助。因此认为用户找BUG和技术解决BUG就是UE。

2.盲目的跟从产品，抄虽然是中国特色，但盲从且不符合公司发展方向的抄袭，会使得产品线跨度大且没有一定共通性。

3.愚蠢的服装统一，5173的标配就是衬衫和西装，春秋冬系领带，整个像传销组织。管理层美其名曰，增加员工服务意识。却殊不知公司规章制度能统一服装，却统一不了员工的意识。越是在员工行为规范上制定条条框框，那么公司的发展越是高层的事，不关员工屁事了。

4.高度的集权统一，任何的大小事务都由某几个人来决定，当然包括厕所啥时扫，明天啥活动等，事无巨细一一过问且拍板。导致无论大小事务，做事的人都先说，老板同意么？

5.5S化的军事管理，在一个互联网公司来说，对所有部门的5S管理，5173是我所知的第一家。因为之前所知的，有客服，有销售等只局限于几个人多且难管理的部门来说。条条框框的限制，是限制了员工在司行为，当然也限制了公司的发展。

6.浮躁的管理，这个在很多创业起步阶段的公司也会遇到，创始人摸不清企业赚钱的目标，不制定大于1个月的战略目标，有机会赚钱的产品都做。这一种浮躁的管理方式，也会让下属的员工们更不清楚公司的目标，何来绩效？

7.地域化限制，公司都会具有一定的地域化特色，但是当发展到一定阶段之后，这样的地域化会制约了公司更大规模的发展。虽然引进高端人才能解决公司管理层上的问题，但是管理层们却忽视了管理中最重要的因素，人。不同地域的人的背景和意识会有很大差异，因此高级人才在管理上也应该更多的本地化管理，这样才能将才能运用得当。

以上只是其中比较典型性的一些问题，也是09年5-7月份之间我所看到5173的问题，当然希望以后能慢慢摸清问题并解决掉，这样会更利于公司的长期发展和促进地区的相关产业。

PS：以上博文内容皆为个人观点。转载请注明出处！

相关话题：产品设计团队协作源地址：http://www.maidow.com/blog/?p=310

鸟儿是追不上蜻蜓的

OutC — 2009-06-28 21:10:54

最近接了几个网站建设的活，从网站策划到网页设计制作，都是我和朋友两个人在完成，工作量虽然很大，经常忙到凌晨两三点，却不感觉到累。

这就是做顺畅了的感觉，网站的前期策划到最后的形成都是按照我的思路一步步完成的，这里面不存在繁琐的工作交接，几乎没有什么冲突，工作便很流畅。

之前看到一个命题：开发一款新产品，如何在开发质量与开发速度上作权衡？当时作者给出的答案是求速度。我表示赞同，首先不管产品质量如何，一但新产品面市，大部分用户习惯了你的功能和操作模式，到时候再想去习惯新产品似乎也就不是件容易的事了。过于追求产品质量，只会在其中浪费大量的时间和精力，高品质的产品是经过多道工序千锤百炼出来的，不是短工期内就能实现的。

回到原题，在产品开发过程中保持较快开发速度的要素是什么？说一下个人看法：

设计很重要。好比写作文一样，产品的设计就像是大纲，没有大纲，主题思想就会乱套。如果最初的设计没有完善到位，后期的环节中一旦出现问题，之后返工的代价会让人受不了。而且有足够创新力的设计也能使团队在开发过程中保持活力和激情。
规范是根准绳。规范的制定能使项目流畅的进行，不至于开发过程中会有人偏离了最初的产品蓝图。
小团队开发。小团队开发可以很有效的避免“体制臃肿和僵化”这一问题，在沟通协作上也不会出现大的磕绊，将效率执行到最大化。
无障碍的沟通协作。这是往往是一般项目组作开发时最棘手的问题，再小的团队也要沟通，除非是一个人开发。不同的意见产生分歧，分歧导致部分项目被搁置，最终延误开发时间。
使用有经验的开发人员。特别是在快速开发小组里面，有经验的开发人员显得特别重要，有经验的人会合理地规范自己的行为，而没有经验的人往往连规范都意识不到。

在快速开发中保持团队小阵容和创新力活力，再快的鸟儿也追不上蜻蜓，就是这个道理。

相关话题：产品设计团队协作源地址：http://www.uesign.com/2009/06/54804/

不同声音，一个设计

Gelei — 2009-06-16 23:31:04

发现在工作中、撞上最多的问题就是“如何达成共识”（而且我想只要我还打算继续做下去、它还会是个经常性的事情）、几乎每天我都会听到很多不同的声音、在这儿列下清单:

“ 这个颜色看起来不够时尚、不够醒目啊 ”
“ 人气人气！页面要表现出热闹的气氛、火红的颜色 ”
“ 我们这个产品与其他产品不一样、不用考虑我们公司的其他产品 ”
“ 功能太少了、用起来效率低 ”
“ 我们的产品要加点生动的图标 ”
“ …… ”

当然一方面、借助这些不同的声音可以让我们的思考不必受限在盒子中、但另一方面、常常“达成共识”又是一个复杂漫长的过程。怎样让“达成共识”能更容易一些？这是我正尝试的方法：

1. 明确问题
不同声音往往是对某件事缺乏共同的理解、明确当中的“某件事”的实质是什么？简化问题的重点。

2. 是否符合设计目标
明确问题后、点到与设计目标有关的问题上、去问: 这个方案真的符合设计目标吗？

3. 利用规则
有一些原则是必须遵守的、有一些是允许设计发展的空间、明确问题是归于前者还是后者、前者是必须遵守的共识、后者是需要达成的共识。

4. 说明设计内容
对不是原则性的部分、详细的向对方说明设计的构思、设计的目的、想要呈现的设计个性以及使用产品的情形，避免一部分太个人喜好的看待设计问题。

5. 重新思考
如果还存在有缺乏共同的理解的部分、反思我处于什么角度以及是怎么考虑的、这是我的判断还是预测？从自己的境地再重新思考。

6. 检阅设计
以上阶段如果还意见相左、那就邀请更多的人对设计进行检阅、总结评估结果和改进建议。

另外、沟通时注意的：

1. 倾听
随时停下来倾听、避免自说自话、也要避免陈述上过于绝对（我的感觉是往往要非常认真的去听对方的意思）

2. 语气
尽量用征询的语气、切忌一副苦大愁深的表情（这也是我要改的地方、之前受石磊影响多了）

3. 语言
不装、用平实乃至粗浅的语言去说专业上的事情（“设计来设计去”的听着头晕）

4. 词汇
蹦中文、不过度包装且直白

相关话题：产品设计团队协作源地址：http://www.uedblog.com/?p=79

前端开发中的团队合作

cuikai — 2009-06-12 01:18:14

最近在着手“蓝色理想”的页面重构工作，这次的项目与以往来比有几个劣势：

对参与开发人员的水平均不了解；
陌生人，谈不上谁配合谁，只能自己多协调一下大家的编码习惯；

结合这两天的项目进展及过去的工作经验，谈一下前端开发中的团队合作：

详尽的开发文档
一件产品的诞生，凝聚的是整个团队的努力。要让大家的劲往一处使，最好能在项目开始前，准备好开发的文档，写明注意事项。未必是最完美的，初期通常考虑不了那么周全，但不能因为这个原因，而放弃文档的制订。前期节省的时间，造成后期维护成本的增加，得不偿失。
代码注释
每一个参与开发的人员，必须注意到自己的代码应该是清晰紧凑的。
时时问一句，我有没有为一起做这件事和后续做这件事的人着想。
避免样式冲突
文章开头的案例比较小，暂时没有出现大规模冲突的情况。
但是在实际的团队配合中，通常会出现这个问题。
在开发中，要尽量避免使用 p h1 h2 h3 li 这样的通配符，以及 .left .right 这些大家有可能用到的变量名称。如果一定要用，放在显眼的位置。让大家知道，你给过什么属性。
重复冗余代码
相比较个人开发的页面，重复属性是团队开发中的一项弊端。自己写的代码，肯定知道哪个模块可以通用。但是同事们写过一遍的代码，如果没有经过调查，往往会再写一遍，等网站上线那一天，突然恍然，哎呦、原来他已经写过XX代码了……
为避免这个问题，需要参与开发的人员，仔细观察设计稿中可以重用的元素，在开发前，明确哪一块是可以通用的，由谁来编写。这样前期耗费一点点时间，减少了整体代码的大小，更减轻了自己的工作量。
沟通
07年刚加入某开发团队，很陌生，有什么问题自己钻牛角尖，不闻不问的编写代码。这点是很不利于项目进展的。有问题，大家拿出来交流一下，简单的两句话，可以省掉很多编码编写的时间。把复杂的东西简单化。

团队协作中，假定每个开发成员的能力都是1，那么，10个人合作的结果可能大于10，也可能小于1。
我们需要做的是尽可能成为项目的推动力。
沟通是必要的，但尽量避免所有问题不加思索的全部抛出来。项目成员需要掌握自行解决问题的能力
人不是静止的事物，更像是方向各异的能量，相互推动事半功倍，若相互抵触则一事无成。

当设计师遇上前端开发

咏沙 — 2009-05-04 00:48:58

作为互联网产品设计师，在和前端开发人员沟通时你是否常常会听到这样的声音：

—— “大姐，给点专业精神好不好，这个表格是自适应的，你这样设计页面不好扩展啊…”

——“用ajax不是不行，不过你要事前给我说嘛，你不说我怎么知道呢，你说了我就知道了嘛…”

面对这些回答，除了欲哭无泪，你有没有想过是什么原因导致出现这样沟通偏差，有没有解决的办法呢？设计师需要了解哪些知识才能和前端开发人员来更好的合作呢？

首先得从这两者之间都有哪些不同说起。我认为最主要原因在于设计师和前端开发在部门中不同的职责划分。通常情况下，产品设计师的产出物多是线框图（wireframe),视觉设计稿（mockup）等，前端负责编写HTML,CSS等代码（demo），有时还会根据需要编写程序代码（如 JSP/ASP/PHP/Rails),光看这些分工，就知道不同的角色对产品的理解和着重点是截然不同的。

按照正常的项目流程，设计团队通常需要先设计出界面mockup或demo（HTML/CSS),接着开发人员才开始正式编写代码。然而多数情况下为了保证项目进度，需要开发人员和设计师在项目前期就介入进来，不同的是，开发人员多是审核通过项目计划书（PRD）和原型评审，她们更关注于技术可实现性；而设计师更倾向理解产品经理的项目需求以及通过什么样方式来解决需求从而达到提升用户体验的目的，她们更关注创意的可行性。

更令人纠结的是前端开发对“界面元素”和“交互动作”的理解和设计师有很大不同。统一的界面元素对网站的前端架构也会很有好处，他们更关注代码的可重用性。一方面是CSS：前端开发要实现设计师（或者自己引以为自豪）的界面设计，如果新页面的设计和原先页面中相同功能元素的设计有出入，哪怕是一点出入，都有可能带来很多重复的工作，将CSS文件变得越来越臃肿。另一方面是JavaScript：对于很多应用型网站，会有很多需要JavaScript的页面交互元素。这些交互元素的视觉或者行为设计与之前的有出入，也会让前端工程师为了既保证代码的健壮性来方便后端工程师的开发，又为了实现一些设计上的差别而对现有代码修修补补忙得不可开交，最可怕的是最终淹没于bug的海洋…而交互设计师的侧重点并不在程序的编码实现，而注重于用户如何最好地与系统交互操作，在设计中重点需要考虑的是界面元素的易用性：比如他们会考虑到并非每个用户都是计算机的熟练用户，面对隐藏的层和特殊设计的菜单可能会抓瞎，用户不见得能明白双击左键能自动滚屏或者怎样能让自动滚屏停下来，直接看最下面的结果？总之，设计师（完美主义者更甚）会不断完善产品，来满足更好的用户体验。

那么设计师怎样来解决这些问题呢？我觉得最重要的就是“沟通”，这是最根本的解决办法。在原型设计前期就要针对自己想法的询问前端开发在技术上的可行性，在界面设计过程中会有很多精确到像素级的标准，同样要和他们沟通了解代码的实现方式，不然很有可能做无用功。在提交界面设计之后，交互设计师也要主动出击，不定时的去关注demo的实现效果（mockup和demo多多少少存在不一致，在后期需要跟进；另外涉及到复杂的交互方式前端很可能会忘记或者搞混，也需要不断的去核查）。另外建立标准的文档管理和设计规范也很重要，好在我们开始建立设计规范和标准(淘斯基和TPL 模式库）的文档管理方法（SVN)，包括：

制定文件命名标准
设定文件统一路径
保存原始创作文件（例如PSD、Fla源文件）
最终完成文件（经过产品经理认可的文件）
视觉模式库和与其对应的代码模式库

当然，前端都很忙的，经常去“骚扰”他们会被鄙视的。跟他们沟通也需要技巧和一些基础认识，我总结了以下几点需要谨记：

网站的页面是动态的。photoshop呈现的是静态的东西，而网站页面是动态的展现内容、布局和交互。设计师过多关注用户体验层面，很难对所有的细节做到面面俱到。而前端（包括开发）需要照顾到所有的功能点涉及到的页面，因此在前期要考虑的尽量周全，别让别人帮我们收拾烂摊子。
关注新技术。网页设计缺少技术支持永远只是艺术。设计师必须经常关注新的技术和交互方式，这样才能在设计的时候提供多种解决方案，才能权衡利弊找到最优化的方案。
界面元素的标准化和统一。前端关注代码的可重用性，设计师关注新创意。因此在设计前期就要考虑哪些元素和交互方式既可以满足用户体验又能够被重复使用，以此来提高效率。
团队合作很重要。设计师很容易沉浸在自己的小世界里不能自拔，这是我们经常犯的通病。“沟通”是团队合作的关键，一切皆在沟通。
相信自己。前端通常出于不同的原因对一些交互方式可行性做出判断，比如代码复杂程度，技术可实现性等等。好的设计师需要有一些超前意识和冒险精神，当他们受新技术的激发，认为它能够大大提升用户体验的时候，就需要把它当作挑战来实现。在对技术的深入了解后去说服前端一起努力实现。

好了，这些血和泪的经验是我工作一段时间慢慢总结的，如果你有更多的方法，希望能一起分享。

如何向产品经理提交需求

北城 — 2009-03-26 22:41:32

今天公司的Happy Hour时间，是几位产品经理和大家互动，增进了解，以便业务上的更好配合。从业互联网多年，一直作为业务需求方，也曾迫于无奈做过一点点产品方面的事情，有一些经验和同事们进行了分享。

1 第一次的沟通非常重要，要对自己的需求非常明确，利用各种工具，包括纸质的图形草稿等，清晰的描述业务需求；

2 对于需求实现层面，要有一定的备份，当产品经理认为难以实现的时候，能够退而取其次；当然，首先要在业务层面对所实现的价值有一定的判断；

3 再三确认需求，要求产品经理能够非常清楚的复述业务需求；

4 平时注意积累，看到好的产品（是业务部门需求的产品，而不是产品部门的产品），要注意保存；可以是直接下载，也可以利用delicious、百度收藏、GReader等等；需要的时候，可以把这些作为Demo给产品经理做参考，无论是逻辑层面，还是设计层面，这对于需求沟通会非常有效；

5 要学习尝试看懂产品原型、流程图，这会有利于理解产品经理所设计的产品，提高沟通效率；

6 要学会产品经理、技术人员常用的若干专业术语，必要的时候这会让你显得很懂行，别人不敢蒙你；

7 精神层面的认同很重要，在沟通需求的时候，尽可能的让产品经理认同你的产品，让他们看到前景；当你的活动获得成功的时候，一定要及时的和产品经理分享；

8 多和产品经理打交道，要了解不同产品经理的习惯；有的产品经理希望得到的需求是故事型的，有的希望得到的是1234型的；

9 注意时间节点，设置报警点；在需求确认的时候，一定要和对方确认清楚完成时间；在过程中，要设置若干个报警点，适时的和产品经理交流进程，一方面避免走错路，一方面确保按时完成。

业务部门的人，往往不具备产品经理的技能，在沟通的时候更注意前端，对于产品的延展性缺乏判断。所以一定要和产品经理有非常充分的沟通。要记住，产品需求的确认，往往会占到整个产品开发时间的1/4—1/3左右。

相关话题：产品设计团队协作源地址：http://www.landigua.com/archives/417

环境是最忠实的执行者

Jian Shuo Wang — 2009-03-21 03:08:27

把水龙头稍微开松一点点，让水可以每一分钟滴一滴，放一个桶在下面，然后忘记这件事情（不用我提醒，你一定会忘的）。等你再过来看的时候，或许桶早已经满了。有趣的是，这个实验成功的前提是，你一定要忘记你做了这件事情，只要你还惦记着，桶里面的水就不会太多。

企业文化的事情也是一样。真的有用举措，一定要做一些像滴水这样的事情，在你忘记了它的存在的时候，它还依然忠实的执行它的职责。

所以说，仅仅落在书面上的规章制度是没有用的，开大会是收效甚微的。这些变革，无论当时多轰轰烈烈，要不了一个月，就在时间的冲刷下消散的无影无踪。

而像海报这样的东西不一样。贴上去的时候不见得有人注意到了；贴了三个月，你会发现真的会有作用，因为它们是每天都在对它们周围的人有些影响，而这三个月里面，可能你的注意力早已经转移了不知道多少次了，也必然忘记了什么时候把他们挂上去了，而它，就在你忘记的时候，在帮你提醒着自己和周围的人。

改变人的行为的最好办法是通过改变环境。因为环境是最忠实的执行者，你做了改变，它就一直在那里；你已经忘记了，它不会忘记。

这是一些从我们的办公室布置中获取的一些点滴灵感。对此列表，Eric同学亦有重要贡献，

如果沟通不足的话，多放些沙发；
如果一个地方特别容易滋生闲谈，去掉那里的椅子，或者放几盆植物。
如果开会容易超时，要放一个大挂钟，
可以写字的玻璃墙旁边，一定要放写字笔；
同一个团队一定要坐在没有个隔板的大cubicle里面，无论多挤，
不同的团队之间，要加上隔板保护团队不受干扰；
办公室只留一个进出口，让团队的成员要有机会通过一个走廊，以便增加大家打照面的机会，
饮水机边上一定要有沙发；
如果一件事情足够重要，印在T恤衫上面分发给团队；
没有什么比免费的水果更能把大家围拢在一起；
技术团队要有一面墙画系统架构图，拓扑图，甚至核心代码 - 除非把大家在做的东西形象的展示出来，否则千万不要以为所有人都知道他们在做些什么。。。

大家还有什么有趣的发现，或者推荐什么书吗？欢迎留言。

推进项目的诀窍

panda — 2009-03-20 13:00:24

和大家明确了KPI和项目计划之后，明显感觉大家是跑起来了。同样也看到了我们在项目推进中的困难，今天也正好说一下推进项目的诀窍。

首先是心态，创业的心态，主人翁的心态，不要问这个问题谁负责，问这是谁的责任，把梦想和目标当成我们自己的事情来做，自己为自己的梦想而奋斗着！这是推进力的源泉，我们是一支使命必达的团队。
推进力的最高境界，就是让大家自我推进。优秀主导者并不是把自己的方案灌输下去，而是说明问题，激发合作伙伴的潜能，让他们提供更好的方案。这是推进力的核心。典型代表就是L同学。我观察L同学总是不遗余力的解释问题的严重性和用户的困惑，让设计师和工程师自然而然的觉的，不解决这个问题，实在是太对不起客户了。（虽然L同学被我们戏称”L前戏”，L同学总是能激励合作者们提供超出期望的方案。）说白了，忽悠，也是种能力。
深入，再深入的挖掘问题。很多人随便两下就可以看出的问题，S同学经常用 “挖”“刨”这些词来对待。优秀的PD和UED不仅要刨根问底，还要带着刨祖坟的心态去对待问题。L同学的前戏很长，其实详尽的描述问题意味着他对问题深入透彻的理解，也有助于合作伙伴抽象出来看清楚问题的本质，其实是把大家的讨论抽象到更高的层次上了。 Heidi Share 给我的BLOG：Define the problem before solving it 这不仅仅是产品经理所需要具备的素质，更是UED所需要具备的素质。Design = Solve Problem ，问题都搞不清，还不如把自己给Solve了呢。其实只有挖准了问题，才能有真正的推进力，不然就真成了大忽悠了。
抽象思维的能力。大家（包括我）总是花了很多时间在讨论具体的界面方案，每当我们豁然开朗的时候，总是抽象了一下，方向做了些调整。我很担心大家陷入界面方案层面的思考太多，以至于没有时间去思考功能逻辑本身的合理性。所以陷入细节的争论之前，先抽象一下，讨论一下问题的本质，也许更高效一些。抽象思维能力在交互设计师的素质里也谈到了，同样适用于前端和视觉，这是深入挖掘问题的前提能力，不然，……

关于分工合作的职责问题，我不想花精力去划定明确的界限了，我们是创业的伙伴，我们是为共同理想和目标奋斗的人，而不是只关心份内工作的打工仔。希望，不仅仅是希望了，我们UED也一定会成为一支结果导向，使命必达的团队。

设计师不要参与开发工作

行云流水泵 — 2009-03-19 09:21:11

千鸟在《产品设计师－这才是吸引人的工作》中回复说：

“技多不压身，但不是说都得下手做。多懂点的好处，一是增加自己的判断力，防止被忽悠；二是更易跨部门沟通；促进换位思考。
不要试图去拆分职能，我们应该做的是适应，与团队其他同事互补。最好的设计师，是块万能膏药。”

非常同意千鸟的观点，设计师各方面都懂一些，有绝对的好处。但应该保持在了解、沟通的层面，绝对不要设计、开发工作都亲力亲为，这样做是肯定是弊大于利的。

设计、开发一把抓，除了可用性大师们对此一致反对外（为什么不好，大师们已经说了很多），自己也有一些切身体会。

由于工作需要，也会做一些前端开发的工作。以设计、开发的不同角度，看待同一个设计细节时，感受确实不一样。做开发时，难免想在交互细节的实现上偷点儿懒儿。一个看似简单的细节逻辑，确实会让程序逻辑复杂不少。而做为设计师，关注的就是这个交互，对用户是否有用的，如果用户需要，那就必须得有这个逻辑。而且不能因为自己开发就政策放宽，那怎么以后怎么要求其它开发人员？怎么再阐述设计？

再比如，浏览器兼容性问题，自己开发时，难免会产生“差不多就可以了”、“这本就是浏览器的问题”等的想法。但在审查前端开发人员的产出物时，发现在一些浏览器上的表现不理想，就会想“这问题都解决不了，切”。

设计与开发真不能同时进行，人的惰性是天生的，有条件的话，就会情不自禁地偷懒，有钢铁般意志力的人，毕竟是少数。技术人员不能像儒家思想家那么浪漫、想当然。

此外，就是牵扯精力，无论是设计，还是开发，都是一个需要深入、细致的过程。想都做好，必须投入大量精力，否则就都做不好。就像反对管理者介入设计、开发工作一样，设计与开发两方面都兼顾，也是很难的。

同时，还有一个效率问题。俗话说，拳不离手，曲不离口。设计、开发工作不能同时进行，势必要搁置其中一项，时间久了难免业务生疏，效率自然大打折扣，看来这确实不是理想的工作方式，对自身的发展也不利。

虽然说，自己设计自己实现，看起来是一件很惬意的事情。但真要兼顾并做好这两项工作，时间长了说不定会精神分裂，哈哈。

关于团队建设以及网站建设的琐事

摄氏度 — 2009-03-04 10:46:59

互联网是一个飞速发展的行业，任何的止步不前都会导致被淘汰，只是时间早晚的问题，所以一个公司的学习与创新能力是非常重要的，特别是对于一个年轻的创业型公司来讲，学习与创新能力是其得以成长的必备要素。对于新知识的求知欲以及创业的激情朝气也是支撑新公司快速成长的必须的要素。

2003年成立的淘宝到2008年就占据了国内网上交易市场的半壁江山以上，除了淘宝切入网上交易市场的时间占得先机外，还在于淘宝团队的努力。淘宝的UED（用户体验设计）团队是国内最好的UED团队，甚至可以说是国内最好的团队之一。所以有太多的人都梦想着进入到淘宝UED团队去工作，不是因为淘宝的名气，也不是因为淘宝的薪资福利，而是因为淘宝UED团队的工作氛围。据我所了解的几个认识的淘宝UED的成员，从他们身上都能感觉到工作时的那种快乐，更为重要的是对于新知识的求知欲。只有这样的工作氛围才能让员工更好的成长，而公司也能更好的成长。

腾讯可以说是国内互联网上最为成功的一个公司，他的成功只因为他有一个核心产品——QQ，依托于QQ所产生的用户黏性，腾讯一步一步的发展成为国内最大最成功的互联网公司之一。而QQ在诞生的初始，并没有这么多这么完善的功能，QQ仅仅只是仿着国外的ICQ做的一个简单的网络聊天工具，没有什么QQ秀、QQ群，甚至连离线消息都是后来才有的。但就是这么一个简陋的网络聊天工具，发展到现在却掌控着国内几乎80%的即时通讯软件市场。

毫无疑问QQ是一个成功的产品。

而任何一个网站也都可以称为一个产品。而任何一个产品都会有一个诞生期，然后存在一个成长期，再然后是稳定期，直至最终该产品下线。这个产品的周期也许会很长，也许也很短，但这之间的阶段性是不会因为时间的长短而消失的。在这些阶段中，产品的诞生期是最为困难的时期，因为很多人都会在产品刚诞生的初期就想要该产品拥有多少多少功能，却不顾及这些功能对于产品开发周期所产生的影响，而更为严重的是因为这些功能的加入而导致产品系统的不稳定。

互联网是个高速发展的行业，几乎所有产品的周期都不会很长，所以就存在迭代开发的概念。先是保证产品的核心功能稳定，快速发布后占据市场的先机，同时也能够得到产品的第一批用户，第一批用户可以算是产品的初级用户。再接着进行第二次开发，在二次开发的过程中，这批初级用户会在使用产品的过程中慢慢晋升到中级用户时，而在这个过程中也会出现很多的问题，于是开发人员可以在收到这些反馈问题之后在第二版中改进。然后是升级版的发布……这就是一个迭代的过程。

但如果该产品在开发初期就除了核心功能外附带诸多的额外功能的话，除去这些额外功能所带来的系统不稳定的风险外，更为重要的是会耽误产品的发布周期，最终导致整个产品周期都被拖延，而产品周期的拖延很可能会导致产品的失败。

而网站是一个比较特殊的产品，产品周期可以很长很长，当然也可能是很短的。虽然说与其他产品相比，网站的产品周期可以不用太过担心，但并不因此就说明网站的开发周期可以很长，迭代开发同样适用于网站。而更为重要的是在开发的过程中要明确网站的核心，什么功能都想做，最终导致的是什么功能都做不好。

产品设计中，做加法并不困难，甚至可以说是很简单的事，随随变变都可以拼凑出很多功能，真正困难的是如何去做减法。而如果需要后期去做减法，那为何不一开始就精简化呢？

做网站就会涉及到改版，这是一个网站必须的经历。但网站改版一般只在两种情况下才会发生：一是因为网站本身的内容扩充导致现在的网站架构承载不下更多的内容，二是基于网站用户需求的转变而导致网站转型。

但不管哪一种才是导致网站改版的真正原因，数据支持是网站改版中所必须的，没有任何的数据支持完全就是在为自己改版，而不是为用户改版。用户才是网站得以生存发展的根本，一个网站面向的永远是他的用户，而不是其他的群体。

网站改版中需要的数据有很多种，而用户使用网站的操作流程是最基本的，如果能做用户调研当然最好的，如果做不了用户调研，那最起码也要有详细的用户浏览网站的点击行为。这是保证网站改版能朝着正确的方向前进的最基本的保障。

资讯网站是完完全全是以内容为王的网站类型，内容是一个资讯网站的根本立足所在，而且在整个网站中保证原创内容能占绝大部分比例，转载只是一种折中的行为，而使用采集程序去采信别人网站的内容则完全是一种个人网站的行为，很多的个人站长都会使用采集程序去采集别人网站的内容来制作垃圾站，为的仅仅只是多赚点广告费，而由此却产生了大量的版权问题以及互联网上信息的重复性。

做为一个网站来说，资讯可以是核心，但并不代表是所有，一个综合性的平台才能有更好的发展。资讯+平台的模式无疑可以让网站拥有更广泛的用户群体，而关健在于如何去搭建这个平台。

任何一个网站，都必须有其具备吸引力的功能应用才能招揽到用户，如果仅仅是看看资讯，没有人会因此去注册成为一个网站的用户。即使是注册成了用户，如何将这些初级用户转换成中级用户甚至是高级用户，这就必须要求网站有核心应用所在，这样才能让用户产生黏性。而如果仅仅是依靠一些小插件来实现WebGame式的应用，是不可能让用户产生长久的黏性。

开心网依靠“抢车位”、“买卖奴隶”等WebGame的方式，飞速成长为国内所谓的SNS社区网站领头羊，能与校内网相抗衡，但不可否认的是用户的疲劳度是会与日俱增的，由于缺乏真正的核心应用，开心网正面临着用户的大量流失。

互联网是个神奇的地方，每个人都可以实现他的梦想！

————————————-分割线————————————–

这是一封写给上司看的长信，做了一点删节处理。

我并不是一个擅长和上司打交道的人，所以大部分的开会时间我都沉默着，不是没有观点可以表达，而是有太多的情况都让我不愿去表达，所以我选择一个旁观者的身份去观看。我从来都不怀疑自己的忍耐力，所以我会一忍再忍，然后还是忍，直到最后终于再忍无可忍了：

长期的内部数据报告做假、光说不做只会推卸责任，视网站改版如儿戏般简单、随意拼凑栏目内容，硬性指派下载模板素材做为任务，创业初期的公司却植入了机关结构的慵懒闲散之风，甚至将网站理解为是做给领导看的！……

这一切都让我无法再忍受下去，这不是我所想要做的互联网，这更不可能成就我的事业，甚至是背道而驰，梦想之翼在这里被折翅！思考再三，最终决定给上司写一封长信，我不知道这封信会产生什么样的结果，但起码在这一刻我做了我想做也应该做的事情。

相关话题：产品设计团队协作源地址：http://www.prower.cn/interaction/1202

项目反思

CC — 2009-03-08 03:49:23

这两个礼拜做了个项目，不得不承认有点失败。虽然本身的需求不确定性，导致小组人员非常被动，一定需要和客户反复确认，而客户往往又会由于这一版的设计而产生新的设计要求，最让我被动的是，本身的设计是平面设计，小组成员中没一个是平面设计出生的设计师却被要求这个项目的平面设计要求最高。让我非常地无奈。但是我想我最大的问题就是对这个项目本身的不满情绪，导致我消极应对了整个项目上进度上的管理。

不过还好，人们总是从失败的项目中可以总结到教训的。这个项目让我确实学到了不少东西。

切忌需求模糊的情况下开始工作。千万别听信什么“你们先做，稍后我来修改”。
切忌在短期项目中尝试新的技术。千万别把新技术带到为期只有一周的项目中去做，哪怕效果再炫，没有完成，就是没有完成。
切忌带着不满情绪去处理项目。项目的失败只能说明作为管理者的失职，负面情绪显然不会带有什么好处。
切忌用对的人去做错的事。空闲的时候，可以让一个不擅长平面设计的人来做练习，可是当要求很高的时候，别指望交互设计出生的人做出让平面设计出生的人满意的设计作品来。
在项目延期的情况下，必须尊重客观实事，不能带个人愿景去处理事情。
作为一个管理者，必须公平公正，否则极易出现企业“反淘汰”情形。即由于员工与企业组织的价值观发生冲突，会造成诚实的员工求去，不诚实的员工反而留下。

我们为什么会失败

mooqii — 2009-03-09 03:43:22

是人的问题吗？
恩，有点关系，我们每个人都有优点也有不足，但之不至于做得这么差。

是钱的问题吗？
至少在开发阶段，我们从来都不用考虑钱的问题。

问题出在哪里？

1.一开始的时候，我们觉得我们的产品设计思想是非常领先的，在我们眼里，别人似乎很傻。所以我们信心百倍，赶超XX不成问题，赶超XX也有可能。前途似乎很美好。
（互联网不像传统行业，思想的更新非常快。现在尽人皆知的思想在一年前可能就非常领先。但同时，业界之间的交流很频繁，抄袭也十分普遍，如果没有领先的人才做支撑，某个思想的领先只是一个短期状态。仅凭一个自以为领先的思想就把心理预期定这么高，未免幼稚。一段时间之后，我们发现竞争对手更新了他们的产品，和我们的理念越来越接近，我们开始时的自以为是被紧张情绪替代。你的思想领先了别人的产品没错，只是别人的思想领先了你的思想。后来我觉得，产品没有用户前是没有太多思想的。）

2.在项目过程中，产品经理在不断成熟，对产品的理解也越来越深入，于是觉得之前设计的产品越看越糟糕，甚至想要推倒重来。
（产品经理的个人能力是一方面原因，另一方面，互联网产品日新月异，即使是一个成熟的产品经理也会在产品设计过程中会看到同行优秀的设计而希望把这些设计都融入到自己的产品中来。我们觉得自己比不过别人的原因是因为产品没别人好，功能没别人强。如果我们的产品比别人的产品功能更丰富，用户体验更好，就应该能战胜他们。后来我觉得，描述一个产品不是告诉别人你的产品能提供什么给用户，而是用户在你的产品里正在做什么。）

3.开发周期为什么这么长！
（不默契的开发团队，不优秀的产品设计团队，不坚定的管理层。）

4.为什么我们一次一次的失望？
（我们对简单的事情[花钱]很有执行力可缺少计划性，而对困难的事情[赚钱]计划里排了一个又一个美好的假设却从来不去执行。）

我的伙伴，谢谢你们对我的信任，虽然我从来不曾成功。能和你们合作，我很开心，希望我们风雨同行，荣辱与共。

什么排在任务队列的最上面

西乔 — 2009-02-13 03:20:37

推荐一篇文章《经济学家如何排队》，还有一篇《从经济学里的排队问题看效率与公平的矛盾》。

我随便说两句，如何给工作任务队列排序。

任务队列有几个排序原则：1 优先级、2 重要性、3 利润、4 稳定、5 取悦客户（老板）、6……

依照不同的排序原则会产生不同的排序结果。

在处理不同类型事务和担任不同角色时需要参考不同的排序原则。

比如bug任务列表，依据应该是重要性。
比如任务分工排序，依据应该是优先级。
比如整体改版计划，依据应该是稳定和利润。
如果你是那某几个倒霉的部门经理，依据中别忘了取悦客户（老板）（用户）（投资人）列表无限中……

项目工程中，很多人搞不清优先级和重要性这两个衡量指标的区别。所以任务列表中这两列经常被混用。其实这不是由于他不够专业造成的，而是取决于他的立场，他是项目经理还是系统架构师，他是干开发的还是干测试的，他是IT部门还是市场部门。

转一个分级指标的范例：

以处理问题的优先等级来分类

优先级 (Priority)	预计完成时间预设值 (Estimated Finish Date)	应变措施 (Resolution)
1	即日完成	立即修改完成 (Fix immediately)
2	三个工作天内	下一个阶段结束前必须修改完成 (Fix before next stage)
3	七个工作天内	产品推出前必须修改完成 (Fix before release)
4	十四个工作天内	如果时间允许才进行修改 (Fix if available)
5	本月内	在下一个版本再修改 (Fix in next version)

以问题的严重性来分类

严重性 (Severity)	指标描述 (Guidelines)	范例 (Examples)
高 (High)	缺少主要功能，或者主要功能毫无作用所产生的问题会导致系统停顿所产生的问题导致无法进行下一步测试	GPF (General Protection Fault)、Crash、当机 (System Hang)需要重新启动来解决的问题
中 (Medium)	主要功能运作不完整所产生的问题会导致系统部份功能不正常所产生的问题宿因严重但不影响下一步测试	Access Violation、Exceptions问题多数出于所有测试路径中的其中一个
低 (Low)	功能运作正常，但会有一些不一致的情况产生所产生的问题不会导致系统任何问题所产生的问题不会影响下一步测试	使用的介面或者接口不一致或者不正确
微 (Minor)	功能运作正常，可是有改进的空间所产生的问题不会导致系统任何问题所产生的问题不影响下一步测试	并未完全符合使用者习惯或者方便使用者

由这两张表格可见，优先级是在描述时间，影响的是进度，而严重性 (Severity) 是在描述质量，影响的是稳定和架构。

我贴出这两张表的原因是我要说的原则1：别想排出一个面面俱到所有人都满意的任务序列。排序列的时候牢记你的职位、分工和立场。

下面的问题就由于是我的原则，涉及我的角色和立场——外包技术服务项目的项目经理。

原则2 会对他人造成影响的排在最前面。 造成影响包括：

会产生报怨的任务。有些角色的报怨会产生严重的负面影响和压力。为团队和长远着想，优先把报怨解决在说出来之前，及时无法及时解决，展现一个姿态。
前置任务。如果某个任务的完成成为其它任务开展的前提条件，提前干完它。（项目经理的主要前置任务基本是是。。写邮件）

原则3 把容易看到成效的任务优先级提前。 包括：

快要完成的任务——“这座楼改完啦”的成就感乘10倍远远大于 “这个10座楼的小区改完啦”
同类未开展类任务中容易完成的——所以项目在进入密集开发的几个月后，技术人员会进入一个“干疲了”的状态，表现为开发效率下降，bug率提高，对优化和全局考虑的积极性下降。原因之一来自技术人员乐观天性导致的挫败感：需要干的事的数量、难度、复杂程序永远远远超出最初的想象。所以，优先开展容易完成的任务。
能实现收益回报的——优先搞点收益回报会令你在以后调配资源更得心应手。

原则4：见这篇专业文章。《CARVER-教你进行项目的优先级处理》

技术团队需要专家

行云流水泵 — 2009-03-10 03:35:19

读了《UX梦之队：专家，多面手，职业工作者》、《产品设计师－这才是吸引人的工作》这两篇文章后，想到的：

一、就所经历过的国内IT团队的现状来看，专家不多，真正的多面手就更少见。个人固执地认为，真正的多面手，应该是多个领域的专家，而不是仅仅有所涉猎的半桶水。如果不是每个领域都能独当一面，只是有所涉猎，甚至仅仅有耳闻，那不是真正的多面手。所以，一直感觉“复合型人才”，是个不靠谱儿的说法，因为起点太高，更不易做到。

以IT行业为例，任何一个技术方向都是一个无止境的领域，都是一个宽而深的空间，很少有人有资格说，对于某个领域已经完全熟知、可以轻松驾驭了。往往是了解得越多，就越能发现自己所不了解的更多，所以高手多半低调，谦虚是因为知道自己所知有限，往往整天虚张声势的半桶水，是无知导致的。正所谓，无知者无畏。

IT是一个迅猛发展的行业，所涵盖的技术领域也都是瞬息万变的。对于从业者而言，如果想让自己在所从事的领域永远技高一筹，立于不败之地，那就只有四个字—学无止境。

由此可见，成为多面手的难度，是高于成为单一领域专家的。因此，就团队建设来看，多面手不应该是退而求其次的方向，而应该是一个进阶要求。

二、做为产品设计师，先后与两个开发小组合作过。其中一个只有一位成员，有8年的开发经验，为人很低调，也很专注，只将精力投入在单一的开发技术上；另一个由两位年轻的程序员组成，工作经验都不超过2年，但号称“一专多能”，可以玩转所有开发技术，如果时间允许SEO与推广也可以做。

合作下来的感受是，配合第二个开发组工作很累，设计方案往往要做大量让步，还要参与一部分前端开发的工作。就这样，项目还一再延期。好不容易完工了，每次测试都BUG一堆，还有浏览器兼容问题，DEBUG的时间比开发周期还长。问其原因，却强调是因为设计方案总在变的，导致程序结构不严谨，，要求再给些时间，重新开发一次。

而与资深程序员的合作，可以说是非常的顺利，提前完成开发任务，同时没测出什么大的BUG，对于设计上的要求，都可以完美的解决。

当然，这里面有一部分人的因素，但更多的应该是技术定位的问题。

多面手任何团队都欢迎，但这样的人才是可遇不可求的。而且能真正做到“样样精通”的没有几个，多数是“样样稀松”。

忘了是谁说的，把10项技能各掌握10%的所谓“复合型人才”，其对团队的贡献，远远不如把一项技术掌握到90%的领域专家。

三、您所在的团队，是否出现过如下的争论？

“这个交互逻辑实现不了？是因为水平不够吧？浏览器兼容问题是有难度，但也不是解决不了。就这水平还前端工程师呢？JS、AS还不如我这个交互设计师熟呢。”

“别提您设计的交互逻辑，本身逻辑上就有问题，评审会上很少能通过。对用户操作流程还不如我熟悉，您这个交互设计师，我实在不敢苟同。”

“PV不够、转化率低，是因为产品经理的方案有问题，他的水平大家最清楚，刚刚毕业没两年，对互联网的了解能有多少，对产品、市场、用户需求的把握能力可想而知。”

“产品定位肯定没有问题，国外很多牛站也都是这么做的，用户不买账，是因为前端、后台的技术能力限制让产品大打折扣，而交互、GUI设计没也有完全按我最初的思路走。”

当然，这些也许仅仅是团队成员的心理活动，也许不会面对面的指出来。但，即使仅仅是心理活动，也说明了问题已经存在。

当团队成员不是领域专家，或者其从事领域水平不是团队中最高的时，沟通很可能会变成效率低下的扯皮。因为你不够权威，你就得不到其它成员的信任，那沟通、合作都无从谈起。

四、团队成员间除了沟通、协作外，互相之间的影响、学习也是必不可少的。如果团队中每种角色都有一个专家级的高手，那对于团队的成长肯定会有积极作用的。即使一些成员的实力稍差一些，也会有一个正确的学习方向。

如果团队成员，都是自称多面手的半桶水，那情况就可想而知了。

曾经接触过一个这样的团队，大家水平都不高，所有的项目都是在摸索，因为没有一个高手的指引，因此大家进步的速度并不明显。

一个新来的测试人员提出要离开，问其原因，是因为在这样的团队不能学习与提高。

而且IT行业的团队，技术实力是重要的，它决定其产品是否有市场价值，设计、技术差的产品，直接导致用户体验不高，用户是不会买账的。

上面这样的团队是没办法立足的，在企业中也不会树立专业、技术权威、不可替代的形象，可能找不到正确的发展方向，没有核心竞争力，除非大量引进专家级高手。不然，设计评审会都没有办法开，多半会变成不存在信任的争论。

所以，对于团队来说，更为重要的是要找到领域专家，只有专家对于团队的发展才是有积极作用的。当然，如果能找到多面手更好，但一定要识别真伪。

对于每个从业者来说，重要的是先把自己定位好，然后以90%以上的精力关注自己的专业领域。其它的领域，可以了解一些，就像千鸟说的，以备沟通之需。

当然，能成为多面手固然好，但要量力而行。成为一个领域内的高手后，您再考虑多面发展，不然您的时间、精力是不够用的。

一家之言，谨供拍砖。

用户体验部门建设

idliulei — 2009-03-03 13:23:28

Jacob Nielsen 将一个公司的可用性成熟度划分为8个阶段：
1. 敌视用户体验
2. 开发者为中心的设计
3. 零星的可用性
4. 可用性投资
5. 可用性部门建立
6. 系统的可用性流程
7. 整合的UCD
8. 用户驱动的公司

他还做了补充，第1阶段出不来的话，可能会痛苦几十年。2-4阶段每个阶段要2-3年，5-7的阶段每个阶段要6-7年。也就是说2-7阶段要20年，而7-8阶段还要另外一个20年。非百年公司不能做啊。

也许，Jacob的意思是你到一个阶段要20年，不如外包给我的公司吧...

如果按照中国1年，外国7年这种相对发展速度来说的话，2-7阶段需要3年，7-8需要另3年，看起来比较靠谱。如果有一个有经验的UX leader的话，还可以从4或5阶段直接发展。那也至少5年吧。

老实说，近2年用户体验的声音有些弱了，真正建立起用户体验部门的公司并不多，用户体验大牛则看到的更少。而一些喜欢buzzword的人把用户体验，交互设计，UI设计，产品设计，UCD，可用性以及用户研究这些概念纠缠在一起，却不能真正了解用户需求并在产品中创新。
三分钟热度，做的了一时“体验”，做不了长久的设计啊。

所以，今年用户体验部门建设的目标：
－在重要项目开始前，进行用户研究；
－界面规范和设计范式的定义；
－跟踪并分析用户体验的质和量；
－进行迭代设计。

产品方面，还是深入关注产品，建立用户和产品设计人员间通畅的沟通渠道。
创新方面，把洞留着，做一些尝试，期待各种可能性。

走踏实一点，路还长着呢