iamsujie的产品设计：人人都是产品经理

我们整天在说话，其中很大一部分都是逻辑学意义上的“论辩”，可是论辩到底有哪些规则，我们又习以为常的犯着哪些错误，有多少人想过？前段时间弄了本《逻辑学基础教程》翻了翻，发现其中对于论辩的章节说的还是比较清晰的，笔记如下。

论辩是一种说服型对话或批判性讨论，通常有>=2方参与，以意见分歧作为起点，目的是通过理性的方式来消除分歧，作为一种典型的对话，其表现形式为语言行为交流序列。通常有9条规则。

1. 自由规则：论辩双方不得阻止对方提出立场，或者阻止对方质疑立场。

Ø 谬误：限制对方提出立场或质疑，宣称某些立场是神圣不可侵犯的或不容置疑的，宣称立场是一种禁忌

u 如：“你居然敢怀疑某人的话！”、“你不该讲死人的坏话！”

Ø 谬误：限制对方的行动自由，给对方施加压力，阻止他提出立场或异议。如诉诸武力、诉诸威胁、诉诸怜悯、人身攻击。

u 如：“再和我吵我把你关起来！”、“你们不能这样啊，我上有老下有小……”

u 人身攻击是指不针对某人的立场而针对某人自身所进行的攻击，常见手法：直接辱骂本人、攻击对方动机、攻击对方的言行不一致。不得不说、在法庭和政治论辩中这常常是一种很好很强大的策略，包括人身攻击的反面策略：通过让受众喜欢某人从而认同他的观点。

（对于各种谬误，感兴趣的可以参看批判性思维指南）

阅读全文…

这篇其实是《别做正常的傻瓜》第九章的读书笔记与感想。题目是：你想让朋友和员工更开心么——赠送礼物和激励员工的艺术。“道”的东西，我很怕自己理解成“术”，希望大家也不要误解如下九条。

大中之小不如小中之大：送礼的时候后，在一个不太昂贵的礼物类别中选择一个比较贵的礼物，要比在一个比较昂贵的礼物类别里选一个比较便宜的礼物收到的效果更好。比如送一条400块的围巾效果好于送一件500块的衣服，我们应该尽量找一些高级的小玩意。

有用的不如无用的：最好的礼物应该是吃不掉、用不掉、送不掉也扔不掉的东西。比如有纪念意义的奖杯，刻上他的名字，千万不要是几瓶酒这种，能喝掉、能送掉。

需要的不如想要的：你应该把人们想买却舍不得买或者想买却不好意思买的东西送给别人做礼物或作为奖励。比如5星级酒店1000块一顿的高档餐券，更多的是心理满足感。

有选择不如无选择：奖励或送礼的时候最好不要让接受奖励或礼物的人自己选择。不然的话他会有“我放弃了另外一种选择的感觉，患得患失很不爽”，经典反例就是：奖励海南游或现金2000元。

小奖不如没奖：人们做事往往是出于自己的内在动力，而一旦与奖励挂钩，就变成了一个经济交易，做事的人会开始衡量投入产出的物质性价比，所以给小奖反而不如不给奖。惩罚也是如此，小的惩罚反而不如没有惩罚。

晚说不如早说：在期待的过程中，让员工的快乐最大化，从而增强激励的效果；让朋友在期待的过程中提前享受到礼物所带来的欢愉。如比尽早宣布奖励大家去海南玩，如果可能的话，在项目开始前就给出承诺。

一次送不如两次送：如果你打算给别人两件礼物的话，那么最好分两次给。因为快乐也是边际效用递减的。（同样的道理，很经典的结论：好消息要分开说；坏消息要一起说；大好小坏一起说；小好大坏分开说。）

公开不如不公开：工资体系最好还是不公开的好，以避免员工互相比较而心理不平衡，也就不必用涨工资的方式来进行协调了，因此避免了整体工资水平的提高。有个问题我好奇很久了，但是也不好问，对于能够知道别人工资的职位，是否是通过高工资来避免他们心理不平衡的呢？还有什么其他好办法么？

涨工资不如发奖金：涨工资不如发奖金给员工带来的快乐大；同时，发奖金有比较大的回旋余地。对于这类物质激励，一般效用期比较短，发奖金是一次性的，涨工资是长期的，涨了就不好降回去，孰优孰劣一目了然。

最后记住，奖励或送礼的目的并不是真正给对方最大的效用，而是要让对方开心，并且感激和记住你。

有时候做一些项目，有一些经费，怎么花真有很大的学问，最后再强调一次吧，这篇说的是“道”，千万不要当成是“术”背下来了……

作为做产品的你，请再看一遍上述的几条，呵呵，并且请把本文标题想成“如何让用户更开心”，独立思考，批判吸收。

人治–>法治–>德治（无为而治），大公司多为第二种：法治。1和3外表很像，区别在于1无法，而3的法在每个人的心中而非纸上。这是产品和团队发展的必经阶段，我们的现状就是“1–>2”，开始规范化，正好有同学原来熟悉UML，所以大家也都开始学习一下。

UML就是统一建模语言，它试图将软件工程的过程给规范化，从产品设计的角度，我对它的简单理解就是用一系列的标准图把需求分析的过程串起来，充分体现了“字不如表，表不如图”的原则，我以单个用例的粒度为界，把相关的图为两个层面。

上层的图中，用例是最小单位，不涉及用例内部，主要有：

Ø 类图：感觉有点像实体关系图（ERD，更接近现实世界的对象，类图更接近技术实现的对象），描述系统中出现的各个对象之间的关系，以及和外部系统的关系。这是对业务领域的描述，一个外行看了以后就应该了解系统是做哪方面事情的。还是用我最喜欢的“小明去饭店”为例，画个图练练。

Ø 用例图：各个用例之间的关系（include/extend）、用例包、用例和actor之间的关系（将一组相关用例打包成一个模块，画成“用例包”）。描述这个系统具体可以做哪些事情。

Ø 状态图：表达系统里实体的状态转换，这也是贯穿多个用例的。例图里描述的就是“小明”的状态转换。

上层的图包装一下就可以生成整个产品最顶级的业务逻辑图，描述整个系统的业务层面的事情，用于商业演示。业务逻辑图的画法现在团队内也没有统一的意见，比较随意，表达清楚就行，这也意味着最难画。

现在说说下层的图，描述的是一个用例内部的事务（用例内部不一定是“单个用例”内部，也可能有用例之间的关系），主要有：

Ø 时序图（顺序图）：描述事情变化在时间维度上的先后顺序，善于表达对象（比如多个页面之间）的交互。玩的好可以完全替代UC中对流程的文字表述。

Ø 活动图（比较接近传统意义上的流程图）：描述各种动作如何引起系统变化，善于表达泳道较多、分支较多的情况。

Ø 协作图：表达不同对象之间是怎么互相影响的，这个图团队里用到的不多，就不画了，理论上他和时序图是可以等价转换的，时序图关注交互在时间上的步骤，协作图关注交互过程中各个对象间的关系。

这些图我们都是用Rational Rose画的，它最好的一个点是可以在不同层次间的图穿透，比如从用例包穿透看到用例图，再穿透进某个用例看活动图，再穿透进活动图的某一步看具体的时序图。

很多时候多种图都可以描述同一件事情，只是从不同的视角去表达一个系统，选用哪个关键是看针对特定的系统，从哪个角度来描述更容易让受众理解。另外还有表述软件实施的构件图、描述硬件结构的部署图，暂时用处不大，遵循性价比的原则直接跳过了。

融入了UML标准图元素以后，一个功能模块的PRD大约就是这样的：文档说明、类图+用例图；一个个的UC，UC里包含时序图、活动图等等。

感慨一下Rational Rose真的太强大（建立了整个软件工程的RUP，Rational Unified Process，包括分析、设计、编码、测试、部署等等一切），我想绝大多数公司应该找一个轻一点的工具，谁好的方案？

最后，再强调，工具是给人用的，如果团队里其他成员都看不懂了，学习成本太高，那一定不要强推UML，寻找合适自己的工具吧，原则很简单：把事情说清楚！

2008年夏，终于看掉了Donald Norman的《设计心理学》（英文是Design of Everyday Things，不知道怎么翻的），加上之前看过诺大师的《情感化设计》，我似乎看到了一位宗师从现实主意到浪漫主义的升华。（大师是先写《设》再写《情》的，我看的顺序反了）

《情感化设计》里面把设计的目标分为三个层次，即本能水平设计，行为水平设计，反思水平设计（有说是对应了心理学里人脑的三种不同的加工水平：本能的、行为的和反思的）。本能水平就是纯生理的视觉冲击，所谓第一眼美女，没什么好说的；行为水平其实就是《设计心理学》一书的内容了；而反思水平是大师的又一次升华，把纯心理需求也纳入了产品设计的考虑范围。

行为水平的设计，和我们现在的工作还是很接近的，能把产品做到用起来爽、贴心就已经很不错了，生活中还是有多让人不满的产品，而一般对现实不满的人都会是现实主义的。虽然大师举的都是传统产品的例子，但一些原则却是非常基础，让人印象深刻，比如：

Ø 反馈：动作前的可预测、动作中的积极响应、动作后的可评估。

Ø 容错：一些貌似多余的强制性设计，不可逆操作可以后悔，“用户没有错，所有的错都是设计的错”。

Ø 简化：充分利用用户已有的知识，利用心智模型，利用标准化，利用一切。

当一个产品在行为水平上做好以后，就可算是一个优秀的产品了，但要做到伟大，大家都发现反思水平上的情感因素变得更重要了，所谓饱暖思淫欲啊，人总是那么不知足，当现实的问题解决了，就要开始浪漫了，当然也有对现实绝望而转向穷开心式的浪漫的，扯远了。只有更进一步的让人不但用起来爽，而且想想都或开心、或伤感、或恐惧……的设计，才会华丽丽的升级为ART（这里用纯大写来表达“艺术”的牛逼），也许iphone算（有人说，所有用iphone的人都有一个特点，就是不好意思说iphone不好用，呵呵），也许一些创意家居用品算（淘宝上很多）。

不过，对于要给大多数普通用户用的产品来说，这第二、第三层次的设计还是要挨个满足的，反思的设计现阶段最多只是面包上的果酱，真的做一个没有行为水平、只有反思水平的“卡洛曼茶壶”，那也只能给闲得蛋疼的用户们去“用”了。

现阶段，还是得默念一百遍：我们是现实的设计师，不是浪漫的艺术家……

前段读了《敏捷估计与规划》，这本书很适合开发经理看，我只是很快的浏览了一下，摘录一些体会。

Ø     敏捷的里程碑是功能驱动的，先完成可交付的最“重要”功能，重要取决于功能商业价值、生命周期、实现难度等综合的结果。而传统的瀑布模型的里程碑是任务阶段驱动的，到了项目50%的时间，可能进入“编码”，但对客户来说，等于0%。而且这样的模式会陷入“实现难度决定开发顺序”的不合理模式，因为这里有个不合理的假设前提：所有功能都能够完成、必须完成，中间过程对客户是透明的。

Ø      项目估计的不确定性是会累积的，80%×80%×……，所以开始订的项目计划，在一个月后已经面目全非，强行的遵守是没有意义的，而应该不断的修正计划，当然，更好的做法是一开始的计划中间留有一些柔性的内容。

Ø   随着时间变化，必然有新的信息出现，特别是瞬息万变的互联网业界，死守着开始的项目计划不调整是没有逻辑的做法，敏捷的迭代刚好权衡了变化的成本和不变的成本，就是：不变本次迭代，更新下次迭代，这是一个将项目计划细化粒度的做法。

Ø      需求唯一不变的特征就是“不断变化”（plus不断细化），敏捷的思想就是欢迎变化，拥抱变化。瀑布模型一次性完成的需求分析，会存在“过度需求”的问题，降低整体效率。

项目管理理论的发展，从开始混乱，每个项目自有一套，每个PM自有一套；到后来人们非常想订出一个统一的简单的流程，减少人为影响（瀑布模型等出现），；再后来进入灵活的敏捷，看似又变得混乱，实则有序。又是宛如那个哲学的三段论：见山是山—见山不是山—见山还是山；也如管理的三个境界：人治—法治—无为而治。