Domanda:
Assegnato a un progetto difettoso, in errore giorni prima della scadenza
FrancoisL
2020-01-30 05:41:20 UTC
view on stackexchange narkive permalink

Lavoro da 1 anno in un'azienda tecnologica come sviluppatore 3D Expert Unity. E pochi giorni fa sono stato "promosso" a un nuovo progetto. È un progetto Unity3D che un cliente ha pagato (con un'enorme somma di denaro). E ho 5 giorni per aiutarti a finirlo. Ma ecco i problemi in questo progetto:

  • Il responsabile tecnico mi ha inserito nel progetto poche ore prima di abbandonare il progetto, lasciando tutti gli altri a lavorare al progetto "da soli"
  • Ho una dozzina di bug di Unity da risolvere in 5 giorni (risolto da qualcuno che conosce Unity e capisce i bug), cosa impossibile in 5 giorni.
  • Siamo un gruppo di 10 persone , e io sono l'unico che conosce Unity, e le altre persone non sono orientate alla programmazione. Alcuni di loro sono stagisti.
  • Se il progetto è ancora difettoso entro 5 giorni, l'azienda perderà i contratti futuri di un potenziale cliente, che possono essere valutati in poche decine di milioni di dollari
  • Il progetto utilizza i servizi di "collaborazione" di Unity, che utilizzano servizi cloud di terze parti. Pertanto, le informazioni del cliente potrebbero essere da qualche parte sulla terra e potrebbero essere accessibili da Unity (e quindi, possono creare azioni legali guidate dal cliente). Nessuno di noi ha Unity Pro (obbligatorio per progetti professionali come questo. Devo ottenere informazioni, ma Unity potrebbe anche avviare azioni legali , credo)

I miei superiori lo sanno la situazione. Tutti i membri del progetto non sono più motivati. Quindi, secondo te, cosa faresti in questa situazione? Dire la verità al cliente? Lascia che il progetto finisca con un bug? Fammi sapere cosa hai in mente.

Ti sei consultato con il tuo capo su come procedere?
@DarkCygnus niente di speciale, solo per lavorarci fino alla scadenza.Gli ho detto che era del tutto impossibile risolvere tutto, ma vuole che provi a risolvere il più possibile le cose poltiglia.
Il Direttore Tecnico che ti ha "insegnato" il progetto è ancora in azienda?C'era una persona esperta di Unity diversa nel progetto prima di te?Sembra che altri stiano cercando di prendere le distanze dal progetto prima del fallimento ufficiale.
"Se il progetto è ancora difettoso entro 5 giorni, l'azienda perderà i contratti futuri di un potenziale cliente" - come lo sai?
Hai detto che i tuoi superiori conoscono la situazione.Quali sono le loro aspettative?Perché pensi che dire la verità al cliente sia un'opzione?Normalmente parli con il cliente?Qual è il tuo ruolo in questa squadra?Hai davvero qualche responsabilità qui?I bug sono significativi?Manca così tanto contesto a questa domanda, ma le risposte sono abbastanza isteriche ...
C'è qualche possibilità che possiamo sapere cosa è successo dopo che quei 5 giorni sono finiti?Veramente interessato
@glace Questa potrebbe essere una domanda ipotetica da utilizzare in un'intervista per vedere come i candidati potrebbero gestire questa situazione e la risposta di Matthews è appena entrata nel loro foglio delle risposte come quella che un intervistatore vorrebbe sentire.Se si tratta di una situazione reale che l'OP si trova ad affrontare, sarei interessato anche a un follow-up ..;)
Tredici risposte:
#1
+217
Matthew Gaiser
2020-01-30 07:11:09 UTC
view on stackexchange narkive permalink

Dovresti concentrarti su una scialuppa di salvataggio per te stesso

Qualcuno ti ha promosso a guidare un progetto con soli 5 giorni rimanenti, che è un disastro assoluto? Con soli 5 giorni, sembra che avrebbero dovuto scegliere un leader ad interim dalla squadra stessa. A meno che non ti abbiano informato di tutti questi problemi (principalmente stagisti, problemi con la licenza Unity e la posta in gioco estremamente alta) prima che tu accettassi il lavoro , sei stato impostato come capro espiatorio o lavori per persone prive di curiosità / abilità / capacità di controllare le cose.

Informerei i miei superiori dei problemi in una lettera formale (inventerei ogni sorta di scusa per evitare qualsiasi cosa tranne scrivere e-mail per mantenere la traccia cartacea) e iniziare a cercare lavoro. Sospetto che tra poco ne avrai comunque bisogno. Chi ti ha promosso ti ha dato un mucchio di merda fumante e uno stuzzicadenti per affrontarlo.

Se almeno un po 'ti fidi del management, informalo in dettaglio dei problemi e che il progetto non è nemmeno vicino al completamento. Se intraprendono un'azione correttiva sufficiente e non ti danno l'onere di rispettare la scadenza, puoi considerare di restare. Altrimenti, esegui semplicemente il piano di partenza che stavi già preparando.

Se non ti fidi della gestione, invia la stessa email e fai il lavoro appena sufficiente per evitare di essere chiamato fannullone durante la ricerca di lavoro. Essenzialmente a quel punto cancellare la società.

Se davvero non ti fidi di loro e pensi di essere stato istituito, dimettiti immediatamente se puoi permettertelo. Non vorrei che il mio nome fosse associato a un progetto importante appena prima che crollasse, soprattutto se si tratta di un progetto abbastanza importante di cui la gente sarebbe a conoscenza.

Fai attenzione pensando che troverai un modo per salvare il progetto. Non posso dire in modo definitivo che sia impossibile, ma le cose non vanno bene. E sarai ritenuto responsabile per aver affermato (o anche detto che ci proverai) che puoi completare il progetto. I tuoi sviluppatori potrebbero esitare allo scricchiolio, potrebbero avere i loro piani di partenza fissati, molto del codice apparentemente funzionante potrebbe essere spazzatura, ecc.

È ora di costruirti una scialuppa di salvataggio e remare prima che il tuo manager ci provi per servire la tua testa per il fallimento del progetto.

Risposta davvero chiara e completa.Grazie per il tuo tempo a scriverlo.Stavo pensando all'idea di lasciare questo lavoro vero e proprio, perché la direzione qui aveva alcuni problemi seri prima, ma non così lontani.Cordiali saluti, sono stato automaticamente collegato al progetto e nessuno mi ha chiesto se lo volessi o no.Quindi, tutti i punti elenco nel mio post sono cose che ho imparato 24 ore su 24 dopo essere stato coinvolto.
Non posso essere più d'accordo con questa analisi della situazione.Consiglio vivamente di ascoltare il consiglio di Matthew Gaiser e di allontanarti il più possibile da questo progetto, fino alle dimissioni, indicando tutti i problemi con il progetto e il fatto che ti è stato appena assegnato.
Quella parte non è chiarita nella domanda, ma a me sembrava una piccola azienda che guadagna soldi con i progetti Unity?Questo è il motivo per cui in precedenza avevano 2 persone qualificate in Unity e ora sono scese a 1, motivo per cui il progetto del valore di "_qualche dozzine di milioni di dollari_" è assegnato all'unica opzione rimasta.Se questa è la situazione, è molto meno probabile che si liberino dell'ultimo pezzo di know-how su Unity.Se è più un contesto aziendale, però, questa risposta è molto più probabile.
Essere impostato come capro espiatorio sembra un'opzione.Tuttavia, la scadenza ridicolmente stretta parla contro di essa."FrancoisL non ha potuto finire il progetto in 5 giorni, è lui il colpevole!"Non lontanamente plausibile.Quindi, fintanto che si considerano le politiche dell'ufficio, il ruolo dell'OP potrebbe essere il Truth Finder, colui che sottolinea tutti i difetti nella (cattiva) gestione del progetto precedente e rivela la nuova realtà ai capi stupiti.
@IMil scendono "in 5 giorni" da quella frase e quindi diventa perfettamente plausibile.Lo fanno senza OP nella stanza e quindi OP deve correggere il record dopo che la colpa è già stata assegnata.Ho dovuto difendermi su qualifiche del genere e 1/3 delle volte la risposta è "niente scuse", 1/3 delle volte non riescono a capire quel dettaglio e si concentrano su "non sono riusciti a finire il progetto",e solo 1/3 delle volte lo capiscono.
@FrancoisL Vorrei aggiungere, ** informare il cliente di questo ** il prima possibile in modo che possano gestire le loro aspettative.Fallo tu stesso, con il tuo capo nella stessa chiamata, oppure chiedi al tuo capo di farlo _ e chiedigli di aggiungerti al cc_ in modo da poter confermare quanto viene detto.
Su "(inventerei ogni sorta di scusa per evitare qualsiasi cosa diversa dallo scrivere e-mail per mantenere la traccia cartacea)" - uno strumento utile qui è l'e-mail "Come abbiamo discusso".Se discuti verbalmente di qualcosa con la direzione, puoi inviare loro un'e-mail "per confermare i dettagli" con la tua comprensione della conversazione subito dopo per aggiungerli alla traccia cartacea.Ti copre le spalle in questo tipo di situazione e, a volte, può finire per scoprire anche un errore di comunicazione onesto.
Onestamente mi chiedo, se "vale milioni", io come cliente vorrei avere rapporti sui progressi nei dettagli.Se la consegna è in ritardo, non me ne importa più di tanto fintanto che c'è un buon nuovo percorso e le altre cose sono gestite professionalmente.Per quelle somme di denaro non è una cosa che fa o fa fallire.Quindi la direzione non sarebbe molto più indulgente se arrivassi a un calendario realistico?- Questa risposta mi suona come da un'azienda gerarchica molto rigida, non penso che la maggior parte funzioni in questo modo, a mio parere la maggior parte delle aziende cerca di avere una politica della porta aperta con il management.
Sembra che nessuno nella direzione sapesse che c'era un problema fino a quando la scadenza non li stava fissando in faccia - poi hanno fatto l'unica cosa che potevano, ovvero assegnare una risorsa aggiuntiva (tu) convinti che tu fossi il miglioreuno per il lavoro.Ma la mancanza di pianificazione da parte loro non costituisce un'emergenza da parte tua.A meno che non intendessero davvero "buttarti sotto l'autobus" dall'inizio, sperano ancora di salvarlo in qualche modo.(continua commento successivo)
(continua dal commento precedente) Allora cosa puoi fare?Chiedere tempo aggiuntivo per completare il progetto, insistere per essere chiamato a capo del progetto, delegare la risoluzione dei bug alle altre risorse e occuparsi di loro come necessario, mostrando loro come farlo.Ciò significherebbe molta stretta supervisione, ma a questo punto è l'unico modo.O forse gli altri hanno ragione;forse dovresti uscire mentre la presa è buona.
@rath non sarebbe in contrasto con la politica interna dell'azienda informare il cliente di questioni a tale livello?Voglio dire, se il cliente non lo sa ora, dovrebbe essere avvicinato dal CEO / qualcuno molto più vicino alla catena di comando delle relazioni con il cliente come project manager.I progetti in cui sono stato coinvolto sono stati per lo più con più o meno demarcazione che se i problemi sono a livello che minacciano l'adempimento del contratto, le persone dedicate alle relazioni con i clienti e / oi dirigenti senior devono essere intensificati.
#2
+52
DarkCygnus
2020-01-30 05:50:35 UTC
view on stackexchange narkive permalink

Quindi, secondo te, cosa faresti in questa situazione? Dire la verità al cliente? Lasciare che il progetto finisse con problemi?

Vorrei andare al più presto con il mio capo ed esporre loro la situazione. Dite loro che, in questo momento, vi manca il risorse per completare il progetto in tempo.

Chiamali, scrivili ... qualunque cosa tu debba fare per contattarli, poiché questo è critico .

Chiedere cosa si può fare per ottenere il progetto in tempo.

Fallo anche per iscritto; un'e-mail va bene. In questo modo hai le prove per sostenere le tue affermazioni in futuro (quindi non sei usato come capro espiatorio).

E nel frattempo, continua a lavorare normalmente sui bug (dal tuo commento sembra che questo sia ciò che il tuo manager ti ha detto di fare fino alla scadenza).

Non avevo pensato a prove scritte come la posta.Molte comunicazioni erano orali o telefoniche, quindi una mail completa per chiarire nuovamente questo aspetto e chiaramente potrebbe essere utile.
@FrancoisL Per ogni evenienza, potrebbe anche valere la pena di contattare BCC qualcun altro di cui ti fidi e fare una copia salvata delle e-mail nel caso qualcuno cerchi di buttarti sotto l'autobus.Inoltre, non parlare personalmente con il cliente.Lascia che sia il capo a occuparsi di tutto ciò.
@FrancoisL Ti consiglio di *** stampare *** le e-mail pertinenti o di ottenere in altro modo copie cartacee;se i server di posta elettronica sono controllati dalla tua azienda, teoricamente possono essere cancellati in qualsiasi momento, il che ti impedirebbe di accedere alle prove per proteggerti.
@SeldomNeedy Non andrei così lontano.Teoricamente potrebbero, ma è difficile da fare e il tuo PC ne avrà ancora una copia in locale.Ma inviare email - diavolo sì.* Ogni * requisito e compito dovrebbe essere scritto.E se è stato dato verbalmente, invii un'e-mail di follow-up per dire "questo è ciò che abbiamo appena deciso".Nessuna eccezione.
E se un dialogo importante avviene verbalmente, seguilo con un'e-mail come "Solo per confermare la nostra discussione di oggi, questa è la mia comprensione di ciò di cui abbiamo parlato ... ... per favore fammi sapere al più presto se ho frainteso qualcosao perso qualcosa ".Quindi sei coperto anche per le chiamate telefoniche e faccia a faccia, perché hai notato che per iscritto è un modo tale che anche l'altra parte ha effettivamente accettato la tua versione della conversazione, o altrimenti ti informa della loro versione diesso.
Ri: "Cancellare le e-mail è difficile".Prego di differire, @Graham;la mia organizzazione lo fa * sempre * sui singoli messaggi per mitigare i tentativi di phishing.Non appena lo fanno e Outlook ottiene una connessione, i messaggi vengono brindati anche sul computer locale.Per lo meno, i messaggi dovrebbero essere salvati su hardware che OP controlla personalmente.
@Graham: D'accordo con SeldomNeedy che non è difficile eliminare le e-mail.L'IT del mio istituto l'ha fatto la scorsa settimana per qualcosa con un errore di battitura minore che avevano inviato.Tutti i messaggi di posta elettronica, inclusi tutti i computer client e persino tutte le risposte a tali messaggi di posta elettronica, sono stati completamente eliminati dal sistema.
@Graham Anche se "il tuo PC" ha le e-mail, in uno scenario di lancio sotto il bus, avresti accesso al PC revocato.È davvero semplice "Hai fatto un pessimo lavoro, sei licenziato, esci dall'ufficio", quindi il PC viene estratto e pulito."Di routine", ovviamente: la proprietà aziendale viene riciclata per il riutilizzo.Le email "scompaiono" da / "non sono mai state" sul server.Sei già stato spinto fuori e l'autobus sta accelerando verso di te.
Sì, la carta è importante.In genere, quando si lascia un lavoro si perde l'accesso a tutto ciò che è elettronico e mantenerlo è una violazione del contratto.
#3
+22
Jessica
2020-01-30 17:30:56 UTC
view on stackexchange narkive permalink

Se l'azienda vuole sopravvivere, puoi diventare il capro espiatorio oppure creare il tuo profilo per gestire professionalmente una situazione orribile.

Dovresti concentrarti sulla scrittura e sulla comunicazione del problemi di questo progetto.

A quanto pare, 5 giorni potrebbero essere troppo pochi anche per questo compito, ma cerca di portare a termine almeno quello.

  • Dove sono problemi del progetto? Tecnicamente & organizzativamente
  • Come possono essere risolti questi problemi
  • Quanto tempo aggiuntivo sarà necessario

Prepara queste informazioni per il tuo capo. Comunica questo.

Quando parli con il tuo capo scopri se:

  • il cliente sa anche che esiste qualche problema
  • il cliente è disposto ad aspettare un po 'più a lungo, poiché questo avrebbe dovuto essere ovvio abbastanza a lungo

Cinque giorni prima della scadenza qualcuno avrebbe dovuto almeno comunicare che ci sono ancora alcuni problemi da affrontare .. In caso contrario, il cliente dovrebbe almeno essere informato in modo strutturato e sapere quanto tempo ci vorrà in più. Senza una pianificazione adeguata non sarai in grado di dirlo al cliente. Ci sono sempre problemi in ogni progetto e talvolta le scadenze verranno perse. La domanda è: come vengono gestite professionalmente tali situazioni. Questo è il tuo compito adesso. Comunica, comunica e comunica.

E ordina un libro per il tuo capo per progetti futuri: "Il mitico mese dell'uomo". La tua situazione è l'esatto esempio fatto in questo libro. Se un progetto sta fallendo, non provare mai a coinvolgere altri sviluppatori. Sembra che i capi nell'industria del software siano stati gli stessi negli ultimi 40 anni.

"Se un progetto sta fallendo, non provare mai a coinvolgere altri sviluppatori."In questo caso, l'unica eccezione sarebbe quella di individuare una rockstar di Unity e dare loro una valigetta piena di soldi per risolvere i problemi.E comunica: invia informazioni lungo la catena manageriale e lascia che le decisioni vengano prese.
#4
+14
gnasher729
2020-01-30 18:13:27 UTC
view on stackexchange narkive permalink

A vantaggio dell'azienda: dovrebbe esserci una discussione tra te, il tuo manager e qualcuno che può prendere decisioni su progetti multimilionari.

Il fatto è che non ci sarà un prodotto privo di bug entro cinque giorni, questo è un dato di fatto. Il fatto, che deve essere comunicato chiaramente a qualcuno più in alto del tuo manager, è che non c'è niente che tu possa fare al riguardo, e che se diventa a forma di pera, è il tuo manager che dovrebbe essere licenziato, non tu. Il fatto è che questo è molto, molto critico in termini di tempo.

Quello più in alto deve decidere se perdere molti milioni, se andare dal cliente umiliante e riuscire in qualche modo a ridurre i costi (questo è qualcosa al di fuori del tuo campionato e al di fuori del campionato del tuo manager), o spedire un prodotto con bug e subire la perdita di reputazione e alcuni costi aggiuntivi per la risoluzione dei bug.

Quindi questa è una cosa di cui hai bisogno per andare avanti. E l'altra cosa è che devi fare tutto il possibile per mettere il software in una forma in cui non presenti bug evidenti, in modo che possa essere dato al cliente e accettato dal cliente. Un cliente troverà sempre problemi con il software dopo averlo accettato e non sa se ci sono problemi di cui sei a conoscenza. Quindi "esente da bug conosciuti" non è il criterio, ma "esente da bug che fanno rifiutare al cliente l'accettazione del software che ci costa milioni", questo è il criterio.

Quindi c'è una possibilità che ne esca come un eroe e la possibilità di uscirne senza lavoro. Dipende da te.

È un grande salto presumere che il manager non possa prendere decisioni sui progetti, e molto probabilmente non è una buona mossa andare al di sopra della testa del manager, specialmente in una nuova squadra.
Questo progetto potrebbe costare all'azienda decine di milioni di contratti di listino.Fuori dai limiti del suo manager.Soprattutto perché questo non è un problema di sviluppo, ma un problema aziendale.
Dovresti anche valutare questi bug se sono critici o meno per il cliente.Quelli critici dovrebbero essere corretti se possibile prima del rilascio o almeno implementare qualche soluzione alternativa che li nasconda o ne riduca la gravità.Per quelli non critici è possibile preparare un elenco di problemi noti con soluzione alternativa (se presente).Questo elenco può essere inviato al cliente in un secondo momento, se necessario.
@DanielFrużyński Non senza che qualcosa di più in alto sia d'accordo.sembra una situazione in cui non vuoi che il cliente abbia il sospetto che tu abbia consapevolmente venduto loro un lavoro difettoso.E dovrai comunque risolvere i problemi;Mi concentrerei (dopo che qualcuno più in alto è d'accordo) sulla risoluzione dei problemi che segnalano al più presto in modo che l'azienda appaia affidabile e reattiva.Ma questo è tutto per il futuro;la cosa più importante è cosa fare questa settimana.
#5
+10
workerjoe
2020-01-30 20:24:53 UTC
view on stackexchange narkive permalink

La gestione delle crisi a volte consiste nello scuotere le cose, capovolgere le tabelle (metaforicamente), " far cadere i tuoi strumenti" e uscire da una routine. Hai personale demotivato e un progetto impossibile. Restare in silenzio e lasciare che fallisca non è un'opzione; né si lamenta né lo ignora. Devi assumerti la responsabilità della situazione e mostrare il percorso da seguire anche se non hai l'autorità formale per approvarla.

È importante non solo mostrare alla squadra, e i tuoi manager, che la situazione è cambiata, ma anche il cliente deve sapere che è stato nominato un nuovo "responsabile delle crisi" per il team e che c'è un nuovo piano da realizzare . Ricorda, il cliente ha sicuramente saputo che il progetto era in ritardo sulla pianificazione e presenta bug, e vogliono che venga risolto. Probabilmente sono spuntati dal precedente project manager e non gli piace "come stanno andando le cose". Sentiti libero di costruire un rapporto raccontando loro tutte le cose che il precedente manager ha sbagliato o non è riuscito a fare e chiarisci che c'è un nuovo sceriffo in città.

Il tuo piano dovrebbe essere presentato al cliente direttamente (non tramite il tuo capo o un reparto vendite) e dovrebbe includere:

  • Identifica cosa farai e cosa non farai . Elenca i 12 bug specifici che risolverai e annuncia un "blocco" su qualsiasi altro codice / funzionalità fino a dopo il rilascio.

  • Fornisci una nuova sequenza temporale per facendo specificamente quelle cose.

  • Dì loro esattamente di cosa hai bisogno se vogliono che questo abbia successo (ad esempio, le licenze software "pro" oggi ). Sii un po 'discreto qui; non accusare il tuo manager di essere scadente o incompetente o di infrangere la legge, dì semplicemente al cliente che è qualcosa per cui dobbiamo pagare senza soffermarti sul motivo per cui non lo hai già.

  • Spiega il problema con i servizi di terze parti e spiega loro cosa devono fare o decidere perché (come parte del blocco del codice) non lo affronterai finché dopo il rilascio

In breve, chiarisci che la situazione attuale ha un problema e che sei un nuovo team leader determinato al 100% a risolvere ciò che non funziona e hai un piano. Possono prenderlo o lasciarlo. Se hanno milioni di dollari investiti in esso, vorranno salvare il progetto piuttosto che vederlo fallire. Il tuo capo o il tuo reparto vendite potrebbe cercare di scoraggiarti dal parlare direttamente con il cliente, perché (consapevolmente o meno) godono del privilegio di possedere la relazione con il cliente, ma ti ringrazieranno in seguito per aver salvato il progetto. "Meglio chiedere perdono che permesso".

Ciò presuppone che il cliente sappia cosa sta succedendo.È del tutto possibile che non ne abbiano idea perché il (precedente) management ha detto loro: "Certo, nessun problema. Sarà pronto il giorno X".
Questo è un cliente che presumibilmente ha più milioni di dollari investiti in questo team di 10 persone e la scadenza è tra 5 giorni.Sono sicuro che ci hanno prestato * un po '* attenzione.
@Llewellyn Quindi puoi incolpare il precedente manager.Il cliente potrebbe perdere la sua merda, ma puoi mettere in chiaro che non sei stato tu.Può essere positivo essere d'accordo con loro sul fatto che la situazione fa schifo, anche se senza ammettere responsabilità che rovinerebbero la tua azienda.Ma la cosa principale è mostrare che hai un piano, e quel piano è realizzabile.Ci sono stato anch'io, anche se non in modo così estremo, ma il cliente ha apprezzato molto il fatto di essere tenuto informato sull'analisi dei gap e tutto il resto.
Non mi è chiaro dal modo in cui è scritta la domanda che l'OP abbia l'autorità di parlare direttamente con il cliente.
@MichaelKay Se fossi nella situazione dell'OP parlerei comunque con il cliente, l'autorità formale sarebbe dannata.Se gli viene esplicitamente vietato di farlo, allora viene considerato il capro espiatorio per il fallimento del progetto e non è vincolato dall'onore a stare al gioco.
Stai dimenticando la cosa più importante: ASCOLTA IL CLIENTE: potrebbero andare bene con la data ma hanno bisogno di funzionalità;potrebbero aver bisogno della data ma accettano un sottoinsieme di funzioni.Potrebbero essere felici di lasciarli scivolare entrambi e semplicemente felicissimi che il vecchio manager se ne sia andato.Ripeti ciò che hai sentito in modo che sappiano che hai capito.Inoltre, SOTTO PROMESSA.Nel frattempo, data l'urgenza del cliente, vedi se c'è una quantità di esperienza a brevissimo termine che puoi assumere per proporre o esaminare soluzioni o eseguire il debug o quello che hai.
#6
+6
Tom
2020-01-31 02:11:16 UTC
view on stackexchange narkive permalink

Hai bisogno di un incontro di emergenza con il top management (le persone più alte le cui teste girano se questo progetto va in crash e brucia).

Non dici chiaramente se tu sei diventato il manager del progetto o lo sviluppatore principale. Se sei il manager, devi chiamare per questo incontro, subito, senza ritardi. In caso contrario, devi insistere affinché lo faccia il manager.

Potresti essere in grado di trovare un aiuto esterno per salvarti il ​​culo. Alcune vere crepe di Unity che possono salvarti. Per i migliori soldi, ovviamente, ma il danno sarà comunque inferiore rispetto a se il progetto dovesse bloccarsi. Ma è per questo che è necessario coinvolgere il top management, perché serve una persona sul tavolo con la necessaria autorità di spesa.

Serve anche una comunicazione di emergenza al cliente. A seconda di ciò che sa o meno, della natura del progetto e del contratto firmato, potrebbe essere possibile annunciare o negoziare un ritardo per guadagnare il tempo necessario.

Devi intensificare questo e chiarisci per iscritto che questa è la situazione che hai trovato quando hai assunto il nuovo ruolo e che sei assolutamente certo che, a meno che non vengano intraprese azioni di emergenza immediatamente , il progetto non verrà consegnato in tempo. Questo devi farlo per coprirti il ​​culo ed evitare di diventare il capro espiatorio.

#7
+6
Harper - Reinstate Monica
2020-02-01 04:42:14 UTC
view on stackexchange narkive permalink

Molte persone ti stanno dicendo di tagliare e scappare. Ma è a causa del livello di drammaticità che stai creando su questo, che ovviamente riflette un livello molto alto di disagio e ansia. Il che ti rende adatto a essere un manager di crisi. Hanno bisogno di qualcuno che raddrizzi la nave. È possibile che siano nei guai perché l'ultima persona non è stata onesta con la direzione.

La tua responsabilità è limitata

Come dipendente W-2, non hai responsabilità personale per i risultati qui in senso legale. Il cliente non può seguirti personalmente in alcun modo.

È un progetto Unity3D che un cliente ha pagato (con un'enorme somma di denaro)

Se il progetto è ancora buggata in 5 giorni, l'azienda perderà i contratti futuri di un potenziale cliente, che possono essere valutati in poche decine di milioni di dollari

Quella è una grossa borsa del non tuo problema / non tuo lavoro .

È facile ottenere un complesso di eroi e pensare che il risultato sia "tutto su di te". Ma non lo è. Poggia esattamente sulle spalle di altri, che hanno pelle nel gioco : hanno investito il loro capitale in questo business e la loro ricchezza personale galleggia o affonda in base al loro decisioni.

Per quanto riguarda la crisi imminente, non lo sai. Era il loro lavoro avere il polso del polso del loro progetto ed essere in costante comunicazione con il cliente al riguardo. È del tutto possibile che stiano già avendo la conversazione "arriverà tardi" con il cliente, e i proprietari e il cliente stanno risolvendo la questione. Non è un tuo problema .

Quindi le informazioni del cliente potrebbero essere accessibili da Unity (e quindi, possono creare azioni legali guidate dal cliente). Nessuno di noi ha Unity Pro (Unity potrebbe anche avviare azioni legali, credo)

Non possono fare causa a te . Sei solo un dipendente. Sei protetto dal velo aziendale, non sei un amministratore, un funzionario o un alto manager, quindi non hai il tipo particolare di dovere fiduciario che è possibile citare in giudizio. E non sei un avvocato e non sei a conoscenza del prodotto di lavoro legale dell'azienda, quindi davvero non lo sai.

Dovresti dire qualcosa del tipo "Non sono sicuro che abbiamo la corretta Licenza software Unity per quello che stiamo facendo, chiedi legale di controllare "e il tuo lavoro è finito.

Quindi sarà tardi

Per prima cosa, assolutamente la prima cosa, devi segnalare alla direzione che è tardi, e un senso grossolano di quanto siamo indietro rispetto alle parti che sono di tua responsabilità. È più importante farlo velocemente che ricercarlo a fondo, quindi dedica 1 ora e non 2 giorni a scrivere questo rapporto. Queste sono le cose che devono sapere per prendere le loro decisioni aziendali .

Il tuo prossimo compito è formulare un piano per portare a termine le tue parti il ​​prima possibile, anche se in ritardo. Dovrai svilupparlo nel prossimo giorno o due al massimo. Imposta una cronologia realistica e inseriscila in un altro rapporto scritto. Questo è il tuo lavoro.

Questi sono rapporti CYA. Vanno sulla carta. Metti una copia nella tua auto prima di presentargliela, quindi consegnala o presentala al loro assistente amministrativo o al loro manager. Invia anche un'e-mail in PDF. Non hanno bisogno di sapere della copia che tieni per te. È una carta "esci di prigione gratis" nell'improbabile eventualità che tu ne abbia bisogno, ma esito a dirlo perché non voglio che tu vada nel panico. Non ne avrai bisogno.

Non che siano affari tuoi, ma quello che succederà davvero qui è che la scadenza va e viene e l'azienda discuterà con il cliente e cercherà di capire cosa fare dopo e come meglio preservare il valore. Quasi certamente, il cliente acconsentirà a una data di fine posticipata. Se la tua azienda ha le tue stime a portata di mano, può negoziare da una posizione di forza e fiducia, e questa è la possibilità migliore per salvare il contratto.

Questo non è il primo progetto in ritardo nello sviluppo del software .

#8
+4
Lawnmower Man
2020-02-01 06:08:22 UTC
view on stackexchange narkive permalink

Opportunity Knocks

A differenza della risposta accettata, mi limito a dire che la probabilità di essere licenziato è 0. A differenza del manager precedente, hai dimostrato di sapere cosa stai facendo e puoi portare a termine le cose. Sei stato assegnato al progetto perché tutti sanno che è uno spettacolo da $ #! + E nessuno vuole toccarlo con un palo da 20 '. Probabilmente tutti sanno che è una "missione suicida". Quindi si aspettano che tu fallisca, e probabilmente lo farai.

Dato che l'azienda si trova in una brutta posizione e tu sei stato incaricato della missione di salvataggio, ora hai un'enorme influenza. Quali sono le loro opzioni? Se avesse qualcuno di migliore per riparare il Titanic, questa domanda sarebbe stata scritta da quella persona. Quindi non pensare a questa situazione come una "promozione" a un progetto: pensala come una vera opportunità di promozione.

Dì la verità

L'ex manager ha mentito sul progressi in modo che non sembrassero male, o hanno già detto alla direzione che la tempistica era impossibile e la direzione li ha ignorati. Esprimi la tua valutazione professionale ma spassionata della situazione: "Ho classificato i bug rimanenti come piccoli, medi o grandi. Piccoli bug possono essere corretti entro 2-4 ore da uno sviluppatore Unity intermedio. Medium può essere risolto in 4-12 ore e la risoluzione di bug di grandi dimensioni può richiedere 12-48 ore. Date queste stime, abbiamo bisogno di circa 340 ore per correggere questi bug, ma abbiamo solo 4 sviluppatori x 8 ore x 5 giorni = 160 ore disponibili. Ciò è dovuto al significativa mancanza di esperienza in Unity nel team. "

Esprimi le tue richieste

Innanzitutto, dì al tuo manager che devi ottenere una licenza Unity appropriata, altrimenti non lavorerai al progetto . Ricorda, personalmente non hai milioni di dollari in gioco da perdere. E se l'azienda ti caccia fuori in questo momento, qualcuno (o forse molte persone) sopra di te ti seguirà fuori dalla porta.

In secondo luogo, se conosci altri esperti di Unity in azienda, specialmente quelli che conosci e di cui ti fidi personalmente, di 'al tuo capo esattamente chi vuoi nel tuo team e per quanto tempo ne hai bisogno. Usa le tue proiezioni del modello di triage come motivazione. Se pensi di poter portare armi esterne a noleggio per aiutare, fallo, ma immagino che anche il tempo a bordo renderebbe questa soluzione impossibile.

Terzo, dì loro cosa pensi di poter realisticamente realizzare, negli scenari di risorse più probabili. Non rivestirlo di zucchero. Sarà una pillola amara per loro da ingoiare, ma hanno bisogno di ascoltarla e preparare il cliente. Solo per chiarire il punto, dì al tuo capo: "Se questi termini non funzionano per te, ho preparato le mie dimissioni per te". Questo è fondamentalmente solo un bluff, ma devi scriverlo nel caso lo chiamino.

Aftermath

Se la compagnia sopravvive, ovviamente ci saranno delle conseguenze. Un problema non diventa così grave senza più livelli di gestione che falliscono. Cerca in giro, scopri chi ha ignorato gli avvertimenti, o ha nascosto il fallimento, o ha agito in altro modo in malafede, e assicurati che la direzione si occupi di quelle persone in modo appropriato, o ti ritroverai semplicemente in un'altra crisi tra pochi mesi. Si spera che a questo punto avrai la leva per richiedere cambiamenti e miglioramenti (più formazione Unity, ovviamente), oltre a un bonus / promozione per te e per chiunque altro si sia fatto avanti. Oppure potresti cercare un nuovo lavoro. Buona fortuna!

#9
+3
Brian R
2020-01-30 22:01:15 UTC
view on stackexchange narkive permalink

Concentrati su ciò che un leader farebbe in questa situazione.

Sii obiettivo nella valutazione e fornisci alla tua leadership un'analisi ponderata della situazione ora che sei effettivamente in grado di mettere le mani su tutte le informazioni pertinenti. Informali dei problemi in sospeso e fornisci soluzioni per ciascuno di essi.

Se riesci a correggere i bug in 5 giorni, ma dovrai assumere tre liberi professionisti esperti a $ 500 / ora, presentalo come una mitigazione contro il rischio di perdere $ 10 milioni se il progetto fallisce.

Non essere negativo e dire quanto stia andando male il progetto: indica gli ostacoli attuali e poi spiega loro come sconfiggerli. In questo modo non sei la persona che non ha potuto farlo, sei la persona che ha presentato le soluzioni che un'altra persona ha rifiutato.

`... dovrai assumere tre liberi professionisti esperti`.Questa è una * idea eccellente *, che potrebbe salvare la giornata.Tuttavia, segui anche gli altri consigli sulla comunicazione con la tua direzione e * pronto *!
Un'altra cosa che un leader dovrebbe fare è comunicare la situazione al * cliente * ... ma questo è ancora più un campo minato :)
@rackandboneman Questo è molto vero, ma a seconda della posizione effettiva di OP in azienda, questo potrebbe essere al di là delle loro responsabilità.Quando si tratta di una brutta notizia, direi che il responsabile pratico (OP) dovrebbe fare un rapporto scritto per il cliente ed essere disponibile per spiegazioni di persona durante la riunione, ma un direttore o VP sarà probabilmente quello che guida ildiscussione per conto della società di OP.
#10
+2
Swiss Frank
2020-02-01 19:37:49 UTC
view on stackexchange narkive permalink

Alcune delle risposte precedenti mettono in guardia dall'essere impostato come un capro espiatorio. Ho lavorato in posti abbastanza disorganizzati da avere i problemi che descrivi, ma non abbastanza machiavellici. Il rasoio di Occam suggerisce semplice caos, nebbia di guerra, mancanza di flusso di informazioni, ecc. E hanno già un capro espiatorio: il manager prima di te. Non puoi possibilmente essere il capro espiatorio, se ho capito bene.

Alcune delle risposte precedenti suggeriscono di fare il minimo possibile, non essere l'eroe, inizia a cercare il prossimo lavoro, ecc. Nella mia carriera, l'esperienza di essere un eroe è effettivamente utile. È richiesto ogni tanto. Nei tuoi panni sarei eccitato all'idea di esercitarmi a spegnere un incendio così grande. Se fallisci, non è colpa tua e imparerai sicuramente qualcosa. Nella mia esperienza le industrie sono piccole e andrai avanti con le persone più e più volte ed è meglio che ricordino uno sforzo super umano piuttosto che un'alzata di spalle e il tuo CV sulla stampante del team. E chissà, c'è una possibilità che le cose funzionino e ti procuri una seria promozione. Potrebbe non essere più denaro o un nuovo titolo, ma le persone inizieranno a chiederti di più, ad ascoltare quello che dici e così via. Questo da solo rende un lavoro molto più piacevole.

Ovviamente, non parlare con il cliente senza permesso, ma supponendo che tu possa, ascoltare è fondamentale. Forse hanno bisogno della data ma non tutte le funzionalità. Forse hanno bisogno di tutte le funzioni ma la data può scivolare. Forse il loro principale desiderio è semplicemente che qualcuno li ascolti e capisca di cosa hanno veramente bisogno e possono perdere la data e caratteristiche e affidabilità. / p>

Inoltre, underpromise in questa fase, la cosa più difficile per qualsiasi ingegnere nella mia esperienza.

#11
+1
Martin Zeitler
2020-01-31 20:11:12 UTC
view on stackexchange narkive permalink

Questo è DOA, prima dell'arrivo. E tu eri sicuramente predisposto al fallimento.

Restituire immediatamente il progetto al precedente manager consigliato, che probabilmente ha preso le distanze, perché i narcisisti vivono spesso in un mondo di sogno e sono incapaci di assumersi la responsabilità delle loro azioni . Chiunque abbia acconsentito a cambiare il project manager poco prima della scadenza potrebbe esserlo anche lui - e potrebbe interpretare te. Non c'è da stupirsi che l'ambiente sia diventato tossico, una volta che la realtà è emersa. Questa intervista spiega bene il problema reale e la follia della situazione. Cerca sempre di lasciare una traccia cartacea e di avere un testimone con te, quando si tengono riunioni rilevanti. Se questa non è un'opzione, segui la catena di comando e lascia che i rappresentanti comunichino con il cliente, in modo da presentare loro una tempistica realistica e requisiti di licenza. Al fine di mantenere il cliente, potrebbe essere richiesta l'accettazione di una penale convenzionale, poiché i termini del contratto non verranno rispettati in tempo. Potrebbe essere necessario sostituire alcuni compagni di squadra irrilevanti con liberi professionisti per accelerare i progressi.

#12
  0
ldog
2020-02-01 14:13:01 UTC
view on stackexchange narkive permalink

Anche se la maggior parte, se non tutte, le risposte qui sono focalizzate sulla ricerca del numero 1 (cioè tu), proporrò una risposta radicalmente diversa. Ma prima di farlo, voglio dire che ciò che descrivo in questa risposta non si esclude a vicenda con ciò che è descritto in altre risposte (cioè ricerca di lavoro, documentare tutto, smettere prima del fallimento, ecc.) Quindi tienilo a mente, il tempismo è tutto in questa situazione. Vuoi lasciare abbastanza tempo per cambiare radicalmente il tuo approccio se la tua comprensione della situazione cambia.

Ciò di cui hai bisogno per capire in una situazione come questa è quella in cui il proverbiale merda ha colpito il proverbiale fan. Qualcuno ha lasciato cadere la palla alla grande e tu sei stato inserito in questa situazione solo per due possibili scenari:

  1. Ti stanno preparando per essere il capro espiatorio.
  2. Sei stato inserito nella situazione perché qualcuno più in alto pensa che tu sia un operatore di miracoli.

Certo, ogni istinto mi dice che 1. è molto più probabile, ma 2. è una possibilità che non può essere ignorata e, anche se non è vera, puoi comunque trasformare questa possibilità in realtà.

In questa situazione, se vuoi risolverla nel miglior modo possibile per l'azienda (cioè fare il miracolo), hai davvero solo un gioco, ed è affermare la tua posizione di leader di il progetto e negozia per più tempo con le parti interessate. Se non riesci a negoziare, non sei in una posizione peggiore di quella che sei attualmente. Se ci riesci, puoi negoziare da una posizione di grande forza (perché rappresenti l'unica luce alla fine del tunnel).

Renditi conto, tuttavia, che queste sono le uniche due possibilità e potresti anche oscillare per le recinzioni, perché se 1. è vero, starai comunque cercando un nuovo lavoro. Tuttavia, potresti finire per fare un fuoricampo.

TLDR: negozia per più tempo perché non hai nulla da perdere. O sei il capro espiatorio o il taumaturgo , quindi dai per scontato il secondo e, nel peggiore dei casi, ricorri al primo e inizia la tua fuga.

non è stato impostato come un fallito.Se ce ne fosse bisogno - se fosse quel tipo di azienda - hanno già il manager che ha rovinato tutto e si è diviso.Non è necessario coinvolgere le persone cinque giorni prima del rilascio per assumersi la colpa, e quanta colpa rimarrebbe su un ragazzo che non è stato nemmeno coinvolto fino a cinque giorni prima del passaggio di consegne?Non è nemmeno sicuro che sia pensato per essere un operatore di miracoli.I dipartimenti hanno solo così tanti lavoratori.Potrebbe essere considerato buono ma non un operatore di miracoli.Potrebbe esserci personale migliore che non può essere portato a termine dai progetti, ecc.
#13
  0
Simon B
2020-02-02 23:40:23 UTC
view on stackexchange narkive permalink

Ecco una visione piuttosto mercenaria sull'argomento.

Se non ti è stato detto che è tuo compito parlare con il cliente, allora non è tuo compito parlare con il cliente. Lasciarlo alla direzione, ai contratti o al dipartimento.

Quindi ci sono due possibilità:

  1. Il software verrà spedito con bug. Se esiste un contratto di supporto, i bug verranno corretti in base a quello. Il cliente non sarà felice, ma tu non puoi fare nulla al riguardo.
  2. Il software non verrà spedito in tempo. Chiunque sia responsabile del dialogo con il cliente dovrà risolverlo. Non è il tuo lavoro.

Quindi fai tutto il possibile per correggere i bug più seri ora. Ciò potrebbe significare chiedere aiuto agli altri membri del team. Oppure può significare congelarli mentre lavori da solo. Fai tutto ciò che risolverà i bug più gravi il più rapidamente possibile.

Mantieni il management aggiornato su ciò che sta accadendo. Questo presuppone che non stiano già organizzando riunioni quotidiane.



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...