产品设计体会(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,寻找合适自己的工具吧,原则很简单:把事情说清楚!

产品设计体会(7010)现实与浪漫

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

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

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

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

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

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

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

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

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

产品设计体会(7009)敏捷估计与规划

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

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

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

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

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

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