人人都是产品经理

今天说一下项目Kick Off会议（简称KO）的作用，会有人觉得这很形式化，但我认为很重要，其实KO只需要15min左右的时间，我会安排在需求评审（参加人与KO基本重合）之前，成本很低。在这15min内，需要传达的信息有如下几点。 Ø         项目的背景与意义说过去，做项目之前的情况，为什么要做这个项目（以让听众痛心疾首为终极目标）。 Ø         项目的目的

前段在一位同行的blog上看到一些对PD工作的描述，感觉用来做招聘的广告词挺好的，摘录下来了，再加工一下，做个“官方说法”与“私下交流”（plus实事真相）的对比版本。 官：PD需要全面负责产品的各个方面。私：因为PD这个职位比较新，具体要做哪些事情没有开发、测试清楚，所以你干多干少自己决定（职责不清楚，就是事情多起来没个谱……）。 官：此职位较难量化考核，综合素质要求高。

几个月来不断的整理适合我们团队的各种文档，是一个非常轻量级的文档包，这次对着理好的mindmanager图讲，分五类： Ø         需求管理类n         功能列表极其管理方法，这里可以体会到团队协同工具的重要，现在我们用的是office live的excel，比较简单。n         产品的网站页面地图。 Ø         项目管理类n    

提前50天左右完成“一周一篇，持续一年”的小目标，继续往下走下一站99篇~~~==========================================================在很多外人眼中，需求人员整天就是在写文档，那干脆整点文档的心得吧。话题超大，网上也有很多文章，我只说几点自己平时很注意的。 Word：在做结构稍微复杂点的文档时采用，简单的几段话一般用记

前段读了《敏捷估计与规划》，这本书很适合开发经理看，我只是很快的浏览了一下，摘录一些体会。 Ø         敏捷的里程碑是功能驱动的，先完成可交付的最“重要”功能，重要取决于功能商业价值、生命周期、实现难度等综合的结果。而传统的瀑布模型的里程碑是任务阶段驱动的，到了项目50%的时间，可能进入“编码”，但对客户来说，等于0%。而且这样的模式会陷入“实现难度决定开发顺序”的不合理模式，因为

先默哀3分钟~~~ 今天国内各大网站，第一次出现了黑白版面，很震撼~~~今天下午的那3分钟，我在9楼看着窗外的马路，人、车全停，喇叭齐鸣，更震撼~~~====================== 分割线，正文开始 ======================== 事物发展到一定阶段，必然需要借助外力来帮助发展，好比Matrix借助Neo，改革开放中政府借助民营经济体，民企知道

过年那段时间，抽空看掉了《产品经理实战手册》，金山的王欣、夏济写的，很实用的操作读物，看起来比较轻松，记录一下自己的体会。另推荐《产品经理的第一本书》和《第二本书》（前两天5块淘到，哈哈），更详细，看起来也累一点，只是浏览过。 看完之后对产品经理有了更全面的理解，正如Product Manager是从宝洁的品牌经理发展而来的一样，还有很多工作是PD平时接触不多的，因为公司里有专门的运营

产品团队刚刚经历了一场公司内部的战争，争夺的是下个月的开发工程师与测试工程师的资源。 先说一下为什么以前没有过这样的战争吧，因为公司原来是按照产品线划分的部门，这样对于某个产品来说，有自己的PD、开发与测试等，下个月要做哪些需求，完全可以在产品经理的层面上决定；而现在公司变成了按职能划分团队，有了统一的产品运营中心（PD和运营）、研发中心（所有开发工程师）、质控中心（所有测试工程师），这样

接上回，下层的图描述的是一个用例内部的事务（用例内部不一定是“单个用例”内部，也可能有用例之间的关系），主要有： Ø         时序图（顺序图）：描述事情变化在时间维度上的先后顺序，善于表达对象（比如多个页面之间）的交互。玩的好可以完全替代UC中对流程的文字表述。              Ø         活动图（比较接近传统意义上的流程图）：描述各种动作如何引起系统

人治à法治à无为而治，大公司多为第二种：法治，1和3很像，外表经常看不出来。管理最高境界就是做到无为而治，这是产品和团队的发展必经阶段，我们的现状就是“1à2”，开始规范化，正好有同学原来熟悉UML，所以大家也都开始学习一下。 UML就是统一建模语言，它试图将软件工程的过程给规范化，从产品设计的角度，我对它的简单理解就是用一系列的标准图把需求分析的过程串起来，充分体现了“字不如表，表不

技术人员的全面介入，可以简单的看作以“需求分析初稿完成”为界，需求完成以后，派生出几个设计：交互设计、编码设计、数据库设计、测试设计，各自设计完成并执行以后，再部署发布。 具体的说一下，交互设计这块，主要是做软件和用户交互的工作，分工有从最直接的视觉设计师到使用感受上的用户体验师（交互设计师）再到偏代码实现的前端工程师。 编码设计，比较偏概要设计的有软件架构师（比如整个系统的表

前几个月尝试做了PM（这次是Project不是Product了），亲身经历了一个项目是怎样一步步不顺下去的。先说明一点：这里的“敏捷”是指甲乙双方配合的“敏捷”，而不是说外包项目本身内部不合适“敏捷”。 先说一下背景，项目时间太紧，工期是由商业谈判决定的，没有及时评估工作量，做着做着产生delay，先试图简单的用加班的方法赶上进度，后来被迫注入“敏捷”项目方法，但事后发现“项目外包”模

我的感觉，评审就是项目相关的几个小团队的人坐在一起，一方讲，另外几方听并确认，统一认识，消除误解，防止偏差没有及时发现而随时间放大。这个过程不做，往往问题到很后才暴露，然后是谁的责任纠缠不清，与其亡羊补牢不如之前就在流程上预防，防病优于治病。 项目过程中，比较大的三方面是PD、开发、测试，所以派生出三次评审，按照项目阶段依次为： Ø         需求评审，俗称UC评审，在需

每隔一段时间都有些难以成篇的零散体会出来，这样也不错，更随意一点，有blog之后又出来twitter了嘛，一个道理。 Ø         产品与设计师是互相依存的，在高层决定公司战略的前提下，很多时候，好的产品对设计师的帮助会远远大于好的设计师对产品的帮助。 Ø         PD、开发、测试的人员比例，对于web应用，我的感觉1：3：1是比较合理的，开发不足会产生一种有枪没

挺好玩的一个话题，很多产品设计出来，结果用户很喜欢，用的很遛，但和设计师的初衷千差万别，简直让人吐血，闲聊一把。 例1：msn的“签名+显示为脱机+联机”组合拳。具体说就是写一句话做msn的签名，然后不停的上线、显示为脱机、上线……，让好友们不断的看到。常见用法1：剧透。比如我刚看完《色戒》，然后就写一句：王佳芝最后死了……再不停的上啊下啊的，是不是很恶毒？常见用法2：表白

做付费产品，就必然要牵涉到卖的问题，最近公司正好“e网打进”火爆销售ing，plus前段时间浏览过《渠道为王》，就说说相关的体会。 销售有两大模式：直销vs分销，分销要通过渠道，渠道又分代理（赚佣金，没有产品所有权和库存风险）和经销（赚差价，产品所有权发生转移，比如批发商），现在的网络付费产品，因为多是个人应用，所以直销比较多，而我们的“e”是给企业用户的，加之国内中小企业现在相应的知

上个周末接受了CSDN的专访plus博文视点的闲聊，发现说的东西都差不多，自己整个精编版如下，完整版猛击此处。  记者：2007年7月，您开始在自己的 MSNSpace 上面写“产品设计体会”这个系列文章的，最初您开始写这个系列目的是什么呢？在这之后，又是哪些原因一直让您保持住了持续更新的热情呢？答：就像我在第一篇里提到的一样，一开始只是个很朴素的原因：那段时间老板要求我们产品设计

项目外包和开发外包的模式有明显区别，手头经历了一个概念不清的项目，结果一路坎坷，体会如下。 合作模式、分工一定要在开始的时候明确。这次的项目外包，乙方又把开发外包，谁对谁负责，什么事情谁做一直没有明确界定。乙方会本能的倾向于开发外包，导致甲方投入越来越多，产生障碍。 既然项目外包了，项目管理方法应该乙方定。当时间紧的时候，乙方或投入资源或和甲方重新商业谈判来解决，甲方强行改变项目管

可用性测试也是用户研究/需求采集的一个常用方法，从理念上讲就是：让产品的最终使用者尽可能多的参与到产品设计各个环节中去，深入一点就很2.0了——“用户创造内容”（这也不是什么新概念，传统行业的宜家IKEA好像早在50年前就有所行动，让用户参与到产品的设计），把用户参与扩展开，还可以包括前期调研、demo评审等等。 可用性测试的效果往往无法量化，所以经常因为项目时间过紧被略过，好不容易前

   最近项目做的对敏捷有点兴趣，花了两个晚上浏览了《敏捷迭代开发——管理者指南》，理念式的书，看起来比较轻松，摘录一些自己的体会。 有些需求在开始的时候是提不出来的，或者说没法细化的，强行的过渡需求分析是浪费时间的行为，到后来多半还是要改。瀑布（其实Royce大大提出的瀑布模型初衷里也是有迭代思想的，不过被后人误读了）的问题是最后集中暴露矛盾，当然对需求固定的项目还是

突然想起QA的一个职业口头禅：你这样做是不对的……当PD们激情四溢的乱冲乱撞时，有个严酷的QA/测试控制着，确实太有必要了，虽然经常吵架，：） 先分清两个概念，原来一直很土的以为QA和测试是一个概念，其实QA是质量控制，主要做流程管理（如需求跟踪流程、需求变更流程）、配置管理（版本管理，多分支开发的管理）、文档管理（如开发规范、UI规范）等东西，经典的CMM成熟度啥的说的就是这回事，不

我们的产品，很大的一个用户群就是土老板，既然如此，我们也要突出一个“土”字！在一篇博文里看到过一个兄弟说过一段话，感觉太tmd的对了，意译如下：“在中国ebay为什么搞不下去？那帮拿着macbook坐在starbucks喝cappuccino的外企小资们怎么会比淘宝那帮土人（绝对是褒义啊~~~）更懂那些对着17寸CRT窝在脏乱差的家plus仓库里喝着西湖龙井的用户！”要知道你生存在什么地方，5

用户大会是一种常用的需求采集方法，可以短时间内从多人处收集大量信息。回忆一下去年夏天组织过的一次阿里软件网店版用户交流会，这种会耗费资源较多，一般机会不多，所以要充分利用。会议虽小但需要注意的东西都一样，按时间上分几步重点摘录如下： 会前最重要的是明确这次用户大会的目的和意义，这在争取资源的时候会更有说服力，比如：产品二期卖点确认，辅助运营决策；三期需求收集（用户怎么说）；现有产品用户

年后第一篇，先happy V day，贴上几个月来零散没法单独成篇的体会。 Ø         产 品里的问题，开始有一两个的时候总让人吃不下睡不着，非要马上干掉，后来就无视了，好比白头发，有一根的时候会马上拔掉，多了起来会很郁闷一阵子，再多也 就烦不了，该干嘛干嘛了。但过了一段时间，想想也不能这样一直消极啊，所以就会从根本上考虑去解决问题，是去养生而不是拔头发了。 Ø  

题目有点绕口令啊，：）春节快到，体会从2007年7月写起到现在也超过了30篇，小结一下，顺道练习一下平时经常用的mindmanager。在需求采集完成以后，一堆PD就会窝在一起头脑风暴（俗称yy），只重数量不重质量的想出尽可能多的点，不要反驳，不要讨论可行性，尽管乱想，最后再统一的略作整理，就得到了一张思维导图。借用这个方法，一方面给已写的体会理出个框架，看看一个作为PD到底需要哪些基

其实这篇是《用户体验的要素》的读后感，其实读了已经快2个月了，刚读完写读后感会比较全面，而事隔一段时间再写就能看出哪些是真正沉淀下来的要点了，也算是给自己找个偷懒的理由吧。大产品设计决定用户体验，而小产品设计又分为五层，帖一张业内著名了好几年的图。战略层：明确商业目标和用户目标，重点是解决两者之间的冲突，找到平衡点。例如，通常的商业目标是赚钱，而用户是要省钱，这种最底层的冲突没

这 次来谈一下很细节的内容——文案，这里不是指网站里大段文字的编辑工作，而是指产品中随处可见的文字。自己的体会：因为文案问题很隐蔽，所以在各个产品中 都普遍存在，虽说不会对产品功能造成太大的伤害，但是过多的文案问题会使得产品整体感觉降一个档次。个人把文案问题分为三个级别。 低级阶段：错别字，病句，错误标点。比如常见的错别字：登录、登陆；语句逻辑关系混乱；中文与英文的标点混合不分等等。 

“大产品设计”的概念在脑中已经出现好几个月了，一个产品最终的商业化，其用户体验，所有的影响因素似乎都可以归结到“大产品设计”上去，具体点说，是商业、产品、技术三个方面。 商业，在公司里主要表现为领导层、运营、市场、销售部门，他们决定的是产品的市场定位，价格与促销策略等。产品，即通常意义上的“产品设计”部门，为产品、用户体验部门等，他们决定了产品的功能范围、交互流程、视觉表现等。技术

老板说过一句话让我印象深刻：其实Product Designer就是Sales。而且比Sales还要难，Sales卖的是已经有的东西，而PD卖的是自己的想法；Sales只要把产品卖给客户，而PD要把想法卖给老板、同事、客户等等。 PD第一卖——老板：项目多得是，凭什么给你资源？PD表决心：我这个对公司有利，对集团有利，对建设和谐社会有利，花钱少见效快，做了以后腰不酸背不痛腿不抽

让我们先回到2002年1月15日，交互设计之父Alan Cooper和极限编程创始人Kent Beck在pk，话题是“当交互设计遇到敏捷开发”。就像小说里两大高手对决一样，双方大战三百回合还是没有分出胜负，终归握手言和（或者小气的赌气分手，呵呵），引用一些对那场战斗的评论：Ø         Cooper大师认为子弹很贵，因此在每次开枪之前一定要精确地瞄准。负责瞄准的人应该是专业的交互设计师。

最近在读《赢在用户》，表现层是在讲人物角色（Personas）的创建和应用，实际是在讨论用户研究的话题。用各种用户研究的方法创建Personas，然后加以应用，目的是在设计产品的过程中时刻不忘用户，做到以用户为中心。大概的看下来，就会发现“用户研究”、“市场研究”、“需求采集”，有很多方法重合，他们都是为产品设计服务的。书中将用户研究的方法从两个维度分类，感觉很不错。 定

又给封闭了好几周了，和外包的微软项目团队在一起。算起来到公司有超过一半的时间出于项目封闭状态，也算幸运吧，因为封闭的项目通常是比较重要和神秘的（好吧，或者是因为办公区域没地方坐了，=,=bbb）。《人件》里很强调办公环境对人的影响，不过那是对正轨成熟的大公司而言的，从我们经常搞封闭就可以看出，确实还是一家创业型的小公司。 封 闭的好处比较明显，大家都挤在一间房里，围着一张会议桌办公

最近很多网站在改版，如yobo、豆瓣，说说自己对改版的体会。改版这件事的初衷都是为了产品升级，更好的服务用户，一成不变的产品必然是死了的产品，所以改版是必须的。但改版在客观上造成对用户现有习惯的挑战，所以做这件事情的时候必须慎之又慎，用一些方法和技巧。网店版1.0到2.0的升级，在页面风格上有极大的改变，几乎完全凭设计师们的喜好进行改变，直到上线前几天，才叫了几个用户来做可用性测试，而这时候其

周末去北京参加UPA年会了，周五深夜才到北京，周日晚就回了，虽然时间不多，不过收获不少，写点作业。这次会议全称是“2007（第二届）中国青年设计节暨DDF.UPA中国User Friendly 2007国际年会”，大会主题为Connecting User Experience Communities, 旨在首次将大中华地区用户体验行业的各个组成部分(包括研究,设计,测试,市场,策略,教

前几天发现UCDChina上有一个专门的话题来讨论概念设计，并且提到了产出物“概念图”，结合我们的产品周期来看，一开始似乎找不到这个阶段，在结合上周的体会，感觉这个阶段应该是在BRD之中。从思维图和概念图的关系开始扯，思维图更多的是一群PD一起BrainStorm的产物，围绕产品的商业目标，尽量发散出各种可能的功能，并简单的划分为几个模块。思维图在乎的是发散，宁可错杀一千，不能漏一个，至于想到

今天看到一篇讲述产品设计中几种文档的文章（一个老外的blog，Michael on Product Management & Marketing），感觉很好，结合工作的实际整理一下。按照那篇文章的思路，从产品的抽象到具体主要产出的文档有BRD、MRD、PRD和FSD。BRD：Business Requirements Document，商业需求文档。这是产品声明周期中最早的问的文档，再早就应该

这周来点实在的，这两天主要在列新产品的Feature List,说一下自己感觉这个玩意应该怎么做，其中吸取了叶老大原来的表格还有网上一些相关文章的内容。这个表是用Excel做的，一些简单的技巧，比如条件格式、筛选、单元格有效性、单元格锁定、隐藏是必须的基本功，另外我比较喜欢把表格弄好看点，这样整天对着就不会闷死嘞，见附图。  （看不清吧，那就对了，暂时不能让你们看清~~~ :P）

这周从产品部门的角度出发，讲一下我心目中的几大主要任务和相应的职责区别，涉及产品经理、产品设计师、用户体验师、视觉设计师四个角色。一般来说，这个顺序就是一个产品从规划到最终成型的任务流方向，是一个从抽象到具体、商业到技术的过程。PM：产品经理，俗称老大（另一个PM项目经理在我们公司更像是从技术角度出发的职位）。一个产品，首先由PM来分析细分市场、目标客户的诉求，规划产品的卖点、杀手级应用，这个

这周回顾一下一年多来经历的5个项目，成功或失败在不同的阶段。 先简单描述公司软件项目的生命周期，其他项目也应该大致如此：市场扫描，需求分析，开发，测试，上线，运营维护……加深体会了一个基本常识：问题出现的越早，越早调整项目规划，损失越小。 第 一个是在压力测试阶段怎么也过不了，无法发布。我不是技术出身的，所以具体原因也不太清楚，感觉问题应该是出在系统设计上，测试的时候功

前 段时间听到过一个说法，说需求分析与技术分析的最大的不同是思路的本质差异，技术分析是“树干——树枝——树叶”的任务分解过程，技术人员很适应并乐于用 这种方式思考，可以把大问题分解成小问题，发现难点逐一攻克。很多做需求的人都是开发出身的，所以开始往往会用这种思路做需求，听到客户提到的功能点，直 接想怎么做系统设计了，有时候需求分析甚至已经越俎代庖到“详细设计”的职责了。而真实情况是，需