Progetti ereditari - Regole generali? [duplicare]

Quando arriva un progetto come questo, le mie regole generali sono:

1) Chiedi di avere accesso completo per valutare cosa è stato fatto.

2) Scopri cosa può essere utile o utilizzabile con un minimo di armeggiare (l'architettura del database e gli elementi di progettazione spesso rientrano in questa categoria).

3) Fornisci una stima basata sul recupero di ciò che è utilizzabile insieme a una stima che normalmente darei da zero. Questo mi aiuta a decidere se è meglio iniziare da zero.

Penso sia importante essere onesti. Se ritengo che ciò che è stato fatto sia veramente scadente, devo essere in grado di spiegare il perché in termini semplici. Oggi è un po 'più semplice (non HTML 5, non un design reattivo, nessuna considerazione per i dispositivi mobili, nessun uso del framework, ecc.) Poiché la tecnologia è cresciuta orizzontalmente e gli sviluppatori malvagi sono più facili da eliminare.

Soprattutto è importante che il potenziale cliente veda ciò che vedo e dia loro la certezza che non solo so cosa c'è che non va, ma come risolverlo. Se ciò significa ricominciare da capo, è meglio mordere il proiettile e farlo ora.

Partire da zero è, di solito, il primo approccio della maggior parte delle persone, ci sono molte ragioni per questo, come lo stile di codifica diverso, qualcosa di antipatico sull'uso di (classi / funzioni), per caricare di più, per non valutare correttamente la quantità di lavoro, ecc. ecc.

Se riesci a evitare di riscrivere tutto di nuovo, è molto meglio; ma implica tempo per leggere e capire il codice. Ovviamente, ci sono alcune situazioni in cui non c'è altra soluzione, ma dovresti cercare di evitarlo, per te e per il cliente. Se l'altro sviluppatore ha utilizzato html 4.01 e si desidera utilizzare html 5, non è un buon motivo per eliminare, se hanno usato asp e si preferisce php, non è un buon motivo, a meno che non si possa usare quella tecnologia, e in In tal caso, devi dire al cliente la tua limitazione, ovviamente puoi provare a discutere sulla qualità di uno rispetto all'altro, ma non aspettarti che il cliente si preoccupi molto di questo.

Prima di accettare un progetto del genere, o prima di dire al cliente i tempi di consegna, devi prenderti il tempo di leggere.

Anche se il cliente odia l'altro sviluppatore, si aspetta comunque che tu faccia le cose velocemente e finisca presto, molte volte dicono di capire che questo è un nuovo progetto e che il tempo deve iniziare da zero, ma dentro, stanno registrando che il tempo stringe, che hanno iniziato il progetto tempo fa e che non è ancora finito e poi, cominciano a fare più pressione su di te. Quindi chiarisci questo punto.

Vorrei anche chiedere al cliente quanto velocemente hanno inviato informazioni al vecchio sviluppatore, se dicono che è sempre in orario, comincerò a sospettare una cattiva relazione con il cliente. Nella mia esperienza, è raro avere materiali e risposte rapidi e precisi, quindi a meno che non abbia una risposta più relativa come "di solito in tempo", "questo o quello non era chiaro ma abbiamo parlato di mail e poi ..." cose in quel modo, sarei molto sospettoso.

Chiederò se hanno ancora la proposta dell'altro sviluppatore e chiederanno cosa è andato storto, cercherò di ottenere tutti i dettagli.

Fondamentalmente, vuoi essere chiaro se il cliente è difficile o no. Il motivo per cui licenziato l'altro sviluppatore è qualcosa che non ti influenza, ma puoi ottenere molte informazioni da questo fatto e dovresti provare ad usarlo.