A feia verdade sobre o processo de desenvolvimento de software

Fonte da imagem: perfectdigital.com

Conheces esta fotografia, certo?

Penso que mostra muito bem que podem surgir grandes discrepâncias e falta de visão em desenvolvimento de software projectos entre todos os participantes e pessoas envolvidas. Os problemas surgem muitas vezes logo no início, quando o cliente chega com uma proposta (teoricamente) final produto visão e apresenta-a ao equipa. Seguem-se novos mal-entendidos, interpretações erróneas e, por fim, a projeto rapidamente envereda pelo caminho errado do desenvolvimento.

Ao analisar o gráfico acima, vou apresentar, passo a passo, todas as ameaças possíveis e sugerir como combatê-las. Vamos diretos ao assunto!

1. Como é que o cliente explicou a ideia?

Haverá discrepâncias nos visão do produto desde o início. Porquê? A razão é muito simples - cada um interpreta a realidade à sua maneira, tem uma ideia de algo na mente e pode não apresentar corretamente essa visão à outra parte. Se descrever por palavras um produto que gostaria de construir, há uma grande probabilidade de o equipa de desenvolvimento compreenderão a sua visão de uma forma diferente da que pretendia.

É claro que é possível evitar esta situação. Deve começar a visualizar o mais cedo possível e discutir elementos individuais das funcionalidades do produto com base em esboços. Curiosamente, os primeiros esboços geralmente não têm nada em comum com o produto final. No entanto, nesta fase, o mais importante é tornar a visão coerente.

2. Como é que o chefe de projeto o entendeu?

Porque é que a primeira e a segunda imagem são tão diferentes? O chefe de projeto analisará sempre mais de perto a visão do produto. No entanto, é importante que essa pessoa, essencialmente responsável por toda a software processo de desenvolvimento, compreende plenamente o problema e as necessidades relacionadas com o produto. O chefe de projeto deve ter uma "visão global" clara. Como pode ver, as duas imagens não diferem em termos de funcionalidade. Apenas têm um aspeto diferente. Para compreender melhor este ponto, voltemos à imagem número um. No início do projeto, não havia esboços e isso já deu origem a um mal-entendido. A funcionalidade do produto está correta, mas o design é completamente diferente.

3. Como é que o analista o concebeu? e 4. Como é que o programador o escreveu?

Por vezes, os analistas e os programadores não conhecem as necessidades dos utilizadores ou os objectivos comerciais estabelecidos. Vêem apenas uma pequena parte de todo o projeto, que capta a sua atenção principal. Não são capazes de olhar de uma perspetiva mais ampla, e isto é particularmente o caso dos grandes projectos, onde muitos programadores trabalham ao mesmo tempo.

Podemos também utilizar outro exemplo. Pode acontecer que o problema a resolver seja incorretamente descrito, por exemplo, pelo proprietário do produto. Isto implica o fornecimento de informações incompletas, com base nas quais o programador ou o designer criam as suas próprias interpretações, e o produto desvia-se cada vez mais da trajetória de desenvolvimento pretendida.

Como mudar isso? Penso que uma boa solução é garantir que as pessoas que são fundamentais para o projeto tenham um conhecimento detalhado do mesmo - o chamado "panorama geral". Em caso de mal-entendidos, será mais fácil para elas trazerem a questão para o processo de desenvolvimento de software de volta ao caminho certo. Por isso, lembre-se: se cada um vir apenas o seu pequeno fragmento da funcionalidade desenvolvida, os mal-entendidos na visão tornam-se uma ameaça provável.

5. Como é que o consultor comercial o descreveu?

Neste caso, a questão é simples. O produto tem de vender. Tem de se destacar de alguma forma, para que, por exemplo, um simples baloiço para o seu jardim atinja elementos extraordinários. A ideia é convencer um potencial comprador. O departamento de marketing e vendas fará certamente tudo para mostrar que o produto é único.

6. Como foi documentado o projeto?

A falta de documentação é um problema muito comum. Por vezes, a criação de documentação durante desenvolvimento de produtos parece uma perda de tempo desnecessária. Isso é um erro. Eu digo muitas vezes que as mudanças são feitas mais rapidamente no papel do que na códigoe há algo de bom nisso. Além disso, é mais fácil consultar a documentação para acompanhar quaisquer alterações. Acredite em mim, um projeto sem documentação corre um risco muito elevado de perder a visão.

7. Que operações foram instaladas?

Esta fase refere-se à colocação do ambiente no servidor. Tal como no ponto relativo aos programadores e analistas, sem dados completos e com falhas de comunicação, pode acontecer que apenas uma parte do ambiente necessário tenha sido criada.

8. Como é que o cliente foi facturado?

É o resultado de uma comunicação deficiente, da falta de experiência do utilizador, etc. O aparecimento de erros aumenta o tempo de desenvolvimento. E tempo é dinheiro, certo? A minha sugestão é executar o projeto de acordo com o método AgileA Comissão Europeia, por seu lado, tem o dever de manter os mais elevados padrões de comunicação e de seguir orientações orçamentais claras. Não tenho dúvidas de que, se o fizer, evitará problemas deste género.

9. Como é que foi apoiado?

Frequentemente, os clientes concentram-se apenas na construção de um produto e ficam por aí. No entanto, vivemos uma época de muitas mudanças e inovações tecnológicas, e é por isso que é necessário manter um suporte técnico constante. A ideia é evitar uma situação em que algo deixa de funcionar de repente, pois fica desatualizado e o produto perde o seu valor. Este aspeto também não deve ser esquecido.

10. O que é que o cliente realmente precisa?

Chegámos ao último ponto. Repare na discrepância entre o primeiro e o último gráfico. Afinal, ambos dizem respeito à perspetiva do cliente. Porque é que isto acontece? Toda a gente mente que é tão simples quanto isso 🙂 Os resultados dos inquéritos diferem sempre das necessidades reais dos inquiridos. Ao responderem à pergunta do investigador, os utilizadores querem mostrar o seu melhor lado. Por conseguinte, MUITAS VEZES NÃO RESPONDEM COM SINCERIDADEmas sim de uma forma que acham que devem responder. Basicamente, não querem ser expostos à avaliação negativa dos outros. Aqui fica uma pequena dica: mencione nas instruções que não há respostas boas nem más.

Onde é que as diferenças aparecem? É frequente as pessoas não saberem o que realmente querem. Muitas vezes, os utilizadores dizem inicialmente que precisam de 10 funcionalidades no produto e, mais tarde, utilizam apenas, digamos, 3.

Então, como é que se resolve este problema? Para além de perguntar aos utilizadores o que querem e precisam, permita-lhes testar o produto, de preferência em artigos autênticos para manter a credibilidade. Quanto mais testes durante a criação dos produtos, maior a chance de o resultado ser preciso.

Resumo

Se alguma vez se tornar membro de uma desenvolvimento de software projeto, lembre-se dos meus exemplos e tire conclusões para não copiar os erros acima referidos. E lembrem-se, estes conceitos são muito importantes na construção de um produto (aplicação) de raiz:

- boa experiência do utilizador e testes, para que possa saber o que os seus utilizadores realmente precisam,

- comunicação no âmbito do projeto, para que as pessoas-chave do projeto tenham uma compreensão profunda do problema e das necessidades,

- desenvolver o produto em conformidade com Ágil,

- não se esqueça do apoio técnico.

Ler mais:

– Como gerir eficazmente os programadores remotos? O guia para CTOs

– Python vs. Ruby? Que tecnologia deve utilizar para o desenvolvimento de produtos?

– Um guia rápido para criar e desenvolver o seu próprio mercado. O que vale a pena saber?