Valutazione della manutenzione del software

1. Quando trattare un software come distribuito e quando iniziare a caricare per la manutenzione?

Quando la Dichiarazione di lavoro è completa, il lavoro è terminato. Se non hai un SoW, sei troppo informale sulla creazione di software per gli altri, e inevitabilmente entrerai in disaccordo con i tuoi clienti, e potresti essere minacciato da cause legali.

Tutto ciò che non è coperto da SoW non rientra nell'ambito del progetto a pagamento. Se scegli di farlo comunque, di solito è una buona idea assicurarti che il cliente sappia che stai dando loro un omaggio - clienti come gli omaggi, e ricorda loro che il prossimo potrebbe costare loro.

2. Come caricare la manutenzione del software?

Il 18% del prezzo di acquisto corrente è una tariffa di manutenzione annuale comune per il software acquistato. Alcuni fornitori riescono a ottenere fino al 20%, ma più di questo è insolito. Se strutturi la tua manutenzione in questo modo, il cliente generalmente ottiene qualsiasi cosa tu faccia, indipendentemente da quanto o quanto poco tempo ci vuole.

L'altro modo per farlo è il modo in cui gli avvocati fanno - chiedi un fermo, che è in realtà solo un pagamento anticipato per il lavoro a una tariffa oraria stabilita. Se il lavoro non consuma molte ore, il cliente riceve il pagamento in eccesso. Se il lavoro lo superasse, parli con il cliente di un pagamento aggiuntivo, a volte in anticipo, a volte in arretrato.

3. Come caricare i miglioramenti specifici non dell'applicazione?

Se addebiti una Commissione di manutenzione annuale, che in genere include altri miglioramenti e rilasci effettuati. In realtà, tali commissioni sono solitamente denominate "M & E" nel business del software - "Manutenzione e miglioramento" - proprio per questo motivo. Non è un "upgrade gratuito", è parte di ciò che il cliente sta pagando.

4. Come si fa pagare per la manutenzione in caso di contratti orari?

Vedi la mia risposta al n. 1. Se hai una dichiarazione di lavoro, è facile vedere cosa c'è dentro e fuori dall'ambito e negoziare i risultati.

Dalla tua domanda deduco che non stai facendo uno sviluppo basato su test.

Il modo migliore per passare dallo sviluppo alla modalità di manutenzione è con un'accettazione formale da parte del cliente se fossero d'accordo "Sì, il software fa tutto ciò che avevamo originariamente richiesto". Naturalmente è necessario un modo obiettivo per determinare se il software soddisfa effettivamente gli obiettivi, cioè un piano di test formale. Se scrivi il test prima di scrivere il software, (sviluppo guidato da test), questa dovrebbe essere una parte naturale del processo.

Parli di "conoscere le modifiche richieste che creano un mucchio di lavoro extra per noi". Questo dovrebbe essere parte di un "ordine di lavoro di cambiamento" scritto e valutato di conseguenza. Ovviamente parte del lavoro (a supporto del cambiamento) include la modifica dei test formali. Non prenderlo troppo alla leggera, molte aziende (gli appaltatori del governo vengono in mente) fanno molto di più sugli ordini di lavoro di cambiamento di quanto non facciano sul contratto originale. (quanto costa fare una barca grigia - $ 100.000 ... Siamo a metà, potresti dipingerlo di bianco? Sicuri che sarà un extra di $ 75.000) Se sei troppo libero per non pagare (e aggiustare la consegna orari) quindi "funzionalità di scorrimento" ti ucciderà.

Per quanto riguarda la "manutenzione", ancora una volta è necessario definire chiaramente i termini. Strettamente parlando, la manutenzione sarebbe limitata agli articoli specificati nella dichiarazione di lavoro originale, ma che il piano di test non è riuscito a testare. Ad esempio, supponiamo che il contratto originale richiedesse che l'informazione su di noi fosse fatta in caratteri Newton Roman da 14 pt e che per qualche motivo fosse fatto con font a 13 punti e il piano di test non verificasse se fosse stato usato il carattere corretto. Poi sei mesi dopo il parto qualcuno scopre l'errore e ti chiede di correggere questo difetto latente; questa è la manutenzione Se comunque usi il font corretto, chiamano e dicono "Conosci la pagina Chi siamo con il 14 pt New Times Roman?". Potresti invece renderlo Helvetica 16 pt? " - beh quella non è manutenzione, è un cambiamento. Questo è quello che etichetterei "break / fix" e penserei che il client non dovrebbe essere addebitato per questo.

Tutte queste cose sono molto soggettive e si basano su quali sono le aspettative dei tuoi clienti.

La tassa di manutenzione sembra essere in un range ragionevole, e corrisponde alle mie aspettative per questo - l'idea non è che si carica il cliente per ogni piccola manutenzione che si fa, ma che questa accusa è destinata a coprire i costi per fornendo manutenzione continua. Ovviamente, più bug hanno il tuo software, più tempo hai intenzione di spendere per la manutenzione. Per quanto riguarda i tuoi clienti, questo è il tuo problema.

È necessario tracciare una linea tra ciò che conta come una nuova funzionalità e cosa è la manutenzione, e il modo migliore per farlo è avere una specifica definitiva per ogni funzione; se non è nelle specifiche, e ritieni che sia un cambiamento significativo delle funzionalità attuali, allora è una nuova funzionalità. Se esiste una funzionalità che non funziona correttamente, allora è la manutenzione.

È così che disegno la linea, ma riconosco che la maggior parte dei clienti proverà a respingerli ovunque sia possibile, poiché li farà risparmiare!