Ho avuto l'opportunità di lavorare con un project manager che aveva un approccio interessante alle controversie sulla proprietà del progetto: " Quando è il momento di chiamare i colpi, è meglio avere un capitano medio di due eccellenti. "

Sembra che la proprietà del progetto sia molto importante per il tuo collega. Perché non trattarlo come una risorsa invece che come una responsabilità?

Fai riconoscere al tuo collega il proprietario del progetto, con tutte le responsabilità che ne derivano. Avere un incontro sia con il tuo manager che con il tuo collega. Scegli qualcosa sulla falsariga di " sembra che al collega X qui piaccia davvero prendere la proprietà. Quindi, per semplificare le cose e offrire loro un'esperienza di proprietà adeguata [se necessario], lascia che si occupino di questo: io aiuterò loro insieme e rimandano alle loro decisioni su piattaforma, biblioteche, approcci e simili. Il prossimo progetto è mio, però. Affare? "

Aspetti positivi di questo approccio:

• Sarai considerato un giocatore di squadra che accetta l'entusiasmo degli altri compagni di squadra e dai loro la possibilità di mettersi alla prova, eliminando un fattore di stress;
• Essendo ufficialmente sul sedile posteriore, sarai scusato di difetti di progettazione (puoi suggerire approcci, ma la decisione finale non è tua);
• Il fatto che sia il manager che il collega accettano la tua proprietà per il prossimo progetto ti dà una solida base per utilizzare il " continuiamo con il mio approccio questa volta, ok? 'argomento quando è il tuo turno di definire le specifiche;
• L'implementazione di una soluzione sotto la visione del tuo collega dimostrerà ti ide con un punto di vista diverso su come affrontare le definizioni dei progetti.

Quando fa un suggerimento o una critica alla tua richiesta di pull, spiega una volta perché non lo cambierai per adattarlo al suo suggerimento. Dovrebbe essere semplice e chiaro. Ad esempio:

"Ciò non migliorerebbe in modo significativo il codice."

"Lo sforzo per apportare tale modifica non è giustificato dal suo valore."

"Il metodo corrente è più semplice."

Se si rifiuta ancora di accettare la richiesta pull, inoltra alla direzione. Puoi farlo tramite e-mail, ad esempio: "La richiesta pull X è stata aperta per Y tempo, ancora in attesa dell'approvazione di Z. Z non ha fornito alcuna motivazione sufficiente per rifiutare la richiesta pull."

Forza lui essere quello che ritarda e interferisce, poiché è quello che sta facendo. Fai notare che la sua insistenza su costanti modifiche al design o il suo rifiuto di approvare tempestivamente le richieste di pull solo perché non vengono eseguite nel modo che ritiene sia meglio sta sprecando il tuo tempo.

Tieni presente che andrai semplicemente alla direzione per decidere se il codice è accettabile così com'è e se la richiesta pull deve essere accettata o meno. O il tuo codice soddisfa gli standard applicabili oppure no. Se lo fa, dovrebbe essere accettato. In caso contrario, ha ragione e tu hai torto.

Richiamerei un manager e gli direi che le discussioni costanti stanno compromettendo l'efficienza. Questo è qualcosa che deve risolvere.

Se fossi stato io, proverei a dividere il progetto. Cercando di trovare un'interfaccia e dare a ciascuno la sua parte da gestire. Forse puoi suggerirlo.

Spesso, contestare uno dei suoi suggerimenti o proporne uno diverso è un'enorme battaglia in salita.

A volte questo è normale. In alcuni casi è davvero prezioso. Dovresti avere anche questo livello di fiducia. Se prendi una decisione, dovresti essere pronto a sostenerla, fino in fondo.

Questo sembra essere soddisfatto ogni volta che non voglio fare qualcosa esattamente nello stesso modo in cui lo farebbe lui, e di solito è un processo lungo e noioso.

Questo potrebbe essere un problema. Non può. A volte gli sviluppatori hanno difficoltà a ricordare "ci sono più di x modi per scuoiare un foo". Puoi provare ad affrontare questo problema con il tuo manager.

Per esempio, supponiamo che io scelga di usare una libreria per svolgere qualche compito. Dovrò giustificarglielo, il che va bene da solo, ma c'è una resistenza insolitamente alta anche se posso giustificarne l'utilizzo.

Questa è un'ottima cosa. Una cosa enorme buona. Quando gestisco un team ogni singola nuova libreria richiede una discussione ENORME. La persona che sostiene l'uso della biblioteca deve giustificarne l'utilizzo. Ci deve essere una seria giustificazione. Se costringerai tutti i membri del tuo team - e tutti quelli che entreranno a far parte del tuo team - a usare questa nuova dipendenza, è meglio che ne valga la pena. Quindi forse è un cattivo esempio. Ma durante le fasi di pianificazione è previsto un certo livello di "lotta per quello che vuoi". Se stai effettuando questi livelli di chiamate durante la fase di "codifica", allora, male per te. Questi avrebbero dovuto essere fatti, discussi, decisi, ecc. Molto prima che la prima riga di codice (per la nuova funzionalità) fosse scritta. L'aggiunta di una dipendenza al momento della codifica, per me, è un rifiuto automatico di una richiesta pull, seguita da una riunione. Quindi un tentativo per assicurarci la prossima volta di stabilire le dipendenze prima di iniziare a scrivere codice.

In generale, non mi sento come se avessi la mia autonomia nel processo decisionale, che ritengo debba essere concesso;

Non lo fai e va bene così. Non ci sono io in squadra. Ancora una volta, se si tratta di problemi a livello di implementazione, è necessario spiegarli. Se si tratta di problemi a livello di pianificazione, è tempo di essere pronti a difendere la tua strada.

invece mi sento come se fossi fondamentalmente solo il suo assistente.

Ora questo è un problema. È possibile che voi due dobbiate definire metriche migliori per una richiesta pull pass / fail. In quali condizioni è un abbonamento? In quali condizioni si verifica un errore? Se fallisce, vengono forniti elementi utilizzabili?

Una regola che uso sempre è che se qualcuno fallisce una richiesta pull, deve fornire elementi utilizzabili per rendere la richiesta passabile.

Fallito: i test non vengono superati, correggi il codice in modo che i test passinoFail: il codice è troppo complesso, riduci la complessità a livelli accettabili
Fallito: la logica appartiene al modello, non il controller lo sposta nel modello .
Fallito: non usare iteratori come x, usa nomi di variabili reali, in questo caso chiamalo "per voce nelle voci" non "per e nelle voci"

Allora almeno guardando il messaggio di errore hai un posto dove iniziare una conversazione.

Il mio manager ha detto che gli va bene fare da mediatori, ma è incredibilmente meschino da parte mia.

Il lavoro del manager è gestire; LASCIATELI . Se il tuo manager si stanca di gestire queste richieste, le farà smettere. Il tuo manager potrebbe benissimo preferire questo livello di supervisione.

Per esempio, supponiamo che io scelga di usare una libreria per eseguire qualche operazione. Dovrò giustificarglielo, il che va bene da solo, ma c'è una resistenza insolitamente alta anche se posso giustificarne l'uso. In generale, non mi sento come se avessi una mia autonomia decisionale , che ritengo debba essere garantita; invece mi sento come se fossi fondamentalmente solo il suo assistente.

In un team / azienda, non hai la tua autonomia nel processo decisionale; almeno non per decisioni di alto livello come scegliere una nuova tecnologia, una nuova libreria, decidere sull'architettura, ...

Quando si lavora a un progetto in un team, è necessario sostituibile . Potresti ammalarti / essere investito da un autobus in qualsiasi momento e un altro collega dovrebbe essere in grado di farsi avanti e continuare da dove eri.

Maggiore è la familiarità che ha detto collega con il tuo lavoro, meglio ecco perché è importante che:

• utilizzi le stesse librerie di terze parti di chiunque altro in azienda,
• strutturi il tuo progetto come qualsiasi altro progetto nella azienda,
• ...

Ovviamente c'è spazio per l'esplorazione. Una nuova libreria di terze parti, una nuova struttura, ecc ... possono migliorare lo statu quo, ma sono dirompenti e quindi i loro benefici dovrebbero in gran parte compensare i loro costi. Questa deve essere una decisione consapevole da parte del dipartimento / divisione / azienda . Non è tuo farlo, anche se puoi difenderlo.

Dobbiamo approvare le reciproche richieste, quindi, se faccio qualcosa che non gli piace, ha la possibilità di rifiutarlo completamente fino a quando non lo modifico per soddisfare i suoi suggerimenti. Se devo portare a termine quella funzione, devo mantenere la mia posizione e passare molto tempo a giustificarla, oppure devo semplicemente cambiarla in ciò che suggerisce e andare avanti con la mia vita. un po 'una roccia e un luogo difficile

Se posso, penso che qui ci sia un problema con il metodo di lavoro.

La progettazione di alto livello dovrebbe essere discussa prima di iniziare il lavoro; è solo una perdita di tempo lavorare per una settimana su qualcosa, presentarlo per approvazione e farlo rifiutare con il motivo "Aspetta, hai considerato l'interazione con X? Non funzionerà mai!".

Ciò significa che prima di iniziare il lavoro, è necessario concordare come una squadra una direzione generale. E se succede qualcosa a metà strada che richiede un cambiamento drastico, devi concordare come un team dove andare da qui.

Nota: ho visto persone discutere per l'approvazione delle loro PR perché ha lavorato molto, nonostante le obiezioni alla sua qualità o al design. Fa male vedere i tuoi sforzi rifiutati ... ecco perché è meglio discutere le cose in anticipo.

Quindi, supponendo che:

• tu avere l'approvazione della direzione per le tecnologie, le librerie di terze parti e la progettazione del progetto,
• hai concordato in anticipo la direzione generale della richiesta di pull.

Poi la discussione sul la stessa richiesta pull dovrebbe essere incentrata su:

• lucidare i casi limite,
• ripulire l'implementazione,
• chiarire i bit oscuri.

Una volta su una luna blu, potresti ricevere un commento del tipo "Oh merda, ci siamo dimenticati di spiegare il caso X". Succede. È un errore di squadra.

Questo, ovviamente, non risolve magicamente il tuo problema di proprietà. Il tuo collega potrebbe essere ancora intrattabile durante la discussione iniziale sulla direzione generale della richiesta di pull.

In generale, se uno ha "proprietà" o meno non ha importanza, vuoi il consenso .

Il tuo primo obiettivo dovrebbe quindi essere capire perché il tuo collega è difficile:

• ha una visione diversa?
• è è un idealista?
• è un maniaco del controllo?
• non si fida delle tue capacità?
• ...

e cerca di risolvere il problema con lui.

Devi allinearti alla visione di alto livello per il progetto, guadagnare la sua fiducia riguardo alle tue capacità, ...

Se tutto il resto fallisce, come ultima risorsa ¹ , potresti coinvolgere il tuo manager e fargli dividere le responsabilità. Hai menzionato te e lui aveva diversi set di abilità, quindi dovresti essere in grado di suddividere le responsabilità in 3 aree: la sua area, la tua area e un'area comune. Nella tua zona, la sua opinione sarebbe puramente informativa (e viceversa).

¹ E intendo infine, il confronto inasprisce le persone.

C'è un modo migliore per gestirlo?

Mi chiedo se pensi che ogni decisione sia binaria:

1. Giusto / corretto (cioè a modo mio)
2. Sbagliato (cioè a modo tuo, non a modo mio, non l'avrei fatto così)

Penso che sia importante classificare le decisioni in almeno tre segmenti anziché due:

1. Gradevole (siamo entrambi d'accordo sul fatto che questo sia positivo)
2. Sgradevole o inaccettabile (c'è un danno oggettivo e identificabile associato a una proposta)
3. Abbastanza buono o accettabile (ad esempio, non l'avrei fatto nel modo in cui mi hai suggerito, ma quello che stai suggerendo è abbastanza buono, immediatamente adeguato e meglio di niente)

Una delle mie esperienze di revisione del codice è stata quando ero il gatekeeper formale (ovvero il leader del team o il proprietario del prodotto) e ricordo che il mio feedback sulla revisione del codice aveva tre categorie:

1. Va bene, pronto per il check-in
2. Non è ancora del tutto pronto, devi cambiarlo (ti chiedo u per modificarlo) prima del check-in
3. Vedo cosa hai fatto, funziona; Cordiali saluti, non l'avrei fatto in questo modo, l'avrei fatto in un altro modo; puoi cambiarlo (prima del check-in, per farlo come ti ho suggerito) se vuoi, ma non devi.

Avere quella terza categoria è quasi necessario se si desidera un aiuto autonomo.

Nota che se è "un danno oggettivo e identificabile associato a una proposta", allora entrambi dovreste essere in grado di vedere e concordare che il danno esiste. Se c'è ancora qualche disaccordo, forse si tratta di un compromesso e forse questo è un argomento che potresti portare al responsabile del prodotto (ad es. "Capo, dovremmo usare e dipendere da un componente di terze parti o adotta più criteri Non inventato qui? ").

In alternativa, c'è un altro sviluppatore di software nelle vicinanze? Lavoravo con un piccolo team di colleghi esperti. Parlavamo uno a uno per discutere e decidere le nostre interfacce. Nella rara situazione in cui due persone non potevano o non erano d'accordo su qualcosa, avremmo coinvolto nella discussione un altro sviluppatore (cioè un terzo) (per trovare un consenso o una decisione a maggioranza).