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