Por: Fernando Ferreira
5217 visualizações
Tempo leitura: 8 min
Ser competitivo no cenário atual do mercado é algo imprescindível, tanto para os profissionais quanto para as empresas. Para as empresas, essa competição tem o objetivo de manter e conquistar novos clientes, seja no ramo de produtos ou serviços. É preciso se reinventar constantemente para garantir e aumentar a sua fatia no mercado. Esse resultado esperado pelas empresas nada mais é do que um reflexo dos seus processos gerenciais e operacionais.
As empresas de Tecnologia da Informação têm um largo histórico de um passado negro. Esta situação ainda ocorre com muita frequência nos dias de hoje. Muitos problemas como projetos entregues fora do prazo e orçamento, funcionalidades pouco ou nunca utilizadas, softwares de baixa qualidade elevando o custo das melhorias e manutenções não são novidades para ninguém. Este é o status quo do cenário de boa parte das empresas de desenvolvimento de software atualmente. É muito comum ver empresas que dizem utilizar a metodologia X ou a metodologia Y e mesmo assim permanecerem imersas nesses tipos de problemas. Mas por que isso ainda acontece? Existem diversos fatores que levam a esse cenário, podemos elencar alguns que são os mais comuns:
- Falsa percepção de produtividade;
- Processos muito rígidos e mal elaborados;
- Escopo mal definido;
- Alto índice de retrabalho (consequência);
- Falta de foco no cliente.
Estes são apenas alguns itens que permeiam grande parte da rotina das empresas de desenvolvimento de software.
Software é algo naturalmente complexo feito para ser utilizado num ambiente extremamente complexo e volátil, o ambiente psicossocial. O cenário atual do mercado exige uma complexidade da qual não podemos escapar, somando-se a isso o excesso de complexidade gratuita que as empresas utilizam nos seus processos.
Com Lean TI propõe-se uma abordagem mais clara e eficiente para que seja criado um ambiente mais produtivo, mais estável e criativo.
A complexidade
Há uma tendência natural no ser humano de complicar as coisas mais do que elas são, soma-se a isso a complexidade inerente aos processos atuais de negócios e temos como resultado um processo ainda mais complexo com uma ferramenta de apoio difícil de usar e manter. Além dessa característica humana, a complexidade em um ambiente também ocorre devido à falta de conhecimento, seja na área de negócios e/ou na área tecnológica. Essa falta de conhecimento acaba sendo contornada através de soluções complexas e de pouca flexibilidade. São soluções que enrijecem os processos e o software de apoio. Com o passar do tempo, o custo de manter e evoluir um software assim aumenta exponencialmente e cria um ambiente de estresse para todos os envolvidos. Além disso, muitas tarefas rotineiras costumam ser automatizadas em cima desses processos de alta complexidade, a partir daí, todo esse fluxo é retroalimentado gerando um alto índice de arrasto para a execução das atividades da empresa.
Menos desperdício – Mapeamento do fluxo de valor
Com Lean TI orienta-se a aplicação de uma ferramenta para que uma empresa possa desenvolver uma cultura de simplificar as atividades aumentando a geração de valor para o cliente. Isso permite que as partes envolvidas possam fazer uma análise do processo como um todo afim de detectar pontos que podem ser eliminados com o objetivo de simplificar o processo e eliminar desperdícios.
O mapeamento consiste em identificar cada uma das atividades do fluxo de processo e classificá-las de acordo com um grau de importância em uma escala de valor para o cliente. No caso das empresas de T.I., valor para o cliente pode significar principalmente software funcionando e dando suporte eficiente a sua operação. As atividades envolvidas para se alcançar esse cenário compõem o fluxo que deve ser mapeado e classificado conforme o valor que agrega.
Essa escala é definida em:
- Atividades que geram valor para o cliente;
- Atividades que não geram valor para o cliente, porém são necessárias ao processo e,
- Atividades que não geram valor e são irrelevantes ao processo.
É nessa última categoria que estão as atividades que devem ser eliminadas de imediato. Pois elas estão gerando desperdícios de tempo e consequentemente dinheiro para a organização. Essas atividades criam um “arrasto” no fluxo gerando uma série de dificuldades e aumentando a complexidade do processo. Para as demais categorias, a organização deverá aplicar diretrizes de análise para identificar pontos que podem ser melhorados e/ou eliminados do processo.
Esse mapeamento deve ser feito com cuidado, evitando excessos de detalhes e também que sejam muito abrangentes. Uma organização que mapeia seu fluxo com excesso de detalhes, pode acabar complicando a visão macro do processo na hora de fazer uma análise geral do mapeamento. Por outro lado, caso esse mapeamento seja muito abrangente e superficial, poderá vir a ocultar pontos que poderiam ser melhorados e até eliminados.
Um processo bem definido acaba por permitir que os envolvidos tenham mais tempo para melhorar ainda mais o processo, resolver problemas com soluções de alta alavancagem, e direcionar sua criatividade para novos desafios.
Menos esforços em atividades rotineiras
As atividades rotineiras estão presentes em todo e qualquer processo das organizações. São atividades que em uma primeira abordagem são essenciais para o fluxo do processo. Aqui cabe uma análise conforme descrito anteriormente, a fim de identificar se tal atividade entra em uma das 3 categorias citadas acima. Muitas empresas ainda hoje executam atividades repetitivas inerentes ao seu processo de desenvolvimento. A execução dessas tarefas demanda tempo e acaba impondo um arrasto em todo o processo, sem falar que a possibilidade de falhas aumenta quando essas atividades são executadas manualmente.
No cenário das empresas de desenvolvimento de software, existem diversas tarefas rotineiras que podem e devem ser automatizadas, podemos elencar algumas:
- Compilação;
- Geração de pacotes de novas versões;
- Gerar relatórios de métricas;
- Efetuar o deployment;
- Testar a aplicação.
A automação das rotinas é uma atividade que vai ao encontro do desenvolvimento ágil e eliminando desperdícios de tempo com possíveis falhas que as pessoas possam vir a causar.
Menos tempo na identificação e correção de bugs
Quando trabalhamos no desenvolvimento de um software, acabamos nos deparando com os bugs. Os bugs não estavam nos requisitos do software, mas eles sempre aparecem mesmo não sendo bem-vindos. As causas são as mais variadas possíveis, as vezes o software já começa a ser desenvolvido com prazo estourado, o desenvolvedor não teve o cuidado e a atenção necessários na criação de uma determinada rotina, os testes não exercitaram a aplicação o suficiente para detectar a maioria dos bugs, enfim, a lista é grande.
Quando um bug é detectado no ambiente de desenvolvimento, sua principal consequência é um possível atraso de deployment dependendo da severidade (podemos associar um custo também). Porém, um bug no ambiente de produção, torna-se um problema muito maior ao cliente (na maioria das vezes para a sua operação), o custo acaba sendo maior e ainda afeta a credibilidade com a empresa fornecedora.
O Lean apresenta uma proposta para a solução de problema que visa atacá-los na sua causa raiz em vez de uma abordagem paliativa. Em Lean, um bug é conhecido pela expressão Mura. Mura significa um problema, um defeito. Um ambiente de desenvolvimento que utilize testes automatizados terá uma grande vantagem na hora de corrigir um bug, pois já existe uma suíte de testes criada. Aplicando a correção e cobrindo o cenário que está gerando o bug, basta executar os testes novamente que já teremos o resultado. Se a correção afetou outra parte do software, já saberemos de imediato, pois os cenários de testes automatizados garantirão isso para nós. Além de eliminarmos a grande maioria dos problemas, termos a garantia de que eles não voltarão a acontecer, pois o eliminamos na sua raiz.
Próximos itens abordados na parte II
Menos excessos com Just in time
Menos bugs com mecanismos a prova de falhas
Menos desperdícios com Kaizen
Clique aqui e leia mais sobre a parte II.
Data da publicação:
11/06/2015
-
Fernando Ferreira
OpenTech
Formado em Tecnologia e Análise em Desenvolvimento de Sistemas pela UDESC - Universidade do Estado de Santa Catarina, trabalha como desenvolvedor desde 2006 utilizando as tecnologias Delphi e .NET. Sempre em busca de boas práticas no desenvolvimento de software e atualizado com as rápidas mudanças no mundo da T.I. Gosta de escrever e participar de eventos de tecnologia.