הפסגון הזוכר - שימור ידע קבוע בארגון עם כוח אדם זמני.

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

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

אני אתן להדר להקדים:

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

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

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

אז באילו רמות אפשר לתעד?

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

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

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

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

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

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

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

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

תיעוד הוא לא ציפוי ששמים על עוגה!

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

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

תיעוד פרויקטאלי והסיפור של הדר

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

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

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

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

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

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

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

לסיום הנה הטיפים של הדר לתיעוד וארגון נכון של מידע:

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

2. כדי לבחון שהמסמך כתוב היטב, מומלץ שיעבור ביקורת ע"י מישהו שלא מכיר מקרוב את הנושא.

3. כדאי לכלול במסמך גם את הקונטקסט הכללי או ה"מטאדאטא".

4. יש לארגן את הידע בצורה היררכית.

5. מומלץ לאחד מסמכים מאותו סוג (פרוייקטים דומים, תיעוד תקלות, מדריכי התקנה) ולסכם אותם לפי אותה תבנית.

6. כדאי למנות אחראי "שימור ידע" שידאג לכך שכולם שומרים על צורת ארגון הידע שהוחלטה.

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

בכל מקרה, אנחנו מאחלים לכם שנה מתועדת יותר מזו שקדמה לה ;)