Le aziende dovrebbero considerare dipendenti remoti o attenersi ai dipendenti locali? [chiuso]

Ho lavorato come e gestito personale in entrambe le situazioni e combinazioni di entrambi. Ho fatto le seguenti osservazioni:

• Il personale Junior non lavora in remoto. Richiedono una buona e personale relazione di lavoro con un mentore. Trovo che il mio junior staff preferisca aspettare che sia disponibile piuttosto che chiedere allo sviluppatore remoto piuttosto anziano (e buono) qualsiasi cosa.

• Assicurati che chiunque consideri di lavorare in remoto sia efficace quando è autoguidato e non si muove sulle tangenti.

• Lo staff remoto può essere facilmente isolato e non sentirsi parte di una squadra, a meno che non si faccia uno sforzo particolare per includerli. Questo isolamento può portare a un fraintendimento del driver di business specifico per un progetto o a interpretare erroneamente gli eventi in modo negativo.

• Non ottenere mai un appaltatore che lavori in remoto, a meno che non abbiano il giusto incentivo per eseguire.

• Quando lavori con un membro del team remoto, assicurati che ottenga un accesso equo alle risorse, incluso il controllo del codice sorgente, il materiale di riferimento, ecc. Non farli saltare attraverso i cerchi per portare a termine il lavoro.

• Organizza le riunioni faccia a faccia il più spesso possibile. Ciò incoraggia una collaborazione di squadra molto migliore in quanto le persone sono più a loro agio con quelle che hanno incontrato.

Forse.

I tuoi vantaggi sono:

• Accesso a un gruppo più ampio di candidati (come fai notare)
• Accesso alle persone che desiderano lavorare a casa

I tuoi costi sono:

• Comunicazione più difficile: non puoi semplicemente portare qualcuno in una sala conferenze libera.
• Nessuna garanzia di comunicazione istantanea: se sei bloccato e stai aspettando Joe Remote, non puoi semplicemente andare alla sua scrivania e chiedergli cosa succede. Se è in isolamento, sei SOL.
• Non tutti gli sviluppatori funzionano bene da remoto. Alcuni hanno bisogno che l'ambiente strutturato sia produttivo.
• Spesso non vi è alcuna garanzia di abbinamenti di orari, ad esempio una persona che lavora da casa potrebbe dormire o una persona in un'altra fascia oraria potrebbe essere sveglia e lavorare in tempi diversi da voi.

Atwood ha pubblicato un articolo decente a riguardo.

Modifica, dall'articolo di Atwood:

The minimum remote team size is two. Always have a buddy, even if your buddy is on another continent halfway across the world.

Only grizzled veterans who absolutely love to code need apply for remote development positions. Mentoring of newbies or casual programmers simply doesn't work at all remotely.

To be effective, remote teams need full autonomy and a leader (PM, if you will) who has a strong vision and the power to fully execute on that vision.

Va bene avere persone remote se due cose sono vere:

1. Le persone sono abbastanza anziane e hanno un track record che significa che ti fidi di loro per fare le cose senza molta supervisione e di essere proattivo nel chiedere aiuto o farti sapere se sono bloccati.
2. Il "polso" del tuo progetto è abbastanza breve (preferibilmente ogni giorno) in modo che eventuali problemi con la disposizione saranno identificati rapidamente. Non intendo solo qualcuno che dice di aver fatto qualcosa in un rapporto di stato o di controllare un elemento da un elenco di attività, ma di progressi effettivi e dimostrabili con una funzione. Ci sono naturalmente molti modi per farlo, ma il trucco principale è dividere le attività in blocchi abbastanza piccoli che possono essere eseguiti in un giorno o meno, e verificare che queste attività siano state completate.

Oggi ci sono tecnologie straordinarie che rendono facile agire come una squadra senza essere seduti l'uno vicino all'altro.

IRC, Jabber o software di tipo chat simile rendono davvero facile tenere tutti gli altri in squadra consapevoli l'uno dell'altro, cosa stanno facendo e sentirsi liberi di discutere immediatamente i problemi. Uso spesso IRC con i gruppi di freenode ed è come avere un grande gruppo di sviluppatori a portata di mano, che agisce come un gigantesco cervello collettivo. Apple ha un bel client di chat incorporato in Mac OS che supporta anche le videoconferenze, particolarmente efficaci con i loro laptop.

Immagina come sarebbe se la società avesse il proprio server di chat interno, con gruppi per dipartimenti, progetti e gruppi di interesse legati al lavoro. Uno sviluppatore potrebbe porre una domanda dove sarebbe stato visto in tutta la società, quindi un altro sviluppatore in qualsiasi altro posto potrebbe vederlo e rispondere. I muri dell'ufficio scompaiono, le comunicazioni alle stelle e le best practice e la condivisione del codice possono accadere da sole senza che qualcuno maneggi un grosso bastone.

Uno dei nostri ingegneri di test di carico lavora da remoto circa 1/3 dell'anno, a volte da casa sua, a circa 30 miglia dal nostro ufficio, altre volte da fuori Stato. È tanto efficace in ufficio quanto fuori, perché mantiene attivo il suo software di chat e chiama per le nostre teleconferenze.

I miei colleghi della mia squadra si siedono in corridoio per non vederli o sentirli. Non so quando sono nei loro cubi, quindi invio loro un messaggio di chat e loro rispondono il prima possibile. Faccio programmazione in team con uno dei nostri ingegneri in un altro sito. La stessa cosa accade; Ci picchiamo a vicenda regolarmente con domande e / o pensieri inutili, e se dobbiamo aumentare il ritmo condivideremo uno schermo e andremo al telefono. Non posso dire se è in ufficio oa casa, e non importa. Lavoriamo allo stesso modo.

Il nostro dipartimento QA è suddiviso tra due città diverse in stati diversi, i nostri ingegneri sono distribuiti in tutta la nostra città in circa quattro diversi luoghi, ma è difficile da dire perché usiamo i nostri telefoni e chattiamo regolarmente. Lavoriamo tutti a distanza gli uni dagli altri in realtà, quindi qual è la differenza? La differenza è la mentalità aziendale.

Ci sono molti grandi vantaggi nel lavorare da remoto, e soprattutto ci vuole un cambiamento di mentalità perché il datore di lavoro cerchi di scoprire che i dipendenti rispondono positivamente ad esso.

Penso che dipenda anche da ciò che vuoi che facciano.

Se stanno contribuendo all'architettura e alla progettazione generale del software, potrebbe essere un problema.

Se ricevono specifiche dettagliate e metodi sfornanti, allora non tanto.

Modifica: per chiarire, sto cercando di dire che se il lavoro può essere isolato, allora va bene dare a un dipendente remoto. Se, tuttavia, è necessaria una discussione dettagliata e incontri di progettazione architettonica, è molto difficile farlo da paesi diversi.