Prazo e Qualidade devem sempre caminhar juntos dentro do planejamento, mas devemos ter ciência que para atender estes requisitos juntos, o prazo provavelmente será afetado.
Atualmente, é normal os gerentes, clientes, analistas, e etc…, envolverem e cobrarem os desenvolvedores por prazos cada vez menores e qualidade cada vez maior. Como consequência estamos ficando cada vez mais longe da combinação perfeita de prazo e qualidade. Para obter um resultado mais coerente, os envolvidos no projeto deveriam definir algumas diretrizes, um bom exemplo é o alinhamento dos usuários com os analistas e desenvolvedores. Existe um mito que o usuário não precisa conhecer algumas funcionalidades tecnicamente, mas temos que traduzir e explicar a complexidade de desenvolver determinadas funcionalidades e regras dentro do ambiente de desenvolvimento. Quando começarmos a mostrar a nossa realidade irão entender a complexidade do nosso trabalho e começarão a solicitar funcionalidades mais coerentes com o que podemos entregar efetivamente.
Os gerentes e líderes, por não conseguirem uma boa equação sobre Prazo x Qualidade e por falta de conhecimento técnico (alguns casos), acabam aceitando os prazos solicitados pelos usuários. Neste caso fica nítido que se houvesse comunicação entre os envolvidos, seria solucionado o problema do prazo. Quando envolvemos todos na obtenção de um resultado comum o comprometimento é maior, devido o sucesso ou fracasso do trabalho ter a assinatura de todos. Gerentes e analistas devem focar seus esforços em serem intermediários entre o cliente e o desenvolvedor, para retirar eventuais dúvidas durante o processo de desenvolvimento.
Nos projetos de TI estão envolvidos muitos profissionais da área de negócio e este apoio nos permitirá uma maturidade cada vez maior, além de ter um profissional que conhece e tem o papel de tradutor da área de negócio com a área técnica. Não temos ainda uma determinação de prazo perfeita, pois software tem seu funcionamento e comportamento diferente a cada dia, mas para ajudar o desenvolvedor na obtenção de melhores resultados e conseguir medir de uma forma mais precisa o seu esforço (devemos sempre acreditar que todos estão envolvidos e comprometidos com o projeto) e com isto os analistas e gerentes conseguirem cada vez mais conhecerem a velocidade de desenvolvimento da sua equipe e, consequentemente, poderão informar ao usuário que o prazo não será atendido (a partir daqui incluão o desenvolvedor na conversa), segue algumas diretrizes para serem seguidas e que ajudarão muito:
- Definir a arquitetura de desenvolvimento de modo que possibilite ao desenvolvedor não ter a preocupação com validação de campos e controles de tela;
- Criar ambiente de desenvolvimento igual ao ambiente de produção;
- Não criar um ambiente de terrorismo aos envolvidos no projeto, onde devemos encarar que a mudança faz parte do negócio e irá comprometer o prazo;
- Alinhar a solicitação do cliente com o que realmente o desenvolvimento possa atender;
- Ter o usuário como aliado;
- Equipe do projeto deve trabalhar de forma alinhada;
- Possibilitar ao desenvolvedor um ambiente em que ele tenha autonomia para discutir e gerar código de maneira criativa;
- Possibilitar contato direto entre analistas, desenvolvedores e usuário;
- Promover reuniões periódicas, afim de, apresentar aos envolvidos quais funcionalidades foram realizadas;
- Valorizar o trabalho em grupo e a troca de informações.
Com a definição de uma arquitetura adequada e a possibilidade de maior interação entre os envolvidos no projeto, teremos uma equipe melhor alinhada e a cada projeto o prazo será mais fácil de ser medido.
Sigam-me no twitter: @ric_agostinho
3 Comentários
O único método que vi funcionar o prazo com a Qualidade foi o Scrum com algumas adaptações que utilizei na WebSoftware Ltda. Reduzimos a quantidade de bugs de forma drástica e o aumento da satisfação do cliente é comprovada. Mas devemos lembrar de mostrar ao cliente como a engrenagem funciona, pois assim ele terá a noção de como realizamos o trabalho e irá entender como trabalhamos o prazo aliado a qualidade.
Minha opinião esta alinhada a do Colega “Fenando Martins”, tambem utilizamos Scrum em nossa equipe. Tudo que esta escrito no artigo do Colega Ricardo esta coerente a realidade do mercado, o que ainda leva ao insucesso em alguns casos é a falta de comprometimento. Ultimamente esta dificil encontrar profissionais (independente do nível hierárquico ou área de atuação) comprometidos verdadeiramente com o resultado é o velho “vestir a camisa da empresa”. Isso vem se perdendo justamente pela “facilidade” de trocar de empresa ou pela falta de interesse da empresa em investir em gestão de pessoas.
Parabéns pelo Artigo.
vejo muitos gestores de equipes reclamando de compromentimento e utilizando scrum como pelourinho… no mercado de trabalho de hoje de nada adianta forçar goela a baixo dos seus colaboadores uma cultura… se a empresa deseja compromentimento dos seus colaboradores é função dela criar meios para gerar esse comprometimento e filtrar as “maças podres”