un approccio migliore per la revisione delle prestazioni degli sviluppatori?

Ovviamente ci sono altri modi per misurare le prestazioni. Sfortunatamente (a meno che non mi sia sfuggito qualcosa nel tuo post), non sei in grado di dettare il criterio dell'ufficio (per quanto arcaico possa sembrare).

Il tuo lavoro (se vuoi avere successo lì e migliorare la tua carriera), è quello di soddisfare e superare quelle aspettative. Chiedi al tuo manager una spiegazione di come quantifica questo criterio. Devi capire e allinearti con le loro aspettative.

Solo se non hanno metodi per quantificare queste cose (e sospetto che non possano produrre una lista per alcune di quelle cose sulla loro lista), forse hanno la conversazione su come possono aspettarsi che qualcuno sia in grado di eccellere in azienda se non c'è modo di collegare tangibili a ciascun elemento nell'elenco. IMHO, questo è il modo politicamente corretto di dire alla direzione del tuo ufficio che sono pazzi senza dirglielo: facendo loro capire che i loro criteri sono un po 'fuori luogo.

Se ritieni che qualcosa sia vago, chiedi chiarimenti alle persone che impongono questi criteri a te, non ai randoms su Internet.

Sono un capo progetto in un'azienda di medie dimensioni in Svizzera (circa 2000 persone). Nella mia squadra cerco sempre di evitare di essere troppo severo riguardo al tempo dell'ufficio.
Organizzo anche un evento sociale settimanale per conoscere i miei colleghi anche sotto una prospettiva personale.

Tuttavia ogni settimana o 2 settimane stabilisco una pietra miliare che deve essere raggiunta da ogni sviluppatore. In questo modo posso vedere chiaramente se quella persona è produttiva o meno. Lascio a chiunque la libertà di andare e venire dall'ufficio quando gli piace, ma tutti sanno che deve consegnare prima della scadenza.

Ho scoperto che questo approccio ripaga in termini di dedizione e partecipazione, dal momento che le persone non si sentono "controllate", ma sono più rilassate al lavoro. Ciò consente loro di essere sempre in grado di portare a termine i propri compiti, poiché ognuno trova il proprio "stile" di lavoro migliore. Finalmente anche il lavoro di squadra è eccellente, grazie ai nostri eventi social.

Il punto di recensione finale è fa le cose , ma è ancora più vago di quelli presentati.

I punti preimpostati potrebbero essere un tentativo di rompere le cose fatte in componenti più facili da misurare.

Ma il problema con questi punti è (ad eccezione di presenza , che è semplicemente stupido) è che sono di nuovo difficili da misurare e facili da sbagliare.

Ad esempio, Condivisione di idee : ecco i miei 100 messaggi con suggerimenti per il miglioramento dell'azienda. Significa che fornisco un input prezioso, o ho appena realizzato che è molto più facile suggerire cose che altre persone dovrebbero fare piuttosto che farlo da solo?

Oppure, il sempreverde, Lavoro di squadra . Come vuoi misurarlo? "Non si presenta con un'ascia per uccidere i colleghi"? Ogni metodo che coinvolge il resto della squadra si degrada rapidamente in un festino di gruppo, imho. A nessuno piace il collega che afferma gli standard bassi di una squadra, a prescindere da quanto bene lo presenta.

Penso che, per migliorare la situazione, anziché cercare di migliorare i rapporti, si dovrebbe scoprire, cosa cercano di gestire con le informazioni che sperano di ottenere dai rapporti e migliorare che . Il tentativo di ottenere una "grande immagine" e poi prendere una decisione sulla gestione del suono su singoli sviluppatori non è riuscito a fare in modo che io abbia qualche speranza che possa essere fatto bene.

Output

Questa è l'unica misura di rendimento a cui riesco a pensare. Vieni a lavorare fino a tardi, bevi vino, dormi al lavoro, qualunque cosa tu faccia, voglio solo che tu scriva quella caratteristica in 2 giorni. Questo è quello che voglio, se sono un manager.

Tuttavia, ci sono altre cose (cose burocratiche) che devono essere affrontate in molte aziende. Mentre sono importanti, non dovrebbero essere considerati un indicatore della performance dello sviluppatore . Piuttosto, possono essere applicati come indicatori della fedeltà dello sviluppatore o della qualifica dello sviluppatore , o cose del genere.

Tra i tuoi articoli, IMHO, Pianificazione del progetto , Lavoro di squadra e Risoluzione dei problemi sono indicatori che un buon sviluppatore dovrebbe avere.

Come sviluppatore mi risolvo solo un obiettivo, qualunque cosa il mio capo si aspetti da me, e questo obiettivo è la soddisfazione del cliente.

Oltre alla tua lista, vorrei sottolineare il completamento del lavoro assegnato, una comunicazione positiva ed efficace all'interno e all'esterno della squadra e un bonus per i suggerimenti positivi e per aiutare gli altri. L'atteggiamento è importante. Mentre l'atteggiamento positivo è difficile da misurare, l'atteggiamento negativo può essere facilmente individuato ed è dannoso per la squadra.

Beh, devo ammettere innanzitutto che questo sistema della tua azienda è davvero un bore !!

Sebbene alcuni punti possano essere mantenuti ... alcuni devono essere rimossi perché sono troppo vecchi

• Disciplina
• frequenza
• Dedizione

Penso che i punti precedenti possano essere rimossi ciechi piegati !!!

Un vero programmatore appassionato può essere identificato ad occhio nudo a chiunque capisca un po 'di programmazione! Questi ragazzi potrebbero ottenere il punteggio più basso nel sistema di marcatura sopra descritto che hai ...

Con un programmatore devi guardarlo

L'approccio verso il lavoro è un aspetto molto necessario per un programmatore, potrebbe prendere un progetto con occhi diversi e nella maggior parte dei casi questo primo sguardo e approccio determineranno il futuro del progetto. Queste cose possono essere molto ben identificate nella riunione e nelle discussioni del team ...

Lavoro di gruppo (presente nel tuo elenco)

Condivisione di idee è di vitale importanza, se fatto nel modo giusto penso che sarebbe sempre di aiuto e se non lo fosse, il progresso della società ...

Problem Solving anche se a volte può essere uno sforzo di squadra ma non puoi spingerlo via perché a volte la brillantezza individuale in una squadra può fare miracoli

Un'altra cosa che devi vedere è l'efficienza del programmatore nel suo lavoro .... un loop può essere eseguito in modi diversi ma il LOC più efficiente dovrebbe essere applaudito