## 产品设计体会（五八）——《项目化管理》培训记录 上周5、6又培训了，《项目化管理》，每周上4天班上2天课还是有点累的，不过培训的收获也不小，整理一下。 整体感觉这个老师还是很不错的，授课技巧很好，在项目管理方面也确实资深（十几年前在李嘉诚一个净利润1k多亿的项目中，就已经是一个子项目的高级PM），课程讲了较多“道”的东西，较少“术”的内容，需要听者有很深厚的功力才能收获更多，自己感觉有不少内容是听得懵懵懂懂，要点记录如下：   1.       课程网站：[www.21pm.com](http://www.21pm.com/)，右上角Eric课程精彩点。   2.       PMBOK的九大知识体系，应按照life circle理解，而不是9个模块分别理解。   3.       ABCDE经典游戏： a)         A+有企业所有权，A是CEO有经营权； b)        A要做正确的事：明确目标、提供资源、核查； c)        B要正确的做事：上令下达、多快好省、帮A找到目标； d)        CDE倡导提问文化。   4.       存在即有理！（不是存在即合理）   5.       项目型管理vs运作型管理 a)         项目：跳跃式发展，有始有终（毛泽东，打江山易，但在价值链上更重要）； b)        项目老板最高境界：无为而治； c)        运作：常规，周而复始（邓小平，守江山难）； d)        运作老板最高境界：大道无术； e)         中国的传统：生产制造大国，擅长做运作型管理。   6.       项目三重限制：T（时间）、R（资源）、Q（质量、数量）： a)         多快好省：数量多、时间短、质量高、资源少；   7.       项目要让两个人满意：Boss、Customer，但两者的目标往往是矛盾的！所以要Balance，达到win-win，项目“物有所值”而不是“物超所值”！   8.       项目的大小级别： a)         Portfolio（组合项目）>Program（大型项目）>Project（单一项目）>MD（交付件，通常15人以内、6个月以下）； b)        MD往下再分就是WBS（任务、工作包、活动）。   9.       项目的三边六拍：边行动边计划边修改；拍脑袋、肩膀、胸脯、桌子、屁股、大腿。   10.   WBS相关： a)         六把刀：                          i.              先管理（追求：快、省）再产品（追求：多、好）：形成模板；                        ii.              动名结构：动词模板偏管理，任务级；多年积累形成固定的名词模板，偏产品，工作包级；                       iii.              最底层作业：action，用工作量衡量（！=工期）；                      iv.              暂不考虑资源限制；                        v.              头脑风暴：不批评、不排斥、不评论；                      vi.              不排序：工作分解开始要“滴水不漏”，重完整性，不考虑流程。 b)        WBS做完，就：心中有树！叶子做完项目就完成，树枝都是模板！ c)        有经验的项目可以自顶而下，无经验可以自下而上。   11.   三点估算法：工作量，（最乐观+最悲观+最可能）/3，对比（1+4+1）除6的方法。   12.   项目预算（资源、时间等）中，B应该找A要一个备份资源，但尽量不要动用。   13.   action planà工作量à关键路径à工期àBaseline： a)         因事择人：把高手调入关键路径； b)        工作串行多（不愿分解）消耗T，并行多（不善分解）消耗R；   14.   收买人心：团队为各自的任务买单，承诺最可能时间，任务分配矩阵的表格最后要老板签字！   15.   以人为本：软件项目的主要成本是人力。

## 产品设计体会（五六）——《需求工程》培训记录 参加了2天的名为《产品经理需求工程实务》的培训，和去年的《产品需求管理》培训内容大约有60%的重合吧，但经过一年，还是听出了大于40%的新东西。   有关需求： Ø         需要（Need，心理状态？怀疑与want记反了）、欲望（Want，实物）、需求（Demand）；自己看到过另一种说法，“Need是客观上需要，Want是主观上想要”。 Ø         需求收集听的技巧：“聚焦于人们的期望而不是问题”，期望à基本功能，问题à增值功能。我的理解应该是：基本功能一定要听用户的，增值功能往往是设计师引发的。   项目管理范畴： Ø         OBS（Organization Breakdown Structure）产出物：项目管理的方法、体系；WBS（Work）产出物：进度计划；PBS（Product）产出物：产品模块；FBS（Function）产出物：用例。 Ø         项目计划，传统：功能à工作量à人力à工期；SCRUM：迭代周期（一周~一月）à人力à功能范围。 Ø         项目每日站立例会，每个人只能说3句话：昨天做了什么？今天要做什么？碰到什么问题，如何解决？ Ø         功能点工作量估计：宏观à专家法；微观à执行者自评（最悲观 + 4*最可能 + 最乐观）/6。   综合方面的： Ø         模仿 + 改良à创新，随着时间的推进，“有可能遇到，但不要奢望”突破式的创新。 Ø         领导的四个层次（比较扯蛋的）：亲力亲为，“活着（松下幸之助）”，“活过（邓小平）”，“没活过也行（耶稣）”。 Ø         企业成功四个模式：拥有资源（国企），生意模式（ali），拥有核心技术（Intel），管理/营销强（P&G，Nike）。 Ø         要找到自己产品的“最”，人们只能记住“第一”、“最”。 Ø         自己的想法：IT公司要做的事情都是类似的，都有那么几块，但是每种职位做什么事情在各个公司都有所不同，其实就是“权限”和“角色”的关系，所有公司都有那些权限，但是各自有独特的“角色定义”，在阿里PD的角色对应经典定义就是：部分“产品经理”的权限 + 部分“开发/系分/架构”的权限 + 部分“项目经理”的权限。

## 产品设计体会（五五）——项目Kick Off 今天说一下项目Kick Off会议（简称KO）的作用，会有人觉得这很形式化，但我认为很重要，其实KO只需要15min左右的时间，我会安排在需求评审（参加人与KO基本重合）之前，成本很低。 在这15min内，需要传达的信息有如下几点。   Ø         **项目的背景与意义** 说过去，做项目之前的情况，为什么要做这个项目（以让听众痛心疾首为终极目标）。   Ø         **项目的目的与目标** 说将来，做项目之后的情况，解决什么问题就算项目成功了（以让听众面带桃花为终极目标）。   Ø         **做法、需求、功能点概述** 说现在，具体用什么方法促使“过去”到“将来”的转变（以让听众跃跃欲试为终极目标）。   Ø         **项目组织架构** 目的是让到场的、相关的人员了解有什么事情应该找谁，注意不要遗漏跟开发关系不大的成员（小型项目的大多数活动是开发及相关过程）：服务部门、配合部门的接口人，因为项目的事情如果他们不知道的话，那么即使项目本身顺利发布，之后也会带来很多配合上的问题。 特别提一下，我会组织一个“项目督导委员会”，必须的，他们的任务很简单——背黑锅（权力越大，责任越大）。当项目因为种种原因出现重大变更的时候，比如成本、工期、需求等，我会向他们提出申请，获得批准后才动，这也是对PM自己和项目成员的保护。   Ø         **项目计划** 让所有人了解两个关键点：1.时间点与里程碑，2.各个时段需要的资源。 这点就不多说了，太深奥的还不懂，按老板的话，其实做好项目很简单，一是计划好，二是控制好，各种手段都是为了这两点服务的。   Ø         **沟通计划** 我觉得和项目全体成员明确这点非常重要，因为太多事情的不顺利都是沟通的问题，大家都做不到一直主动、彻底的沟通，所以有个规矩来逼着做一些沟通的工作，可以免去很多麻烦。一般来说，常见的手段有：项目日报、每日晨会、评审会、产品试用会、发布预告/公告……

## 产品设计体会（五四）——PD招聘广告词 前段在一位同行的blog上看到一些对PD工作的描述，感觉用来做招聘的广告词挺好的，摘录下来了，再加工一下，做个“官方说法”与“私下交流”（plus实事真相）的对比版本。   **官：PD需要全面负责产品的各个方面。** 私：因为PD这个职位比较新，具体要做哪些事情没有开发、测试清楚，所以你干多干少自己决定（职责不清楚，就是事情多起来没个谱……）。   **官：此职位较难量化考核，综合素质要求高。** 私：因为职责内容丰富，不论是360度调查，还是用KPI考核你都可以顺利回避（怎么感觉哪方面出了问题都要背黑锅啊，所谓战战兢兢，如履薄冰）。   **官：需要敏锐的商业嗅觉，辅助决策公司战略方向。** 私：你真的可以决定公司产品长什么样（产品当然是老板生的，你也就给她化个妆）。   **官：需要很强的沟通能力。** 私：有很多机会展示你的想法，如果有兴趣的话，可以利用工作机会认识公司里几乎每一个人（你总是关于某个产品的信息交换中心，也是各方共同挤压的对象，哪边都不得罪是一门艺术哦）。   **官：关注业界动态，对互联网产品兴趣浓厚。** 私：因为你要了解行业的最新资讯，做竞争对手分析，所以需要不断去各种网站注册，试用，老板无法判断你是否在冲浪/瞎逛，全凭自觉（时间久了是很痛苦的，整天被那么多垃圾产品恶心，自己做的产品看太多了更恶心……）。   **官：很多的培训和学习机会。** 私：职位需要，可以申请各种培训，购买书籍，拜访客户/专家（拜访客户是不错，可为什么我们的客户总隐居在连车都打不到的无人区？囧）。   纯娱乐，不要当真。

## 产品设计体会（五三）——产品文档与规范 几个月来不断的整理适合我们团队的各种文档，是一个非常轻量级的文档包，这次对着理好的mindmanager图讲，分五类：   Ø         需求管理类 n         功能列表极其管理方法，这里可以体会到团队协同工具的重要，现在我们用的是office live的excel，比较简单。 n         产品的网站页面地图。   Ø         项目管理类 n         项目Kick Off的ppt。 n         项目任务书。 n         项目日报。 n         项目发布通知。 n         流程类：初期常用的是日常发布流程、紧急发布流程。   Ø         商业需求类 n         主要是BRD，团队现阶段还不用严格区分BRD和MRD（可参见《十七》），统一用BRD就可以了。   Ø         产品需求类 n         基本就是PRD了，包括如下三大块：总体说明、UC文档、非功能需求。   Ø         需求规范类 n         界面规范：整体的如页面大小、字体字号颜色编码。 n         交互规范：如列表的默认排序、列表中文字的对其方式，手头这个产品是“文本左对齐、时间居中、数字右对齐”。还包括字段的校验规范、系统反馈的规范等等。 n         文案规范：如语言风格、语法模板、常用操作的标准说法等。   [](http://blufiles.storage.live.com/y1p3O4KBNpz6AUVz32vPku3twqbeZljyVYfrVeDxOJ_rd28uQ2hO-fEEKn_VOY5cfn4aZAmdcW5Oyk) **------> [大图猛击这里](http://photos.i.cn.yahoo.com/down-tuC5ixgibpnHXomzOC77eD8gFHRPGys-?cq=1&aid=3241&pid=2f05.jpg)**     另外还有些技术方面的规范，比如开发规范，会说一些代码的规矩，函数命名规则等等，不太懂，就不涉及了。   网上不少同行前辈讨论过产品文档、规范应该什么时候整理，我个人的感觉是产品1.0发布以后，2.0发布之前。一般互联网产品都会在1.0发布后还有很长的生命周期，而在做1.1、1.2的时候往往有一个设计工作的缓冲期（一方面是开发测试忙着应付扑面而来的线上故障、另一方面是PD需要收集反馈以确定下一步方向、团队也会做人员调整），所以这个时候做产品规范，是第一代产品、第一代团队的工作总结，提高后期的效率是最合适的。当然，这个工作也是应该采用迭代的方式进行的，无需也做不到一蹴而就。

## 产品设计体会（五二）——MS Office使用心得 提前50天左右完成“一周一篇，持续一年”的小目标，继续往下走下一站99篇~~~ ========================================================== 在很多外人眼中，需求人员整天就是在写文档，那干脆整点文档的心得吧。话题超大，网上也有很多文章，我只说几点自己平时很注意的。   Word：在做结构稍微复杂点的文档时采用，简单的几段话一般用记事本搞定，打开Word绝对不是一开始就码字，而是要先设置一堆东西，比如页面、格式样式、标题级别啥的，充分利用Word的自动功能，和编程有点像。   Excel：在写结构化文档的时候很好用，当你用Word写作的时候发现老是写1、2、3……条的时候，就要考虑是不是应该转用Excel了。几个基本功能：条件格式、筛选、单元格有效性、单元格锁定、隐藏，可以让表格看起来爽一点。   PowerPoint：好的ppt只是演讲者的辅助，应该尽量少的描述文字。但经常我们又要满足“受众拿到ppt就可以了解内容”，非常幸运我们发现了一个叫做“单击此处添加备注”的地方，可以把所有想说的东西都附加在这里，既不干扰陈述时的听众，又让有事来不了事后看ppt的观众可以了解全部内容。另外自己很注意的一点，也是从软件可用性概念带来的：要说的东西一条一条的出现，并且想办法突出当前在讲的这一条。   以上三个简直是Office三部曲啊，又是一次“字à表à图”的进化。这三个是比较通用的，下面三个就稍稍专业一点。   OutLook：还是菜鸟，当信件少到能够每封必看的时候，其实email对于我们来说还没有到需要管理的程度，换句话说，这时候我们还只是一个初级用户。但是“邮件规则”、“邮件标记”、“会议邀请”几个点真的要好好研究一下，对提高效率很有用。   Visio：这个真的很强大，做流程图、网页低保真demo（用Axure替代了）、简单的UML图（用Rational Rose替代了）、团队组织结构、甚至将来家里装修布置都可以用。   Project：这个用的不多，不过对于项目的安排、每个任务谁来做、何时做，以及人物之间依赖关系的管理真是杠杠的。   其他的产品，如OneNote、Access……基本不用。

## 产品设计体会（五一）——敏捷的估计与规划 前段读了《敏捷估计与规划》，这本书很适合开发经理看，我只是很快的浏览了一下，摘录一些体会。   Ø         敏捷的里程碑是功能驱动的，先完成可交付的最“重要”功能，重要取决于功能商业价值、生命周期、实现难度等综合的结果。而传统的瀑布模型的里程碑是任务阶段驱动的，到了项目50%的时间，可能进入“编码”，但对客户来说，等于0%。而且这样的模式会陷入“实现难度决定开发顺序”的不合理模式，因为这里有个不合理的假设前提：所有功能都能够完成、必须完成，中间过程对客户是透明的。   Ø         项目估计的不确定性是会累积的，80%×80%×……，所以开始订的项目计划，在一个月后已经面目全非，强行的遵守是没有意义的，而应该不断的修正计划，当然，更好的做法是一开始的计划中间留有一些柔性的内容。   Ø         随着时间变化，必然有新的信息出现，特别是瞬息万变的互联网业界，死守着开始的项目计划不调整是没有逻辑的做法，敏捷的迭代刚好权衡了变化的成本和不变的成本，就是：不变本次迭代，更新下次迭代，这是一个将项目计划细化粒度的做法。   Ø         需求唯一不变的特征就是“不断变化”（plus不断细化），敏捷的思想就是欢迎变化，拥抱变化。瀑布模型一次性完成的需求分析，会存在“过度需求”的问题，降低整体效率。   项目管理理论的发展，从开始混乱，每个项目自有一套，每个PM自有一套；到后来人们非常想订出一个统一的简单的流程，减少人为影响（瀑布模型等出现），；再后来进入灵活的敏捷，看似又变得混乱，实则有序。又是宛如那个哲学的三段论：见山是山à见山不是山à见山还是山；也如管理的三个境界：人治à法治à无为而治。

## 产品设计体会（五十）——终点：Matrix 先默哀3分钟~~~ 今天国内各大网站，第一次出现了黑白版面，很震撼~~~ 今天下午的那3分钟，我在9楼看着窗外的马路，人、车全停，喇叭齐鸣，更震撼~~~ ====================== 分割线，正文开始 ========================   事物发展到一定阶段，必然需要借助外力来帮助发展，好比Matrix借助Neo，改革开放中政府借助民营经济体，民企知道自己在被“利用”，但他为了自身更好的发展欣然接受，这其实是最终的和谐共赢，在Matrix中，第三集便是如此，大大超出第一集的概念。这也就是哲学层面的UGC。（延伸：多数情况，外力是阻力，所以要感谢阻力、感谢对手！）   前段看了谢文对“一起”的一些想法，发现整个就是要做Matrix了，呵呵。而我的理解：网游、SNS、电子商务，都是把现实的一部分通过虚拟现实来实现，做下去都是相通的：比如网游里可以打装备，再兑换为RMB；SNS的开心网已经很像网游；而淘宝也添加了聚宝盆等社会性元素。各个产品的终点都是Matrix那里，统一的平台，虚拟的平行世界。   之所以有所谓的虚拟现实/现实/现实中各个局部小世界的区分，是因为物质/信息/能量流通不畅造成的区隔，我们还有很多只能在“现实”中获得，而无法通过其他世界的流通得到的东西。如果游戏（定义成可以让人专心去做的一件事）获得的回报： 1. 可以流通到现实中； 2. 可以流通到他人身上； 那么就不会被冠上“沉迷”一词，或者就不叫“游戏”了，而是可以执着去做的事业。   采访儿子沉迷于网游的家长，他也许没有像我这么古怪的想法，但他知道，他的孩子玩游戏的回报没法变成钱（其实这点是可以实现的），所以他的儿子将来就没法在现实中生存；而儿子也没有想清楚，他在游戏中的回报，大多数是精神上的满足，这虽然可以流通到现实中，但没法流通到他的父母身上。两代人之间也许不会像我这样想，所以不理解，很痛苦，不知为啥，这事儿让我突然想到“建国初国人感叹生活在水深火热中的美国人好惨，我们一定要拯救他们”的画面。   所以相对而言，从电子商务切入虚拟现实更靠谱一点，毕竟已经看得到滚滚流通着的真金白银。

## 产品设计（四九）——产品市场化 过年那段时间，抽空看掉了《产品经理实战手册》，金山的王欣、夏济写的，很实用的操作读物，看起来比较轻松，记录一下自己的体会。另推荐《产品经理的第一本书》和《第二本书》（前两天5块淘到，哈哈），更详细，看起来也累一点，只是浏览过。   看完之后对产品经理有了更全面的理解，正如Product Manager是从宝洁的品牌经理发展而来的一样，还有很多工作是PD平时接触不多的，因为公司里有专门的运营、PR、市场、销售团队会做掉相应的工作。不过这次的产品暂时没有专门的运营团队，而且最近又加入了销售团队的邮件组，正好给了PD接触相应领域的机会，列几个还记得的职能方面吧。   包装：对互联网产品来说，我的理解就是产品的portal、登录页面等，这块是给用户的第一感觉，重要性不言而喻。   定价：有很多种理论方法，比如成本导向、需求导向、竞争导向等等，似乎还有种更常用的，就是：老板开会讨论法，=,=。   促销：“广告”和“公关”似乎都可算为促销策略的一部分，这部分的功能是大覆盖的“面”的攻击，好比空军的轰炸。（这部分一直没理清，好像几件事情互相包含的）   销售：好比地面部队，更精准的点对点的攻击。B2B那边好像70%的人员都是销售？攻击力还是很强的。所以说阿里其实不是IT公司……   渠道：产品销售的方式，产品采用何种渠道，取决于性价比的综合考虑，比如自己公司的多种产品，就有电话直销、登门直销、网上直销、线下渠道加盟（好比雇佣军）等多种模式。   产品市场化要做的事情很多也很细，这块实在是没有研究，比如做一次公开的推广活动，就牵涉到市场预算的及时到位、宣传资料的准备、事前事后的PR轰炸，确实需要老手来做。给自己科普一下，简单一记。

## 产品设计体会（四八）——资源战争与BRD 产品团队刚刚经历了一场公司内部的战争，争夺的是下个月的开发工程师与测试工程师的资源。   先说一下为什么以前没有过这样的战争吧，因为公司原来是按照产品线划分的部门，这样对于某个产品来说，有自己的PD、开发与测试等，下个月要做哪些需求，完全可以在产品经理的层面上决定；而现在公司变成了按职能划分团队，有了统一的产品运营中心（PD和运营）、研发中心（所有开发工程师）、质控中心（所有测试工程师），这样的话，下个月各个产品就都想尽可能多的抢到开发与测试，然而资源总是严重不足的，所以最终做哪些，就必须要上升到几个中心的大老板层面来决定了，而大老板的决策依据就是各个产品经理的pk，对各自产品发展BRD（Business Requirement Document）的描述，于是，战争爆发了，：）   所以前段时间，大家一起在准备BRD，这就是我们的武器，我们需要尽力说明我们要做的东西的商业价值，才能抢到各种资源，因为在pk之前，全公司的资源需求已经是现有资源的好几倍了……（一般以“人日”来简单估算衡量，有同学说一群人pk简称群p，就是多争取点~人~~日~~~，呃，很邪恶！）   武器主要包含以下几个部分：项目概述、项目背景、商业价值分析（重点！大老板最感兴趣的，一定要说在点子上）、功能需求描述、其它需求、资源评估（重点2！大老板们要看成本）、风险和对策。   当然同学们也会搞点技巧性的东西，比如卖个破绽，故意加入一些让老板砍的东西，有点类似谈判技巧里的玩意。   最后谈一下两种组织架构的各自优缺点，按产品线划分的部门对产品本身是有利的，产品经理可以按照自己的想法做，资源有保证，产品规划不会被动改变，它的缺点也就是按职能分部门的优点；职能部门对全公司的资源共享有利，确保所有资源都用在对公司最有意义的产品上，另外它能把资源战争的鲶鱼效应从产品内部扩大到公司层面，使PD和产品经理们更抓狂的去为产品的发展而苦苦思索……   记录一下漏写的： 1. 两种组织结构的变化，我的理解是公司自然发展的必然过程，随着产品的增多，全公司变成了越来越多个资源局部最优，他们之间可以互补的可能性越来越大，此时全局最优的效益越来越明显，所以打通。 2. 产品划部门的优势，还有个是沟通的顺畅，单线领导，都向产品经理负责。

## 产品设计体会（四七）——UML学习摘录（下） 接上回，下层的图描述的是一个用例内部的事务（用例内部不一定是“单个用例”内部，也可能有用例之间的关系），主要有：   Ø         **时序图**（**顺序图**）：描述事情变化在时间维度上的先后顺序，善于表达对象（比如多个页面之间）的交互。玩的好可以完全替代UC中对流程的文字表述。              [](http://blufiles.storage.live.com/y1p3O4KBNpz6AUhC5w_FKZp98pRJsTCO_D0aOsWBd4sPz7ASfg-Zb5OUKuxtnUTmzqS4ivbUZxul2Q)   Ø         **活动图**（比较接近传统意义上的**流程图**）：描述各种动作如何引起系统变化，善于表达泳道较多、分支较多的情况。                  [](http://blufiles.storage.live.com/y1p3O4KBNpz6AWyDoV63XSkbB1yiF-KYeBYwEvsFFRwD_-GROo-y7zFKd7lTl6UnhO7cc0ipJocEoI)   Ø         **协作图**：表达不同对象之间是怎么互相影响的，这个图团队里用到的不多，就不画了，理论上他和时序图是可以等价转换的，时序图关注交互在时间上的步骤，协作图关注交互过程中各个对象间的关系。   这些图我们都是用Rational Rose画的，它最好的一个点是可以在不同层次间的图穿透，比如从用例包穿透看到用例图，再穿透进某个用例看活动图，再穿透进活动图的某一步看具体的时序图。   很多时候多种图都可以描述同一件事情，只是从不同的视角去表达一个系统，选用哪个关键是看针对特定的系统，从哪个角度来描述更容易让受众理解。另外还有表述软件实施的**构件图**、描述硬件结构的**部署图**，暂时用处不大，遵循性价比的原则直接跳过了。   融入了UML标准图元素以后，一个功能模块的UC文档大约就是这样的：文档说明、类图+用例图（需求描述部分）；一个个的UC，UC里包含时序图、活动图等等（需求分析阶段）。整块的需求规范化工作最近也在做，以后有机会再整体整理出来。   最后感慨一下Rational Rose真的太强大（建立了整个软件工程的RUP，Rational Unified Process，包括分析、设计、编码、测试、部署等等一切），想找一个轻一点的工具，折腾了半天Visio，发现总是缺点什么，谁有更好的方案？

## 产品设计体会（四六）——UML学习摘录（上） 人治à法治à无为而治，大公司多为第二种：法治，1和3很像，外表经常看不出来。管理最高境界就是做到无为而治，这是产品和团队的发展必经阶段，我们的现状就是“1à2”，开始规范化，正好有同学原来熟悉UML，所以大家也都开始学习一下。   UML就是统一建模语言，它试图将软件工程的过程给规范化，从产品设计的角度，我对它的简单理解就是用一系列的标准图把需求分析的过程串起来，充分体现了“字不如表，表不如图”的原则，具体是以单个用例的粒度为界，把相关的图理解为两个层面。   上层的图中，用例是最小单位，不涉及用例内部，主要有：   Ø         **类图**：感觉有点像**实体关系图**（ERD，更接近现实世界的对象，类图更接近技术实现的对象），描述系统中出现的各个对象之间的关系，以及和外部系统的关系。这是对业务领域的描述，一个外行看了以后就应该了解系统是做哪方面事情的。还是用我最喜欢的“小明去饭店”为例，画个图练练。               [](http://blufiles.storage.live.com/y1p3O4KBNpz6AV_KPKIkWr1mx6ubLw5xj3aAL2bUziPjISKb5XPUALmD3Cqei9of4LmasnvK3kcF6Q)   Ø         **用例图**：各个用例之间的关系（include/extend）、用例包、用例和actor之间的关系（将一组相关用例打包成一个模块，画成“**用例包**”）。描述这个系统具体可以做哪些事情。          [](http://blufiles.storage.live.com/y1p3O4KBNpz6AWnZqemj7MBtR9qbDGFCZd5UfJ353R0NxWbIdenyyZyftmGS5aW8p3hetmkKBHaJls)   Ø         **状态图**：表达系统里实体的状态转换，这也是贯穿多个用例的。例图里描述的就是“小明”的状态转换。             [](http://blufiles.storage.live.com/y1p3O4KBNpz6AWy1KAu460WvyV6Wbo6a0y6-xvJYYE1ga35dQH7K2tK3BGvcHgRxc6kos3xojFrLm4) 这个层面上的图包装一下就可以生成整个产品最顶级的**业务逻辑图**，描述整个系统的业务层面的事情，用于商业演示。业务逻辑图的画法现在团队内也没有统一的意见，比较随意，也就意味着最难画。 下一次再画点下层的图。

## 产品设计体会（四五）——外行眼中的技术分工 技术人员的全面介入，可以简单的看作以“需求分析初稿完成”为界，需求完成以后，派生出几个设计：交互设计、编码设计、数据库设计、测试设计，各自设计完成并执行以后，再部署发布。   具体的说一下，交互设计这块，主要是做软件和用户交互的工作，分工有从最直接的**视觉设计师**到使用感受上的**用户体验师（交互设计师）**再到偏代码实现的**前端工程师**。   编码设计，比较偏概要设计的有**软件架构师**（比如整个系统的表结构设计），具体到coding的层面就是最常见的**开发工程师**，他们也会有分工，比如偏应用、偏底层数据库、专做搜索引擎，等等。   数据库设计，对于大用户量的应用特别重要，而阿里的用户数实在是比较多，所以相应的人员——DBA，**数据库管理员**，在业界也确实是比较强的。   测试设计，就比较单纯了，相应的人员就是**测试工程师**，再细分一点就有功能、性能等等，一般来说性能测试会写一些自动执行的脚本，感觉更高科技一点。   上述各项工作完成之后，就要把各方面准备好的产出物拼在一起部署发布，那么就牵涉到硬件方面的管理，这就是SA，**系统管理员**。对于BS应用，感觉部署方面的工作比传统CS软件简单一些。   对于软件项目的整个过程,需要在流程/规范上做控制以防止低级失误的发生，比如有时候需求人员会觉得某个功能的改动很小，就直接叫开发人员改而跳过测试人员，这样违反流程的行为对于复杂的系统是极其危险的。所以产生了SQA，也就是软件**质量控制人员**，这块和测试不一样。   对于多次不断发布的产品、多分支开发的产品，**配置管理员**（SCM）就显得非常重要了，有他们的控制，就不会发生“某个bug在新代码发布之后重新出现”这样的低级失误。像简单的用SVN、CVS来管理文档、代码的更新、软件版本的变更、日构建/发布的控制，就是SCM的雏形。

## 产品设计体会（四四）——项目外包不适合“敏捷”？ 前几个月尝试做了PM（这次是Project不是Product了），亲身经历了一个项目是怎样一步步不顺下去的。先说明一点：这里的“敏捷”是指甲乙双方配合的“敏捷”，而不是说外包项目本身内部不合适“敏捷”。   先说一下背景，项目时间太紧，工期是由商业谈判决定的，没有及时评估工作量，做着做着产生delay，先试图简单的用加班的方法赶上进度，后来被迫注入“敏捷”项目方法，但事后发现“项目外包”模式不适合敏捷。   首先，项目外包使得甲方不愿意砍需求。为了敏捷灵活，公司内部的项目需求在很大程度上是可以砍的，是“保质不保量”，这是符合敏捷的原则的。但是项目外包，甲方在提需求的时候不愿把任何一个功能像平时那样推到2期做，因为项目结束后2期在哪里都不知道，所以“保质保量”变成了“不保质保量”。   其次，敏捷必然导致文档工作不细致，甲方游离于项目之外的“验收测试”模式难以适应。敏捷从模式上会导致提交测试的产品和最初的需求之间必然有很多变化，并且文档很难跟上，而这种敏捷在公司内部之所以运行的很好，是因为PD、开发、tester在项目过程中可以充分交流，tester在TC（Test Case）评审的时候会叫上PD和开发，有些属于详细设计的细节是在评审的时候与开发直接确认，在测试执行过程中也会协助确认需求细节并迭代测试。而项目外包的时候，甲方会从一份颗粒度过粗的需求文档上派生出“验收测试”的TC，又因为验收有“考试”的性质，所以不允许乙方的开发参加甲方的TC评审，导致只能和甲方需求人员确认细节，而需求人员对如此细节又没有要求，无奈之下只能按照自己的想法说，必然导致两边对需求的理解有鸿沟。另一方面，验收测试是一次性的，只有pass或false的结论，没有迭代的过程，不符合敏捷的思想。   最后，乙方没有“敏捷”的经验和意识。一般甲方没有独立软件研发能力才选择项目外包（否则多用开发外包），职业性质/国内的项目管理现状决定了外包工程师的习惯是按照详细的设计文档开发/测试，抗拒需求改变，所以强行“敏捷”会导致失控。因为没有一份完整的详细设计文档，开发人员会按照自己的想法编码，测试人员也照自己的想法测试，没有做TC评审的意识，加之没有和需求人员即时沟通反馈的习惯，没有一个迭代的过程，再为了工期的死命令削减测试强度，结果就是发现做的与需求不符的时候已经晚了。   很多原因共同造成不好的结果，还有些没说，总结下来就是不能再这么做了，对敏捷的理解很粗浅，欢迎指正。

##产品设计体会（四三）——说说评审会 我的感觉，评审就是项目相关的几个小团队的人坐在一起，一方讲，另外几方听并确认，统一认识，消除误解，防止偏差没有及时发现而随时间放大。这个过程不做，往往问题到很后才暴露，然后是谁的责任纠缠不清，与其亡羊补牢不如之前就在流程上预防，防病优于治病。   项目过程中，比较大的三方面是PD、开发、测试，所以派生出三次评审，按照项目阶段依次为：   Ø         需求评审，俗称UC评审，在需求完成以后，是PD说给开发、测试听；  Ø         设计评审，在设计完成之后，是开发把对需求的理解以设计文档的形式说给PD、测试听，这部在时间紧的情况下会被省略（代码评审现在几乎不做）； Ø         测试评审，俗称TC评审，在TC写完测试开始之前，是测试把对需求的理解以TC的形式说给PD、开发听。   评审的发起方，可以考虑都由QA发起，作为项目过程管理的一部分。也可以考虑每个评审由每个阶段的负责人发起，在阿里通常是这样做的。   评审的主要过程：   Ø         确定参加人员，注意两种容易被漏掉的角色：一是能做决定的人，因为评审的时候各方不可避免的会对业务有不同理解，从而开始对需求细节进行讨论，这时候就需要有人能拍板，有人能负责；二是与此系统有接口的其他项目的成员，我们吃过太晚发现冲突的亏，改起来成本很高； Ø         协调资源（时间、地点、设备），通常大家都很忙（包括会议室和投影仪），找个时间不容易； Ø         事先分发文档，保证参加评审的人有足够的时间阅读并思考，每个参加者也要做好功课，带着问题参加（这点自己做的不好，=,=），避免出现评审会上第一次看到相关文档的情况发生，否则评审是没有效率的； Ø         评审会本身，没问题就快速的通过，有小问题当场确认，大问题带回去，需要再次评审；最后是评审结果的发出，项目继续往下走。

## 产品设计体会（四二）——又是零散体会 每隔一段时间都有些难以成篇的零散体会出来，这样也不错，更随意一点，有blog之后又出来twitter了嘛，一个道理。   Ø         产品与设计师是互相依存的，在高层决定公司战略的前提下，很多时候，好的产品对设计师的帮助会远远大于好的设计师对产品的帮助。   Ø         PD、开发、测试的人员比例，对于web应用，我的感觉1：3：1是比较合理的，开发不足会产生一种有枪没子弹的郁闷，而测试因为产品修改比较简单，所以可以比传统软件轻。   Ø         产品进化论：产品的定位、发展和生物的进化很像，满足大众需求的产品是普适的，就像一个大的生物种类，当其中的一个小群体长时间生存于某个特定的环境下时，就会进化成适应局部特性的亚种，同样的道理满足小众的产品就要往局部的特性做才符合自然规律，即所谓垂直、所谓特定的目标用户群体。另外，普适的产品越是想满足所有人，就越没法满足所有人，比如新闻联播。   Ø         四十多篇了，有些人问过是怎么坚持下来的，我后来想想，可能是因为《体会》是写给自己看的吧，没有任何被动。但做产品应该是做给自己还是做给用户呢？这不3月份又有两位大师级的人物吵起来了，论题就是“产品设计，首先满足自己”，正方是37Signals代表着的是产品经理（或管理人员），著有著名的《Getting Real》，还没拜读过；而反方 Don Norman 代表着的是设计师，著有《设计心理学》、《情感化设计》。有兴趣的可以去搜搜看。   Ø         互联网产品有一点幸福，因为可以比较简单的做AB-Test，其实就是对照试验。比如我有10万用户，不知道某个功能做成什么样子好，那就可以把两套方案都做出来，给A组1000个人先用方案A，B组1000个人先用方案B，拿到数据结果以后，再决定剩下的98%用户该怎么办。这样的低成本很多传统行业的同学羡慕不已。

## 产品设计体会（四一）——用户创意无限 挺好玩的一个话题，很多产品设计出来，结果用户很喜欢，用的很遛，但和设计师的初衷千差万别，简直让人吐血，闲聊一把。   例1：msn的“签名+显示为脱机+联机”组合拳。 具体说就是写一句话做msn的签名，然后不停的上线、显示为脱机、上线……，让好友们不断的看到。 常见用法1：剧透。比如我刚看完《色戒》，然后就写一句：王佳芝最后死了……再不停的上啊下啊的，是不是很恶毒？ 常见用法2：表白 or 求婚。喷嚏网上看来的，摘录一下“……当天下午就把msn签名改成“今天我求婚，大家帮我发短信：夏某，嫁给刘某某吧，时间19点整”……果然，立马就有不少人开始在msn上打听这事，真是一呼百应，有号令三军之势！……下班以后我们几个都留下观战，埋伏在公司门口，我还特意借了公司的DC准备抓拍精彩瞬间……那边夏某的手机开始一通狂响，吼吼～我们都知道是msn求婚志愿团的短信到了，omg，那手机，那是足足响了五分多钟……”咳咳，msn的设计师们恐怕看了也傻掉了吧。 衍生用法：好友多的同学一直在琢磨这事儿了，写上“广告位招租”，然后说明我的几百个好友都是IT精英，消费能力强，每天上班时间必在线，打个相关产品的广告，比如啥新奇特的电子产品，来回上下三次，就相当于精准投放了几百人的广告，杠杠的啊。   例2：Windows的回收站当个文件夹。 这是前段时间看到一个同事的用法，当场惊呆。说是为了保持桌面整洁，所以把常用的文件都先放到桌面，然后删进回收站，要用的时候恢复一下。我们问不怕麻烦啊？回答：习惯了……习惯？我有帮别人电脑清空回收站的习惯……   其实生活中还有很多类似的例子，比如微波炉，把毛巾沾湿了放进去转1min，就可以洗脸了，宅男必学……还有啥例子哦？欢迎补充。   绕回来，碰到这种事情，设计师应该怎么办呢？我觉得不妨就从了吧，甚至可以将就错的把这个功能发展下去（不要和公司业务发展冲突），毕竟用户最大，这也算一个另类的“UGC：用户产生内容”的方式了。

## 产品设计体会（四十）——销售渠道 做付费产品，就必然要牵涉到卖的问题，最近公司正好[“e网打进”火爆销售ing](http://www.alisoft.com/portal/agent/index.html)，plus前段时间浏览过《渠道为王》，就说说相关的体会。   销售有两大模式：直销vs分销，分销要通过渠道，渠道又分代理（赚佣金，没有产品所有权和库存风险）和经销（赚差价，产品所有权发生转移，比如批发商），现在的网络付费产品，因为多是个人应用，所以直销比较多，而我们的“e”是给企业用户的，加之国内中小企业现在相应的知识很薄弱，直销成本太高，所以我们选择了渠道销售。   在渠道的推拉战术方面，“e”显然用的是推的方法。所谓“拉”是通过PR、广告、传播等手段启动市场，刺激消费者，促使渠道来找厂商；“推”是集中力量做渠道工作，用高额利润去刺激渠道主动推销产品,快速抢占市场。推适合企业规模小、技术含量高、销售过程复杂的产品，一般来说：新产品推，老产品拉，“e”的驱动路线“PDà阿里的渠道销售à渠道à终端用户”。   从产品设计的角度，对于通过渠道销售的产品，在设计上，新增功能和改动功能的时候，还需要额外考虑渠道销售人员的培训成本、渠道商的培训成本，他们习惯了卖推广，要把一个功能说明白很不容易；另一方面，既然选择通过渠道来销售，就说明终端用户对互联网的应用能力不足，相应的设计思路也要转变。   再有一点，在渠道终端的用户一般是企业，企业用户与个人用户的差异也不得不考虑，比如支付，企业用户就有开发票的问题，不能简单的只考虑网上支付的途径，另外由于渠道的介入，多级的定价，分成比例，开发票的流程，渠道政策都要有相应的系统支撑。   白鸦的一篇[《如何保证顾客的整体体验？》](http://uicom.net/blog/?p=721)让爱好用户体验的人对销售渠道又提出了另一个层面的问题，社会发展导致对效率的优化——分工，也是出于成本考虑，我们的产品采用渠道销售——一种业务的外包形式，我们的终端客户是不会了解中间细节的，他们会把外包服务的不爽怪罪到产品上，给产品的体验减分，那么最终一个很大的问题，似乎也只有折中解决的问题，就是：如何保证渠道的服务质量来保障我们产品的整体体验？

### 产品设计体会（三九）——CSDN专访精编版 上个周末接受了CSDN的专访plus[博文视点](http://www.broadview.com.cn/)的闲聊，发现说的东西都差不多，自己整个精编版如下，[完整版猛击此处](http://news.csdn.net/n/20080319/114499.html)。 **记者：**2007年7月，您开始在自己的 MSNSpace 上面写“产品设计体会”这个系列文章的，最初您开始写这个系列目的是什么呢？在这之后，又是哪些原因一直让您保持住了持续更新的热情呢？ **答：**就像我在第一篇里提到的一样，一开始只是个很朴素的原因：那段时间老板要求我们产品设计师的周报要写作文，不少于500字。当然之前也确实在工作中有些零散的体会，但一直懒得整理，正好在老大们的“产品设计师要有想法”这个观点的指引下，就开始写了。……我写得也不多，基本就是每周一篇。年初我给自己的08目标中有写满52篇，正好满一年，现在很有信心要写满99篇，相信到时候会有一些小小的奇迹出现。   **记者：**系列文章发表这么久以来，您最大的收获是什么？写这个系列文章得出的体会，对您的工作有怎样的提高？ **答：**写系列文章是一个不断思考、整理的过程，在写作过程中，我越来越感觉到需要学的东西很多，不管是工作中还是自学的时候都能得到新的知识，所以需要一个提炼、融入自己知识体系的过程。举个不合适的例子，就好像做产品一样，不断的加功能，加到太乱了就重构一次，再加功能，越来越强大。 写了这些文章后，确实感觉工作更有目的性了，经常一个礼拜是这样的过程：这几天要做什么工作，缺哪些知识，就去看点文章看些书；然后再到工作中实践；最后总结写成体会，就这样循环。   **记者：**对于自己的工作，您是抱着怎样的态度去关注的呢？ **答：**态度？能骗到自己把工作当爱好就OK了。我发现自己真是干一行爱一行，我研究生是学生物医学工程的，在医院实习过半年，穿着白大褂在检验科给人做检查。后来又用很多临床收集来的数据做分析，整天对着电脑研究数据挖掘和信号处理。之后找工作误打误撞进了阿里，做起产品设计，从开始什么都不懂，到现在越做越觉得这就是我想做的事情。阿里能提供的平台和自由度真的很好，三五年内我觉得完全可以继续边做边学到很多东西。   **记者：**做产品设计需求雄厚的技术功底吗？对于以后想走向产品设计的开发者，您有什么建议呢？ **答：**我本来不是技术出生，所以我回答：不是必要条件。团队里也有从开发转向产品设计师的，很有特点。背景这个概念绝对是有利有弊，看各人怎么用自己的“技术背景”了。用好了，可以在设计的时候思考全面，进入实施阶段与工程师更顺畅的沟通；用不好就会让技术压倒商业，在业务模型没定的时候就考虑过细的实现难度问题。团队中的产品设计师原来还有做运营的、做项目设计师的，所以说之前做什么不重要，产品设计师必须是一个通才而不是专才，另外加上不断的学习。对于要做产品设计师所需要的综合素质，各位可以看系列文章第三十篇《“体会”导读的思维导图》。   **记者：**最后，您希望您的读者在看了这个系列文章后有什么体会？ **答：**之前只是周报，然后贴出来的最初目的是找到同行，抛砖引玉，大家一起交流一起进步，因为自己是个新人加菜鸟，入行到现在也才两年不到，所以一直很希望得到大牛的指引。但是，我感觉写原创的产品设计师、产品设计师太少，可能大家都太忙了吧。这方面交互设计师、用户体验师做的就好很多。我去年开始就订阅了好几位牛人的blog来关注阅读，都很有意思而且收获也很大。在他们眼中经常感觉PM和UE是“对立”的，所以我要立志做一个“爱好用户体验的产品设计师”，：）

## 产品设计体会（三八）——项目外包！=开发外包 项目外包和开发外包的模式有明显区别，手头经历了一个概念不清的项目，结果一路坎坷，体会如下。   合作模式、分工一定要在开始的时候明确。这次的项目外包，乙方又把开发外包，谁对谁负责，什么事情谁做一直没有明确界定。乙方会本能的倾向于开发外包，导致甲方投入越来越多，产生障碍。   既然项目外包了，项目管理方法应该乙方定。当时间紧的时候，乙方或投入资源或和甲方重新商业谈判来解决，甲方强行改变项目管理模式是风险极大的。比如这次双方对“需求à设计à编码”环节的理解有差别，乙方是教科书里的软件工程，而甲方的“需求”包含了很多“设计”的内容，“编码”也包含了部分“设计”，“需求”完了直接进入“编码”。说法不同，实质一样，不过后来采用甲方的模式，导致乙方真的跳过了“设计”阶段，没有产出相应的文档。   项目外包的需求如何配合？乙方应该push，向甲方收集需求，并维护《需求说明书》，当然甲方要积极配合并即时告知最新变动并走乙方的流程进行评估，而开发外包就是甲方push更合适，走甲方的需求流程，不断给外包的工程师更新需求。   项目外包的测试如何配合？甲方肯定会有验收测试，但是乙方一定要在项目范围内安排比验收测试更详细的测试，前外不能把“找bug”的测试部分寄托在甲方的验收测试上，而这次到项目提交的时候，项目组内部做过的测试还远不如验收测试详细，这和验收的原则显然是不一致的。   另外外包的项目会有甲方乙方两个PM，这次也听乙方的中年PM谈了很多两种PM的不同，受益很多。