אתמול ציינו מיקרוסופט שנתיים ל-user group של שרפוינט בישראל. האירוע היה חגיגי ונחמד. במסגרתו הושק אתר קהילת שרפוינט החדש, שמומלץ לכל מי שעוסקים בתחום. בשונה מההרצאות הטכניות והמקצועיות שבדרך כלל מוצגות במפגשי ה-user group, הפעם החליטו קרן וליאור, המארגנים את פעילות הקבוצה (בהתנדבות! כל הכבוד להם) לחזור על מצגת The Voice שהעברנו בכנס SharePoint Extreme. בהשראת תוכנית הטלוויזיה, יש שלושה מנטורים שהם מומחים בתחום, ומספר מציגים שנותנים טיפים קצרים לגבי שימוש בשרפוינט. אני נתתי שני טיפים, את הראשון פרסמתי לפני כמה שבועות והיום אפרסם את השני שעוסק בשאלה של מתי לפתח ומתי להעדיף יישום out of the box.
שרפוינט הוא תשתית מאוד מגוונת ומספקת הרבה מאוד יכולות. אחד היתרונות שלה הוא שהיא מספקת הרבה יכולות OOTB – ישירות מהקופסא – עבור מגוון צרכים: ניהול מסמכים, פורטל ארגוני, אתר אינטרנט ועוד ועוד. יחד עם זאת, היכולות של שרפוינט פונות למכנה משותף של צרכים (בכל העולם) ולא פעם ללקוח יש צרכים שונים שאינם תואמים במדויק למה שהתשתית מספקת.
השאלה: מתי ליישם יכולות מהקופסה ומתי לפתח בעצמנו?
למה זו בכלל שאלה? ובכן, פיתוח תמיד עולה יותר כסף ומכניס יותר סיכונים לפרויקט.
כמו בן, מיקרוסופט משדרגת כל כמה שנים את התשתית כדי להתאים לצרכים משתנים של הארגונים והשוק בכלל. יכולות OOTB גם יוסבו כחלק מהשדרוג (בסבירות גבוהה) ואילו פיתוחים יצטרכו במקרים רבים . ואגב שדרוגים, הרבה פעמים השדרוג מספק יכולת חדשה שלא הייתה קיימת קודם, לא פעם זו בדיוק התכונה שפיתחתם…
בנוסף, רכיבים שהם חלק מהתשתית פותחו ע”י הספק והם עומדים בסטנדרטים אחידים שכוללים: ביצועים, היקפים, תאימות לממשק משתמש ועוד. לפתח רכיבים שיעמדו בסטנדרטים האלו זה לא פשוט – ואם לא נפתח ככה, ניתן תוצר פחות טוב ללקוח.
הכלל שנאמץ הוא כלל ה-80-20. בכל מקרה שבו הפתרון OOTB עשוי להתאים לצרכי הלקוח, יש להעדיף אותו. OOTB יכול לכלול: יישום של רכיבים קיימים (רשימות, תבניות וכו’), קונפיגורציה ברמת הסיסטם, בניית רכיבים באמצעות SharePoint Designer, כגון master page.
מתי כן נפתח? במקרים שבהם מדובר בצורך שאינו ניתן ליישום בצורה אחרת, שהוא חיוני לעבודת המשתמשים/ מטרות המערכת או או חיוני להטמעה והצלחת המערכת. עוד שיקול שכדאי לקחת בחשבון הוא האם מה שאנחנו נפתחים ישמש אותנו עבור צרכים נוספים – ככל שהרכיב שמפתחים ניתן יותר לשימוש חוזר, כך עדיף.
אם החלטנו לא נפתח – חשוב להכיר היטב ולעומק את היכולות הקיימות של שרפוינט. יש דברים שהפלטפורמה יודעת לתת אבל צריך להכיר טוב את היכולות כדי לדעת את זה. יש מאגרי מידע, user groups וכמובן קורסים וסדנאות. בנוסף צריך לחשוב יצירתית איך מגשרים על הפער מול המשתמשים, אם יש כזה.
ואם כן נפתח, העשה את זה באופן שלא ינטרל יכולות של שרפוינט, בצורה מודולרית, שניתנת להתקנה והסרה (ושדרוג בקלות או ביטול במעבר גרסאות) וכמובן בצורה סטנדרטית.
עוד שתי הערות: הצגתי פה שתי אפשרויות מנוגדות, אבל בעצם הן יכולות – וצריכות – לחיות זו לצד זו. בכל פרויקט בשרפוינט צריך לקבל את ההחלטה הזו של פיתוח או יישום עבור כל רכיב, ובעצם הפתרון משלב את שתי הגישות. כמו כן, יש אפשרות נוספת באמצע, והיא שימוש ברכיבים או מוצרים של צד שלישי, שבעצם מחליפים את הפיתוח. זה פתרון טוב, אבל כמובן צריך לבדוק היטב מהו הרכיב שמתקינים, ושהוא עומד בכל התנאים שהגדרנו עבור פיתוח בשרפוינט והאם יש תמיכה מהספק או לחילופין מדובר בקוד פתוח שאפשר לבד לבצע תיקונים בקוד.
לסיכום: היישום של שרפוינט עם יכולות OOTB מספק TTM קצר מאוד ו-ROI מעולה; קל מאוד לבצע שינוים במהירות ולהדגים למשתמשים; לא נכנסים ל”הרפתקאות” מיותרות וכשכן מפתחים, עושים את זה מהסיבות הנכונות ובצורה הנכונה.
Comments