לחברת IT ממוצעת יש דרישות, היסטוריה של מעקבי משימות, מקורות (אולי אפילו עם הערות בקוד), הנחיות למקרים טיפוסיים, חשובים ומורכבים בייצור, תיאור של תהליכים עסקיים (מ-onboarding ועד "איך לצאת לחופשה" ”), אנשי קשר, מפתחות גישה, רשימות של אנשים ופרויקטים, תיאורי תחומי אחריות - ועוד שלל ידע שכנראה שכחנו ואשר ניתן לאחסן במקומות הכי מדהימים.
ידע =/= תיעוד. אי אפשר להסביר את זה, צריך לזכור את זה
איך לוודא שמי שצריך לדעת מזה משהו מבין איפה ואיך למצוא אותו, וכל מי שצריך להיות מודע לדברים והסכמים בודדים יוכל לברר באופן מיידי ומדויק על שינויים בהם.
בפרק האחרון של הפודקאסט "ראש הצוות יתקשר", החבר'ה מסקיינג דיברו על ניהול ידע עם איגור צופקו הוא אדם בוועדת התוכנית KnowledgeConf ו"מנהל הלא נודע" בפאנט.
ההקלטה המלאה זמינה בשם , ולהלן אספנו כמה טיפים מעניינים וקישורים לחומרים שימושיים שהוזכרו באודיו או הרחב את המידע ממנו. זה יהיה נהדר אם תשתף גם את הפריצות והטריקים של הצוות שלך בתגובות.
פריצה ראשונה: אתה כבר לא צריך לדעת באיזו מערכת לחפש
"לקחתי את מקורות הידע שלנו ועשיתי חיפוש כללי אחריהם: חלון בודד עם מערכת סינון לצמצום אזור החיפוש. כן, יחד עם זאת, אתה עדיין צריך לפקח על איכותו, לחדש את בסיס הידע ולהילחם בשכפול ומידע שגוי.
פיסת נייר אחת כדי למצוא זה הכל
אבל כבר, כ-60% ממהנדסי פלנט משתמשים בחיפוש הזה לפחות 1-2 פעמים ביום - ובדרך כלל מוצאים תשובות בעמדה הראשונה או השנייה. ובצורה של הוכחת קונספט היא הוספה לאינדקס של מסמכי גוגל: כל הדוקסים, התיקיות, כונני הוואן וכו' - כל זה גם נלקח בקלות לתוך החיפוש הפנימי".
פריצה שנייה: איך לא לפספס דברים חשובים באופן קריטי בחבורה של צ'טים
"אם אתה עובד בצוות מבוזר, אז כנראה שחלק ניכר מהיום שלך עובר ב-Slack - ובמקרה כזה אתה רגיל לעשות משהו כזה: "@myteam, עזור/הסתכל/הזן את הנכון... "." אבל יש בעיה עם שפע המידע - ואפשר לפספס אזכור נפרד בין הודעות אחרות.
ב-Skyeng אנו נעזרים בבוט שדרכו ניתן לכתוב הודעה ולתייג כל מספר של אנשים או קבוצות. אנחנו משתמשים בו במקרים שבהם זה באמת חשוב שאנשים יקראו או יגיבו: הוא יחטט בלי סוף עד שתלחץ על כפתור "קראתי" - לא תוכל לדלג או להתעלם ממנו".
שאלה לתשובה: מה לעשות עם התיעוד?
"הרבה ידע מגיע מאנשי טכנולוגיה, אבל לא כולם יודעים לתאר אותו היטב.
אחרי הכל, אין לך שום מהדר או לינטר שיגיד לך אם אתה עושה את זה נכון או לא - ולעתים קרובות הפלט שיש לנו הוא לא מובן, מעוצב בצורה גרועה וטקסט לא שלם. כמובן, אתה צריך לעשות את זה כרגיל, לא בגלל שמישהו בא ואמר "זה הכרחי" - אתה עושה את זה טוב לעצמך: בעוד חודש-חודשיים תקרא את זה ותבין. ואדם אחר, שפותח מסמך, לא יסגור אותו מיד לנצח, מתוך הבנה שהוא חסר תועלת.
חלק מהפודקאסט מוקדש לשאלה "כמה אנשים צריך כדי לכתוב תיעוד טוב או לעשות הדגמה רגילה"
אך נותרה השאלה: כמה זמן להקצות לכך ואיך לעשות זאת ביעילות?
ואם יש כאן תשובה כנה: אלא אם כן מעורבים אנשי עסקים, ואם הם לא יחוו באופן אמפירי את ההשפעה של תיעוד טוב, יש סיכון שהמאמץ יניב תמורה מועטה. זה יותר סיפור על שינוי תרבות.
לכל השאר, הניסיון והליווי יצילו אותך. אנלוגים של תכנות זוג, מעקב התקדמות וסקירות קוד עשויים להתאים כאן - מציגים שיטות עבודה מומלצות, חטטנות בשגיאות ומשעממים בסופו של דבר."
בונוס: "בסדר, אני אגיד להם ככה, הם יבינו"
השאלה "כמה זמן להשקיע בזה ובאיזה רמה לעשות את זה" חשובה לא רק במסגרת התיעוד, אלא בכלל להעברת כל ידע. ההדגמה היא גם דוגמה מצוינת לשיתוף מידע. אבל יש ניואנסים: למשל, איך לוודא שהם לוקחים זמן מינימלי.
ערוץ שיתוף ידע בין פיתוח: דוחות פנימיים, ספרים שימושיים, מאמרים וכו'. התמצית המובנית מאוחסנת גם ב-Notion.
בחלקם, ניתן לפתור בעיות אלו על ידי תרגול של דוחות פנימיים. פעם בשבוע נלקחות 40-60 דקות בזמן פחות עמוס - והחבר'ה עושים דיווח וידאו לקולגות מפרויקטים שונים. צוות החזית של מוצר המפתח - Vimbox - על ערכת ממשק המשתמש שלך, שיכולה להתאים לכל פרויקט אחר. צוות הפיתוח השיווקי דיבר על ספרייה למעקב ורישום בקשות, שמשכה מיד את התעניינותם של כמה פרויקטים אחרים. צוות פרויקט מתמטיקה שיתף את החוויה שלהם במעבר מ-REST API ל-GraphQL. צוות השיעורים הקבוצתיים חושב לשתף כיצד הם היו הראשונים לעבור ל-PHP 7.4. וכולי.
הרשימה נשמרת מאז מאי 2018 ויש לה למעלה מ-120 ערכים
כל הפגישות מתחילות דרך Google Meet ארגוני, מוקלטות ובתוך 1.5 שעות מופיעות בתיקייה בכונן Google משותף, וקישורים להקלטות משוכפלים באותו Slack. כלומר, לא חייבים להגיע אם יש מקרה חירום, אלא לצפות בו מאוחר יותר במהירות 20 - בדרך כלל הדיווח עצמו נמשך עד XNUMX דקות, והדיון - איך זה יוצא. אבל אנחנו לא הולכים מעבר לשעה)
נ.ב. מה עבד ומה לא עבד לך?
קישורים שימושיים:
- רודיון נגורנוב ממעבדת קספרסקי על ולמה זה לא תיעוד (תודה לערוץ של איגור על הקישור , יש עוד הרבה כאלה).
- איגור צופקו מפלאנט על זה בחברה שלי
- אלכסיי קטייב מסקיינג (פערי ידע בטכנולוגיות ובתחומים ספציפיים) בצוות מבוזר.
- סרגיי גונצ'רוק מפלאנט על העברת מידע - , אם אתה נתקל בבעיה בצוות מבוזר.
מקור: www.habr.com