产品设计体会(3015)项目中Bug的一些事

项目中,测试最开始一段时间,Bug总是不断的蹦出来,Bug指缺陷或故障,区别在于项目发布之前发现的叫缺陷,项目发布之后发现的叫故障,通常故障会对用户造成伤害,团队里也制订了相应的惩罚机制。这次不妨从Bug的角度来说说项目,下图是我们使用过的一份Bug级别定义,一般来说对一个Bug的描述有以下几个关键点。

bug级别定义

缺陷级别(Severity:即上图中的5级别定义,一般大于等于III级的Bug被认为是严重的问题。

所属产品、项目:有的人需要同时处理很多产品、项目,这个属性可以用来筛选。

Bug名称:一个短句,此Bug的简单说明。

Bug描述:写成如下形式,“执行某操作,期望出现什么情况,实际出现什么情况”,还可以添加截图、文档等附件。

其实其他属性还有很多,不过我觉得非必须,经常不填,也就不说了。

我们的测试过程使用了Mercury Interactive公司的Quality Center来管理,它是一个基于 Web且支持测试管理的所有必要方面的应用程序,更小的团队,用Excel来管理Bug也未尝不可。作为PD,也是会经常提Bug的,PD做测试的时候主要是模拟用户的身份使用产品,而测试人员会更多的按照TC执行。当发现一个Bug以后,我们会提交给相应的开发工程师,如果认为是需求问题也会提交给对应的PD,这时候Bug的状态为Open,之后的状态改变,可以用下图表示。

Bug状态流转图(图中defer拼错了)
Bug状态流转图(图中defer拼错了)

收到OpenBug,确认并修复,状态变为Fixed;否认,也许提出者理解错了,也许不打算修改,状态改为Rejected;或者认为不是自己的问题,可以把Bug转交(Assign to)给别人。

测试验证状态为FixedBug,没问题了就Closed,否则可以Reopened。看到RejectedBug,发现是自己理解错了,就可以Closed,仍然认为是Bug的可以Reopened。对于DeferredBug,意味着本项目中暂不修正,可能是因为技术做不到,时间不允许,性价比太低等,必须慎之又慎,通常由能负责的人,比如是测试经理、项目经理最终同意才Deferred

整个过程中,Bug的每次状态改变都可以添加注释说明,我们更鼓励有争议叫上当事人面对面的交流,而不是在系统里不停的纠缠。

到了项目发布之时,我们要求所有Bug的状态必须是Closed或者Deferred,当然对III级的Bug,有时候并没有这么严格。

使用Quality CenterExcel的好处,在于每个Bug重要的状态转换点,系统都会有邮件通知到相关人员,防止遗漏;项目中每个人在系统里的角色不同,权限不同,防止误操作,甚至一些恶意行为,比如开发人员就不能把Bug状态改为Closed;所有操作都有记录,谁在何时做了什么,便于追溯。这些都有效的防止了人为因素导致的问题。

PS:很久都不发带图片的文章,是因为picasa,我终于打算放弃,转投flickr了。。。

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

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

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

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

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

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

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

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

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

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

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

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

产品设计体会(7017)《流程管理》培训记录

2008年秋参加的,全称是《市场驱动的产品开发流程管理》,记录一下,先归纳一下整体的内容,然后再说几个专题。

Ø  大思想:

n  管理是一门科学(法治,规章制度,合适中公司)也是一门艺术(通俗的人治(从外向内的推动),领袖魅力,适合小公司;高雅的德治(由内向外),企业文化,适合大公司)。

n  路况(软硬件环境)与开车水平(个人能力)要求成反比,流程的目的就是改善路况。

n  公司战略–>产品战略–>产品路标规划–>计划。

n  公司战略推动:流程、组织、IT为骨架,并由激励机制保证。只有流程而没有与之配套的战略、组织、IT、激励等,就好比没有爱情的婚姻不能长久……

n  凡事的三个凡是:必计划、必评审、必文档化

Ø  最多传统行业的一次培训,都是中年人,-,-bbb,传统行业的流程明显细化了很多,比如奇瑞汽车的项目过程中有两三百个评审点,此外采购、物流等实体工业特有的元素也让他们的产品开发过程复杂了不少,当然也有相似之处,比如:

n  制造业的样品,类似我们的Demo

n  小批量试产,类似部分用户内测。

Ø  项目与生小孩:

n  生小孩容易养小孩难,不但培养成功很难,而且弄死他也很难,而且越往后越难,毕竟人是有感情的……

n  所以要少生优生,不幸多生就要排定优先级,不能 “会哭的孩子有奶吃”,而要“劫富济贫”(把资源投入到回报最大的小孩身上)。

n  小孩小的时候容易教容易影响,所以高层要尽早参与项目决策。

n  情感因素会与业务需求矛盾,越高层遇到的这种矛盾越多,所以好老板都不是“好人”。

Ø  项目管理与流程管理:项目管理是独特工作,风险大,效率低;流程管理(有点向运作型管理,类似的项目做多了就会出流程,据说华为员工去世的处理都有流程……)的是例行工作,风险小,效率高。

Ø  产品开发流程的最简模型(普适的),各阶段的关键词:

n  概念:启动,目标管理(SMART),业务需求,DCP1(商业评审点,Decision Check Point)。

n  方案:立项,外围组(一些非关键成员,执行层面)加入,规格、计划,DCP2

n  开发。

n  验证:测试,DCP3

n  发布:项目团队解散,成立LMTLife-Circle Management,老人带新人做这个来锻炼比较合适)。

n  生命周期维护:DCP4

n  前面两个阶段需要高手做,进入第三个阶段,高手应该去做新项目,引出“管道管理”。

继续,一点和组织有关的内容,组织是对流程的支撑。

Ø  最简项目组织结构(PDT):督导组(PAC)、Leader、核心组、外围组。根据产品性质,结合公司组织结构决定核心组成员,有能力、有权力的人要加入核心组。督导组是核心组所涉及部门的一把手,这样才能给核心组成员授权。

Ø  职能型组织/项目型组织/矩阵型组织:

n  职能型组织适合计划经济,有利于同类资源共享,互相学习提高,但各部门目标不一致(个人目标、部门目标、公司目标容易不一致),只对“上面”负责(唯一的客户),没有人对客户负责。

u  小段子:修高速公路最难的是拆迁问题(个人最优与集体最优的矛盾,没办法的,必然是在什么山头唱什么歌)。

u  团队同学们认为,这比较适合运作型的公司,人真的可以当作可替换的“资源”。

n  项目型组织正好相反,会资源浪费。项目发展下去就是事业部–>分公司。

n  矩阵型组织,一条是产品线、业务线,为了对客户负责;一条是资源线、行政线,为了资源共享。缺点:考核困难,要建立对事负责的文化。

n  权责利匹配,谁负责谁决定,谁执行流程谁制定流程,让着急有用的人着急。

n  职能(角色)与职位(人)的关系,一个人可以承担多个角色,一个角色也可以多人承担。

Ø  项目经理与部门经理兼任带来的问题:

n  管事,短期,有成就感,“猎人”,对打仗负责;

n  管人,长期,有权力,“农民”,对练兵负责,贡献技术与人;

n  部门经理如兼任项目经理会用权力来寻求成就感,从而放弃农民的责任去做猎人,短视。

n  推论:职能型组织变革,相当于剥离部门经理的成就感,所以会遇到有权力的人的阻力。

n  考核应该项目经理提供建议,部门经理决定。

Ø  公司变革必然要有人流血牺牲,所以变是找死,但不变是等死。如果要变,一把手必须亲自做,各层次执行流程的人亲自制定流程,有痛苦才会珍惜(对于请来的咨询公司而言,答案早已经有了,但就是要有一个过程让这个公司里的相关人员自己把答案说出来才有用)。并且向流程制定小组中派“政委”来掌控这个过程。

最后一部分,说一些评审的话题,再罗列一下我记的一些有意思的句子。

Ø  商业评审与技术评审:

n  参加评审的人都要承担相应的责任。

n  商业评审(决定做不做)与技术评审(决定怎么做)两者必须分开,否则陷入细节,技术人员受打击,领导变昏君。

n  商业评审的一大目的就是砍项目(决定继续、终止、重新定向),类似与我们的产品例会,BRD评审以及开发完成以后的“演示会”。

u  商业评审是分阶段分发资源的时间点,通过的项目发放到下一个商业评审点之前的资源。

u  小段子:决定玩21点(启动项目),每一张(设立评审点)看(评审动作)一次,再决定是放弃还是继续。

n  合理设置商业评审点,并且两点之间要“将在外君命有所不受”。

n  想要评审不走形式,就必须把评审会变成形式。

u  事情做在前,提前发邮件材料,电话确认(邮件收到,附件能打开,图能显示……),约面谈(分别串供)。

n  技术评审类似我们的UC评审、设计评审、TC评审。

n  技术评审的三个决定:GoGo with risk(有风险的继续)、Redirect(必须要解决某问题后再继续)。

n  反例:技术评审三部曲——抓壮丁(随便找的有空的人来参加)、科普会(来的人根本不了解情况)、批斗会(争论……)。

Ø  零散的句子:

n  “取其精华,去其糟粕”,但是多数情况我们无法分辨精华与糟粕(上海地铁1号线与2号线的例子),所以不如“先僵化、后优化、再固化”。

n  土匪与游击队的区别在于将来他们有没有成功,失败了就叫土匪,成功了就叫游击队。

n  个人能力关键部门:研发(基底)、销售(体会乙方)、采购(体会甲方)、售服(练心态)。

n  研发人员要有成本意识,不要盲目创新。

n  当需要某种技术时的思路:一买(用现成的)二包(外包)三开发(自己做)。本质上还是基于成本的考虑,中国的国情下,说不定自己做更便宜……

n  著名先烈Motorola:技术开发强,产品开发弱。发明了很多,后来都是别人商业化的好。

n  产品开发是一个投资行为;产品开发是一个端到端(起:从客户中来;止:到客户中去)的流程;产品开发不只是研发部门的事情。

n  产品与样品:样品是做出来就行(很像实验室的行为),产品需要考虑经济效益。

n  协调是非增值的工作。

n  大会(应该是指人数多少吧)决定小事,小会决定大事。

n  小段子:硅谷的ICIndian软件强,Chinese硬件强。

n  流程结构的轻重,只能通过试错来找到平衡点。

n  新人做老产品(新人不挑活,老产品不容易出事),老人做新产品(老人需要激情)。

n  太贱的东西不适合直销。

n  信息充分的情况下,随着项目进行风险应该越来越小,否则项目必然有问题。

n  激情来自于变化,看来价值观中拥抱变化和激情其实是一条。