Vamos revisar o processo!

Recebi há pouco um e-mail muito legal da STP, com o artigo Is QA About People or Process?. Colei o artigo no final do post para quem tiver interesse.

Achei muito interessante o questionamento feito sobre controle de qualidade. Temos um bug em produção! Vamos rever o processo! :)

O processo de uma empresa deve ser algo vivo, ou seja, deve estar em constante aperfeiçoamento e sim, bugs e métricas relacionadas a esses bugs (bem como outras métricas e outros inputs) são utilizados como base para essas melhorias.

• Se minha empresa tem um processo maduro, então os softwares produzidos por ela serão sempre de excelente qualidade?
• Se minha empresa não tem um processo maduro, então os softwares produzidos por ela serão sempre de baixa qualidade?

 O que é processo afinal? Será que posso dizer que tenho um processo porque desenhei algumas caixinhas de workflow?

Falta ai uma consideração muito importante: pessoas!

São projetados procedimentos a serem seguidos, mas são pessoas que os vão seguir e onde temos pessoas, temos suscetibilidade a falhas. E nem todas as falhas devem necessariamente ser motivo de revisão no processo.

No artigo abaixo, Edward faz uma comparação interessante entre indústria de manufatura e de software e a aplicabilidade de modelos de qualidade nesses ambientes.

Is QA About People or Process?
By Edward J. Correia

Any time a defect gets through to production, companies have a tendency to reexamine their processes. “If we had tighter processes in place, this would not have happened,” is usually the thinking of management. If you deal with product quality, perhaps your reaction was something like, “Here we go again.”

But is quality control really about process? Can an air-tight process make up for sloppy, apathetic, or time-constrained people? Or, can a meticulous person assure quality despite controls that are less than perfect? Are people or processes most responsible for good quality?

Obviously, quality assurance involves a combination of the two. But according to V. Viswanathan, a quality analyst with international IT services company Virtusa, the answer might also depend on the industry. Having worked in manufacturing as well as software development, he believes that project-related endeavors like software development tend to be person-centric, whereas the manufacturing industry centers on process. “The amount of savings and benefits that occur in the software industry due to process improvement activities may not be really significant,” he says, whereas the Six Sigma process is a cornerstone of manufacturing.

“Six Sigma is mainly applicable to industries where operations or activities are identical,” he points out, hardly a characteristic of software development. “I don’t mean that Six Sigma is not applicable to software development. But by applying Six Sigma, drastic benefits may not be achieved as those that occur in the manufacturing industry."

Part of the Six Sigma strategy for business process improvement is to identify the root cause of a problem and then find and implement a solution. “In order for Six Sigma to be most effective, the operations have to be repeatable,” says Viswanathan. Hence, individual talent plays a far smaller role in manufacturing than in software development. Some of the differences include the following:

In manufacturing, each product is intended to be identical; in software development each product is customized (otherwise there would be nothing to develop).

Processes in manufacturing are the same for each operation; processes in software development vary in terms of content.

Most manufacturing workers perform at a similar level of effectiveness; software development workers’ abilities vary widely, as do their levels of skill and effectiveness.

As is true of many creative activities, the content involved with software projects can vary wildly, and operations related to application development will vary accordingly. “In software, the operations across projects might be similar, but are not identical. You may have the same set of phases…requirement analysis, design, coding, testing, and implementation… between projects. But the details of each are different,” he says.

Therefore, activities that you might have implemented to improve a process or solve a problem in one project may not be valid for another. “Also, the level of success might be different. Even if it is applicable, the consistency of success cannot be maintained across projects,” says Viswanathan. What’s more, errors are inevitable whenever human input is involved. And the places where errors turn up cannot be predicted. Such relative chaos is anathema to manufacturing, which relies on predictability and consistency for maximum output.

Each According to Ability

Perhaps the biggest difference between the software office and factory floor is the way in which each makes use of ability. A nimble factory worker might produce one percent more widgets and be less prone to injury than someone who is clumsy. But a skilled developer can become the basis of an entire industry (think Linus Torvalds).

The most effective software development team is one that combines skilled, competent and caring workers with solid, logical processes that work well and make sense to all involved. Because without buy-in from the team, your processes are not worth the paper they’re printed on.