אחד מהחוזקות שלי כמנהל מוצר זה שאני מגיע מרקע של פיתוח, תשתיות תוכנה, וארכיטקטורה. זה אומר שאני מבין איך המערכות עובדות באמת. לכן פנו אלי בשאלה לפני שבועיים לגבי ההבדל בין שימוש ב-SDK לבין יצירת API למערכת לבין לתת למשתמשים אפשרות לליצור Macro-ים פנימיים במוצר. למה דווקא שלושת אלו? כי מנהל המוצר שדיבר איתי רצה להרחיב את מגוון היכולות שהוא חושף בפני המשתמשים שלו, שלושת הכלים הללו הם אפשרויות שונות להרחבת יכולות של מוצר מבלי לפתח את כל הפתרון בעצמכם ולפעמים אין הגיון כלכלי או עסקי בפיתוח יכולות נוספות.
התשובה המעצבנת והקבועה שלי היתה שאין מה לדבר על מהו הפיתרון הנכון מבלי להבין עד הסוף מה הבעיה שרוצים לפתור. אין טעם לענות על "עם איזה רכב אתה רוצה שאני אגיע מחר?" אם אנחנו לא יודעים האם מתוכנן למחר מעבר דירה, נסיעה קצרה, או טיול שטח ומה היתרונות והחסרונות של כל אחד מכלי הרכב האלו. אחרי שאנחנו מבינים את הצורך אז אנחנו יכולים להתקדם. אז יאללה, בואו נבין מהם שלושת הכלים הללו ולמה חשוב לנו להכיר אותם.
ממשק תכנות חיצוני (API או Application Programming Interface) הוא אפשרות לתוכנות לתקשר אחת עם השניה באופן מוגדר מראש. כלומר, לאפשר למוצר שלי לשלוח או לקבל או לשלוח הודעות או בקשות מוגדרות מראש לתוכנות חיצוניות. כבר כתבתי בעבר באריכות על איך מאפיינים ממשקי API ועד כמה זה חשוב. כי מהרגע שאני חושף API אני מאפשר למערכות אחרות להתממשק עם המערכת שלי. זה יכול ליצור שיתופי פעולה והרחבת יכולות בין המוצר שלי ומוצרים אחרים. דוגמה קלאסית היא למשל שאם אני מפתח מערכת אני יכול לפנות ישירות ל-API של מערכת תשלומים כדי לבצע חיוב של לקוח. ככה אני לא צריך לפתח מחדש את כל הלוגיקה של חיוב תשלומים ועמידה ברגולציות של טרנזאקציות פיננסיות ועדיין יכול לחייב לקוחות. תחשבו על זה כמו להזמין מנה של דים סאם מאודה ממסעדה, אני לא צריך לדעת להכין את המנה, רק לפנות למי שכן ולבקש את מה שאני רוצה. דוגמה נוספת היא אם אני מזמין רהיט מאיזו חנות אונליין ואז באמצעות API נפתח לי חלון לתשלום שמתופעל על ידי חברה אחרת.
יתרונות: מאפשר לקשר בין מערכות שאין שום קשר ביניהן, לרוב אפשר להחליף פנייה ל-API של חברה אחת בפנייה ל-API של חברה אחרת בקלות יחסית, פיתוח קל יחסית.
חסרונות: יוצר תלות במערכת חיצונית, הגבלות בהתאמה אישית, עלול לכלול עלויות מתמשכות, מסרבל את תהליך הבדיקות עקב תלות בחברה אחרת.
לעומת זאת ערכה לפיתוח תוכנה (SDK או Software Development Kit) הוא ממש רכיב קוד שאני מקבל או קונה מיצרן אחר ומכניס לתוך המוצר שלי. החבילה הזו לרוב כוללת ספריות, כלים לדיבוג, מדריכי משתמש ועוד. אם נמשיך את הדוגמה שלנו ממקודם אז בזמן שאני מפתח את האפליקציה שלי אני מכניס לתוכה את הקוד שמבצע את החיוב של הלקוח. היתרונות הן שכמו קודם אני לא צריך לפתח את כל הלוגיקה והעבודה של חיוב הלקוחות שלי, אלה רק להשתמש ב-SDK. בניגוד ל- API שהוא פנייה למערכת חיצונית בשימוש ב-SDK אני מכניס את היכולות ישירות לתוך הקוד שלי (חשוב לציין שלפעמים חברות אחרות נותנות SDK שהוא רק מעטפת ל-API שפונה למערכת שלהם). החיסרון הוא שיש לי רכיב בתוך המוצר שלי שאני לא שולט בו ואני עלול להידרש להתאים את המערכת שלי לדרך העבודה שלו. במקרה הזה קל יותר לחשוב על זה כאילו אני מתקין במטבח שלי מכונה להכנת דים סאם מאודים. קניתי את המכונה והיא שלי ואני יכול להכין כמה דים סאם שאני רוצה כי המכונה היא חלק מהמטבח שלי.
יתרונות: חוסך המון זמן של מחקר ופיתוח שהיה נדרש בכדי לייצר את הפיתרון בעצמנו.
חסרונות: דורש שיהיה SDK של המוצר השני שמתאים לטכנולוגיה שלנו, דורש תחזוקה שוטפת של התוכנה בכדי לתמוך ב-SDK, וקושי בביצוע אופטימיזציה או פתרון בעיות שנובע מכך שהמידע שאני יכול לקבל מה-SDK לרוב מוגבל.
אז איך מקרואים (Macros) נכנסים לנושא הזה? לפעמים אני רוצה לאפשר ביצוע של פעולות במוצר שלי אבל אני לא רוצה להיכנס לתוך המעמסה של יצירה ותחזוקה של API או SDK, או שאני לא בטוח מה הפעולות שהמשתמשים בעצם ירצו לעשות עם המוצר שלי. אז מה אפשר לעשות? מקרואים זה פיתרון נחמד. בגדול מקרואים מאפשרים למשתמש ליצור תוכנית שהמוצר שלי יריץ. הממשק הנוח ביותר ליצירת מקרואים זה לאפשר למשתמש "להקליט" סדרה של פעולות ידניות שהוא מבצע ואז להציג לו קוד שמראה את הפעולות הללו ואז המשתמש יכול לערוך את הקוד הזה בשביל לבצע את אותה הפעולה בצורה אוטומטית, היצירה של המקרו פשוטה מאוד אבל כל עריכה ושינוי שלה כבר תדרוש הבנה של שפת המקרו שלנו וקצת הבנה בתכנות. הדוגמה הכי טובה היא כנראה Microsoft Excel שם אפשר בקלות ליצור ולערוך מקרואים (הנה מדריך קל עם תמונות). אני עדיין זוכר איך לפני איזה עשרים שנה יצרתי מקרו לחבר של אחי שחסך לו לבצע את אותה פעולה רפטטיבית במשך שעות פינה לו ימים של עבודה. בדוגמת בישול הדים סאם שלנו, דמיינו שאני מצלם את עצמי מכין דים סאם במטבח שלי ואז נותן לרובוט את הסרטון שצילמתי ואומר לו לעשות בדיוק את מה שאני עשיתי.זה כמובן יפעל מעולה, עד שאני אזיז קערה או אשנה את מבנה המטבח שלי ואז הרובוט יתחיל לשבור דברים בטעות.
יתרונות: גמישות רבה – הלקוחות שלי יכולים לעשות כל מה שהם צריכים בלי להטריד אותי, יצירה מהירה של מקרואים, יכול לתת יתרון תחרותי כי קשה לייצר בסיס למקרואים.
חסרונות: עלות פיתוח מאוד גבוהה כדי להגיע למצב שיש מערכת הרצת מקרואים, אובדן שליטה על אופי השימוש במערכת, עומס תחזוקה, מחייב רמה גבוהה של תמיכה בלקוחות, וכמובן עקומת לימוד גבוהה מאוד התלויה בכישורים של המשתמשים.
חשוב לזכור ששלושת הפתרונות הללו לא סותרים אחד את השני. אין שום מניעה להוסיף סוגים שונים של פונקציונליות באמצעות כלים שונים. למשל לבצע סליקה באמצעות API, חישובים מתמטיים באמצעות SDK של תוכנה אחרת, ואפשרות להקלטת מקרואים בשביל לתת למשתמש אפשרות להריץ מספר תסריטים בו זמנית.
כשאנחנו חושבים על לתת למשתמשים או מערכות אחרות יכולת להתממשק עם המוצר שלנו חשוב להבין מה הפתרון הנכון ביותר מבחינת הצרכים של המשתמשים שלנו והעלויות של כל אחד מהפתרונות. בסופו של יום אנחנו לא בוחרים פתרונות טכנולוגיים בגלל כמה הם חדשים, מגניבים, או אם קראנו עליהם בבלוג. בחירה בכל פתרון כזה צריכה לתמוך ביעדים העסקיים של החברה שלנו. האם יש הצדקה לעלויות של פתרון אחד על פני אחר? האם יש באמת צורך לתת יד חופשית רחבה למשתמשים שלנו? האם יצירת קשר חזק בינינו לבין חברת צד שלישי לא חושפת אותנו לבעיות בהמשך הדרך? הסיבה שאנחנו צריכים להבין את המונחים הללו היא כי יש לבחירה באחד מהן השלכות שחורגות רק מהיישום בפועל.
שואלים אותי הרבה שאלות על נושאים טכניים בסדנאות למנהלי מוצר, אם אתם רוצים להזמין סדנה לשדרוג הידע הטכני של מנהלי המוצר שלכם – דברו איתי 🙂
אורי.
תודה רבה לכל מי שתרם לפוסט הזה, ביניהם: מאיה גרשוביץ בר, רונן אברבנל, גלעד בר אילן, שחר לנגבהיים, מרינה ברלין, יובל שפר, ועוד.
