it-swarm.it

Responsabile del progetto che desidera bloccare il preventivo con un contratto firmato

In una precedente occupazione, un project manager (PM) non era soddisfatto dei tempi di consegna del codice su un progetto in cui mi trovavo. Mi è stato detto dal mio capo del progetto che il PM stava pensando di farmi firmare un contratto per bloccare le mie stime di tempo Ho dato per le attività e le date di consegna.

La situazione del progetto era che stavamo lavorando con nuove tecnologie, base di codice, standard di codifica e requisiti molto inclini al cambiamento. Stavo imparando cose nuove e applicandole il meglio che potevo sui requisiti che continuavano a cambiare. I requisiti durante le iterazioni sono cresciuti di 2-3 volte, con la mia stima da completare a crescere di circa 5-8 volte. Le uniche cose che non sono cambiate sono state le stime e le date di consegna.

Sì, alla fine ho perso la maggior parte delle scadenze. E stavo lavorando su alcune nuovissime tecnologie sulle quali nessun altro membro dell'intero team di sviluppo poteva davvero dare una mano perché non ne avevano familiarità. Almeno non facilmente.

Mi è sembrato allora che PM volesse che i suoi numeri si sommassero-- e quindi volevo che firmassi un contratto per "garantire" che avrei sempre consegnato il codice di lavoro in tempo. Suppongo che con un contratto firmato il PM potrebbe usarlo contro di me se non potessi consegnare in tempo.

Credo che quello che è successo dopo è stato che altri project manager e/o project leader mi hanno difeso, e non hanno permesso che ciò accadesse.

La mia domanda è: questo dovrebbe sollevare una bandiera rossa sul gestore? È pratica comune per un manager bloccare le stime dei tempi di uno sviluppatore di software con un contratto firmato? O in questo caso, prova a.

Nota, ero un dipendente a tempo pieno, non un consulente indipendente.

Aggiornamento: voglio aggiungere che ho dato nuove stime settimanalmente, ma sembra che le stime originali e le date di consegna siano state le PM fissato su.

116
spong

La mia domanda è, dovrebbe sollevare una bandiera rossa sul manager?

. Significa che è tempo di aggiornare il tuo curriculum/CV e iniziare a cercare un nuovo lavoro. Oppure significa che il tuo manager sta per iniziare a giocare a giochi molto cattivi con te.

È prassi comune per un gestore bloccare le stime dei tempi di uno sviluppatore di software con un contratto firmato?

Non ho mai sentito parlare di questo essere applicato a un dipendente.

La stima del tempo e dello sforzo è sempre difficile. Soprattutto perché la nostra professione è piena di eccessivo ottimismo. Esistono alcuni sistemi di stima che potrebbero aiutare con le stime in futuro, ma devono raccogliere statistiche storiche da te stesso. Uno è PSP . Un altro è Punti funzione . A molti sviluppatori non piace nessuno dei due e troverai opinioni molto forti su entrambi.

La principale difficoltà nella stima dei tempi e degli sforzi è la mancanza di feedback nella nostra euristica di stima. Una delle chiavi è scrivere ciò che pensi sia la stima e quali parametri hai usato per stimarla. Quindi, in base a ciò che effettivamente fai, confrontalo con quello che pensavi di fare. E usalo per modificare i parametri di stima. In ingegneria, lo chiamiamo " feedback ."

109
Tangurena

Sì, dovrebbe assolutamente suonare un campanello d'allarme.

Se fossi stato nella posizione, per il mio intrattenimento personale, avrei chiesto al gestore di firmare un contratto che congelasse tutti i requisiti. Immagino che il manager probabilmente salverebbe. Poi me ne andrei.

160
whatsisname

Bene questo è semplice. Devi solo dire al tuo manager che firmerai per bloccare il tuo tempo stimato quando firmerà per bloccare le specifiche. Perché non puoi, di sicuro fornire eventuali stime per qualcosa che è sconosciuto. Specifiche complete del progetto prima di iniziare, nessuna modifica - e puoi finirlo in tempo :)

Una modifica al contratto spec => è nulla. Probabilmente la cosa sarà nulla dopo 10 minuti il ​​tuo primo giorno :)

59
Slawek

Sì, questa è una bandiera rossa. Ciò che ti dice è che il gestore non capisce come gestire i rischi nei progetti software. Quello che dovrebbe fare è capire che cosa ha causato esattamente il ritardo in primo luogo e quindi iniziare a strumentare un processo per gestire efficacemente i rischi di pianificazione che inevitabilmente si verificano durante un progetto software.

MAI in nessun caso firmerei un contratto con il mio manager che garantisca un programma. Altri hanno menzionato di avergli firmato un lock-in sulle specifiche. Questo secondo me non è sufficiente. Ciò non tiene conto di difficoltà impreviste con gli strumenti o la tecnologia, la progettazione incompleta o scadente, le prestazioni degli altri membri del team, ecc.

31
Pemdas

Questa non è una bandiera rossa, questa è una stupidità da armi.

Se le stime e le scadenze vengono costantemente saltate, la cosa razionale da fare è identificare le cause e migliorare i processi.

Se dai la colpa e dai un calcio al cavallo perché non sai dove stai andando, non essere sorpreso se il cavallo ti morde e scappa!

27
Steven A. Lowe

Mentre il direttore era in linea con la sua richiesta. Non è completamente da biasimare. Se lavoravi in ​​un territorio completamente sconosciuto, non c'è niente di sbagliato nel dire "Non lo so". Mi ci è voluto un po 'di tempo per capire che "Non lo so" è una risposta perfettamente accettabile, quindi so quanto punge per pronunciare quelle parole. Ma se davvero non lo sai, questa è la risposta. E se si oppongono a quello chiedono loro di darti una stima di quanti penny ci vorranno per fare una pila alta quanto la Sears (rendila Willis) Tower. E sarebbero disposti a firmare un contratto pagandoti ogni centesimo che avevano spento?

Qualsiasi Project Manager che valga il suo stipendio dovrebbe sapere che alcune cose non si adattano bene a Nice in un foglio di calcolo. A volte le cose sono fatte quando sono fatte. Penso che tu stia andando bene facendo progressi su quanto hai fatto. Basta smettere di dare gli aggiornamenti numerici.

Un altro esercizio è quello di suddividere il grande compito in unità più piccole e più stimabili. Questo esercizio ti aiuterà a capire meglio anche quello che devi fare. Consulta le stime del software di Steve McConnell e gli schemi di requisiti software di Stephen Withall per suggerimenti sulla suddivisione dei compiti e sulla scoperta di requisiti nascosti, rispettivamente.

Non sparare dall'anca su un preventivo. Prenditi il ​​tempo per scomporlo. Stimare un gran numero di piccole attività ti darà una migliore stima complessiva (a causa della legge delle medie alcune delle tue stime saranno sotto ma alcune saranno finite e tenderanno a pesarsi) del grande compito.

19
Michael Brown

Chiedi al tuo "project manager": stiamo vendendo software o scadenze?

14
ThomasW

Sono un project manager e un programmatore :-) Potrei andare avanti a lungo su come la maggior parte dei PM provengono dall'esterno del settore e non riesco a gestire tutto ciò che non si adatta bene a un modello di linea di produzione ... ma io no, non qui. Invece ecco una lunga polemica su cosa fare realmente (Mr Mod, se è troppo lungo fai quello che vuoi con esso). Sono d'accordo con i commenti già fatti qui, alcuni che dovresti fare prima di altri, ma ecco cosa penso che sarebbe stata la tua prima mossa. Oh, e la risposta ovvia alla tua domanda è sì, ma è elaborato in un linguaggio colorato e dettagliato di seguito.

Prima di iniziare, però, nota che il PM molto probabilmente ti sta dando dolore, perché qualcun altro più in alto nella catena alimentare sta dando loro dolore. Loro (noi) siamo semplici creature ... Ci sono modi per evitare la situazione che hai descritto - Mike Brown lo copre abbastanza bene. Non c'è niente di sbagliato nel spostare qualcosa per 3/4/5 .. ore prima di dare il via (in realtà tutti i tipi di allarmi devono spegnersi se questo non lo fa Non succede.) E se stai andando in un territorio sconosciuto, fai un passo indietro e chiedi una settimana di ricerca nell'area e alle tecnologie per essere in grado di fare una stima sensata (ti consigliamo di farlo correttamente perché vuoi che le nuove tecnologie imparino e giocare con te no?). Se il tuo PM e la direzione nel posto in cui ti trovi non lo capisci ... quindi aggiorna il tuo curriculum e cerca l'uscita più vicina, lasciandoli al destino che meritano così tanto. Che il PM penserebbe persino di convincere un dipendente a tempo pieno a firmare un contratto del genere è un brutto segno n ... l'unico modo in cui ho potuto vedere che loro potrebbero non essere totalmente incompetenti è che stavano davvero giocando a giochi mentali con il capo del tuo progetto e tu (da quello che ho letto non te l'hanno messo direttamente, e alla fine non hanno seguito la minaccia). Il PMing dopo tutto è un paradiso per il tuo psicopatico aziendale standard. È stato positivo che gli altri ti abbiano preso in giro per quello che hai detto, quindi i consigli che seguono sarebbero probabilmente è risultato positivo per te alla fine. Immagino che avrebbero avuto una rivoluzione nelle loro mani se si fosse rivelato più che parlare.

Quindi alla situazione attuale/buco che hai descritto, perché accadrà di nuovo a qualcuno, da qualche parte (come circa 5 minuti fa, e di nuovo in altri 5, scheduleRepeat ()). Probabilmente senza la stupidità del contratto, ma la trama di base è sempre la stessa. Organizza un incontro (!), A loro piacciono gli incontri ;-) Alla fine tutti possono darsi una pacca sulla spalla come se fosse stato fatto qualcosa. IMPORTANTE: Assicurati di includere il capo del progetto tecnico/il capo squadra/l'architetto/il responsabile della progettazione nell'invito alla riunione che abbia già esaminato il problema con loro e li abbia presi in considerazione. Più in alto nella gerarchia puoi scegliere qualcuno dalla tua parte, meglio è. Perché il tuo PM lo vedrà e proverà ad abbinare il tuo design manager con un equivalente. In caso contrario, sono stupidi e hai già vinto. Che di per sé li riporta generalmente in linea , perché ora sono visibili a qualcuno che probabilmente li può licenziare sul posto. Se stanno giocando con te, ti è permesso di restituire il favore.

Durante l'incontro, esamina i dettagli tecnici di ciò che stai trattando e del perché impiega il tempo necessario. Dovrebbero volerlo sapere (e come possono aiutarti a farlo), ma il fatto triste è che generalmente ciò non accade ... probabilmente avrai 10 minuti prima che i loro occhi tornino nella loro testa. Ora quello che vorrei fare qui probabilmente non è legale ... sì, ho controllato, in realtà è altamente illegale e non vuoi andare in prigione per così tanto tempo. Il punto è che hai fatto del tuo meglio per essere proattivo e se hai presente alcuni alti, il tuo dolore ora è loro ... come dovrebbe essere. Dovrai usare il tuo giudizio su come potrebbero andare le cose, perché "l'escalation" è ciò che accadrà. Se la leadership nel posto in cui ti trovi è per metà decente, faranno la cosa giusta e faranno anche la cosa giusta da te. In caso contrario, avresti avuto il tuo curriculum in anticipo sul mercato ... saresti comunque partito alla prima occasione (e sembra che alla fine lo hai fatto). La leadership si dividerà in due gruppi: o sono tecnicamente esperti e vedranno immediatamente il tuo punto di vista; o non lo sono e cosa faranno al di fuori del sorriso e sopportarlo? Se potessero fare quello che fai, lo farebbero già.

Mantieni il problema dei requisiti in evoluzione come carta vincente da utilizzare alla fine ... servirà come uscita per tutti. Il progetto stesso e il maledetto cliente/stakeholder avranno il loro nome preso invano. Il modo più indolore di procedere sarebbe che si verifichi una sorta di reset sul progetto, e forse che PM sarebbe riassegnato tranquillamente a un'area diversa. I miracoli accadono di tanto in tanto. Se il problema del contratto fosse sollevato nell'incontro dal Primo Ministro, poi ha risposto con i requisiti congelando la domanda di contro-contratto - per quanto mi riguarda hanno già bruciato i loro ponti con te e con l'intero team di sviluppo, quando hanno iniziato a giocare a quel tipo di mente Giochi.

Prima di firmare: Cambiare ambito/requisiti: uno dei migliori motivi per adottare la metodologia Agile, quindi i clienti/le parti interessate sono adeguatamente responsabili di cambiare idea su ciò che vogliono ...

Oh, un'altra cosa: sull'affermazione "Non lo so", è sempre stato il mio punto di riferimento personale su come valutare il valore di un collega tecnologo o membro in uno dei miei team di progetto. Trovo le uniche persone che sono in grado di dire che direttamente sul tuo viso sono le migliori che ci siano, principalmente perché qualcuno che sa di essere fuori dalla profondità non lo dirà mai - le apre ad essere chiaramente esposto da qualcuno con abilità reali in un battito cardiaco. D'altra parte, qualcuno che si schiererà e lo dirà, avrà anche un piano di base (anche se non è stato pensato attraverso) su come affrontare le incognite in modo che tra 24 ore ci sia una risposta più utile, e in una settimana ancora migliore. Quando l'Apollo 13 stava volando intorno al lato oscuro della Luna, accadde un intero gruppo di "Non lo so". Se non riesci a gestire questo genere di cose, stai facendo un gioco sbagliato.

10
nomaderWhat

Sì, questo dovrebbe sollevare una bandiera rossa, soprattutto se sei un dipendente a tempo pieno. Quali erano le condizioni del contratto? Saresti effettivamente licenziato se avessi mancato le scadenze? O ti perderesti un bonus? Cosa farebbero?

La bandiera che questo solleva è che il manager non ha idea di come gestire un progetto che si occupa di tecnologie nuove/non familiari e che sposta i requisiti che incidono direttamente sullo sforzo stimato. Mentre a volte si verificano scadenze rigide, un manager che conosce la situazione non dovrebbe cercare di convincere i dipendenti a firmare contratti per farli rispettare. Le ore tardive e i periodi di crisi saranno male, ma è probabilmente la norma. E ancora a volte la scadenza scade. Succede, e come è stato pubblicato da qualcun altro, l'unico modo per attenersi al programma è congelare i requisiti PRESTO SU in modo che ci sia ancora abbastanza spazio per mantenere la sequenza temporale.

Da quello che hai detto, le campane di allarme sono in ritardo di qualche mese. Normalmente è rischioso basare un progetto sensibile al tempo su tecnologie che il personale non conosce già. È insensato farlo se non si ha la conoscenza della raccolta dei requisiti e della gestione dell'ambito.

Detto questo, sono d'accordo con le altre risposte. Inoltre, potresti voler aggiornare il tuo curriculum se non l'hai già fatto.

8
Larry Coleman

Proprio come tutti gli altri intervistati, non potrei essere più d'accordo sul fatto che questo dovrebbe sollevare una bandiera rossa.

Sembra che il PM non vuole essere coinvolto nel processo di sviluppo.

Nella mia pratica personale mi sono allontanato da molto tempo dal trattare con specifiche anticipate dettagliate, firme, stima completa del progetto o prezzi a offerta fissa (dal punto di vista della consulenza).

La ragione di ciò è la realizzazione, di cui parlano molti guru di Agile e Lean Software, che il software non è un'entità fabbricabile fissa, ma è principalmente un processo di scoperta.

Molte persone hanno ancora problemi con questa nozione, e sembra che il tuo PM. Si tratta di una semplice comprensione dei compromessi.

Specifiche rigide e stime fisse funzionano per sistemi in cui il costo del cambiamento è elevato. Come costruire un grattacielo. Se hai dimenticato di specificare i pozzi degli ascensori in avanti, sarà davvero difficile adeguare l'edificio una volta che è stato installato. L'elevato costo del cambiamento richiede molta pianificazione iniziale, l'apprendimento delle incognite di componenti e tecnologie e la sperimentazione iniziale. Solo una volta che hai fatto tutti questi compiti, puoi stimare budget e costi.

Nel software le persone si sono abituate molto all'idea che il costo del cambiamento è basso, e quindi amano trarre vantaggio dal fatto di poter cambiare le cose una volta che vedono un rilascio, incorporare una nuova comprensione dell'applicazione, del business, del cliente su una base permanente. Tutto questo è buono e un'enorme opportunità se sfruttato correttamente. La maggior parte delle persone di software con cui ho incontrato e con cui ho lavorato in realtà non ama passare molto tempo a pianificare o investigare; la maggior parte di noi (inclusi i PM) desidera vedere una trazione continua. È qui che è nato lo sviluppo iterativo con le sue piccole versioni incrementali di funzionalità. Esistono altre pratiche che possono essere utilizzate, come lo sviluppo guidato dai test per garantire che il costo del cambiamento rimanga basso e che il debito tecnico sia contenuto.

La realizzazione di questo lavoro implica un "contratto" tra le due parti, il proprietario del prodotto (Agile parla per il tuo PM o clienti o team QA) e gli sviluppatori. Gli sviluppatori accettano di lavorare solo su cose a cui è stata data la priorità come la cosa più importante per la data iterazione e per non prenderla per sempre, ma si sforzano di rilasciare blocchi di funzionalità completamente integrati frequentemente (ad esempio settimanalmente o mensilmente). I proprietari dei prodotti, al contrario, accettano di rivedere continuamente le versioni incrementali e fornire un feedback rapido. accetta anche di stabilire le priorità per la prossima iterazione e una volta impostato per non cambiare idea per la durata dell'iterazione.

Quest'ultima parte dell'accordo è qualcosa che il tuo PM probabilmente non capisce. Molti PM tradizionali in realtà non lo fanno. Alcuni di loro pensano che il loro lavoro sia finito quando abbandonano le specifiche; non voglio conoscere problemi, alternative, modi migliori, ecc. Il rovescio della medaglia è che questo non solo contrasta il flusso di sviluppo del software, ma danneggia anche l'organizzazione lasciando molte opportunità sul tavolo.

Dai un'occhiata al Manifesto Agile: http://agilemanifesto.org/ Potrebbe risuonare con te. Un buon libro da leggere è anche "Lean Software Development" di Mary Poppendieck

In bocca al lupo.

4
Wolfram Arnold

Sembra che il manager stia cercando qualcuno da incolpare quando riferisce al suo superiore.

Trovo che se hai un manager irragionevole che pensa che una "stima" sia la stessa di un "periodo fisso", la cosa migliore da fare è pensare a un periodo di stima molto generoso e poi raddoppiarlo!

Inoltre, forzare il manager a garantire che i requisiti siano completamente dettagliati e fissi. Eventuali modifiche da quel momento in poi non verranno affrontate senza una "rinegoziazione formale" con il project manager del nuovo tempo di completamento.

Alla fine il project manager ottiene l'idea e pianifica di conseguenza.

4
martinws

La mia esperienza personale con questo genere di cose è che il project manager sta cercando di creare una scia di carta per sbarazzarti di te rendendo la tua risoluzione colpa tua. Ciò renderebbe una bandiera molto rossa. Il chilometraggio può ovviamente variare leggermente.

2
PSU

Buone risposte, ma lasciami aggiungere i miei 2 centesimi.

Se studi mai la probabilità, esiste una "variabile casuale". Questo è un numero di cui non conosci il valore, ma puoi descrivere il tuo non sapere con una distribuzione, come una normale distribuzione (curva a campana) o un'altra.

Il punto è che il lavoro richiederà un certo periodo di tempo, ma qualsiasi stima precedente sarà errata, di un po 'o molto, sul lato negativo o positivo, quindi c'è il rischio e qualcuno deve assumersi il rischio. Generalmente, se le persone corrono rischi, vengono pagate per questo. L'assicurazione costa denaro.

Quando ero un consulente, di solito avevo la possibilità di firmare un contratto di tempo e materiali rispetto a un contratto a prezzo fisso. Con tempi e materiali il cliente si assume il rischio. Con il prezzo fisso, sopporto il rischio. Con il prezzo fisso, costruisco un margine di sicurezza, perché se non riesco a raggiungere l'obiettivo, nessuno vince.

Chiederti di impegnarti a una data di consegna fissa, soprattutto senza requisiti fissi, sembra come provare a trasferire il rischio a te, anche se non è chiaro cosa stai effettivamente rischiando. In ogni caso, una risposta è semplicemente quella di mettere un margine di sicurezza davvero generoso.

Post scriptum Lo vedi sempre con contratti governativi. C'è una richiesta iniziale per le proposte, le offerte vengono fatte, viene accettata un'offerta bassa e quindi iniziano le richieste di modifica, quindi i palloncini dei costi e l'appaltatore vengono incolpati. Le cose funzionano molto meglio se esiste una relazione di lavoro di squadra tra cliente e appaltatore, piuttosto che una contraddittoria.

1
Mike Dunlavey

"Camminare sull'acqua e sviluppare software da una specifica sono facili se entrambi sono congelati".

-Edward V. Berard

Se i tuoi requisiti cambiano, è irragionevole aspettarsi che le tue stime iniziali siano accurate. Sì, questa dovrebbe essere una bandiera rossa.

0
Bill the Lizard

Sì, ovviamente questo solleva una bandiera sull'esperienza e la competenza del tuo ex capo. Sì, come suggerito dalla maggior parte delle persone, sarebbe un buon momento per aggiornare il tuo CV.

Sì, come affermano le altre risposte, nella maggior parte dei casi non vorrai firmare tale accordo. Tuttavia, voglio suggerire che potrebbero esserci alcune situazioni in cui potresti prendere in considerazione l'idea di firmarlo.

La maggior parte degli sviluppatori e dei manager sono consapevoli del costante attrito tra funzionalità, scadenza e budget. Molti nominerebbero anche la qualità come quarta dimensione ("Sono in grado di soddisfare qualsiasi serie di requisiti desiderati, entro domani per un budget ridotto, purché tu sia disposto ad accettare che non funzionerà!")

Ma c'è ancora un'altra dimensione: il rischio. Se devo solo consegnare con successo il 50% delle volte, posso abbassare immensamente le mie stime; sono imbottiti per gestire un tasso di consegna molto più elevato.

Siamo in grado di affrontare il rischio in vari modi (e le stime del riempimento sono uno di questi). Il gestore non è disposto ad accettare alcun rischio e desidera metterlo a rischio. Normalmente, dovresti rifiutare una simile mossa ... a meno che tu non sia ben ricompensato.

Se sei in grado di nominare la tua scadenza, con una quantità reciprocamente accettabile di riempimento per far fronte a ritardi imprevisti, e sei in grado di negoziare un bonus (molto grande) se lo colpisci, e sei in una posizione finanziaria per essere in grado di gestire il penalità (es. licenziamento) se non ci riesci, potresti scoprire che vale la pena "accettare" quel rischio e firmare il contratto - con clausole adeguate per gestire le modifiche ai requisiti.

0
Oddthinking

Dico mettiti nei suoi panni e cerca di capire cosa l'ha motivato. Dal potenziale manager/contabile hanno bisogno di un numero per giustificare ciò che sta accadendo e come stanno andando le cose.

Potrebbe essere che essere ridicolizzato nella sala riunioni per aver spostato le scadenze, mancando troppe scadenze, ha provato il modo più semplice possibile per bloccarle. Dammi un numero e firma qui! Essendo dall'altra parte, avresti potuto solo percepire che è qualcosa contro di te. Tuttavia, fare stime e continuare a rendersi conto che devono essere adeguati è ciò che gli è più utile. Se capisci cosa ha motivato la richiesta e qual è il vero problema che sta affrontando, potresti essere in grado di aiutare lui e te stesso. Come programmatori risolviamo i problemi. Questo non è diverso, capire e risolvere il suo problema e sarà il tuo migliore amico. C'è così tanto lavoro da fare che nessuno ha il tempo di tracciare una vendetta personale! Ha bisogno di aiuto con il suo lavoro, la soluzione più semplice era quella di avere qualcuno che firmasse un documento! Probabilmente lo ha ottenuto da un libro di gestione per manichini, "Fai firmare i tuoi lavoratori ed essere responsabile per un numero." Divertente ma triste

0
Arjang

Questa è una stupidità diretta. Non so quale fosse l'obiettivo finale, ma ogni project manager a metà decente responsabile dei prodotti software dovrebbe essere consapevole che le stime sono esattamente quelle che vengono chiamate: stime. Non sono promesse e non possono essere fatte senza svuotare lo sviluppatore di software di tutta la loro energia o costringerli a mantenere la loro "promessa" comunque.

Se vuoi dimostrare quanto sia ridicolo un contratto del genere, ecco due suggerimenti:

a) Altamente sopravvalutato al punto in cui il progetto impiega cinque o dieci volte il tempo che si stimerebbe senza un contratto. Se il responsabile del progetto chiede perché le stime sono così alte, dite semplicemente che vi state solo assicurando di poter adempiere al vostro contratto.

b) Questo è già stato suggerito: chiedi un contratto che assicuri che non cambi un singolo requisito e assicurati che ciò includa la correzione degli errori di ortografia. Nella mia esperienza non esiste un singolo progetto software in cui i requisiti non cambiano ad un certo punto durante lo sviluppo. È più probabile che il project manager debba rompere il contratto di te.

Se il project manager accettasse qualcuno di questi due suggerimenti, sapresti per certo che sono fuori di testa.

A proposito, come funzionerebbe comunque un contratto per un dipendente a tempo pieno? Non conosco le normative sul lavoro in altri paesi, ma come dipendente a tempo pieno in un'azienda non credo che qualcuno potrebbe costringerti a firmare un contratto vincolante per rispettare una scadenza e avere un caso valido. Certo, potrebbero darti un inferno se non rispetti la scadenza, ma non hanno bisogno di un contratto per quello. Nessuno potrebbe licenziarti o darti meno soldi. Potrebbero tagliare il bonus concordato nel peggiore dei casi. Quindi, a meno che non sia diverso in altri paesi, questo sembra più una minaccia vuota di qualsiasi cosa dovresti prendere sul serio.

0
Anne Schuessler

Ho intenzione di andare contro il grano qui.

La situazione che descrivi non è poi così insolita a livello di Engineering team, specialmente a seguito di un progetto/rilascio particolarmente tardivo. In molte situazioni, la direzione e l'intera organizzazione potrebbero in effetti avere registrato per una data di rilascio particolare e altre parti dell'organizzazione saranno orientate per quella data. Può esserci un'enorme pressione sulla catena di gestione per raggiungere quella data.

È qui che entra in gioco un processo di ingegneria generale. Probabilmente hai sentito parlare del modello a cascata. Esistono altri modelli, ma l'obiettivo finale di tutti loro è quello di fornire costantemente qualcosa quando è previsto e contenente cosa è stato concordato. Specifiche funzionali, progetti, elenchi di attività, ecc. Contribuiscono a rendere questo processo prevedibile. La comunicazione, l'analisi dei rischi e (come hai detto) aggiornando regolarmente le aspettative sulla pianificazione riducono le sorprese e rendono disponibili le informazioni il prima possibile in modo da poter adattare i piani. E sì, ci dovrebbero essere adattamenti al piano ogni volta che vengono aggiunte o rimosse funzionalità.

In alcune delle squadre con cui ho lavorato, non esiterei a trattare le mie stime come impegni firmati, ma ciò riflette la qualità delle squadre e della direzione, e non una particolare abilità nella stima. Un team che è disposto a firmare un contratto per la consegna in tempo è un indicatore di un team ben funzionante, non un bandiera rossa.

0
TREE