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

Cosa sono le "società di software personalizzate"?

Per "società di software personalizzate" intendo aziende che fanno soldi principalmente costruendo pezzi di software personalizzati e unici. Esempi sono agenzie o società di intermediazione o appaltatori / consulenti come Redify .

Qual è l'opposto delle "società di software personalizzate"?

L'opposto del modello di business di cui sopra sono le aziende che si concentrano su prodotti a lungo termine, siano essi applicazioni desktop / mobili distribuibili o software SaaS.

Un modo sicuro per accumulare debito tecnico:

Lavoro per un'azienda che tenta di concentrarsi su una suite di prodotti SaaS. Tuttavia, a causa di alcuni vincoli, a volte finiamo per piegarci alla volontà di determinati clienti e finiamo per costruire pezzi di software personalizzato che possono essere utilizzati solo per quel client.

Questo è un modo sicuro per incorrere in debiti tecnici. Ora abbiamo un po 'di software da mantenere che non aggiunge nulla al nostro prodotto principale.

Se il lavoro personalizzato è un modo sicuro per creare debito tecnico, come lo gestiscono le agenzie?

Quindi questo mi ha fatto pensare. Le aziende che non hanno un prodotto di base come centro del loro modello di business, fanno sempre un lavoro di software personalizzato. Come affrontano la nozione di debito tecnico? In che modo non li porta al fallimento tecnico ?

Se riesci a piegare i requisiti specifici dell'utente in qualcosa che sarà utile per tutti, fantastico. Se il cliente è disposto a pagare i costi di supporto in corso per la funzionalità, anche grande. Ma se sei un piccolo team e ti ritrovi a lottare per supportare tutte le tue funzionalità, non c'è nient'altro che prendere alcune decisioni difficili sulle funzionalità di cui hai meno bisogno, e poi dedicare un po 'di tempo a sradicarle dalla tua base di codice.

SaaS ti mette in una buona posizione per raccogliere statistiche sull'utilizzo. Dovresti cercare di attrezzare le tue funzionalità se non l'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 battuto i piedi e ha trattenuto il respiro fino a quando non gli hai dato un pulsante di esportazione in MS Access probabilmente non lo usa da più di un anno. Alcune funzionalità vengono mantenute attive anche se solo un cliente le sta utilizzando, poiché quel cliente è rumoroso e minaccia di portare la sua attività altrove ogni volta che qualcosa non è di sua soddisfazione. L'interruzione della funzione potrebbe costarti un cliente adesso, ma il tempo impiegato nel supportare tale funzione potrebbe costarti decine di clienti nel corso degli anni. È una misura della qualità del tuo team di gestione,

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 sia ragionevole. Infatti, se ti accetti di creare funzionalità specifiche per l'utente, potresti provare a convincere il tuo personale di vendita a stabilire una data di scadenza dall'inizio. Chiamalo la "durata del supporto", e chiarisci che più lo desiderano e maggiore sarà il costo. Prova a fornire soluzioni alternative per i tuoi clienti, in modo che non vengano lasciati andare in frantumi quando si attiva una funzione, ad esempio uno script che converte i file XML esportati in formato di accesso MS o un po 'di consigli sulla scelta di un RDBMS migliore.

Qualcosa che ha funzionato per noi come misura preventiva è quello di ottenere un rapporto dal nostro team di vendita inviato al nostro team di sviluppo e gestione su base mensile. Questo rapporto copre i feedback dei clienti: quali sono le funzionalità più popolari, quali sono le funzionalità più richieste, quali sono le funzioni 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 sta pensando un po 'di più a ciascuna funzionalità nel contesto del quadro più grande, invece di inviare un flusso infinito di richieste di funzionalità e di stabilire le priorità in base su quale client era il più rumoroso. L'effetto è stato quello di rendere il nostro personale di vendita più esigente quando si tratta di richieste di nuove funzionalità in una trattativa perché sono più consapevoli di dove ciascuna funzionalità potrebbe adattarsi alla proposta di valore complessivo del nostro prodotto.

Avere un codice modulare con molti test automatici ti aiuterà quando stai hackerando funzionalità nel tuo prodotto e hackerandole di nuovo, ma alla fine questa non è una questione di programmazione ma di gestione. Scrivere 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 a tutti e che sono relativamente facili da implementare
2. cose fantastiche che saranno utili a tutti e difficili da implementare
3. una delle cose stupide che sono necessarie solo per questo unico cliente che non ne ha davvero bisogno comunque

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

Onestamente, questo non è mai fallito e non credo che abbiamo finito per implementare nessuna delle funzionalità della categoria 3. E ovviamente nessuno dei clienti ha camminato (le vendite non mi avrebbero permesso di farlo altrimenti :)

(questa esperienza è stata presso un'azienda ISV)

a causa di alcuni vincoli a volte finiamo per piegarci alla volontà di alcuni clienti e finiamo con la costruzione di pezzi di software personalizzato che possono essere utilizzati solo per quel client.

Il tuo problema non è che stai creando il codice utilizzato per un solo client. Il problema è che stai incorporando il codice utilizzato solo per un cliente in un prodotto che stai vendendo a molti altri clienti che non necessitano di tale funzionalità.

Le aziende che non hanno un prodotto di base come centro del loro modello di business, fanno sempre un lavoro di software personalizzato. Come affrontano la nozione di debito tecnico? In che modo non li porta al fallimento tecnico?

Consegnano il prodotto. E poi vanno avanti. Quando sviluppi un prodotto sotto contratto, tutto ciò che fai su quel progetto è per quel cliente. Qualsiasi debito tecnico che può essere maturato 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.

Ciò non significa che va bene fare un lavoro schifoso, ovviamente. Il tuo obiettivo numero uno è far sì che il tuo cliente voglia 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 costantemente codice pulito da solo, è probabile che verrai assunto ad un certo punto per lavorare su un progetto che ha già accumulato un mucchio di debiti. Può essere buono (il cliente vuole pagarti per ripulire il disordine) oppure no (il cliente non ha idea di quanto sia cattivo il codice e non capisce perché "solo" l'aggiunta di alcune 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 determinati tipi di funzionalità - significa evitare inutili rigidità, problemi di dipendenza e cose che rendono difficile cambiare una base di codice (cioè costosa). La funzionalità personalizzata non implica nulla di tutto ciò: implica solo una base ristretta per la funzionalità. Quindi, la chiave è quella di considerare il più possibile la logica riutilizzabile più comune possibile dall'implementazione, lasciando le cose personalizzate e una tantum come il proprio modulo autonomo che può essere distribuito per il cliente richiedente.

Ad esempio, supponiamo che tu avessi un prodotto che era un'applicazione web interna che i tuoi clienti avrebbero installato su una rete intranet. Un giorno arriva un cliente e si offre di guidare un autocarro con cassone ribaltabile pieno di soldi per la tua azienda se ne creerai una versione con un'applicazione desktop "rich client" anziché un'interfaccia del browser. Bene, se il tuo sistema è ben progettato e le tue dipendenze ben gestite, si tratta solo 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 è un fattore da tenere in considerazione, anche se hai un solo cliente che desidera tornare al 1999 e disporre di un'applicazione desktop per questo.

Questa è una domanda un po 'complessa a cui rispondere perché, come molte cose, dipende davvero dalle circostanze del progetto, dal livello di controllo che la società appaltata ha, se il software personalizzato è stato gestito dall'azienda appaltata per l'intero ciclo di vita, la quantità di "interferenza" 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 continuare.

Tutti i sistemi hanno un certo 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 un problema apparentemente innocente ma di lunga data. Quindi, come gestiscono le aziende a contratto?

In molti casi non lo fanno. Spesso il software viene scritto da una società, quindi modificato da un'altra, e non è inusuale vedere la base di codice essere davvero incasinata poiché ogni società sotto contratto lavora a una scadenza serrata e non giustifica il tempo per mantenere pulito il codice ( 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 contrattato, ma che in qualche modo trovano il tempo per lasciare la base di codice esistente in uno stato migliore di quello che hanno trovato. Lo fanno spesso con un'attenta pianificazione, identificando le fonti di debito tecnico - di solito quelle che avranno un impatto maggiore sul nuovo lavoro - e escogitano strategie per fornire casi di prova e modifiche che contribuiscono a gestire il debito tecnico e ad integrare tutto ciò 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 maturi se non viene attivamente trattato. È lo stesso di 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, dovrai occuparti del debito tecnico che potrebbe essere derivato dal codice che la società precedente ha lasciato indietro.

D'altra parte, se la tua domanda fosse quella di chiedere se scrivere software indipendentemente dal tuo modello di business sia una garanzia di debito tecnico. La risposta sarebbe assolutamente. La vera domanda è come qualsiasi azienda gestisce il debito tecnico. Lasciarli maturare e gestirli in un momento prestabilito o gestire una base di codice pulita in modo continuo al fine di pagare il debito tecnico il più presto possibile? Tale risposta si basa sulle priorità individuali di un'azienda e se il debito tecnico sostenuto è finanziariamente rilevante.

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

Una società di software personalizzata costruirà un software esattamente adattato all'attività in corso, lo consegnerà e lo manterrà se necessario. Il software veramente personalizzato spesso non necessita di nuove funzionalità aggiunte molto spesso.

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