E alla fine, il mio supervisore convoca un incontro con me e lui. E alla fine della riunione, il mio supervisore mi chiede di eliminare tutte le modifiche, impostare la priorità e inviare un'email al mio collega invece che verbalmente.

È abbastanza tipico scrivere tutti i problemi che hai trovare durante una revisione, piuttosto che cercare di spiegare i tuoi punti verbalmente. Senza un elenco scritto, è troppo facile per tutti (tu incluso) dimenticarne alcuni, il che significa che potrebbero non essere corretti. Aiuta anche la comunicazione: l'autore può guardare indietro su ogni punto e venire da te se sono necessari chiarimenti. Infine, crea una traccia cartacea: se il tuo collega afferma che non gli hai mai parlato di qualche problema, avrai una chiara registrazione scritta che mostra che hai effettivamente trovato il problema e trasmetterlo.

Ma dubito o forse mi sento turbato dal motivo per cui ho bisogno di lavoro extra per fare il suo dovere. Quindi vorrei sapere che è solo un mio problema, o questo non è un problema comune e dovrei parlarne con il mio supervisore.

Annotare ogni problema che trovi fa parte di il processo di revisione e dovresti farlo in modo coerente. Non è davvero molto lavoro rispetto allo sforzo di rivedere effettivamente il prodotto di lavoro di qualcun altro.

Ci sono molti strumenti che possono rendere più facile rivedere il lavoro di qualcuno. Quale / i utilizzerai dipenderà dalla natura del lavoro e dagli strumenti che già utilizzi. Alcuni esempi:

• Github ha funzionalità che rendono facile vedere e commentare le modifiche relative a qualsiasi richiesta pull, quindi le tue note sono viste nel contesto e devi solo cercare attraverso il codice cercando di capire cosa è cambiato.

• La maggior parte dei software per l'ufficio (Microsoft Office, Google Docs e Pages / Numbers / Keynote di Apple) ti consente di allegare commenti a un documento, che inserisce nuovamente il tuo commento nel contesto.

Elencare le tue note in un documento o in un messaggio di posta elettronica le separa dall'oggetto in revisione, crea problemi di versione (come "Hai l'ultima copia delle mie note di revisione?") e rende difficile vedere la cronologia della recensione. Se il tuo lavoro prevede la revisione del lavoro di altre persone o la revisione del tuo lavoro, tu e i tuoi colleghi risparmierete molto tempo e fatica utilizzando strumenti che hanno lo scopo di facilitare il processo.

In 17 anni non ho mai ricevuto una revisione verbale del codice e se qualcuno ci provasse gli chiederei di inviarmi i commenti via email. Non ricorderò il commento n. 2 30 minuti dopo aver corretto il bug n. 1. È lo stesso motivo per cui utilizziamo un software di tracciamento dei bug.

Dovresti davvero considerare l'utilizzo di un software di revisione del codice. Ti consente di inviare recensioni, tenere traccia delle approvazioni e commentare per riga, mostrando a quali righe si applica il commento. Consente inoltre al revisore di rispondere (a volte il revisore aveva ragioni per dire che qualcosa è veramente giusto).

Ora, se hai un problema particolare che pensi sarebbe stato meglio spiegato faccia a faccia, va bene. Avere una discussione. Quindi documenta il risultato con il resto della revisione.

Per quanto riguarda il tuo lavoro extra, è una revisione del codice. In qualità di "membro senior del personale", rivedere il lavoro di altri fa parte del tuo lavoro. In una grande squadra, potrebbe essere la maggior parte del tuo lavoro. E in realtà non è un lavoro extra: a lungo termine risparmierai tempo perché questi non torneranno più tardi come bug.

Il tuo supervisore ti ha assegnato il compito di rivedere il lavoro di un collega, quindi fare tale revisione è tuo lavoro.

È anche del tutto ragionevole inviare i commenti alla revisione tramite e-mail anziché verbalmente, poiché aiuta solo tutte le persone coinvolte a verificare se tutti i commenti alla revisione sono stati risolti. Inoltre, se tu o il collega vieni trascinato in un'altra attività e / o questa attività viene sospesa, aiuta a evitare di ripetere il lavoro la prossima volta che viene ripreso.

Sconsiglio di portare questo dipende dal supervisore, e certamente non usando il tono "non è il mio lavoro" usato qui, specialmente se sei uno staff senior .

Dato che chiedi, in modo formale o revisione semi-formale, è più o meno normale che il revisore scriva i commenti della revisione e l'implementatore risponda ai commenti della revisione, spiegando come è stato risolto o perché non può essere risolto.

L'unico caso in cui l'implementatore prende nota dei commenti di revisione mentre il revisore dà la sua opinione è quando la "revisione" avviene per caso. Ad esempio, al revisore è capitato di guardare il codice mentre lavorava sul proprio compito e ha trovato qualcosa di "interessante" che deve essere modificato. In tal caso, il revisore potrebbe semplicemente chiamare e dire: "Ehi, ho trovato questa cosa in questo codice che potrebbe aver bisogno di qualche rielaborazione, ti dispiace dargli un'occhiata quando hai un po 'di tempo?"

"Mi sento sconvolto dal fatto che ho bisogno di fare del lavoro extra per un collega per fare il suo lavoro".

Questa sembra essere una grande mancanza di comprensione da parte tua di come funziona lo sviluppo del software. Ci sono diverse attività che devono essere svolte da persone diverse per produrre una nuova funzionalità: qualcuno deve raccogliere i requisiti. Qualcuno deve trasformarlo in una specifica verificabile (che dice allo sviluppatore cosa fare e una lista di controllo in modo che possiamo dire che la funzione è "completata"), poi c'è lo sviluppatore che scrive il codice, c'è il revisore che rivede il codice e il tester che verificherà che il codice funzioni nella vita reale. Ognuno di questi ruoli deve essere svolto correttamente per il successo, il che significa ad esempio che il raccoglitore di requisiti non si limita a raccogliere i requisiti, ma li scrive in modo che l'autore delle specifiche possa fare il suo lavoro, lo sviluppatore scrive codice leggibile per far lavorare i revisori più facile, il revisore fornisce le informazioni necessarie allo sviluppatore, il tester non si limita a testare, ma annota quali errori sono stati rilevati e dove riprodurli.

In qualità di revisore, il tuo compito è rivedere il codice e fornire tutte le informazioni necessarie allo sviluppatore in modo utilizzabile. Sì, scrivere quello che hai trovato è il tuo lavoro. Stai dicendo che sei sconvolto dal fatto che devi fare il tuo lavoro; è un pessimo atteggiamento da avere.

Lo sviluppo e la revisione del software vengono solitamente eseguiti dalle stesse persone. Quindi, se dovessi dare una revisione delle prestazioni, ti giudicherei dalla tua capacità di sviluppare un buon codice, ma anche dalla tua capacità di fare revisioni, sia di trovare problemi che di comunicarli alla persona che ha bisogno di risolverli. Quindi in questo momento, se insisti a farlo verbalmente, perché non vuoi lavorare per supportare qualcun altro, ti classificheresti piuttosto in basso per me.

Sono d'accordo sulla necessità di annotare le cose, per evitare ambiguità e creare un registro affidabile delle tue richieste di modifica. Ma questa è solo metà della storia. Per darti le migliori possibilità di feedback positivo su questioni complesse, devi discuterne anche tu. Ecco perché:

1. Il feedback funziona meglio come una cosa a doppio senso. (Spesso, questo non è possibile, ad esempio con il feedback online. Ma è in questo caso.) Potrebbe interpretare male ciò che scrivi, sia tecnicamente che prendendo personalmente il feedback. Discutere lo evita.

2. Se ti affidi esclusivamente al feedback scritto, puoi finire per annoiarti cercando di indovinare ogni possibile interpretazione e reazione a ciò che tu " stai scrivendo. Parlare lo evita.

Quindi una combinazione dei due può funzionare bene: crea un elenco di punti di revisione, quindi esaminali con lui. In questo modo, ottieni il meglio da entrambi i mondi.

Certo, questo è più lavoro. Ma prendere scorciatoie nella comunicazione di solito finisce per costarti più tempo alla fine.

Questo mi ricorda un post sul blog che un collega ha scritto sul nostro sito web per fornire un feedback scritto.

http://writing-skills.com/five-signs-time-pick-phone

Gli elementi 4 e 5 sono particolarmente rilevanti qui.