Sono stato assunto circa un anno fa come lead (beh, davvero l'unico) sviluppatore di un nuovo progetto / prodotto che chiameremo prodotto "B". Il prodotto B è stato progettato per perseguire un nuovo mercato per l'azienda.
Questa azienda ha avuto un grande successo con un prodotto simile per un mercato diverso. Chiameremo questo altro prodotto "A".
"A" ora ha quasi 5 anni ed è affidabile.
I due mercati non si sovrappongono necessariamente, ma molte delle funzionalità di base in A potrebbero essere riutilizzate per funzionare per B.
La mia scadenza per perseguire questo nuovo mercato per il prodotto B è stata piuttosto aggressiva. Dovevamo dimostrare rapidamente alcune capacità ai potenziali clienti e dimostrare loro che eravamo un serio concorrente nel nuovo mercato. Per accelerare lo sviluppo, abbiamo preso la via più breve per creare un nuovo prodotto. Abbiamo iniziato con una copia profonda (una succursale) del prodotto A delle aziende e l'abbiamo riproposta come B.
Questo approccio ha molto senso dato i limiti di tempo in quanto abbiamo ereditato gratuitamente molte funzionalità e infrastrutture core sovrapposte. Abbiamo rimosso un sacco di funzionalità e opzioni che non si applicavano, lasciato alcune cose rimandate e aggiunte alcune nuove funzionalità necessarie per proteggere questi clienti. Non è stata una transizione perfetta, ma è stata abbastanza buona.
Il prodotto B è in circolazione da circa un anno a questa parte e le cose stanno andando bene, poiché abbiamo assicurato due clienti con diversi potenziali clienti all'orizzonte. Quali sono i prossimi passi?
Da una prospettiva di "best practice", non sembra una buona strategia continuare a sviluppare il prodotto B come una copia del prodotto A. Non è una solida base per costruire un nuovo prodotto.
Abbiamo raggiunto il nostro obiettivo immediato creando un "prodotto" e dimostrandolo ai potenziali clienti. Ora, non dovremmo fare un passo indietro, scoprire cosa vogliono veramente gli utenti e perfezionare il nostro design?
In realtà non abbiamo un "nuovo prodotto". Abbiamo creato alcuni "vaporware" per un paio di installazioni demo.
Sfortunatamente, ho l'impressione dalla direzione che pensano che abbiamo un nuovo prodotto da sviluppare e vendere e non c'è tempo per fare un passo indietro, rifattorizzare e perfezionare. Perché dovremmo spendere tempo e denaro per ridisegnare quando abbiamo già qualcosa che possiamo usare e vendere?
Ecco i miei problemi:
-
Poiché è stato creato da una copia di A, il codice base del prodotto B è pieno di artefatti e "debito tecnico" dal prodotto A. Parte di questo codice non è più raggiungibile. Parte di questo codice è raggiungibile, ma forse la logica aziendale non ha senso per il prodotto B. Ad esempio, potrebbero esserci ricerche su tabelle vuote nel database o verifiche su cose che non esistono. Questo tipo di logica non solo fa male alle prestazioni, ma è anche un incubo di manutenzione.
Ho intenzione di stimare che stiamo effettivamente utilizzando il 35% del codice base del prodotto A, e il resto è il bagaglio.
-
Il management pensa che sia stato intelligente creare B da una copia di A: "Risparmierà poiché il codice può essere riutilizzato tra i prodotti." Se un bug è corretto in A, perché non può essere unito in B? O se sviluppo una nuova funzionalità in B, perché non può essere unita ad A? Questo argomento è difettoso. Sebbene B sia stato creato da A, è stato fatto così più di un anno fa, e A ha un team dedicato con 4 sviluppatori. Sono solo sul prodotto B. Il ramo di codice per A continua a divergere da B. Ora, è molto difficile unire qualsiasi cosa.
-
Infine, mi sento come se avessimo messo dei vincoli inutili su di noi iniziando con un prodotto che ha già 5 anni. Alcuni aspetti sono stati progettati molto male e senza dubbio creeranno gli stessi problemi con una nuova base di utenti. Prendiamo le nostre lezioni apprese e sfruttiamo questa opportunità per migliorare il design anziché copiare le schifezze. Inoltre, utilizziamo le nuove tecnologie dove ha senso: molte cose sono cambiate in 5 anni!
Come posso convincere il management che dobbiamo perfezionare il nostro prodotto, molto probabilmente da zero? Il mio capo pensa in termini di tempo e di dollari, e sento che perderò questo dibattito se non sto attento. Questo tipo di sforzo può essere quantificato e messo in termini gestionali?
Ho letto su "design emergente" e sto cercando di affrontare la mia tesi dal punto di vista del fatto che non dobbiamo consegnare tutto in una volta. Concentriamoci su piccoli pezzi di codice funzionante con il valore più aziendale.