12 motivi per il fallimento in analisi e business intelligence

Il numero 9 potrebbe sorprenderti

Nell'analisi e nella business intelligence, ci sono molte cose che possono andare storte. Dopotutto, stiamo cercando l'unica versione della verità. Che si tratti di un report o di un progetto – affinché i dati ei risultati risultino coerenti, verificabili, accurati e, soprattutto, accettati dall'utente finale – ci sono molti anelli della catena che devono essere corretti. La pratica dell'integrazione continua, inventata dagli sviluppatori di software e presa in prestito dalla comunità di analisi e business intelligence, è un tentativo di cogliere gli errori o gli errori in anticipo.  

Tuttavia, gli errori si insinuano nel prodotto finale. Perché è sbagliato? Eccotene alcune scuse motivi per cui la dashboard è sbagliata o il progetto non è riuscito.

1. Sarà più veloce.  Sì, questo è probabilmente vero. È una questione di compromessi. Quale preferisci? Lo vuoi veloce o vuoi che sia fatto bene?   Ad essere onesti, a volte siamo messi in quella posizione. Ne ho bisogno entro venerdì. Ne ho bisogno oggi. No, mi serviva ieri. Il capo non ha chiesto quanto tempo ci sarebbe voluto. Lui detto noi quanto tempo abbiamo dovuto farlo. Perché è quando Sales ne ha bisogno. Perché è allora che il cliente lo vuole.    
2. Sarà abbastanza buono.  La perfezione è impossibile e inoltre la perfezione è nemica del bene. Il inventore del radar di allerta precoce del raid aereo ha proposto un "culto dell'imperfetto". La sua filosofia era "Sforzati sempre di dare ai militari il terzo migliore perché il meglio è impossibile e il secondo migliore è sempre troppo tardi". Lasceremo il culto dell'imperfetto ai militari. Penso che il punto di un progresso agile e incrementale verso il risultato finale sia mancato qui. Nella metodologia Agile c'è il concetto di Prodotto Minimo Vitale (MVP). La parola chiave qui è praticabile.  Non è morto all'arrivo e non è fatto. Quello che hai è un waypoint nel viaggio verso una destinazione di successo.
3. Sarà più economico.  Non proprio. Non a lungo termine. Costa sempre di più aggiustarlo in seguito. È più economico farlo bene la prima volta. Per ogni passaggio rimosso dalla codifica iniziale, il costo è un ordine di grandezza superiore. Questo motivo è legato al primo, la velocità di consegna. I tre lati del triangolo di gestione del progetto sono l'ambito, il costo e la durata. Non puoi cambiarne uno senza influenzare gli altri. Lo stesso principio si applica qui: scegline due. Bene. Veloce. Economico.  https://www.pyragraph.com/2013/05/good-fast-cheap-you-can-only-pick-two/
4. È solo un POC. Non è che metteremo in produzione questa Proof of Concept, giusto? Questo riguarda la definizione delle aspettative in modo appropriato. Un POC è in genere limitato nel tempo con un insieme specifico di obiettivi o casi d'uso per valutare l'applicazione o l'ambiente. Questi casi d'uso rappresentano must-have critici o modelli comuni. Quindi, la valutazione POC, per definizione, è una fetta della torta più ampia su cui possiamo basare ulteriori decisioni. è raramente non è mai una buona idea mettere in produzione un POC, sia esso software o hardware.    
5. È solo temporaneo. Se i risultati sono sbagliati, funziona male, o è semplicemente brutto, non dovrebbe essere passato alla produzione. Anche se si tratta di un output provvisorio, deve essere presentabile. Gli utenti finali e le parti interessate non lo accetteranno. L'avvertenza è, tuttavia, che potrebbe essere accettabile se queste sono le aspettative che sono state stabilite come parte del processo. "I numeri sono giusti, ma vorremmo il tuo feedback sui colori nella dashboard." Tuttavia, questo non dovrebbe essere in produzione; dovrebbe essere in un ambiente inferiore. Troppo spesso, “è solo temporaneo” diventa le buone intenzioni di un problema permanente.
6. Questo è l'unico modo che conosco.  A volte c'è più di una risposta giusta. E a volte c'è più di un percorso per arrivare a una destinazione. A volte portiamo con noi le nostre vecchie abitudini. Sono duri a morire. Usalo come momento di apprendimento. Impara nel modo giusto. Prendere il tempo. Chiedere aiuto.  
7. Questo è il modo in cui lo abbiamo sempre fatto. Questo è difficile da risolvere ed è difficile discuterne. Ci vuole una vera gestione del cambiamento organizzativo per cambiare i processi e le persone che li eseguono. Spesso, un nuovo progetto, un nuovo software, un aggiornamento o una migrazione esporranno problemi a lungo nascosti. È il momento di cambiare.  
8. Spiacenti, l'ho fatto di nuovo. Sono un falegname e abbiamo un motto perché si fanno tanti errori: misurare due volte e tagliare una volta. Conosco questo aforisma. Lo ripeto a me stesso. Ma, mi vergogno a dirlo, ci sono ancora momenti in cui la mia tavola è troppo corta. È questa negligenza? Forse. Il più delle volte, però, è solo qualcosa di facile e veloce. Non ho davvero bisogno di un piano. Ma sai una cosa? Se mi fossi preso il tempo per disegnarlo su un piano, ci sono buone probabilità che i numeri sarebbero stati elaborati. Il pezzo troppo corto potrebbe essere stato su carta e una gomma l'avrebbe riparato. Lo stesso vale per analisi e business intelligence, un piano, anche per qualcosa di semplice e veloce, può ridurre questo tipo di errori.     
9. Distrazioni. Guardare ma non vedere. Cecità disattenta. Potresti aver visto il video dove ti viene assegnato un compito da svolgere, come contare il numero di passaggi di basket per una squadra. Mentre sei distratto dall'esecuzione di quel semplice compito, [AVVISO SPOILER] non noti il ​​gorilla che cammina sulla luna. Sapevo cosa sarebbe successo e sarei stato comunque un terribile testimone se fosse stato commesso un crimine. La stessa cosa accade nello sviluppo di report. I requisiti richiedono un allineamento pixel-perfetto, il logo deve essere aggiornato, il disclaimer legale deve essere incluso. Non lasciare che questo ti distragga dall'assicurarti che i calcoli siano validi.   
10. Avevi intenzione di farlo. O, previsto. Per lo meno, era sempre un'opzione. Thomas Edison disse notoriamente “Non ho fallito. Ho appena trovato diecimila modi che non funzioneranno. La sua filosofia era che con ogni fallimento, era un passo più vicino al successo. In un certo senso, aveva pianificato di fallire. Stava escludendo possibilità. Ha fatto ricorso a tentativi ed errori solo quando ha esaurito le teorie. Non ho più di mille brevetti a mio nome come Edison, ma penso che potremmo avere approcci migliori per lo sviluppo di analisi o report. (Domanda di brevetto Thomas Edison per lampada elettrica a incandescenza 1882.)
11. Stupidità.  Non negarlo. Questo esiste. La stupidità sta da qualche parte tra "Volevi" e "Oops". Questo tipo di fallimento epico è la varietà del Darwin Award: guarda questo, tienimi la birra. Quindi, forse, a volte è coinvolto l'alcol. Fortunatamente, nella nostra professione, per quanto ne so, un cruscotto ubriaco non ha mai ucciso nessuno. Ma, se per te è lo stesso, se lavori in una centrale nucleare, per favore fai le tue analisi da sobrio.
12. Il successo non ha importanza. Il leggendario stuntman Evil Knievel è stato pagato per eseguire acrobazie che sfidano la morte. Successo o fallimento, indipendentemente dal fatto che abbia bloccato l'atterraggio o meno, ha ottenuto un assegno. Il suo obiettivo era sopravvivere. A meno che tu non venga compensato per le ossa rotte - Knievel ha avuto il Guinness World Record per la maggior parte delle ossa rotte in una vita - il successo conta.