קייס סטאדי - 5 מרכיבים לפרויקט אוטומציה מוצלח!

הפחידו אותנו שיהיה זוועה!!

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

מערך המכירות של החברה מנוהל בפייפדרייב ואילו מערך התפעול והנהלת החשבונות ב-ERP של פריוריטי. טבעי שתהיה אינטגרציה בין המערכות – ואכן הייתה, אבל היא לא עבדה בצורה טובה.

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

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

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

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

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

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

אחרי QA מאסיבי שלנו ושל הלקוחות (עוד על זה בהמשך) זה עובד מעולה!

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

רציתי לחלוק כאן את הגורמים שתרמו להצלחה:

שותף לדרך

כל הממשק שהיה בין פייפדרייב לפריוריטי היה מבוסס על זאפייר – ונהיה ברור שזה לא מספיק טוב. 

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

אמרנו למנהל ה-IT בחברה, מוטי, דבר פשוט: תן לנו מישהו מהצד של פריוריטי (יותר נכון מטמיע של פריוריטי) שיכול לדבר איתנו בשפת ה-API בצורה טובה. שנוכל לנהל איתו שיח אינטיליגנטי ולשאול שאלות – בדיוק כפי שעשינו עם כל המערכות האחרות שממשקנו לפייפדרייב: משולם, Stripe, איירטייבל, Arrivy, חנות הווקומרס של החברה. כל הממשקים שיצרנו לחברה מול ה-CRM.

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

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

ברגע שהיה מולנו פרטנר טוב – יכולנו "להעיז" לעבוד עם ה-API, לדעת שיש מי שתומך בנו, ולצאת לדרך.

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

נדב אגב צייד אותנו לא רק במענה לשאלות נקודתיות אלא בעוד דבר – מה שמביא אותי לנקודה הבאה…

טוב קולקשן טוב משם טוב

"יש לך רפרנס טוב לשלוח לנו לפני שמתחילים?" שאלתי את נדב.

"שולח לך לינק לדוקומנטציית API, רוצים גם קולקשן בפוסטמן?"

ברור!!

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

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

בדיקת היתכנות זה מאסט! בטח בריצה למרחקים ארוכים

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

אמרנו למוטי שהשלב הראשון בתהליך הוא בדיקת היתכנות – לראות שמצליחים לתקשר, שהכל נראה תקין.

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

קראנו לזה Priority Playground – והוספנו בכל פעם ענף אחד, עשינו disable לאחרים ובדקנו בכל פעם פונקציונליות אחת.

ככה נראית החנוכיה הסופית:

בדיקת ההיתכנות לקחה כמה ימים – בסופה בנינו אפיון עסקי וטכני מלא (ב-Miro) והתחייבנו ללקוחות על לוחות זמנים.

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

אגב, הזכרתי את האפיון – אז זה הזמן להזכיר עוד חלק חשוב בתהליך, והוא

אפיון שכולם מבינים

בכל פרויקט אוטומציה כזה, שהוא יותר מטריוויאלי, יש כמה אנשים מעורבים:

  • מנהל או מנהלת לקוח – שאחראים על הקשר הישיר עם הלקוח, מבינים את הקייס העסקי ומכירים לאורך זמן את התשתיות והיכולות. הם אחראים לאסוף את הדרישות העסקיות ולייצר אפיון.
  • צוות האוטומציה – שאחראים לקבל את האפיון העסקי והטכני, לתת דגשים לגבי המערכות הנבחרות, להקים בפועל את האוטומציות במערכות ה-low code / no code, לבדוק שהתהליך עובד בצורה תקינה ולהעביר ל-QA סופי.
  • צוות ה-QA – מקבלים את האפיון העסקי והטכני ושואלים – "מה לעזאזל יכול להשתבש? מה הלקוח אמור לעשות? ואיך נבדוק את זה בצורה הכי טובה לפני שעולים לאוויר?" הם בונים את תוכנית ה-QA ואת הסנריוז הנחוצים עבור הבדיקות, טוחנים את האוטומציה מכל הכיוונים מרגע שהבנייה הסתיימה, מחזירים לצוות האוטומציה אם מזהים באגים והם היחידים שיכולים להגיד בסוף "זה עובד! אפשר לשלוח ללקוח 😁" 
  • הלקוח – איך שכחנו את הלקוחות 😂😂 אותם בדרך כלל מעניין הצד העסקי של התהליך, ולא מעניין הצד הטכני. הם מעיין נובע של ידע לגבי העסק, הלקוחות, המוצרים – ולכן מרכיב קריטי בתהליך האפיון (בצד העסקי, לעיתים רחוקות בצד הטכני)

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

למה 3 אם כתבתי כאן 4 בעלי תפקידים? כי יכולה להיות "כפילות כובעים". במקרה הזה לדוגמא, אני הייתי מנהל הלקוח וגם איש האוטומציה שבנה בפועל (לעולם, אגב, איש האוטומציה ואיש ה-QA יהיו אנשים שונים. מי שבנה את האוטומציות לא יכול לבדוק אותן בצורה אובייקטיבית).

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

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

מי שלא רוצה לחפור יותר פנימה לפרטים הטכניים – לא צריך. רואים את התהליך ומבינים אותו "מלמעלה". 

לאחר שכולם עברו על האפיון ומבינים אותו, אפשר "לתת בגונג" ולהוציא את הבנייה והכנת תוכנית ה-QA לפועל! תזכרו שצוות ה-QA צריך זמן כדי להכין תוכנית, להבין את הסנריו העסקי (הם לא בהכרח "חיים את הלקוח" ברמה היומיומית כמו מנהל הלקוח) ולהיות סופר יצירתיים במחשבה, איך להפיל את הסנריו.

איך עובדים נכון מול ה-QA? או! לזה מוקדש הסקשן הבא.

איך עובדים נכון עם צוות ה-QA בפרוייקטי No Code?

בשביל הנקודה הסופר סופר חשובה הזו, ראיינתי את ליאת האלופה מצוות ה-QA והתמיכה שלנו.

ליאת היא אשת ה-QA והתמיכה שעובדת על האוטומציות של הלקוחות האלו כך שהיא מכירה את הלקוח מבחינת הפעילות העסקית.

ליאת הייתה "שומרת הסף" של האוטומציה, מה שנקרא ה-Gatekeeper. אני אמנם הייתי בקשר עם הלקוחות וחברת ההטמעה של פריוריטי תוך כדי בניית האוטומציה, ובישרתי להם כשסיימתי בדיקות פנימיות והעברתי את הפרויקט ל-QA – אבל ליאת היא היחידה שיכולה להכריז שהאוטומציה בשלה לעלות לאוויר!

איך ליאת ניהלה את התהליך מהצד שלה, ואיך עלינו לאוויר עם delivery של אוטומציה באיכות גבוהה ובזמן? ראיינתי את ליאת על התהליך מהצד שלה, צפו כאן למטה!

מה לקחתם מהקייס הזה?

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

כתבו בהערות מתחת – זה יעזור לי לדייק את התכנים עוד יותר!

Facebook Comments