In che modo le persone non tecniche apprezzano un problema non relativo all'interfaccia utente? [chiuso]

Question

Supponiamo che tu stia lavorando a un progetto aziendale in cui devi ottenere l'approvazione della gestione per poter sviluppare un nuovo set di funzionalità. Di solito la tua gestione non ha problemi a firmare alcune nuove e brillanti funzionalità dell'interfaccia utente. Sfortunatamente hanno difficoltà ad apprezzare alcuni problemi dietro le quinte che sono cruciali per il benessere dell'applicazione come transazioni, integrità dei dati, instradamento del flusso di lavoro, configurabilità, sicurezza, ecc. Dal momento che non sono tecnici e questi problemi sono non immediatamente visibile, non è ovvio per loro che questo è cruciale.

Come li hai convinti che questi problemi infrastrutturali devono essere affrontati e che è importante per il loro processo aziendale?

Answer 1

Ogni imbarcazione ha i suoi lati nonxy. Cose che DEVONO essere fatte, ma nessuno le nota direttamente. In una drogheria qualcuno deve organizzare come e quando riempire gli scaffali della drogheria in modo che appaiano sempre freschi. In una lavanderia hai bisogno di qualcuno che pensi a come i processi dovrebbero essere ottimizzati in modo che il cliente ottenga i suoi vestiti in tempo.

La parte difficile è: il cliente non si accorgerà quando queste cose impercettibili sono state fatte nel modo giusto FINO A CHE AVVISO STANNO PERDENDO! Come quando la lavanderia non è pronta in tempo ma con due giorni di ritardo, o le verdure nel supermercato hanno macchie marroni e sembrano terribili.

Lo stesso vale per l'IT. Non noti buone transazioni fino a quando il tuo cliente principale bussa alla tua porta e ti dice che un progetto importante e costoso è fallito perché le voci del database del tuo prodotto sono state misteriosamente confuse. Non si nota una buona sicurezza finché le informazioni sulla carta di credito del cliente non vengono visualizzate in Elbonia (e subito dopo la parola è sui giornali nazionali che avvisano i clienti della tua azienda).

La cosa a cui devi veramente fare il martello ancora e ancora e ancora è che il software NON è statico. Deve essere curato anche dopo la fine della sua fase di sviluppo iniziale. Non è solo un prodotto che acquisti una volta e di cui ti dimentichi. Ogni casa automobilistica sa che i servizi sono di primaria importanza per i prodotti che costruiscono, semplicemente perché accadranno cose che devono essere riparate e migliorate. È lo stesso con il software.

Crea una presentazione, visualizza, verbalizza, traduci le tue informazioni tecniche in vantaggi. Gli uomini d'affari non si preoccupano del tuo desiderio di estetica del codice in un progetto di refactoring, ma comprenderanno che le tue modifiche aiuteranno il prodotto a diventare più affidabile, ottenere una migliore reputazione e ridurre la quantità di future richieste di assistenza. Fagli capire mostrando loro i vantaggi!

Answer 2

Stessa cosa che la gente fa da migliaia di anni: disegnare immagini. Diagramma i problemi, usa metafore visive familiari al tuo pubblico, trascina il problema sul loro territorio.

Supponendo che non siano intenzionalmente ottusi ...

Answer 3

Un grande +1 per analogie e metafore. Se possibile, trovane uno che risuoni con gli interessi personali del tuo pubblico (se si tratta di 1-2 persone). Per metafore generali, mi trovo spesso a usare il traffico pendolare o la metropolitana, per qualche motivo.

es. Al momento stiamo eseguendo la migrazione di un'app da un OODB a Postgres / Hibernate: la maggior parte di questo lavoro viene eseguita nella versione '4'. Molti esperti di dominio si sono chiesti perché in R4 ci siano così poche funzionalità rivolte all'utente. Dico loro regolarmente che abbiamo 'distrutto la città per entrare in metropolitana. È molto costoso e innegabilmente rischioso, ma una volta fatto, i vantaggi di R5 + saranno davvero sorprendenti. ' La vera conversazione è più coinvolta, ma posso tornare su questo tema ancora e ancora, ben dopo R4. Tra qualche mese, spero di dire "Hai chiesto X ed è ora molto semplice - proprio perché ci hai permesso di rimetterci in metropolitana in R4".

Answer 4

Il modo più sicuro per ottenere una gestione di livello superiore per acquistare il lavoro di sviluppo è presentarlo in modo quantificabile. Idealmente questa misura quantificabile è in $$. È necessario spiegare loro le conseguenze della lesione sull'integrità dei dati, sulla sicurezza, sulle transazioni, ecc. E su come ciò influenzerà la comunità di clienti / utenti e, infine, i profitti. Dovresti stare attento in queste situazioni perché a volte il management si aspetta che questi requisiti non funzionali funzionino correttamente. In questo caso, dovresti stimare in alto e lavorare su questi elementi insieme al lavoro visibile dell'interfaccia utente (l'ignoranza è felicità) o devi documentare queste aree di necessità mentre comunichi con la direzione, quindi se le cose vanno male come prevedi, non è il tuo lavoro ad essere in linea.

Answer 5

Sfortunatamente, di solito ci vogliono un disastro o due prima che questa roba ottenga l'attenzione che merita.

Dipende davvero da come è la tua gestione, ma ho avuto fortuna con il buon vecchio timore della sincerità. Se attraversi un paio di scenari di catastrofe e fai notare che qualcuno verrà incolpato se si verificano, può essere sufficiente a far esplodere il loro istinto di recupero e infine prestare attenzione:)

Answer 6

Analogie automobilistiche.

Tutti conoscono quel "sistema" ed è sufficientemente complesso per rappresentare la terribile situazione.

Answer 7

Sto combattendo essenzialmente con lo stesso tipo di situazione. Che si tratti di approvazione da parte della direzione o di accettazione da parte di un utente / sponsor, il problema rimane di vocabolari, priorità e prospettive diverse. Ho fatto una domanda simile qui .

Ho anche avuto risposte diverse, allettanti in modo vicino a utili, ma non abbastanza definitive. Navigare e cercare SO utilizzando parole chiave pertinenti mi ha portato a trovare approfondimenti utilizzabili in varie risposte sparse su molte domande non correlate. Trovare ed estrarre queste gemme mi ha portato a porre questa domanda sul site mining .

Sarebbe stato utile poter contrassegnare le varie risposte e vederle tutte in un unico elenco, ma purtroppo quella funzionalità non è ancora disponibile in SO. Ho suggerito su uservoice .

Spero che trovi qualcosa che puoi usare dai riferimenti che ho dato.

Answer 8

Il giusto tipo di domanda di risposta è il segreto.

• Va bene andare in crash ogni 5 pagine Web?
• Dobbiamo proteggere i numeri delle carte di credito?
• Va bene pagare gli appaltatori per distribuire una patch ogni fine settimana?
• Lo volevi adesso o volevi che funzionasse?

Answer 9

Robustezza. Quando si tratta di esso, devi parlare la loro lingua, che è come influenza la loro linea di fondo. Se si tratta di un problema di sicurezza o correttezza, devi dire loro che i clienti non vogliono prodotti che agiscono in modo errato, non importa quanto siano belli.

Answer 10

Mi piace l'idea di Debito tecnico , perché consente la traduzione di problemi tecnici ( anche se vagamente) in questioni di denaro - e il denaro è qualcosa che la maggior parte dei manager capisce.

Sebbene l'idea del debito tecnico sia stata originariamente applicata a problemi di architettura, può essere utilizzata in modo più ampio per qualsiasi tipo di situazione in cui vi sia la pressione di prendere una scorciatoia - cioè, andare in debito tecnico - piuttosto che farlo giusto la prima volta. (Farlo nel modo giusto equivale a risparmiare per comprare qualcosa - ci vuole tempo - piuttosto che acquistarlo a credito e indebitarsi.)

Proprio come i debiti possono essere buoni (ad esempio prestiti per la casa) e cattivi (ad esempio le carte di credito), così il debito tecnico può essere buono e cattivo. Non cercherò di caratterizzare completamente le differenze, ma un buon debito tecnico può essere tracciato con precisione, in modo da sapere quanto sei in debito.

Quindi, cerca di spiegare il tuo importante problema non relativo all'interfaccia utente in termini di debito tecnico e il costo del mancato aggiustamento in termini di pagamento degli interessi su tale debito.

Answer 11

Un'immagine descrittiva aiuta davvero le persone non tecniche a capire di cosa stai parlando. Ad esempio, di seguito è riportato un esempio di Sun che descrive come le informazioni vengono elaborate in una delle loro applicazioni piuttosto complesse.

_{(fonte: sun.com )}

Cercare di spiegare questa applicazione a parole sarebbe impossibile per un non tecnico. Indicando il diagramma e dire guarda, questa parte è il nostro punto debole, dobbiamo migliorarlo. Ciò avrà senso per loro. Se si sentono come se avessero una certa comprensione di ciò che stai facendo, saranno molto più disposti a supportare la tua richiesta.