O Problema de Tecnologia é a Cultura

O Problema de Tecnologia é a Cultura

Sua empresa ainda está com dificuldades de entregar seus projetos de tecnologia satisfatoriamente? Ainda passam do prazo, do orçamento ou tem baixa qualidade?

Sem dúvidas, o problema não está no uso da tecnologia, nem na capacidade dos seus técnicos e desenvolvedores de trabalhar mais rápido. O PROBLEMA ESTÁ NA CULTURA DE SUA EMPRESA!

A indústria de software teve tempo suficiente para amadurecer e solidificar os processos que são eficazes e promovem sucesso, visando resultados expressivos e a satisfação de todos os envolvidos.

Em quase todos os projetos de sucesso, são notáveis as características similares de processos. A característica mais importante é que esses projetos implementaram processos de Gerenciamento de Ciclo de Vida de Software, mais conhecido como ALM (Application Lifecycle Management).

O ALM compreende toda a vida de um software, desde sua idealização até o dia em que o mesmo é aposentado e deixa de ser usado. A noção de que um software continua a ser responsabilidade de quem o criou mesmo depois de entregue, muda completamente o compromisso e dedicação aplicados durante o desenvolvimento inicial. Saber que, mesmo depois de entregue, o desenvolvedor terá que continuar a trabalhar no mesmo código, faz com que ele pense duas vezes antes de entregar algo com baixa qualidade. Afinal, ele é quem terá que “consertarâEUR(TM) o bug depois.

Existem inúmeras outras vantagens em usar ALM:

  • Menores iterações, aumentando o número de entregas e diminuindo o tempo de resposta do cliente em avaliar o progresso.
  • Metas objetivas e curtas que mantém a moral e o comprometimento dos envolvidos.
  • Entrega e manutenção tornam-se um só processo, ou seja, um ciclo constante.
  • Menos desperdício; maior envolvimento e satisfação da equipe.

Quanto mais entregas, maior o retorno financeiro. Entío, por que o ALM ainda é tío ilusivo e utópico? O problema de implementar-se ALM no Brasil não é a tecnologia, nem capacidade dos desenvolvedores. Trata-se de algo cultural.

A cultura tecnológica no Brasil ainda é extremamente deficitária e infantil, mistificando a área como uma lâmpada mágica que quando esfregada concede três desejos que aparecem milagrosamente.

Aos alheios da área, quem trabalha com tecnologia sabe fazer de tudo e completa qualquer tarefa imediatamente. Consequentemente, não há noção de esforço ou complexidade e por isso não entende os custos de tais serviços.

Portanto, implementar ALM no Brasil é uma questío cultural e não tecnológica. Na metodologia ígil, as entregas são curtas, objetivas e rápidas. No entanto, não há planejamento em longo prazo. Cada iteração é planejada em si mesma, com seus objetivos e metas, sucessivamente. Para quem está acostumado com processos burocráticos e paternalistas, que exigem vários documentos de aprovação – documentação, especificação, assinados por vários gerentes -, a ideia de deixar que a equipe de desenvolvimento decida o que será entregue é assustadora.

Porém, desenvolvimento de software não é igual a outros projetos e deve ser encarado de forma mais abstrata, mais criativa e artística. Criação de software, apesar de fundamentalmente lógica, é uma arte.

Levando em consideração os fundamentos de ALM, como um processo delgado e fluído, torna-se extremamente necessário que esses paradigmas de caixa preta sejam desmistificados e superados. Somente dessa forma poderemos ver um crescimento concreto da área.

Por esse motivo, discutirei alguns dos princípios que ajudam í  implementação de um ciclo de vida de software eficaz:

  1. Em primeiro lugar, e talvez o mais importante, é aceitar que desenvolver softwares não é algo trivial e que os processos de sua empresa precisam mudar se deseja ter projetos concluídos com sucesso.
  2. Otimização do sistema, ao invés de otimização de indivíduos produz maior retorno e diminuição de desperdício.
  3. Projetos pequenos tem maior probabilidade de ter mais sucesso. Considere cada iteração como um pequeno projeto, entregue em cadência estável e frequente.
  4. Desvincule-se do paternalismo e necessidade de controle. Delegue a responsabilidade de auto-organização para a equipe (ou equipes). Permita que decidam como e quanto irão entregar em cada iteração.
  5. Prioridade deve ser sua prioridade. Não fique apagando incêndios!
  6. Melhoramento contínuo exige otimizações contínuas.
  7. Valorize seus recursos, especialmente os recursos humanos. O retorno do investimento no indivíduo é maior do que a quantidade de horas pagas pelos clientes.

Há outros pontos que podem ser mencionados e que estío diretamente relacionados í  implementação de processos ígeis (xtreme programming, scrum, etc.). No entanto, focarei nos pontos acima, que mostram-se como pontos fracos da área de desenvolvimento no país.

Desenvolver software não é algo trivial. Assim, os processos de sua empresa precisam mudar se deseja ter projetos concluídos com sucesso.

Como já mencionado anteriormente, nenhum software é codificado da mesma maneira. Blocos de código podem ser copiados, reutilizados e refatorados. No final, a solução nunca é igual a nenhuma outra. Ou seja, software personalizado responde í s necessidades específicas do negócio. De outra maneira, softwares de prateleira (pacotes fechados) seriam suficientes para suprir as necessidades do fluxo da empresa.

Por essa razío, quem desenvolve softwares torna-se perito nas regras de negócio da empresa e encontra maneiras de codificar essas regras de negócio, afim de automatizar o fluxo. Quem desenvolve torna-se especialista, tanto em programação, quanto no domínio do negócio de seus clientes.

Otimização do sistema, ao invés de otimização de indivíduos produz maior retorno e diminuição de desperdício.

É muito comum os funcionários serem avaliados pelo índice de utilização que apresentam. Se um desenvolvedor estiver com os braços atrás da cabeça, olhando para o teto, imediatamente presume-se que esteja livre, ou enrolando.

Essa é a forma mais errada de se avaliar uma equipe, a não ser que se espere estar numa linha de produção de automóveis.

Um desenvolvedor pode estar pensando em uma solução, pode estar criando fluxos, imaginando estruturas ou mesmo pode estar liberando o stress de ficar olhando para um monitor de computador por horas seguidas. Isso não significa que sua capacidade e efetividade estejam comprometidas.

Da mesma forma, focar em cada indivíduo como um produtor unitário, diminui grandemente a performance do sistema.

O Problema de Tecnologia é a CulturaExistem várias maneiras de se apresentar esse conceito, mas mencionarei o jogo de moedas como base para a discussão:

Esse exemplo ajuda a explorar a diferença entre otimização do indivíduo versus a otimização do sistema.

Quando um sistema depende do indivíduo para processar tarefas, a média de tempo de entrega é 60% maior do que em sistemas que ignoram o indivíduo e focam-se apenas no uso do próprio sistema.

íEUR primeira vista, pensa-se que haverá desperdício, pois, o indivíduo que estiver parado, esperando o sistema prosseguir, irá custar muito para a empresa. No entanto, nota-se que quando o fluxo do sistema é otimizado, a quantidade, a qualidade, a rapidez e a cadência de entregas aumenta; consequentemente, aumenta o lucro, mesmo com o aparente desperdício de utilização de indivíduos.

Por esse motivo, é muito mais importante entender e otimizar as engrenagens dos processos utilizados pela empresa, do que simplesmente aumentar a pressão nos indivíduos para que produzam mais e mais rápido.

Projetos pequenos têm maior probabilidade de ter sucesso. Considere cada iteração como um pequeno projeto, entregue em cadência estável e frequente.

Esse é outro paradigma que denigre o sucesso dos projetos. A maioria dos gestores e gerentes de projeto estío acostumados com os grandes blocos de entregas, que apresentam grandes fases de contrato e grande foco de atenção. Contudo, quando esses grandes blocos têm problemas, o mesmo fica perceptivelmente enorme, chegando até a causar o fracasso do mesmo.

Mas, em pequenos projetos, ou iterações, se houver falha, será de umas poucas semanas. Se houver sucesso, as entregas serío a cada poucas semanas. Entío, deixa-se de lado a noção de grandes entregas, para pequenas e constantes entregas. Com pequenas entregas, que acontecem a cada duas semanas, por exemplo, o cliente sempre verá novidades a cada duas semanas, de forma quase transparente, sem burocracia e sem preocupações.

Os ganhos, dessa forma, são abrangentes e agradam todos os stakeholders do projeto.

Desvincule-se do paternalismo e necessidade de controle. Delegue a responsabilidade de auto-organização para a equipe (ou equipes). Permita que decidam como e quanto irão entregar em cada iteração.

Relacionado ao ponto 2 (Otimização do sistema) o paternalismo e controle causam desinteresse, infelicidade e queda na qualidade e produtividade dos envolvidos. Claro que sempre existirão aqueles que trazem um ótimo currículo, mas não são o que vendem. Por isso, o processo de contratação deve ser meticuloso e embasado (analise de personalidade, validação do histórico do currículo, etc.).

Mas, quando uma equipe de qualidade é montada, deve-se confiar que farío o melhor trabalho possível. Deve-se confiar que farío as entregas do jeito correto, com a qualidade esperada e no tempo determinado.

Micro gerenciamento é algo que deteriora o relacionamento da empresa com os colaboradores. Assédio moral destrói a confiança, e o paternalismo pode criar um ambiente de controle.

E, sob pressão desnecessária, colaboradores acabam por sair e buscar melhores oportunidades.

Prioridade deve ser sua prioridade. Não fique apagando incêndios!

Filas são o pior inimigo de qualquer projeto. Mas, pior que filas são os subprojetos que aparecem de forma emergencial e acabam sendo feitos em detrimento de outras prioridades. Portanto, é necessário comprometer-se em manter as prioridades de forma a manter a lista de atividades fluindo da maneira como foram planejadas. Se alguma atividade emergencial aparece, deve ser negociada e planejada de forma a entrar na lista de atividades e não sobrescrevê-la. A forma mais fácil de avaliar a criticidade de uma emergência é calculando o prejuízo que essa emergência vai causar no projeto principal se o mesmo atrasar. Caso a emergência tenha um valor muito maior, entío é justificado (como rede caindo, erros que impedem de um comercio digital vender, etc.). Mas se a emergência se baseia em quem pediu, por exemplo, o prejuízo pode ser muito maior.

Melhoramento contínuo exige otimizações contínuas.

É impossível chegar í  conclusão de que não há mais otimizações a serem feitas. Sempre haverá novos colaboradores, novos projetos, mudanças do mercado, mudanças na tecnologia. As intempéries da tecnologia forçam o melhoramento contínuo. A filosofia da metodologia ígil, Scrum, Kanban, Storyboarding, levam ao melhoramento contínuo, í  análise granular dos processos e fluxos que comprazem o ciclo de vida dentro da empresa. Portanto, sempre que houver a impressão que tudo está funcionando bem, é porque está na hora de buscar melhorias.

Valorize seus recursos, especialmente os recursos humanos. O retorno do investimento no indivíduo é maior do que a quantidade de horas pagas pelos clientes.

É difícil reunir uma equipe eficaz e profissional, que seja capaz de funcionar com o mínimo de interação gerencial e que seja coesa suficientemente para fluir e entregar com qualidade e no prazo. Portanto, valorize seus colaboradores, valorize o feedback constante tanto dos clientes quanto dos recursos. Invista em um departamento de Recursos humanos. Invista em benefícios secundários para seus funcionários, como liberdade de horários, trabalho remoto, bí´nus, etc. Claro que ninguém é insubstituível, mas num mercado que está sempre em avanço, o desperdício de ter que treinar novos colaboradores constantemente pode trazer um prejuízo maior do que investir mais em manter satisfeitos e felizes os que ficam.

A implementação do ALM não tem muito a ver com tecnologia ou custo de investimento, mas sim com um paradigma cultural que perpetuou-se por mais de 50 anos e mostrou-se ineficaz para projetos tecnológicos. Essa transição não é fácil, mas tem profundos resultados em projetos de quaisquer tamanhos e orçamentos.

 

Carlos Augusto A. Casalicchio
Executivo de Tecnologia e Negócios
carlos.casalicchio@zueuz.com
(15) 99142-4586

 

Referências

CAPODAGLI, B., JACKSON, L.., The Disney Way, 2007, McGrall Hill, New York, 312 p.

COCKERELL, L., Creating Magic, 2008, DoubleDay, New York, 270 p.

___, Be Our Guest, 2001, Disney Institute, New York, 207 p.

NADER, G., A Magia do Império Disney – 3-ª Ed. 2012, 2012, Senac, Sío Paulo, 536 p.

___, O jeito Disney de encantar os clientes: do atendimento excepcional ao nunca parar de crescer e acreditar, Disney Institute; [prefácio de Michael D. Eisner; tradução Cristina Yamagami]. âEUR” Sío Paulo : Saraiva, 2011, 141 p.

Innovation and Storyboard, video disponível em:

http://www.youtube.com/watch?v=5QtZRJ5JZA4–  Acessado em 28/04/2014

SANTOS, Danilo S. dos, Baixa Qualidade no Atendimento ao Cliente como Fator de Insucesso nas Organizações, disponível em:

http://revistas.unijorge.edu.br/conexao/pdf/1.pdf–  Acessado em 29/04/2014

BORIS, B. , O problema da qualidade de Atendimento , A ísltima Instancia, Universo Online, 16/01/2014. Disponivel em:

http://ultimainstancia.uol.com.br/conteudo/colunas/68590/o+problema+da+qualidade+de+atendimento.shtml–  Acessado em 29/04/2014

PARKS, R., Disney Show & Tell, HR Magazine, 1998. Citação de Leon Rubis

____, Cinco dicas para tornar a sua empresa mais sustentável, Terra Online, Disponível em:

http://economia.terra.com.br/vida-de-empresario/cinco-dicas-paratornar-a-sua-empresa-maissustentavel,52ed970548b83410VgnVCM20000099cceb0aRCRD.html Acessado em 29/04/2014

____, Falta de profissionais qualificados é problema grave, diz Flávia Oliveira, Globo News, 29/10/2013, Disponível em:

http://g1.globo.com/globonews/noticia/2013/10/falta-de-profissionais-qualificados-e-problema-grave-diz-flaviaoliveira.html Acesso em 29/04/2014

PABLO, Importância Dos Recursos Humanos Nas Micro E Pequenas Empresas, Disponivel em:

http://www.rhportal.com.br/recursos-humanos/Importancia-DosRecursos-Humanos-Nas-Micro-E-Pequenas-Empresas.htm Acessado em 30/04/2014
___, Lessons Learned, PMBOK Reference, disponível em:

http://www2.cdc.gov/cdcup/library/pmg/implementation/ll_description.htm

CURLEE, W, GORDON, R., – Complexity Theory and Project Management, Disponível online em:

http://bit.ly/1K0dqA7

NANTES, R. Pesquisa de Clima Organizacional, disponível em:

http://www.endeavor.org.br/artigos/gente-gestao/ferramentas/como-implantar-uma-pesquisa-de-clima-organizacional

MARSLOW, Piramide de Marslow, Wikipedia, disponível em

http://pt.wikipedia.org/wiki/Ficheiro:Hierarquia_das_necessidades_de_Maslow.svg

___, Avaliação de Desempenho, Wikipedia, disponível em:

http://pt.wikipedia.org/wiki/Avalia%C3%A7%C3%A3o_de_desempenho

DOURADO, A, Orientação: Avaliação de desempenho; motivação e resultados, disponível em:

http://www.portaldoservidor.ba.gov.br/noticias/orientacao/orientacao-avaliacao-de-desempenho-motivacao-e-resultados

ARAísJO, A., Lesão por Esforço Repetitivo, InfoEscola, disponível em:

http://www.infoescola.com/doencas/lesao-por-esforco-repetitivo/

PMBOK-® Guide and Standards, Project Management Institute, Disponível em:

http://www.pmi.org/PMBOK-Guide-and-Standards.aspx

Guia de Avaliação ALM http://vsaralmassessment.codeplex.com/

Avaliação ALM http://www.microsoft.com/visualstudio/almcatalyst/Assessment/

Microsoft ALM http://www.visualstudio.com/en-us/explore/app-lifecycle-management-vs.aspx

Sobre ALM http://en.wikipedia.org/wiki/Application_lifecycle_management

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *