Quale risposta dovrei dare?

Questa risposta è per un ruolo di sviluppatore di software ( nessun rapporto diretto ) :

La semplice risposta qui è la verità . E in questo caso specifico, se sai che la scadenza non verrà rispettata, la cosa migliore è fornire la verità prima piuttosto che dopo .

Fondamentalmente vogliono sapere che non nasconderai il fatto che non rispetti la scadenza e non hai paura di chiedere aiuto .

Non otterrai mai un lavoro del genere ripetendo una risposta che ti è stata data su un sito come questo. Devi imparare come rispondere a questa domanda con le tue parole usando la tua esperienza e gli esempi di cui hai effettivamente fatto parte. Detto questo, puoi trovare una risposta migliore da dare loro la prossima volta. La chiave è capire perché lo chiedono. Credono di sapere cosa fare e cosa non fare in quella situazione e vogliono vedere se lo fai anche tu.

Una buona risposta conterrà due cose. In primo luogo, dovresti essere facilmente in grado di elencare le tue opzioni: dire al cliente che la scadenza non sarà rispettata, far cadere una parte del lavoro, quel genere di cose. E questo elenco non dovrebbe includere cose che non funzioneranno, come l'aggiunta di persone al progetto. Secondo, dovresti essere in grado di spiegare come sceglieresti tra queste opzioni e come comunicheresti nella situazione. Se dici semplicemente "Vorrei X" senza alcuna spiegazione del motivo per cui X invece di Y, non è una buona risposta.

Se stai facendo domanda per una posizione di project management, si aspetteranno opzioni leggermente diverse e processi di pensiero rispetto a se ti stai candidando come sviluppatore lavorando senza il supporto di PM, ma la base "avrei una scelta di X o Y, non prenderei in considerazione A o B e sceglierei X o Y in base a Z "sarà ancora lì.

Se non hai una buona risposta e ti è stata chiesta più di una volta, procurati una buona risposta. Sicuramente l'hai affrontato? Anche se hai visto qualcun altro gestirlo invece di gestirlo tu stesso? Cosa ha funzionato, cosa no, cosa hai fatto prima in quella situazione? Migliora nel raccontare quella storia.

Questa è anche un'opportunità, dopo aver risposto alla domanda , per parlare di quanto sia importante non entrare in quella situazione e di cosa fare per prevenirla. Potrebbe trattarsi di riunioni periodiche sullo stato, rilasci frequenti, resistenza allo scivolamento dell'ambito, monitoraggio dei progressi o qualsiasi altra tecnica che hai imparato nel tuo lavoro. L'intervistatore vuole sapere cosa sai fare.

In quanto sviluppatore di software , non è compito mio discutere questo tipo di problema con il cliente e in quanto sviluppatore di software non posso fare nulla per risolvere personalmente il problema.

Quindi l'unica linea di condotta sensata è contattare il gestore del programma il prima possibile per renderlo consapevole della presenza di un problema e discutere con lui cosa si può fare per ripristinare il progetto sulla buona strada.

La risposta potrebbe essere quella di assegnare più persone al lavoro, negoziare una scadenza successiva con il cliente o diverse altre opzioni. Ma non spetta a me prendere la decisione.

O cosa si aspettano di sentire?

Stanno cercando di vedere come pensi ed elabori questo tipo di domande.

Non vogliono vederti mentre cerchi di dire loro quello che pensi che vogliano sentire. Non vogliono sentire una risposta preconfezionata.

È difficile, ma cerca di non indovinare cosa vogliono sentire. Invece, ascolta la domanda, riflettici e rispondi onestamente. Prova a metterti nella situazione posta e di 'loro come reagiresti.

E se hai effettivamente incontrato la situazione, assicurati di indicare che hai, cosa hai fatto e se lo faresti di nuovo la stessa cosa.

Buffo che questa fosse una delle domande, la mia risposta a cui (credo) mi ha dato uno dei miei lavori precedenti. Non era un buon lavoro, perché tali situazioni erano comuni lì. Ma era rilevante per quel lavoro (e dovrebbe darmi un suggerimento per non accettarlo).

Ho menzionato quello che abbiamo fatto in uno dei progetti a cui ho partecipato:

una situazione impossibile: in una piccola azienda, avevamo bisogno del contratto per tenerci in vita per i prossimi mesi. Era un'estensione del nostro sistema (contabile) che volevamo implementare, ma la scadenza per completarla era impossibile. Quindi abbiamo iniziato a implementarlo comunque, con le nostre migliori ipotesi su come farlo, e abbiamo pubblicato un grande documento con molte domande che chiedevano esattamente come vogliono che venga implementata la nuova funzionalità. E abbiamo detto loro che ci sarebbero voluti X mesi dopo che avremo ricevuto le risposte finali.

Indovina un po ': ci sono voluti mesi per concordare tra loro ciò che esattamente vogliono, mentre noi stavano implementando la migliore ipotesi. Abbiamo ottenuto il contratto, alcuni pagamenti importanti dal cliente. Nella maggior parte dei casi abbiamo indovinato, pochi casi abbiamo dovuto riprogettare, poche funzionalità sono state rimandate alla fase due, ma l'azienda è sopravvissuta per combattere un altro giorno.

Non sono sicuro che tu possa semplicemente simulare tale risposta (perché questa è una vera storia di guerra, qualsiasi domanda successiva potrebbe rivelarti un falso se non l'hai vissuta).

In una situazione in cui vivi o muori, sei costretto a correre rischi con speranze che avrai fortuna, perché altrimenti la compagnia morirà comunque. Nessuno scrive delle centinaia di startup fallite, vengono citate solo quelle di successo. Vedi pregiudizio per la sopravvivenza: presumi che sopravviverai.

Secondo il Team Software Process (della Carnegie Mellon University), è necessario comunicare con gli stakeholder non appena il team sa che la scadenza non può essere rispettata. Ciò consente a tutte le parti interessate di ripianificare, rimuovere funzionalità o fare qualcosa per risolvere il problema (di non rispettare la scadenza).

Secondo il Mythical Man Month, di Fredrick Brooks Jr., aggiungere più persone a un progetto non ridurrà il programma.

In termini di gestione del progetto, c'è il triangolo con i lati di ambito, tempo e budget. Se uno dei lati cambia (in lunghezza), anche gli altri due devono cambiare.

Quindi, per rispondere alla domanda dell'intervistatore:

1. Calcola la nuova scadenza in base alle circostanze attuali. Determina la probabilità di rispettare con successo la scadenza.
2. Calcola la durata richiesta per completare i requisiti rimanenti. Determina la probabilità di rispettare la scadenza con questa tecnica.
3. Calcola la nuova scadenza in base all'aggiunta di risorse al progetto. Dothis per 1 persona fino a 5 persone. Determina la probabilità di rispettare la scadenza con questa tecnica.
4. Chiama una riunione con le parti interessate per discutere la situazione e ripianificare. Usa le informazioni degli elementi # 1, # 2 e # 3 sopra.

Le informazioni dai # 1, # 2 e # 3 dovrebbero provenire dai membri del team (che fanno il lavoro). Sono i più vicini al progetto e possono fornire informazioni con il massimo grado di certezza.

IMHO, pianifica sessioni di straordinario solo se il tempo di completamento è piccolo. Non vi è alcuna garanzia che gli straordinari miglioreranno la qualità del prodotto; a volte gli straordinari possono introdurre più problemi e prolungare il programma.

In un negozio in cui ho lavorato, i requisiti sono stati rimossi dal progetto per ridurre la pianificazione.

Questa sarebbe la mia risposta, se il mio ruolo fosse un Project Manager :

Se non credo che possiamo rispettare una scadenza, la prima cosa che devo stabilire è ciò che sarebbe necessario in termini di manodopera e altre risorse per raggiungere l'obiettivo.

Quindi dovrei andare dalla mia direzione e insieme possiamo eseguire una valutazione se vale la pena spendere le risorse aggiuntive per per completare il progetto.

Se la direzione spinge contro risorse aggiuntive, andrei dal cliente e spiegherei la situazione e consiglierei una riduzione della portata del lavoro, fino a quando il lavoro diventa fattibile nel lasso di tempo. Lavorerei con il cliente per dare priorità al lavoro in modo da garantire che l'impatto sul cliente sia ridotto al minimo.

Se il cliente rifiuta di ridurre l'ambito o di discutere la priorità del lavoro, analizzerei attentamente i requisiti per vedere qual è il insieme di prodotti che limitano il danno alla reputazione della mia azienda e, inoltre, eventuali sanzioni pecuniarie applicabili. Vorrei chiarire al cliente cosa verrà consegnato in quel lasso di tempo, al fine di mitigare l'impatto sul cliente.

Immagino che in alcune situazioni, i clienti possano essere più ricettivi alla rinegoziazione quando si rendono conto che non otterranno tutto ciò che desiderano e desiderano avere un controllo migliore su ciò che ottengono. Potrebbero anche essere disposti a posticipare la scadenza "difficile".

Ovviamente, è deplorevole che qualsiasi progetto arrivi a un punto in cui c'è una grande sorpresa verso la fine. Idealmente dovremmo monitorare i progressi e ciò ci consentirebbe di modificare l'ambito del lavoro in modo graduale per garantire che i requisiti più importanti siano soddisfatti.

Ho già una domanda in questo senso, quindi non è così raro. A mio parere l'unica risposta corretta è in questo senso:

Qualcuno ha sbagliato da qualche parte per arrivare qui, ora ne trarremo il meglio organizzando un incontro di emergenza e vedremo cosa è possibile invece di ciò che non lo è.

Sapere che fallirai e farlo comunque sarebbe la risposta sbagliata. Se non può essere fatto, non può essere fatto. Eppure ti imbatterai spesso in situazioni che sembra ti chiedono di fare l'impossibile.

La chiave assoluta qui è trovare ciò che è possibile e lavorare da lì. Questa non è una domanda sull'ingegneria del software hardware. Questa è una domanda su come gestire le aspettative, affrontare gli imprevisti e tenere insieme un progetto.

Significa anche che stanno cercando più di qualcuno che si limita a scrivere codice. Stanno cercando qualcuno con un soffio di capacità manageriali o almeno stanno scoprendo se hai quelle. Perché indipendentemente dalla risposta che dai loro, come dai loro la risposta gli dirà molto su come pensi ai progetti.

Un possibile follow-up potrebbe essere (o come domanda da parte loro o come risposta da parte tua se si aspettano risposte lunghe) come gestire le ricadute e ridurre le possibilità che accada di nuovo.

Quindi c'è una scadenza ed è impossibile rispettarla. Qualunque cosa tu risponda, qualunque cosa tu faccia, una cosa che non accadrà è il rispetto della scadenza. Ecco cosa potete fare tu e il tuo manager:

1. Informa il tuo manager il prima possibile per dargli una possibilità di ridurre al minimo il danno. Mancare una scadenza con un danno finanziario di $ 10.000 è molto meglio che mancare una scadenza con un danno finanziario di $ 100.000.

2. Non farti prendere dal panico, calmati e calma tutti gli altri. Sul serio. Ho visto adulti svolazzare come polli senza testa in quelle situazioni. Ho fatto lo stesso una volta quando ero molto più giovane e ho imparato da quello. Ora so che invece di sbattere le ali e non fare nulla, cambi il problema nella tua mente da "Come faccio a rispettare una scadenza che è impossibile rispettare" a "Come minimizzo il danno".

3. Il metodo che non funziona è cercare di affrettarsi o cercare di aggiungere più persone. Ciò che aiuta è convincere le persone a fare cose secondarie. Ad esempio, se devi scrivere codice e provarlo, scrivi il codice e qualcun altro lo prova. Un altro metodo che il tuo manager può utilizzare è migliorare la tua capacità di lavorare più ore. C'è un bell'albergo a 100 metri dal mio posto di lavoro. Posso fare più ore se il mio capo paga per me per stare in quell'hotel e ordina che cibo sano arrivi all'ora di pranzo e cibo più sano arrivi alle 17:00. In un'occasione, qualcuno doveva essere a casa mia per ricevere una consegna di mobili. Lo ha fatto la moglie del mio capo. Non era felice, ma il mio capo aveva bisogno che lavorassi. Questo genere di cose è anche abbastanza motivante.

4. Esistono due metodi ovvi per finire prima: ridurre la qualità e ridurre le funzionalità. Questo deve essere discusso.

5. Esiste un metodo ovvio per rispettare una scadenza che le persone spesso dimenticano (perché vedi il punto 2): spostare la scadenza. Pochissime scadenze sono inamovibili. Guarda il metodo ingegnoso di Peter M. Congratulazioni se riesci a farcela. Spesso è più facile negoziare. Probabilmente è fatto uno o due livelli sopra di te. Ma se chiarisci al cliente che non c'è alcuna possibilità che riceva la cosa promessa al momento promesso, può scegliere di estendere la scadenza o di non ottenere nulla.

6. Spero che non si arrivi a questo, ma il primo topo che salta da una nave che affonda ha le migliori possibilità di sopravvivere.

Sento che alcuni degli altri stanno costruendo una versione troppo debole di "scadenza rigida".

Non sono mai stato un PM ma in più di un'occasione ho dovuto dire la verità al CEO quando tutti gli altri, compreso il Primo Ministro che avrebbe dovuto saperlo, tacquero. Abbiamo determinati requisiti legali e quando i requisiti della legge cambiano, dobbiamo cambiare il nostro codice in modo che corrisponda e le scadenze sono stabilite dal governo. La verità era "Quel giorno è già passato".

Ero lì da molto tempo. Sapevo quanto tempo ci sarebbe voluto dal rilascio dell'ingegneria interna alla produzione. Avevo appena esaminato i registri dei test e sapevo quanto tempo sarebbe durato il test. Avevo una stima davvero buona per il numero di elementi rimandati a test non riusciti, ho utilizzato una cifra bassa per il tempo di consegna e una cifra davvero buona per il tempo di ripetizione del test. Ho sommato i numeri e ho detto che avevamo -1 giorni per continuare lo sviluppo. Non ricordo come sia andata la spiegazione di tutto questo (cosa che è avvenuta immediatamente), ma ricordo solo la mia dichiarazione di apertura.

A causa dei limiti del controllo del codice sorgente che prima non interessavano alla direzione, potevamo non ho deciso di abbandonare le funzionalità completate per alleviare il tempo di test in modo che queste cose non potessero essere migliorate.

Sfortunatamente non potevo dire loro quanti giorni potevano realisticamente aspettarsi, quindi non hanno accettato la mia risposta. Ma durante la dimostrazione interna delle funzionalità richieste dalle normative, la direzione della prossima settimana ha chiesto modifiche radicali. Vai a capire.

Abbiamo finito per consegnare con un mese e mezzo di ritardo.

Tra l'incudine e il martello? Mettiti dall'altra parte della roccia e offri al cliente una demo di funzionalità parziale in metà tempo rispetto alla scadenza. Li prenderai alla sprovvista e li trascinerai nella conversazione. Portandoli settimanalmente per discutere quale funzionalità è stata aumentata quella settimana, imparerai rapidamente che i loro requisiti non erano al 100% di ciò di cui avevano bisogno e, nel momento in cui la scadenza si avvicina, potresti avere "qualcosa" che possono usare, anche se è funzionale all'80%, sei molto più avanti rispetto alla concorrenza a cascata.

Prendendo tutto ciò che è stato detto alla lettera, l'opzione migliore è considerare qualsiasi altro lavoro su questo progetto come una perdita di tempo e invece passare al progetto successivo. Che non è la decisione di uno sviluppatore di software.

Questo non accade nella vita reale. Mi sono trovata in situazioni come questa e la soluzione fondamentalmente era dare al cliente quello che voleva vedere. Che è cambiato da dati illeggibili (non del formato giusto ma non intenzionalmente) a dati falsi (dati generati o di test che passano le routine di scrittura) a cose preparate con intervento manuale a esempi di lavoro selezionati a mano per la cosa reale.

Ciò può comportare la collaborazione con la società appaltante per convincere i destinatari a valle a giocare anche al gioco dell'attesa: le cose devono sembrare come se mancassero così poche cose che avrebbe poco senso abortire.

Ho preso subappalti da imprenditori incompetenti con buoni rapporti d'affari e pagando bene dove la priorità principale era tenere sempre il culo coperto, calcolare le scadenze in modo sicuro e produrre materiale funzionante e ben documentato che gli facevi firmare ogni volta dal momento che il progetto di governo era decisamente destinato a un atterraggio di fortuna e tu non volevi essere il capro espiatorio sotto il carrello di atterraggio che crolla.

Questo incendio di spazzatura è stato cancellato circa due anni dopo la morte "dura" dline, molto tempo dopo aver consegnato e ritirato. Questo è il motivo per cui la risposta giusta al fallimento infallibile di una scadenza rigida raramente è rinunciare: alcune scadenze possono innescare sanzioni che si vogliono evitare. Ma le scadenze per eliminare definitivamente un progetto in corso sono rare e la decisione finale potrebbe benissimo cadere in un momento di cui non sei a conoscenza.