Come posso convincere un membro del team a utilizzare un framework web? [chiuso]

Non riuscirai a convincerlo a farlo. Si chiama effetto Dunning-Kruger . È troppo ignorante per sapere cosa non sa e ha troppa paura di perdere ciò che definisce come un vantaggio.

Quando non riesci a raggiungere un consenso, devi raggiungere un compromesso. Forse puoi dividere il lavoro in modo che il suo bisogno di apprendere il quadro sia minimo. Forse hai una sorta di "design-off" in cui ognuno fa il suo modo per un paio di settimane e poi la squadra vota su quale sia il migliore. Forse puoi coinvolgere il tuo professore sponsor o chiunque sia il cliente nel risolvere il problema.

Un argomento a tuo favore è la riusabilità della conoscenza. Tutti i membri del team che apprendono un quadro ben noto e ampiamente utilizzato (come CodeIgniter) saranno in grado di riutilizzare le proprie conoscenze sul prossimo progetto. Considerando che la conoscenza di una "biblioteca" proprietaria e casuale non è riutilizzabile. Questo può risuonare bene con gli altri membri del team, poiché probabilmente preferiscono acquisire alcune utili e riutilizzabili conoscenze su questo progetto.

Un altro argomento potrebbe essere una misura concreta dei costi di sviluppo / manutenzione. Immagino che uno sviluppatore esperto di CodeIgniter possa svilupparsi più rapidamente di quanto il tuo collega abbia scritto personalmente tutte quelle funzioni proprietarie. Questo potrebbe essere dimostrato dal fatto che sia tu che lui costruite una pagina web identica - voi con CodeIgniter, lui a modo suo - e misurate i tempi necessari per il completamento. Quindi crea una serie di modifiche / estensioni alle pagine, misurando nuovamente il tempo necessario. Naturalmente, le specifiche dovrebbero essere preparate da qualcuno indipendente da entrambi, per combattere su un terreno neutrale.

Un altro - come hai detto tu - è la qualità del codice. Una volta che le pagine web sono pronte, esegui lo stesso set di test di accettazione su ciascuna di esse e confronta la densità dei bug.

Naturalmente, quando si è sotto pressione, potrebbe non esserci alcuna possibilità di fermarsi e fare tali misurazioni. Quindi probabilmente vorrai una risoluzione veloce a questo dilemma. Prova a convincere gli altri membri del team (ad esempio facendogli leggere le prossime risposte al tuo post qui :-), per aumentare la pressione del gruppo su di lui. Alla fine, se davvero non può essere convinto, potresti voler tagliare il progetto in due parti, una per lui e - idealmente - una per il resto della squadra, usando CodeIgniter. Concentrati a fare la tua parte al meglio delle tue capacità e fagli fare ciò che vuole. I risultati probabilmente parleranno da soli.

Sento che devi coinvolgere gli altri 3 compagni di squadra. Entrambi avete bisogno di presentare i vostri argomenti a loro e spiegare loro le cose in modo che capiscano. Alla fine della giornata, dovranno lavorare anche con questa base di codice. E se tutti sono uguali, allora dovrebbero dire qualcosa su ciò con cui desiderano lavorare.

Penso che per ognuno di voi sia un buon approccio per delineare i vantaggi delle rispettive soluzioni e mostrare agli altri membri del team perché ritenete che sia il modo migliore per andare. Quindi lascia che decidano. Ci sono 3 di loro quindi sarà il tie breaker.

Una cosa che vorrai sottolineare è che se questo è il tuo progetto suor, e gli altri membri del team non hanno altra esperienza, questo progetto deve riflettere il lavoro che possono fare ai potenziali datori di lavoro. Se lo fai bene, può essere un buon punto di discussione in un'intervista. So che chiedo ai neolaureati di delineare il loro progetto senior e come è stato progettato e sviluppato.

Se vanno con l'approccio dell'altro, dovrai risucchiarlo. Ma non rinunciare alla speranza. Vieni con un buon design in modo che il caos che sta scrivendo non avrà alcun impatto su tutto. Se hai tempo, fai un po 'di codice per ripulire e refactoring alcune delle sue cose e mostragli che non deve reinventare la ruota ogni volta.

Credo che il college sia come una sandbox. La maggior parte delle cose che fai non vengono utilizzate nella distribuzione. Quindi ti dà molta più libertà di sperimentare e uscire dalla tua zona di comfort. Esplora nuove cose perché il fallimento non avrà troppo impatto. Inoltre, nella tua situazione, i membri del tuo team hanno il vantaggio in più di avere qualcuno con conoscenze pregresse che li aiuta.

Per quanto riguarda l'altro membro del team esperto, non ha bisogno di venire al college se non vuole imparare qualcosa di nuovo. Questa è una buona opportunità per imparare qualcosa di nuovo e aggiungerlo alla sua cassetta degli attrezzi.

E per i membri del team inesperti, le loro possibilità di essere impiegati / impiegati meglio aumenteranno con un quadro come CodeIgniter sul loro curriculum (in realtà le conoscenze per giustificare il loro curriculum).