Quali opzioni ha uno sviluppatore disciplinato quando si unisce a un team di sviluppatori indisciplinati come membro normale, non come lead? [chiuso]

Senza essere in una posizione di comando della squadra, le opzioni sono piuttosto limitate. Esistono diverse basi di potere . L'individuo nella tua domanda non avrà il potere legittimo, in quanto non è il capo o il manager e non ha la posizione per guidare il cambiamento. Tuttavia, a seconda della loro personalità, possono essere in grado di sviluppare una posizione di potere referente o potere esperto, ma ciò richiederà tempo. L'uso del potere coercitivo probabilmente non sarà utile nell'attuare le modifiche.

Se esiste un supporto manageriale per l'implementazione di queste buone pratiche nel team, avere qualcuno a conoscenza delle pratiche, del team e delle componenti tecniche del progetto sarebbe estremamente prezioso. Tuttavia, avrebbero bisogno di lavorare a stretto contatto con il manager per attuare eventuali modifiche. L'individuo dovrebbe essere presente per il lungo raggio e comprendere il loro ruolo nel facilitare la visione del management.

Se né la dirigenza né i membri senior del team vogliono cambiare le cose, penso che sia molto improbabile che qualcosa cambierà. Il cambiamento deve venire da qualche parte, dall'alto verso il basso dalla direzione o dal basso verso l'alto dal team. Se nessuna parte è disposta a supportare il cambiamento, il cambiamento non avverrà.

Sarei interessato alla capacità dello sviluppatore di andarsene. Lavorare nelle condizioni che descrivi - altri sviluppatori che non migliorano o maturano continuamente le loro competenze, mancanza di buone pratiche di ingegneria del software e non essere in grado di guidare le modifiche per migliorare le condizioni di lavoro - potrebbero portare lo sviluppatore a lasciare il squadra o l'organizzazione per trovare una soluzione migliore. Se lo sviluppatore continua a lavorare su di esso, potrebbero vedere livelli più elevati di stress, ansia e persino burnout .

In alternativa, guidare le modifiche dall'alto verso il basso potrebbe allontanare i membri del team. Se hai persone con una conoscenza business-critical molto specifica e hai apportato modifiche che considerano difficili, potrebbero diventare scontenti e lasciare anche l'organizzazione. Il management deve prestare attenzione quando implementare le modifiche per avviare un processo di trasformazione, ma non perturbare le persone o le attività commerciali.

La maggior parte degli sviluppatori si trova a dover creare software scadenti o meno gestibili / non scalabili / non proprio così perfetti al fine di rispettare una scadenza arbitraria o di essere licenziati. Uno dei motivi per cui i bravi programmatori sono considerati buoni è perché sono in grado di resistere a questa situazione a causa della loro reputazione, influenza, capacità persuasive, minacce di allontanamento, ecc.

Essere una "rockstar" è relativo e non dovrebbe essere troppo difficile per far brillare qualcuno in questo gruppo. Crea software altrettanto e meglio in metà tempo. Poi vai via nel bel mezzo della giornata. Vogliono tutti sapere come sei in grado di farlo. O più probabilmente, fai le cose e ti assegneranno compiti difficili. Imposta un esempio.

Osserva cosa stanno facendo tutti. Fare domande. Potresti scoprire che non sono gli sviluppatori a non essere disciplinati. Aiutali a sistemare le cose che vedono come problemi. Non puoi cambiare tutto in una volta. Poche persone vogliono essere un cattivo programmatore, ma questo non significa che siano disposti a fare ciò che serve per migliorare. L'influenza di un buon programmatore sarà accettata da alcuni. Una buona compagnia può solitamente estirpare i non-hacker. Non essere sorpreso se questo richiede alcuni anni.