Ferma questa follia prima che inizi.

Quando il tuo capo ha un problema urgente che deve essere affrontato "da tutti", convoca una riunione.

Discuti il ​​problema in modo razionale, allenati cosa è necessario fare, elabora le risorse necessarie per realizzarlo e metti in atto il piano.

Smetti di essere preso dal panico, inizia a pianificare. Fallo nel modo giusto, con il giusto numero di persone.

Sentiti libero di includere il tuo capo nella riunione e dimostra che "tutte le mani sul ponte" non è sempre appropriato: hai bisogno di "il mani giuste sul ponte ".

Finisci quindi con un team unito che lavora sul problema nel modo più ottimale / efficiente. Chiunque non abbia bisogno di lavorare su un'attività che è già dotata di risorse complete (ed efficienti) può lavorare su qualcos'altro (idealmente preparandosi per un'attività successiva (o shock / orrore, creazione / completamento di un piano di test)). In ogni caso, se il capo atterra sulla scrivania di qualcuno e chiede perché non stanno martellando febbrilmente il codice in Visual Studio, avranno la risposta appropriata.

A volte, potresti aver bisogno che tutti lavorino su un problema , ma poiché hai pianificato le cose, tutti sanno cosa stanno facendo, perché e quando.

Quando il panico è passato e il problema è risolto, prova a capire cosa è successo che ha causato il panico situazione in primo luogo e mettere in atto un processo per mitigare i panici futuri. È probabile che tu scopra la causa principale durante le tue indagini iniziali, ma un processo post mortem dimostra un approccio proattivo per evitare i problemi.

Come regola generale, i proprietari non cambiano. Se le cose buone del lavoro non compensano questo, allora devi andartene.

Se rimani, un approccio che ha funzionato per me con un tale proprietario è ignorarlo. Fai quello che pensi sia meglio. Funziona solo se sai davvero cosa è meglio e puoi mostrargli i risultati più velocemente di quanto lui possa scoprire cosa stai facendo e arrabbiarsi. Funziona particolarmente bene per i proprietari con tempi di attenzione brevi. Questo non funziona bene quando il proprietario conosce i dettagli di ciò su cui stai lavorando tutto il tempo perché non hai il tempo di arrivare a un risultato che puoi mostrare.

Se esci , inventati una bella bugia bianca sul motivo per cui te ne vai. Sarà ancora meno ricettivo a ciò che devi dirgli quando smetti.

Sostienilo. Ed essere visto che lo fa.

Non parlarne mai in pubblico e non farti vedere per non farlo.

Sembra che il tuo capo abbia paura. Quindi rendilo senza paura.

Sono uno sviluppatore da oltre 20 anni. Sono stato manager di team grandi e piccoli (e intermedi). Ho investito i miei soldi in progetti e posso raccontare la sensazione. Funziona così.

• Sono impegnato e (forse anche) quasi al verde e sono stressato a morte
• Non so esattamente cosa la mia squadra fa per me, se se ne vanno sono pieno
• Ho clienti / utenti che dicono cose e devo parlare di tori ** t in piedi e lo odio
• Il mio team si sente come se mi stesse sfuggendo

MODIFICA: inclusa la citazione di un commento OP ausiliario

  La maggior parte recentemente è stato perché ha affermato che un menu in un sistema che abbiamo riscritto mancava di tutte le opzioni che il sistema originale aveva. Non ho avuto nulla a che fare con lo sviluppo del menu, ma i due sviluppatori che hanno insistito sul fatto che non è vero. E il proprietario, per quanto ne so, non è ancora riuscito a fornirci un esempio di un elemento che manca da questo nuovo menu. Ha semplicemente detto "le voci di menu mancano".  

ES: il menu da cui sono scomparse le cose. È del tutto possibile che il menu SIA CORRETTO dal punto di vista degli sviluppatori "tecnicamente" utilizzabile ma è ANCHE del tutto possibile che molti utenti abbiano frainteso e odiato il motivo per cui una caratteristica intuitiva DAVVERO UTILE del menu dell'interfaccia utente originale è stata eliminata. È successo con Windows8. Può succedere a te. touchscreen / tastiera (ad esempio: saltare oltre con il tasto [pressioni, espansione automatica, mostrare chiaramente dove può avvenire l'espansione automatica) molto spesso gli sviluppatori hanno tanta fretta di ottenere un "aspetto" o una "funzionalità" che dimenticano che queste cose vengono utilizzate dagli esseri umani.

e non pensare che questo genere di cose di cui parlo sia banale per gli utenti. molto spesso odiano le "nuove funzionalità" che interrompono una cosa su cui facevano affidamento.

Il modo per evitare che il tuo capo sia sempre in preda al panico è ridargli fiducia. Sostienilo in ogni caso. Non tenete riunioni che supplichino la sua autorità. Parla bene di lui. Lascia che sbagli le cose, fagli sapere uno a uno. Sostienilo comunque. fagli sentire che hai la schiena e digli che lavoro fa bene. Penso che sia positivo che tu sia venuto online per parlare di queste cose, perché farlo in un ufficio può essere la cosa peggiore da fare.

Dico tutto questo perché, alla fine, sei l'unica cosa che puoi controllare . E se segui il mio consiglio (e lo pratichi!) Il peggio che può accadere è che diventi un dipendente così incredibile che sarai inimmaginabilmente prezioso per tutta la tua carriera . il meglio che ti può capitare è che cambi idea del tuo capo riguardo al panico.

Il mio suggerimento è un po 'diverso da quello di Snow: incontra il proprietario 1: 1 nel momento in cui non c'è crisi. Uscire per un pranzo o un caffè con lui può essere una buona idea. Quindi, digli più o meno quello che hai scritto qui e cerca di renderlo il più non personale e non accusatorio possibile: fai capire al proprietario che le chiamate "a tutte le mani" fanno male agli affari.

Si spera, il proprietario è una persona ragionevole e capirà il tuo punto. Altrimenti, è il momento di cercare un altro lavoro.

La risposta breve a questa domanda è che hai bisogno di una sorta di funzione di gestione dei prodotti più formale nel tuo negozio.

Lo scopo principale di questa funzione è definire, comprendere e mantenere un backlog di lavoro prioritario per il team di esecuzione. Ciò consente al team di esecuzione di rivedere continuamente il lavoro di fronte a loro e di prendere buone decisioni in generale su come gestire le cose, chi e quante persone mettere in una determinata area di lavoro e altri aspetti per mantenere una produzione stabile senza troppi contesti interruttori e simili.

In secondo luogo, è utile avere qualcuno in un ruolo di tipo project management che faccia le cose sopra per il team di esecuzione. Idealmente non è la stessa persona che fa la parte di gestione del prodotto, in modo da poter separare i conflitti di interesse tra l'urgenza percepita e l'efficienza del team a lungo termine.

In una piccola azienda, questi non devono essere persone dedicate in ogni ruolo. Ciò che serve è una chiara comprensione di chi fornisce cosa al flusso e quando. Ad esempio, il tuo capo in questo caso suona come il chiaro proprietario del prodotto e sarebbe a capo della funzione di gestione del prodotto. Che faccia la maggior parte del lavoro da solo o deleghi il lavoro sui dettagli e fornisca solo supervisione e assegnazione delle priorità, è qualcosa che tutti voi dovreste risolvere in base alla vostra situazione unica come azienda. Un'altra persona, tipicamente uno degli sviluppatori più senior e / o più organizzati, può assumere il ruolo di project manager. Quella persona trascorre parte del proprio tempo occupandosi del lavoro in arrivo e assicurandosi che sia adeguatamente allocato, che non ne derivi il thrashing e che ci sia comunicazione con la funzione Prodotto su quali siano gli impatti sui costi di un'eccessiva ridefinizione delle priorità. / p>

Ho cercato di affermare queste cose nel modo più generico possibile senza specificare una metodologia. Ovviamente ci sono gusti di Agile, il buon vecchio stile Waterfall e una sfilza di approcci meno conosciuti per darti linee guida vere e provate su come lavorare all'interno di uno di questi. Da quello che hai descritto, con frequenti cambi di direzione urgenti ea breve termine, passare a una versione semplice di Scrum sarebbe un buon punto di partenza. Da lì puoi valutare quanto bene sta funzionando ed evolverlo per soddisfare le esigenze della tua azienda. Se non hai nessuno a bordo con almeno una certa esperienza in Scrum per agire come coach, allora questo è un problema separato che probabilmente ha già molte buone domande e risposte qui intorno.

Se non c'è una struttura di comando tra te e il proprietario, ce n'è davvero bisogno.

Hai bisogno di qualcuno che gestisca gli sviluppatori, e questa è la persona con cui il proprietario dovrebbe parlare. È compito di questo manager quindi dividere il lavoro e risolvere il problema.

Non è nemmeno necessario essere una persona nuova. Sono un manager, ma anche uno sviluppatore attivo nel team. Il lavoro viene da me, lo divido e coordino lo sforzo. Poiché sto anche lavorando attivamente ai progetti, ne comprendo la portata e le problematiche, consentendo a tutti coloro che non sono necessari di continuare con le loro cose BAU.

il mitico problema del mese dell'uomo riguarda l'aggiunta di persone a un team esistente quando il tempo è già stretto. invece di accelerare le cose, dedichi tempo ad aggiornare le nuove persone e in generale ad aumentare il sovraccarico di comunicazione.

questo non si applica qui. sei già una squadra e la composizione della squadra non cambia. stai solo affrontando un nuovo problema / compito per la stessa squadra.

ciò che chiede il tuo capo assomiglia molto alla programmazione mob.

https: // en.wikipedia.org/wiki/Mob_programming

altri team hanno trovato un modo per essere produttivi con questo metodo, quindi invece di provare a cambiarlo, approfitterei della situazione e trova un modo per ottenere il massimo

Far lavorare gli sviluppatori su attività e codice con cui non hanno familiarità è estremamente inefficiente. Convincere gli sviluppatori a cambiare attività è estremamente inefficiente a causa del riadattamento mentale necessario che di solito non viene considerato in questo tipo di condizioni.

Come puoi convincere il tuo capo a capirlo? Dipende dal tuo rapporto con il tuo capo e dal tipo di capo che sono. Il tuo capo ha dimostrato la volontà di ascoltare gli sviluppatori in passato? Sei in regola con il tuo capo? Sei rispettato dal tuo capo? Il tuo capo è relativamente privo di stress? Meno di queste risposte "sì", più difficile sarà apportare qualsiasi tipo di cambiamento positivo.

Nel mio ultimo lavoro, la mattina di un giorno particolare, ci è stato detto che il numero di I biglietti di aiuto erano troppo alti e che ognuno di noi doveva chiudere le 8 entro la fine della giornata. Ognuno di noi ha lottato e abbiamo calcolato una media di 3 biglietti chiusi ciascuno, il che con il senno di poi è stato uno sforzo incredibile, ma non è stato apprezzato. Tuttavia, non posso parlare della qualità delle soluzioni messe in atto per questi problemi.

Fondamentalmente quello che è successo nella tua situazione e nella mia è il capo in preda al panico e ha cercato di risolvere un problema lanciando di più risorse a esso. Sì, sarebbe fantastico se tutti i nostri capi leggessero, capissero e fossero d'accordo con The Mythical Man-Month. Tuttavia, nel mio caso sapevo che questo non sarebbe mai successo. Spero che la tua situazione sia migliore della mia.

L'unica possibilità che mi viene in mente è fare un'autopsia in uno di questi momenti. È andata come si aspettava il tuo capo? È stato un bene per l'azienda o ha solo sprecato un sacco di tempo e denaro? Quali lezioni si possono trarre? (qui puoi guidare sottilmente il pensiero del tuo capo in modo che raggiunga le stesse conclusioni di The Mythical Man-Month senza leggerlo.) Ad esempio

• Abbiamo provato a lavorare sull'attività A, ma solo Alice sa come funziona, quindi ha dovuto passare metà della giornata a spiegarlo a tutto il team. Abbiamo effettivamente sprecato 2,5 giorni lavorativi come team (lo stesso che avere uno sviluppatore in malattia per 2,5 giorni). Cosa pensi che dovremmo fare la prossima volta?
• Abbiamo trovato davvero difficile coordinarci dato che avevamo così tante persone che lavoravano allo stesso compito contemporaneamente (fornisci una stima del tempo medio sprecato per individuo membro del team, quindi moltiplicalo per la dimensione del team). Cosa pensi che dovremmo fare la prossima volta?
• La mia scadenza per il compito importante B è stata anticipata di un giorno e mezzo perché ho trascorso una giornata sull'attività A e mi ci è voluta mezza giornata per tornare al flusso del compito importante B (fornire solo cifre veritiere). Non sono più sicuro di poterlo completare in tempo. Cosa pensi che dovremmo fare la prossima volta?
• Due sviluppatori non sono stati in grado di contribuire affatto perché non hanno abbastanza esperienza con la tecnologia C. Il team ha sprecato 2 giorni lavorativi per non averli compito A. Cosa pensi che dovremmo fare la prossima volta?

La cosa fantastica di questo approccio è che stai comunicando chiaramente i tuoi problemi, senza sembrare che tu stia dicendo al tuo capo cosa fare . Ripone la responsabilità su di loro, perché non è mai stato tuo in primo luogo ! Si spera che inizieranno a rendersi conto del danno fatto e di come sta influenzando la linea di fondo. In (quasi) tutte le discussioni d'affari, il denaro vince! Se escogitano un'idea in modo indipendente, è più probabile che la implementino, indipendentemente dal fatto che esattamente la stessa idea si trovi in ​​un libro di 30 o 40 anni.

Se sei davvero, davvero, fortunato, dopo che questo è andato bene un paio di volte puoi dire: "Ehi capo! Indovina cosa? Ho trovato questo libro che concorda con i cambiamenti che hai messo in atto e suggerisce ancora di più sulla stessa linea! " Forse lo leggeranno, ma i capi sono generalmente persone impegnate, quindi è improbabile che un capo senza un'abitudine di lettura esistente lo legga. Potrebbero chiederti cos'altro dice.

Assicurati prima dei tuoi fatti. Dato un compito apparentemente indivisibile, sei sicuro che sia indivisibile? Forse non cinque modi, ma forse due o tre? Se si tratta di un'attività di programmazione, dovresti creare unit test, che non devono essere (o non dovrebbero affatto essere) eseguiti dal programmatore principale. A volte le attività di programmazione che sembrano indivisibili in superficie possono essere suddivise almeno un po 'più finemente. Sì, c'è un limite e sì, ci saranno rendimenti decrescenti poiché lo sforzo di coordinare il lavoro toglie il lavoro produttivo effettivo, ma se riduce il tempo complessivo per il completamento, hai almeno incontrato lo spirito del tuo capo intento.

Come detto in un'altra risposta, sarebbe bello se tutti coloro che avevano qualche connessione a uno sforzo di sviluppo software (team leader, project manager, supervisori, ecc.) avessero tutti letto e accettato "The Mese dell'uomo mitico ". Forse a un certo punto in cui non ci sono pressioni sulle scadenze e le cose procedono bene, potresti trovare un modo per presentare il libro al tuo capo. "Ehi, ho trovato questa lettura davvero affascinante ...".

Il mio suggerimento è di non dirgli niente. Dopotutto, lui possiede un'azienda e tu no. Molto probabilmente sa più di te sulla gestione di un'azienda. Se sai veramente di più sulla gestione dell'azienda di quanto ne sappia lui, forse dovresti gestire la tua azienda invece di lavorare per lui. Questo non vuol dire che non ci sia alcuna inefficienza nel modo in cui affronta il problema, ma ci sono probabilmente dei vantaggi che non vedi e il proprietario dell'azienda probabilmente sa che queste inefficienze esistono e sente ancora che ne vale la pena coinvolgere tutti. Penso che sia una forma di superiorità illusoria pensare che il tuo suggerimento sia l'approccio migliore.