Domanda:
Quando devo dire al mio capo che sono senza lavoro?
Anon
2017-05-30 12:58:49 UTC
view on stackexchange narkive permalink

Sono uno sviluppatore di software, ma non sono il "manager del mio tempo" perché ho un capo che mi dà compiti e scadenze. A volte mi capita di essere inattivo per ore, a volte anche per giorni. Durante questi periodi Guardo sempre il codice e studio o cose del genere, quindi non ho bisogno di sapere cosa fare per far passare il tempo.

Qual è il tempo corretto dopo essere stato inattivo per notificare al mio capo?

Per chiarire: se finisco il mio lavoro prima delle scadenze do sempre un avviso al mio capo, ma per vari motivi (il mio capo stesso è sepolto con documenti legali, devo aspettare altri sviluppatori per finire il loro lavoro e così via ...), a volte capita solo di aspettare.

Nella vendita al dettaglio dicono "se puoi appoggiarti, puoi pulire".C'è sempre unit test o documentazione da fare (o refactoring, ma potrebbe essere necessario approvazioni).Fai sempre un lavoro di backup quando parli con il tuo capo "Ho finito tutto il mio compito, fammi sapere quando ce ne saranno altri. Nel frattempo, farò X.".
Una nota a margine "... essere inattivo per ore, a volte anche per giorni" mostra una mancanza di capacità di lavorare da soli.Se non riesci ad allenarti dovresti fare qualcosa al lavoro dopo poche ore, figuriamoci pochi giorni, qualcosa è seriamente sbagliato.Dovresti far sapere a chiunque assegni i tuoi compiti non appena hanno finito.Per quanto ne sai stanno aspettando che tu finisca per poter assegnare qualcos'altro, nel frattempo pensando "Accidenti Anon ci vuole molto tempo per finire i loro compiti ..." Il che è ovviamente un brutto segno contro te stesso.
In una nota a margine correlata, prendi in considerazione l'idea di suggerire l'uso di un sistema di tracciamento dei problemi, se non è già presente.Ciò consente di comunicare il completamento dell'attività con interruzioni minime.Ti offre anche uno spazio per documentare piccoli problemi / funzionalità che puoi risolvere nel tempo tra le modifiche principali.
Se davvero non ti è permesso lavorare su qualcosa senza che ti sia assegnato e puoi andare avanti per giorni senza incarichi, anche se li hai richiesti, allora direi che è il momento di dire al tuo capo che non stai facendotutto va bene nel momento in cui ti dimetti.
@the_lotus Alcuni luoghi unit test e documentazione non sono considerati qualcosa che gli sviluppatori fanno nel loro tempo libero, ma parti essenziali della consegna.
"Qual è il tempo corretto dopo essere stato inattivo per notificarlo al mio capo?"- L'hai capito al contrario.Il momento "corretto" per dirlo al tuo capo è quando puoi dire con sicurezza "Dovrei finire questo compito entro la fine di oggi / domani / questa settimana. Cosa c'è dopo nella mia lista di cose da fare?".La mia parola per descrivere qualcuno che fa rapporto a me e si accontenta di essere "inattivo per ore, a volte anche per giorni" sarebbe "osso inattivo senza motivazione" - e vorrei sbarazzarmene il prima possibile!
Se un manager desidera molto controllo, di solito gli dico che sto per esaurire le attività una volta che sono abbastanza sicuro di poter terminare quella corrente nel tempo stimato rimanente.** Cerco di anticipare l'esaurimento delle attività in anticipo in modo che i manager siano consapevoli prima che arrivi il crollo, per dare loro il tempo di inventare qualcosa prima che io finisca per inattività.
Suggerirei di cercare un altro dipartimento o un posto dove lavorare.Essere il tempo "gestito" in un ambiente del genere porterà all'autocompiacimento e ad un'abitudine fiacca.Questo non è un ambiente sano in cui lavorare. I migliori lavoratori (e programmatori) che conosco sono quelli che non si permettono di rimanere in una situazione in cui un micro manager impedisce loro di portare a termine le cose.
Potresti sicuramente dedicare più tempo a `stackoverflow` ...
Ci sono molti suggerimenti, a seconda del campo in cui lavori. Vedi se riesci a lavorare su funzionalità sperimentali o simili.Forse puoi prototipare cose che l'azienda vuole, ma non deve pianificare.In tal caso potresti creare un ramo separato e lavorarci su quando hai tempo.Magari creando qualcosa di eccezionale per l'azienda e la tua crescita personale.
E ora ho dei flashback su quando il mio precedente capo voleva che lavorassi a Project X, nonostante nessun design, specifica, dettagli o anche una vaga nozione di cosa fosse * Project X. * Sarei stato rimproverato per aver lavorato su Project Y(che era letteralmente "aggiornalo per iOS 10") che doveva essere fatto allo stesso tempo.Il mio capo e io avevamo conversazioni quasi quotidiane che dicevano: "Perché non lavori su X?""Hai capito cos'è X?""Haha, è divertente! No. Vado a pranzare."Finito per fare quello che @RalphBolton suggests: ha smesso.Il progetto per X è sceso con 14 ore rimanenti.Neanche tu hai finito
Cinque risposte:
Glorfindel
2017-05-30 13:07:10 UTC
view on stackexchange narkive permalink

La revisione del vecchio codice e lo studio sono entrambi importanti per lo sviluppo personale e (direttamente o indirettamente) vantaggiosi per l ' azienda . Quindi non lo definirei "inattivo", il che significherebbe che stai semplicemente guardando fuori dalla finestra.

Detto questo, dovresti informare il tuo capo immediatamente dopo aver terminato un compito, in modo che lui / lei possa decidere se ci sono questioni più urgenti della revisione del codice o dello studio.

Informali dicendo "Ho completato il mio compito attuale e leggerò e imparerò il codice fino a quando non verrà assegnato un nuovo lavoro" o qualsiasi altra attività adatta ...
@HorusKol è probabilmente un buon modo per esprimerlo.
Ho lo stesso problema.In genere dico al PM che ho "larghezza di banda" e posso lavorare su qualcosa una volta che ho completato le mie attività.Di solito si incontra con "troveremo qualcosa su cui lavorare" a cui mi viene assegnato un compito di 10 minuti 5 ore dopo.In definitiva, un ufficio così disorganizzato da non poter mantenere i propri dipendenti occupati in modo remunerativo è uno che non merita il tuo tempo.
Inoltre, non limiterei lo studio solo al tuo attuale codice base.Potresti considerare di aggiungere / aggiornare commenti / documentazione del codice esistente ... prova che l'hai effettivamente guardato (e capito?).Inoltre, apprendere nuove librerie e strumenti che potrebbero aiutare te stesso e il tuo team in seguito (unit test, jq, regex, plug-in IDE ... ecc.).Potresti anche contribuire attivamente a una delle librerie open source che la tua azienda probabilmente sta utilizzando ... trova la sua pagina GitHub, scegli un problema e inizia l'hacking.
Penso che dovresti effettivamente menzionare molto prima di finire i tuoi compiti che avrai la capacità per più lavoro.Fa parte del motivo per cui si incontrano quotidianamente nello sviluppo del software.Sarei molto seccato scoprire che qualcuno nel mio team non aveva lavoro, sapeva che non avrebbe avuto lavoro e non mi ha detto nulla (anche se devo ammettere che di solito so bene in anticipo quale lavoro c'è e lascio che i membri del teamsapere cosa è disponibile quando finiscono i loro compiti).
@SandyChapman Ho considerato anche questo, ma ho scoperto che Kate Gregory l'aveva già pubblicato come risposta.Inoltre, non vorrei che uno dei membri del mio team segnalasse di aspettarsi di finire con un compito in due ore, e poi non all'altezza di tale aspettativa perché * Ho trovato alcuni bug durante il test finale, ne ho bisogno di un altromezza giornata per risolverli *.Lo sviluppo del software (compresi i miei lavori) è spesso difficile da prevedere a quel livello di dettaglio.
Kate Gregory
2017-05-30 18:27:21 UTC
view on stackexchange narkive permalink

Il momento giusto per chiedere più lavoro dipende da quanto tempo impiega il tuo capo per darti più lavoro.

  • se il tuo capo tiene un "arretrato" di attività e può dirti "fai l'articolo 2345" in pochi secondi e il tuo capo è sempre presente quando vuoi chiedere, allora può chiedere nel momento in cui finisci il lavoro
  • se il tuo capo potrebbe non essere raggiungibile per alcune ore o ha bisogno di alcune ore per capire cosa darti dopo, allora il tempo corretto è il doppio o triplo. Quindi, se vai al lavoro martedì mattina e ti rendi conto che "finirò questo oggi, e poi posso dare un'occhiata a quel tutorial [novità] ma ho bisogno di qualcosa di nuovo per domani", prima di iniziare qualsiasi altra cosa, invia un'email a / rilassati / skype / visita il tuo capo e consegna esattamente quel messaggio: "Finirò X oggi, quindi posso dare un'occhiata a quel tutorial Y ma ho bisogno di un compito per domani." Se ottieni l'attività prima di iniziare il tutorial, il tutorial può attendere
  • se il tuo capo potrebbe non essere raggiungibile per giorni alla volta, devi guardare avanti giorni alla volta e costruire il tuo backlog di cose a cui puoi passare al termine di ogni attività. Ovviamente, devi essere disposto a spostare le priorità di queste attività e aggiungere nuovi elementi prima che vengano completati tutti quelli vecchi.

Essere bloccati non è una buona cosa. Mentre apprezzo l'iniziativa di qualcuno che vuole imparare, migliorare il vecchio codice, aggiungere test e documentazione, generalmente mi aspetto che questi vengano usati per riempire piccoli ritardi inevitabili, del tipo che si verifica quando un'attività di 3 giorni risulta essere solo occorrono 2 ore, o il cliente improvvisamente dice "non importa se non lo vogliamo", oppure devi aspettare il parere di un esperto prima di poter programmare qualcosa. Non dovrebbero accadere tutto il tempo. Il fatto che siano suggerisce che qualcuno sta gestendo male il tuo tempo. Chiunque sia, puoi correggere tu stesso la situazione assicurandoti di chiedere abbastanza presto per il tuo prossimo compito.

Vorrei riformulare "posso correggere" con "potrebbe essere in grado di", perché ci sono momenti in cui non è il caso.Idealmente le persone dovrebbero sapere con 1 mese di anticipo su cosa lavoreranno, ma a volte non sai nemmeno quale sarà il tuo prossimo compito domani o se avrai le informazioni per farlo.
Non lo sapevo con un mese di anticipo da decenni, senza contare cose programmate come tenere un discorso in una conferenza.Ma non è quello che serve per gestire bene il tuo tempo.Ciò che è necessario per gestire bene il tuo tempo è lavorare sempre sulle cose più preziose, invece di lavorare su cose meno preziose solo perché sei bloccato e ieri non hai detto a nessuno che saresti stato bloccato oggi.
Sono d'accordo, è solo che le cose "più preziose" sono state spostate dallo sviluppatore al project manager.Al momento sono bloccato mentre avvisavo giorni prima (i clienti non fornivano elementi), quindi ora sono bloccato tra documentazione e miglioramenti.
Se ** sempre ** ci vogliono giorni per ottenere un compito sostitutivo, allora devi gestire il tuo tempo per affrontare quella realtà.Se ** occasionalmente ** ci vogliono giorni, allora non stai gestendo male il tuo tempo quando ciò accade.Tali eventi si verificano quando si aggiorna la documentazione o si guardano le registrazioni di quella conferenza che si è tenuta di recente o simili.Inoltre, dire a qualcuno una volta che sei bloccato e poi fare cose di scarso valore per giorni alla volta suggerisce agli altri che non ti dispiace essere bloccato.Assicurati di ricordare alle persone che hai bisogno di attività.
** ASAP ** è la risposta.La cosa è _quando_ si verifica "possibile".Qualcosa di simile _ non appena vedi che il problema sta arrivando_ potrebbe essere.
sh5164
2017-05-30 14:09:21 UTC
view on stackexchange narkive permalink

Non si tratta tanto di "l'ora corretta" che del modo corretto. Il vero problema qui è che non hai nulla da fare al lavoro, nessun incarico per ore o giorni.

Anche se il tuo capo ti dà "compiti e scadenze", un modo per risolvere il tuo problema lo farebbe essere quello di prendere l'iniziativa e svolgere le attività necessarie da soli, come la documentazione del codice o gli unit test.

In questo modo sarà più facile venire dal tuo capo e dire:

Quando ho terminato questo compito in anticipo, ho iniziato a fare test unitari

Invece di "Non ho niente da fare", che potrebbe venire come critica o mancanza di iniziativa.

E a proposito dell'ora corretta, potresti dirlo alla fine della giornata, come un briefing in modo che il tuo capo possa sapere cosa fai e tu puoi chiedere al famoso:

Cosa dovrei fare dopo?

Non sarai mai bloccato per più di un giorno e anche allora hai comunque lavorato su attività secondarie che avresti dovuto svolgere comunque.

Loïc Lopes
2017-05-30 20:48:28 UTC
view on stackexchange narkive permalink

Quando possibile, dovresti provare a dirglielo prima di aver finito. Puoi provare qualcosa del tipo "Penso che questa attività sarà completata in due ore, sai quale attività potrei iniziare dopo?".

Gli darà un po 'di tempo per riflettere su ciò che potresti fare e ti eviterà di essere inattivo.

Stavo per dirlo, ma con i giorni invece delle ore.
@PStag Sono d'accordo, dipende dalla lunghezza dell'attività corrente.
PStag
2017-05-31 01:13:58 UTC
view on stackexchange narkive permalink

Dovresti dirgli subito quello che stai facendo nel frattempo. In effetti, se sono compiti lunghi, glielo direi prima che il tuo compito sia completato.

Penso che avrò terminato l'attività (x) entro (data) e ho intenzione di dedicare il mio tempo ricerca (y) mentre aspetto una nuova attività.

Questo:

  • Gli fa sapere quando l'attività sarà completata con abbastanza tempo per pianificare la fase successiva.

  • Gli permette di darti un input sul tempo di studio, dandogli anche un suggerimento se è troppo impegnato per fare un piano.

  • gli dice la tua opinione su come pensi che le tue abilità debbano essere migliorate.

Forse va bene nell'industria del software, ma nell'esercito si dice: "Non dire mai al tuo comandante che non hai lavoro da fare".
-1
@TheLethalCoder o nel 21 ° secolo per quella materia.L'esercito è un pozzo di soldi, qualsiasi consiglio, specialmente sull'uso del tempo, è destinato a essere una sciocchezza assoluta.Ho letto "non essere mai aperto e onesto con il tuo anziano".Questo è totalmente tossico


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Continua a leggere su narkive:
Loading...