Domanda:
Come posso convincere il mio capo che lo sviluppo del software deve essere svolto in team?
Mintri
2019-12-05 15:38:04 UTC
view on stackexchange narkive permalink

Sono uno sviluppatore di software in un'azienda di 30 persone specializzata in tecnologia finanziaria. Ho iniziato a lavorare qui all'inizio di quest'anno. Nel tempo ho sentito che l'azienda ha triplicato i propri dipendenti negli ultimi 3 anni. L'organizzazione del lavoro può essere descritta al meglio come "mentalità di avviamento". C'è molta gestione del progetto del pavimento, improvvisamente si ottengono compiti in cucina e così via. Ogni sviluppatore fa ciò che deve essere fatto dopo, indipendentemente dalla forza, dai punti deboli o dall'esperienza. Ma la cosa più strana è che ogni sviluppatore lavora da solo su 1 progetto di sviluppo software completo, abbastanza complesso, che nessun altro sviluppatore può subentrare in caso di malattia. Inoltre, un progetto può andare avanti solo se è disponibile lo sviluppatore specifico del progetto. A seconda degli anni in cui uno sviluppatore ha lavorato in azienda, può succedere che 4 progetti necessitino di questa specifica risorsa per sviluppatori, se i clienti fanno richieste di modifica.

Ho imparato la gestione agile dei progetti in una grande azienda e Lo adoro. Ho imparato molto sulla gestione dei progetti da solo e ho avuto una piccola esperienza in questo, quindi nel mio colloquio di fine anno con il mio capo gli ho proposto, penso che dobbiamo iniziare a lavorare in team. Era scettico. Ho elaborato i numeri di fronte a lui, perché lavorare in team avvantaggia l'azienda e ha contato i diversi miglioramenti delle competenze trasversali, il lavoro di squadra nello sviluppo del software ti porta in cima.

Alla fine ha rifiutato tutto con l'espressione: tutto questo suona come mettere 2 uomini nella stessa posizione di lavoro, il che è antieconomico e la nostra piccola impresa non può permetterselo.

Ero così perplesso nel sentire la risposta di "2 uomini nella stessa posizione di lavoro" sulla difesa del lavoro di squadra, che ho semplicemente zittito.

Mi piace lavorare qui, ma odio come lavoriamo mentre vedo come potremmo essere molto migliori in tutto, se potessimo iniziare a organizzare chiaramente l'azienda e lavorare insieme e non solo in qualche modo lavorare dopo gli uni agli altri.

Come posso convincere il mio capo che il lavoro di squadra non è "due uomini nella stessa posizione di lavoro"?

Qual è la tua capacità nel ruolo?Sei un manager o uno degli sviluppatori che lavorano su un progetto da solo?
"mentalità da startup" è solo una nuova parola per non-organizzazione.Dover difendere la condivisione della conoscenza come fai tu non è neanche lontanamente vicino alla mentalità di una startup ...
@JayGould im uno degli sviluppatori.
@LaurentS.non sono riuscito a trovare una formulazione migliore :)
@JoeStrazzere beh eh ammette che vogliamo essere agili, ma in realtà è solo la gestione del caos.
Invece di concentrarti sul cambiamento del posto di lavoro, concentrati su ciò che puoi imparare.Una volta che senti che non stai più imparando o che la tua frustrazione è semplicemente insopportabile, vattene e trova un'azienda più strutturata.Problema risolto.
Sei risposte:
520 says Reinstate Monica
2019-12-05 16:39:48 UTC
view on stackexchange narkive permalink

Evidenzia il fattore bus

Una persona che lavora su un po 'di software significa che solo una persona conosce il funzionamento interno di quel po' di software. Cosa succede se quella persona viene investita da un autobus? Lascia l'azienda? Il licenziamento è efficace immediatamente? È malato? È incontattabile durante una crisi?

La vita accade e le ragioni per cui una singola persona non è più in grado di lavorare su progetti, temporaneamente o permanentemente, sono abbondanti e comuni. Avere almeno una seconda persona in quel lavoro è una buona polizza assicurativa contro le eventualità della vita moderna.

Guarda lo sviluppo di VKD3D, un livello di compatibilità da DirectX12 a Vulkan. Il fondatore del loro progetto e uno dei loro programmatori principali, Józef Kucia, che all'epoca aveva 30 anni, ha avuto un incidente mortale durante l'esplorazione di una grotta di neve (Jaskinia Wielka Śnieżna) sui monti Tatra (Polonia) all'inizio di quest'anno.

Se fosse stato il loro unico sviluppatore, l'intero progetto sarebbe stato fottuto; il progetto è troppo complesso perché qualcuno lo possa semplicemente raccogliere senza alcun tipo di documentazione, cosa che se sei l'unica persona che lavora sul lavoro, semplicemente non avrai tempo per farlo.

Ho sollevato quel punto.Ma il mio capo crede nella nostra esperienza.Bene, ho dimostrato che posso in qualche modo recuperare un progetto vecchio di 10 anni con un orribile codice legacy e quasi 0 documentazione.abbiamo 2 anziani che sono con l'azienda da oltre 10 anni, in totale l'azienda ha 13 anni.E senza che il mio capo fosse arrogante, ha sottolineato che in qualche modo funziona sempre nell'uno o nell'altro modo, e 13 anni di crescita e successo non possono essere tutti sbagliati.
Niente di tutto ciò avrà importanza in una crisi.Se hai bisogno di una soluzione critica e il tuo cliente ha bisogno che venga eseguita * adesso *, non puoi semplicemente assegnare alle persone un lavoro e aspettare che si mettano al passo. Potresti essere stato in grado di recuperare il ritardo con un progetto di 10 anni con codice scadente, ma potresti farlo in uno scenario di emergenza?Il problema della fortuna è che alla fine si esaurisce.Quando lo fa, hai bisogno di un piano B
Sono completamente d'accordo con te.Ho visto che i risultati di questa azienda derivano da 60 - 70 ore settimanali di lavoro del mio capo, una mano piena di sviluppatori locali e affidabili e molta fortuna, non è mai uscito nulla di serio.ma questo difficilmente può essere chiamato successo per metodo.mi sento come se fossi in una situazione in cui provo a dirlo a un bambino.non toccare il fuoco, bc fa caldo.Finché non ci sono incidenti a cui reagire.Sembra il tipo di persona fredda e analitica.E dire ai clienti che un progetto deve congelare un po 'di tempo, a causa di un incidente costa meno di 2 uomini nella stessa posizione di lavoro.
Bene, come il bambino che vuole toccare il fuoco, dovrà imparare a sue spese.Un giorno imparerà che in realtà la sua matematica costo / rendimento semplicemente non si somma;Non solo due sviluppatori possono coprire molto più terreno di uno, ma significa anche che un minor numero di bug entrano in produzione perché il tester non sta segnando i propri compiti ed è molto più probabile che tu abbia qualcuno in grado di rispondere in caso di crisi.Se nei prodotti viene rilevata una grande vulnerabilità di sicurezza, i client non accetteranno il "tempo di congelamento";smetteranno di usarlo e inseriranno nella lista nera l'azienda dai contratti futuri.
@520saysReinstateMonica Anche se sono pienamente d'accordo con la tua risposta, permettimi di correggere un dettaglio o due sul fattore bus ..
@iLuvLogix quali correzioni hai in mente?
vedi la mia modifica ..;)
@iLuvLogix Ahh lo vedo.Sì, è una buona aggiunta!Ho apportato una piccola modifica per chiarire che non stiamo parlando di due persone nella stessa squadra
@520saysReinstateMonica np, volevo solo correggere il fatto che non è stato ucciso - sfortunatamente è morto per i risultati di un incidente e che aveva 30 anni ..
@iLuvLogix ~~ potresti confonderlo per Jozef Kucias, che aveva 30 anni ma è morto un secolo fa.Lo sviluppatore di VKD3D aveva 28 ~~ - Non importa.Codeweavers ha aggiornato il proprio blog, ma gli articoli di notizie no.
@520saysReinstateMonica Per favore correggimi se sbaglio, ma non è morto nel [2019] (https://www.winehq.org/news/2019091101)?Se mi sbaglio, allora mi dispiace, colpa mia, ma pur sempre un triste ma vero esempio da utilizzare riguardo al fattore bus .. link a [codeweavers] (https://www.codeweavers.com/about/ blogs / jwhite / 2019/09/08 / a-tragic-loss)
@iLuvLogix hai ragione, Józef Kucia è morto nel 2019. È un esempio molto triste.
Daniel
2019-12-05 19:38:44 UTC
view on stackexchange narkive permalink

Non cambierai la cultura aziendale dall'oggi al domani!

Ammettiamolo:

  • sei 1 dei 30 dipendenti , molti di loro sono probabilmente abituati o addirittura apprezzano il modo in cui è fatto ora
  • Non sei in una posizione di potere (Manager ecc.)
  • Sei assunto per fare un lavoro diverso (Sviluppo)
  • Sei abbastanza nuovo per l'azienda

Quindi il peso della tua opinione è abbastanza piccolo. Chiediti questo: se non potessi cambiare questa parte, voglio continuare a lavorare qui. Se no, inizia a cercare un altro lavoro. Se ti piace ancora mantenere il lavoro, preparati per un lungo viaggio.

Puoi influenzare la cultura aziendale nel tempo ea poco a poco. Ma non li cambierai durante la notte e non otterrai mai il 100% di ciò che pensi dovrebbe essere fatto.

Ti suggerisco di fare piccoli passi per migliorare la collaborazione. Chatta con i tuoi college e guarda cosa stanno pensando. Forse puoi introdurre standard di codifica? Standup settimanali per avere almeno un'idea di cosa stanno facendo gli altri? Un wiki per problemi noti ... ecc. Piccole cose che non spaventano il tuo capo ma migliorano un po 'il lavoro di squadra.

Inoltre, se ci sono ostacoli e difficoltà che possono essere attribuiti a cattive pratiche di sviluppo puoi segnalare loro. Tuttavia, non giocare al gioco della colpa. Rimani sempre neutrale, pratico e suggerisci miglioramenti attuabili. A nessuno piace sentire un profeta del giorno del giudizio parlare di quanto sia brutto tutto.

Un giorno, qualcosa andrà davvero storto, specialmente se l'azienda continua a crescere in quel modo. Se ciò accade, si spera che tu abbia stabilito un approccio lungimirante e pieno di idee per il miglioramento. Resisti all'impulso di dire te l'avevo detto! Offri il tuo aiuto!

Se sei disposto a fare molti sforzi extra e molta pazienza con poche aspettative di rendimento, a volte puoi effettivamente spostare qualcosa. Ti suggerisco di leggere un po 'sull'argomento: "che conduce dal basso"

mai pensato a "guidare dal basso" sicuramente lo cercherò, grazie. Adesso lavoro in questa azienda da quasi un anno.Non ho notato tutto questo all'inizio, dato che c'era molto da fare il primo giorno, ma il mio cervello di sviluppatore non può smettere di provare e ottimizzare le cose. Ora è un po 'come un rompicapo per me sommare altre cose di cui non sono molto felice, ma poiché preferisco aggiustare le cose piuttosto che riacquistare ho fatto del mio meglio per risolvere la situazione.Ma mi ha condannato che questo introdurrà il mio addio in questa compagnia.Grazie per la magnifica risposta!
@Mintri Ti ho sentito parlare della "roba piuttosto aggiustata" ma sfortunatamente cambiare un'organizzazione può essere un compito piuttosto scoraggiante anche se accolto con favore dalla direzione.Ecco perché esiste un intero campo chiamato "gestione del cambiamento".Aspettatevi un sacco di lavoro e frustrazione e non molto grazie per questo.Se ci riesci, però, può anche essere molto gratificante e portarti avanti nella tua carriera.Ti auguro buona fortuna!
user180146
2019-12-05 15:52:03 UTC
view on stackexchange narkive permalink

Inoltre un progetto può andare avanti solo se è disponibile lo sviluppatore specifico del progetto. A seconda degli anni in cui uno sviluppatore ha lavorato in azienda, può succedere che 4 progetti necessitino di questa specifica risorsa per sviluppatori, se i clienti fanno richieste di modifica.

Trova esempi in cui questo è andato storto e daglieli. Sostieni anche che se uno sviluppatore lascia, tutta la conoscenza di quel particolare progetto software rimane nella configurazione corrente. Tutti costano denaro e forse allora vedrà i vantaggi.

Modificato dopo i commenti:
Ma alla fine, se il tuo capo arriva con argomenti irrazionali, non puoi convincerlo con quelli razionali . Potrebbe anche essere che abbia buone ragioni ma non può o semplicemente non vuole spiegarle. Alla fine è una sua decisione. Quindi preparati se la risposta rimane no.

Potrebbero esserci argomenti razionali che il capo non ha espresso o l'OP non ha citato.Ci sono valide ragioni per opporsi ad Agile e ragioni per cui è complessivamente più efficace che le persone lavorino su singoli progetti.Ovviamente ci sono degli svantaggi come accennato, ma lo sono anche gli svantaggi di qualsiasi suggerimento di OP.È una scelta in entrambi i casi, ed è quella del capo da fare, che a quanto pare ha già fatto un bel po 'di tempo fa.
@Battle Sono d'accordo che ci sono pro e contro per agile.Non volevo suggerire che rifiutare Agile sia di per sé irrazionale.ma dire: "2 uomini nella stessa posizione di lavoro" suona come una ragione irrazionale (o errore, l'inglese non è la mia lingua principale) per me.
Beh, matematicamente puoi vederlo in questo modo: 1 persona che lavora su un progetto, efficienza al 100%.2 persone che lavorano su un progetto: ciascuna 80% di efficienza.3 persone - 65%, ecc. Può diminuire dovendo adattarsi gli uni agli altri, la comunicazione, i problemi relativi al lavoro sul codice, ecc. Spesso una sfida è ridurre al minimo tale perdita con vari mezzi come la revisione del codice nel caso di molti sviluppatori,o semplicemente avere una corretta struttura di codice / progetto.Tutto ciò ha ancora un costo in un modo o nell'altro.Inoltre, che dire di una delle due persone che non è in grado di lavorare nel suo campo di competenza?
Ho sollevato quel punto.Ma il mio capo crede nella nostra esperienza.Bene, ho dimostrato che posso in qualche modo recuperare un progetto vecchio di 10 anni con un orribile codice legacy e quasi 0 documentazione.abbiamo 2 anziani che sono con l'azienda da oltre 10 anni, in totale l'azienda ha 13 anni.Capisco da dove viene la sua posizione.E senza che il mio capo fosse arrogante, ha sottolineato che in qualche modo funziona sempre nell'uno o nell'altro modo, e 13 anni di crescita e successo non possono essere tutti sbagliati. Ma solo perché non c'è stato ancora un incidente grave.
Non vedo questo lavoro di crescita selvaggia, anche perché sposteremo il nostro campo di attività dal servizio orientato allo sviluppo di prodotti software, ma forse vedo le cose troppo oscure.
@Battle Seguendo la tua logica: se uno di loro fosse malato, ad esempio: l'efficienza scenderebbe dal 100 allo 0% (nessuno a prendere il sopravvento) mentre in una squadra scenderebbe nel peggiore dei casi a una persona ancora all'80%."2 uomini nella stessa posizione di lavoro" è un'estrema semplificazione del lavoro di squadra.
Corretta.Questo è il compromesso.Ma di solito la maggior parte delle persone non si ammala per più del 5% delle volte che lavora e non tutti i compiti o progetti sono cruciali.Andarsene, tuttavia, lascerà una grossa ammaccatura, e questo è il vero rischio e compromesso.Ricorda inoltre, in un team non è sempre il caso che tutti conoscano ogni parte del codice, quindi se è necessario lavorare da quelle parti, l'aspetto "team" non aiuta molto, anche se stiamo ancora parlando di> 0% di efficienza.
@user180146 sono d'accordo con te, che è un'estrema semplificazione del lavoro di squadra, quindi cerco di trovare, un modo per fargli vedere, quel lavoro di squadra> lavoro da solista in ogni aspetto, imo.uno dei miei argomenti era: 3 team di uomini che lavorano su 2 progetti.quindi ci sono 120 ore lavorative -20 per la gestione del team, la sincronizzazione e altro.quindi sono 50 ore di lavoro svolto su ogni progetto in una settimana, con risorse trasferibili.Se uno si ammala, il team ha ancora 66 dipendenti ed entrambi i progetti completano 33 ore questa settimana.dopo questo mi ha chiesto perché sono uno sviluppatore e non un project manager ed è venuto con il 2 uomo nella stessa posizione di lavoro
Goose
2019-12-05 19:34:13 UTC
view on stackexchange narkive permalink

"... 2 uomini nella stessa posizione di lavoro ..."

Sembra che uno (o entrambi) stia assumendo "Agile uguale alla programmazione in coppia". Devi chiarirlo nella tua prossima conversazione sull'argomento.

La cosa principale che deve essere considerata è l'adattamento del modello operativo della tua azienda e l'implementazione Agile a cui stai pensando (XP, Scrum, ecc.). Ad esempio, se il tuo modello di business prevede l'offerta di X ore / dollari per il progetto per vincere un progetto del cliente, è meglio evitare la programmazione in coppia perché l'aumento della qualità del software e della condivisione / resilienza delle conoscenze ti farà fare offerte più alte dei tuoi concorrenti che non lo stanno facendo. Ciò lascerà la tua azienda in una spiacevole posizione economica.

Se il tuo gruppo, tuttavia, sta lavorando a un prodotto, qualcosa che vendi più e più volte, ho visto molti prodotti di successo costruiti utilizzando Tecniche di Scrum.

Per riassumere, per sostenere il lavoro di squadra, dovresti sostenere un approccio (ad esempio XP, Scrum) che si adatti al tuo modello di business / redditività economica. Avrai difficoltà a presentare un approccio che ignori l'ambiente in cui opererà.

dwizum
2019-12-05 23:01:27 UTC
view on stackexchange narkive permalink

Qualsiasi domanda che inizi con,

Come posso convincere persona X di ...

è difficile per rispondere, perché nessuno di noi sa veramente cosa motiva il tuo capo. Quindi, mentre possiamo fornire idee per argomenti specifici che puoi fare, non possiamo davvero capire se questi argomenti saranno effettivamente d'aiuto o meno. Come hai notato, alcuni capi rifiuteranno ciò che ti sembra un argomento sensato.

La buona notizia è che puoi seguire un processo per rispondere tu stesso a questa domanda. La chiave per convincere qualcuno di qualcosa è capire il suo punto di vista. L'errore che la maggior parte delle persone commette è cercare di sostenere il cambiamento in base alla propria prospettiva. Sebbene possa essere importante attuare un cambiamento che ti aiuterà personalmente, sarai molto più efficace se puoi inquadrarlo dal punto di vista dell'altra persona.

Se vuoi avere la possibilità migliore di convincere il tuo capo per apportare un cambiamento, fai un passo indietro rispetto ai tuoi argomenti attuali e procedi come segue:

  • Assicurati di comprendere la cultura della tua azienda. Se esiste una strategia, missione o altra struttura generale (ufficiale o non ufficiale), assicurati di comprenderla.
  • Osserva il tuo capo e rifletti su ciò che lo motiva. Sono in linea con gli obiettivi dell'azienda? Hanno motivazioni personali? Cose che gli interessano o di cui hanno paura?
  • Metti da parte i tuoi argomenti e le tue motivazioni.
  • Assicurati di poter articolare chiaramente il problema in questione e il cambiamento vuoi fare, in un modo che abbia senso dal punto di vista del tuo capo. Essere in grado di esporre il problema in un modo che abbia senso per loro e legare la tua soluzione ai loro motivatori.

Se il tuo capo è felice di ignorare il "fattore bus", probabilmente non vincerai litigando per il cambiamento a causa di singoli punti di fallimento. Tuttavia, forse il tuo capo è motivato dalla riduzione dei bug ticket, dai tempi di consegna delle riunioni, dalla produttività delle attività o da qualche altro fattore. Forse c'è anche una metrica misurabile a cui tengono! O, almeno, un fattore debole a cui puoi legare il tuo cambiamento.

Rendendo il più chiaro possibile il rapporto tra il tuo cambiamento e i loro obiettivi, avrai maggiori probabilità di ottenere ciò che desideri.

Manuel Rodriguez
2019-12-05 18:52:47 UTC
view on stackexchange narkive permalink

Il lavoro di squadra di solito non è voluto dall'azienda stessa ma è richiesto dall'esterno, ovvero dal cliente che acquista i prodotti. L'interfaccia con il mondo esterno si trova solitamente nel reparto marketing. Se l'obiettivo è introdurre il lavoro di squadra per lo sviluppo del software, questo equivale a lasciare che il reparto marketing controlli le decisioni tecnologiche.

Un buon punto di partenza è una richiesta del cliente che può essere soddisfatta solo se diversi dipartimenti uniscono le loro forze. Se uno sviluppatore non è motivato a lavorare in un team, può riferire direttamente al cliente e spiegargli perché il compito può essere risolto molto meglio da una sola persona.

Per introdurre il lavoro di squadra per un progetto di sviluppo software è importante sapere che non gli ingegneri a lungo termine devono decidere quale tipo di software è richiesto, ma il cliente. Parlare con il cliente, chiedere le sue esigenze e comunicarle nuovamente in azienda è un obbligo di gestione e si tradurrà in un'atmosfera collaborativa.



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