Scrivere software su una base di consulenza può spesso essere una proposta perdente per sviluppatori o clienti o entrambi. Ci sono troppe cose che possono andare storte e che alla fine si traducono in perdita di tempo e denaro. La regola del 15% che abbiamo creato è volta a creare una situazione vantaggiosa per entrambe le parti.
I clienti ottengono generalmente quello che vogliono, ei negozi di sviluppo fanno un discreto profitto. Una soluzione perfetta, ma finora sembra funzionare per noi.
Questo potrebbe sorprendere qualcuno, ma guadagniamo pochissimo denaro vendendo licenze software. La maggior parte delle nostre entrate proviene da servizi di consulenza che scrivono codice per il noleggio. Avendo fatto questo per diversi anni, abbiamo imparato alcune lezioni difficili. In alcuni progetti le lezioni erano così difficili che in realtà abbiamo perso denaro. Alcuni mesi fa ho messo insieme un documento tipo manifesto che intendeva affrontare le difficoltà che abbiamo affrontato nello sviluppo di software per i clienti. Mirare con piacere a dire che ha fatto una differenza notevole. La mia speranza è che questa bozza venga letta da altri che sviluppano software su base consultiva, in modo che possano apprendere queste lezioni nel modo più semplice piuttosto che nel modo in cui le abbiamo apprese. Quello che segue in questo articolo è una sintesi di uno dei principi principali che ora seguiamo nello sviluppo del software della regola del 15%. Se si desidera, si prega di leggere l';intero documento sul nostro approccio allo sviluppo del software. Per gli impazienti, la regola del 15% va così prima di intraprendere un progetto di sviluppo, creiamo una dichiarazione di lavoro (che funge da contratto e da una specifica) che delinea ciò che fa bene, quante ore richiederà e quanto sarà costa al cliente. Come parte del contratto, ci impegniamo a investire fino alla quantità di tempo indicata nel documento più il 15%. Cioè, se la dichiarazione di lavoro dice che il progetto ci richiederà 100 ore per essere completato, passeremo fino a 115 ore (ma non più). Per quanto riguarda dove-foresta e perché-sballottare su come funziona, continua a leggere. Coloro che hanno sviluppato software per il noleggio sanno che il prodotto finale non finisce quasi mai esattamente come il cliente aveva immaginato. Ci sono inevitabilmente modifiche che devono essere fatte (che possono o non possono essere discusse in anticipo) al fine di ottenere che la cosa assomigli almeno a ciò che il cliente ha in mente. E, sì, questo può accadere anche se trascorri ore e ore a perfezionare le specifiche per riflettere i desideri del cliente. Inoltre, possono emergere problemi tecnici non previsti dal team di programmazione. In teoria, migliore è il team di programmazione, meno è probabile che ciò accada, ma non finisce sempre così (il sistema operativo Microsoft Vista è un esempio eccezionale). Questi due fattori, tra gli altri, equivalgono al rischio inerente al progetto. Qualcosa non andrà bene, e questo significa quasi sempre che qualcuno paga o perde più denaro di quanto originariamente previsto. La domanda è: chi dovrebbe essere responsabile per conto di quei dollari extra? Fino a tempi relativamente recenti, avremmo affrontato quasi tutti i rischi nei nostri progetti. Se l';app non fa quello che il cliente ha in mente, o se si sono verificati problemi tecnici imprevisti, in genere è uscito dalle nostre tasche. Per la maggior parte non può avere un problema enorme, ma sembra sempre avere almeno un certo effetto ( i casi estremi sono ovviamente quando abbiamo perso soldi per un progetto). Sembra ingiusto, vero? Il rischio inerente al progetto non è necessariamente colpa di entrambe le parti. È solo lì. Non l';abbiamo messo lì, e nemmeno il cliente. In quanto tale, non dovrebbe essere il caso in cui una delle parti sostiene tutto.
Come è fatto il software