Come resistere quando i colleghi trascurano il processo?

Il problema che sto affrontando:

1. I membri del mio team iniziano a lavorare su progetti senza i documenti funzionali / tecnici pronti - anche se il nostro processo aziendale stabilisce che questi dovrebbero essere lì prima di iniziare.
2. I membri del mio team accettano soluzioni economiche e non strutturate e implementeranno hack davvero cattivi nel software senza pensarci due volte quando la gestione del progetto nota che hanno "un tempo limitato".
3. I membri del mio team iniziano a lavorare su progetti che collaborano con un progetto incompiuto di un altro team, che non è stato testato e non finito. (causando molto lavoro extra).
4. I miglioramenti e le intere fasi del software non sono pianificate correttamente e spesso si traducono in front-end / design non terminati quando lo sviluppatore back-end deve iniziare a lavorare.

Questi problemi sono stati discussi all'infinito per più volte da quando ho iniziato a lavorare qui. Tutti erano d'accordo e la linea di fondo è che abbiamo dobbiamo rispettare il processo, che significa lo sviluppatore di back-end non inizieranno fino a quando tutto è curato.

Questi problemi continuano ad accadere - e mi sto davvero de-motivando fino al punto in cui sono davvero infastidito dal lavoro stesso e da alcuni dei miei colleghi.

I membri del mio team si lamentano molto, ma solo l'uno verso l'altro. They keep on going - whatever the situation is. Il risultato?

1. Divento insicuro, forse sono io?
2. È così che dovrebbero andare le cose?

La mia domanda? How can I say no against work ignoring the process if everyone else seems to mindlessly accept?.

Cioè senza sembrare un fastidioso sviluppatore che è solo alla ricerca di qualcosa da lamentarsi continuamente.

Tutti erano davvero d'accordo?

Una volta ho avuto una situazione in cui volevamo migliorare i processi. Abbiamo proposto un processo diverso e tutti sembravano essere d'accordo.

Ma poi, ogni volta che volevo seguire questo processo, veniva chiamata un'eccezione, dovuta a "questioni più importanti", che sembrava sempre ragionevole a prima vista. Quindi, in effetti, il processo non è mai stato seguito di fatto, ma tutti hanno pensato "in linea di principio, stiamo seguendo il processo".

Il problema era: se proponi un miglioramento, non c'è nessuno che non sia d'accordo (a chi non piacciono i miglioramenti?). Ma se presenti i costi, di solito, c'è molto disaccordo. E perdere il modo conveniente di fare le cose è un costo enorme per la maggior parte delle persone.

Per dimostrarlo, ho formulato la domanda in modo diverso: "Per favore, dai la priorità a tutte le cose che dovrei fare (implementare funzionalità, rimuovere bug, seguire il processo migliorato, pulire la scrivania, arrivare in tempo)".

Dopo il processo è finito dietro la pulizia della scrivania e non essere in ritardo di 5 minuti. Quindi, sostanzialmente, hanno concordato qualcosa di completamente diverso da quello che ho proposto.

Il problema potrebbe essere che non vogliono pagare i costi per la qualità. Ciò può portarli a razionalizzare la tua critica come piagnucolio, ma nella mia esperienza non lo è. Il debito tecnico potrebbe non essere così visibile ed è facile attribuirlo alle circostanze, ma alla fine ne consegue la realtà.

Spero che fino a quel momento se ne siano resi conto, o hai cambiato lavoro.

Forse sei tu

Sembri favorire un modo molto strutturato e organizzato di codifica, i tuoi compagni di squadra sembrano avere un approccio più "fai cose". Ora dici che porta a un sacco di "tempo sprecato", quindi forse una certa struttura è in ordine e non ci sono scuse per il lavoro sciatto. Tuttavia, i progetti software tendono ad essere fluidi e l'applicazione di troppa struttura causerà anche un sacco di costi organizzativi.

Forse dovresti incontrarti tutti nel mezzo e provare un approccio più agile e interattivo, ma strutturato.

Chi è responsabile di queste persone? Qualcuno li ha assunti e qualcuno può licenziarli / ritenerli responsabili.

"La mia azienda richiede ..." non ha senso senza alcuna applicazione.

Non è possibile richiedere tempo che non consenta il processo di produzione.

Sembra che questa mancanza di controllo e aspettative non realistiche siano le ragioni della scarsa qualità.

Puoi: lasciare, diventare lo sviluppatore principale, non fare nulla o iniziare a lavorare con coloro che si sentono come te. Assicurati che tutti sappiano che seguirai le procedure corrette finché qualcuno non troverà un modo migliore e le cambierà. Sembra "Le regole della casa del sidro".

Sembra che tu non voglia che i tuoi colleghi seguano un processo completamente diverso, vuoi solo che prendano decisioni diverse in esso. Certo, ci sono delle regole (linee guida?) Su cosa dovrebbero fare e le ignorano. Ma il problema che descrivi è che devono prendere una decisione (per iniziare a lavorare sul progetto o rifiutare una specifica) e decidono di andare avanti. Tale decisione non cambierà se continui a ricordare loro le regole; a loro non importa tanto delle regole come te . Vogliono sentirsi utili e dire di no non li fa sentire utili .

Se vuoi che il loro comportamento cambi, allora ricordarli continuamente delle regole probabilmente non è molto efficace; è più probabile che li porti a ignorarti. Prova a trovare un modo per cambiare il processo per renderli più utili mentre continua a seguirlo. Riesci a implementare una sorta di revisione del codice, controllando il reciproco codice e imparando l'un l'altro per impedire agli hacker di passare al codice di produzione? Puoi cambiare il modo in cui le specifiche (docs / ext.interfaces / front-end) vengono gestite da una decisione in bianco e nero finita / non finita a un processo più cooperativo, dove verso la fine della specifica viene chiesto a uno sviluppatore aiuto finire? (E, si dovrebbe accettare il fatto che i requisiti saranno cambiare)

Principalmente non sei tu, non sono loro, è il processo. Se tu (e il tuo PM) riuscite a trovare un modo per organizzare cose in cui le persone non devono andare contro il loro personaggio così tanto, il processo sarà seguito molto più rapidamente.

Questo è il punto in cui farei il check-in con una sessione a porte chiuse con il mio team leader. Spero che tu abbia un rapporto di lavoro abbastanza buono con il protagonista da renderlo molto informale.

Lo scopo dell'incontro è capire perché il team sta facendo le cose nel modo in cui le sta facendo. Se tutti si sono riuniti, annuiscono, sorridono e concordano un nuovo processo, perché non cambiano ancora? È probabile che sia molto più profondo della semplice non cura o incompetenza. È probabile che al lavoro ci siano autisti che non sono visibili ad occhio nudo.

Inizia l'incontro supponendo che i tuoi colleghi, se potessero, seguano un processo che porta a meno panico, meno debito tecnico e maggiore qualità del prodotto - dopo tutto, chi non lo vuole? Quindi qual è la forza invisibile?

Sembra che ci sia molta implementazione / integrazione prima del lavoro iniziale di progettazione e prototipo dell'interfaccia utente. La società è a corto di persone che possono fare quel lavoro iniziale? Forse potresti fare volontariato. C'è un problema a ottenere il consenso con le parti interessate? Forse il tuo team può trovare un nuovo modo di comunicare con loro o può adottare un nuovo approccio alla documentazione delle ipotesi.

Se inizi con uno a uno in cui chiedi il tuo esempio perché puoi aprire la porta a una discussione che evita la difesa e si concentra su problemi e soluzioni.

Un altro trucco potrebbe essere quello di chiedere se si può sperimentare un nuovo modo di fare le cose. Il supporto del tuo team porta a forzare un po 'il problema e ti consente di adottare l'approccio che stai sostenendo: probabilmente si risolveranno i problemi quando si abbandona il "sistema", quindi si desidera la gestione dietro di te. Ma se risultate più produttivi e privi di stress, fornite un buon esempio per cambiare il modo di fare le cose e probabilmente vincerete sostenitori.