12 סיבות לכישלון באנליטיקה ובבינה עסקית

מספר 9 עשוי להפתיע אותך

באנליטיקה ובינה עסקית, יש הרבה דברים שיכולים להשתבש. אנחנו, אחרי הכל, מחפשים את הגרסה הבודדת של האמת. בין אם זה דוח או פרויקט – כדי שהנתונים והתוצאות יצאו עקביים, ניתנים לאימות, מדויקים ובעיקר מקובלים על משתמש הקצה – יש הרבה חוליות לשרשרת שצריכות להיות נכונות. הפרקטיקה של אינטגרציה מתמשכת, שהומצאה על ידי מפתחי תוכנה ונשאלה על ידי קהילת האנליטיקה והבינה העסקית, היא ניסיון לתפוס טעויות או שגיאות מוקדם.  

ובכל זאת, טעויות מתגנבות לתוצר הסופי. למה זה לא בסדר? הנה כמה תירוצים הסיבות לכך שלוח המחוונים שגוי, או שהפרויקט נכשל.

1. זה יהיה מהיר יותר.  כן, זה כנראה נכון. זה עניין של פשרות. איזה אתה מעדיף? האם אתה רוצה את זה מהר או שאתה רוצה לעשות את זה כמו שצריך?   למען האמת, לפעמים מעמידים אותנו במצב הזה. אני צריך את זה עד יום שישי. אני צריך את זה היום. לא, הייתי צריך את זה אתמול. הבוס לא שאל כמה זמן זה ייקח. הוא אמר לי לנו כמה זמן היינו צריכים לעשות את זה. כי זה הזמן שבו Sales צריך את זה. כי זה הזמן שבו הלקוח רוצה את זה.    
2. זה יהיה מספיק טוב.  השלמות היא בלתי אפשרית וחוץ מזה השלמות היא אויב הטוב. ה ממציא מכ"ם האזהרה המוקדמת של תקיפה אווירית הציע "כת הבלתי מושלמים". הפילוסופיה שלו הייתה "תמיד תשאף לתת לצבא את השלישי הטוב ביותר כי הטוב ביותר הוא בלתי אפשרי והשני הטוב ביותר הוא תמיד מאוחר מדי." נשאיר את כת הבלתי מושלמים לצבא. אני חושב שהנקודה של התקדמות זריזה ומצטברת לקראת התוצאה הסופית מתפספסת כאן. במתודולוגיה Agile, יש את הרעיון של מינימום Viable Product (MVP). מילת המפתח כאן היא בַּר חַיִים.  זה לא מת עם ההגעה וזה לא נעשה. מה שיש לך הוא נקודת ציון במסע ליעד מוצלח.
3. זה יהיה זול יותר.  לא באמת. לא בטווח הארוך. זה תמיד עולה יותר לתקן את זה מאוחר יותר. זול יותר לעשות את זה נכון בפעם הראשונה. עבור כל שלב שהוסר מהקידוד הראשוני, העלות גבוהה בסדר גודל. סיבה זו קשורה בראשונה, מהירות המסירה. שלושת הצדדים של משולש ניהול הפרויקט הם היקף, עלות ומשך זמן. אתה לא יכול לשנות אחד מבלי להשפיע על האחרים. אותו עיקרון חל כאן: בחר שניים. טוֹב. מָהִיר. זוֹל.  https://www.pyragraph.com/2013/05/good-fast-cheap-you-can-only-pick-two/
4. זה רק POC. זה לא שאנחנו הולכים להכניס את הוכחת הקונספט הזו לייצור, נכון? זה עוסק בהגדרת ציפיות כראוי. POC הוא בדרך כלל מוגבל בזמן עם קבוצה מסוימת של יעדים או מקרי שימוש כדי להעריך את היישום או הסביבה. מקרי שימוש אלה מייצגים פריטי חובה או דפוסים נפוצים. אז, הערכת POC, בהגדרה, היא חלק מהעוגה הגדולה יותר שעליה אנחנו יכולים לבסס החלטות נוספות. זה לעתים רחוקות אף פעם לא רעיון טוב להכניס POC לייצור, בין אם זה תוכנה או חומרה.    
5. זה רק זמני. אם התוצאות שגויות, הוא מתפקד גרוע, או שהוא פשוט מכוער, הוא לא היה צריך לברוח לייצור. גם אם זו פלט ביניים, זה צריך להיות ייצוגי. משתמשי קצה ובעלי עניין לא יקבלו זאת. האזהרה היא, עם זאת, זה עשוי להיות מקובל אם אלו הן הציפיות שנקבעו כחלק מהתהליך. "המספרים נכונים, אבל נשמח לקבל ממך משוב על הצבעים בלוח המחוונים." ובכל זאת, זה לא אמור להיות בהפקה; זה צריך להיות בסביבה נמוכה יותר. לעתים קרובות מדי, "זה רק זמני" הופך לכוונות הטובות של בעיה קבועה.
6. זו הדרך היחידה שאני יודע.  לפעמים יש יותר מתשובה אחת נכונה. ולפעמים יש יותר מנתיב אחד להגיע ליעד. לפעמים אנחנו מביאים איתנו את ההרגלים הישנים שלנו. הם מתים קשה. השתמש בזה כרגע למידה. למד בדרך הנכונה. קח את הזמן. לבקש עזרה.  
7. זו הדרך שתמיד עשינו את זה. קשה לתקן את זה וקשה להתווכח איתו. נדרש ניהול שינויים ארגוניים אמיתיים כדי לשנות תהליכים ואת האנשים שמבצעים אותם. לעתים קרובות, פרויקט חדש, תוכנה חדשה, שדרוג או הגירה, יחשפו בעיות נסתרות זמן רב. זה הזמן לשינוי.  
8. אופס, אני עשיתי את זה שוב. אני עובד עץ ויש לנו מוטו כי נעשות כל כך הרבה טעויות: למדוד פעמיים ולחתוך פעם אחת. אני מכיר את הפרשה הזו. אני חוזר על זה לעצמי. אבל, אני נבוך לומר, יש עדיין מקרים שבהם הלוח שלי קצר מדי. האם זו חוסר זהירות? אוּלַי. עם זאת, לעתים קרובות יותר מאשר לא, זה פשוט משהו מהיר וקל. אני לא באמת צריך תוכנית. אבל אתה יודע מה? אם הייתי לוקח את הזמן לשרטט את זה על תוכנית, רוב הסיכויים שהמספרים היו מעובדים. ייתכן שהיצירה הקצרה מדי הייתה על הנייר ומחק היה מתקן אותה. הדבר נכון גם לגבי אנליטיקה ובינה עסקית, תוכנית - אפילו למשהו מהיר וקל - יכולה להפחית טעויות מסוג זה.     
9. הסחות דעת. מסתכל אבל לא רואה. עיוורון חסר תשומת לב. אולי ראית את וידאו שבו ניתנת לך משימה לעשות, כמו לספור את מספר מסירות הכדורסל לקבוצה אחת. בזמן שאתה מוסח בביצוע המשימה הפשוטה הזו, [SPOILER ALERT] אתה לא מבחין בגורילה ההולכת על הירח. ידעתי מה עומד לקרות ועדיין הייתי מעיד עד נורא אם היה מבוצע פשע. אותו דבר קורה בפיתוח דוחות. הדרישות דורשות יישור פיקסלים מושלם, הלוגו חייב להיות מעודכן, יש לכלול את הוויתור המשפטי. אל תתנו לזה להסיח את דעתכם מלוודא שהחישובים תקפים.   
10. התכוונת. או, צפוי. לכל הפחות, זו תמיד הייתה אופציה. תומס אדיסון אמר באופן מפורסם "לא נכשלתי. הרגע מצאתי עשרת אלפים דרכים שלא יעבדו". הפילוסופיה שלו הייתה שעם כל כישלון, הוא היה צעד אחד קרוב יותר להצלחה. במובן מסוים, הוא תכנן להיכשל. הוא שלל אפשרויות. הוא פנה לניסוי וטעייה רק ​​כשנגמרו לו התיאוריות. אין לי יותר מאלף פטנטים על שמי כמו אדיסון, אבל אני חושב שאולי יהיו לנו גישות טובות יותר לפיתוח ניתוח או דוחות. (בקשת פטנט של תומאס אדיסון על מנורה חשמלית ליבון 1882.)
11. טִפּשׁוּת.  אל תכחיש את זה. זה קיים. הטיפשות נמצאת איפשהו בין "התכוונת" ל"אופס". סוג זה של כישלון אפי הוא מגוון ה-watch-this-thous-beer-my, פרס דרווין. אז, אולי, לפעמים מעורב אלכוהול. למרבה המזל, במקצוע שלנו, עד כמה שידוע לי, לוח מחוונים שיכור לא הרג אף אחד. אבל, אם הכל זהה לך, אם אתה עובד בתחנת כוח גרעינית, אנא עשה את הניתוח שלך בצורה מפוכחת.
12. ההצלחה לא משנה. הפעלולן האגדי Evil Knievel קיבל תשלום עבור ביצוע פעלולים מתריסים למוות. הצלחה או כישלון - בין אם תקע את הנחיתה או לא - הוא קיבל צ'ק. המטרה שלו הייתה לשרוד. אלא אם כן תקבל פיצוי על עצמות שבורות - לקניבל היה שיא גינס עבור רוב העצמות השבורות בחיים - ההצלחה כן חשובה.