Gestione di consulenti p / t come collaboratori Open Source?

2

Ho appena assunto il ruolo di leader tecnologico per un progetto che ha avuto un problema con i suoi appaltatori part-time (forse 2-5 ore / settimana):

  • invio del codice che fa cadere l'app di produzione,
  • richiama richieste che non possono essere unite automaticamente,
  • scrittura di test erroneamente detti che non testano effettivamente ciò che rivendicano e
  • non scrive test per le nuove funzionalità inviate.

Un grosso problema è che questi appaltatori remoti e part time non sono in ufficio per rispondere immediatamente se c'è un problema con il loro codice.

Inoltre, sono l'unico sviluppatore a tempo pieno nell'app e non possiamo permettermi di dedicare il mio tempo a controllare e eseguire il debug del codice degli altri.

La mia idea è di adottare uno stile di lavoro open-source con loro. Ad esempio, un grande, importante progetto (come Linux, Ruby, Rails, ecc.) Accetterà le modifiche proposte? Scopriamo i criteri che hanno e poi li rafforziamo. Lasciamo andare ogni imprenditore che non gioca secondo le regole.

È questo il modo di gestire le relazioni?

MODIFICATO: per evidenziare la natura molto part-time dei contraenti. Meno di 10 ore a settimana, di solito 2-5.

    
posta Dogweather 15.10.2013 - 21:22
fonte

1 risposta

1

Una cosa che ho cercato di superare nella mia precedente azienda con un successo limitato è che un progetto deve mantenere un rapporto minimo tra pensatore e operatore, se arrivi alla soglia e vai oltre, ti troverai in una situazione in cui ti trovi. Troppe persone che "eseguono" semplicemente i compiti in realtà stanno introducendo più danni che benefici.

Ecco perché continuavo a dire al mio capo e al suo capo che abbiamo bisogno di trascorrere del tempo e investire nelle persone. Dare loro un po 'di libertà e anche più responsabilità (se scelgono di averlo, non spingerlo giù alla gola) e promuovere più pensiero e assunzione di proprietà per il prodotto.

Tuttavia, tutto ciò che ho affrontato è stato interno al nostro team di sviluppo con persone a tempo pieno. Non sono mai stato nella tua situazione e sembra quasi che l'appaltatore con la sua definizione sia un "agente", ma di nuovo, non necessariamente.

Quindi il mio unico consiglio, e sto facendo la maggior parte di questo sarebbe:

  • Verifica se puoi avere un'altra persona permanente nel tuo team per aiutarti con le recensioni e il monitoraggio
  • Limita il numero di appaltatori con cui lavori a) mantieni solo i primi N che causano il minor numero di spese generali eb) hai più tempo per fare il tuo lavoro, non solo fai recensioni tutto il giorno
  • Identifica i buoni appaltatori a lungo termine e prova a convertire alcuni di loro in "pensatori". Se ti piace lavorare con loro e gli piace lavorare con te e hai già stabilito delle aspettative, vedi se riesci a stabilire una sorta di gerarchia in cui quei ragazzi riesamineranno effettivamente il lavoro di altri appaltatori.
  • Come hai suggerito, stabilisci alcune linee guida di base che tutti dovrebbero seguire e quando esegui una revisione, se tali linee guida non vengono soddisfatte, rifiutale con il minimo sforzo da parte tua.

Sfortunatamente, l'ultima cosa che vuoi fare è smettere di monitorare / rivedere / tutorarli. Come suggerito da Dan nei commenti, come team leader, questa è la tua priorità più alta rispetto alla consegna del tuo codice.

    
risposta data 15.10.2013 - 23:19
fonte