Quanto costa in manutenzione / aggiornamenti?

-1

Sono interessato a come le aziende costano nel mantenimento del software e / o al miglioramento della qualità del codice nel tempo.

Il contesto che vorrei aggiungere, non è quello di un'azienda che ha un singolo prodotto in cui tutte le sue risorse sono dedicate a questa area, più una società che sviluppa molti progetti più piccoli all'anno per una gamma di clienti. / p>

Il mio esempio immaginario potrebbe essere quello di un'azienda di web design, diciamo che hanno 10 clienti e un team di 10, ci sono 5 siti / progetti live esistenti che hanno un piccolo contratto di manutenzione in atto per consentire costi di hosting e ampli ; correzioni di errori urgenti. Ci sono 5 progetti attivi, diciamo con un budget di £ 10.000 che è destinato allo sviluppo attuale. Con un contratto di manutenzione potenziale per dire £ 1000 per coprire le correzioni di hosting / urgenti.

Una volta consegnati questi progetti più piccoli e personalizzati, in che modo le aziende vendono il costo della manutenzione continua al cliente? La maggior parte dei clienti sembra capire che l'hosting comporta un costo e che correzioni / modifiche comportano costi, ma non ho idea del modo migliore per vendere il concetto, ad esempio aumentare la copertura dei test o il refactoring del codice per migliorare la manutenibilità.

Assumerei che molti clienti presumessero che tale qualità sarebbe già integrata nella fattura originale, quindi la qualità della vendita sembra difficile. Tuttavia, l'aumento del prezzo per adeguarsi alla qualità della mazza potrebbe rendere la società meno competitiva nel prezzo.

Sono curioso dei pensieri delle persone in questa area o di trucchi e suggerimenti che potrebbero valerne la pena.

    
posta dougajmcdonald 17.10.2017 - 09:18
fonte

2 risposte

2

Nessun cliente paga per "aumentare la copertura del test o i refactoring del codice", paga per correzioni di bug e nuove funzionalità.

(supponendo che il tuo cliente non sia uno stesso venditore di software che ha acquistato una libreria da te.)

Queste cose non sono un fine in sé, sono un mezzo per un fine, che è quello di mantenere la fonte mantenibile e evolvibile . Quindi dovrebbe essere nel proprio interesse di qualsiasi fornitore di software professionale investire qualche sforzo in cose come la copertura dei test e i refactoring per qualsiasi prodotto attivo, con l'obiettivo di mantenere lo sforzo complessivo di correggere i bug o aggiungere nuove funzionalità - insieme allo sforzo per refactoring - il più basso possibile.

Naturalmente, ogni volta che un venditore di software vende un prodotto, probabilmente desidera motivare il cliente ad assegnare un contratto di manutenzione il più a lungo possibile. Quindi è spesso una buona idea, finché esiste un contratto di manutenzione, per distribuire automaticamente le nuove versioni di un prodotto, comprese correzioni di bug e alcune nuove funzionalità, per tenerlo visibile al cliente che il suo investimento nella manutenzione lo ripaga . Ma il modo in cui il venditore raggiunge questo obiettivo come il più economico possibile dipende da lui, non è la preoccupazione del cliente.

Se la tua azienda non ha compiti di manutenzione per uno specifico software, e il software non si evolve ulteriormente, non ha senso fare alcun refactoring. Se non si prevede che un pezzo di software o un modulo all'interno del programma venga toccato per i prossimi anni, non ha senso applicare i principali refactoring a questo modulo specifico.

Quindi, in breve, è sempre un compromesso. I refactoring e i test sono un tipo di investimento e devono essere bilanciati dal potenziale sforzo e dai rischi che ci si aspetta senza di loro.

    
risposta data 17.10.2017 - 10:10
fonte
2

La risposta semplice è che non lo fanno.

I clienti percepiscono la qualità sono termini dell'esperienza utente. Se agli utenti piace il software, il software è buono.

Inoltre, quando viene introdotto un nuovo software, se agli utenti non piace, ciò può essere attribuito alle specifiche piuttosto che all'implementazione. per esempio. Gli utenti odiano dover cliccare due volte quel pulsante, ma abbiamo specificato che doveva essere così per motivi di lavoro.

Inoltre, al momento dell'acquisto del software, il cliente avrà firmato l'interfaccia utente e il design e non cambierà nel tempo.

Quindi di solito "software cattivo" si riferisce ai bug trovati dopo la vendita. Questi non saranno visti come oggetti a pagamento dal cliente e ci saranno varie clausole contrattuali per limitare il modo in cui l'uomo viene riparato gratuitamente.

Nel tuo esempio di azienda del sito web, non toccheranno il codice per i siti web a meno che il cliente non abbia accettato di pagare per una nuova funzionalità. Questo è quando cose come la copertura del test unitario sono utili. Come ti impediscono di rompere le altre funzionalità quando aggiungi quella nuova.

Ma stanno aumentando il tuo profitto, non i clienti. Quindi di solito non li menzioni, altrimenti il cliente potrebbe girarsi e dire "Oh ok, quindi puoi fare la nuova funzione con meno soldi!"

    
risposta data 17.10.2017 - 13:20
fonte

Leggi altre domande sui tag