כמה זמן לוקח לנו לפתח מוצר? כמה זמן לוקח להוציא פיצ’ר חדש? איפה “מתחיל” פיצ’ר? איך אפשר לראות את התמונה המלאה, שבה פיצ’ר מתחיל במחלקות השיווק והמכירות, קרוב כמה שאפשר לתיאור של מה שהלקוחות רוצים, ועד לתכולה שהפיתוח מפתח? אתאר את השלב הראשון בדרך שבו חיברנו את המערכות לכדי תהליך אחד רציף. החיבור הטכנולוגי שאותו אני מתארת בעצם הוא רק ההתחלה של קבלת התובנות העמוקות על צווארי בקבוק, אחוזים של יכולות מפותחות אל מול פרויקטים ועוד ועוד. הדרך עוד ארוכה.
נקודת היציאה לדרך – תפיסת מבוססת Silo’s
נקודת היציאה שלנו לדרך היתה שהפיתוח קורה בג’ירה. ניהול הלקוחות מתרחש בסיילספורס. כמו בארגונים רבים אחרים שהתפתחו בקצב מסחרר ובצורה אורגנית, כל מחלקה פיתחה לעצמה את הכלים המתאימים לה והמשרתים אותה. כל אחת מתמקדת בריצה המהירה ביותר שהיא יכולה לעשות כדי להשיג את המטרות שלה.
מעבר לחיבור מערכות בין השיווק לניהול הפיתוח כ- Post sale
במסגרת ה- Scale למחלקת הפיתוח, בוצע תהליך גדול בפיתוח שמטרתו היתה לייצר שיטת עבודה אחידה בתוך מערכת הג’ירה (כפי שמתואר כאן), כך שהגי’רה הפכה להיות Single Source of Truth לתוכניות הפיתוח והחליפה כל מיני אקסלים ושיטות אחרות שהיו קיימות בעבר. השיטה הזו ייצרה תוכנית אחודה וברורה למחלקת הפיתוח המתארת את התפתחות הפיצ’רים מהתחלה ועד לאימפלמנטציה בקרב הלקוחות.
במקביל לתהליך האחדה ויצירת תהליכי עבודה מסודרים בג’ירה, תהליכי המכירות ב- SalesForce עברו אף הם תהליך שיפור וסידור. תהליכים אלו ייצרו את היכולת הבסיסית ואת המוטיבציה לחבר את שתי המערכות על מנת לאפשר זרימה מתחילת הצפת הצורך בפיצ’ר מסוים ועד שהוא יוצא ללקוחות. המטרה שעמדה מאחורי יצירת התהליך הרציף היתה לוודא שהפרויקטים שנחתמים תואמים את אסטרטגיית המוצר (“מוכרים מה שרוצים ולא מה שאפשר”) וכן וידוא ויצירת הלימה ותיאום ציפיות מוקדם בין זמני אספקת הפרויקטים לבין היכולת לעמוד בהם בפיתוח תוך הסתכלות על התעדוף וחשיבות המוצר הספציפי שנמכר והלקוח, משך זמן הפיתוח המשוער של הפיצ’רים החדשים הנוספים וכו’. אבל איך יוצרים את הסנכרון הזה מבחינת מערכות המידע?
איך יוצרים חיבור ממחלקת השיווק והמכירות למחלקת הפיתוח ובפועל יוצרים תהליך אחיד ורציף טכנולוגית?
התהליך מתחלק למספר שלבים מרכזיים:
שלב 1 – מפרויקט ב Salesforce לחיבור ראשוני עם מחלקות המוצר והפיתוח: Deal Scoping
פרויקט חדש שדורש פיתוח עובר סבב אישורים עקרוניים במחלקות השונות בהיבטים שונים כגון היבטים משפטיים, כדאיות כלכלית וכו’. כחלק מתהליך זה, מתבצעות שיחות ראשוניות עם המוצר והפיתוח על מנת לקבל פידבק ברור על הפיצ’רים שאמורים לפתח במסגרת הפרויקט לפני שהוא נחתם. המטרה היא למנוע “גול עצמי” שבו אנו חותמים על פרויקט ובו ריבוי יכולות מאוד ייעודיות ללקוח או מורכבות בצורה יוצאת מן הכלל או שאינן תואמות את האסטרטגיה. שלב זה מסתיים כאשר החוזה נחתם או מאוד קרוב לכך, או נדחה.
כל פרויקט אשר דורש את מעורבות הפיתוח היה נפתח בעבר ב- Salesforce ומנוהל באקסלים ומיילים בין הפיתוח לשיווק. בעקבות יצירת החיבור, כל פרויקט שדורש פיתוח, עובר סנכרון לג’ירה, ובו שדות רבים מה- Salesforce עוברים באופן אוטומטי לג’ירה. כל פרויקט הופך להיות Epic, בתהליך Workflow ייחודי שמאפשר ניתוח הפרויקט עבור הפיתוח וקבלת החלטות. באופן יוצא דופן, בשל ריבוי השדות הייעודיים ותהליך ה- Workflow הייחודי, ניהול הפרויקט בפרויקט מסוג Team Managed בג’ירה, מסוג Business Project. בימים אלו מתבצעת ההמרה של הפרויקט לפרויקט מסוג Company managed ועמה יבוא שינוי בתפיסת ההמרה.
שלב 2 – הערכות מקדימות לפני כניסה לפיתוח: Deep Scoping
מרגע שהפרויקט נחתם או קרוב לכך, הפרויקט מתורגם לרשימת הפיצ’רים הנדרשת לפיתוח לטובת הפרויקט. בשלב זה, כל פיצ’ר חדש שנדרש הופך להיות פיצ’ר (epic) משל עצמו. מתנהלים סביבו דיוני הגדרה מוצרית, הגדרות ארכיטקרטורה והערכת זמנים גסה לפיתוח על בסיס מורכבות הפיתוח, חדשנות הפיתרון הטכנולוגי.
שלב זה מתנהל בפרויקט ג’ירה מסוג Company Managed, באותם מבנים ושדות כמו פרויקטי הפיתוח מתוך הבנה שזה שלב ה- Scoping שבתוך תהליך הפיתוח של החברה (SDLC – software Development Life Cycle). עם זאת, זהו שלב ייעודי שנפרד מתוכנית הפיתוח עצמה.
שלב 3 – הכנסה לפיתוח: Engineering Workplan
לקראת כל רבעון כל הפיצ’רים שנבחרו/נועדו להיות מפותחים ברבעון, מועברים משלב ה- Deep Scoping לתוכנית העבודה של הפיתוח. התשתיות וההגדרות המשותפות של הפיתוח וה- Deep Scoping מאפשרות למעבר הזה להיות חלק. במסגרת המעבר, הפיצ’ר עצמו מועבר, ומגדירים לו את כל המנהלים המתאימים (Executive Sponsor, Tech Lead, QA Lead, Architecture Lead וכו’), בניית תוכנית הפיתוח בגדול על אבני הדרך השונות ותוכנית העבודה על ידי פירוק הפיצ’ר למשימות בג’ירה של הפונקציות השונות המעורבות – משימות העיצוב, כתיבת ה- PRD, ומשימות הפיתוח עצמן לצוותיהם השונים, כולל האינטגרציה שתידרש.
שלב זה מתנהל בפרויקט ריכוזי של כלל הפיתוח מסוג Company managed, במתודולוגיה שתתואר בפוסט נפרד.
לסיכום, ניתן לראות כיצד עברנו ממקום שבו כל מחלקה מנהלת בנפרד את ה-pipeline שלה לתהליך רציף, שיש בו ניהול סדור בכל שלב מבחינת מטרה, אחריות ותהליך שמאפשר זרימה רציפה של פרויקט לכדי רשימת פיצ’רים והכנסתם לתוכנית העבודה של הפיתוח.
האם גם אתם אנשי אופרציה העוסקים בתהליכי עבודה, מתודולוגיות וכלים בעולמות הפיתוח? אם כן, נשמח שתצטרפו לקבוצת Engineering Operations בוואטסאפ ותעקבו אחרינו בעמוד ה- Linked In שלנו.