Facunte iLife

Salve meus nobres!

Na primeira parte do artigo traçamos cenários comuns de desenvolvimento de soluções em empresas de diferentes portes.

Sinto-me incongruente neste cenário fatídico (trágico), porém estou de mãos atadas, lábios lacrados, costurados pela desunião de uma classe conhecida como: “OS CARAS DA INFORMÁTICA”.

No final da primeira parte do artigo, concluí com o seguinte pensamento:
Somos responsáveis pela mudança deste cenário. Não devemos culpar nossos diretores e gerentes. Nós permitimos isso!

Por que nós permitimos tal cenário?

1. Medo de enfrentar o “boss”?
   Certamente essa é uma das tarefas mais complicadas, que exige dose infinita de coragem. Mas se houver união, esta dose será dizimada entre os corajosos, porém uma força maior será formada.
2. Falta de iniciativa?
   Vocês já perceberam quantas coisas perdemos por falta de iniciativa?
   Quantas vezes nos questionamos sobre aquela “oportunidade única” que perdemos?
3. Ambiente hostil!
   Este é um fator delicado, que exige um bom estudo estratégico antes de criar a tal coragem. Existem diversos níveis de hostilidade, desde a “teatral”, que apenas representa de maneira figurada, até a mais covarde que se apóia em técnicas desprezíveis como o assédio moral. Neste caso, você deverá denunciar a pessoa, ao invés de estudar estratégias.
4. Falta de argumentos
   Opa! �? aqui que entramos… Vamos enumerar alguns:
   – Se há tempo para ficar corrigindo “bugs”, então há tempo para implantar processo de qualidade de software.
   – Adotar uma metodologia enobrece e fortalece a qualidade do projeto
   – Entrega no prazo
   – Maior disponibilidade de tempo para novos projetos
   – Maior integração entre as equipes
   – Maior confiabilidade na equipe
   – Melhoria no ambiente de trabalho
   – Redução drástica de “bugs”.
   – Redução do tempo para implantar novas funcionalidades
   – Redução do tempo para encontrar qualquer tipo de inconsistência

Bem, com estes argumentos já é possível iniciar uma boa análise estratégica.

O espaço está aberto para discutirmos o assunto.

Follow me on Twitter: @facunte (http://www.twitter.com.br/facunte)

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• Compartilhar/Salvar

Nobres,

Vocês já conseguiram convencer seus gerentes e diretores a adotarem o modelo de qualidade de software em suas equipes?

Bem, esta é uma tarefa árdua e a batalha pode ser comparada com a histórica luta entre Davi e Golias.

Vejamos o cenário atual da maioria das empresas.

Empresa A
O cenário mais comum

1. Gerente solicita desenvolvimento de uma “simples” rotina para cálculo de Folha de Pagamento.
   Obs: Não há especificação de fórmulas, tão pouco as informações que farão parte do cálculo.
2. Desenvolvedor – neste cenário também pode ser chamado de Analista de Sistemas, Analista de Requisitos, Analista de Testes, Analista de Suporte, DBA e até mesmo “mágico” – levanta informações com gerente e/ou profissionais de RH e põe a mão-na-massa. Desenvolve a “simples” rotina, faz testes convencionais do tipo: informa valor, clica aqui, vê resultado e pronto!
3. Gerente faz uma rápida avaliação na rotina desenvolvida e autoriza a implantação.
4. O restante da epopéia (sim, isto pode ser considerado um poema épico, heróico) já é sabido: dezenas de erros serão observados, desde a análise dos requisitos até a fórmula criada.
5. Gerente solicita revisão e correção dos erros.
   O ciclo vicioso está formado. No momento em que “todos” os problemas apontados forem solucionados, novas requisições estarão numa imensa fila de espera. O “mega-desenvolvedor” tem trabalho para o resto de sua vida – um final dramático.

Empresa B
Algumas empresas estão brincando neste nível

1. Gerente solicita desenvolvimento de uma rotina para cálculo de Folha de Pagamento. Agenda a reunião com todos os envolvidos no processo (analista de sistemas e RH) .
2. Na reunião são apresentadas todas as informações para realização do cálculo. O analista pouco questiona, já que não é especialista em requisitos.
3. Com base nas informações coletadas na reunião, o analista desenvolve a rotina, faz testes convencionais do tipo: informa valor, clica aqui, vê resultado e pronto!
4. Gerente faz uma rápida avaliação na rotina desenvolvida, agenda nova reunião com os envolvidos e apresenta a solução.
5. A rotina é implementada.
6. A mesma epopéia: dezenas de erros serão observados, desde a análise dos requisitos até a fórmula criada.
   Cenários diferentes, os mesmos problemas e todos nós reclamamos do processo.
   Nos corredores ouvimos colegas dizerem:
   – Você acredita que terei que alterar isso ou aquilo?
   – Não aguento mais, eu sabia que aquilo estava correto, mas não sou o chefe aqui!
   – As informações foram transmitidas pela metade, terei que refazer todo o processo.
   – Isso não é justo. Trabalhei 6 meses neste projeto e os caras mudaram tudo!

   Somos responsáveis pela mudança deste cenário. Não devemos culpar nossos diretores e gerentes. Nós permitimos isso!

   A epopéia continua na Parte II.

   Follow me on Twitter: @facunte (http://www.twitter.com.br/facunte)

   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • 
   • Compartilhar/Salvar

Há cerca de dois anos atrás fiz um post sobre a Qualidade de Software. Como o blog foi desativado, estou repostando…

O primeiro post é uma breve reflexão da Qualidade de Software nas empresas.

Let´s go!

Quer polemizar uma conversa? Então fale sobre qualidade de software. O assunto é mais discutido do que aplicado.

Muitas empresas sonham com qualidade de software, mas não sabem por onde começar. Como convencer gerentes a adotarem metodologias, gerenciamento pleno e disciplina? Na visão de muitos gerentes e diretores, esse processo já acontece em suas equipes. Será?

�? dificil para o gerente admitir que em sua equipe não são utilizadas metodologias de desenvolvimento; que não há gerenciamento pleno do ciclo de desenvolvimento e também a ausência de disciplina. E o pior: acreditam que num projeto não há riscos, ou pelo menos ignoram!

Uns dizem que o processo para implantação de qualidade de software deve vir de cima (Presidentes, Diretores e Puxa-Sacos Masters). Penso de outra maneira: o processo deve vir de baixo: desenvolvedores ligados no processo deverão convencer seus colegas a conhecerem melhor sobre o assunto, as práticas, engenharia de software e afins. Devem preparar um bom planejamento com cases de sucesso, práticas e metodologias a serem adotadas, artigos, documentos ligados a engenharia de software e apresentar aos seus gerentes.

Uma coisa é certa: não dá pra implantar um processo de qualidade de software do dia para a noite. Deve-se escolher muito bem a prática a ser adotada.

Nos próximos posts continuarei discutindo sobre o assunto e apresentando argumentos suficientes para você convencer seu gerente.

Follow me on Twitter: @facunte (http://www.twitter.com.br/facunte)