מאמר

turkeyDinner
אריאל וייס

|

השילוב המנצח בין UX ל-Agile

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

 

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

 

 

wristWatch

 

 

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

 

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

 

 

brokenUp

 

 

לפרק ולפרק (ולתעדף)

 

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

 

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

 

להיות חלק מהצוות

 

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

 

ב-OurCrowd (החברה בה אני עובד), יש לנו אנשי צוות ברחבי העולם מרקעים שונים והמשובים המיידים על כל שלב בעבודת המוצר וחווית המשתמש הם קריטיים לחברה.

  

איך מתמודדים עם זמני ההמתנה?

 

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

 

 

stopWatch

 

 

למדוד הכל

 

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

 

לאהוב את המשתנים 

 

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

 

 

האם אתם גם משתמשים בשיטת Agile במקום עבודתכם? או שאולי אתם חושבים שהיא פוגעת בתהליך ה-UX? ספרו לנו בתגובות.

אולי יעניין אותך גם: