O dia em que o processo falhou

Para tudo na vida definimos algum tipo de processo. Processo pela definição literal do Aurélio, “é um conjunto de papeis relativos a um negócio” e que pode ser aplicado a qualquer tipo de seguimento de trabalho, software, administrativo, jurídico, etc.

Para Sommerville o processo de software consiste em atividades e informações associadas que são exigidas no desenvolvimento de um sistema de software (Sommerville, 2003). Logo uma das partes mais importantes para a correta definição e manipulação de um processo é a informação.

Tal informação é trafegada por diversas camadas e definidas pelas atividades que cada pessoa exerce no sistema. E o mais importante que em um processo de qualidade são as formas com as quais uma informação pode se transformar.

Depois de entender um pouco mais sobre processos, chegamos ao momento automatizar uma parte das atividades, tornando-as mais ágeis e menos suscetíveis a falhas. Uma automatização sempre se dá através de máquinas ou programas. Quando a automatização se processa através de software, deve-se pensar em primeira instancia nos papeis que os atores exercem em um processo, assim a definição do workflow da informação fluirá mais fácil. Vale ressaltar que o foco do processo sempre está direcionado a qualidade do andar do negócio, não se constrói falhas, furos ou mesmo lacunas no processo.

Na construção da automatização de um processo, pode-se escolher (comprar) frameworks já prontos onde pode-se utilizar ipsi litem, customizar esse framework ou mesmo criar um novo baseado no correto entendimento do negócio. Os passos básicos que não se pode faltar nesse framework são: Comunicação, Modelagem, a Construção e a implantação. Quando se constrói alguma coisa cujo negócio não faz parte do nosso dia a dia, devemos adotar a pratica da boa comunicação, uma boa comunicação pode eliminar falhas de entendimento o que pode causar conflitos, pode também gerar compromissos e se gerenciado por uma coordenação, estimula e intermédia a percepção dos interlocutores do processo e facilita a Cooperação nas tarefas executadas no processo. Esse modelo 3C (Figura 1) é detalhado em (Borghoff and Schlichter, 2000).

Se um processo for seguido sempre a risca, isto é, nunca há desvios, exceções ou falhas, nesses casos deve-se sempre mensurar, com periodicidade, a execução das atividades do processo de negócio. Quando se codifica um procedimento não há possibilidades de burlar, manipular, alterar o fluxo das atividades bem como as informações que são imputadas pelos atores do negocio. Essas medidas são eficazes, pois sempre a desvios do fluxo normal de uma atividade. Exceções acontecem, são esperadas, não são freqüentes, mas existem.

Construído, testado e implantado o processo automatizado vive seus dias em produção e passa a cada dia por provas que nem sempre foram levantadas em tempo de projeto.
Vejamos agora se esse processo automatizado for para um negocio de segurança predial. Há um fluxo de cadastro de pessoas, entradas de dados diversos, gerencia de informações, controle de hardware, liberações que dependem de cadastros x dados informados que podem estar relacionados com horários, estatísticas, periodicidade de entradas e diversas outras regras envolvidas nesse processo que aparentemente é muito simples: entrar com nome e CPF sair com a liberação de uma catraca.

Analisando em primeira instância, uma boa segurança patrimonial se torna morosa, pela quantidade de variáveis que devem se validadas para uma simples ação. Essa morosidade é compensada quando seus gerentes conseguem rastrear todas as informações de entrada e saída de pessoas em estabelecimento com processos automatizados. Em segunda instancia já identificamos uma falta de agilidade no processo quando, por exemplo, uma pessoa não cadastrada precisa entrar no estabelecimento para uma reunião emergencial e sua atuação é crucial para o negocio da empresa, mas como o processo é altamente seguro, exige um cadastro de pelo menos 24h de antecedência, a fim de liberar seu acesso.

Para esse tipo de problema a solução é bem simples:
1 – Criar o fluxo de exceção no sistema e fazer o redeploy;
2 – O Gerente do processo mandar entrar fora dos cadastros e fluxo de atividades descritos no sistema.

Mas é claro que a primeira solução é a mais recomendada. Pois com ela é possível a rastreabilidade das exceções que ocorrem no processo, porem essa solução se torna ainda mais morosa que o simples fato de liberar a entrada de uma pessoa às dependências da empresa. Agora imagina que essa segunda ação é tomada contra uma empresa de segurança patrimonial? O que pode gerar? Desconforto aos envolvidos, irritação por parte dos atendentes, a não correção do processo por aqueles que definem tais regras de acesso, tempo despendido para liberar o acesso até a tomada da ação.

Conclusão

Não se executa mais nenhuma tarefa sem que as informações sejam cadastradas, cruzadas, medidas e analisadas manualmente. Processos automatizados que não contemplam fluxo de exceções são geralmente mais lentos que os manuais, pois todo desvio num processo manual pode ser simplesmente contornado na hora, podendo não haver uma rastreabilidade desse desfio. Um processo que tem a cada passo um fluxo de exceção pode ser que não seja in totum seguro.

Para que um processo automatizado seja equilibrado, deve-se pensar em todas as alternativas cabíveis: quais atores irão utilizar o sistema, alguns fluxos de exceção que não altere a segurança, desempenho ou a modularidade do processo.

Referências:

Borghoff, U.M., Schlichter, J.H. 2000. Computer-Supported Cooperative Work: Introduction to Distributed Applications. Springer, USA

Sommerville, Ian. “Engenharia de Software”, Addison Wesley, São Paulo, 2003.

Custo efetivo da falta de qualidade.

Há algum tempo venho dizendo que qualquer pessoa que nunca passou pela cadeira dá área de Ti se alto intitula: Programador, Analista e Arquiteto. Acredito que esse último é mais um status do que capacidade de realização, bem não vou discutir isso aqui. Sem discriminação ou preconceito, mas o que mais vejo nessa estrada é um pouco de descaso com a qualidade em detrimento do marketing.

Falando em estrada, e a computação nada mais é que a resolução virtual de um problema real pode-se comparar programas de computadores às rodovias estaduais e federais. Uma boa rodovia é aquela onde é definido o tipo de solo a fim de se preparar o mesmo para que, por exemplo, passe o asfalto, a região onde será construída a rodovia, medição e identificação através de curva de nível onde será tirado ou depositado mais material (solo) para nivelamento, diminuição do trajeto e custo da obra. Disponibilização de maquinário apropriado e muitos outros fatores para o sucesso dessa obra. Mas tudo isso e bem antes foi definido a equipe qualificada para o correto desenvolvimento do projeto: Engenheiros: que não se resume em um único engenheiro civil, técnicos de estrada, laboratoristas que efetuam diversos testes antes, durante e algumas vezes depois da estrada pronta, gerentes do projeto e outros.

E o que fazer quando não se encontra profissionais qualificados para execução dessa tarefa? Subcontrata uma empresa com profissionais qualificados para essa tarefa ou treina a equipe ou simplesmente executa com o que se tem.

O caso acima nada mais é que uma construção de rodovia, mas se analisarmos bem e compararmos com nosso cotidiano, podemos identificar com a construção de software que fazemos todos os dias. Vamos pelo caso de sucesso.

A empresa contratada tem uma equipe qualificada, treinada e com vasta experiência na empreitada. Qual o produto que irão entregar? Uma rodovia plana, segura, confiável onde os carros poderão realmente exercer a velocidade máxima estipulada pela legislação de transito corrente, possibilidades de duplicação sem ter que destruir tudo para duplicar, etc. Isso tudo seria uma maravilha, mas como isso algumas vezes não é realidade o que vemos? Estradas que ao passar o tempo cheias de buracos devido a carga excessiva de carros e caminhões que todos os dias passam por elas, asfaltificação não adequada ao tipo de solo ou mesmo não compactado para receber tal carga, diversas emendas por causa de reformas ou passagem de tubulação tanto energia quanto dutos de gás. Nesse caso o mais correto seria a reconstrução de um trecho da estrada pois não existe emendas no asfalto e muitos outros problemas que vemos no dia a dia. E qual a solução se dá a esses problemas? Uma delas é a operação tampa buracos, logo já sabemos o que vai ocorrer daqui alguns tempos que esses buracos que foram superficialmente tampados.

Agora voltando a computação, em um caso de sucesso de projeto, temos produtos confiáveis, performáticos, completos, robustos, seguros, de fácil manutenção, que quase nunca é gerado incidentes, problemas e seus releases são de evoluções. Esses tipos de projetos com certeza foram rentáveis aos seus idealizados: Contratante e Contratada. Mas o que na maioria das vezes vemos? Produtos mal acabados, de péssima qualidade, problemas de disponibilidades, não rastreáveis, baixo desempenho, e o pior: índice alto de incidentes, recorrentes, problemas, mudanças, cobranças internas e externas, especialistas em trecho de código, desmotivações, stress.

O desfecho dessas construções se dá a capacidade de realização de cada profissional na retirada e preparação do solo na peneira ou refino dos casos de usos, na capacitação da equipe ou a busca do alto conhecimento em fontes confiáveis. Mas o grande problema de não seguir um padrão é o custo excessivo na construção e em seguida na sustentação do mesmo. O não investimento em qualificação profissional acarreta iterações não findadas de projetos de TI e sempre voltando ao custo de manter pessoas e software. Mas aos caros da área, o que vai sobrar é a experiência, como já dizia a máxima: “conhecimento nunca é demais”. Se você participar de projetos que sempre tem final feliz, esse será o seu melhor marketing, e isso só se consegue através de vivencia, estudo e a capacidade de aprender com o erros.

Até a próxima.

Leonardo Marteleto