Cosa faresti se fossi 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" dalla direzione perché i clienti sono felici?
Non dovrei proprio preoccuparmi? Va bene che i clienti non si rendono nemmeno conto che potrebbero avere un'applicazione migliore di questa?
A che punto smetto di preoccuparmi di costruire correttamente e seguire il flusso?
Se i clienti sono felici, stai facendo qualcosa di giusto. Molte persone amano gli hot dog senza sapere come sono fatti ...
Se l'app è una buona soluzione al problema ma sei preoccupato che le basi siano difettose, scopri come migliorare in modo incrementale e lancia un piano per implementare tali miglioramenti man mano che aggiorni il Prodotto. La chiave incrementale è fondamentale: se hai voglia di riscriverne parti intere, il tuo manager dirà giustamente che è irragionevole. Il perfetto può essere nemico del bene. Cerca la storia di Jwz su come Netscape abbia permesso a IE di prendere l'iniziativa perché "dovevano" riscrivere Navigator.
Se l'interfaccia utente dell'app è di per sé un disastro, i clienti potrebbero comunque essere contenti perché la stanno confrontando "nel modo più duro" e persino un programma bacato può essere meglio di così. Lo stai confrontando con un ideale che puoi immaginare grazie al tuo background e alle tue abilità. Di nuovo, considera come puoi migliorare le cose in modo incrementale e inseriscile come parte del piano.
Non smettere di preoccuparti: vuoi che il tuo lavoro sia il migliore che possa essere. Ma ricorda anche che è il cliente che paga le tue bollette e tu stai scrivendo software per loro, non tu.
Non è un incubo per loro. Sarà un incubo per te e sembra che tu pensi di sapere cosa stai facendo, quindi verrà risolto. Preferiresti la gente che non sottostà alla programmazione pensa che la tua app sia peggiore di quanto non sia in realtà? Questa non è l'eccezione. Goditelo finché puoi. Meglio sperare che il client sia troppo grande per questa app. Possono andare così lontano in un'altra direzione come un business che questo è assolutamente inutile. Potresti riscriverlo per una serie di motivi completamente diversa da quella che pensi.
Non penso che dovresti mai smettere di preoccuparti, anche se sembra che il management superiore si sia fermato. Penso che la cosa importante da trarre da questa esperienza sia ricordare e documentare tutte le cose che pensi siano andate storte. Evitare questi errori in futuro verrà infine riconosciuto, se non questo attuale gruppo di manager, forse il prossimo gruppo di manager per cui lavori.
Vorrei iniziare a presentare idee per i prossimi passi allo sviluppo che includono il ri-factoring per migliorare la qualità del codice. Evita di approfondire i dettagli tecnici, ma fai notare come le correzioni suggerite significheranno ha continuato la soddisfazione del cliente. Preparati a combinare la pulizia con nuove funzionalità, dal momento che la gestione sarà sempre alla ricerca di qualcosa di nuovo da vendere.
In generale, i clienti non si preoccuperanno della manutenzione finché qualcosa non andrà storto. Idealmente, la tua azienda si preoccuperebbe della sua reputazione e vorrebbe proteggerla mantenendo il codice.
Tuttavia, se questo prodotto è visto come a brevissimo termine, potrebbe non esserci 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 lo fai. Utilizzi il successo per garantire il finanziamento / l'autorizzazione / il buy-in per avviare il refactoring in modo tecnicamente corretto e di facile manutenzione. Oppure usi il successo per ottenere la promozione dal dipartimento "I get to the old codebase".
Forse la tua priorità / punto di vista è sbagliata.
La cosa più importante di qualsiasi progetto software è che soddisfi i requisiti degli utenti.
Questo è un trilione di volte più importante di essere "corretti" secondo le mode di design di questo mese in C / S.
Sì, dovresti usare schemi di progettazione corretti, usare la tecnologia correttamente ecc.ecc. ma solo nella misura in cui rende più semplice implementare i requisiti degli utenti in modo affidabile e gestibile.
Un sistema veramente mal scritto che soddisfi effettivamente un bisogno aziendale è sempre meglio di un pezzo di codice meravigliosamente scritto e meravigliosamente documentato che nessuno vuole o ha alcun motivo per usarlo.
Cerca di comunicare con gli utenti attuali e chiedi loro quali sono gli aspetti che ritengono debbano essere migliorati. 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 miglioramenti proposti dall'utente"
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 trascorso.
Leggi altre domande sui tag project-management client-relations