Come avvicinarsi al vecchio "questa sarà solo una piccola applicazione"? Si, come no?

11

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

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

Quindi, in base a budget e vincoli, eccetto alcuni degli architetti e mi tuffo e non mi preoccupo.

Quindi chiedono un altro modulo. E un altro. E alcuni miglioramenti. E tutto questo accade molto lentamente, attenzione, per anni. E prima che tu lo sai, hai questa mostruosa applicazione che è orribilmente progettata.

Che 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 si può sovra-progettare la cosa, perché dopotutto è solo una piccola applicazione e andranno da qualche altra parte se si dice (nel senso che conosco tutte le voci) "Beh, per ogni caso, architettiamo questa cosa in strati con la massima sicurezza e separazione delle preoccupazioni, in effetti andiamo con uno strumento di iniezione di dipendenza che renderà davvero questa cosa fantastica bla bla bla ".

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

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

Come dovrebbe essere affrontato?

Suppongo che la domanda si riduca a "Quando non hai tutte le informazioni per il risultato finale di quella che sembra una piccola applicazione, come puoi evitare (o mitigare) prendere decisioni di progettazione e di progettazione in anticipo? sarà completamente inopportuno in seguito?

    
posta richard 06.08.2011 - 09:35
fonte

5 risposte

17

Ne ho incontrati parecchi e quello che faccio normalmente è esattamente quello che hai fatto, immergerti subito e completarlo.

Quando tornano per più, significa che il loro modello di business sta funzionando e che dovrebbero essere disposti a investire un po 'di più. È allora che li metto a posto (di solito il 3 ° modulo dipende dalla complessità) e dico loro le cattive notizie.

Metterò tutto sul tavolo, offrirò di rifare l'intera cosa incluso l'ultimo modulo e dirgli quanto costerà. All'inizio avranno di solito un po 'di shock adesivo, ma se hai un buon rapporto di lavoro e le tue cose funzionano, non dovrebbe essere un grosso problema.

Assicurati che capiscano tre cose però:

  1. Se davvero non vogliono preoccuparsi di una completa riscrittura, farai comunque il terzo modulo. Potrebbe volerci qualche ora in più e tu li fatturerai per questo. Ricorda loro che dovrebbero davvero pensare di fare una riscrittura in futuro, perché più aspettano, più costerà.

  2. Davvero gli costerà di più per convincere qualcun altro a farlo. La nuova persona deve ridisegnare tutto con una minima comprensione dei loro bisogni e stranezze, il che significa tempi di riscrittura extra e il rischio che non faccia un lavoro altrettanto buono.

  3. Che non stai cercando di fare un soldo veloce. La cosa ha bisogno di una riprogettazione.

BTW, se la tua abitudine di fatturazione è qualcosa come metà ora, metà della sua esecuzione, potresti considerare di offrire loro termini di pagamento estesi. Cambialo a metà ora e dividi il saldo nel periodo in cui lavorerai su di esso. Ciò potrebbe ridurre il problema se hanno problemi di budget.

    
risposta data 06.08.2011 - 10:15
fonte
10

Fagli una piccola app e pagati per questo.

In base alla mia esperienza, è urgente investire più tempo all'inizio del necessario, nel caso in cui il cliente desideri di più. Ma devi pesare l'effetto nel farlo (sei pagato per questo) rispetto alla propensione che tutti questi cambiamenti addizionali si verifichino realmente. L'intera app potrebbe essere sostituita completamente dopo un anno.

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

Adde semplicemente un piccolo addebito al cliente per ogni modulo di successo e rifatti il progetto iniziale passo dopo passo, ma sempre solo per soddisfare le esigenze del cliente.

    
risposta data 06.08.2011 - 09:55
fonte
8

Le risposte precedenti sono buone e, se sono onesto, quello che probabilmente farei. Detto questo, sono un po 'a disagio per questo approccio in quanto stai prendendo decisioni che appartengono propriamente al cliente, in base a una supposizione di ciò che vogliono (e al desiderio di trovare il lavoro)

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

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

Commenti che altri hanno fatto sul fatto di avere un buon rapporto di lavoro sono chiari - 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 chiedersi quanto ti serve questo lavoro ...

    
risposta data 06.08.2011 - 13:31
fonte
1

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

È un modo di guardarlo, invece di uno ... progetto LONGGGGG.

    
risposta data 06.08.2011 - 18:32
fonte
1

how do you avoid (or mitigate) making architecural and design decisions early on that will be completely innapropriate later?

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

La tua domanda diceva che aveva processi di business ma non sono sicuro che siano processi validi. Ecco alcuni suggerimenti:

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

Il tuo prodotto troppo cresciuto

Succede a tutti noi. Ricostruire da zero di solito è una pessima idea, soprattutto considerando che verrà fatto di nuovo in futuro.

Invece, mi contraggono per le modifiche richieste dall'utente. Aggiungi tempo extra per ogni funzione, utilizzando il tempo originale per lavorare sulla funzione e il tempo extra per migliorare l'architettura generale, un piccolo miglioramento alla volta. L'obiettivo non è quello di "riparare" completamente l'architettura in un unico contratto, ma piuttosto di crearlo lentamente nel tempo.

Migliora lentamente l'iterazione del codice per iterazione, concentrandoti sulle parti che contano davvero.

    
risposta data 02.09.2011 - 02:21
fonte