שניים בקופסה (אם אפשר) וכולם בתיעוד (תמיד).
בהקשר של IT, "שניים בקופסה" מתייחס לשני שרתים או רכיבים שנועדו לעבוד יחד כדי לספק יתירות ואמינות מוגברת. הגדרה זו יכולה להבטיח שאם רכיב אחד ייכשל, השני ישתלט על פעילותו, ובכך ישמור על המשכיות השירות. המטרה של "שניים בקופסה" היא לספק זמינות גבוהה והתאוששות מאסון. זה חל גם על תפקידים אנושיים בארגון; עם זאת, הוא מיושם לעתים רחוקות.
בואו נסתכל על דוגמה רלוונטית ל-Analytics. סביר להניח שכולנו מכירים אדם בחברה או בארגון שלנו בשמו שהוא האדם ה"מכוון" ל-Analytics. הם אלה שיש להם דוחות או לוחות מחוונים על שמם - הדוח של מייק או לוח המחוונים של ג'יין. בטח, יש אנשים אחרים שמכירים אנליטיקה, אבל אלו האלופים האמיתיים שנראה שהם יודעים לעשות את הדברים הקשים ביותר ולהשיג יתר על המידה במועדים. הבעיה היא שהאנשים האלה עומדים לבד. במקרים רבים תחת לחץ, הם לא עובדים עם אף אחד שכן זה עלול להאט אותם וכאן מתחילה הבעיה. אנחנו אף פעם לא חושבים שאנחנו הולכים לאבד את האדם הזה. אני אמנע מהאופייני "נניח שהם נפגעו מאוטובוס" או שימוש בדוגמה הממנפת את ההזדמנויות הנוכחיות בשוק העבודה ואומר משהו חיובי כמו "הם זכו בלוטו!", כי כולנו צריכים לעשות את חלקנו כדי להיות חיוביים בימים אלה.
הסיפור
יום שני בבוקר מגיע, ומומחה האנליטיקה והאלוף שלנו MJ הגיש את התפטרותם. MJ זכתה בלוטו וכבר עזבה את הארץ ללא טיפול בעולם. הצוות והאנשים שמכירים את MJ נרגשים ומקנאים, אך העבודה חייבת לצאת. כעת עומדים להבין את הערך והמציאות של מה ש-MJ עשה. MJ הייתה אחראית על הפרסום והאימות הסופי של הניתוח. נראה היה שהם תמיד מסוגלים לשפר את היעילות או לבצע את השינוי הקשה הזה לפני שסיפקו את האנליטיקה לכולם. לאף אחד לא היה אכפת באמת איך זה נעשה והיה בטוח בעובדה שזה קרה עכשיו, ו-MJ היה רוק סטאר אינדיבידואלי של אנליטיקס, כך שהוענקה רמה של אוטונומיה. עכשיו כשהצוות מתחיל לאסוף את השברים, הבקשות, הבעיות היומיומיות, בקשות השינויים, הם אובדי עצות ומתחילים להסתבך. דוחות / לוחות מחוונים נמצאים במצבים לא ידועים; חלק מהנכסים לא עודכנו במהלך סוף השבוע, ואנחנו לא יודעים למה; אנשים שואלים מה קורה ומתי הדברים יתוקנו, עריכות ש-MJ אמר שנעשו לא מופיעות ואין לנו מושג למה. הקבוצה נראית רע. זה אסון ועכשיו כולנו שונאים את MJ.
השיעורים
יש כמה נקודות טייק-אווי קלות וברורות.
- לעולם אל תאפשר לאדם לעבוד לבד. נשמע טוב אבל בצוותים זריזים קטנים יותר, אין לנו זמן או אנשים לגרום לזה לקרות. אנשים באים והולכים, המשימות הן רבות, אז זה חלוק וכבש בשם הפרודוקטיביות.
- כל אחד חייב לחלוק את הידע שלו. גם נשמע טוב אבל האם אנחנו חולקים עם האדם או האנשים הנכונים? זכור שהרבה זוכים בלוטו הם עמיתים לעבודה. ביצוע מפגשי שיתוף ידע גם לוקח זמן מהמשימות ורוב האנשים משקיעים רק במיומנויות ובידע בדיוק בזמן שיש צורך בכך.
אז מה הם כמה פתרונות אמיתיים שכל אחד יכול להיות מסוגל ליישם ולעמוד מאחוריהם?
נתחיל עם ניהול תצורה. נשתמש בזה כמונח גג למספר נושאים דומים.
- שינוי הנהלה: תהליך תכנון, הטמעה ובקרה של שינויים במערכות תוכנה בצורה מובנית ושיטתית. תהליך זה נועד להבטיח ששינויים יבוצעו בצורה מבוקרת ויעילה (עם יכולת חזרה), עם מינימום הפרעה למערכת הקיימת ומקסימום תועלת לארגון.
- ניהול פרוייקט: תכנון, ארגון ובקרה של פרויקטים לפיתוח תוכנה על מנת להבטיח את השלמתם בזמן, במסגרת התקציב ובתקני האיכות הרצויים. זה כרוך בתיאום של משאבים, פעילויות ומשימות לאורך מחזור החיים של פיתוח התוכנה כדי להשיג את יעדי הפרויקט ולספק את מוצר התוכנה בזמן.
- אינטגרציה רציפה ואספקה רציפה (CI/CD): תהליך האוטומציה של הבנייה, הבדיקות והפריסה של תוכנה. אינטגרציה מתמשכת דורשת מיזוג קבוע של שינויי קוד למאגר משותף והפעלת בדיקות אוטומטיות כדי לזהות שגיאות בשלב מוקדם בתהליך הפיתוח. אספקה/פריסה רציפה כוללת שחרור אוטומטי של שינויי קוד שנבדקו ומאומתים לייצור, מה שמאפשר שחרור מהיר ותכוף של תכונות ושיפורים חדשים.
- בקרת גרסה: תהליך ניהול שינויים בקוד המקור וחפצי תוכנה אחרים לאורך זמן באמצעות כלי תוכנה מיוחדים. זה מאפשר למפתחים לשתף פעולה על בסיס קוד, לשמור על היסטוריה מלאה של שינויים ולהתנסות בתכונות חדשות מבלי להשפיע על בסיס הקוד הראשי.
כל האמור לעיל מתייחס לנוהלי פיתוח תוכנה טובים. אנליטיקה שמניעה ומנהלת את העסק ראויה לא פחות מכיוון שהם קריטיים למשימה לקבלת החלטות. כל נכסי האנליטיקה (משרות ETL, הגדרות סמנטיות, הגדרות מדדים, דוחות, לוחות מחוונים, סיפורים וכו') הם רק קטעי קוד עם ממשק חזותי לעיצוב ושינויים מינוריים לכאורה יכולים להסריח את הפעולות.
שימוש בניהול תצורה מכסה אותנו כדי להמשיך לפעול במצב טוב. נכסים מנוסחים כך שנוכל לראות מה קרה בתקופת חייהם, אנחנו יודעים מי עובד על מה יחד עם ההתקדמות שנעשתה ולוחות הזמנים, ואנחנו יודעים שההפקה תימשך. מה שלא מכוסה בשום תהליך טהור הוא העברת הידע וההבנה מדוע הדברים הם כפי שהם.
לכל מערכת, מסד נתונים וכלי ניתוח יש את המוזרויות שלהם. דברים שגורמים להם ללכת מהר או לאט, פריטים שגורמים להם להתנהג בצורה מסוימת או לייצר תוצאה רצויה. אלה יכולות להיות הגדרות ברמה מערכתית או גלובלית או דברים בתוך עיצוב הנכס שגורמים להם לפעול בדיוק כפי שהם צריכים. הבעיה היא שרוב הדברים הללו נלמדים עם הזמן ולא תמיד יש מקום לתעד אותם. גם כשאנחנו עוברים למערכות ענן שבהן אנחנו כבר לא שולטים איך האפליקציה פועלת ואנו סומכים על הספק שיעשה את זה מהר ככל האפשר, השינוי של ההגדרות נמשך בתוך הנכסים שלנו כדי לפתוח בדיוק את מה שאנחנו מחפשים. הידע הזה הוא מה שצריך לתפוס ולשתף על ידי הפיכתו לזמין לאחרים. ידע זה חייב להידרש כחלק מתיעוד הנכסים ולהפוך אותו לחלק בלתי נפרד מתהליך בקרת הגרסאות ו-CI/CD צ'ק-אין ואישור ובמקרים מסוימים אף כחלק מרשימת בדיקה לפני פרסום של דברים לעשות ולא לַעֲשׂוֹת.
אין תשובות קסם או בינה מלאכותית לכסות על קיצורי דרך בתהליכי הניתוח שלנו או על היעדרם. ללא קשר לגודל הצוות ששומר על זרימת הנתונים והניתוחים, השקעה במערכת למעקב אחר שינויים, גרסת כל הנכסים ועזרה בתיעוד תהליך הפיתוח ותפיסת ידע היא חובה. השקעה בתהליכים ובזמן מראש תחסוך המון זמן בזבוז מאוחר יותר בהבנת דברים כדי לשמור על מצב בריא של הניתוח שלנו. דברים קורים והכי טוב שתהיה פוליסת ביטוח עבור MJs ושאר זוכי לוטו.
