In che modo le "società di software personalizzate" trattano il debito tecnico?

Se riesci a piegare i requisiti specifici dell'utente in qualcosa che sarà utile per tutti, ottimo. Se il cliente è disposto a pagare i costi di supporto continuativi per la funzione, anche grandioso. Ma se sei una piccola squadra e ti ritrovi a dover lottare per supportare tutte le tue funzionalità, non c'è niente da fare se non prendere delle decisioni difficili sulle funzionalità di cui hai bisogno di meno, e poi investire un po 'di tempo per estirparli dalla tua base di codice.

SaaS ti mette in una buona posizione per raccogliere statistiche di utilizzo. Dovresti cercare di migliorare le tue funzionalità se non lo hai già fatto in modo da poter tenere traccia di chi sta usando cosa. La nostra esperienza è che i clienti più idiomatici di solito sono anche i più disfunzionali; quel tizio che ha timbrato i piedi e ha trattenuto il fiato fino a che non gli hai dato un pulsante di esportazione verso MS-Access probabilmente non l'ha usato da più di un anno. Alcune funzionalità sono mantenute in vita anche se un solo cliente le sta usando, perché quel cliente è rumoroso e minaccia di portare il suo business altrove ogni volta che qualcosa non è per la sua soddisfazione. L'interruzione della funzione potrebbe costarti un cliente ora, ma il tempo impiegato a supportare questa funzione potrebbe costarti decine di clienti nel corso degli anni. È una misura della qualità del tuo team di gestione, indipendentemente dal fatto che siano disposti a prendere quel tipo di decisione.

Quando interrompi una funzione, assicurati di annunciare la decisione ai tuoi clienti (o almeno a quelli interessati) con largo anticipo, ovunque tra sei mesi e tre anni è ragionevole. In effetti, se ti accetti di creare funzionalità specifiche per l'utente, potresti provare a convincere il personale di vendita a costruire una data di scadenza dall'inizio. Chiamalo "vita di supporto" e chiarisci che più a lungo lo vogliono più denaro costa. Cerca di fornire soluzioni alternative per i tuoi clienti in modo che non siano lasciati a disagio quando viene utilizzata una funzionalità, ad esempio uno script che converte i file XML esportati nel formato di accesso MS o un consiglio su come scegliere un RDBMS migliore.

Qualcosa che ha funzionato per noi come misura preventiva è quello di ottenere una relazione dal nostro team di vendita inviato al nostro team di sviluppo e gestione su base mensile. Questo rapporto riguarda il feedback dei clienti: quali sono le funzionalità più popolari, quali sono le funzionalità più richieste, quali sono le caratteristiche proposte che generano il maggior numero di buzz. Questo è interessante se sei uno sviluppatore, ma il vero vantaggio è per il team di vendita, che ora pensa un po 'più a ciascuna funzione nel contesto di un'immagine più grande, invece di inviare un flusso infinito di richieste di funzionalità e priorità basate su quale cliente era il più strong. L'effetto è stato quello di rendere più rigido il nostro personale di vendita quando si tratta di nuove richieste di funzionalità in una negoziazione perché sono più consapevoli di dove ciascuna caratteristica possa rientrare nella proposta di valore complessiva del nostro prodotto.

Avere un codice modulare con molti test automatici ti aiuterà quando esegui l'hacking di funzionalità nel tuo prodotto e le riabiliti di nuovo, ma alla fine non si tratta di una domanda di programmazione ma di una gestione. Scrivere un codice per fare una vendita è un gioco da pazzi.

Quando mi trovo di fronte a richieste di sviluppo personalizzate, le filtro attraverso il filtro cool che divide le richieste in 3 pile:

1. cose fantastiche che saranno utili per tutti e che sono relativamente facile da implementare
2. cose fantastiche che saranno utili per tutti e sono difficili da implementare
3. stupido one-of cose che sono necessari solo per questo cliente che non ne ha veramente bisogno In ogni modo

• La categoria 1 viene implementata nell'attuale ciclo di sviluppo.
• La Categoria 2 viene implementata nel prossimo ciclo di sviluppo.
• La categoria 3 ottiene una citazione di 1 mese di tempo di sviluppo dopo il quale la maggior parte dei clienti si rende conto che la sua richiesta non vale la pena.

Onestamente, questo non ha mai fallito e non penso che abbiamo finito per implementare nessuna delle funzionalità di categoria 3. E naturalmente nessuno dei clienti camminava (le vendite non mi avrebbero permesso di escluderlo altrimenti:)

(questa esperienza è stata presso una società ISV)

due to certain constraints we sometimes end up bending to the will of certain clients and we end building bits of custom software that can only be used for that client.

Il tuo problema non è che stai creando codice che viene utilizzato solo per un cliente. Il problema è che stai incorporando il codice utilizzato solo per un cliente in un prodotto che stai vendendo a molti altri clienti che non hanno bisogno di quella funzionalità.

Companies who don't have a core product as the center of their business model, well they're always doing custom software work. How do they cope with the notion of Technical Debt? How does it not drive them into Technical Bankruptcy?

Forniscono il prodotto. E poi si spostano. Quando sviluppi un prodotto sotto contratto, tutto quello che fai su quel progetto è per quell'unico cliente. Qualsiasi debito tecnico accumulato durante lo sviluppo diventa il problema del cliente dopo la conclusione del contratto e lo sviluppatore passa a un altro progetto per un altro cliente.

Questo non significa che sia giusto fare un lavoro schifoso, ovviamente. Il tuo obiettivo numero uno è far sì che i tuoi clienti desiderino continuare a lavorare con te e fare un lavoro di qualità è il modo per arrivarci. Inoltre, non significa che il debito tecnico non sia un problema per gli sviluppatori di contratti. Anche se scrivi coerentemente codice pulito, è probabile che a un certo punto sarai assunto per lavorare su un progetto che ha già accumulato una quantità di debito. Può essere buono (il cliente vuole pagarti per ripulire il pasticcio) o no (il cliente non ha idea di quanto sia pessimo il codice e non capisce perché "solo" l'aggiunta di alcune altre funzionalità richiederà così tanto tempo ).

Non sono d'accordo con la premessa che il lavoro personalizzato è garantito per generare debito tecnico. Evitare il debito tecnico non significa evitare certi tipi di funzionalità - significa evitare inutili rigidità, problemi di dipendenza e cose che rendono difficile la modifica di un codice base (cioè costoso). La funzionalità personalizzata non implica nulla di tutto ciò: implica solo una base ristretta per la funzionalità. Quindi, il loro punto chiave è di considerare il più possibile la logica più comune e riutilizzabile possibile dall'implementazione, lasciando il materiale personalizzato e unico come il proprio modulo autonomo che può essere implementato per il cliente richiedente.

Per esempio, supponiamo che tu avessi un deliverable che era un'applicazione web interna che i tuoi clienti avrebbero installato su una intranet. Un giorno arriva un cliente e si offre di guidare un autocarro con cassone ribaltabile pieno di soldi fino alla tua azienda se ne crei una versione che abbia un'applicazione desktop "rich client" invece di un'interfaccia browser. Bene, se il tuo sistema è ben progettato e le tue dipendenze gestite correttamente, si tratta semplicemente di riutilizzare il dominio, l'accesso ai dati e i componenti del servizio durante la creazione di un nuovo componente di presentazione. Il debito tecnico non è una considerazione, anche se hai un solo cliente che vuole tornare al 1999 e avere un'applicazione desktop per questo.

Questa è una domanda alquanto complessa a cui rispondere perché, come molte cose, dipende realmente dalle circostanze del progetto, dal livello di controllo della società appaltata, indipendentemente dal fatto che il software personalizzato sia stato gestito dalla società appaltata per l'intero ciclo di vita. , la quantità di "interferenze" da parte di altre persone con accesso alla base di codice, l'atteggiamento di tutte le persone coinvolte, la complessità del progetto e le metodologie utilizzate ... Potrei davvero andare avanti.

Tutti i sistemi hanno un certo grado di debito tecnico. In alcuni casi questo potrebbe non essere particolarmente evidente a causa degli sforzi diligenti da parte degli sviluppatori che lavorano per mantenere sempre una base di codice pulita, tuttavia nessun sistema è perfetto e una riprogettazione importante può rendere evidente una questione apparentemente innocente, ma di vecchia data. Quindi, come gestiscono le aziende appaltate?

In molti casi non lo fanno. Spesso il software sarà scritto da una ditta, poi modificato da un'altra, e non è raro vedere la base di codice diventare davvero incasinata dato che ogni azienda sotto contratto lavora a una scadenza ristretta e non giustifica il tempo per mantenere il codice pulito ( e a volte a malapena testato) se ciò significa che potrebbero rischiare di perdere una scadenza.

In altri casi, trovi aziende che non solo gestiscono bene il loro progetto contrattuale, ma trovano anche il tempo di lasciare il codice esistente in uno stato migliore rispetto a quello in cui lo hanno trovato. Lo fanno spesso con un'attenta pianificazione, identificando le fonti di debito tecnico - di solito quelle che incidono di più sul nuovo lavoro - e escogitano strategie per fornire casi di test e modifiche che contribuiscono alla gestione del debito tecnico e fanno tutto questo nel loro programma di progetto .

Essere un software personalizzato garantisce un debito tecnico rispetto alla scrittura di un prodotto centrale? La risposta breve è no, tuttavia è probabile che il debito tecnico maturerà se non viene affrontato attivamente. Questo è uguale a qualsiasi altro progetto software. Se controlli il progetto interamente durante il suo ciclo di vita, allora hai una migliore opportunità di affrontare il debito tecnico. In caso contrario, sarà necessario affrontare il debito tecnico che potrebbe essere derivato dal codice che la società precedente ha lasciato.

D'altra parte, se la tua domanda dovesse chiederti se scrivere software indipendentemente dal tuo modello di business è una garanzia di debito tecnico. La risposta sarebbe assolutamente. La vera domanda è come qualsiasi azienda gestisce il debito tecnico. Lasciarlo maturare e gestirlo a un orario programmato, o gestire una base di codice pulita in modo continuativo al fine di pagare il debito tecnico il prima possibile? Questa risposta si riduce alle priorità individuali di un'azienda e se il debito tecnico sostenuto è rilevante dal punto di vista finanziario.

Il software personalizzato non è una garanzia di debito tecnico, ma servire due padroni è.

Una società di software personalizzata costruirà un pezzo di software esattamente adattato al compito in questione, lo consegnerà e lo manterrà se necessario. Il software veramente personalizzato spesso non ha bisogno di nuove funzionalità aggiunte molto spesso.

Il problema descritto in questa domanda è quando le aziende produttrici creano caratteristiche personalizzate in un prodotto altrimenti generico. Se il prodotto fosse interamente personalizzato, si sposterebbe solo quando i requisiti del cliente singolo cambiassero. Se il prodotto fosse del tutto generico, si sposterebbe solo quando verranno aggiunte nuove funzionalità per renderlo più accattivante. Ma quando si dispone di una funzione personalizzata in un prodotto altrimenti generico, si hanno due blocchi di codice, a stretto contatto, che si spostano a velocità diverse. Come le placche tettoniche che causano i terremoti, l'interfaccia tra questi blocchi di codice è un "punto caldo", maturo per i problemi.