产品设计体会(3000)项目与文档,系列说明

2007年底之前,也就是开始做产品设计师约1年以内,我一直只是很单纯的在做产品设计、以及大产品设计,在为产品所发起的一个个项目中,扮演的是一个设计师的角色,主要负责“做多少、怎么做”的问题,那会项目经理是开发经理兼任,他负责“何时做、谁来做”的问题。

后来公司发现这样的一些弊端:

对设计师的考核是产品的商业价值,比如用户活跃度等等,而这些指标和产品的用户体验关系极大,大家知道,想把产品的用户体验做到极致,让用户轻松,必然的代价就是我们受罪,特别是开发的同学要额外做很多他们看起来价值不大的细节,比如一个最简单的登录页面上的2个输入框,一个填帐号,一个填密码,想体验好一点,就要考虑如何限制输入内容长度,如何控制输入非法字符,如何给用户提示等很多问题。简单说一下输入帐号的长度控制问题,就又要考虑是点击“登录”提交表单时判断?鼠标焦点移动到密码输入框时判断?还是输入帐号时随时计算长度直接判断?……

开发同学的考核一般来说是项目的完成情况,Bug数量,很显然,如果他们做项目经理,矛盾就自然而然就发生了,开发的同学会倾向于简化项目,尽量少做、做自己熟悉的,使得项目顺利完成 & bug很少,但是做出来的东西商业价值不足、用户体验不好。

由于上述原因,公司决定让产品设计师兼任项目经理,这样对我们的要求就更高了,于是我也渐渐的有机会接触了项目管理方面的事情,发现这块“硬功”也是一个产品设计师必备的素质,于是,我们向着全能战士——产品经理,又跨了一大步。

话说一个事物必然有它的两面,如果你只看到了一面,必然说明你只看到了系统的一部分,我还是比较相信在哲学层面上,很多东西都是“守恒”,或者说“对立统一”的。那么这么做的缺点又是什么呢,留个悬念,后续在一些有关组织结构的文章里再做讲述。

回到本系列,先谈论了做产品与做项目的异同。在做项目的过程中,我体会到创业公司,或者大公司里的创业型团队,特别是对于互联网、软件行业,有一颗敏捷之心很重要,所以这部分里有不少关于敏捷的描述。此外举例了适合创业型团队的项目管理方法中的几个关键点,比如Kick Off评审会,最简单的一句:计划与控制,就是项目管理。

大大小小的项目做了几十个,自然的发现另外2点提高效率的事情:流程与文档。

流程的作用,是把经常做的事情固化,以提高效率,下文有例子描述了简单的需求流程,再举个不好的例子,如果阿里有一位同事不幸去世了,那公司一定会起个紧急项目来处理这件事,而如果是华为,就可以走流程了。项目与流程是对立统一的关系,并且可以互相转化,后面也会仔细描述。

文档管理主要谈到了两块:一是模板管理,文档为什么要有模板?我们有哪些常用的文档模板?各个模板的目的是什么?相应的又应该怎么设计?举例说明了一些文档具体应该如何写,已经贴出来的有最最常见的UC;二是版本管理,提到了版本管理的目的,有哪些常用的版本管理方法及其优劣,顺便讨论一下文档轻重的问题。

这个系列还没有结束,这篇算是一个阶段性小结。

产品设计体会(3011)产品文档规范

我基本每隔几个月就会整理一次团队的产品文档规范与模板,然后release一个非常轻量级的文档包,起个酷点的名字:PD_std_template_tool_kit.mmap,这次讲讲理好的mindmanager图:


====== 看不清猛击图片看大图 ======

Ø 需求管理类

n 用户调研模板,调研前、中、后都要做什么,调研问卷怎么设计。

n 功能列表极其管理方法,这里可以体会到团队协同工具的重要,我们用过office liveexcel,比较简单。

n 产品的网站页面地图,这块让UE的同学帮忙这里更合适。

Ø 项目管理类

n 项目管理制度,原则性的东西,比如项目经理、开发经理、测试经理的权责利。

n 项目任务书,网上有很多模板,小项目可以灵活变通。

n 项目Kick Offppt,之前有说过这个话题

n 项目组织结构,省时间的,以后每次填名字就可以了,没啥技术含量。

n 项目WBS,我用的是一个小软件“WBS Chart Pro”(奇怪我搜不到下载了,需要的可以问我要),只有几M,它做的图可以生成project文件,就是说项目计划也有了。(我不喜欢动不动就几百兆的软件,而对于几M就能实现大部分功能的小软件特别有好感,呵呵。)

n 项目日报,主要有今日要闻,明日看点,当前问题,所需支持,项目进展等几项。

n 项目发布通知,为了省时间而已。

Ø 流程管理类:小团队常用的有日常发布流程紧急发布流程等。

Ø 商业需求类:BRD,参见4004

Ø 产品需求类:PRD,参见3010

Ø 需求规范类:

n 交互规范:控件规范,如列表的默认排序、列表中文字的对其方式,手头这个产品是“文本左对齐、时间居中、数字右对齐”;判断规则规范,包括字段的校验规范、系统反馈的规范等等。

n 视觉规范:整体的如页面大小、字体字号颜色编码。

n 文案规范:如语言风格、语法模板、常用操作的标准说法等。

Ø 日常工作类,暂时只整理了会议记录模板和日报周报模板。

另外还有很多文档,比如开发规范,会说一些代码的规矩,函数命名规则等等,PD接触的不多,我也太懂,就不扯了。

网上不少同行前辈讨论过产品文档、规范应该什么时候整理,我个人的感觉是产品1.0发布以后,2.0发布之前。一般互联网产品在1.0之前都是急行军,顾不上文档,而在做1.11.2的时候往往有一个设计工作的缓冲期(一方面是开发测试忙着应付扑面而来的线上故障、另一方面是PD需要收集反馈以确定下一步方向、团队也会做人员调整),所以这个时候做产品文档规范,总结第一代产品、第一代团队的工作,对提高后期的效率是最合适的。当然,这个工作也是应该采用迭代的方式进行的,无需也做不到一蹴而就。