Cosa faresti se ti trovassi in una situazione in cui il progetto a cui stai lavorando è ovviamente costruito male e avrà fallimenti in futuro e sarà un incubo da mantenere ... ma è considerato un "successo" dal management perché i clienti sono felici?
Non dovrei preoccuparmene? Va bene che i clienti non si rendono nemmeno conto di poter avere un'applicazione migliore di questa?
A che punto smetto di preoccuparmi di costruirlo nel modo giusto e di seguire il flusso?
Risposte:
Se i clienti sono felici, stai facendo qualcosa di giusto. Molte persone amano i hot dog senza sapere come sono fatti ...
Se l'app è una buona soluzione al problema ma sei preoccupato che le fondamenta siano difettose, scopri come migliorare le cose in modo incrementale e formula un piano per implementare tali miglioramenti mentre aggiorni il prodotto. L'incrementale è la chiave: se hai voglia di riscriverne intere parti, il tuo manager dirà giustamente che è irragionevole. Il perfetto può essere nemico del bene. Guarda la storia di jwz su come Netscape ha lasciato che IE prendesse il comando perché "dovevano" riscrivere Navigator.
Se l'interfaccia utente dell'app è di per sé un disastro, i clienti potrebbero comunque essere contenti perché lo stanno confrontando con "il modo difficile" e anche un programma con errori può essere molto meglio. Lo stai paragonando a un ideale che puoi immaginare a causa del tuo background e delle tue abilità. Ancora una volta, considera come puoi migliorare le cose in modo incrementale e proponilo come parte del piano.
Non smettere di preoccuparti: vuoi che il tuo lavoro sia il migliore possibile. Ma ricorda anche che è il cliente che paga le tue bollette e stai scrivendo software per loro, non tu.
Non è un incubo per loro. Sarà un incubo per te e sembrano pensare che tu sappia cosa stai facendo, quindi verrà risolto. Preferiresti che le persone che non comprendono la programmazione pensino che la tua app sia peggiore di quanto non sia in realtà? Questa non è un'eccezione. Goditelo finché puoi. È meglio sperare che il client superi questa app. Possono andare così lontano in un'altra direzione come impresa che questo è assolutamente inutile. Potresti riscriverlo per una serie di ragioni completamente diverse da quelle che pensi.
Non credo che dovresti mai smettere di preoccuparti, anche se sembra che il vertice si sia fermato. Penso che la cosa importante da trarre da questa esperienza sia ricordare e documentare tutte le cose che pensi siano andate male. Evitare questi errori in futuro verrà infine riconosciuto, se non questo gruppo corrente di manager, forse il prossimo gruppo di manager per cui lavori.
Comincerei a presentare idee per i prossimi passi dello sviluppo che includono il factoring per migliorare la qualità del codice. Evita di approfondire troppo i dettagli tecnici, ma fai notare come le correzioni che suggerisci significheranno una continua soddisfazione del cliente. Preparati a mescolare la pulizia con le nuove funzionalità, dal momento che il management sarà sempre alla ricerca di qualcosa di nuovo da vendere.
In generale, i clienti non si occuperanno della manutenzione fino a quando qualcosa non va storto. Idealmente, la tua azienda si preoccuperebbe della sua reputazione e vorrebbe proteggerla mantenendo il codice.
Tuttavia, se questo prodotto viene visualizzato a brevissimo termine, potrebbe non esserci effettivamente un valore aggiunto per farlo correttamente. In tal caso - cerca le soluzioni economiche - le cose con poco sforzo che hanno un grande valore per la sanità mentale degli sviluppatori.
Non Utilizzi il successo per garantire finanziamenti / autorizzazioni / buy-in per iniziare il refactoring verso tecnicamente corretto e facile da mantenere. Oppure usi il successo per essere promosso dal dipartimento "Ricevo il vecchio codice di base".
Forse la tua priorità / punto di vista è sbagliata.
La cosa più importante di qualsiasi progetto software è che soddisfa i requisiti degli utenti.
Questo è un milione di volte più importante che essere "corretto" secondo le mode del design C / S di questo mese.
Sì, è necessario utilizzare modelli di progettazione corretti, utilizzare la tecnologia correttamente ecc. Ecc. ma solo nella misura in cui semplifica l'implementazione dei requisiti degli utenti in modo solido e mantenibile.
Un sistema veramente mal scritto che soddisfa effettivamente un'esigenza aziendale è sempre meglio di un codice meravigliosamente scritto e meravigliosamente documentato che nessuno vuole o ha motivo di usare.
Cerca di comunicare con gli utenti attuali e chiedi loro quali aspetti LORO pensano di aver bisogno di miglioramenti. Quindi potresti migliorare alcuni aspetti che ritieni debbano essere migliorati e migliorare anche gli aspetti proposti dagli utenti. Puoi giustificare i tuoi miglioramenti come "necessari per implementare i miglioramenti proposti dagli utenti"
Ad esempio: se gli utenti pensano che la funzione di ricerca sia lenta. Puoi migliorarlo creando un Data Layer migliore che ovviamente serve più della semplice ricerca, ma puoi quindi giustificare il tempo impiegato.