O universo da tecnologia da informação é repleto de processos. Temos processos para desenvolvimento de software, prestação de serviços, gerenciamento de projetos (específicos ou não de software), garantia de qualidade e até para preparar o cafezinho da cozinha.
Note que não estou me referindo exatamente a modelos de processos como waterfall (cascata), iterativo, incremental, evolucionário, espiral e de prototipação, nem de metodologias ou frameworks de processos como Scrum, XP, RUP, ITIL, COBIT, CMMI ou MPS.BR. Todos estes possuem seu valor e nos dão uma base para definir o processo que adotamos no dia-a-dia nos mais diversos aspectos, incluindo artefatos, atividades e boas práticas fundamentais.
O foco deste artigo é no processo implementado em nosso ambiente de trabalho, o qual somos (algumas vezes) obrigados a seguir.
Em conversas com colegas de trabalho, ao pronunciar a palavra mágica “processo”, geralmente ocorrem duas reações: uma gargalhada ou uma cara feia. No primeiro caso, o riso é acompanhando de desdém, tipo: ” se pelo menos tivéssemos um processo de verdade…”. Do outro lado, estão os que ficam quase irados: “não entendo porque nos fazem perder tempo com esses processos que não servem pra nada!”
Mas e aí? Você se encaixa em um desses grupos? O processo é um obstáculo no seu trabalho? Ou talvez você esteja do outro lado, criando processos para sua equipe ou empresa e acredita que certas atividades são de grande importância, mas não consegue se fazer entender. Vamos analisar alguns desses aspectos nos tópicos a seguir.
Quando realmente sofremos com o absurdo
Para ilustrar o sofrimento que alguns desenvolvedores tem de aturar, irei descrever exemplos de alguns dos piores casos de processos, ou de motivos para a definição deles, que já testemunhei:
Ditadura
Alguém da diretoria quer “controlar melhor” as atividades, culminando em algo excessivo e desnecessário. Houve um caso onde o chefe queria relatórios de atividades dos funcionários com detalhes em minutos! Por quê? Vai saber…
Labirinto
Processo confuso e redundante. Além de mandar e-mail, preencher documentos e incluir informações no sistema de controle, ainda é necessário imprimir e assinar um documento. Nesse tipo de processo, o desenvolvedor sempre é “culpado” por esquecer algum dos passos “essenciais” do processo.
Surpresa
Tudo está normal, de repente, você dá de cara com o processo.
Certa vez, ao solicitar o envio de um script de correção urgente ao cliente, responderam-me:
– “Onde está o documento de envio?”
– “Que documento?”, repliquei.
E então, a surpresa:
– “Houve uma reunião com a diretoria hoje e recebemos ordens de, a partir de agora, não enviar nada ao cliente que não esteja acompanhados do respectivo documento de envio.”
Bem, restou-me correr atrás de alguém que pudesse me dizer do que isso se tratava… ordens são ordens, não é?
Morto-vivo
Às vezes o processo é essencial, outras nem tanto. Você leu o tópico anterior? Algum tempo depois disseram que o tal documento não era mais necessário. Isso mudou intermitentemente algumas vezes. Já aconteceu de você ficar perdido em como sua empresa funciona?
“Garantia” de Qualidade
Neste ponto alguém pode até argumentar em contrário, devido às boas práticas que alguns processos agregam. Porém, já presenciei casos onde um determinado processo foi adotado para tentar diminuir o número de defeitos num sistema! Primeiro, de forma geral, a burocracia apenas deixa o programador mais nervoso. Além disso, os desenvolvedores eram pouco experientes, então seria melhor investir em treinamento ou incluir pessoas mais maduras no projeto.
Em outra situação, um funcionário que recebeu a incumbência de uma atividade simples estava errando repetidamente, semana após semana. Ele simplesmente devia copiar alguns valores de uma planilha e fazer a inclusão no banco de dados, mas frequentemente os valores do sistema ficavam errados. Seu superior não sabia o que fazer. Seria de propósito? Seria uma total falta de inabilidade? Seria falta de comprometimento? O gerente tentou resolver a situação com um “processo” onde o funcionário problemático teria que “prestar contas” de suas ações. Obviamente isso não resolveu.
Marketing
Determinados certificados relacionados a processos (como CMMI e MPS.BR) colaboram para o status das empresas. Logo algumas investem tempo e dinheiro em práticas e documentações inúteis a fim de aumentar sua credibilidade para com clientes em potencial, sem se preocupar efetivamente com a qualidade de seus produtos ou com a queda de produtividade. Resta aos funcionários ficar até mais tarde para cumprir as exigências adicionais.
Processos servem para alguma coisa, afinal?
O processo é uma ferramenta. Como tal, ele deve ser usado para que os envolvidos e a organização como um todo alcancem seus objetivos. Estes objetivos devem estar alinhados às metas da organização, aos requisitos dos clientes e com as exigências dos órgãos regulatórios.
Um grande problema é que os requisitos e exigências são por vezes conflitantes. Por exemplo, para o cliente, as entregas de correções devem ser imediatas. Entretanto, do ponto de vista de qualidade, é necessário haver revisão e testes, que oneram razoavelmente o tempo necessário para entregar algo. Nos ambientes mais desorganizados, o desenvolvedor pode executar um script diretamente em produção. Por outro lado, em algumas empresas os usuários estão acostumados a ficar dias parados porque as correções não podem ser aplicadas sem uma série de aprovações de diferentes setores.
O processo pelo processo
Um dos maiores erros na engenharia de software é adotar um processo sem um motivo concreto, porque é “legal”, a última moda. Pior, alguns acreditam que determinado processo é a solução para as dificuldades do dia-a-dia. Ainda há aqueles que ficam tão impressionados com um determinado processo que tentam adotá-lo integralmente, com toda sua carga de artefatos e atividades.
Muitos gerentes e diretores acreditam que podem resolver os problemas de gerenciamento simplesmente adotando uma nova abordagem de processos. Eles não conseguem entender porque seus subordinados são tão avessos e resistem tão intensamento a mudanças. Por que será?
É uma questão de mentalidade
Por que resistimos aos processos e reclamamos deles? Por que alguns relatam um “renascimento” ao adotar processos ágeis? Por que os gerentes estão sempre impondo novos processos?
Existem conflitos de expectativas e entendimento. Considerando que não haja absurdos no processo, os desenvolvedores reclamam porque não entendem a necessidade da diretoria. Por que parece que quando um programador é promovido a gerente ele se “converte ao lado negro da força”? Na verdade ele simplesmente amadureceu e percebeu a importância de um gerenciamento adequado. Nós, desenvolvedores, devemos procurar amadurecer e compreender os desafios de nossos superiores, pois assim poderemos contribuir de forma mais efetiva em nosso trabalho e, quem sabe, os gerentes não sentirão a necessidade de criar processos rígidos para resolver seus problemas.
Por outro lado, os gerentes devem entender que processos não resolvem os problemas por si mesmos. Analogamente ao nosso governo, criar leis duras e colocar o exército nas ruas não irá mudar a mentalidade do povo, embora a opressão possa dar a impressão de maior organização e controle. Fazer “a coisa certa” é um desafio gigante, mas conseguir a sincera colaboração e motivação dos envolvidos é algo que não tem preço.
E os processo ágeis? Os “agilistas” relatam que métodos ágeis podem aumentar em diversas vezes a produtividade da equipe, a qualidade, deixar o cliente mais satisfeito e os desenvolvedores mais felizes e realizados. Será que realmente não seria o caso de existir um processo “bala de prata”, isto é, que garantisse o sucesso?
Se você observar a literatura dos “agilistas”, perceberá que antes de alcançar qualquer nível de sucesso, houve uma mudança de mentalidade geral dos envolvidos. Mas, quando o processo ágil falha, logo dizem que ele não foi seguido corretamente. Há uma certa verdade nisso, pois sempre que falhamos é porque não fizemos as coisas como deveriam ser feitas. Porém isto também se aplica a todos os processos.
Conclusões
Enquanto, em nosso trabalho, não pararmos de correr desenfreadamente em qualquer direção, pensando apenas em entregar código e se livrar do fardo que os superiores nos colocam, nunca iremos amadurecer, crescer profissionalmente e ter o prazer de entregar software bem feito.
Devemos rever nossos conceitos e despertar para a realidade do que estamos fazendo, não apenas continuar a repetir indefinidamente e irrefletidamente o que já praticamos vez após vez.
Devemos usar o processo como um aliado para nossos objetivos, que deve intervir em caso de necessidade e não como lei primordial. A chave para o sucesso do projeto (e do processo também), consiste em:
- Transparência: o desenvolvedor merece saber e deve entender a razão do processo;
- Confiança: o processo não deve ser feito baseado na desconfiança entre as partes ou resultará em um mal-estar geral;
- Equilíbrio: embora virtualmente fosse bom controlar tudo o que ocorre na empresa, o processo deve ser apenas bom o suficiente para cumprir seus objetivos.
Lembre-se: o processo pode tanto contribuir como obstruir o desenvolvimento de software.
Para refletir: como saber se seu processo foi feito para o fracasso?
Pense nas atividades que devem ser executadas. Se o sentimento que lhe vier à mente for equivalente a quando você precisa fazer uma ligação de cancelamento de serviços (TV a cabo, celular, …), então provavelmente as pessoas farão tudo ao seu alcance para evitá-lo!
Se você está nessa situação (e é fã de Star Trek) vai entender que “resistir é inútil!”
