בשעה טובה סגרתי ממש החודש 20 שנות ניסיון כדאטה אנליסט …
קשה להאמין שכבר עבר כל כך הרבה זמן, וזו חתיכת תקופה – אבל כן, הזמן לא משקר…
אז לכבוד המאורע החשוב, שבמקרה קרה בסמוך לראש השנה ויום הכיפורים,
הגיע הזמן לסכם את התקופה – עם תובנות עיקריות.
ובשביל לעשות את זה מעניין –
החלטתי גם לחלק את התובנות לפי סדר כרונולוגי,
כלומר – תובנה אחת מרכזית מכל שנה בתחום.
וגם להמחיש את התובנה עם Case Studies מעניינים.
ובגלל שיש כאן הרבה תוכן מעניין, החלטתי לפרק אותו למספר חלקים,
לפי שלבי ההתפתחות בתפקיד:
- התפקיד הראשון – רמת ג'וניור;
- רמת סניור;
- שלב התמחות.
אז בלי הרבה הקדמות –
הנה החלק הראשון, של התובנות מתפקיד הג'וניור.
תהנו!
אייל
2001 – נחיתה רכה יש רק במטוס (וגם זה לא תמיד)
אחרי 4 שנים בלימודי הנדסה, כל מה שרציתי הוא רק להיכנס כבר לתפקיד ולהוכיח את עצמי.
אבל מיד אחרי שנחתתי בתפקיד, הכתה בי המציאות בכל כובד משקלה…
הייתי צריך ללמוד ה-מ-ו-ן חומר:
מערכות, קבצים, עולם התוכן העסקי, אנשי קשר.
לא ידעתי מאיפה בכלל להתחיל, או אילו שאלות לשאול קודם.
והתחלתי לקבל אינסוף טלפונים מאנשי קשר בחברה שדרשו נתונים.
מצאתי את עצמי מיד נשאר עד מאוחר בשביל ללמוד עוד ועוד דברים,
ולהספיק את העבודה – שאין לי עדיין ממש מושג איך לעשות…
ואולי הכי חמור – מהר מאוד גם מצאתי את עצמי לבד.
פשוט, כי מי שהחלפתי אותו – עזב אחרי כמה שבועות.
בלי להשאיר זכר…
התופעה הזו חזרה על עצמה בכל תפקיד חדש אליו נכנסתי,
ואחרי כמה תפקידים סופסוף הבנתי את העניין:
שום דבר לא באמת מכין אותך לתפקיד חדש.
כמעט אף פעם לא יהיה ידע מסודר, מישהו שיוכל להדריך כמו שנרצה.
לכן, היכולת לקפוץ למים וללמוד לשחות, ולהסתדר עם מה שיש היא קריטית.
לתת לעצמנו את האשראי שאנחנו צריכים בשביל להיכנס לעניינים,
וגם ללמוד לסמוך על עצמנו בתהליך.
זה חלק מהתחלת הקריירה בתור אנליסטים, ושיעור חשוב מאוד גם להמשך.
2002 – המהות של דאטה אנליסט היא אפיון, לא קידוד
אני זוכר עד היום את אחת ההחלטות הכי חשובות שקיבלתי בקריירה שלי.
וזה משהו שעשיתי בצורה מאוד אינטואיטיבית – כבר בתחילת הדרך.
ההחלטה: להתמקד באפיון ולא רק בצד הטכני של הקוד.
למה הכוונה?
בארגון שבו עבדתי בתפקיד הראשון היתה מערכת BI ייעודית עם בסיס נתונים מהדור הראשון… שליפת נתונים ממנה חייבה ללמוד קוד מאוד ספציפי – ולא סטנדרטי.
העניין הוא, שהקוד הזה היה נראה לי מאוד מסובך וייחודי.
זה לא היה SQL, אלא משהו שונה – "ליד"…
כבר אז הבנתי, שאם אלמד את הקוד הזה –
מאותה הנקודה אקבע את עצמי לפוזיציה של "כותב הקוד", "הטכנאי",
במקום להתמקד במהות – של לאפיין את הפתרון האנליטי השלם.
אז החלטתי להסתמך על אנשי BI שלמדו את הקוד הספציפי בקורס ייעודי,
כאשר אני מתמקד בלהנחות אותם בדיוק מה התהליך הלוגי שאני מחפש.
או במילים אחרות – אני מאפיין את ה-SQL בראש,
נותן להם לממש אותו בקוד, ואז מוודא שהתוצאה מדויקת.
ואם אני צריך לבצע תהליך לוגי הרבה יותר מורכב –
אני פשוט מאפיין להם כמה שליפות פשוטות,
טוען את תוצאות השליפה לסביבת SQL אצלי –
ואז מבצע את העיבוד המורכב.
אז מצד אחד זה קצת פגע בי בטווח הקצר,
כי הייתי צריך להסתמך על אחרים בשליפת נתונים…
אבל מצד שני, לא בזבזתי את הזמן שלי על טכניקה שלא תעזור לי בעתיד,
ולכן יכולתי להישאר ברמת המהות של הדברים – ברמה הלוגית.
לימים הבנתי שההחלטה הזו אפשרה לי להקפיץ רמה את כל הארגון –
מהפאזה הטכנית, לפאזה של שיפור ביצועים.
אגב – זה לא אומר שלא נגעתי כלל בקוד, או שההחלטה שלי נכונה תמיד;
הרמה הטכנית מאוד חשובה בשביל להבין את התוכן של הנתונים "דרך הידיים".
העניין היה שהקוד של כלי ה-BI הארגוני הספציפי היה בעייתי,
והבנתי שהוא חוטא למהות הלוגית-אפיונית של המקצוע.
השורה התחתונה היא שאסור להתמקד רק בקוד הטכני,
ובטח לא להפוך ל-"טכנאי תשתית נתונים".
במקום, חובה להפנים – שהמהות שלנו כאנליסטים חייבת תמיד להיות ברמה הלוגית-אפיונית:
זה אומר קודם כל לאפיין בדיוק מה המטרה של תהליך עיבוד וניתוח הנתונים,
ורק לאחר מכן לכתוב קוד שיממש את האפיון הזה.
2003 – לחפש את הגישה המנצחת
לאחר כשנתיים בתפקיד, בהם עסקתי בעיקר בשליפת דוחות,
הבנתי בשלב מסוים – שהגישה של שליפת הנתונים (BI) –
פשוט לא מכסה את כל הצרכים האנליטיים של הארגון.
התחלתי לקבל משימות, שחייבו לא רק שליפת נתונים,
אלא גם בעיקר תחזיות או הערכות לצורך תכנון עתידי של משאבים.
משימות כאלו כבר לא היו יכולות להתבסס רק על נתוני עבר,
אלא לכלול גם היבטים של גמישות, הערכות, תרחישים וכיו"ב.
ובהתאם למשימות – חיפשתי גישות אנליטיות נוספות.
מצאתי את עצמי חוקר עבור כל משימה כמה גישות אנליטיות,
לעיתים אפילו מממש מספר גישות בשביל לוודא שהתוצאה דומה.
לדוגמה:
בשביל לחזות נטישה של לקוחות –
אפשר כמובן לשלוף נתוני עבר ולחשב את אחוזי הנטישה;
אבל בנוסף לכך, ניתן להפעיל גם מודל סטטיסטי,
לחשב נוסחה מתמטית – ואפילו להריץ סימולציה.
דוגמה נוספת:
על מנת להקצות תקציב בצורה אופטימלית בין ערוצי שיווק,
ניתן לבצע חישוב לוגי של כל התרחישים ב-SQL;
לחילופין, אפשר להריץ קוד עם לולאות בפייתון,
או אפילו לפתור באמצעות חקר ביצועים (לדוג' Solver באקסל.
ויש כמובן עוד כמה גישות מעניינות לתקוף את האתגר…
על מנת להפוך לאנליסטים תותחים –
חייבים ללמוד, להכיר ולהתנסות בכמה שיותר גישות פתרון אנליטיות,
בשביל שנוכל לבחור את הגישה האופטימלית בהתאם לבעיה הספציפית.
2004 – דאטה אנליסט סביר מוציא תובנות; דאטה אנליסט נינג'ה משפר ביצועים
אחרי כמה שנים שבהן ניסיתי להבין מי נגד מי,
וטבעתי בים של בקשות טכניות – הבנתי שאי אפשר להמשיך ככה.
להיות "ספק דוחות" ו-"אינסטלטור של נתונים" זה משהו שממש לא תורם לי ורק שוחק אותי.
והוא בטח שלא עוזר לארגון, כי אני מנציח בזה את הבינוניות של להסתפק בדוחות סיזיפיים ולא יעילים.
בנקודה הזו, אחרי שחיקה בלתי נתפסת – סופסוף הייתי בשל לשינוי דרמטי.
והשינוי הגיע מגישה אחרת לחלוטין:
במקום לייעל את הזמן שלי בשביל להוציא יותר דוחות בזמן נתון,
הבנתי שאני חייב להסתכל מערכתית על מה יעזור לכל הארגון.
או במילים אחרות:
במקום רק להוציא דוחות ולנתח אותם, ובמקרה הטוב לקבל תובנות…
ה-Next Level הוא לחפש איך אפשר לשפר את תהליכי העבודה וקבלת ההחלטות.
שיפור תהליכי העבודה וקבלת ההחלטות משפיעים ישירות על הפעולות שהארגון יבצע,
וכשעושים פעולות מבוססות מידע – משפיעים באופן ישיר גם על הביצועים.
מה שהתחלתי לעשות הוא לאפיין את הצורך האמיתי מאחורי כל בקשה לדוח או משימה אנליטית – קטנה כגדולה.
האפיון הזה כלל הבנה של המטרה – הצורך העסקי, והשימוש בדוחות.
ולאחר מכן – הסדרה של תהליך העבודה מול הגורם הרלוונטי,
כלומר – להפוך תהליכים "שוטפים" לתהליכים תקופתיים – אחת לשבוע, אחת לחודש.
וכאשר הדבר הזה מוסדר – אפשר לבנות מנגנון מבוסס נתונים בשביל לתמוך בתהליך.
בצורה כזו – עומס העבודה יורד, ובנוסף איסוף הנתונים מאפשר בקרה עקבית וזיהוי הזדמנויות לשיפור.
זה מה שמאפשר לנו להקפיץ את ביצועי הארגון בכמה רמות.
2005 – חייבים שיהיה חזון אנליטי
אחרי כ-3 שנים בתפקיד – התחלתי פחות או יותר למצות את העניין…
העבודה השוטפת כבר היתה הרבה מאחוריי,
הבנתי בדיוק מה מצופה ממני לעשות,
ואפילו סיימתי לייעל את המשימות החוזרות באמצעות אוטומציות כאלו או אחרות –
מה שעזר מאוד לארגון.
בנקודה הזו שאלתי את עצמי:
"אוקיי, אז מה עכשיו?"
ואז התחלתי תהליך של כמה שבועות, שבו ניסיתי להבין (שוב):
- איך אפשר לדחוף את הארגון ל-Next Level הבא שלו?
- איפה ההזדמנויות המעניינות?
- היכן צווארי הבקבוק וחוסר היעילות בארגון?
- מה נוכל לחקור ולשפר?
- אילו תופעות מעניין אותנו לנתח לעומק ולהפיל את המנהלים מהכיסא?
- מהן המגמות שאנחנו הולכים לפגוש בעתיד?
התחלתי למפות מספר נושאים שעניין אותי לחקור, והתחלתי להניע פרויקטים בנושא.
הארגון אמנם לא ציפה ממני לעשות את זה, אבל זה היה חזק ממני –
פשוט היה בי דרייב עצום לחפש את הדבר הבא,
את הממצא הבא שיטיס את הארגון קדימה.
הדרייב הזה גרם לי לחקור תופעות ולהגיע לתובנות פורצות דרך –
חלקן בשימוש עד היום.
וכמובן – שהמנהלים היו בשוק מהתובנות, הם פשוט לא ציפו להן.
עד כדי כך – שנתנו לי להקים פעילות מחקרית כזו מאפס.
והפעם – בצורה מסודרת ומתוכננת, במקום כיוזמה אישית שלי…
מצב כזה מגיע מיד, אבל קריטי שהדרייב הזה תמיד יהיה קיים.
משעמם לך בעבודה הנוכחית בתור דאטה אנליסט?
יש לך 3 אפשרויות:
- להמשיך ולהשתעמם (ולעיתים גם להתבכיין על זה…)
- לקום ולעזוב, בתקווה שבמקום הבא יהיה יותר מעניין (ולא תמיד זה קורה).
- ליזום – לצאת מאיזור הנוחות – ולפעמים גם להגיע לתוצאות מדהימות.
לפחות על סמך הניסיון שלי –
בדיוק בנקודות הללו תגענה קפיצות המדרגה המקצועיות הכי גדולות בקריירה.
2006 – לדעת מתי הגיע הזמן לעבור לאתגר הבא
עד השלב הזה כבר עברתי מסלול שלם בארגון:
- כניסה לתפקיד ולימוד עולם התוכן.
- ייעול תהליכי העבודה.
- דחיפת פרויקטים אנליטיים להקפצת הרמה האנליטית והביצועים בארגון.
ולמען האמת – כבר התחלתי להרגיש מיצוי מסוים.
הבנתי, שכבר למדתי כל מה שאפשר במסגרת הנוכחית,
כבר שיפרתי בגדול מה שהיה אפשר,
וגם דחפתי קדימה את הארגון כמה שיכולתי.
בשלב הזה – הגעתי לצומת דרכים.
זה קורה לכולנו, וזהו שלב טבעי וחיובי מאוד בקריירה –
לבחון את האפשרויות, ולהבין שהגיע הזמן לעבור לאתגר הבא.
התובנה החשובה בשלב הזה, היא לזהות את הנקודה המדויקת שבה כדאי לעשות שינויים.
וכמובן – להעיז לעשות אותם…
בגדול, ישנם שני מקרי קצה שכדאי להימנע מהם:
מצד אחד, להרים ידיים מהר מאוד – לעיתים חודשים ספורים מתחילת התפקיד.
לפעמים זה מוצדק, אם ישנו חוסר התאמה עם האווירה בארגון, בעיה מול המנהלים, או אפילו פער קיצוני בציפיות בין מה שתואר בראיונות העבודה, ובין המשימות בפועל.
אבל כבר נתקלתי בלא מעט אנשים, שאצלם מדובר במנגנון אישיותי שמקשה עליהם להתמיד במשרה אחת במשך תקופה.
וכך הם מפספסים את מסלול ההתפתחות הטבעי בתור אנליסטים,
ובהרבה מקרים שורפים את עצמם במשרות שדווקא מאוד יכולות לסייע להם בקריירה.
המקרה ההפוך, הוא להיתקע באותו המקום הרבה מאוד שנים.
בהתחלה אולי יהיה לנו נחמד, ונלמד הרבה.
יחד עם זאת, ככל שיעבור הזמן, נוכל למצוא את עצמנו במצב שבו עברו 10 שנים,
ואנחנו כבר לא ממש רלוונטיים בשוק.
לחלק מהאנשים מתאימה קריירה ארוכה במקום יחיד,
אנשים אחרים חייבים דינמיות.
קריטי להבין איפה אתם נמצאים, ולזהות את הנקודה שבה יש לעשות שינוי ולחפש את האתגר הבא.
אצלי זה קרה באיזור ה-3-5 שנים אחרי הכניסה לתפקיד,
אבל זה כנראה משתנה קצת יותר או פחות לכל אדם.
זיהוי הנקודה המדויקת להחלפת תפקיד היא מיומנות מהותית שעלינו לפתח בשביל לפתח קריירה מפוארת בתחום.
לכן, קריטי ללמוד להקשיב לעצמנו,
לזהות את האיתותים שאולי מיצינו את התפקיד –
ולהבין אם הן אכן איתותים אמיתיים,
ואחרי שהגענו לנקודת הבנה שהגיע הזמן לעבור לאתגר הבא –
ללמוד גם לצאת מאיזור הנוחות ולקחת החלטות אמיצות.
לא פשוט, מפחיד – אבל הכרחי.
ועם הנקודה הזו – מסתיים החלק הראשון ב-20 התובנות של סיכום 20 השנים הראשונות כדאטה אנליסט.
ההמשך – בחלק הבא!