Come affrontare il vecchio "questa sarà solo una piccola applicazione"? Si, come no?

Ok, mi sono imbattuto in questo molte volte, ma qui lo scenario peggiore è leggermente esagerato.

Un cliente dice "hey puoi farci questo piccolo modulo per fare questo piccolo compito"?
Io: "Sicuramente nessun problema".

Quindi, basandomi su budget, vincoli, ecc., Salto un po 'dell'architettura e mi tuffo e non faccio sudare.

Quindi chiedono un altro modulo. E un altro. E alcuni miglioramenti. E tutto questo accade molto lentamente, badate, negli anni. E prima che tu lo sappia, hai questa applicazione mostro che è orribilmente progettata.

Cosa fai quando ti viene chiesto di fare qualcosa di piccolo? Non sai se continuerà a crescere ... se il cliente continuerà a chiedere aggiunte (e nemmeno loro).

Non puoi sovrastimare la cosa, perché dopo tutto è solo una piccola applicazione, e andranno da qualche altra parte se dici (in quanto conosco tutta la voce) "Beh, nel caso, progettiamo questa cosa in strati con top -o-the-line sicurezza e separazione delle preoccupazioni. In effetti andiamo con uno strumento di iniezione di dipendenza che renderà davvero questa cosa fantastica blah blah blah ".

Diranno "sì giusto" e andranno da qualcun altro.

Budget, tempo e percezione sono importanti quanto l'architettura stessa dell'applicazione.

Come dovrebbe essere affrontato questo?

Immagino che la domanda si riduca davvero a "Quando non si hanno tutte le informazioni per il risultato finale di quella che sembra essere una piccola applicazione, come evitare (o mitigare) di prendere decisioni architetturali e progettuali in anticipo che sarà completamente inopportuno più tardi?

Ho incontrato un bel po 'di questi e quello che faccio normalmente è esattamente quello che hai fatto, immergiti e fallo.

Quando tornano per saperne di più, significa che il loro modello di business funziona e che dovrebbero essere disposti a investire un po 'di più. Questo è quando li faccio sedere (in genere 3 ° modulo a seconda della complessità) e racconto loro le cattive notizie.

Metterò tutto sul tavolo, offrirò di rifare tutto compreso il modulo più recente e dirgli quanto costerà. In genere avranno un po 'di shock adesivo all'inizio, ma se hai un buon rapporto di lavoro e le tue cose funzionano, non dovrebbe essere un grosso problema.

Assicurati di aver capito tre cose però:

1. Se davvero non vogliono preoccuparsi di una riscrittura completa, farai comunque il 3 ° modulo. Potrebbero volerci alcune ore in più e le fatturerai. Ricorda loro che dovrebbero davvero pensare a fare una riscrittura in futuro, perché più attendono, più costerà.

2. Costa davvero di più per convincere qualcun altro a farlo. La nuova persona deve ridisegnare tutto con una comprensione minima delle proprie esigenze e stranezze, il che significa tempi di riscrittura extra e il rischio che non faccia un lavoro altrettanto buono.

3. Che non stai provando a guadagnare velocemente. La cosa ha bisogno di una riprogettazione.

A proposito, se l'abitudine di fatturazione è qualcosa come metà ora, metà quando è finita, potresti considerare di offrire loro termini di pagamento estesi. Cambialo a metà ora e dividi il saldo nel periodo in cui ci lavorerai. Ciò potrebbe ridurre il pizzico in caso di problemi di budget.

Trasformalo in una piccola app e ricevi il pagamento.

Nella mia esperienza è interessante investire più tempo all'inizio di quanto realmente necessario, nel caso in cui il cliente desideri di più. Ma devi ponderare l'efford nel farlo (vieni pagato per questo) rispetto alla propensione che avverranno davvero tutti questi cambiamenti aggiuntivi. L'intera app potrebbe essere sostituita completamente dopo un anno.

E investendo tempo nell'architettura iniziale, potresti sentire di farti un favore. Ma davvero, fai un favore al cliente rendendo gli altri moduli più economici per lui.

Basta fatturare un po 'di più al cliente per ciascun modulo successivo e riformattare passo dopo passo il progetto iniziale, ma sempre per soddisfare le esigenze del cliente.

Le risposte precedenti sono buone e, se sono onesto, cosa probabilmente farei. Detto questo, sono leggermente a disagio per questo approccio in quanto stai prendendo decisioni che appartengono correttamente al cliente, sulla base di un'ipotesi di ciò che vogliono (e del desiderio di ottenere il lavoro)

Non posso fare a meno di pensare che si dovrebbe fare è essere onesti con il cliente e dare loro la scelta: 1. Ora posso farlo in modo rapido e (relativamente) economico. Sarà fantastico - funzionerà - ma i futuri miglioramenti costeranno in modo incrementale un po 'di più 2. Posso dedicare più tempo in anticipo, il che costa un po' di più e non aggiunge alcun vantaggio reale per gli utenti, MA ti farà risparmiare denaro a lungo termine se devi aggiungere nuove funzionalità.

Idealmente, sarai in grado di fornire loro alcune cifre relative al tempo / ai costi del ball-park - altrimenti la conversazione potrebbe essere troppo accademica - ma apprezzo che arrivare a questi numeri possa anche richiedere uno sforzo. Almeno, inquadrare la discussione in termini di progetti precedenti renderebbe la vita più facile per il cliente (e rendere la vita del cliente più semplice dovrebbe essere una priorità assoluta :-))

I commenti che altri hanno fatto sull'avere un buon rapporto di lavoro sono puntuali, ma puoi iniziare questo processo essendo onesto te stesso. Se il cliente è il tipo con cui non puoi nemmeno avere quella conversazione, ora potrebbe essere il momento di chiederti quanto hai bisogno di questo lavoro ...

Tratterei ciascuna di queste "iterazioni" come un progetto separato. Dovresti chiudere questi progetti al termine di ogni piccolo modulo o aggiunta. Quindi, quando vogliono qualcos'altro, redigere i documenti. E col passare del tempo, il software diventa più costoso ... il che significa che stai caricando di più per ogni piccolo progetto.

È un modo per guardarlo, invece di un ... progetto LONGGGGGG.

come evitare (o mitigare) di prendere decisioni architettoniche e progettuali che saranno completamente inadeguate in seguito?

Non puoi . I programmatori non sono sensitivi. Mentre possiamo prevedere cose semplici o vedere miglioramenti dell'interfaccia utente, non possiamo davvero programmare oltre ciò che non sappiamo che il cliente potrebbe desiderare in seguito (vedi lì la follia?).

La tua domanda diceva che aveva processi aziendali ma non sono sicuro che siano buoni processi. Ecco alcuni suggerimenti:

• Richiedi tutte le modifiche e le aggiunte firmate per iscritto e con un budget.
  • Perché hai le bollette da pagare
  • La parte scritta e firmata si assicura che sia ciò che vogliono veramente e riduce il 90% delle cose frivile che i clienti cambiano idea a metà strada durante il progetto

Il tuo prodotto invaso

Succede a tutti noi. Ricostruire da zero di solito è un'idea terribile, soprattutto considerando che sarà fatto di nuovo in futuro.

Invece, vorrei contrattare per le modifiche che l'utente ha richiesto. Aggiungi tempo extra per ogni funzione, usando il tempo originale per lavorare sulla funzione e il tempo extra per migliorare l'architettura complessiva, un piccolo miglioramento alla volta. L'obiettivo non è quello di "riparare" completamente l'architettura in un contratto, ma piuttosto di scheggiarla lentamente nel tempo.

Migliorare lentamente l'iterazione del codice mediante iterazione, concentrandosi sulle parti che contano davvero.