להשתפר מעט כל יום. האם זה לא יהיה נהדר? ב-Easy LMS, כולנו מאמינים בשיטת הקייזן. שיטת פרודוקטיביות יפנית זו עוזרת לנו להתמודד עם בזבוז זמן, להפוך את העבודה לנעימה וקלה יותר. ההיבט המרכזי שלה הוא שיפור מתמיד.
למה קייזן?
תהליכי שיפור משמעותיים. ניסינו, תאמינו לי, אבל אף פעם לא עם האפקט הרצוי. הם נעצרו, כי לא יכולנו לבחור מבין כל השיפורים האפשריים, ואיבדנו את עצמנו בבעיות היומיומיות. תמיד הייתה שאלה של לקוח שעלתה בין לבין, שהייתה דחופה יותר מהקמת תהליך שלם.
מכיוון שאנחנו מאוד אוהבים להשתפר, בחרנו בשיטת הקייזן. לאחר קריאת הספר "טויוטה קאטה: ניהול אנשים לשיפור, הסתגלות ותוצאות מעולות" מאת מייק רוטר, השתכנענו ביעילותה. הרי קייזן אינו מתמקד בעובדה שהכל צריך להיות מושלם בבת אחת, אלא בצעדים קטנים בכל יום. הצעדים הקטנים הם אכן צעדים קטנים מאוד. בסך הכל, הצעדים האלה ייקחו אתכם רחוק. בסופו של דבר, אתם גם רצים מרתון צעד אחר צעד.
התרגום המילולי של קייזן הוא "שינוי לטובה".
סקירה כללית של שיטות הקייזן ב-Easy LMS
ל-Kaizen מגוון רחב של שיטות ותהליכים, גדולים וקטנים כאחד, כדי לממש שיפורים. Kaizen ב-Easy LMS מבוסס על החלקים הבאים:
קביעת כיוון באמצעות תנאי יעד.
שיפורים קטנים ומתמשכים.
ניתוח שורש הבעיה: שאילת "למה" חמש פעמים.
ידע הוא כוח.
קאיזן הוא באחריות כולם.
בואו נתמקד בחלקים שתיים עד חמש, תוך הדגמה של איך אנחנו מיישמים קאיזן. חלק ראשון דורש מאמר שלם כדי להסביר.
חלק 2: שיפורים קטנים ומתמשכים
חלק מהשיפורים נראים קטנים מדי ודווקא אז חשוב לבצע אותם.
כמה קטן זה קטן? במקרה שלנו, קטן מאוד. לימוד קיצורי דרך, או אפילו העברת מדפסת למיקום נוח יותר, הוא שיפור. לכן, ביצוע שיפורים קטנים הוא אולי הצעד הקשה ביותר. נראה שחלק מהשיפורים חסרי תועלת מדי, קטנים מדי, או בעלי השפעה קטנה מדי. לכן לעתים קרובות לא מבצעים אותם, ודווקא אז חשוב לבצע אותם. הסכנה השנייה היא שככל שמחכים יותר, הבעיה הופכת לגדולה יותר, מה שאומר שצריך לשלב אותה בתכנון, עם כל הסכנות הנלוות. אפשר להתחיל מיד בביצוע שיפורים קטנים. אפילו בלי אישור מההנהלה. כל צעד קדימה מייצר רווח.
הבנו זאת כשבחנו מקרוב את מחזור השחרור שלנו. בעבר, יצרנו פונקציונליות חדשה או פתרנו באגים באינטרנט ("שחרור") פעם בכמה שבועות. כעת אנחנו עושים זאת לפחות פעמיים בשבוע, ובקרוב מאוד זה יהיה בכל פעם שסיימנו משהו.
הדרך לשם מורכבת מעשרות צעדים קטנים (מיני). נרצה להדגיש ארבעה:
אנחנו בודקים קודם כל הכל לפני שהוא עולה לאוויר. כדי לבדוק גרסה, המפתחים היו צריכים בתחילה להנגיש אותה בסביבת הבדיקה שלנו. מפתחים לפעמים שוכחים את זה, או חולים. הרי אנחנו רק בני אדם? זה נתן לנו סיבות רבות לוודא שהבודקת שלנו, קרוליין, תוכל להכניס את הגרסה לסביבת הבדיקה בעצמה.
יצירה אוטומטית של שחרור לוקחת 45 דקות, וזה זמן המתנה ארוך למדי. מכיוון שזה לוקח כל כך הרבה זמן, אנחנו עושים זאת כעת בזמנים קבועים: שני וחמישי בבוקר בשעה 6:00. כשקרוליין מגיעה, היא יכולה להתחיל מיד. אבל קודם, כמובן, כוס קפה?
בתחילה נדרש מפתח גם להעלות גרסה לאוויר בסביבה החיה. זה כבר לא המצב. כיום קרוליין עושה זאת בעצמה. העלאתה לאוויר אפשרית רק אם הכל אושר.
אנחנו תמיד מנהלים מבחני קבלה וזה לוקח הרבה זמן. במיוחד אם יש 25, כמו שקורה אצלנו. לכן, התחלנו להפוך את הבדיקות האלה לאוטומטיות אחת אחת. הבדיקה הראשונה חסכה לנו קצת זמן. עכשיו כולן אוטומטיות וזה חוסך לנו 12 שעות בשבוע.
חלק 3: ניתוח שורש הבעיה, תוך שאילת "למה" חמש פעמים
כשמשתמשים בקייזן, לא סתם מתקנים דברים.
כשמשתמשים בקייזן, לא רק מתקנים דברים. מטפלים בשורש הבעיה, כך שצריך לפתור אותה רק פעם אחת. יעילות יוצאת דופן. אפשר למצוא את שורש הבעיה על ידי שאילת "למה" חמש פעמים.
בכל פעם שאנחנו לא עומדים ביעד מסוים, אנחנו מבצעים ניתוח גורם שורש. זה נותן לנו מגבלה של שלושה סיפורי משתמש שעשויים להיות בפיתוח. קבענו זאת יחד. זה מאלץ אותנו להשלים סיפורים לפי סדר עדיפות. אם מישהו בוחר סיפור רביעי, אנחנו עוצרים את העבודה ומתחילים לנתח.
לאחרונה, היינו צריכים להעלות משהו לאוויר בזמן ששלושה סיפורים כבר היו בפיתוח. להעלות משהו לאוויר, פירושו סיפור מספר ארבע. הגענו לניתוח הבא:
למה פתחנו סיפור חדש?
אנחנו חייבים לעשות שחרור והשחרור דורש סיפור שקובע מה צריך להיעשות.
למה אנחנו צריכים את הסיפור הזה?
נפרסם מספר פונקציונליות חדשות ומבוקשות.
למה נפעיל מספר פונקציונליות?
אנחנו אף פעם לא מעלים רק פונקציונליות אחת לאוויר.
למה אנחנו לא עושים את זה?
יצירת גרסה לוקחת יותר מדי זמן. העלויות עולות על התועלת.
למה זה לוקח כל כך הרבה זמן?
בדיקות הן צוואר הבקבוק.
למה בדיקה היא צוואר הבקבוק?
הבדיקות האוטומטיות אינן אמינות מספיק, ולכן ישנן בדיקות ידניות רבות.
למה בדיקות אוטומטיות אינן אמינות?
מכיוון שאנחנו משתמשים במסגרת ישנה יותר שבה אנחנו מבצעים בדיקות.
ישנם פתרונות רבים ברמות שונות כדי לפתור את הבעיה הזו. יחד נחליט מהו הפתרון הטוב ביותר כרגע. הפתרון לשורש הבעיה הזו הוא לעדכן את המסגרת להרצת הבדיקות.
חלק 4: ידע הוא כוח
איך תדעו אם שינוי הצליח? ידע הוא כוח. צור קו בסיס, ולאחר מכן מדוד אותו שוב לאחר ההתאמה. אנחנו מנסים להפוך כמה שיותר דברים למדידים, אבל לפעמים זו גם תחושת בטן שאפשר לעשות משהו מהר יותר או טוב יותר. שוב, אנחנו רק בני אדם.
תהליך שהפכנו למדידה מלאה הוא סיפור משתמש. לפני שסיפור יכול לעלות לאוויר, הוא עובר סדרה שלמה של שלבים. כיצד לנקוט בצעדים אלה? לא היה לנו מושג עד שהתחלנו למדוד זמן. אז היה ברור מיד היכן צוואר הבקבוק: לקח יותר מדי זמן עד שקרוליין יכלה לבדוק. ביצענו ניתוח גורם שורש ויישמנו באופן מיידי שיפור על סמך זה. שיפור נוסף שהופיע: תהליך ניהול התרגומים. אבל זה כבר משהו למאמר אחר.
חלק 5: קאיזן הוא באחריות כולם
קייזן עובד רק אם כולם בחברה תורם לו על ידי לקיחת אחריות והקדשת זמן ותשומת לב. ב-Easy LMS, לכל אחד ניתן המרחב להעלות שיפורים ואת הזמן להקדיש להם. כי אנחנו יודעים שזה יועיל לנו בטווח הארוך.
עכשיו, לאחר שקראתם את המאמר הזה, האם תרצו לעשות צעד נוסף בדרך לקייזן?
