Quão importante é conhecer a funcionalidade antes da codificação?

Eu trabalho para uma empresa de desenvolvimento de software onde o trabalho de desenvolvimento nos foi esquecido. A equipe em terra lida com o suporte e conversa diretamente com os clientes. Nunca conversamos diretamente com os clientes, apenas conversamos com pessoas da equipe on shore, que conversam diretamente com os clientes.

Quando os requisitos chegarem, a equipe em terra conversará com os clientes, fará os documentos de requisitos e nos informará. Criamos documentos de design depois de estudar os requisitos (seguimos o modelo tradicional em cascata).

Mas há um problema em todo o processo: ninguém na equipe offshore ou onshore entende a funcionalidade do aplicativo completamente. Sabemos apenas que é um aplicativo Web complexo e grande que lida com processamento complexo de pedidos, gerenciamento de catálogos, gerenciamento de campanhas e outras atividades. Lutamos com o documento de design, pois os requisitos não seriam claros. Em seguida, ele entra em uma série de perguntas / respostas entre a equipe on shore, a equipe off shore e os clientes. Frequentemente nos diziam para entender a funcionalidade do código. Mas isso geralmente não é viável, pois a base de código é enorme e até a compreensão de um item de menu simples leva dias, se não semanas. Tentamos dizer aos clientes para nos dar transferência de conhecimentosobre o aplicativo, mas sem sucesso. Nosso gerente costumava nos dizer para começar a codificar, mesmo que o documento de design não esteja completo ou os requisitos não estejam claros. Começamos codificando a parte dos requisitos que parece clara e aguardamos o resto.

Isso normalmente atrasaria a implantação em um mês. Em casos extremos, teríamos erros muito baixos no desenvolvimento e na produção, mas os clientes diriam que não foi isso que pediram. Isso iniciaria um jogo de culpa e uma série de solicitações de mudança e acabaríamos desenvolvendo algo muito diferente.

Minha pergunta é como você faria o trabalho de desenvolvimento se não conhecesse completamente a funcionalidade do aplicativo?

ATUALIZAR

A metodologia de desenvolvimento não é realmente minha escolha e não sou o líder da minha equipe. É assim que tudo começou. Tentei falar às pessoas sobre as vantagens do ágil, mas sem sucesso. Além disso, não acho que minha equipe tenha a mentalidade necessária para trabalhar em um ambiente ágil.

Versão curta:

Saber o que fazer, conhecer seu cliente.

Imagine o seguinte: você é uma empresa relacionada ao desenvolvimento imobiliário. Você pede ao seu parceiro para construir um grande complexo. O parceiro diz que, apesar de todos os documentos que você forneceu, ele também precisa conversar diretamente com as pessoas que comprariam os apartamentos neste complexo. A sério?

Versão longa:

É sempre bom saber como um aplicativo específico será usado, porque é divertido aprender coisas, mas nem sempre é possível em projetos grandes.

Alguns domínios são muito complexos. Se você é apenas um desenvolvedor e trabalha em vários aplicativos de vários domínios, nem sempre consegue entender o que o usuário final está fazendo , porque exigiria que você passasse cinco anos aprendendo contabilidade, dez anos na faculdade de medicina, seis anos na faculdade de direito, etc.

Por outro lado, um produto de software fabricado sem a compreensão do domínio específico será, na melhor das hipóteses, um pouco inutilizável .

É por isso que os requisitos funcionais e não funcionais devem ser escritos por pessoas que entendem completamente o domínio. Em geral, a coleta de requisitos envolve ao mesmo tempo:

1. Técnicos (por exemplo, desenvolvedores que diriam que um recurso específico é impossível, que este outro pode ser muito melhor se for feito dessa maneira, e isso custará milhares de dólares enquanto houver uma alternativa muito mais barata),

2. Pessoas especializadas em gerenciamento de projetos,

3. Pessoas especializadas no domínio do cliente , que têm o entendimento completo desse domínio e as necessidades precisas do cliente. Obviamente, esse pode ser o próprio cliente.

Um requisitos funcionais e não funcionais são escritos e são precisos o suficiente; você não precisa de mais nada como pessoa cujo trabalho é traduzir esses requisitos em código.

Quanto ao seu caso específico, você descreve a causa do problema:

Lutamos com o documento de design, pois os requisitos não seriam claros.

Não é a falta de conhecimento sobre o cliente que causa todo o problema , é a baixa qualidade dos requisitos. Em um projeto gerenciado corretamente, os requisitos funcionais e não funcionais devem ser perfeitamente claros e inequívocos. Se o documento de requisitos não é claro ou se diz que "o design visual do produto deve ser atraente" ou outras estupidez como essa, é porque foi escrito por pessoas que não sabem como escrevê-lo.

Sabendo disso, você deve agir de maneira diferente:

• Se você sabe que a equipe que reúne os requisitos está desesperada e sua equipe possui pessoas qualificadas para a coleta de requisitos, explique a situação ao seu superior e diga que a outra equipe deve ser substituída por alguém competente , por exemplo, pessoas suas.

• Caso contrário (ou seja, se eles não estiverem desesperados), tente determinar a causa interna desses baixos requisitos e convencê-los de que fazer seu trabalho corretamente reduzirá apenas o custo geral do projeto . Mostrar as estatísticas sobre o quanto os requisitos mal escritos influenciaram o projeto, aumentando o custo (quanto?) E o risco de não estar pronto para o prazo final é uma boa idéia aqui.

Provavelmente o documento de requisitos está incompleto. Vejo isso o tempo todo: gerentes de projeto inexperientes estão convencidos de que o documento de uma página é suficiente e não entendem por que escreveriam de trezentas a quatrocentas páginas em vez de uma. Se for o caso da sua empresa, mostre que gastar mais tempo com os requisitos diminuiria os custos.

Você está usando exatamente a metodologia de desenvolvimento errada para os problemas que está enfrentando.

Ao usar o Waterfall, você está se comprometendo a:

1. Obtendo os requisitos certos com antecedência - isso obviamente não está funcionando
2. Codificando os requisitos para longe do cliente - você não consegue verificar efetivamente os problemas com o cliente, desde que se comprometeu a desenvolver os requisitos
3. A primeira chance do cliente ver sua funcionalidade é durante o teste - é tarde demais, considerando os problemas que você está tendo

Considere usar, se possível, uma maneira diferente de gerenciar o projeto. O Agile Software Development possui vários recursos projetados para resolver os problemas que você está enfrentando.

Uma comparação decente de Waterfall vs Agile foi escrita há um tempo, vamos fazer algumas citações que destacam seus problemas:

Faltando a marca:

Depois que um estágio é concluído no método Waterfall, não há como voltar atrás, pois a maioria dos softwares projetados e implementados no método waterfall é difícil de mudar de acordo com o tempo e as necessidades do usuário. O problema só pode ser resolvido voltando e projetando um sistema totalmente novo, um método muito caro e ineficiente.

Amarrado...

Os métodos ágeis permitem alterações nas especificações conforme os requisitos do usuário final, gerando satisfação com o cliente. Como já mencionado, isso não é possível quando o método em cascata é empregado, pois qualquer alteração a ser feita significa que o projeto deve ser iniciado novamente.

... e não é possível mover

Para sincronizar a diferença entre os dois, pode-se dizer que o método cascata clássico representa previsibilidade, enquanto a metodologia Agile indica adaptabilidade. Os métodos ágeis são bons para reduzir os custos indiretos, como justificativa, justificativa, documentação e reuniões, mantendo-os o mais baixo possível. E é por isso que os métodos Agile beneficiam equipes pequenas com requisitos em constante mudança, em vez de projetos maiores.

Onde você está agora é ruim; você não está atendendo aos requisitos do cliente e, se você é o culpado pelo desenvolvimento de software, a produtividade diminui, a desconfiança aumenta e as coisas provavelmente pioram, e não melhor.

O relacionamento com o cliente é crítico ; aqui, parece que você não é capaz de coletar efetivamente os problemas deles e se adaptar às mudanças nos requisitos da maneira como trabalha atualmente; portanto, você precisa procurar maneiras de mudar isso.

Não é assim que funciona. Um dos assuntos da minha formação atual é o de análise e o relacionamento com um cliente. A ênfase sempre esteve na definição clara do projeto. Imagina isto:

• Você ordena que uma empresa de construção construa uma casa, mas não sabe como deseja que ela seja. Você acabou de personalizar o primeiro andar, para que a equipe construa uma casa até o primeiro andar. Então você deseja que o térreo seja disposto de maneira diferente. Opa ...

A menos que você tenha certeza de que pode (parcialmente) criar as bases corretas para o aplicativo, eu diria ao cliente que não há outra maneira de fazê-lo a não ser com objetivos e funcionalidades claramente definidos. Porque se você der uma facada no que pode ser, corre o risco de jogar muito dinheiro e tempo pelo ralo.

Aqui estão algumas coisas que ajudarão a superar os problemas:

1. Melhore a comunicação entre as duas equipes. Peça à outra equipe para compactar o requisito em 3 palavras e o programador implementará essas palavras exatamente. As palavras só precisam estar corretas. Nada será implementado sem essas palavras. Cada palavra fornece 2000 linhas de código. A implementação começa quando uma nova palavra é conhecida.
2. Se uma palavra não for imediatamente clara para seus programadores, eles poderão fazer uma única pergunta . A questão novamente precisa ser correta. Ele precisa de resposta imediata - a resposta não pode esperar uma ida e volta de outro lado do mundo, mas precisa ser conhecida de antemão. A implementação começa imediatamente após o recebimento da resposta e a resposta será seguida à risca.
3. Se durante a implementação houver requisitos pouco claros ou confusos, a maneira de resolvê-los é primeiro olhar para as 3 palavras (existentes). Se ainda não está claro, o programador faz o melhor palpite possível . Qualquer atraso neste processo é absolutamente proibido; e pedir ajuda à outra equipe não é o caminho certo para resolvê-lo - eles já tiveram a chance de alterar os requisitos ao decidir três palavras corretas.
4. Se depois de tudo isso, o requisito ainda não for claro ou impossível de implementar, a maneira correta de lidar é rejeitar as três palavras que causaram o problema e passar para as próximas. Quaisquer palavras rejeitadas serão coletadas e passadas para a outra equipe, e elas precisarão modificar as palavras antes de digitá-las novamente no sistema. A rejeição de palavras sempre muda o prazo e a implementação precisará ser planejada novamente.
5. As equipes precisariam ser avaliadas com base em quantas palavras rejeitadas elas tiverem. Após a implementação do requisito, ele é corrigido para sempre e não pode mais ser alterado . Qualquer tentativa de alterar os recursos já implementados será rejeitada.
6. O problema real da pergunta é que ela supõe que mais informações facilitam a implementação. Isso não é verdade. Quanto mais liberdade seus programadores tiverem, mais fácil será a implementação . A compactação dos requisitos permite a comunicação de grandes quantidades de informações sem restringir muito o que os programadores podem fazer.