אבחנות ומסקנות שהתקבלו במהלך כ-7 שנים של בניה, ניהול וגידול תהליך פיתוח מבוזר.
נניח שאתה בעל תפקיד בעסק רווחי. בכל שינוי במודל הקיים ישנו סיכון של שבירת המודל והפיכתו ללא-מתפקד.
ככל שהשינוים המבוצעים קיצוניים ורבים יותר, הסיכון שהמודל ישבר גדל. הסיבה, מן הסתם, היא גורמים בלתי צפויים והנחות יסוד שגויות, או פשוט היעדר מחשבה אודות השלכות של שינויים. מגוון הסיבות הקטנות מתאחדות לגל גדול של תוהו-ובוהו עם כל עליה בכמות וקיצוניות השינויים.
אלא אם כן בידיך כשרון ראיית הנולד, עדיף למנן סיכונים ולפרוש לאורך זמן.
אם האפשרות קיימת להיות זהיר ולבצע שינויים אחד-אחד, תוכל להנות מהיכולת לדעת במידה גדולה של דיוק איזה שינוי שיבש או שבר מודל שעבד, ותהיה לך האפשרות לתקנו או לבטלו כליל.
בהינתן משימות שחסרות צורה מוגדרת וידועה מראש, נדרשת תקשורת הדוקה בין הצדדים המשתתפים בביצוע. זמני תקשורת והמתנה ארוכים שאופייניים לעבודה מרוחקת מוכפלים ע"י הצורך התכוף בתקשורת, והתוצאה - זמני ביצוע ארוכים ותסכול.
מכח האמור מעלה, מטלות כגון מחקר הדורש פידבק תכוף, בדיקות היתכנות, יצירת PoC ואב טיפוס איטרטיבית (rapid prototyping) עדיף לעשות כאשר כל הצדדים נהנים מתקשורת זמינה וקלה (קריא: יושבים באותו החדר).
למרות הכתוב מעלה אודות חסרונות הפיתוח המרוחק, היתרונות משמעותיים מאוד: עלויות מופחתות וזמינות מומחים גדולה יותר.
לפיכך, עדיף ללכת על מפתחים מרוחקים כאשר ישנה וודאות בנוגע ליעד ודרך ההגעה אליו. כשיודעים מה בונים, באיזו טכנולוגיה ויש הבנה טובה של החלקים השונים ואיך הפתרון אמור להיראות, ניתן לבנות תכנית מפורטת ולפרקה למשימות מתועדות ומוגדרות היטב. כדי להגיע אל ההבנה הזו ניתן (ורצוי) להיעזר בשירותינו.
עובדים מרוחקים אינם תופסים מקום במשרד. ללא התחייבות, גיוס עובדים וסיום עבודתם הם חסרי חיכוך. בכנס אחד מישהו תיאר את אוקראינה כ"ענן מפתחים" שניתן להקצות ולשחרר ממנו משאבים ע"פ הצורך.
ועם זאת, הניסיון מראה שכשני שליש מהגיוסים המרוחקים נכשלים ממגוון סיבות כגון אי התאמה תרבותית, אי יכולת של המועמד לעבוד באופן מרוחק, היעדר מוטיבציה, הבדלים בשעות ואפילו רמאות מסוגים שונים והטעייה ע"י העובד. רק חלק מאלו ניתן לאתר מראש באמצעות ראיון ומבחנים.
העלות הגבוה ביותר בגיוסים שנכשלים היא הזמן והמאמצים המבוזבזים בנסיונות להכניס את העובד החדש לתהליך מזין מול מערכות ותשתית קיימות.
לפיכך, אם בארגונך ישנו מנגנון גיוס ואונבורדינג משומן, וזמנך היקר דורש להתקדם במהירות האפשרית, גיוס-יתר הינה גישה הנותנת תשובה מסוימת לבעיית נשירת העובדים החדשים.
והנה מדוע. לעיתים תכופות, כאשר מחפשים פתרון קיים לבעיה מקומית, הפיתוי לפתור אותה באמצעות כלי מתוצרת עצמית הוא גדול, במיוחד אם הפתרונות הקיימים נראים מסובכים וגדולים על הבעיה. וכאן בעצם נכנסים לחוב: במקום לאמץ פתרון קיים, לוקחים קיצור דרך באמצעי מיצור עצמי - פשוט וזריז.
עם הזמן, כאשר הצרכים משתנים, נאלצים לשכלל את הפתרון העצמי. ובמידה והוא לא מקבל פופולריות רחבה, המעמסה של תחזוק הכלי, תיקונו ושיפורו כדי שיענה על הצרכים הגדלים של הפרויקט נופלים עליך.
תוך כדי כך, לא ניתן לגייס מומחים בעלי ידע קיים עם הכלי, היות ואינו קיים בשוק. כל מי שתגייס יצטרך את הפתרון שלך.
בנוסף, המוטיבציה של עובד לעבודה עם פתרונות כאלה היא קטנה, היות וישנה הבנה שכל נסיון שנצבר אינו שמיש בשוק העבודה. לפיכך, המשרה הופכת עבור העובד לדרך ללא מוצא. הנטיה להישאר במשרות כאלו היא של העובדים הבינוניים ומטה.
החכמה, כמו בכל חוב טכני, היא לדעת מתי להחזיר אותו. לא תמיד האפשרות ללכת על הבחירה הנכונה קיימת, וקיצורי דרך נדרשים לשם שרידות הפרויקט ועמידה בלו"ז. עם זאת, אסור לשכוח אודותיו. ברגע שהאפשרות מופיעה, יש להחליף פתרונות מסוכנים שעלולים ליפול ודורשים תחזוקה מתמדת בכלים סטנדרטיים מהתעשייה.
הנקודה הזו אינה ספציפית לצוותים מרוחקים. הרבה נכתב בנושא, אך בקיצור נמרץ: מפתחים מסוגלים לעבוד בשטף (thread) אחד. דהיינו, לבצע משימה אחת בכל רגע נתון. הם עושים את זה בצורה הטובה ביותר כאשר מתאפשר בידם לעבוד על משימה בודדת, ללא הפרעות, באופן מתמשך. לוקח זמן להתרכז, אך ברגע שמפתח נכנס ל-zone, הוא עובד ביעילות.
כאשר מתקיימים תנאים שדורשים את הזזת המפתח בין משימות, יעילותו פוחתת מכך שהוא נאלץ להחליף קונטקסט לעיתים תכופות. הדבר גורע מהיכולת להתמקד באופן עמוק ועקבי במשימה אחת.
בספרות המקצועית ישנן כמה וכמה גישות למניעת וצמצום הבעיה הזו. הגישה המובילה היא חלוקת הצוות ל"קומנדו כיבוי שריפות" שזמין למטלות חדשות בהתראה קצרה ובעל מומחיות מספקת לטפל במגוון רב של נושאים, כאשר מטרתו היא להשאיר את שאר חברי הצוות במציאות בה הם יכולים להתמקד במשימות המתוכננות שלהם.
היכולת לתכנן ולבצע דורש הבנה של המשאבים שעומדים לרשות הארגון (כגון תקציב) וכמו כן הבנה של התוצאה הסופית הרצויה, כולל הגמישות הנדרשת מהפתרון, כמות השינויים תוך-כדי יישום ומידת החריגות האפשריות מהתכנית המקורית.
כאשר ישנה תנודתיות בתקציב העומד לרשות צוות הפיתוח, והדבר מוביל לפיטוריהם של חברים מנוסים בצוות בפיתוח, הדבר בעל השפעות הרסניות ארוכות טווח. ידע ונסיון שהצטברו במהלך תקופה ארוכה מתנדפים בין רגע. חברי הצוות הנותרים חוטפים מכה למורל כאשר הם מועמדים מול האפשרות הריאלית של הפסקת העסקתם. הם מתחילים לחפש אלטרנטיבות, והטובים מביניהם יהיו הראשונים לעזוב.
חשוב מאוד להבטיח מציאות תקציבית יציבה בכדי לאפשר תכנון ארוך-טווח.
בחלוף הזמן עובדים מאבדים את הרצון להמשיך. הסיבות משתנות, והן יכולות לנבוע מהיעדר צמיחה מקצועית, ציפיות שאינן מתאימות למציאות, רוטינה משעממת, שחיקה ויחסי אנוש רעילים בתוך הארגון. האפשרויות להתמודדות הן שיפור והתאמה תנאי העובדים לאופיים, רמתם וציפיותיהם על מנת לעודד את צמיחתם. או, לחילופין, אם זה לא מתאפשר, ליצור מנגנון יעיל למציאה, אימון והחלפה של עובדים בתכיפות גבוהה.
תבניות תקשורת בתוך צוות הן עניין סבוך. אייטם בודד נוצר באמצעות תקשורת בין בעל העניין ומנהל הפרויקט או המוצר, נשקל על ידי ארכיטקט, מפורק למשימות ותתי משימות לכמה מפתחים, ולאחר הפיתוח מגיע ל-QA, בסופו של דבר אל ה-DevOps. וזהו המסלול הקצר והאופייני בתהליך פיתוח סטנדרטי.
רמת הסיבוך בתקשורת תוך-צוותית היא, לעיתים קרובות, נעלמת מהעין ואין מתיחסים אליה באופן מודע. בני אדם יודעים אינטואיטיבית איך לתקשר כאשר הם בקולקטיב קטן כגון חדר או קומה במשרד.
כאשר הארגון הוא גדול או מבוזר, דברים נוטים לצאת משליטה במידה והתקשורת לא הופכת לפורמאלית. הכוונה במילה זו אינה השימוש באימייל או בתארי כבוד, אלא הבנה משותפת ונהירה ע"י כלל המשתתפים בנוגע לצעדים הנדרשים ע"י כל משתתף כדי להגיע אל המטרה המשותפת.
להגיע לפורמליזציה של התהליך אפשר ע"י הטמעתו בתוך מערכת שמהווה את מקור האמת (source of truth) של כלל הצוות. זו, למשל, יכולה להיות מערכת לניהול משימות. כמו כן, ניתן ורצוי להגן מפני פעולות לא רצויות של חברי הצוות באמצעות חסמים טכניים כגון הרשאות commit לענפים מסוימים ברפוזיטורי וכדומה.
© 2023 Web GMA R&D Ltd.