העברת ידע

צ’קליסט מתכלל להעברת ידע בפרוייקטי תוכנה.

מבנה הקבוצה:
– חברי הצוות
– היררכיה ואחריות, שרשרת דיווח
– אנשי הקשר של הלקוח / צוותים / ספקים קשורים
– מספר טלפון
– כתובת דוא”ל

דרישות עסקיות:
– תיאור דרישות העסק
– מהי הפונקציונליות שהתוכנה מאפשרת?
– מה השיקולים והדרישות של בעלי העניין וכיצד התוכנה ממלאת את הדרישות הללו באופן מלא?
= תרחישי שימוש ו/או usecases
– תיעוד משתמשים
– תרחישי בדיקה
– סטטוס הגרסה האחרונה של הSTR (# בדיקות עברו, נכשלו ולא הופעלו)
– איך בודקים מרחיש שפיות?

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

תיעוד טכני:
– ארכיטקטורת מערכת
– ארכיטקטורה \ תכן של תתי-מערכות
– מבנה מסדי נתונים
– ארכיטרטורת רשת
– ארכיטקטורה מבחינת פרימיטיבים טכניים
– ארכיטקטורה מבחינת משימות עסקיות, מקרי שימוש
– החובות הטכניים של הצוות
– כל הממצאים וההצעות הטכניות בנוגע למערכת הקיימת
– החלטות עיצוב ADR
– אילו תכונות איכות מערכת זיהו והתייחסו כיצד?

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

מערכת אספקה ​​וסביבה:
– שרתי CI/CD
– תשתית בדיקות
– בנה גרסאות
– אסטרטגיות פריסה
– איך מתקינים את התוכנה?
– איך מגלגלים את התוכנה לאחור?

מערכות מידע (חשוב מאוד):
– מערכת טיפול בבקשות משתמשים (או SRS וזרימה ידנית)

מערכת מעקב אחר באגים (JIRA, TFS או GITLAB)
שלח מייל והודעות
מיילים וסיכומים חשובים
הערות פגישה (זכור לעדכן את הגרסה האחרונה!)
קובצי עיצוב UI/UX (axure, jpeg, pngs, invision)
ספריות קבצים (תיקיות משותפות)

תיעוד הפרויקט
– גרסאות העבודה העדכניות ביותר (מקווה שאתה משתמש ב- git כדי לטפל בהן!)
– דוחות התקדמות פרוייקטים פנימיים
– מסמכי תכן SDD או HLD אם יש, אם אין זה זמן טוב לכתוב אחד.
– רשימת מלאי
– כל תוכנה שנמסרה ללקוח (גרסאות, כלים)
– כל תוכנה המסופקת מהלקוח (מפתחות, מזהים, כלים)
– כל חומרה המסופקת מהלקוח (מפתחות, מזהים, כלים)
– מערכת בסיס ידע / פורטל מידע . WIKI או SHREPOINT או אחר
– כיצד להתחיל – מדריך למפתח חדש
– מערכת פיקוח או ALM (JIRA ןכדומה) – איך משתמשים ומה הדגשים לכתיבה ולהתמצאות
– מערכת ניתוח פעולות משתמש
– חשוב לזהות אנשי קשר לכל הנושאים הנוגעים לכל מערכת
– כמו כן כל הנהלים והטקסים: עיבוד זרימה של בקשות משתמשים; אישורי זרימה של תיעוד טכני חדש

תהליכים ורשימת מקבלי ההחלטות (DM – decision makers):
– נהלים ורשימת DMs הקשורים לשגרה יומית
– נהלים ורשימת DMs הקשורים לסגירת שלב ספרינט / איטרציה / עבודה
– נהלים ורשימת DMs הקשורים לתכנון מהדורה / איטרציה חדשה
– נהלים הקשורים לטיפול בבקשות שינוי, ורשימת מסמכי DM
– נהלים וטקסים הקשורים להוצאת מהדורה חדשה
– צוות בדיקות, אבטחת איכות:
– הכרחי כדי לקבל גישה לכל מסדי הנתונים של סקריפט הבדיקה
– הכרחי כדי לקבל את התיאור של הליכי נושא השחרור

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

תחום פעולה \ התנהלות פרויקטלית:
– תוכנית עבודה
– מפת דרכים
– גִרְסָה פעילה \ אחרונה
– איזו גירסה ניתנת מתי?
– מהן התכונות העיקריות / יישומים / משימות / באגים בכל גרסה
– אבני דרך – כיצד גרסאות אלו משפיעות על הלקוח?
– תשלומים – על מה קיבלנו תשלום, על מה נשלם עבור נקס? מה עם הגרסאות הבאות?
– הגדרת מטרות במונחים טכניים
– הגדרת מטרות מבחינת המוצר

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

סעיף “מטרות” חשוב ביותר:
מה נדרש מצוות הפיתוח, הבדיקה והתמיכה? מה הכי חשוב לעשות עכשיו?
מהן מטרות הצוות החדש?

הנוסחה לשינוי

כדי ליצור שינוי נדרש
– חזון – לאן אנחנו הולכים?
– מניע – למה אנחנו הולכים לשם?
– תוכנית עבודה -איך אנחנו מגיעים לשם?
– מיומנות ומשאבים – מה הכלים שלנו כדי להגיע לשם?

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

ייעוד (purpose)

הכוונה להבנה – “למה מה שאני עושה חשוב?” (או איך העשיה שלך משנה את העולם). מה התמונה הגדולה? איך הדברים שאתה עובד עליהם גדולים וחשובים יותר מעצמך? איך הדברים שאתה עושה תומכים את החברה או את העולם? קשר ישיר עם הלקוח יתמוך בתחושה של מטרה. אחריות מקדמת תחושה של אחווה שבתמורה תתמוך את תחושת המטרה של הצוות.

איך לתמוך במטרה	איך לערער
לספק קשר קבוע עם לקוחות בפועל	מנע קשר ישיר בין מפתח ללקוח
לספק קשר שוטף עם אנשי עסקים פנימיים	צור מאגורות – מצב בו הצוות הטכני והעסקי לעיתים נדירות מתקשרים.
תתקשר את התמונה הגדולה באופן תדיר אל הצוות	תתקשר את התמונה הגדולה רק במפגשים של כלל החברה
וודא שהתקשורת מגובה במציאות	תקשר מידע קלישאתי שמנותק מהמציאות
תאר את האימפקט של עבודת הצוות בעולם האמיתי: “המוצר שלנו הציל XX חיי אדם בשנה האחרונה”	התעקש שהתמונה הגדולה היא נחלתם של מנהיגים – והצוות לא צריך לדעת על התמונה הגדולה.
להדגיש את הערך של עבודה באיכות גבוהה	דונו רק ביתרונות כספיים מיידיים לחברה ו / או ליעדי מסירה לטווח קצר

מומחיות (mastery)

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

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

אוטונומיות

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

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

ההימור שלי – לחברות פרויקטים בתוכנה

עם קשר \ בלי קשר לתהליכים שלנו – אני חושש שפתאום התגבשה אצלי תפישה. פתאום קרה לי “קליק” – הכל נפל למקום הנכון. אולי הדעה שלי קיצונית – הייתי רוצה לשתף אותה אתכם.

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

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

• קונבנציה של קוד יכולה לעזור למנוע בעיות תדירות. אם נתעד ונעקוב אחרי הדרכים הטובות אולי נוכל להימנע מבעיות שפגשנו בעבר.
• סקרי קוד עוזרים לנו למצוא טעויות. עיניים של אנשים אחרים יכולות לראות משהו שהעיניים שלי לא רואות. אולי קשה להביע ביקורת- אבל כל עוד הכוונה היא לשפר את דרכינו אני חושב שרק יצא מזה טוב. בנוסף – זה כן אומר שכולם צריכים שיבצעו להם סקרי קוד (כולם! ראשי צוותים, ואפילו אני צריך סקר קוד).
• כלי סריקת קוד יכולים לאתר בעיות פוטנציאליות.
• שימוש בבקרת תצורה עוזרת לנו לחזור למצב לקין. זה הכפתור UNDO  הענק שמאפשר לנו לחזור אחרוה בזמן – לנקודה שידענו שהיה יותר טוב.
• בדיקות אוטומטיות עוזרות לנו להימנע מטעויות. זה לא משנה אם הן בדיקות יחידה או אינטגרציה – ברגע שאני יודע שיש בדיקה אדומה – אני יודע שמשהו שבור. בנוסף רק הבדיקות מראות מה האמת. והאמת? האמת כולה בקוד ולא בשום מסמך.
• Continuous integration מתריעה על תקלות מוקדם. היכולת להתריע על תקלות מוקדם היא קריטית! אנחנו צריכים לדעת שנגענו באזורים רגישים של המערכת – גם בכאלה שלא יכולנו לצפות מראש. היחידה שיכולה לבדוק את זה היא המכונה – כאמור – היא לא עושה טעויות.
• Continuous deployment זו יכולת לתקן טעויות מהר. אם לוקח שבועות או חודשים לשחרר גירסה ללקוח –אנחנו נשארים תקועים לנצח בהמתנה לאישור שינוי קוד קטן באמת עונה על צרכי הלקוח.

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

מאפייני צוות בעל ביצועים גבוהים

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

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

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

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

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

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

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

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

יעדי התכן ומסמך התכן

להלן רשימה כקו מנחה להגדרת התכן ורשימת הפרקים בו

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

אתגרי תכן תוכנה

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

לתכן, כתהליך, יש מספר אתגרים:

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

בהיבט האתגרי – תכן הוא יותר אומנות ממדע.

פידבק ב15 שניות

בספר “the effective manager” יש מדריך למסירת פידבק ב15 שניות ב4 צעדים פשוטים:

1. שאל – “האם אני יכול לתת לך פידבק?”
2. ציין את ההתנהגות (“כשאתה עושה X…”)
3. ציין את האימפקט (“… התוצאה היא Y.”)
4. ציין את היחס (“המשך כך” לפידבק חיובי, או “אנא המנע מזה בעתיד” לפידבק שלילי).

דוגמאות מהיומיום:

• “כשאתה מעדכן את המנהל שלי, אפילו כשהכוונות שלך טובות, אני מוצא את עצמי מתרץ למנהל שלי מדוע אני לא מסונכרן. האם תוכל בפעמים הבאות לעדכן אותי לפני כן?”
• “כשאתה משחק בטלפון תוך כדי הפגישה עם הלקוח אתה משדר חוסר מעורבות וחוסר עניין – ומעביר ללקוח מסר שאתה לא קשוב לצרכיו. אנא הימנע מכך בעתיד?”

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

הספר מעלה גם 3 שאלות שכדאי לשאול את עצמנו לפני שאנחנו ניגשים לתת פידבק:
1. האם את\ה כועס? אם כן – אל תספקו את הפידבק.
2. האם את\ה מתעסק\ת בעבר במקום בעתיד? (האם את\ה מזכיר\ת שוב ושוב את אותו אירוע שקרה בעבר?) אם כן – אל תספקו את הפידבק.
3. האם את\ה יכול לוותר על הפידבק? (לשחרר) – אם לא – אל תספקו את הפידבק.
בגדול – אם את\ה מרגיש דחף לתת את הפידבק – את\ה כנראה עושים משהו מהסיבות הלא נכונות.