Devo incorporar o custo de saída na escolha de uma solução

10

Atualmente, estou escolhendo entre dois projetos / soluções viáveis de software. A solução 1 é fácil de implementar, mas bloqueará alguns dados em um formato proprietário e dificilmente será alterada posteriormente. A solução 2 é difícil de implementar, mas será muito mais fácil mudar posteriormente.

Devo ir YAGNI nisto ou devo incorporar o custo de saída na tomada de decisão? Ou, perguntando de forma diferente, o custo de saída faz parte do TCO?

Estou pensando em voltar ao cliente para perguntar se ele acha ou não os custos de saída relevantes, mas eu gostaria de saber o que a comunidade pensa primeiro.

PS O custo de saída é o termo correto?

— dvdvorle
fonte

Você pode adicionar por que você acha que a primeira solução bloqueará os dados e será difícil mudar mais tarde?

— 11409 Jaap

Em essência, nem todos os formatos são proprietários, mesmo os que são supostamente 'padrão' ou 'abertos'? Yagni provavelmente se aplica se o formato 'proprietário' for mais fácil de implementar, fácil de usar e / ou o formato defacto para troca.

— JustinC

Sem entrar em detalhes; pense nisso como colocar uma planilha do Excel (projetada pelo cliente) em um sistema de gerenciamento de documentos (solução 1), em vez de criar as tabelas e GUIs apropriadas e gerar a planilha do Excel sob demanda (solução 2). Exceto que não é o Excel.

— dvdvorle

No entanto, isso provavelmente não impede a observação desse aspecto de preocupação em apresentar a escolha e a decisão ao patrocinador do projeto.

— JustinC

@ JustinC bem, eventualmente, estamos falando de dinheiro aqui. É mais barato usar o formato 'proprietário' a longo prazo ou não? Isso é o que eu acho que é mais importante para o patrocinador do projeto

— dvdvorle

4

O custo de saída faz parte do TCO (o T representa o total ), mas é difícil determinar a menos que você saiba a priori quanto tempo o sistema vai durar. Em outras palavras, se você souber que o sistema será usado por exatamente um ano e custará US $ 52.000 para desativá-lo daqui a um ano, você pode estar bastante confiante em adicionar US $ 1.000 por semana ao orçamento operacional para cobri-lo.

Esse modelo sai pela janela quando você não conhece a vida útil do sistema. O sistema poderia, em teoria, permanecer em uso para sempre, o que significa que não haverá dinheiro gasto para desligá-lo. Qualquer coisa que você incluir agora será em dólares de hoje, e esses números podem não ter sentido daqui a cinco anos, devido a mudanças nas taxas de trabalho e na tecnologia que tornam o processo mais fácil (ou mais difícil).

É melhor dar ao seu cliente uma idéia do que é necessário para se afastar do sistema e deixá-lo levar isso em decisões sobre a substituição quando chegar a hora.

(E agora, depois de escrever esta resposta, posso votar para encerrar isso como um tópico fora do assunto.)

— Blrfl
fonte

A alternativa para o custo de saída fazer parte do custo total de propriedade desta solução seria que ele faria parte do custo total de propriedade da próxima solução. Agora eu sei que isso soa estranho se eu disser dessa maneira, mas, na minha experiência, o custo de descomissionamento de um sistema faz parte do plano / orçamento do projeto do próximo sistema, não do plano / orçamento do sistema atual. Isso faz sentido?

— Dvdvorle

11

Faz sentido para mim, e essa é a conclusão que cheguei. Você não pode realmente chegar a um total real até que tudo acabe.

— Blrfl

Concordo com as dificuldades de estimar com precisão os 'custos de saída', acho que há valor em fornecer um mesmo que esteja no dinheiro de hoje. Compare "isso seria difícil e demorado" e "isso provavelmente custaria entre US $ 25.000 e US $ 50000 se fosse feito amanhã".

— vaughandroid

@Blrfl, o que torna essa pergunta fora de tópico?

— 31412 ne nepirpir

11

@neontapir: A questão principal é realmente sobre gerenciamento de projetos; o fato de ser sobre um programa não é realmente sobre programação. O mesmo poderia se aplicar com a mesma facilidade a comutadores telefônicos ou fornos de pizza.

— Blrfl

2

YAGNI é uma ótima regra em seu lugar, mas não tenho certeza de que deve se aplicar neste caso. Você está estimando custos futuros aqui, uma atividade que deve envolver alguma consideração sobre futuras alterações de requisitos. Se você estivesse escrevendo a implementação, seria uma história diferente!

Eu sugiro que você faça o custeio, mas verifique se o cliente entende por que você o fez. Se eles não forem muito técnicos, não se surpreenda se disserem algo como "não pode ser uma boa solução se você já estiver pensando em usar outra coisa!"

Pode haver alguns aspectos mais detalhados a serem considerados ao fazer / apresentar suas estimativas de custo:

Qual a probabilidade de os dados serem migrados para outro sistema no futuro?
É provável que o fornecedor da solução altere seu próprio formato de dados para que seja mais fácil / difícil migrar os dados no futuro? Em caso afirmativo, isso afetará sua solução?
Mesmo que você não queira alterar os dados posteriormente, há uma chance de que você queira apresentá-los / acessá-los de maneira diferente? Minha experiência é que isso é bastante comum!

— vaughandroid
fonte

1

Trabalhando a partir do seu comentário sobre a situação do arquivo do Excel, considero-o como:

não alterando o formato atual (solução 1)
versus analisar o formato agora e armazená-lo em um formato diferente (possivelmente / possivelmente mais adequado / pronto para o futuro) (solução 1 + etapa de análise, também conhecida como solução 2)

Eu acredito que YAGNI se aplica a essa etapa de análise; certifique-se de manter o conhecimento sobre a estrutura atual, mas não implemente a análise ainda.

Além disso, a estrutura de dados analisados pode não ser tão flexível quanto você pensa; os requisitos também podem ser usados para armazenar informações / arquivos diferentes, o que significa que você precisa atualizar / expandir suas tabelas.

— Jaap
fonte

Para ficar claro, atualmente não há solução (solução 0, se você preferir). Atualmente, eles mantêm todas as informações em arquivos em papel. Concordo plenamente com esta resposta se eles já usaram o arquivo "Excel" no sistema de gerenciamento de documentos, mas ainda há uma opção aqui.

— Dvdvorle

Ou você acha que isso não é relevante porque a implementação da solução 1 é barata?

— dvdvorle

O que quero dizer é que acredito que se a solução 2 pode ser considerada um aprimoramento da solução 1, mas esse aprimoramento não é estritamente necessário agora, o YAGNI se aplica.

— Jaap

Eu vejo o que você quer dizer. É algo para se pensar. Embora eu ache que está na hora de ir ao cliente agora, veja o que ele pensa sobre isso como uma melhoria e outros enfeites.

— dvdvorle

0

Se você não tiver 95% de certeza de que será alterado no futuro - Solução 1 - YAGNI =)

Certamente, isso depende de seus clientes e de sua experiência em programar algo para esse cliente.

— MikroDel
fonte

2

Então você está dizendo que qualquer custo relacionado à chance de 5% de a solução mudar é irrelevante?

— dvdvorle

Quero dizer que este algum tipo de sentimento ... Você conhece a si mesmo o que significa "YAGNI" - o resto é sentimento =)

— MikroDel

0

Na minha experiência, as rodas reinventadas levam mais tempo para reinventar do que você pensa, e as rodas externas tendem a ser mais fáceis de substituir. Ambos os tipos de rodas tendem a parecer piores depois de comprados do que quando você tomou sua decisão.

Se você realmente acha que o número 1 é fácil de implementar e está questionando quanto tempo o número 2 levará, eu ouviria a pergunta. Implemente o número 1 agora e pense no design maior à medida que avança. Isso o ajudará se você quiser reinventá-lo posteriormente.

Por outro lado, se o item 1 não parecer mais tão fácil quanto você pensava, pule para o item 2.

— btilly
fonte