Vale la pena chiedere di B anche se so che il mio capo dirà "no"?

Direi di sì, ne vale la pena perché se non altro tu sei costruire la tua reputazione all'interno dell'organizzazione. Stai anche esercitando le tue abilità trasversali, il che sarà un grande vantaggio per te lungo la strada.

E infine, chissà per certo se la risposta sarà NO finché non chiedi . Se non lo chiedi, non riceverai mai.

Aggiornamento basato sui commenti :

Ci sono libri interi su come per chiedere quello che vuoi. Direi che dovresti utilizzare un approccio basato sui fatti per giustificare ciò che stai chiedendo. In effetti, puoi utilizzare questo approccio praticamente per tutte le tue richieste professionali.

Alcuni approfondimenti basati sulla mia esperienza includono:

1. Comprendi il tuo capo (o la persona da cui vuoi qualcosa) e le sue esigenze e limitazioni.
2. Assicurati di poter dimostrare perché ciò che stai chiedendo è una cosa positiva.
3. Includi qualsiasi settore pertinente o dati di supporto per eseguire il backup della tua richiesta.

Vale la pena discutere il tuo ragionamento con il tuo capo:

• Afferma che puoi pensare a due modi per risolvere questo problema.
• Spiega i compromessi di ciascuno uno.
• Digli con quale hai intenzione di andare.
• Chiedigli se ha senso o se è d'accordo.

Questo dimostra che:

1. Hai le conoscenze tecniche per elaborare A e B.
2. Comprendi i compromessi (incluso il lato finanziario) per prendere la decisione migliore da solo.

NON chiedere se dovresti fare B o se dovresti fare A o B, perché questo mostrerà il punto (1) sopra ma potrebbe inviare il opposto messaggio per il punto (2). Anche se chiedi quale scegliere presentando i pro e i contro di ciascuno (invece di chiedere se è d'accordo con quello che intendi scegliere), potrebbe comunque mostrare che non sei davvero in grado di prendere questa decisione da solo .

Fintanto che non esageri, non dovrebbe esserci molto danno nel solo ottenere una seconda opinione o approvazione riguardo a ciò che intendi fare e generalmente sarebbe visto come un forza (perché nessuno vuole una mina vagante che faccia quello che pensa sia meglio senza consultare nessun altro).

In base alla tua descrizione, l'opzione B potrebbe introdurre complicazioni in software altrimenti stabile, quindi dovresti aspettarti una certa avversione al rischio se aggiunge poco valore.

Detto questo, non c'è niente di sbagliato nel menzionarlo di sfuggita. Indica i due vantaggi che vedi, gli svantaggi e il motivo per cui sospetti che non valga la pena farlo.

Per quanto ne sai il tuo capo e i tuoi colleghi potrebbero prevedere altri vantaggi, pensa ai potenziali effetti collaterali dal loro punto di vista, e decidi che è effettivamente meglio.

Lo metterei in modo leggermente diverso. Direi qualcosa del tipo: "Ho escogitato due potenziali soluzioni. B ha alcuni vantaggi ma penso che A sia più pratico. Consiglierei di implementare A. Cosa ne pensi?"

il modo in cui stai dando al comando tutte le informazioni che hai e facendogli sapere quale decisione avresti preso. Un buon lead sarà d'accordo con te o ti spiegherà perché non lo fanno.

A proposito, non c'è bisogno di considerarlo come una dimostrazione. Quello che stai facendo è trasmettere ciò che hai imparato e fare una raccomandazione. Partendo dal presupposto che questo non è un test, cioè il vantaggio non ha già deciso, questo è esattamente quello che dovrebbero cercare in un junior.

C'è un fattore importante in questo che penso che nessuna delle risposte fino ad oggi abbia affrontato; sei nuovo in azienda.

Come regola generale, sarei propenso a dire che (assumendo nessuna differenza di prestazioni tra le due opzioni) l'opzione è "intelligente" e sfrutta il modo in cui il sistema è impostato probabilmente non è la soluzione migliore, semplicemente perché è intelligente (e quindi presumibilmente non qualcosa che il prossimo ragazzo a guardare le cose capirebbe immediatamente intuitivamente), e perché trae vantaggio da come è impostato il sistema (il che significa che se noi decidere di cambiare il modo in cui il sistema è impostato tra mesi, potremmo avere una piccola bomba a orologeria, come parte di cose che non ci aspetteremmo di essere influenzate, ma che smette di funzionare quando il sistema viene aggiornato).

Ma - sei nuovo . Non sai se ci sono ragioni per cui il sistema è impostato come è. Non sai necessariamente se l'azienda ha preso in considerazione la possibilità di cambiare le cose in modo significativo e se le tue idee si scontrerebbero con questo o se andrebbero d'accordo.

Quindi, questa non è solo un'opportunità per te per mostrare al tuo capo che sei magro fuori dagli schemi: è anche un'opportunità per imparare più storia.

Conoscere la storia dietro un progetto può aiutarti a capire perché sono state prese determinate decisioni, perché le persone potrebbero essere contrarie a determinate direzioni o modifiche e può fornire un'idea di dove le cose potrebbero andare in futuro. Questo può essere estremamente utile. Mi sono trovato in situazioni in cui la semplice conoscenza della storia di un sistema è stata in grado di impedire che venissero apportati potenziali cambiamenti disastrosi.

Quindi, affrontando questo aspetto non solo "potremmo farlo in due modi, e penso che questa sia la strada da percorrere ", ma" in un modo o nell'altro si adatta meglio / peggio ai progetti / idee imminenti? " aiuta a rendere questo meno intelligente quanto sei intelligente e quanto sei perfetto, e più su di te che sviluppi una comprensione più profonda del sistema.

In definitiva, la vera conversazione potrebbe non essere con il tuo capo, ma con altri membri del team, ovviamente. Sta a te capire se ha più senso parlare prima con loro o con il tuo capo. Se qualcuno agisce da mentore, potrebbe essere la persona a cui rivolgersi.

Propongo un'altra soluzione:

Non chiedere. Ma ... menzionalo di sfuggita

Dici che il tuo compito era trovare una soluzione e questa è l'opzione A. Quindi, dopo aver informato il tuo supervisore dell'opzione A, potresti quindi menzionare l'opzione B, come

"Ho notato che, se ci fosse una modifica X al sistema, una soluzione come l'opzione B potrebbe funzionare e avrebbe i seguenti vantaggi ..."

Dimostreresti comunque di aver trovato una soluzione creativa e intelligente. Se il tuo supervisore pensa che valga la pena provare, può dirtelo (o almeno pensarci). Tuttavia, non ha nemmeno bisogno di rispondere, nel caso in cui non lo consideri (quindi chiedi meno da lui, rispetto a se gli avessi fatto una domanda). Quindi fai lo stesso, ma con un rischio ridotto di ottenere un "No" come risposta.

Prima di tutto, non puoi mai essere del tutto sicuro di ciò che le persone potrebbero dire o pensare. Forse il tuo capo penserà che l'idea B sia un'ottima idea. Forse con la sua conoscenza più avanzata dei tuoi sistemi, scoprirà che i vantaggi / svantaggi del metodo B sono maggiori di quanto ti aspettavi.
O forse non lo farà e sceglierà invece A, ma presentare altre opzioni non danneggerà la tua reputazione, al contrario.

Dimostra che hai riflettuto un po 'sul problema e, da quello che dici, mostra che hai assimilato come sono organizzate le cose anche nel tuo nuovo posto. In quanto tale, mostra alcune delle tue qualità a un capo che non sa ancora cosa sei in grado di fare.
Non si mette in mostra finché non enfatizzi troppo quanto "un'idea intelligente" potrebbe essere quando lo esponi al tuo capo.

Ti consiglio di presentare entrambe le opzioni pur rimanendo concreto.
"Queste sono le soluzioni che ho trovato per risolvere il problema: opzione A e opzione B. Penso che B renderebbe le cose più veloci, ma implementarlo richiederebbe la modifica di X ".
Lascia che sia il tuo capo a decidere se le modifiche necessarie per l'opzione B valgono o meno.

Per me personalmente, chiedo sempre perché la cosa peggiore che può accadere è che il mio capo dica "No". La maggior parte dei miei migliori progetti che pensavo fossero irraggiungibili (per status, esperienza, politica, ecc.) Sono diventati realtà perché l'ho chiesto.

Se sei così sicuro che l'idea verrà abbattuta, devi chiederti perché. I manager in generale non sono abituati a rifiutare idee che sono onestamente vantaggiose per l'azienda. Valuta i motivi ed eliminali o attenuali se puoi prima di andare dal tuo capo. Il tuo approccio migliore è spesso dire qualcosa del tipo:

Avevo considerato di farlo in questo modo, ma penso che non sia la migliore linea d'azione per questi motivi ...

Questo a volte può innescare idee nei colleghi sui modi per farlo funzionare, o soluzioni alternative / di compromesso che non ti sono venute in mente. A volte tutto ciò che puoi fare è fare un piano per migrare lentamente da una soluzione legacy. Le persone che lavorano insieme possono trovare soluzioni migliori rispetto a quelle separate.

Politicamente, spesso è bene per te mostrare al tuo capo il tuo modo di pensare, quali cose hai considerato e come hai fatto le tue scelte. Quindi sì, fallo anche se pensi che una o più opzioni non gli piaceranno. Se hai intenzione di farlo, sembrerai migliore al tuo capo se sarai convincente. Quindi presentalo in un modo che la direzione possa capire.

Quando ho due o più opzioni possibili, lo scrivo come analisi decisionale formale e lo presento in questo modo. In questo modo la persona può vedere i pro ei contro di ogni opzione e, cosa più importante, vede che hai pensato alle possibili soluzioni.

In genere consiglio l'opzione con il miglior punteggio numerico, ma se non è d'accordo con il mio punteggio, possiamo modificarlo al volo e vedere cosa succede.

Come fare un'analisi decisionale è la domanda. In un foglio di calcolo si impostano i fattori decisionali. Queste sono le cose che stanno alla base per decidere quale sia l'opzione migliore. Ogni fattore riceve un fattore di ponderazione che indica quanto sia relativamente importante quel fattore. Quindi ogni opzione viene posizionata in alto. Ogni opzione è valutata numericamente rispetto a ciascun fattore di classificazione. Quindi moltiplica il fattore di ponderazione e il punteggio numerico per ottenere il totale per quel fattore per ciascuna opzione. Quindi sommali insieme per vedere qual è il migliore.

Un esempio mostrato di seguito:

È mia opinione che tu abbia bisogno di una terza opzione. Come hai capito, alle aziende non piace apportare modifiche al di fuori del progetto immediato e il tuo capo potrebbe anche non avere voce in capitolo, indipendentemente dal fatto che sia il modo migliore per fare le cose. Questo ha a che fare con la logica di un business (politica, finanze, ecc.) Su cui non sono in grado di consigliare direttamente. Pertanto, se l'opzione A non è così eccezionale e l'opzione B verrà scartata per motivi di logica aziendale, allora dovresti aver bisogno di un'opzione C che è migliore dell'opzione A e più business come dell'opzione B. Senza l'opzione C, lo farei presentare prima l'opzione B perché sembrerebbe una soluzione migliore se approvata e le modifiche esterne possono essere apportate. L'opzione A sarebbe quindi un ripiego nel caso in cui tutto il resto fallisse. Presentare l'opzione A prima o accanto all'opzione B farà sì che le opzioni diverse da A non vengano prese in considerazione perché l'opzione A sembra essere il percorso più semplice. Questa è stata la mia esperienza in situazioni simili.

Come sottolineato in una risposta precedente, sii consapevole che "intelligente" non è necessariamente "migliore". Vantaggi quali tempo di elaborazione ridotto, minore ingombro di memoria, codice gestibile, tempo per l'implementazione, facilità di manutenzione futura, rispetto del budget e riduzione delle ore di lavoro sono i tipi di cose che rendono una soluzione "migliore". Fallo velocemente, fallo bene e guadagnerai il tuo prestigio.

Probabilmente non è un errore affermare che sei consapevole di un approccio più intelligente ma hai scelto di non prenderlo. Tuttavia non lo chiederei, per due ragioni.

Primo, essendo piuttosto nuovo, potresti dover chiedere cose in altre occasioni. Tuttavia non essere il ragazzo che sempre chiede le cose più banali, cioè il ragazzo che è totalmente incapace di fare una cosa da solo. Come programmatore, sei un risolutore di problemi, risolvi i tuoi problemi.

In secondo luogo, "intelligente" di solito è meno importante che portare a termine il lavoro ed essere generico o portatile. In effetti, la maggior parte delle soluzioni aziendali non sono affatto intelligenti, sono abissali. Tuttavia, fintanto che funzionano abbastanza bene in modo che non ci siano reclami, non importa.

Hai detto che A "funzionerà" mentre B funzionerà solo per il tuo particolare sistema, e anche così richiederebbe una piccola modifica. Questo è qualcosa che quasi certamente provocherà una reazione negativa. Con un po 'di fortuna, farai citare Tony Hoare. Se sei meno fortunato, otterrai qualcosa di meno educato.

Una soluzione che funziona solo su un sistema di solito è impossibile. Ottimizzare dove non c'è bisogno urgente di solito è anche un no-go.

Ci sono molte buone risposte, ma la domanda del titolo era "Vale mai la pena fare una domanda se sai che la risposta è no?" La risposta è "Sì". Ci sono molte ragioni per cui dovresti porre una domanda anche se pensi che la risposta sia no. Potrebbe essere a scopo di documentazione (CYA) o potrebbe essere in modo che tutti sappiano qual è la politica su un determinato problema.

Alla tua domanda più specifica, codice leggibile> codice intelligente. Ma se hai una soluzione migliore di quella proposta, dovresti implementarla o almeno presentare il tuo caso. Steve Jobs una volta ha scritto una prova che ridurre il tempo di avvio da 30 secondi avrebbe effettivamente salvato vite umane. Ancora più importante, dovresti imparare e la tua azienda vuole che tu impari in modo da rimanere utile, che lo sappia o no. Fare la soluzione migliore che sai quanto è importante per il tuo sviluppo.

Inoltre, quando presenti il ​​tuo caso, non dire "questo non ti aiuterà, ma ..." i modi in cui aiuterà. Risparmiare ore aziendali all'anno potrebbe far risparmiare decine di migliaia di dollari, a seconda di chi è interessato dal codice.

Potete fare entrambe le cose?

bool bBeClever = false;

if (bBeClever)
impressionWay ();
else
boringWay ();

Ancora meglio, invece di creare funzioni impressionanti e boringWay () completamente diverse, puoi creare una funzione che possa fare entrambe le cose, sulla base di un booleano (preferibilmente modificabile in fase di esecuzione utilizzando un parametro passato o altro variabile)?

Questo è il mio consiglio che sembra piuttosto adattato a questa domanda specifica (sulla programmazione del computer). Successivamente, ecco alcune altre considerazioni che potrebbero essere più facilmente applicabili in altri scenari (in altre attività).

Se gli approcci sono così fondamentalmente diversi che è davvero necessario fare solo l'uno o l'altro, forse perché non hai abbastanza tempo di programmazione per fare entrambe le cose, quindi fai semplicemente ciò che è più saggio (cioè: più facilmente gestibile con circostanze che possono cambiare, molto probabilmente per essere approvato dai superiori, ecc.) ma documenta l'altra altra opzione. Anche se non ottieni credito per aver completato l'altra opzione, la tua intelligenza può sopravvivere a chiunque stia leggendo i commenti e / o la documentazione del codice. Prendere una nota del genere può anche fornire valore, consentendo alle persone di ricordare che è disponibile questo metodo di ottimizzazione che potrebbe essere perseguito se specifiche esigenze / priorità ogni cambiamento. Spero che il tuo capo dovrebbe apprezzare questo valore aggiunto.

Quando sono stato pagato per la programmazione, so che il mio supervisore ha apprezzato in modo significativo molte idee che ho trasmesso, anche quelle che non sono state implementate immediatamente.