Quanti dettagli tecnici sono eccessivi quando si parla di manager non tecnici?

Non dire al tuo capo dei cambiamenti che hai spinto, che hanno chiesto specificamente di essere rimossi non sembra affatto una soluzione. Sembra insubordinato al meglio. Quindi devi stare attento nel modo in cui spieghi al tuo manager perché questa decisione è stata presa, e in che modo introduce il rischio di annullamento nel prodotto.

Il trucco ovviamente è evitare quella situazione in primo luogo.

Penso che la radice del tuo problema potrebbe rimanere nel modo in cui stai presentando il tuo problema al tuo capo. Il punto cruciale è che sembra che tu stia chiedendo a una persona non tecnica di prendere una decisione tecnica. Sembra follia. Assumerò che questa persona non tecnica abbia una migliore comprensione del contesto aziendale del problema. Se è così, allora che è ciò su cui devi concentrarti. Aiuta il tuo manager a capire in che modo ciascuna delle soluzioni proposte risolve il problema aziendale sottostante. Aiutali a capire il tempo necessario per implementare la soluzione, cosa significherà per il programma e i vantaggi che potrebbe comportare in futuro.

Molto spesso le soluzioni che uno sviluppatore deve presentare sono lungo i seguenti vettori:

1. Ecco una soluzione rapida, che risolve il problema sulla sua superficie, ci consentirà di mantenere il nostro programma, ma probabilmente dovrà essere completamente rielaborato lungo la strada.

2. Ecco una soluzione che richiederà più tempo per implementare, significa che dobbiamo ritardare un lancio, ma fornirà una base migliore per il prodotto che tecnicamente andrà avanti.

Se questo è applicabile in questa situazione, scomposizione per loro in quei modi. Assicurati che comprendano anche i rischi tecnici e commerciali associati alla soluzione tecnicamente più debole. I dettagli tecnici sono in qualche modo irrilevanti a meno che non li rendiate rilevanti facendo di loro il punto focale della vostra presentazione. Invece, prova a presentare le tue soluzioni attraverso l'obiettivo dell'azienda.

Infine, se i dettagli tecnici sono essenziali, coinvolgere lo sviluppatore principale nella presentazione al manager. Vieni preparato e unito. Pratica quello che vuoi dire in modo che tu sia chiaro e conciso. Presentare una presentazione powerpoint 3-10 per aiutare a visualizzare la soluzione. Non impantanarsi nelle erbacce del codice di presentazione, mantenerlo di alto livello, ma sufficientemente dettagliato per tenerlo informato. Rendi chiara la tua raccomandazione e il razionale.

IME, la chiave qui è di avere abbastanza membri maturi del team che possono raggiungere il consenso in modo che non sia solo per una persona a decidere se un gruppo di funzionalità entri o meno in una versione o meno. Naturalmente non è facile convincere una squadra ad avere l'esperienza e dire "Ehi, questo non accadrà. oppure "Ehi, potremmo fare di più di quanto pensassimo, cos'altro ti piacerebbe?"

Mentre nascondere i dettagli è una prospettiva, un'altra è la questione della gestione del tempo e dell'ottimizzazione della comunicazione. Ad esempio, descrivete tutte le idee per la risoluzione dei problemi utilizzate per correggere un errore più e più volte se chiedete aiuto a qualcuno? Rendi pubbliche tutte le sensibilità e le allergie alimentari prima di mangiare in ogni ristorante? Questi non sarebbero anche casi di menzogne per omissione? Sottolineando solo la domanda su quanto lontano prenderesti questo professionalmente e personalmente.

La lezione può essere fare ciò che ha senso. Se ci vorrà molto tempo per annullare le modifiche e poi ripristinarle, potrebbe essere meglio lasciare le cose dove sono ora.

Suppongo che il tuo manager sia responsabile delle tue consegne al cliente / superiore / altre parti dell'organizzazione. Se viene inserita una funzione in cui il tuo manager richiede esplicitamente di non essere incluso, e il tuo cliente scopre che si tratta di malfunzionamenti, ciò mette il tuo manager in una situazione molto spiacevole. Sembra che tu abbia bisogno di sistemare le decisioni nel tuo team. Forse il tuo manager e il tuo lead developer possono chiarire l'aria e trovare un processo migliore.

Nella mia esperienza devi decidere questo progetto per progetto. Ma in realtà dovrebbe sempre essere una decisione aziendale basata sul valore e sul costo. A volte è difficile per gli sviluppatori pensare in questo modo e ci mettiamo nei guai pensando in termini di "Non farà male a nessuno e sarà solo più lavoro per me lungo la strada". Di solito quello che faccio in questi tipi di situazioni è fondamentalmente un tentativo di spiegarlo in termini che l'utente aziendale capisce, non nascondendo nulla ma dandogli un livello di dettaglio tale da poter prendere una decisione efficace. Nel tuo esempio specifico potresti usare qualcosa del tipo,

These 10 features are ready to be deployed and by not releasing 8 of them it will cause x number of hours/days of delay for the current release and y number of hours/day extra work for the next release. Also if we do not push feature #2 then feature #9 which you do want will not work completely or will be incomplete.

Quindi disponi le opzioni

If we do push all 10 features then we can disable #1-5 and only user x will have access to #6-8 so we can communicate with them. Or what ever the mitigation is for releasing the features before the business is ready for them.

Io dico sempre agli sviluppatori quando parlano con gente che pensa al business che la maggior parte delle volte non è proprio il fatto che tu abbia bisogno di parlare un linguaggio "business" diverso per loro, solo che devi sentirti a tuo agio con il livello di dettaglio che dare loro. Come sviluppatori tendiamo a entrare nelle erbacce, disponendo tutte le opzioni perché questo è il modo in cui risolviamo le cose. Quando parli con gli utenti aziendali, devi essere a tuo agio nel comunicare con loro il cercapersone, i punti salienti, i fatti che li aiutano a prendere una buona decisione di lavoro.

Smetti di provare a verbalizzare i dettagli tecnici. Fai sapere al boss quanto tempo ci vorrà e offri una lista veloce di tutto ciò che è coinvolto. Lascia le lunghe discussioni se hai bisogno di chiarire un particolare concetto o teoria. Quelli che non lo capiranno ti stancheranno.

Puoi tenere così tanto nella tua testa se non sei in grado di avere una sorta di riferimento. I giocatori di scacchi del maestro non si comportano meglio dei principianti nel memorizzare pezzi degli scacchi che sono stati piazzati casualmente su una scacchiera. Se sono in linea con una tipica partita a scacchi, fanno molto meglio.

Di chi è il lavoro per decidere quali funzionalità vanno inserite nel rilascio? Nella mia esperienza, è il responsabile dello sviluppo. Se stai spremendo cose extra di cui non sa perché è utile, è grandioso. Non so che mi spingerei così lontano da spingere le cose che ha esplicitamente detto di non spingere, perché potrebbe tornare a morderti.

In fin dei conti, fa schifo se hai passato del tempo su qualcosa e non sei in grado di includerlo al momento, ma forse la ragione per cui non dovrebbe essere spinto è perché non hai sufficienti risorse di QA per testarlo adeguatamente. Preferirei ritardare una funzionalità in una versione successiva piuttosto che averla in circolazione senza essere adeguatamente testata.

Avevo un manager che non voleva conoscere i dettagli tecnici di nulla. Se descrivessi un problema che avevo con una caratteristica, più la descrivevo, più la pressione sanguigna sarebbe alta (era quasi un cambiamento visibile). Quindi, forse non dovresti fornire troppi dettagli tecnici. Vedi se questo aiuta.

woah there!

questo potrebbe potenzialmente significare per te un coglione un giorno ...

Do you not have a release/ change log?

Modifica

In sostanza, quello che stavo cercando di dire è documentando le versioni, le modifiche pianificate, le correzioni dei bug. Può essere chiaramente comunicato al tuo capo, questo può includere i dettagli tecnici, ma anche la descrizione di alto livello delle modifiche (proposte o meno).

Questo risolve il problema di "oh, a quale livello di dettaglio dovrei comunicare al mio capo?"