Come decidi se dovresti prendere un progetto?

Dalla mia esperienza: mai lavoro che coinvolge denaro per i familiari che devi trascorrere le vacanze con o amici che vuoi mantenere. Una delle parti coinvolte avrà sempre la sensazione che l'altra parte stia caricando troppo o non pagando abbastanza e che abbia fatto un favore all'altra parte. Quando arriva la scadenza, di solito sono la meno comprensiva, e di solito sono buchi di culo durante il beta test perché se hai un bug - che vuoi - non capiranno. È sempre un casino.

Ero idealista e pensavo che tutti gli altri avessero bisogno solo di migliori capacità delle persone, ma no, è proprio così. Le persone che non comprendono il processo di sviluppo del software saranno SEMPRE sconcertati quando qualcosa non soddisfa le loro aspettative nel primo momento in cui lo vedono. Questo è vero negli affari con i project manager tanto quanto con i membri della famiglia. Il problema è che devi mantenere una relazione con familiari e amici e le cose non sono mai strettamente aziendali.

Detto questo, se il progetto sta per aumentare i livelli di stress e non hai bisogno di soldi, allora perché prenderlo? Soprattutto se hai già un lavoro di sviluppo software su cui vuoi eccellere, direi che dovresti dedicare gran parte del tuo impegno lavorativo all'eccellenza nel tuo lavoro diurno perché è lì che alla fine sarai ricompensato per un lavoro di qualità.

Se hai bisogno dei soldi e stai bene con la potenziale perdita di un amico di famiglia, allora prendi il lavoro. La cosa peggiore che potrebbe accadere - a parte le cose che ho menzionato prima - è che impari cosa sei e non sei bravo, o impari che hai morso più di quanto puoi masticare causando un brutto progetto mal di testa a causa della tua inesperienza. L'ho fatto due volte con il mio attuale lavoro - fortunatamente ho dei datori di lavoro molto comprensivi. Sebbene fosse infelice mentre mi sentivo morto nell'acqua, emisi un programmatore molto migliore con un set di abilità molto più ampio di prima.

Non esiste un calcolo per determinare quali lavori lasciare e mantenere, solo l'esperienza e la tua personalità. Devi solo decidere cosa apprezzi e perseguirlo. Cose da considerare:

Questo è un progetto su cui mi piacerà lavorare? La squadra è una squadra con cui mi divertirò a lavorare?

Che tipo di pagamento offriranno? Se nessuno, allora quale sviluppo professionale riceverò? Offrono alcun tipo di rischio condiviso (vale a dire opzioni azionarie, percentuale di profitti)? Questo è un grande persuasore per me.

Comunque, questi sono solo i principi da usare nel processo decisionale. Tutto dipende da ciò che apprezzi. Ad esempio, apprezzo le sfide intellettuali e il tempo con la mia famiglia, quindi di solito attribuisco un'alta priorità a ciò che è il progetto e alle abilità che imparerò a farlo. Tuttavia, assicuro anche di dichiarare in anticipo che sto lavorando solo 2 o 3 notti a settimana in modo da poter passare del tempo con mia moglie e i miei figli poiché lavoro già tutto il giorno. Mi adeguo alla scadenza per soddisfare questa richiesta. Se a loro non piace, allora non prendo il lavoro.

Qualunque cosa tu faccia, assicurati di indicare chiaramente ciò che vuoi e non farai, e assicurati che dichiarino chiaramente le loro aspettative prima di accettare il lavoro. La cosa peggiore che può accadere è che il cliente abbia aspettative non dichiarate e che tu abbia sottovalutato quelle aspettative.

P.S. Vorrei davvero aver letto questo articolo all'inizio della mia carriera. Si applica al mio ultimo paragrafo. link

How do experienced developers make the decision of whether to take the project or just let it go?

Ho bisogno del lavoro? Se è così, "prendo" il progetto.

What are some good metrics to make the decision easier?

Quante scelte ho? Più di 1? Posso scegliere tra le alternative.

Solo 1? Bene. È così allora.

La questione "stress nella mia vita" è discutibile; mancata adozione di un progetto significa mancato mantenimento dell'occupazione; che ha conseguenze disastrose.

Se hai il tipo di libertà finanziaria in cui lo "stress" è un fattore decisivo, è davvero grandioso.

Che cosa guadagnerai da questo progetto? I soldi? Esperienza? Qualcos'altro?

• Soldi: proviene da un familiare (cerco di non fare affari con la famiglia, ma è tutta un'altra discussione), è piccolo (quindi lo fai sembrare), sei abbastanza giovane, quindi don ' mi aspetto un sacco di soldi da esso (basato sulle mie esperienze ).

• Esperienza: imparerai una nuova lingua! Ciò potrebbe essere utile in futuro, potrebbe darti un leggero vantaggio rispetto agli sviluppatori .NET che conoscono solo C #.

Ma il tuo istinto ti dice che questo progetto sarà cattivo . Perché? Sembra che potresti almeno avere una certa esperienza da questo.

La maggior parte degli appaltatori inizierebbe guardando quanti soldi avranno per decidere di intraprendere un progetto. Idealmente, i progetti più difficili portano a più soldi. Se questo è difficile, dovrebbe pagare bene, ma non conosco i dettagli per sapere se effettivamente verrà pagato bene ...

In risposta ai dettagli del tuo aggiornamento: digli che questo è ben oltre lo scopo di un singolo programmatore junior. Potresti essere in grado di fare qualche minuto di ricerca e vedere se c'è un prodotto esistente che può fare ciò che vuole e vedere se la pagina "Funzionalità" parla di personalizzazione / plug-in / estensibilità. Potrebbe anche voler parlare con un negozio di software personalizzato se nessun prodotto esistente è disponibile, oppure è necessario eseguire un vasto lavoro di programmazione di plug-in. Non c'è niente di sbagliato nell'ammettere che un progetto è troppo grande per essere gestito: è molto meglio che prenderlo e fallire completamente (specialmente se si tratta di un familiare - le funzioni familiari potrebbero essere scomode e tese per anni).

A friend of my family

Personalmente se questa frase è coinvolta, non prendo il progetto.

Come libero professionista, accetto solo progetti in cui sono fiducioso di poterlo completare in tempo, nel budget, in buona qualità. Rifiutare un progetto non significa disoccupazione, almeno non per sempre. Accettare un progetto che non puoi offrire costa tutto: denaro, reputazione, salute.

A volte è un po 'più difficile quando un buon cliente ha bisogno di aiuto per un nuovo progetto che semplicemente non si adatta alle mie capacità; ma anche così, è meglio essere onesti e lasciare che sia qualcun altro a farlo.

Nel tuo caso, puoi e dovresti rifiutare il progetto - non sei abbastanza esperto, non conosci la lingua, è troppo grande per te.

Ho fatto programmazione freelance per oltre venti anni. Perché un progetto abbia davvero successo, ha bisogno almeno del seguente:

1. Qualcuno che conosce la programmazione, il software e le tecnologie hardware utilizzate per la distribuzione - o tecnologie abbastanza simili per apprendere le tecnologie di implementazione davvero veloci
2. Qualcuno che conosce il dominio del problema ed è in grado e disposto a tradurlo in specifiche che il programmatore può utilizzare. (Se il programmatore è anche l'esperto di dominio, e il progetto è abbastanza semplice, le specifiche possono essere nella loro testa o note informali.)
3. Qualcuno che sia in grado, disposto e con esperienza di gestire bene le attività del progetto, la cronologia, ecc. e conosca i tipi di insidie che puoi affrontare con cose come la stima e come evitarli
4. Qualcuno che gestisca le comunicazioni e le relazioni tra tutti gli stakeholder del progetto, inclusi i programmatori e i clienti
5. Persone di entrambe le parti, consulenti e clienti, che hanno esperienza nel mantenere solidi gli affari in corso, inclusi contratti e denaro. Se non hai questa esperienza da solo, puoi andare avanti con un consulente esperto finché non lo sei.
6. Un rapporto commerciale lungo tutto l'arco in cui, se devi prendere una decisione aziendale difficile, non hai problemi al di fuori del lavoro
7. Un team abbastanza grande, con la giusta combinazione di esperienza, strumenti e risorse, per fornire un prodotto di qualità entro il termine richiesto

Descrivi un amico-della-famiglia che non sa nulla di programmazione, chi vuole che tu, un programmatore inesperto, costruisca un sistema ERP usando una tecnologia che non conosci.

Mi sembra che questa situazione non manchi assolutamente di # 1, # 3, # 6 e # 7, e forse tutti loro. Come dice Adam su Mythbusters, "Questa è una ricetta per il disastro."

Diamine, non vorrei toccare questo con una canna da dieci piedi me stesso. Potrei andare avanti all'infinito sulle altre bandiere rosse che vedo qui, ma in fondo, il mio consiglio per te è andare con il tuo istinto, perché hai ragione: "niente di veramente buono ne verrà fuori."

Dato che questo è un amico di famiglia, se fossi in te, direi semplicemente: "Hai un grande progetto, e hai bisogno di qualcuno davvero bravo, e io sono troppo inesperto per darti i risultati che dovresti avere , "e lascia perdere.

Ho anche scoperto che quando hai un cliente che è un problema in un'area, è probabile che sia un problema in altri. Un potenziale cliente che prenderebbe in considerazione l'idea di avere un sistema ERP progettato e implementato da un programmatore junior o è così ignorante da essere un pericolo per se stesso e per gli altri, o ridicolmente a buon mercato, e l'uno o l'altro li metterebbe nella mia lista "Stai lontano" .

FWIW, in qualità di consulente / libero professionista, finisco anch'io a ricoprire i ruoli dalla mia parte, con il consiglio di mia moglie. Abbiamo capito cosa sono tutti questi elementi vedendo i progetti fallire a causa della mancanza di essi - a volte, sono stati i nostri progetti. E anche dopo vent'anni, e nonostante la verifica di questi criteri, mi ritrovo ancora con un progetto occasionale che non funziona - il rischio è sempre parte dell'essere in attività. Ora mi assicuro solo che i progetti non falliscono a causa di qualcosa che ho fatto di sbagliato e che i contratti sono strutturati, quindi vengo pagato se l'altro lato si rovina.

Vuoi lavorare con le altre persone coinvolte?

Il progetto è solo una scusa per incontrarsi e associarsi con le persone.

La mia idea personale sarebbe quella di fare una piccola esplorazione di ciò che vuole, che tempistica, che tipo di costi si aspetta, ecc. Se questo è in realtà un grande ERP allora l'aiuto potrebbe durare per anni e ottenere davvero brutto forse. Gestione dei rifiuti vs SAP sarebbe un esempio di quanto sarebbe costoso questo se si intende davvero grande come in 9 budget di progetto a cifre.

Il mio punto nel fare l'esplorazione è tracciare una linea nella sabbia in modo che sia chiaro perché sto facendo le domande e cosa intendo avere come risultato. "Quanto riesco a vedere questo essere?" è la domanda che avrei come metterei in discussione la metodologia, il budget e le scadenze e quindi fare una piccola ricerca per vedere se le cose sembrano essere o al livello o è qualcosa che potrebbe finire in qualche sito di umorismo IT come Daily WTF .