Você já parou para pensar no porquê o desenvolvimento de projetos de software é uma tarefa tão árdua? Até mesmo as taxas de sucesso de complexos projetos de engenharia são mais altas. E por que isso acontece?
Nos últimos 20 anos venho buscando entender isso e desenvolver maneiras de resolver essa questão na qx3. Nem por isso tenho todas as respostas, mas tenho algumas delas! E é isso que quero compartilhar aqui.
nualmente o Standish Group publica o relatório CHAOS, que analisa a taxa de sucesso de um projeto de software. Ano após ano, as taxas de insucesso continuam alarmantes.
Em 2015, para piorar o cenário, eles mudaram o famoso conceito de sucesso de projeto de “no orçamento, no tempo e com o escopo definido” para “no orçamento, no tempo e com o cliente satisfeito” e só com essa mudança fez a taxa cair 7% em relação ao ano anterior.
Como podemos mudar isso? Aqui vão algumas maneiras que descobri serem muito efetivas, depois de tomar muito na cabeça.
Seja nas relações pessoais ou profissionais, o principal problema que temos é não conseguir se colocar no lugar do outro. E quando estamos falando no desenvolvimento de um projeto, nada é mais importante.
Desenvolver um software é transformar uma ideia em algo real e funcional.
E para garantir o sucesso de um projeto é necessário estabelecer uma relação de confiança com o “demandante”.
Pensar com a cabeça do “cliente” é sair da caixa. Sair fora dos bits e bytes, entender os objetivos funcionais que aquele software irá resolver. Aqui, ainda não é o momento de demonstrar sua capacidade técnica. Primeiro você precisa conseguir entender muito claramente as necessidades a serem atendidas.
Projetos de software tem um alto grau de incerteza. E temos que saber lidar com isso.
Se ao primeiro problema temos sempre vontade de jogar a sujeira para debaixo do tapete para não “frustrar o cliente” e pensamos que iremos conseguir recuperar o prejuízo lá na frente, geraremos quase sempre a famosa bola de neve, fazendo o projeto e o relacionamento com o cliente naufragar.
Lembre-se, a boa relação com seu cliente é a melhor maneira de manter um projeto com alta eficiência.
Você pode fazer um planejamento maravilhoso, com cronogramas, documentos, wireframes e isso vai aumentar muito as chances de sucesso do projeto. Mas infelizmente em um projeto de software, existem muitas variáveis que não conseguimos controlar. E você precisa se preparar para mudar sempre que necessário.
Depois de muito tempo trabalhando com diferentes equipes, entendo que a melhor característica de um profissional de TI é de reagir bem em relação aos problemas/mudanças.
Um caso emblemático e triste que aconteceu comigo, foi de um projeto bem complexo que fizemos para o mercado financeiro. Tínhamos que desenvolver um motor para processar e distribuir mais de 100.000 mensagens por segundo de cotação da bolsa de valores.
Fiz uma busca no mercado por um profissional que tinha experiência nesse tipo de solução e consegui contrata-lo após uma grande negociação.
O projeto estava com um bom andamento no seu terceiro mês, mas de um dia para o outro esse profissional sofreu um acidente de carro e faleceu.
Foi um dia muito triste para a qx3!
E aí? O que fazer nesse momento? Hoje entendo que não tomei a melhor decisão…
Quis manter o desenvolvimento com o resto da equipe, que apesar de ser bastante capaz, não tinha experiências anteriores nesse tipo de serviço.
A melhor solução seria a renegociação com o cliente, ajustando novas expectativas ou melhor ainda, cancelar o projeto até encontrar um novo profissional.
Precisamos saber nos adaptar sempre.
“Não é o mais forte que sobrevive, nem o mais inteligente. Quem sobrevive é o mais disposto à mudança” — Charles Darwin, biólogo
Nós desenvolvedores adoramos inovar! E isso é ótimo. Somos movidos pela constante evolução da tecnologia. Mas precisamos saber dosar isso.
Sempre temos a vontade de escolher aquela tecnologia que acabou de sair do forno e que não tem projeto nenhum funcionando nela.
A melhor tecnologia a ser escolhida é a que seu time tem experiência comprovada!
Sem dúvida em alguns momentos precisamos arriscar, mas para isso faça um projeto piloto antes! De preferência um projeto de curta duração e que não gere muito problema se for atrasar e principalmente custar mais…
Não entendo bem o motivo, mas principalmente em grandes empresas ainda existe uma cultura de não envolver no projeto os usuários finais que usarão o software depois de pronto. Acredito que essa possa ser uma das principais falhas de um projeto de software. Existem “áreas meio” dentro dessas empresas que acham que sabem tudo sobre o projeto, mas na grande maioria das vezes não é isso que acontece. Normalmente projetos demandados diretamente pelas área de TI e de Marketing são os mais fáceis disso acontecer…
Não falar com usuário final pode fazer fracassar projetos de várias formas. Os fracassos mais usuais são:
Temos conseguido resolver esse problema em alguns clientes mais abertos a novos conceitos, dividindo o projeto em duas etapas. Uma etapa inicial que chamamos de consultoria de UX (User Experience), onde fazemos um trabalho profundo de pesquisa, planejamento e validação do software com os usuários, e a execução em um modelo ágil em que os usuários consigam validar as nossas entregas de forma periódica (períodos não maiores do que 10 dias úteis).
No decorrer de um projeto somos sempre surpreendidos por inúmeros impedimentos ou dificuldades que fazem com que a gente não consiga andar mais na atividade atual planejada. Os impedimentos mais comuns são uma falta de aprovação de um artefato, uma definição pendente pelo demandante, uma tecnologia escolhida que não se comportou como o esperado ou um serviço de fornecedor externo que não ficou pronto a tempo.
Normalmente nesses momentos tomamos a linda decisão de parar o que estamos fazendo e passamos para uma próxima atividade sem impedimentos, deixando para trás a anterior daquele jeito… Quando o impedimento for solucionado, voltamos para atividade em questão sem lembrar de nada de como estávamos fazendo. E também vamos ter aquele impulso de fazer diferente porque já aprendemos uma outra forma mais inteligente de fazer, deixando para trás várias horas não planejadas.
Outro ponto importante é que para um programador reutilizar código é sempre o melhor dos mundos! E fazemos isso o tempo todo! Mas em projetos dessa natureza isso pode se tornar no seu calcanhar de aquiles. Principalmente por ter várias atividades não testadas e validadas pelo usuário, iremos reutilizar código não testado o que gera o famoso “débito técnico”!
Minha sugestão é fazer uma gestão muito eficiente desses impedimentos, não faça corpo mole, corra atrás da resolução. Caso não consiga uma solução a curto prazo, é recomendado parar o projeto, renegociando custos e prazo.
Nós, seres humanos, temos o terrível hábito de criticar mais do que elogiar. Eu mesmo busco diariamente mudar isso. Além desse nosso modelo mental, ainda está muito ativo na nossa cultura empresarial, sistemas de avaliação que são totalmente focados em discutir, melhorar e traçar metas para evoluir os pontos fracos.
Hoje vejo que é muito mais fácil melhorar cada vez mais os pontos fortes do que os fracos e o retorno é muito maior!
Então escolha bem o seu time pensando nos pontos forte de cada um!
Faça-os focar no que têm de bom e crie alternativas para mitigar os riscos dos pontos fracos.
Faça uma divisão de responsabilidades eficiente!
Explore o que cada um tem de melhor e veja já a curto prazo os benefícios de uma equipe motivada e eficiente.
Para escrever sua resposta aqui, entre ou crie uma conta
Desenvolvimento de Software
•ESTÁCIO
Processos de Desenvolvimento de Software
Processos de Desenvolvimento de Software
Processos de Desenvolvimento de Software
Compartilhar