Cosa devo fare per lasciare un lavoro professionalmente? [duplicare]

È consigliabile organizzare il tuo lavoro durante tutto il tempo in quel modo che la tua improvvisa scomparsa non avrebbe devastato il funzionamento della compagnia. Si dovrebbe sempre tenerlo a mente. Mantieni le cose chiaramente e logicamente strutturate, segnala regolarmente i tuoi progressi e controlla subito le cose.

Che cosa potresti fare specificamente negli ultimi giorni:

• Prepara un elenco di credenziali che sono presumibilmente sconosciute a quelle per sostituirti

• Prepara un rapporto sullo stato dei tuoi progetti e il loro stato

• Documenta tutti i problemi aperti e in sospeso di cui avevi intenzione di occupartene in un momento futuro

• Chiedi ai tuoi superiori se c'è qualcosa di specifico che vogliono che tu possa documentare

• Chiedi ai tuoi superiori se ci sono tutor che vogliono che tu dia a chiunque sia coinvolto

• Se sei stato coinvolto nel trattare con clienti e parti esterne, potrebbe essere sensato avvisarli della loro imminente modifica del contatto. Ma prima chiedi il permesso, a volte i tuoi superiori non vogliono che i clienti vengano avvisati delle persone che escono.

Questo praticamente lo copre.

Ammettiamolo, abbiamo tutti un debito di documentazione. Le ultime due settimane sono una buona opportunità per mettere quegli ultimi articoli in scrittura o nella testa del tuo collega. Se crei un documento, assicurati di rivederlo con il destinatario previsto per assicurarti che sia comprensibile.

Conferma che tutto il codice su cui stavi lavorando è compilato, e se possibile passa eventuali test di unità.

Crea un elenco di doveri che hai svolto mentre erano lì, compresi quelli sgradevoli che non desideri sul tuo curriculum e forniscili ai tuoi superiori. Ciò consentirà loro di assicurarsi che tutte le tue attività siano coperte e assumere un sostituto appropriato.

Assicurati che tutti i tuoi dati siano salvati e resi accessibili ai tuoi colleghi.

Prendi nota dei numeri di telefono delle persone di cui vuoi tenere traccia!

Non posso mai dimenticare questo post di Mike Hofer in "Qual è il tuo parere di programmazione più controverso?" ogni volta che viene posta una domanda in questo senso ...

Your job is to put yourself out of work.

When you're writing software for your employer, any software that you create is to be written in such a way that it can be picked up by any developer and understood with a minimal amount of effort. It is well designed, clearly and consistently written, formatted cleanly, documented where it needs to be, builds daily as expected, checked into the repository, and appropriately versioned.

If you get hit by a bus, laid off, fired, or walk off the job, your employer should be able to replace you on a moment's notice, and the next guy could step into your role, pick up your code and be up and running within a week tops. If he or she can't do that, then you've failed miserably.

Interestingly, I've found that having that goal has made me more valuable to my employers. The more I strive to be disposable, the more valuable I become to them.

Credo che idealmente, sia a livello individuale che a livello di team, tutto il software dovrebbe essere scritto per essere il più facile da prendere il più possibile. Letteralmente: se l'intera squadra subisce avvelenamento da cibo e muore quando va a pranzo in gruppo, la compagnia dovrebbe essere in grado di assumere un nuovo team di sviluppatori - e il progetto dovrebbe essere così pulito e ben documentato che le nuove persone possano intervenire e raggiungere la piena produttività entro un paio di settimane.

Quindi in sostanza, penso che sia più una questione di "processo in corso" di qualsiasi altra cosa dovresti fare quando esci. Non è sempre pratico in ogni singolo momento, ma credo che sia meglio lavorare come se si potesse lasciare il lavoro in qualsiasi momento. Codifica, documenta e aderisci a processi tali che ogni sviluppatore decente possa calarti nei tuoi panni in qualsiasi momento e non strappare i capelli a niente perché è troppo ottuso.

Una cosa che mi piace fare quando cambio lavoro è passare un po 'di tempo durante l'ultima settimana, facendo una lista TODO per lo sviluppatore che subentrerà.

Spiega dove ti trovi attualmente nel programma, perché hai preso alcune decisioni architettoniche chiave e dove le cose devono andare.

Ovviamente cose come le password - come eseguire il processo di compilazione - ecc. dovrebbero essere facilmente disponibili.

Vorrei aggiungere la lista di @Developer Art:

Assicurati che tutto sia selezionato nel controllo del codice sorgente (con i commenti) prima di partire (è davvero fastidioso quando qualcuno si dimentica di farlo).

Assicurati che sappiano specificamente cosa è ciò che non è finito nei progetti di curriculum come parte del tuo elenco di stati.

Se hai email che saranno pertinenti alla prossima persona assegnata ai progetti che il tuo capo non ha, inoltrale a lui.

Anche se il manaegment dovrebbe sapere dove sono i requisiti di progetto ei file di controllo del codice sorgente, è utile per loro avere un documento riassuntivo che possono dare alla prossima persona assegnata invece di doverli creare da soli. Pensa a tutte le cose che vorresti sapere su un progetto in corso nel tuo nuovo lavoro e mettilo in un documento per il tuo capo riguardo ai tuoi progetti attuali. Se sei su più di un progetto, crea un documento separato per ciascuno.

Per quanto riguarda le password, ci sono due considerazioni. Genero nuove password casuali e le cambio, e allo stesso tempo scrivo una lista. In questo modo so che hanno accesso in corso e sappiamo entrambi che non lo faccio.