![\"Swing](\"\/app\/uploads\/2024\/05\/swing-software.jpg\")
<\/p>\n<\/p>\n
Fonte da imagem: perfectdigital.com<\/em><\/p>\n Penso que mostra muito bem que podem surgir grandes discrep\u00e2ncias e falta de vis\u00e3o em desenvolvimento de software<\/a> projectos entre todos os participantes e pessoas envolvidas.<\/strong> Os problemas surgem muitas vezes logo no in\u00edcio, quando o cliente chega com uma proposta (teoricamente) final produto<\/a> vis\u00e3o e apresenta-a ao equipa<\/a>. Seguem-se novos mal-entendidos, interpreta\u00e7\u00f5es err\u00f3neas e, por fim, a projeto<\/a> rapidamente envereda pelo caminho errado do desenvolvimento.<\/p>\n Ao analisar o gr\u00e1fico acima, vou apresentar, passo a passo, todas as amea\u00e7as poss\u00edveis e sugerir como combat\u00ea-las. Vamos diretos ao assunto!<\/p>\n Haver\u00e1 discrep\u00e2ncias nos vis\u00e3o do produto<\/a> desde o in\u00edcio. Porqu\u00ea? A raz\u00e3o \u00e9 muito simples - cada um interpreta a realidade \u00e0 sua maneira, tem uma ideia de algo na mente e pode n\u00e3o apresentar corretamente essa vis\u00e3o \u00e0 outra parte. Se descrever por palavras um produto que gostaria de construir, h\u00e1 uma grande probabilidade de o equipa de desenvolvimento<\/a> compreender\u00e3o a sua vis\u00e3o de uma forma diferente da que pretendia.<\/p>\n \u00c9 claro que \u00e9 poss\u00edvel evitar esta situa\u00e7\u00e3o. Deve come\u00e7ar a visualizar o mais cedo poss\u00edvel e discutir elementos individuais das funcionalidades do produto com base em esbo\u00e7os. Curiosamente, os primeiros esbo\u00e7os geralmente n\u00e3o t\u00eam nada em comum com o produto final. No entanto, nesta fase, o mais importante \u00e9 tornar a vis\u00e3o coerente.<\/p>\n Porque \u00e9 que a primeira e a segunda imagem s\u00e3o t\u00e3o diferentes? O chefe de projeto analisar\u00e1 sempre mais de perto a vis\u00e3o do produto. No entanto, \u00e9 importante que essa pessoa, essencialmente respons\u00e1vel por toda a<\/strong> software processo de desenvolvimento<\/a><\/strong>, compreende plenamente o problema e as necessidades relacionadas com o produto<\/strong>. O chefe de projeto deve ter uma \"vis\u00e3o global\" clara. Como pode ver, as duas imagens n\u00e3o diferem em termos de funcionalidade. Apenas t\u00eam um aspeto diferente. Para compreender melhor este ponto, voltemos \u00e0 imagem n\u00famero um. No in\u00edcio do projeto, n\u00e3o havia esbo\u00e7os e isso j\u00e1 deu origem a um mal-entendido. A funcionalidade do produto est\u00e1 correta, mas o design \u00e9 completamente diferente.<\/p>\n Por vezes, os analistas e os programadores n\u00e3o conhecem as necessidades dos utilizadores ou os objectivos comerciais estabelecidos. V\u00eaem apenas uma pequena parte de todo o projeto, que capta a sua aten\u00e7\u00e3o principal. N\u00e3o s\u00e3o capazes de olhar de uma perspetiva mais ampla, e isto \u00e9 particularmente o caso dos grandes projectos, onde muitos programadores trabalham ao mesmo tempo.<\/p>\n Podemos tamb\u00e9m utilizar outro exemplo. Pode acontecer que o problema a resolver seja incorretamente descrito, por exemplo, pelo propriet\u00e1rio do produto. Isto implica fornecer informa\u00e7\u00f5es incompletas sobre as quais o criador<\/a> ou designer criam as suas pr\u00f3prias interpreta\u00e7\u00f5es e o produto desvia-se cada vez mais da trajet\u00f3ria de desenvolvimento prevista.<\/p>\n Como mudar isso? Penso que uma boa solu\u00e7\u00e3o \u00e9 garantir que as pessoas que s\u00e3o fundamentais para o projeto tenham um conhecimento detalhado do mesmo - o chamado \"panorama geral\". Em caso de mal-entendidos, ser\u00e1 mais f\u00e1cil para elas trazerem a quest\u00e3o para o processo de desenvolvimento de software<\/em> 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\u00e3o tornam-se uma amea\u00e7a prov\u00e1vel.<\/p>\n Neste caso, a quest\u00e3o \u00e9 simples. O produto tem de vender. Tem de se destacar de alguma forma, para que, por exemplo, um simples baloi\u00e7o para o seu jardim atinja elementos extraordin\u00e1rios. A ideia \u00e9 convencer um potencial comprador. O departamento de marketing e vendas far\u00e1 certamente tudo para mostrar que o produto \u00e9 \u00fanico.<\/p>\n A falta de documenta\u00e7\u00e3o \u00e9 um problema muito comum. Por vezes, a cria\u00e7\u00e3o de documenta\u00e7\u00e3o durante desenvolvimento de produtos<\/a> parece uma perda de tempo desnecess\u00e1ria. Isso \u00e9 um erro. Eu digo muitas vezes que as mudan\u00e7as s\u00e3o feitas mais rapidamente no papel do que na c\u00f3digo<\/a>e h\u00e1 algo de bom nisso. Al\u00e9m disso, \u00e9 mais f\u00e1cil consultar a documenta\u00e7\u00e3o para acompanhar quaisquer altera\u00e7\u00f5es. Acredite em mim, um projeto sem documenta\u00e7\u00e3o corre um risco muito elevado de perder a vis\u00e3o.<\/p>\n Esta fase refere-se \u00e0 coloca\u00e7\u00e3o do ambiente no servidor. Tal como no ponto sobre os programadores e analistas, sem uma dados<\/a> e com falhas de comunica\u00e7\u00e3o, pode acontecer que apenas uma parte do ambiente necess\u00e1rio tenha sido criada.<\/p>\n \u00c9 o resultado de uma comunica\u00e7\u00e3o deficiente, da falta de UX<\/a> e assim por diante. O aparecimento de erros aumenta o tempo de desenvolvimento. E tempo \u00e9 dinheiro, certo? A minha sugest\u00e3o \u00e9 executar o projeto de acordo com o m\u00e9todo Agile<\/a><\/strong>A Comiss\u00e3o Europeia, por seu lado, tem o dever de manter os mais elevados padr\u00f5es de comunica\u00e7\u00e3o e de seguir orienta\u00e7\u00f5es or\u00e7amentais claras. N\u00e3o tenho d\u00favidas de que, se o fizer, evitar\u00e1 problemas deste g\u00e9nero.<\/p>\n Frequentemente, os clientes concentram-se apenas na constru\u00e7\u00e3o de um produto e ficam por a\u00ed. No entanto, vivemos uma \u00e9poca de muitas mudan\u00e7as e inova\u00e7\u00f5es tecnol\u00f3gicas, e \u00e9 por isso que \u00e9 necess\u00e1rio manter um suporte t\u00e9cnico constante. A ideia \u00e9 evitar uma situa\u00e7\u00e3o em que algo deixa de funcionar de repente, pois fica desatualizado e o produto perde o seu valor. Este aspeto tamb\u00e9m n\u00e3o deve ser esquecido.<\/p>\n Cheg\u00e1mos ao \u00faltimo ponto. Repare na discrep\u00e2ncia entre o primeiro e o \u00faltimo gr\u00e1fico. Afinal, ambos dizem respeito \u00e0 perspetiva do cliente. Porque \u00e9 que isto acontece? Toda a gente mente que \u00e9 t\u00e3o simples quanto isso \ud83d\ude42 Os resultados dos inqu\u00e9ritos diferem sempre das necessidades reais dos inquiridos. Ao responderem \u00e0 pergunta do investigador, os utilizadores querem mostrar o seu melhor lado. Por conseguinte, MUITAS VEZES N\u00c3O RESPONDEM COM SINCERIDADE<\/strong>mas sim de uma forma que acham que devem responder. Basicamente, n\u00e3o querem ser expostos \u00e0 avalia\u00e7\u00e3o negativa dos outros. Aqui fica uma pequena dica: mencione nas instru\u00e7\u00f5es que n\u00e3o h\u00e1 respostas boas nem m\u00e1s.<\/p>\n Onde \u00e9 que as diferen\u00e7as aparecem? \u00c9 frequente as pessoas n\u00e3o 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.<\/p>\n Ent\u00e3o, como \u00e9 que se resolve este problema? Para al\u00e9m de perguntar aos utilizadores o que querem e precisam, permita-lhes testar o produto, de prefer\u00eancia em artigos aut\u00eanticos para manter a credibilidade. Quanto mais testes durante a cria\u00e7\u00e3o dos produtos, maior a chance de o resultado ser preciso.<\/p>\n Se alguma vez se tornar membro de uma desenvolvimento de software<\/a> projeto, lembre-se dos meus exemplos e tire conclus\u00f5es para n\u00e3o copiar os erros acima referidos. E lembrem-se, estes conceitos s\u00e3o muito importantes na constru\u00e7\u00e3o de um produto (aplica\u00e7\u00e3o) de raiz:<\/p>\n - boa experi\u00eancia do utilizador e testes, para que possa saber o que os seus utilizadores realmente precisam,<\/p>\n - comunica\u00e7\u00e3o no \u00e2mbito do projeto, para que as pessoas-chave do projeto tenham uma compreens\u00e3o profunda do problema e das necessidades,<\/p>\n - desenvolver o produto em conformidade com \u00c1gil<\/a>,<\/p>\n - n\u00e3o se esque\u00e7a do apoio t\u00e9cnico.<\/p>\n Ler mais:<\/strong><\/p>\n - Como gerir eficazmente os programadores remotos? O guia para CTOs<\/a><\/p>\n - Python vs. Ruby? Que tecnologia deve utilizar para o desenvolvimento de produtos?<\/a><\/p>\nConheces esta fotografia, certo?<\/h2>\n
1. Como \u00e9 que o cliente explicou a ideia?<\/strong><\/h2>\n
2. Como \u00e9 que o chefe de projeto o entendeu?<\/strong><\/h2>\n
3. Como \u00e9 que o analista o concebeu? e<\/em><\/strong> 4. Como \u00e9 que o programador o escreveu?<\/strong><\/h2>\n
5. Como \u00e9 que o consultor comercial o descreveu?<\/strong><\/h2>\n
6. Como foi documentado o projeto?<\/strong><\/h2>\n
7. Que opera\u00e7\u00f5es foram instaladas?<\/strong><\/h2>\n
8. Como \u00e9 que o cliente foi facturado?<\/strong><\/h2>\n
9. Como \u00e9 que foi apoiado?<\/strong><\/h2>\n
10. O que \u00e9 que o cliente realmente precisa?<\/strong><\/h2>\n
Resumo<\/strong><\/h2>\n