Como abordar o ol '"isso será apenas uma pequena aplicação"? Okay, certo?

Ok, eu já me deparei com isso muitas vezes, mas aqui está o pior cenário, um pouco exagerado.

Um cliente diz "ei, você pode nos tornar esse pequeno módulo para fazer essa pequena tarefa"?
Eu: "Claro que não há problema".

Portanto, com base em orçamentos, restrições, etc., pulo parte da arquitetura e mergulha direto e não suporto.

Então eles pedem outro módulo. E outro. E algumas melhorias. E tudo isso acontece muito lentamente, durante anos. E antes que você perceba, você tem esse aplicativo monstro que é horrivelmente arquitetado.

O que você faz quando lhe pedem para fazer algo pequeno? Você não sabe se ele continuará crescendo ... se o cliente continuará pedindo acréscimos (e nem eles).

Você não pode arquitetar demais a coisa, porque afinal é apenas um aplicativo pequeno, e eles irão para outro lugar se você disser (no sentido de que conheço toda a voz) "Bem, só para garantir, vamos arquitetar essa coisa em camadas com top segurança e separação de preocupações. De fato, vamos usar uma ferramenta de injeção de dependência que realmente tornará essa coisa fantástica blá blá blá ".

Eles vão dizer "sim, certo" e vão para outra pessoa.

Orçamento, tempo e percepção são tão importantes quanto a arquitetura do próprio aplicativo.

Como isso deve ser abordado?

Eu acho que a pergunta realmente se resume a "Quando você não tem todas as informações para o resultado final do que parece ser um aplicativo pequeno, como você evita (ou atenua) a tomada de decisões arquiteturais e de design desde o início?" inapropriado mais tarde?

Já deparei com algumas delas e o que normalmente faço é exatamente o que você fez, mergulhe e faça tudo.

Quando eles voltam para mais, isso significa que seu modelo de negócios está funcionando e que eles devem estar dispostos a investir um pouco mais. É quando eu os sento (normalmente o terceiro módulo, dependendo da complexidade) e digo as más notícias.

Vou colocar tudo sobre a mesa, oferecer refazer tudo, incluindo o módulo mais recente, e dizer a ele quanto vai custar. Eles geralmente terão algum choque de etiqueta no início, mas se você tiver um bom relacionamento de trabalho e suas coisas funcionarem, não será um grande problema.

Certifique-se de que eles entendam três coisas:

1. Se eles realmente não quiserem se preocupar com uma reescrita completa, você ainda fará o terceiro módulo. Pode levar mais algumas horas e você será cobrado por isso. Lembre-os de que eles realmente devem pensar em reescrever no futuro, porque quanto mais esperar, mais custará.

2. Realmente vai custar-lhes mais para conseguir que alguém faça isso. A nova pessoa precisa reprojetar tudo com o mínimo de compreensão de suas necessidades e peculiaridades, o que significa tempo de reescrita extra e o risco de que ela não faça um trabalho tão bom.

3. Que você não está tentando ganhar dinheiro rápido. A coisa precisa de um re-design.

BTW, se seu hábito de cobrança é algo como metade agora, metade quando terminar, considere oferecer condições de pagamento estendidas. Mude para metade agora e divida o saldo no período em que você trabalhará nele. Isso pode diminuir a pressão se eles tiverem problemas de orçamento.

Basta fazer dele um aplicativo pequeno e ser pago por isso.

Na minha experiência, é convincente investir mais tempo no início do que realmente necessário, caso o cliente queira mais. Mas você tem que ponderar o esforço para fazê-lo (você é pago por isso) versus a probabilidade de que todas essas mudanças adicionais realmente ocorram. Todo o aplicativo pode ser substituído completamente após um ano.

E investindo tempo na arquitetura inicial, você pode sentir que faz um favor a si mesmo. Mas, na verdade, você apenas faz um favor ao cliente, tornando os outros módulos mais baratos para ele.

Apenas fature um pouco mais o seu cliente por cada módulo bem-sucedido e refatore o projeto inicial passo a passo, mas sempre apenas para atender às necessidades do cliente.

Respostas anteriores são boas e, se eu for honesto, o que eu provavelmente faria. Dito isto, estou um pouco desconfortável com essa abordagem, pois você está tomando decisões que pertencem corretamente ao cliente, com base na suposição do que ele deseja (e no desejo de conseguir o emprego)

Não posso deixar de pensar que alguém deve fazer é ser honesto com o cliente e dar a ele a opção: 1. Eu posso fazer isso rapidamente e (relativamente) mais barato agora. Vai ser ótimo - vai funcionar -, mas os aprimoramentos futuros custarão um pouco mais de forma incremental 2. Posso gastar mais tempo com isso antecipadamente, o que custará um pouco mais e não acrescentará nenhum benefício real aos usuários, MAS você economizará dinheiro a longo prazo se precisar adicionar novos recursos.

Idealmente, você poderá fornecer a eles algumas figuras de tempo / custo - caso contrário, a conversa pode ser muito acadêmica -, mas compreendo que chegar a esses números também pode exigir esforço. Pelo menos, enquadrar a discussão em termos de projetos anteriores facilitaria a vida do cliente (e facilitar a vida do cliente deveria ser uma prioridade :-))

Os comentários de outras pessoas sobre ter um bom relacionamento de trabalho estão no local - mas você pode iniciar esse processo sendo honesto. Se o cliente é do tipo com o qual você não pode ter essa conversa, agora é a hora de se perguntar quanto você precisa desse trabalho ...

Eu trataria cada uma dessas "iterações" como um projeto separado. Você deve encerrar esses projetos quando cada pequeno módulo ou adição terminar. Então, quando quiserem outra coisa, rascunhe a papelada. E com o passar do tempo, o software se torna mais caro ... o que significa que você está cobrando mais por cada projeto pequeno.

É uma maneira de ver, em vez de um ... Projeto LONGGGGGG.

como você evita (ou atenua) a tomada de decisões arquiteturais e de design desde o início, que será completamente inadequada mais tarde?

Você não pode . Programadores não são médiuns. Embora possamos prever coisas simples ou ver melhorias na interface do usuário, não podemos realmente codificar além do que não sabemos que o cliente pode desejar mais tarde (você vê a loucura aí?).

Sua pergunta mencionou que havia processos de negócios, mas não tenho certeza se são bons processos. Aqui estão algumas dicas:

• Exija todas as alterações e adições assinadas por escrito e com um orçamento.
  • Porque você tem contas a pagar
  • A parte escrita e assinada garante que é o que eles realmente querem e reduz 90% das coisas frívolas que os clientes mudam de idéia no meio do caminho durante o projeto

Seu produto coberto

Isso acontece com todos nós. Reconstruir a partir do zero geralmente é uma péssima idéia, especialmente considerando que será feito novamente no futuro.

Em vez disso, contrataria as alterações solicitadas pelo usuário. Adicione tempo extra para cada recurso, usando o tempo original para trabalhar no recurso e o tempo extra para melhorar a arquitetura geral, uma pequena melhoria por vez. O objetivo não é "consertar" completamente a arquitetura em um contrato, mas em vez disso a lasca lentamente ao longo do tempo.

Melhore lentamente a iteração de código por iteração, concentrando-se nas partes que realmente importam.