Tieni presente che l'OP nelle domande che hai collegato ti è stato detto che non aveva un rendimento e che gli è stata data la possibilità di riscattarsi. Sulla base della stessa ammissione del PO, si è rifiutato di fare il lavoro e invece si è concentrato sul refactoring anche dopo la scadenza e il punto di essere in grado di riscattare. È un po 'come se tu assumessi un imbianchino per dipingere la tua casa e lui sta demolendo il compensato, cambiando i tubi e facendo di tutto tranne che dipingere. Gli diresti che vuoi che dipinga ma lui rifiuta e continua a fare questi cosiddetti lavori di "preparazione della pittura". Vorresti che quella persona continuasse a "dipingere" la tua casa? Sembra che non ti sia stato detto questo.

Potrebbe essere che il tuo capo capisca che è una cosa difficile da modificare. Essendo un team composto da un solo uomo, è chiaro che incapperai in bug ed errori, forse anche di grandi dimensioni.

In tutto non direi al tuo capo che stai ottenendo risultati inferiori. Parla con lui delle aspettative e se le stai soddisfacendo. Parla anche della difficoltà di gestire il codice e del fatto che stai dedicando tempo al refactoring.

Penso che l'approccio migliore sia essere onesto con il tuo capo e dirgli che la base di codice deve essere riformattata per essere facile da gestire in futuro.

Una comunicazione aperta e onesta è tuo amico qui.

La buona notizia è che hai ricevuto buone valutazioni delle prestazioni in passato e non hai sentito nulla di diverso nel frattempo. Anche se i manager non sempre si elogiano quando le cose stanno andando bene, di solito saranno piuttosto bravi a farti sapere quando vedono un problema. Il fatto che il manager non ti abbia detto nulla è un buon segno che stai almeno soddisfacendo le aspettative.

Detto questo, non c'è niente di sbagliato nel chiedere un feedback. Organizza un incontro con il tuo manager e chiedi una valutazione onesta di come stai. Non dire loro che senti che stai ottenendo risultati insufficienti (non c'è alcun vantaggio in questo), ma chiedi loro cosa pensano che potresti fare meglio. I manager amano i dipendenti che sono proattivi riguardo al miglioramento personale. Sii pronto a ricevere critiche, non è sempre facile, ma ricorda che lo stai facendo in modo da poter essere un esecutore migliore ai loro occhi.

Per quanto riguarda le stime mancanti a causa di un debito tecnico imprevisto, succede . Affrontare l'ignoto arriva con il territorio in questa professione. Con l'esperienza migliorerai nel prevederlo e incorporarlo nelle tue stime. La chiave è essere onesti e fornire aggiornamenti regolari su ciò che stai facendo, quali sfide stai affrontando e perché ci vuole più tempo di quanto pensassi. Le stime mancate sono fastidiose per un manager, ma la maggior parte dei manager vuole solo sapere cosa sta succedendo in modo da poter pianificare al riguardo. È molto peggio per un manager essere colto di sorpresa da una scadenza mancata perché non sapeva che avessi problemi.

Quindi, se l'implementazione di qualcosa richiede più tempo di quanto si pensasse inizialmente perché la base di codice è un terribile pasticcio, sii in anticipo. Comunica cosa intendi fare al riguardo e mantieni il tuo manager aggiornato su come sta andando. E se devi affrontare una decisione tra una soluzione rapida che si aggiunge al debito tecnico o impiegare molto tempo per risolverlo nel modo giusto, presenta queste opzioni al tuo manager e lascia che sia lui a prendere la decisione. Questo è ciò per cui vengono pagati.

Per il progetto in corso ho dato una stima al mio capo e non posso trattenerla, ancora una volta. Ho lasciato progetti simili su questa app incompiuti , perché sono passato ad altri.

Se per "incompiuto" intendi che tu abbandonato alcune funzionalità richieste prima di implementarle perché non riuscivi a farle funzionare, dovresti parlarne con il capo.

Sarebbe meglio per il tuo ego e meglio per il cliente se scegliessi piccoli cose che puoi fare e implementarle. Mentre lo fai, migliorerai e il cliente otterrà un prodotto sempre migliore.

Scegli alcune cose che puoi fare, vai dal tuo capo e ottieni il consenso per quelli che saranno i prossimi deliverable e consegnare. La tua morale / fiducia aumenterà.

Lascia che ti dia un POV diverso. Sono stato CEO di 2 aziende di successo (non sicure per la salute), quindi voglio esprimere la mia opinione come se fossi un mio dipendente.

La mia azienda è mia figlia e i migliori dipendenti sono quelli che dimostrano prendersi cura della mia azienda e che sono davvero felice di creare un team affiatato. Ricordalo sempre quando vuoi parlare con il tuo capo, non concentrarti su te stesso ma guarda il quadro più ampio.

Il meglio che un dipendente nella tua posizione potrebbe fare se fossi il capo a cui è rivolto me e parlare onesto. Non blaterare dei suoi sentimenti, ma parlare onestamente della sua performance rispetto all'azienda.

L'hai azzeccato abbastanza bene

Sono l'unico a lavorare su un grande app, in winforms, con cui non ho molta familiarità, con molto debito tecnico (dato che non c'è un singolo pattern implementato, tranne che per singleton) e sto cercando di far funzionare una cosa semplice (come in Drag&Drop, implementare un nuova griglia, ..).

Cerco di mettere insieme il codice distribuito e di astrarlo, ma questo richiede tempo e ha già introdotto un bug imbarazzante. Per il progetto in corso ho dato un preventivo al mio capo e non posso trattenerlo, ancora una volta. Ho lasciato progetti simili su questa app incompiuti, perché sono passato ad altri.

Questo mi lascia con la sensazione che non sto aggiungendo (abbastanza) valore all'azienda, poiché altri progetti più piccoli stanno diventando fatto. Sono pronto ad affrontare il mio capo con questa sensazione e ammetto che potrei non essere qualificato per farlo da solo

Vai dal tuo capo e dì questa riga esatta aggiungendo che l'intero argomento è correlato all'azienda e al team che ti piace e che desideri fortemente avere successo.

Hai detto che il tuo è un buon capo, quindi sono abbastanza a mio agio nel darti questo consiglio. Sii onesto e dai al tuo capo la possibilità di scegliere il meglio per l'azienda senza mettere i tuoi amici e il tuo capo in una posizione fastidiosa per una preoccupazione egoistica. Pagherei il doppio dello stipendio per un dipendente che, sono sicuro, può perseguire se stesso ed essere onesto per il bene dell'azienda.

Ci vuole tempo per astrarre il codice, ha introdotto un bug e nessuno ti ha chiesto di farlo. Quindi devi considerare perché pensi che sia importante? Cosa aggiunge al progetto? È davvero necessario?

In passato, ho visto molte persone avere una grande tentazione di fare questo tipo di "lavoro impegnato" quando non sanno come fare Dovresti fare. Ma almeno se lo rifattorizzano, deve migliorare e forse allora la soluzione cadrà nelle loro ginocchia.

Se hai solidi motivi per il refactoring, portali al tuo capo, spiegagli perché pensa che il codice abbia bisogno di refactoring ed è per questo che stai adottando questo approccio, ma ci vorrà più tempo. Se è d'accordo, saprà cosa stai facendo e perché ci vuole tempo e dovresti stare bene. Se non è d'accordo, almeno riceverai indicazioni più specifiche da lui.

D'altra parte, se scopri che stai rifattorizzando il codice "solo perché", allora devi assolutamente fermarti. Dici che stai cercando di aggiungere cose semplici come implementare una nuova griglia, ma il problema è che non riesci a trovare dove aggiungerla? Che provi ad aggiungerlo e non funziona? Chiarisci quali sono i problemi su quella correzione, quindi portalo al tuo capo. Avere strategie per un incontro del genere va bene, ma se hai davvero bisogno di chiedere aiuto, allora vai a chiedere aiuto. Ma assicurati di poter dettagliare ciò che hai provato e quali sono stati i risultati.

Le cose non sono necessariamente male :)

ha già introdotto un bug imbarazzante.

Non ci sono bug imbarazzanti. Tutti commettono errori: è normale. Quello che puoi fare è provare a scrivere quanti più test possibili (unità, funzionalità, integrazione, ecc.). Questo non impedirà i bug, ma dovrebbe ridurne il numero.

Ho dato una stima al mio capo e non posso tenerla, ancora una volta.

Da questo Posso concludere che sei un giovane ingegnere. Forse dovresti lavorare sulle tue capacità di stima. Per una migliore stima, è necessario avere una certa esperienza. Inoltre, puoi provare il metodo di stima di monte carlo.

Se non sei sicuro dei tuoi progressi o delle tue prestazioni, puoi sempre chiedere al tuo capo cosa ne pensa, ma senza menzionarlo che pensi sia un male.

È positivo essere autocritici, perché solo così puoi davvero migliorare te stesso. Ma non lasciarti ingannare dal fatto che hai prestazioni basse. Se il tuo manager non è soddisfatto della tua performance, te lo dirà.

Detto questo, una gigantesca bandiera rossa qui è che ti mancano le stime. Quando perdi un preventivo, devi sapere perché. Quindi elimini il perché o lo prendi in considerazione nella tua prossima stima. Se ti manca a causa del refactoring, questo è un problema. Il problema non è che stai refactoring, ma piuttosto che il refactoring non viene calcolato come parte della stima.

Quindi ti consiglio di non discuterne affatto con il tuo manager. Non dargli un motivo per cercare un motivo per cui hai prestazioni basse !! Invece, fai la cosa professionale: impara dal passato e incorporalo nel tuo futuro. E il primo modo per farlo abbastanza facilmente è assicurarti che le tue stime riflettano il lavoro che intendi fare.

Come altri hanno detto ...

1) avvicina il capo / PM in modo proattivo & sii onesto

Ma, aggiungerei anche ...

2 ) sii onesto sul fatto che

a) stai forgiando un nuovo territorio con gli strumenti / codice che stai utilizzando (ad esempio: non sei un esperto, quindi non possono fare ipotesi di progetto basate sul tuo essere un esperto in questo)

b) è un gran casino che stai cercando di districare .. il che aumenta

i. ) il tempo necessario per apprendere il codice ii. ) il tempo necessario per apportare modifiche

Ciò che questo dirà al tuo project manager è che quando si tratta di stime dei tempi (che i PM amano e che cercano di trattenere tutti) le tue stime sono solo un colpo nell'oscurità e sono selvaggiamente imprecisi. Non per cattiveria o stupidità .. solo perché questo è un nuovo territorio da coprire, e il territorio è molto ostile (codice di merda).

Quindi, invece di chiederti orari precisi (es. : "10 giorni per farlo, 5 giorni per farlo" ... metodo del percorso critico / stima del tempo CPM) .. dovrebbero invece aspettarsi intervalli di tempo stimati ... più di un "Penso che sarà da 10 a 20 giorni prima che riesca a farlo. "

E se chiedono perché le stime di intervallo di tempo selvagge ... dovrai parlare in gergo di Project Management e dire che stai passando a più di un PERT ( Valutazione del programma Tecnica di revisione &) Metodo di stima del tempo.

Ciò che PERT fa è richiedere che le persone che lavorano sulle pietre miliari forniscano 3 stime temporali ...

ottimista (quando può essere fatto nel Situazione dell'1% in cui dio ti sorride e tutto va per il verso giusto)

pessimista (l'1% del tempo in cui satana sta facendo la cacca in tutto il tuo progetto e niente va bene)

molto probabilmente (un momento in cui ti senti a tuo agio nel colpire 50% delle volte)

È importante sottolineare il fatto che "molto probabilmente" non è "Sono sicuro al 90% di poter portare a termine la cosa in questo lasso di tempo". No ... è "il 50% delle volte che riesco a raggiungere questa stima".

Perché le stime opt, pes & molto probabilmente si mappano su una curva a campana in PERT ...

opt = +3 dev std a rightpes = -3 dev std a leftml = da -2 a +2 curva a campana interna dev std

tempo medio per finire milestone = (opt + ml x 4 + pes ) / Stima di deviazione 6std = (pes - opt) / 6

(una curva a campana PERT presuppone 6 deviazioni std, perché un livello di deviazione +/- 4std sta andando fuori nel territorio "valori anomali astronomicamente improbabili" .)

I PM impiegherebbero le stime di tempo e possono fare z-score per ottenere curve di probabilità su quando le cose saranno fatte.

Ma, la conclusione è che PERT viene utilizzato per capire quali traguardi sono confusi ... qualcosa di nuovo e abbastanza diverso da indurre le persone a dare stime sconcertanti avrà una gamma più ampia di una pietra miliare che qualcuno ha già fatto e di cui è molto fiducioso.

Il tuo capo (se lo sono un PM o esperto di Project Management) dovrebbe sentire la parola "PERT" e iniziare a capire che forse hanno bisogno di ripensare a come ti vedono mentre lavori al compito.

Perché mentre i PM spesso scavano nel PMBOK e impara un sacco di matematica e si roba x sigma ... alla fine nel mondo reale diventano pigri e passano semplicemente ai metodi CPM o altro e chiedono semplicemente alle persone di fornire loro una stima di un SOLO NUMERO di tempo per una pietra miliare.

Per loro è fantastico .. b / c non devono calcolare cose per adattarle al loro diagramma di rete e al tracker del progetto.

Ma fa schifo per l'ape operaia come te .. b / c poi ti tengono a un numero / data esatto ... e in un progetto in cui stai facendo qualcosa di completamente diverso da quello che hai fatto prima ... non hai bisogno di quel tipo di pressione.

~~~ ~~~~~~~~

È anche bello far sapere a un capo che, mentre sei un programmatore, ciò non significa che sei un esperto istantaneo di tutto ciò che riguarda la programmazione.

Sono stato impiegato come analista / report runner in un luogo collegato a un dipartimento di gestione dei progetti e conoscevo alcuni codici, quindi ho automatizzato alcune cose. Da quando l'ho fatto, hanno pensato a me come "coder guy". Così, un giorno il direttore mi ha contattato per creare un sito web interattivo ... come ASP, HTML, tutti i nove metri ... sarebbero stati un sito web di monitoraggio del progetto a livello aziendale.

Io ' Lo guardo sbalordito, perché non sembrava capire che a) quello era LUNGO fuori dalla mia timoneria, b) anche se lo era, sapevo che quello che stavano chiedendo era qualcosa per cui di solito assumeresti una squadra di prorammer fare.

Ho dovuto fare una chiacchierata a disagio con il ragazzo .. e ho dovuto metterla in un linguaggio che potesse capire.

"Immagina tu, il direttore del project managemet ottenuto trasferito a essere il direttore della fatturazione "

" Ok .. sarebbe un cambio di passo, ma non vedo quale sarebbe il grosso problema ... "

"... in Cina."

"Cina?"

"Sì ... Cina."

"Ma io non parlo cinese. "

" Esattamente ".

" Oh. " (all'improvviso si rende conto di quello che mi stava chiedendo)