In this text I'd like to introduce you to product peer reviews.
And then follow up with specifics on the various areas of the process
and then describe in detail product peer reviews as they can be carried out
in the two industries that I happen to work in:
- Software Development
- Market Research
Note, however, that I'll be talking here about product reviews (of documents, code, etc.),
not about reviews of scientific papers. Also note that I wrote "product" reviews above,
since I'm convinced that these need not necessarily be limited to technical or engineering industries,
but could be implemented in other business as well (as I describe in the sequel on market research).
First, let's talk about deliverables.
By deliverable here I mean any piece of work that is later used by other parties,
be it other teams members in your company or by external clients.
Thus, from here on, I will be referring to all receivers of a deliverable as "clients".
Also, I'll be talking only about "soft" deliverables, such as documents, code,
questionnaires, reports, requirements, design documents, test plans, presentations, etc.
Next, it may be worthwhile to briefly describe faults and quality gates.
A fault is a mistake in a deliverable.
Depending on the type of the deliverable, these can be bugs in code,
missing requirements, incorrectly defined filters, but also such trivial things
as spelling and grammar mistakes (especially in reports, presentations, help documents, etc.).
A quality gate is a phase/activity in the product development process
that signs off a deliverable as ready to be delivered to a client (in the broader sense of the word).
For instance, software design documents are reviewed
and are handed off to software developers for coding
after they are deemed as correct and ready to be used
in the next phase of the product development lifecycle.
Or a questionnaire is reviewed and passed on to the fieldwork department
after we make sure that it is constructed correctly, will answer all the needs of a research projects, etc.
What's important here is that often different people are involved
and different tasks are carried out before and after a quality gate.
Thus, a fault can be split into two categories:
- error: created and found in the same phase, before passing a quality gate,
- defect: created in one phase, but found in another phase; that is, it passed at least one quality gate.
Since faults are easiest to fix in early stages of a product's lifecycle,
we would like to have errors instead of defects (well, it would be best to have neither, but that's rarely possible).
If a fault escapes a quality gate, fixing that fault usually consumes more resources than when it is still an error,
since it usually involves people from other departments (who, for instance, already moved on to other tasks)
and often takes the development process a step back.
So what are product peer reviews?
These are a phase in a product development lifecycle dedicated to finding (and fixing) errors,
conducted by a team of peers.
The purpose here is to find faults as early as possible in the product development lifecycle.
Although we can find defects during reviews, that is not what reviews focus on.
According to various research, peer reviews are very good at finding certain kinds of errors
(different kinds in the various types of deliverables).
Now, that doesn't mean that errors of all kinds will be caught by such reviews -
there are whole classes of errors that can be verified automatically
but are very difficult for people to spot, for instance.
Apart from verifying quality of a product,
peer reviews bring several other improvements to the development process:
- get to know, share, and work on company standards,
- get to know other products better,
- share knowledge and experience with your peers,
- get to know your coworkers;
reviews ARE a social occasion and allow people to meet many coworkers at a company.
Although none of these are what reviews focus on,
nevertheless these are very important from the perspective of building experienced and well cooperating teams.
Shortly, I will upload texts on roles and perspective in reviews,
and I'll try to show various pitfalls that make product peer reviews a burden
instead of providing an effective means of raising the quality of your products.
Top
|
Texts
