【3019】为什么不开除测试,让用户来

前些日子,在知乎上看到一个很有趣的问题:

 

为什么互联网公司不开除测试,转而让大众来测,找到一个Bug给100元?我一时脑洞大开,请做测试的大牛来说道说道。

为什么不开除测试,让用户来
为什么不开除测试,让用户来

 

回答的讨论也很有意思,有不少都是围绕“100块够不够、给不给、怎么给”来说的,我的角度是,测试绝对是产品团队里一个重要的角色(注意,不是自然人,创业团队可能就是产品经理来做这个角色),没了他们还真的不行,回答如下:

 

  • 默认前提是,开发已经做了单元测试冒烟测试(原则上冒烟应该测试来做,但,人家都被你们开除了啊,只好让开发来做了,至少保证交给大众的是一个能跑起来的产品),这两项总不至于期望大众来帮忙做吧;
  • 很多Bug其实并不是非此即彼的,产品就这么设计的,内部的测试知道,但外部的大众不知道,觉得用的不爽,提了,这钱是给还是不给?哪怕公司内,测试发现此类问题(比如为了安全考虑,密码第二次输入确认的框不允许复制黏贴),开发说这是一个需求/特性,大家还得再把产品叫过来一起讨论下,外部可做不到;
  • 专业的测试是需要测试用例(Test Case,更不要说TC评审了)的,常见的测试用例(临界值相关、内存会不会泄露、特殊字符什么的……专业测试玩起来一套一套的,分分钟把开发认为没问题的程序搞挂),在大众那里可没有,不踏实,感觉……有点像西医和中医的区别,敏感话题不展开;

 

  • 专业测试提的Bug是分级的(成熟的产品也应该分级标准和规范),几级以上必须全部close才能发布什么的,开发也会按照级别来确定修复顺序,大众提交上来的,还得安排人去分级review;
  • 专业测试会把Bug指定给特定的开发或产品经理,背后的逻辑是知道技术角度的模块划分,以及对应的负责人,方便流程往下,大众提交上来的,还得安排人去做assign to这个动作;
  • 专业测试懂得用开发明白的语言描述,说清楚是什么机器、什么系统、什么版本……特别是“如何重现”这件事,大众提上来的,Bug重现不了,急死你;

 

  • 内部经常有针对Bug的讨论,部分Bug可以defer或reject,那么问题来了,谁来牵头组织讨论,确定Bug状态的流转与控制?可不要指望大众会“跟进”自己提交的Bug;
  • 如果开发比较牛逼,理解了,修完了,是否修复的验证谁来做,谁来close这个Bug,确认修复?整体的回归测试谁来做?

 

  • 以上还只说了狭义的功能测试性能测试压力测试怎么办?大众没法帮你模拟10万人同时XXX;还有,自动化测试谁来做?
  • QA相关的还没说呢;

 

  • 其实,这个在方法论里面接近于“UAT,用户接受度测试”,有的也叫验收测试,经常由产品经理代表用户做(当然,有资源最好让用户亲自来),不是找Bug,而是看产品是否满足用户需求、设计是否符合用户认知什么的;
  • 这事儿很好,有条件都做吧,但更多的目的是找个理由和用户互动;

 

好问题,帮我复习了一遍和测试有关的概念,暂时想到这么多,大家可以补充。

对了,近期iamsujie.com做了改版,大大提升了移动端的阅读体验,欢迎尝试。

iamsujie 微信公众号二维码
iamsujie 微信公众号二维码

【8036】重构产品部门组织结构

一句话点评:组织结构会影响人们的行为。只要角色定位准确、管理方式得当,大多数的组织结构都是可行的,如果贵公司的组织结构和任何理论推荐的不同,公司却运转良好,建议你保持这种结构不做任何改变。

Marty Cagan发表于2008416日,原文链接,译者:潘希颖 / 审校:姜沈励 林航 徐定翔

我曾讨论过产品组织中的几个关键角色(包括产品经理、项目经理、交互设计师、视觉设计师、可用性工程师、原型制作人员、工程师、架构师、测试人员/QA和产品营销人员),以及这些角色之间的关系,然而如此复杂的组织结构依然会让企业摸不着头脑。

虽然每个产品组织的组织结构各不相同,但我认为,在过去的几年内,已经出现了一个标准的组织结构。而它的出现存在其合理性。

其实,组织结构并不是我关注的重点,我对组织中各个角色及其相关职责的关注程度更高。我相信,只要角色定位准确、管理方式得当,大多数的组织结构都是可行的。而且我认为,与其照搬一个成功企业的组织模式,不如根据领导团队的特点定制一个更加符合企业自身情况的产品组织。

我们都知道,组织结构会影响人们的行为。在其他条件不变的情况下,如果依照下述方式改变公司的组织结构,会收获到意想不到的好效果。

我这里讨论的对象是产品部门,并不涉及公司其他部门,比如销售、客服、财务、业务拓展及IT(非产品开发)部门。

我认为CEOCOO,以及子公司的总经理都需要将他的员工明确地划分至三个部门:营销、产品管理及设计、产品开发。并保证这三个部门同属于公司组织结构的最高一层,而不出现其中一个部门隶属于另外一个部门的情况。
建议一个中小型公司的CEO/COO,或者大公司的业务经理将组织结构做出如下安排:

营销部门包含其企业营销(corporate marketing)、营销传播(marketing communications)、现场营销(field marketing)、产品营销(product marketing)。

产品管理及设计部门负责产品管理和用户体验设计(交互设计/信息架构、视觉设计、原型制作、用户研究/可用性开发),如果条件允许,该部门还可引进行业专家。

产品开发部门主要负责产品架构、代码编写、质量测试、产品发布、平台运营(SaaS软件运营公司)和项目管理(PMO,项目管理办公室)。

注释:

为内部员工技术服务的IT部们有别于产品开发部门。这点在以后的文章中我会详细描述。在此,我只强调一下,这两个组织在需求上有本质的区别,因而管理方式也该有所区别。通常是由首席信息官CIO管理IT部门,而由CTO(首席技术官)或 VP(产品开发副总裁/工程部副总裁)来负责管理产品开发部门。

在某些公司将PMO(项目管理办公室)作为最高级别的管理部门,这本身没错。但多数时候,PMO是产品开发部门的一部分,因为项目经理管理的大部分资源 都在产品开发部门里,因此产品开发负责人会全权负责产品的实施与交付。但不管在什么情况下,项目经理还是直接受项目管理办公室管辖。

不管将用户体验设计归入营销部门还是产品开发部门都会产生问题。用户体验团队(特别是交互设计师)和产品经理就应该是拴在一根绳上的蚂蚱。为了使产品经 理与用户体验设计团队的合作更加紧密,越来越多的公司选择将产品管理和产品设计合并为同一个部门(但每个职能都有各自的负责人,如产品管理总监负责产品战略,用户体验总监则负责平台/软件的整体信息架构及风格)。

在营销部门里,通常也会有一些负责营销项目和广告的图形设计师。用户体验组织中的视觉设计团队可能也能满足营销工作的需求,但我觉得在营销部门设立这样的职位会更好。强大的用户体验离不开对交互设计的持续关注和对应用程序的可视化设计。而这些图形设计师的领导者则应该清楚如何为产品团队提供支持。如果你的创意总监是产品类视觉设计和营销类视觉设计的双项全能,那么你的公司就有福了,因为这样的视觉设计团队可以同时满足两种设计需求,所塑造出的品牌形象的也会非常一致。但是,如果视觉设计团队负责人隶属于营销部门却不了解产品的需求,就必须尽快做些改变了。

不要把用户研究和可用性研究混为一谈。用户研究是以人口统计学和消费者行为学(包括购买模式)为基础对客户进行分析与研究。因此,只要产品经理和交互设计师能随时找到用户研究人员,且相互之间建立了良好的工作关系,就可以将用户研究作为营销活动的一部分。而可用性研究是对人物角色、原型,以及如何让用户能够方便地使用产品进行具体的研究。与用户研究不同,可用性的研究成果会直接反馈给交互设计师、视觉设计师和产品经理。因此,可用性研究人员是用户体验设计团队不可或缺的一部分,只有这样,在研究产品的过程中,他们才能更好的与其他成员合作,他们的研究结果才能更好更快地反馈给相关人员。

有的公司将产品营销归为产品部门。这种结构不会产生大问题,没准还有一定的优势。但我还是认为将产品营销独立出去会更好一些,因为这样营销人员对自己的角色定位能更加准确,产品管理和产品营销之间的职能划分也更为清晰。但即使产品管理和产品营销同属于一个部门,也不应该将各自的职责混为一谈。

创业型公司的组织结构通常比较简单,因为相对于组织结构而言,公司更看重个人能力。可一旦公司走上正轨,进入快速发展阶段,尽早采用有效的组织结构会是明智之举。

如果贵公司的组织结构和我推荐的不同,公司却运转良好,建议你保持这种结构不做任何改变。但如果你的团队挣扎在痛苦的边缘,好产品的诞生比预计的要困难,就可以考虑将组织结构朝上述方向改进一下,看看会不会有所改善。

特别感谢Chuck GeigerKyrie Robinson对本文的贡献。

P.S. Marty Cagan将出席PM-China首届产品经理高峰论坛,然后,我可能会客串一下主持人,呵呵,详情请见:http://www.pm-china.org

本文节选自《启示录:打造用户喜爱的产品》一书作者的博客。该书从人员、流程、产品三个角度介绍了现代软件(互联网)产品管理的实践经验和理念。特此感谢Marty Cagan先生授权。