קוד

Designed by Unsplash

הערך הניהולי של פיתוח תוכנה מקצה לקצה

פיתוח Full-Stack להלן FS, הוא סט הטכנולוגיות וכלי הפיתוח שמאפשר לתכניתן לפתח מערכת קצה אל קצה או לכל הפחות פיתוח ממשק המשתמש GUI\Front-End להלן FE, ו-Back-End להלן BE, שירותי מערכת אחוריים: לרוב שירותי נתונים או שירותים עסקיים. לעתים הדבר גם מחייב הבנה טובה בשימוש בבסיסי נתונים.

אם מתחילת עידן מערכות השרת/לקוח, הביקוש לתכניתנים התמקד בכאלה בעלי התמקצעות ומומחיות ספציפית כל אחד בתחומו: מפתחי FE או מפתחי BE הרי שבעשור האחרון אנו עדים יותר ויותר לכך כי מגמת הביקוש משתנה וישנה דרישה גוברת והולכת למפתחי FS ורסטיליים השולטים ב-2 עולמות פיתוח אלה.

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

היתרונות הניהוליים של צוות Full-Stack

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

שיבוץ כח-אדם

כל מנהל  יאמר לכם שאחד האתגרים הכי גדולים בניצול יעיל של כח-האדם, הוא היכולת לנהל את השיבוץ וההקצאה
של כח-האדם באופן המיטבי שמשמעו על פי רוב: באופן גמיש ומהיר.
לעתים קרובות מנהלים קוראים לפעילות הניהולית הזאת ״שבץ-נא״. רק שהמשחק הזה, בצורתו הניהולית,
הוא לא על נקודות אלא על כסף אמיתי, חוסר יעילות תתורגם מידית לשורה התחתונה – שורת הרווח/הפסד.
במקרה זה תוכניתי FS הם קלף מנצח – בגלל הוורסטיליות שלהם:
יש לך צורך בתכניתן למשימה מסוימת? אם יש לך תכניתן FS פנוי, ההיגיון אומר שהוא מתאים למשימה.
בבת אחד הגיעו לפתרונן 2 בעיות:
תקציב שמתבזבז בשל תכניתן זמין ללא משימות ומאידך הנזק מעיכוב במשימה שאינה מאוישת –
לעתים קרובות זהו הנזק הגדול יותר, למרות שאינטואיטיבית יותר קל להתחבר להבנה שבנזק הכלכלי של תכניתן מושבת.

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

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

חסכון בעלויות אינטגרציה

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

צד ה-FE  פונה ל-BE בניסיון להפעיל את אחד הממשקים

בשלב זה מתגלות בדרך כלל תקלות 

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

כאשר מתגלה מקור התקלה – בדרך-כלל התיקון הוא רק באחד הצדדים

לכן תכניתן אחד יעבוד על פתרון התקלה בעוד התכניתן השני עשוי להיות מושבת. 

יש כאן אם כן חוסר יעילות ב-2 ממדים:

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

2 – בזמן תיקון התקלה – התכניתן האחר על פי רוב מושבת.

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

כאשר תכניתן FS מבצע אינטגרציה, זה על פי רוב: מול עצמו…
כל הבעיות החמורות הללו נפתרות מאליהן.

יותר איכות בפחות עלות

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

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

מה הלאה?

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