הכל עניין של נקודת מבט
A matter of point of view
מאת אשר יובל: מנכ"ל ומנהל הידע, מתודה מחשבים
זה הכל עניין של נקודת מבט" אמר השפן לעליזה, "לך נדמה שנפלת כמו טיל מלמעלה למטה ולי דווקא נדמה שטסת כמו טיל מלמטה למעלה".
(פרפראזה על עליסה בארץ הפלאות)
לפני מספר שנים, פגשתי את פרופ' אייבר ג'קובסון (Ivar Jacobson), מאבות תורת האובייקטים ושיטת UML, ובמהלך השיחה שמעתי ממנו את המשפט הבא: "אל תאמר תיעוד, אמור נקודת מבט". ובאנגלית: Don't say documentation, say view. אני מודה שלקח לי זמן מה להפנים את המשמעות של ביטוי חכם זה. היום נדמה לי שאני מבין אותו ואני מבקש לשתף אתכם בתובנה "קטנה" זו.
כאשר אדם מתבקש לכתוב מסמך כלשהו, כגון: רשימת תיוג, סיכום פגישה, ייזום וכו', שלא לדבר על מסמך מקצועי "כבד" יותר, כגון: תיק אפיון, תיק דרישות, תכנית בדיקות וכו', הוא נתקל מהר מאד בבעיה של "סדר הדברים", היינו, רשימת הסעיפים או ראשי הפרקים של המסמך. כיצד להציג את המידע? מה בא לפני מה? מה תחת (כלול בתוך) מה?
נתאר לעצמנו את התרחיש הבא. עובד נכנס לפגישה אצל המנהל שלו והם מלבנים נושא מסוים: צורך במערכת חדשה, תכנית עבודה לשנה הבאה, תחקור פרויקט, רכישת תוכנה וכו', סביר שהפגישה תסתכם במשפט הבא (של המנהל לעובד כמובן): "בבקשה תעלה על הכתב את תוכן שיחתנו", או: "תגיש לי בבקשה נייר עבודה קצר הסוקר את הנושא". זהו. הקוף נמצא כעת על שכמו של העובד1. הוא חוזר למשרדו ומתחיל להעלות על הכתב את עיקרי הנקודות שהועלו בשיחה. בהתחלה "בתפזורת", רשימה פשוטה, נקודה אחר נקודה, במהירות, לעיתים גם בחזרות, העיקר שלא ישכח שום דבר. אך ככל שהמסמך הולך ומתרחב, נאלץ הכותב לגבש את הנקודות לקבוצות, למיין ולסדר אותם בסדר הגיוני כלשהוא: בהיררכיה, במבנה שטוח, כרשימת תיוג, אולי אפילו בטבלה או בתרשים וכו'. מהר מאד הוא מבין שהסידור שהוא בונה יש לו משמעות וחשיבות לא פחות מהתכנים עצמם. שהמבנה והארגון של המסמך הוא עצמו תוכן מרכזי. הוא יוצר את ה- View של המסמך2.
הטענה העיקרית שאנחנו מבקשים לטעון במאמר זה, היא שרבים מאיתנו יוצרים, בד"כ שלא במודע, נקודות מבט (views) חדשות, ללא צורך וללא הבנה מספקת למשמעויות ולהשלכות של מושג חשוב זה על הסביבה, הארגונית ו\או הפרויקטלית, בה אנו פועלים.
ננסה להראות שארגון ופרויקט מסודרים, חייבים להפנים נושא זה, ולהשתית את הניהול שלהם על "נקודות מבט" ברורות ומוגדרות היטב; בוודאי לא לאפשר יצירה "דינאמית" של נקודות מבט מתחלפות ומשתנות שגורמות לתקורה וחיכוך גבוהים ביותר בניהול הארגון או הפרויקט.
הכותב מול הקורא
מחשב הוא מכונה שבממוצע על כל פעולת כתיבה אחת, מבצע כשלוש פעולות קריאה. בלי זה – אין תועלת במחשב! הדבר נכון גם למסמכים. אם אין יחס גבוה של קוראים מול כותבים (יחס של 1:3 איננו גבוה, לא במחשב ולא במסמכים), אולי לא כדאי בכלל לכתוב את המסמך. אך דא עקא, שלעתים קרובות נראה שהכותב לא מצפה ברצינות שיקראו את מה שכתב! התלונות והקובלנות הנשמעות תדיר מצד כותבי מסמכים: הם לא קראו את המסמך שהגשנו להם, הם לא אישרו לנו את המסמך וכו' – הן לעתים קרובות "דמעות תנין". וכי מישהו עשה באמת מאמץ שהמסמך יהיה קריא? מישהו חשב על הקורא שצריך "להיכנס לראש של הכותב" ולהבין בכלל את מבנה המסמך לפני שהוא צולל לפרטים? האם הכותב ער לעובדה שראשי הפרקים של המסמך שהוא החליט עליהם, כופים על הקורא מבנה מחשבתי שצריך להפנים "ולעכל" אותו?
על משקל ROM (Read Only Memory) יש לאמריקאים ביטוי שנקרא, ספק ברצינות ספק בהומור WOD (Write Only Document). הכוונה למסמכים שכותבים אותם לתיקייה! מישהו מילא את חובתו וכתב את התיעוד. האם זה מה שהכותב רוצה שייקרה? שהמסמך שלו יהפוך ל- WOD?
תבניות, גלופות, סגנונות וכללי כתיבה
כל ארגון שמכבד את עצמו משקיע לא מעט ב"נייר מכתבים" – Stationery שמטרתו לייצג את הארגון בצורה מכובדת כלפי פנים וכלפי חוץ. החזות החיצונית של "ניירת הארגון" - מסמכים ומצגות - צריכה להיתמך ע"י תשתית של תבנית, גלופות, סגנונות וכללי כתיבה "שלנו". מומחים לאופיס צריכים לבנות תבניות בסיסיות של מסמכים ומצגות (גם גיליונות אקסל) שנשתלות בספריית התבניות של האופיס ונמצאות באופן בולט וברור על שולחנו של כל עובד בארגון.3 חלק בסיסי מהחניכה של כל עובד חדש (וגם רענון לעובדים ותיקים!) צריך לכלול הדרכה מעשית: "ככה כותבים אצלנו". היצירתיות והחדשנות שהעובד מביא איתו תתבטא בתכנים וברעיונות, לא במבנה, בסגנונות ובכללי הכתיבה. אלה מוכתבים בצורה חדה וברורה ע"י הארגון, יוצרים דפוסי עבודה משותפים וחוסכים זמן רב.
לצערנו, בארגונים רבים יש עדיין ויכוח בנושא ועדיין "לא כולם השתכנעו שזה חשוב". עובדים רבים חושבים שכל העניין מתמצה בגופנים (פונטים) ובצורת ההדפסה של הדף. הם מעדיפים לעצב כל שורה בעזרת פקודות ה- Word, "לחצוב בסלע", במקום פשוט לבחור בסגנון מוכן. עצתנו למנהלי הארגונים היא לא להיכנס לוויכוחים ושכנועים מיותרים, פשוט לקבל החלטה ש"ככה כותבים אצלנו" ולזרום קדימה. עד מהרה, כל אחד יבין את התועלת העצומה שבעבודה מסודרת לפי סגנונות ותבניות של הארגון והנושא ייכנס לתלם.
מצגות וסיכומי מנהלים
אין סיבה שבעולם שמצגות, שבד"כ מלוות מסמך כבד יותר (אפיון מערכת או תקציב שנתי), יהיו במבנה שונה מזה של המסמך הפורמאלי והמלא. בשיטת מפת"ח למשל, אם המסמך המקצועי בנוי לפי ראשי הפרקים הבאים: 1. יעדים, 2. יישום, 3. טכנולוגיה ותשתית, 4. מימוש, 5. עלות
המצגת, שהיא ההבהקים (Highlights) של המסמך המקצועי-הפורמאלי, תהיה בדיוק באותם ראשי פרקים (אלא בשפה פשוטה וכוללנית יותר). בניית מצגת שלא על פי הסדר והמבנה של המסמך הפורמאלי נובעת מ"יצירתיות" שאינה במקומה ו\או מרצון "להקל על המנהל" שבסופו של דבר רק מכביד עליו.4 ניתן גם לומר זאת בכיוון הפוך, אם מבנה המסמך הפורמאלי (ראשי הפרקים המרכזיים שלו) אינו בסיס טוב למצגת, אז אולי הוא מבנה לא טוב וצריך לשנותו. יכולת המנהל להעמיק מהמצגת למסמך הפורמאלי, בשיטת drill-down, היא דרישה חשובה ביותר ותנאי הכרחי!
השימוש בקישוריות בין אובייקטים (ותיקיות), יוצרת הזדמנות מיוחדת למצגות מתקדמות המכילות קישורים למסמכים, לגיליונות אלקטרוניים וגם לתיקיות. מצגות "המפעילות" אובייקטי תוכן (אופיס) אחרים הם אמצעי רב עוצמה. יש כאן שדרוג משמעותי ממצגות של "ידע כללי" (know about) למצגות של ידע מעשי וקונקרטי (know-how), ממצגות של "מה" למצגות של "איך וכיצד". מזווית המאמר שלנו, מדובר בשדרוג למצגות המשקפות את נקודת המבט האמיתית של הפרויקט, בתכנון ובמעקב, והמסמכים המופעלים מהן הם הפרטים וההרחבות של נקודת מבט זו. הדבר נכון בפרט במצגות מנהלים, כאלה שלא "מקשטות" את הפרויקט "לדרג הבכיר", אלא מציגות למנהלים את נקודת המבט האמיתית של הפרויקט. אותה נקודת מבט שאי הסכמה עליה היא לעתים כל שורש הבעיה של "אי קשב ההנהלה הבכירה".

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

כיצד ומתי לאפשר נקודות מבט שונות
לעיתים, אין מנוס מקיום של מספר נקודות מבט. מקרים אלה יכולים לנבוע ממספר סיבות:
1. הבדלים בין בעלי מקצוע: מהנדס, כלכלן, משפטן וכו', כאשר כ"א מהם רואה את הנושא \ המערכת \ הפרויקט, מנקודת מבט שונה. סיבה זו מוכרת ולגיטימית, אך יש לנסות ולצמצמה למינימום ההכרחי, למשל, ע"י סדנאות משותפות ועבודה בשיתוף (Groupware).
2. התפתחות המערכת לאורך מחזור החיים: נקודת המבט של האפיון למשל, (הגדרת דרישות), איננה תואמת את נקודת המבט של הפיתוח (עיצוב ובנייה).
3. שימוש בכלים. לצד תיעוד המערכת שמנוהל בכלי תיעוד וניהול דרישות, מופעלים כלי פיתוח: עיצוב ותכנות "שחושבים" אחרת.
4. פרויקט במיקור חוץ בו הלקוח מפעיל ספק רציני שיש לו מתודולוגיה ו"שפה" משלו. הלקוח בוחר במודע או בכורח הנסיבות שלא לכפות על הספק את השיטות שהוא אמון עליהן.
5. לוקאליזציה של חברות בינ"ל. ארגון או חברה בינ"ל שחייבים לדבר במספר שפות ותרבויות ולתמוך בלוקאליזציה של המוצרים והשירותים ותהליכי הפיתוח והשירות שלהם.
אמצעים שונים כגון: אינדקסים, מילון מונחים, חיפוש ורשימות איורים וטבלאות, יכולים לסייע לגשר על בעיית ריבוי נקודות המבט, אך לא תמיד. לעתים, אין מנוס מיצירת מספר נקודות מבט לאותו מסמך – לאותו פרויקט. חשוב לוודא שריבוי זה לא יביא יחזיר אותנו למצב הכאוטי בו כל אחד מייצר את נקודת המבט שלו, בלי משים. ריבוי נקודות מבט של בעלי עניין בפרויקט שמבינים את הנושא ואת הצורך בשפה משותפת, יכול להביא לפתרונות יצירתיים תוך שימוש בכלים מתקדמים שהם נושא למאמר אחר.

סיכום – שפה אחידה
אנחנו מדברים כל הזמן על מסמכים, מצגות ואובייקטי תוכן אחרים, אך חשוב לזכור שאלה בעצם הדבר המשני. הם מייצגים משהו אחר, הרבה יותר חשוב. "משהו אחר" זה הוא הליבה של הפרויקט, התפיסה של המערכת – The system perception. זה נשמע אולי קצת מופשט ולא ניתן "למישוש", אבל הוא העיקר, הוא "הדבר" שעליו ואליו כל הגורמים המעורבים צריכים להתביית. הוא המערכת כפי שהיא צריכה להיתפס בעיני כולם, הוא השפה המשותפת של כל הגורמים המעורבים בעשייה.
הרבה מאד נכתב בספרות המקצועית על הצורך בתקשורת ושפה משותפת בפרויקטים ובארגון. אין כמעט מצגת מקצועית שלא מזכירה נושא זה ואין כלי או מתודולוגיה שלא מבטיחים לממש אותו. כגודל ההבטחות - האכזבות; ולמרות זאת, הנושא אינו יורד מסדר היום. חשיבות הנושא איננה נפגמת בשל הקושי לממשו. אין ספק שעל חוסר שפה אחידה משלמים הארגונים והפרויקטים מחיר כבד מאד! הצעתנו היא להתחיל בצעד "קטן ופשוט", בדרך להגשמת החזון הגדול. לוודא שלמסמכים ולמצגות שנוצרים בארגון או בפרויקט יש "תוכן עניינים" וראשי פרקים מוסכמים וידועים ולהפסיק להמציא את הגלגל! להכפיף את הכותב לקורא, לעצור את יצירתיות הכותבים והיועצים, להשקיע בתבניות, סגנונות וגלופות עבודה ולהפנים את הרעיון של "נקודת מבט"...
זה הכל עניין של נקודת מבט.
_________________________________________________________________
1למי שטרם קרא, מומלץ בחום לקרוא את המאמר: אצל מי נמצא הקוף. המקור הוא מאמר באנגלית שבינתיים גם יצא כספר: William Oncken J. & Donald L. Wass: Who's Got the Monkey? Harvard Business Review 1974 (1999, book). . 2
כפי שכבר אמרנו לעיל: מה בא לפני מה ומה תחת מה. ה- view של המסמך בשני היבטים בסיסיים: הרצף (הסדר האופקי) וההיררכיה (הסדר האנכי, הפירוק לתת סעיפים). The document sequence and the hierarchy.
3יש כאן שילוב חשוב בין מעצבים שמסתכלים על החזות החיצונית של אובייקט התוכן (מסמך, מצגת) ובין מומחי אופיס שמתמקדים ב"מנוע", במבנה הפנימי. אנו ממליצים על מתן עדיפות למומחי אופיס שיש להם גם "רגש ועין טובה" לבהירות וקריאות האובייקט. 4
ואולי גם מרצון לערפל ולכסות ...
|
|
|
|