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

זה החלק המעשי והטכני של סיפור התיאום שהמדריך "מה זה BIM?" של האתר מספר ברמת המתודולוגיה - Common Data Environment מתאר את הרעיון של מודל משותף ותמיד עדכני; Worksharing היא איך רוויט בפועל מיישמת את זה.

מודל מרכזי ומודלים מקומיים

לפרויקט רוויט משותף יש מודל מרכזי (Central Model) אחד - הקובץ הראשי, המוחזק במיקום מבוקר אחד (כונן רשת, או Revit Cloud Worksharing על Autodesk Construction Cloud / Forma), ומכיל את המצב המחייב והעדכני של כל ה-worksets, כל האלמנטים, וכל היסטוריית הגרסאות. אף אחד לא עורך את המודל המרכזי ישירות.

במקום זה, כל חבר צוות עובד מתוך מודל מקומי (Local Model): עותק של המודל המרכזי שנשמר על המחשב שלו. כל העריכה בפועל קורית בקובץ המקומי. מדי פעם, כל אחד מריץ Synchronize with Central (SWC), שדוחף את השינויים שלו למעלה למודל המרכזי ומושך למטה את השינויים של כולם מאז הסנכרון האחרון שלו. דילוג על סנכרון לזמן ארוך מדי גורם למודל המקומי להתרחק יותר מהמצב המשותף העדכני, מה שהופך התנגשויות עתידיות לסבירות יותר וגם את הסנכרון עצמו לאיטי יותר.

Worksets: חלוקת המודל לאזורי עריכה

Workset הוא תת-קבוצה בעלת שם של אלמנטי הפרויקט, שניתן ללוות ולערוך כקבוצה. Worksets קיימים כדי לשמור על גבולות עריכה ברורים: workset ייעודי לתחום אחד עבור אלמנטי קונסטרוקציה, אחר עבור מחיצות פנים, workset משותף לאלמנטים שהרבה צוותים נוגעים בהם. השיטה הנכונה בפועל צרה יותר ממה שזה נשמע: להשתמש ב-worksets לגבולות ארגוניים גסים, אבל להסתמך על השאלת אלמנטים (Element Borrowing), לא על checkout של workset שלם, לעריכה יומיומית - checkout של workset שלם חוסם את כולם מלגעת בכל דבר בתוכו, בעוד השאלה נועלת רק את האלמנטים הספציפיים שבאמת משנים.

איך השאלה ובקשות עריכה עובדות בפועל

הנעילה ברמת אלמנט של רוויט היא אוטומטית ובעיקר בלתי נראית עד שהיא כן נראית. כשעורכים אלמנט שאף אחד אחר לא נוגע בו, הופכים בשקט ל"שואל" (Borrower) שלו ויכולים לבצע שינויים בחופשיות. כשמנסים לערוך אלמנט שמישהו אחר כבר עורך, רוויט חוסמת את השינוי ומציעה להגיש בקשת עריכה (Editing Request) במקום - התראה לבעלים הנוכחי, שנראית בחלון Editing Requests, שמישהו אחר צריך שהאלמנט ישוחרר.

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

מודלים מקושרים: החצי השני של התיאום

Worksets פותרים שיתוף פעולה בתוך מודל של תחום אחד. תיאום בין תחומים - אדריכלות, קונסטרוקציה, מערכות (MEP) - עובר דרך מודלים מקושרים (Linked Models) במקום: כל תחום שומר קובץ רוויט נפרד משלו, וכל תחום אחר מקשר את האחרים כגאומטריית ייחוס, נראית אבל לא ניתנת לעריכה ישירה. זו הפרדת תחומי אחריות מכוונת: צוות מערכות לעולם לא אמור להיות מסוגל להזיז בטעות עמוד קונסטרוקציה, רק לראות איפה הוא נמצא.

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

שיתוף עבודה בענן מול מקומי

שיתוף עבודה מסורתי שומר את המודל המרכזי על שרת רשת מקומי, מה שעובד היטב עבור משרד בודד אבל נשבר ברגע שפרויקט חוצה כמה משרדים או כולל יועצים חיצוניים על חיבור איטי. Revit Cloud Worksharing, המתארח על Autodesk Construction Cloud / Forma, מחליף את המודל המרכזי בכונן רשת באחד המתארח בענן, ומאפשר לצוותים מפוזרים לשתף פעולה בזמן אמת ללא קשר למיקום פיזי - במחיר שכולם צריכים חיבור אינטרנט אמין וגישה תואמת לפרויקט הענן.

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

איך שומרים על פרויקט משותף בריא

כמה הרגלים מבדילים בין מודל משותף שרץ חלק לבין אחד שמייצר התנגשויות סנכרון קבועות ותסכול:

  1. מסנכרנים מוקדם, מסנכרנים הרבה. מודל מקומי שעובר ימים בלי סנכרון צובר גם קבוצה גדולה יותר של שינויים ליישוב וגם סיכוי גבוה יותר להתנגש עם עריכות של מישהו אחר לאותם אלמנטים.
  2. מגבילים גישת כתיבה למיקום המודל המרכזי. הקובץ המרכזי אמור להיות נוגע רק דרך תהליך ה-Synchronize with Central של רוויט עצמה - עריכות ישירות או מחיקה בטעות של הקובץ המרכזי עצמו יכולות להשחית את הפרויקט עבור כולם.
  3. מקצים worksets לפי גבולות עריכה אמיתיים, לא באופן שרירותי. worksets שממופים לאופן שבו הצוות באמת מחלק עבודה (לפי תחום, לפי אזור במבנה) מונעים התנגשויות השאלה מיותרות; worksets שלא ממופים לשום דבר אמיתי רק מוסיפים עומס ניהולי.
  4. מתאימים גרסאות רוויט בין כל הצוות, במיוחד בפרויקטים המתארחים בענן, שבהם זה נאכף ולא אופציונלי.
  5. דוחסים (Compact) את המודל המרכזי מדי פעם. עם הזמן, גודל הקובץ של המודל המרכזי גדל מהיסטוריית גרסאות שמצטברת; דחיסה מדי פעם שומרת על הביצועים מלהתדרדר.

איפה זה נכנס

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

אם אתם רוצים תרגול מעשי עם תהליכי עבודת צוות אמיתיים במקום ללמוד Worksharing בדרך הקשה בעבודה הראשונה שלכם - בדיוק בשביל זה בנינו את הקורסים שלנו.