产品设计体会(5007)如何让团队更开心

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

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

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

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

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

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

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

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

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

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

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

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

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

产品设计体会(7011)UML学习摘录

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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