Posso capire la pressione del programma. Vuoi compiacere i tuoi utenti, poiché sono la linfa vitale dell'azienda. Tuttavia, è anche vero che alcuni cambiamenti renderanno tutto più semplice lungo la strada. Sfortunatamente, la gestione nella mia organizzazione ha una resistenza istintiva a tali cambiamenti e questa resistenza è così forte che ostacola i miglioramenti a lungo termine.

Ad esempio, Apple ha recentemente introdotto il conteggio automatico dei riferimenti per i programmi iOS. Questo è un notevole miglioramento rispetto alle chiamate di mantenimento / rilascio manuali che una volta era necessario utilizzare. Il codice è più semplice da scrivere e da gestire. È probabile che il cambio stesso produca alcuni arresti anomali. Ma una volta risolti, è probabile che il numero di strani incidenti casuali diminuisca.

Di recente ho detto al mio capo che volevo passare al conteggio dei riferimenti automatico. La sua risposta fu che voleva concentrarsi su miglioramenti visibili. È probabile che questa risposta sia stata a sua volta guidata dalla pressione che sta ricevendo da sopra di lui - e probabilmente proprio dal CEO.

Ci sono molti esempi simili. Il filo conduttore è che qualcosa deve essere risolto, ma i costi a breve termine della correzione superano i benefici a breve termine, in cui "a breve termine" è definito come "entro le prossime settimane".

Come dovrei gestire la situazione?

EDIT: grazie per le risposte. Continuate a venire. Poiché è rilevante per la mia situazione, dovrei chiarire che il mio manager e il CEO sono entrambi programmatori, anche se il CEO potrebbe aver ormai dimenticato come sia. Apparentemente i loro lati del programmatore sono stati sopraffatti da altre pressioni.

Stai davvero parlando di debito tecnico. Forse una metafora aiuterebbe i tuoi manager. Confronto spesso l'effetto del debito tecnico nei software con la cottura in una cucina sporca. Se il lavandino, i banconi e la stufa sono pieni di stoviglie sporche e c'è spazzatura sul pavimento, ci vuole più tempo per preparare un pasto. Tuttavia, il modo più veloce per preparare il pasto successivo è aggirare il caos. Pulire la cucina e mantenerla pulita ritarderà il pasto successivo, ma migliorerà la consegna di tutti i pasti successivi. E proprio come la persona affamata nella sala da pranzo non può vedere la cucina disordinata e non capirà perché vuoi pulire prima di iniziare a cucinare, la tua direzione non può vedere il disordine nel codice. È necessario mostrare loro il pasticcio o mostrare i problemi di qualità e i ritardi causati dal pasticcio.

Forse potresti anche parlare di compiti urgenti e compiti importanti. Quando non vengono eseguite attività importanti, le attività urgenti richiedono più tempo e costano di più.

Ti sei imbattuto in qualcosa che affligge i programmatori ovunque ad un certo punto della loro carriera: questo codice deve essere riformulato, ci sono problemi di architettura laggiù, questo modulo sta diventando non mantenibile, ecc. A causa dell'attuale cultura della tua organizzazione, tuttavia, vieni spinto a concentrarti sul lavoro che produce solo vantaggi direttamente visibili .

È di nuovo il classico segreto dell'iceberg . Il segreto ha a che fare con il fatto che proprio come un iceberg è sott'acqua al 90%, così come la maggior parte di qualsiasi progetto di sviluppo: il 90% del lavoro sarà completamente invisibile per l'utente finale. Tale codice avrà un impatto sull'utente finale, ma la gestione ha difficoltà a comprendere perché hai passato sei ore a refactoring delle chiamate di mantenimento / rilascio e di referenziamento automatico quando non riescono a vedere alcuna differenza e tutto funziona perfettamente.

Ecco alcuni fatti che puoi portare con te su questo problema.

• La direzione, a meno che non siano programmatori stessi , non capirà il segreto dell'iceberg.
• Questo è un problema di ignoranza, non di malizia. L'amministratore delegato desidera un buon prodotto, semplicemente non capisce tutto ciò che va in un buon prodotto.
• Il CEO (e il tuo capo diretto) non sono stupidi: studia e prepara alcuni fatti e alcuni dati concreti sul perché dovresti dedicare tempo a questo e ad altri problemi di Iceberg.

Non dimenticare: sei un uomo (o una donna) di compagnia. Non un maniaco del codice. Stai sviluppando questo prodotto per un'azienda che ha un interesse acquisito nel suo successo o fallimento: i tuoi progetti e le proposte di progetto dovrebbero riflettere questo. Mostra la tua passione per l'azienda e il prodotto, mostra le tue conoscenze e dimostra al tuo capo e CEO che dovrebbero fidarsi di te quando verrai da loro e dirai che qualcosa ha bisogno di lavoro. Mostra loro come contribuirà ai profitti, aggiungendo valore al prodotto (più persone acquistano copie) o risparmiando tempo (meno clienti arrabbiati quando il tuo prodotto fallisce).

Non

Vedo questa domanda e tutte le domande come una sorta di vicolo cieco. Non puoi "convincere" le persone di nulla. Se non sono già a conoscenza di cose come questa o indagate su di essa, è probabile che non gliene freghi. E nessuna quantità di dati li convincerà altrimenti. Il cambiamento deve venire dall'interno. Puoi condurre un cavallo all'acqua ma non puoi farlo bere.

Dico di apportare le modifiche desiderate nelle prossime stime tecniche. Be ', ehi, dobbiamo "aggiornare" a questo nuovo framework introdotto da Apple. Non lasciare che ARC non sia sulla tua tabella di marcia. Non ci sono opzioni; la migrazione ad ARC è l'unico modo.

Ho già risposto a una domanda simile qui, quindi questo potrebbe essere considerato un duplicato. Fondamentalmente, non avrai intenzione di fare uno "sforzo di refactoring". Il modo in cui rendi il codice più pulito è seguire la regola del boy scout: lascia sempre il codice più pulito quando lo lasci rispetto a quando sei arrivato.

Proprio come ripagare il debito reale può sembrare un'attività insormontabile (o ripulire una casa disordinata). Il trucco è migliorarlo pezzo per pezzo fino a quando non inizi a vedere "isole di pulizia". Una volta che hai un momento significativo, altri sviluppatori del team inizieranno a notare e alla fine contribuiranno all'attività.

Suggerirei di leggere Clean Coder di "Uncle" Bob Martin. Scrivere un buon codice fa parte del tuo lavoro. Non chiedi il permesso di fare il tuo lavoro, lo fai e basta.

Come per altre domande di questo tipo, è necessario fornire numeri che il management capirà. Numeri che mostrano quanto tempo verrà risparmiato implementando questi miglioramenti, quanti meno "incidenti strani casuali" si verificheranno, ecc. Convincerli che gli arresti anomali sono visibili all'utente finale e che tutto ciò che viene fatto per prevenirli è positivo per l'azienda.

Potresti anche tentare di implementare questi miglioramenti nel tuo tempo libero (ad esempio al di fuori dell'orario di lavoro) e successivamente mostrare i vantaggi alla direzione. Lo farei solo quando è chiaro che la direzione non capisce cosa stai cercando di comunicare e / o che non vuole dedicare tempo a te nemmeno per provarlo.

In bocca al lupo!

Presentare un caso aziendale

Ci sono molte ragioni per cui le raccomandazioni degli ingegneri vengono spesso ignorate. Il modo migliore per affrontare quasi tutti i motivi è il caso aziendale del perché dovrebbe essere fatto. La classica analisi costi / benefici. Questo non solo è un argomento convincente, ma dà anche ai tuoi capi qualcosa da portare ai loro superiori.

• Qual è il costo iniziale?
• Qual è il costo in corso?
• Quali sono i risparmi di tempo / denaro previsti e da dove provengono?
• Quanto tempo ci vorrà prima di vedere il ROI?

Quando si esegue un caso aziendale, è sempre necessario eseguire il backup dell'argomento con i dati.

• Quanto tempo impiega attualmente lo sviluppo a gestire i problemi che verranno eliminati o mitigati?
• Quanti reclami degli utenti vengono collegati ai problemi che verranno rimossi o mitigati?
• Quali altri vantaggi avrà?

Allinea i numeri e trasformali in un'equazione approssimativa, ma semplice. Costerà X e gioverà alla compagnia Y.

Nota: non essere sorpreso se implementare un'idea accademicamente buona costa in modo proibitivo.

Questo tipo di cambiamento rientra nella categoria del refactoring. L'approccio Agile sarebbe che dovresti incorporare il tempo di refactoring AMPLE in ogni storia che stimi e questo è esattamente il motivo. A parte gli ingegneri, nessuno capirà perché vuoi farlo e va bene, non è IL LORO lavoro determinare come codificare correttamente, è tuo.

Quindi la prossima volta che hai un pezzo di lavoro da fare, assicurati che questi cambiamenti ne facciano parte. Se stai fornendo stime, assicurati di aggiungere il 30% alla tua stima per il refactoring, se non stai fornendo stime, fai semplicemente il refactoring come parte del tuo lavoro.

Potrebbe renderti più lento - beh no, non è questo il modo di guardarlo, il modo di guardarlo è che la tua velocità attuale è un'illusione, essenzialmente una bugia che stai attraversando la catena, in realtà dovresti essere un un po 'più lento a causa di questo lavoro che sai deve essere fatto.

Probabilmente potresti costruire case più rapidamente se non avessi usato il calcestruzzo come base - e avrebbero un bell'aspetto per il cliente ma - beh - Anche se il cliente non vede la necessità della fondazione, il costruttore deve. (Questo è in realtà un parallelo interessante perché si scopre che i costruttori non fanno sempre quello che sanno che dovrebbero fare, quindi abbiamo bisogno di approvare leggi per costringerli a - non ci sono tali leggi che regolano lo sviluppo del software anche se affrontiamo lo stesso decisioni e spesso prendere quelle sbagliate ...)

Dici che sei abbastanza fortunato che il tuo manager e CEO sono entrambi programmatori. In modo che probabilmente non capiscono quello del debito tecnico è.

Dovresti gestire la situazione cercando di risolvere la situazione in base ai fatti, il che significa che esiste una reale possibilità che non finirai per apportare i miglioramenti tecnici desiderati (i fatti possono essere fastidiosi in quel modo).

Il tuo compito è quello di assicurarti che comprendano i costi e i benefici del pagamento di qualsiasi debito tecnico particolare che incorri. Il loro compito è decidere se il miglior uso delle risorse è nel ripagarlo o nel fare qualcos'altro.

Così come può essere difficile per le persone non coinvolte nel codice vedere i vantaggi del miglioramento delle cose "nascoste", può essere difficile per i programmatori vedere i benefici delle modifiche visibili del codice quando i benefici si accumulano in qualche modo nelle aree aziendali " nascosto "dagli sviluppatori.

È bello se il tuo management può spiegarti perché le funzionalità visibili valgono più del tuo tempo che pagare il debito tecnico, ma in realtà non è tuo compito prendere la decisione comunque. Quindi spiegarlo a te non fa molto per il business, tranne che per farti felice. E in un certo senso, insistere nel fare ciò non significa fidarsi di loro per fare il loro lavoro. Se non ti piace quando ti gestiscono in modo micro, allora dovresti capire.

Quindi, fintanto che li stai tenendo informati sullo stato di tutti i debiti tecnici e sui costi e benefici dell'ignorare rispetto a ripagarli, hai fatto il tuo lavoro. A meno che tu non ti fidi davvero che il management faccia il proprio, nel qual caso hai un problema molto più grande che sarebbe un'altra domanda da affrontare.

Forse questa non è una risposta, ma una risposta basata su errori che ho fatto. Anche un disaccordo con alcune delle filosofie che ho letto qui.

• Non cadere nella convinzione che il programmatore conosca meglio.
• Essere onesti. Rifattorizza mentre procedi, ma non mentire e riempire le stime per i tuoi scopi.
• Non possiedi il codice. Non intraprendere lavori non approvati dal responsabile.
• Potresti avere ragione su qualcosa; potresti sbagliarti ... ma dovresti fare quello per cui sei pagato.

Ma certamente segui l'eccellente consiglio dato sul miglioramento delle cose.

Ovviamente lavori per un capo dai capelli a punta (PHB). Non programma più, se mai, e se lo ha fatto probabilmente non era davvero buono (anche se gli piace inserire frasi come "const correttezza" e "errore di segmentazione" in modo che i ragazzi sappiano che si è guadagnato le strisce ) - è così che è stato scelto per la gestione.

Al CEO (che ha praticamente un Mohawk) piace il PHB perché il PHB offre funzionalità . Ogni sprint mostra con orgoglio una nuova casella di spunta (leggermente disallineata, con un'etichetta ambigua), un'icona luccicante (non ancora funzionante in nessun ambiente ma a colori a 8 bit su Citrix) e un modulo (che presenta crash casuali a causa delle condizioni di gara nella variante xml su misura basata su C ha implementato un database locale che nessuno nel team di sviluppo ha il coraggio di toccare perché è stato scritto da una delle vecchie leggende degli sviluppatori della guardia 10 anni fa e fa TUTTO con macro con nomi di 5 lettere, sia che abbiano bisogno di 5 lettere o non).

I programmatori che eseguono effettivamente il "bit di lavoro" (sai quel bit che succede, in modo inopportuno dopo tutto il vero lavoro come disegnare cerchi su lavagne, gridare e mangiare Battenburg in miniatura) sanno che in un sistema sano il lavoro che ha appena preso 10 ragazzi 10 giorni per scavare faticosamente fuori dalla giungla non mantenuta, probabilmente equivarrebbe a uno o due giorni uomo, incluso il test. Ma per ottenere il sistema da dove è sano, potrebbero essere necessari 6 mesi di duro lavoro, con poco in termini di ovvia ricompensa esterna.

Il PHB sa che in 6 mesi, con le buone o con le cattive, può ottenere trenta o quaranta nuove funzionalità nell'applicazione che i venditori (che devono essere maghi dato ciò che stanno effettivamente vendendo) possono essere utilizzati per tentare nuovi acquisti e aggiornamenti .

Tuttavia, per dare al PHB le sue quote: senza quelle caselle di spunta e quei moduli le vendite potrebbero ristagnare o diminuire, un concorrente potrebbe guadagnare quote di mercato e questo potrebbe essere peggio dell'alternativa.

La conclusione a cui sono giunto è che l'unica via d'uscita dal pantano è lavorare in una nuova start-up, con alcune persone che condividono la tua visione di come dovrebbe essere fatto il software e poi ostinatamente aderiscono a quella filosofia (I sto ancora lavorando per arrivarci!)

C'è un altro costo nascosto non menzionato in altre risposte. Vale a dire che i bravi ingegneri tendono ad andarsene nel tipo di ambiente descritto. Alla fine, chiunque abbia l'ambizione o la capacità di refactoring ha lasciato l'azienda, e quindi le cose andranno male, probabilmente non risolvibili. Sfortunatamente non puoi dirlo al tuo manager senza trovarti arrogante ("Sono uno dei tuoi migliori programmatori") e un idiota invadente ("Lascerò se non fai quello che voglio"). Tuttavia, ricordati di menzionarlo nell'intervista di uscita, per assicurarti di non avere uno stato di riassunzione.

Hai ragione e torto entrambi, ecco perché questi problemi restano in sospeso per molto tempo e creano sentimenti duri.

I motivi per cui sono chiaramente indicati sopra: la direzione pensa in denaro; o ancora più specificamente: entrate. Per loro qualcosa che ha un costo ma nessuna visibilità diretta per il cliente non aggiunge entrate, quindi è un cattivo piano.

Anche la tua visione è giusta: sarà positiva per i clienti ma a lungo termine. Le tue azioni potrebbero generare entrate ancora maggiori in futuro rispetto ai piani a breve termine.

Non sei il gestore, non sei il responsabile diretto delle entrate (presumo ovviamente). Quindi ti stai confondendo (è così per la gestione) con i loro problemi e non ti stai concentrando sul tuo lavoro: espandere ulteriormente il software.

Tutte parole dure e chiare, ma è così che sorgono la maggior parte dei problemi, a causa di errori di comunicazione. Entrambi volete la stessa cosa, ma le vostre decisioni a breve termine sono prese in modo diverso. Tutto perché lo sviluppatore ha una prospettiva diversa rispetto al gestore.

Come risolvi questo problema? Ci si comunica e si capisce abbastanza bene su una serie di questioni. Questo sarà il focus sull'impegno e la soddisfazione del cliente molto probabilmente.

Per risolvere questo problema in un metodo stabile e a prova di futuro concordare una cosa: misurare il costo della correzione di bug nel vecchio codice. Misura il tempo impiegato per lavorare con il vecchio software e come sarebbe con la nuova base di codice.

Per dimostrarlo, potresti ad esempio fare una cosa abbastanza semplice: diramare il software nel tuo controllo delle versioni. Prima fai quello che la gestione vuole, quindi crea quella funzione. Lo fai, ma l'accordo è che hai tempo per mostrare il modo diverso. Quindi fai la stessa cosa nella nuova categoria, ma prima risolvi i problemi che vuoi eliminare. Quindi sviluppare anche la soluzione.

Ora hai la stessa soluzione ma completamente sviluppata in modo diverso. Crea un caso da esso, metti le soluzioni una accanto all'altra tra cui alcune informazioni di gestione come la stabilità, la quantità di codice necessario e il codice stesso.

Ora prendi un caffè e inizia a dare un'occhiata, senza discutere chi ha ragione, ma quale sarebbe l'influenza di entrambe le direzioni per l'azienda. Ciò creerà un incontro davvero utile e non una discussione peggiore perché non genererà l'atmosfera di cui entrambi avrete bisogno. Ciò non renderà il tuo prodotto migliore.

Se hai una revisione del codice, crea un ticket tecnico che indichi che il codice dovrebbe essere migliorato usando ARC e assegnalo al gestore.

Convincilo. Spiegagli alcuni piccoli esempi di miglioramenti tecnici simili che hai fatto e i suoi benefici per i progetti.

Devi vendere quei cambiamenti nell'unico modo in cui la direzione è disposta ad acquistare:

Trova una funzionalità rivolta agli utenti così avvincente che la direzione deve solo averla, ma sarebbe impossibile fare a meno di alcuni miglioramenti di basso livello nel codice.

È compito del tuo capo assicurarsi che l'azienda concentri lo sviluppo sulla fornitura di ciò che i clienti percepiscono come valore aggiunto. Esistono due fattori che possono alterare questa percezione:

1. Quanto tempo ci vuole per consegnare una richiesta del cliente?
2. Consegni quando dici che lo farai?

La maggior parte preferirebbe dire che ci vorranno 6 settimane e consegnare in 5 piuttosto che dire che consegnerai in 3 ma ne impiegherai 4.

Avere una base di codice corrente che è più facile da gestire e migliorare consente di fornire più velocemente e aumentare la prevedibilità. Se stai impiegando troppo tempo a correggere bug, hai meno risorse disponibili per aggiungere nuove funzionalità. Valuta la quantità di risorse spese per la correzione del codice e la precisione delle promesse delle funzionalità. Questo è un modo per determinare se il tuo codice attuale (secondo la filosofia del tuo capo) costa troppo.

Lasciate che vi racconti un'opportunità da $ 2 miliardi che ci è quasi sfuggita di mano a causa dell'inerzia del management.

Alcuni di noi hanno il punto di ascoltare la voce del cliente, il che significa capire cosa vuole. Non è sempre quello che chiede, ma se sei in grado di conversare con il tuo cliente, alla fine giungi a una comprensione reciproca di ciò che vuole. (Quindi può iniziare esplicitamente a chiederlo.)

Detto questo, è importante capire chi dovrebbe avere quella conversazione con il cliente. In genere hai la tua gente di sviluppo del business insieme ad alcuni designer principali che lo fanno. Se hai qualche competizione, puoi aspettarti che anche il cliente stia conversando con loro.

Allo stesso tempo, è importante che gli sviluppatori mantengano aggiornati i loro campi, perché ci sarà concorrenza che ti batterà se non lo sei.

Nella nostra situazione, avevamo un cliente esistente e un prodotto piuttosto efficace basato sulla vecchia tecnologia e il cliente aveva bisogno di rapidi aggiornamenti. Ciò di cui avevano veramente bisogno era un prodotto sostitutivo completo, ma la mentalità della nostra azienda era che ciò ci avrebbe immediatamente costretti a una posizione competitiva, mentre la modifica del prodotto esistente consentiva ai nostri clienti di continuare con noi senza essere legalmente obbligati a renderlo competitivo. Il nostro management pensava di possedere questo mercato. Il problema era che non potevano tenere il passo con le richieste di aggiornamento, perché la struttura del prodotto esistente non era abbastanza flessibile per l'aggiornamento.

Il cliente divenne impaziente e iniziò a conversare con fonti concorrenti. Abbiamo perso la nostra "proprietà" di quel mercato e un paio di miliardi di dollari di entrate. Tuttavia, una volta che il mercato ci ha costretti a una posizione competitiva, il management non ha avuto altra scelta che uscire dal mercato o competere. (La maggior parte di quelli che erano blocchi stradali alla fine sono stati licenziati.) Abbiamo gareggiato e siamo stati in grado di riconquistare il business con il filo più sottile.

All'inizio ho detto che questa opportunità ci è quasi scivolata tra le mani. Abbiamo recuperato l'attività, per le entrate che ho citato. Se all'inizio fossimo stati più preparati ad adattarci alle preoccupazioni del cliente, non ci sarebbe stata alcuna vera concorrenza.

Il take-away che sto offrendo è questo: cerca sempre di rimanere all'avanguardia nelle tue capacità personali. Sviluppa sempre un prodotto flessibile e che possa essere adattato rapidamente alle esigenze dei tuoi clienti. Se lavori troppo a lungo per un'azienda che non la pensa così, appassirai e la tua motivazione personale diminuirà. L'ho visto succedere.

Quando hai un'idea per migliorare il tuo prodotto per qualsiasi motivo, poniti queste domande: - È questo ciò che penso che il cliente desideri? Posso convalidare le mie idee sullo sviluppo del prodotto con la voce del cliente? La mia azienda è in grado di soddisfare le esigenze del cliente? Se é cosi, come? - Dovresti quindi essere in grado di presentare un caso persuasivo riguardo alle tue proposte di sviluppo del prodotto.

Il linguaggio comune degli affari in tutti i campi e settori è denaro. Il problema che stai descrivendo non è un problema di programmazione: è un problema aziendale. Se si desidera ottenere una risposta adeguata a una proposta commerciale, è necessario inquadrarla nel linguaggio commerciale. Ciò significa che devi essere in grado di presentare un piano di progetto alternativo che includa tutti i costi e i benefici.

Devi conoscere cose come i costi delle opportunità, il ROI (ritorno sull'investimento) e il VAN (valore attuale netto). Non hai bisogno di un MBA per farlo, ma hai bisogno di accedere a dati che potrebbero non essere disponibili per te, come i costi di manodopera, i costi generali e il potenziale di entrate. Se puoi fare una chiara argomentazione sul fatto che un percorso fornirà più valore di un altro utilizzando numeri fissi, otterrai la massima attenzione dalla direzione.

Quando ero uno sviluppatore più recente in una squadra molto piccola, ho fatto molto di questo tipo di miglioramento nel mio tempo libero. Mi è piaciuto; Vorrei accedere e provare nuove interessanti tecniche mentre ero seduto in salotto con mia moglie di notte. Dato che sono diventato uno sviluppatore più senior e poi manager di una squadra più grande, il mio tempo libero è scomparso. Stavamo lavorando ore extra solo per ottenere le funzionalità e le correzioni critiche. È diventato davvero difficile giustificare passare il tempo di qualcuno in quel normale lavoro di pulizia, anche se tutti sapevamo quanto fosse importante.

I tuoi capi non hanno bisogno di una spiegazione di quanto sia importante, mantenere bassi i costi di manutenzione, ridurre i costi della crescita futura, mantenere coinvolto un team di sviluppo di talento, ecc. Se lo fanno, hai grossi problemi. Ciò di cui potrebbero aver bisogno, tuttavia, è un piano. Perché in questo momento sto indovinando che hanno tutti i tipi di piani, programmi, tabelle di marcia, promesse e pressioni sul lato "aggiungi funzionalità", che sono in competizione con la mera illusione e le richieste aperte del team di sviluppatori.

Una cosa che potresti provare è fare un piano documentato. Verifica se puoi collegarlo alle versioni o uscire dai criteri per le nuove funzionalità. Una richiesta di "dedicare un po 'di tempo a ripetere il conteggio dei riferimenti" potrebbe essere difficile da approvare per il tuo capo, ma programmare un periodo di 5 giorni tra 4 settimane potrebbe essere più semplice. Fondamentalmente, tuttavia, vedi che sono pianificate e pianificate nuove funzionalità, prova a imitarlo o inietta una parte "nascosta" in essa.

Inizia in piccolo chiedendo il 5% di tempo assegnato a quel tipo di cose, quindi costruisci gradualmente le tue priorità di roadmap tecnologica e continua a impegnarti a giustificare il business case, il ROI, i livelli di rischio, ecc. Su ciascuno di essi. Molto presto avrai anche un assaggio delle sfide dei tuoi capi, poiché troverai rapidamente molte più idee fantastiche di quelle che hai tempo di fare.

In bocca al lupo!

Ecco perché la tua richiesta di conteggio dei riferimenti automatico è stata respinta:

1. Non è un miglioramento . Una volta che hai qualcosa di più grande del mondo, qualsiasi cambiamento andrà nella direzione sbagliata. Nessuna quantità di refactoring cambierà il fatto che se è necessario apportare modifiche, andrà sempre nella direzione sbagliata. Il trucco è sapere quando le modifiche sono abbastanza significative da valere il rischio di causare nuovi problemi. Il vostro management ha chiaramente affermato che se gli utenti finali non riescono a vederlo, non vale la pena rischiare.
2. Il conteggio dei riferimenti è una funzione completamente folle. Hai visto alcune grandi aziende già esistenti implementare alcune funzionalità e hai immediatamente pensato di aver bisogno della stessa funzionalità. Bene, è molto probabile che il tuo codebase sia completamente diverso da quello che sta usando Apple. Probabilmente il conteggio dei riferimenti non funzionerà o è solo una perdita di tempo. Dovresti trovare un modo diverso che non richiede la diffusione di primitive per il conteggio dei riferimenti ovunque nel tuo codice. Probabilmente il tuo piano di contabilizzazione richiede migliaia di modifiche nella base di codice, la maggior parte di tali modifiche non sono necessarie. Basta perdere tempo e denaro.
3. Stai risolvendo il problema sbagliato. La direzione di solito sa che tipo di problemi ci sono nel sistema. Alcuni irrilevanti problemi di perdita di memoria che la soluzione di contabilità sta risolvendo non sono tra questi. Concentrati su problemi reali e non su alcuni problemi immaginari relativi al modo in cui i computer gestiscono la memoria.
4. Ci vuole troppo tempo per implementarlo Apple è leggermente più grande della tua squadra insignificante con pochi programmatori e alcuni manager. Possono fare grandi cambiamenti semplicemente pagando il prezzo. Se bastano pochi milioni per implementare qualcosa, sono le noccioline. Se le piccole aziende cercano di fare la stessa cosa, esauriranno rapidamente i loro soldi. Lo sviluppo del software è già molto costoso; l'aggiunta di costi superflui non aiuta un po '. Una caratteristica irrilevante come la gestione della memoria sta per aprire le porte: dopo che l'hanno approvata, metà dei programmatori vogliono che il loro "miglioramento" sia implementato. È una storia infinita e l'azienda potrebbe invece fare qualcosa di utile.

Ecco alcuni passaggi che è possibile utilizzare per gestire il problema:

1. Rilascia la funzione
2. Scopri qual è il vero problema
3. Inizia a fare qualcosa di utile
4. Pianifica attentamente come usi il tuo tempo
5. Scopri come i tuoi miglioramenti stanno portando soldi
6. Scegli solo le funzionalità che portano la maggior parte del denaro
7. Comprendi che l'aspetto di programmazione dello sviluppo software è solo una piccola parte dell'intero sistema: i miglioramenti apportati non varranno mai la pena