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