Back to Basics

Back to Basics

回归基础

Normally I focus on the product definition aspects of creating successful products. My reasoning is simple: it doesn’t matter how great a job you do in building your product if it isn’t the right product. That is really the role of the product manager; to define the right product at the right time.  However, there is one little detail that too many product teams seem to miss, even when they define an otherwise excellent product. That is, the product has to actually work.

通常我专注于创建成功产品的产品定义方面。我的原因很简单:如果你构建的不是一个正确的产品,无论你所做的工作多么了不起,都是没有意义的。产品经理的真正职责是:在正确的时间定义正确的产品。然而,有一个小的细节看起来被许多产品团队所忽视,尽管他们定义了一个非常优秀的产品。也就是说,这个产品必须确实可行。

I wish that by now, after roughly 30 years of modern software development, we wouldn’t have to keep talking about this, but in truth, while there are many notable exceptions in well-run companies, the state of software quality in general is still awful. During the boom times of the nineties, when Internet sites were developed and launched in a just months, with little concern for quality (just call it a beta!, this was an especially severe problem. ) Things seemed to get better for a while, but now I fear we are on a downswing again.

在现代软件开发大致经过了30年后,我希望到现在,我们无需持续讨论这个问题,但事实上,软件质量的状态还是普遍糟糕,虽然在一些高水平的公司有一些例外。在90年代的整个繁荣时期,互联网站点在数月内就开发和发布出来,在这个过程中很少关注质量(仅有beta版本,这是一个相当严重的问题)。在一段时间内,一切都看起来变的不错,但是现在我担心我们再次处于衰落。

I have pointed to new products and sites almost daily, and I get so frustrated when the quality issues are so bad that they completely obscure what great innovations or contributions may lay behind them.

我每天都指出新产品和站点因为质量问题如此糟糕而完全掩盖了伟大的创新和贡献,这使我感到很无奈。

Largely this is due to the general state of software QA (quality assurance) in our industry. There is a huge chasm between best practices and common practices. For engineering teams that know how to design and build for automated testing, and know how to measure quality and ensure against regressions, the tools and practices are well established and the results are real.

很大程度上这是由于我们这个行业的软件QA普遍的情况。在最佳范例和习惯做法之间存在巨大差距。工程师团队知道如何设计和构建自动化的测试,知道如何检测质量和确保回归分析,这个工具和实践都得到了很好的设置,结果是真实的。

The problem is that far too many teams still are doing little better than was done a generation ago.  Testing is all too often still manual, the priority of the testing is so low that it is the first thing to get cut in the rush to launch, the QA organization is understaffed and especially undertrained.  The logic goes like this: this site is for teenagers, so let’s hire some teenagers to run through the site and find bugs. I am all for giving teenagers jobs, but a) this is no substitute for the knowledge of how to systematically and rigorously ensure that a release of software meets the specifications; and b) manual testing quickly breaks down when you are turning out new builds faster than you can manually test the product (which today is almost always the case).

但问题是,太多的团队做的还不如上一代。测试通常依赖人工,测试的优先级是如此的低,以至于首先被砍掉而为了匆忙的发布,QA组织人手不足,尤其是缺乏训练。逻辑看起来就是这样:网站是面向青少年的,因此就雇一些青少年来使用网站并发现bugs。我的一切工作都是为了青少年,但是a)如何系统地、严格地确保发布的软件是符合规格的知识是不可替代的;b)当你开发出比你现在人工测试产品更快的方法时,人工测试很快就被中断(现在总是发生这样的情况)。

Typically, the product manager worries about the spec, and the engineering manager worries about delivering a quality implementation of that spec. However, the product manager is ultimately responsible for the success of the product, and if the quality is so poor that the user experience is severely impacted, then it is essentially the same problem as if the features are the wrong ones.

典型的情况是,产品经理考虑的是规格,技术经理考虑的是交付一个达到质量规格的产品。然而,产品经理要对产品的最终成功负责,如果质量太糟糕,UE就会受到严重影响,从本质上来说,这是同一个问题,就像把特点弄错了一样。

This doesn’t mean that the product manager needs to micro-manage QA, but it does mean that the product manager needs to take a very active role in defining release criteria, including and especially software quality. There is nothing wrong with the product manager asking his engineering or QA manager colleagues questions about the QA staffing, funding, and testing process.

这并不意味着产品经理需要QA的微观管理,但是这意味着产品经理需要扮演一个积极的角色,在定义发布规格,包括,尤其是软件质量。产品经理向他的工程师、QA经理询问QA配置、预算和测试进程的问题都是毫无疑问的。

The irony is that too many engineering teams still believe that modern software testing practices cost more money or take more time than doing it manually. If done properly, you will find significantly faster time to market, more productive QA staff (with greater job satisfaction), and most importantly, a much better user experience.

具有讽刺意味的是,太多的研发团队仍然相信现代的软件测试实务要比人工花费更多的钱和时间。如果操作正确,你会发现上市时间明显加快,QA团队更有生产力,最重要的是,UE会更好。

Most types of software don’t need to be perfect, but remember that it’s all about the user experience. If the product is a mess, with bugs constantly getting in the user way, then your product will suffer. If this is the situation you face with your product, you will need to argue for fixing the problem at its core, investing in QA staff, tools and process, and prepare to trade off some new features you want so that your engineering team can have the time to clean up the product.

大多数类型的软件并不需要完美,但是请记住,这一切都关系到UE。如果这个产品一团糟,在使用过程中不断出现bugs,那么,你的产品将受到损害。如果这是你面临的产品情况,你将需要在它的核心,QA成员上的投入,工具和进程上论证确定这个问题, 并且准备着去掉一些你想要的新特征,以便你的工程团队有时间去改善产品。

(Can you tell that I just wasted several hours doing battle with a product from a company that clearly has no clue? 😉

(你能说,我刚刚浪费了几个小时和公司一个线索混乱的产品战斗?)

Let’s hope that someday soon a note like this will no longer be necessary.

我们希望在不久的一天象这样的便条不会有存在的必要。

分享到QQ 分享到微信 分享到微博

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址