צוות פרויקט Salesforce: תפקידים, אחריות ומודל עבודה מול הספק

התפקידים שקובעים את קצב הפרויקט

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

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

תשעת התפקידים והמנדט של כל אחד

Executive Sponsor — מכריע בין מחלקות, מאשר ויתורים על Scope ומגן על העדיפות מול לחצים מקבילים. אם אין לו סמכות תקציבית, הוא אינו Sponsor אלא נציג.

בעל תהליך — מגדיר איך העבודה תתבצע בפועל אחרי השינוי, ומאשר שהתהליך שנבנה תואם למציאות. אחד לכל תהליך ליבה, לא ועדה.

Product Owner / מנהל CRM — מנהל את סדר העדיפויות בבקלוג, מכריע בין בקשות מתחרות ומחזיק את הקשר בין דרישות לבין ערך.

מנהל פרויקט — לוח זמנים, תלויות, סיכונים, תיאום ספקים ודיווח.

ארכיטקט פתרון — מכריע במודל נתונים, בהרשאות, בגבולות מערכת ובאופן המימוש; אחראי לתעד חלופות שנשקלו.

Salesforce Admin — קונפיגורציה, סביבות, ניהול משתמשים ותחזוקה שוטפת אחרי העלייה.

מפתח — לוגיקה מותאמת, אינטגרציות, בדיקות אוטומטיות.

בעלים לנתונים — קובע מה מקור אמת, מה נחשב רשומה תקינה ומי מאשר טעינה.

מוביל אימוץ והדרכה — תקשורת, הכשרה לפי תפקיד, ניהול התנגדות ומדידת שימוש.

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

מי חייב להיות פנימי

טבלת RACI לנקודות ההכרעה המרכזיות

עמודת זמן התגובה היא החלק המעניין בטבלה. RACI בלי SLA להחלטה הוא תיאור נחמד שלא משנה את הקצב.

זמינות ריאלית — הטעות שחוזרת בתכנון

התכנון הכושל הנפוץ הוא הנחה שעומס בעל התהליך יורד אחרי האפיון. בפועל הוא עולה שוב בשלב הבדיקות, בדיוק כשהעובד חוזר לעבודתו השוטפת.

דוגמה להמחשה: מכללה אקדמית

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

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

מודל העבודה מול הספק

שלושה מנגנונים מספיקים לרוב הפרויקטים:

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

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

נקודות המפגש עם שלבים אחרים

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

בדיקה מהירה לפני תחילת פרויקט

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