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

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

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

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

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

לאחר שהנחנו את היסודות - הKPIs שלנו - אפשר לבנות עליהן את העקרון השני: עבודה בצוותים מועצמים.

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

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

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

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

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

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

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

התהליך בו אנחנו צריכים לשכנע זה את זה ולהגיע למצב שהצוות מסכים על החשיבות של המשימה, מוביל לכמה דברים חיוביים וחשובים:

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

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

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

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

אתם מוזמנים לשמוע עוד על עבודה בצוותים מועצמים בשני הפרקים האלו: איך עושים פרודקט במאנדיי.קום ואיך לבנות פיצ׳ר מנצח.

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

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

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

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

נשתמש בדוגמא שנתנו קודם - נניח שהצוות עובד על פיצ׳ר חדש, וצריך להחליט איך לבנות אותו:

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

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

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

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

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

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

השתכנעתם? רוצים לנסות גם? הנה כמה טיפים פרקטיים לבניית צוות כזה:

אנשים זה הכל

• כדאי לשים דגש על העבודה בצוותים מועצמים כבר בשלב הגיוס, ולאורך כל הדרך: אחד הדברים שאנחנו מנסים לחפש כשאנחנו מראיינים מועמדים לכל המשרות - פיתוח, מוצר, עיצוב וכולי - הוא היכולת והרצון לעבוד בסוג כזה של צוות. נחפש מישהי שיכולה לשים את האגו בצד ולהקשיב באמת, וגם להשתכנע אחרת ממה שחשבה בהתחלה אם יש לכך סיבה טובה; שיש לה את הרצון להבין דברים לעומק ועד הסוף גם אם הוא לא בתחום המקצועי שלה; והסבלנות להסביר את הדברים שהיא כן מומחית בהם לחברי הצוות שלה, שיכולים להגיע מעולמות שונים לחלוטין. וגם בהמשך הדרך, בשיחות 1:1 עם המנהלת ובתהליכי המשוב, יש דגש גדול על אותן יכולות.
• בניית אמון מקצועי הוא אחד הדברים הכי חשובים בצוותים מועצמים - תקדישו את הזמן לבנות אותו: תשקפו לאורך כל הדרך את העבודה שלכם, אם יש בעיות לא צפויות או אתגרים, מה אתם לומדים תוך כדי התהליך (בין אם זה צלילה למחקר משתמשים, כתיבת קוד, עיצוב תפריט או כל דבר אחר) ואיך אתם מתכננים להתמודד עם אותם אתגרים. נסו לשתף באופן שיהיה כמה שיותר ״מכליל״, כלומר שכל חברי הצוות יוכלו להבין (גם למי שאין רקע טכני או עיצובי למשל); תשתפו זה את זה בדילמות, ותפנו לצוות כשאתם צריכים לקבל החלטות משמעותיות בנוגע למשימה.
• בתור מנהלות צוות, לתת קונטקסט זה חשוב אבל צריך גם לוודא שלא נותנים את כל התשובות. הדרך ליצור צוות מועצם היא לתת לאנשי הצוות את מרחב הפעולה להבין, לשאול ולטעות כדי לייצר אצלם הבנה עמוקה ואמיתית של האתגרים ושל העסק. אנחנו נמנעים מלהוריד מסמכי דרישות מפורטים שמכוונים בדיוק איך דברים צריכים להיראות. במקום זה, אנחנו מייצרים checkpoints שבהן אנחנו מתכנסים כצוות (או חלק ממנו) כדי לדבר על הבעיה והפתרון - אלו דיונים שיובלו על ידי חבר הצוות שאחראי על המשימה, שבהם הוא מגייס את הצוות לעזור לו לייצר פיתרון מעולה. ככה יש מקום לחדשנות וגם לטעויות מצד אחד, ועדיין אפשר לשמור על כיוון משותף וסטנדרט מקצועי גבוה מצד שני.
• בתור מנהלי מוצר, חשוב להבין את הקונטקסט הטכני בדיוק באותה מידה שחשוב שהמפתחים יבינו את הקונקסט העסקי. אתם לא צריכים לדעת לכתוב שורת קוד אחת, אבל כן חשוב מאוד להבין את היתרונות והחסרונות של בחירה בפתרונות טכניים מסויימים, את רמת המורכבות שלהם, את התקלות והבאגים וההשפעה שלהם על המוצר בפועל ועל העבודה של הצוות, וכולי. גם מנהל מוצר שאין לו שום רקע טכני יכול ללמוד לדבר בשפה הזו. למשל, אם בעדכון היומי (דיילי/סטנדאפ) אחת המפתחות מדברת על משהו שאתה כמנהל מוצר לא מבין, זו האחריות שלך לשאול ולוודא שאתה מכיר את המשימה שהיא עובדת עליה. אפשר לבקש ממנה הסבר אחר כך כדי לא לעכב את כולם :)
• מערכת היחסים בין מנהל המוצר לראש צוות הפיתוח היא קריטית לבניית הצוות. אם הצוות מרגיש שהם לא מעריכים אחד את השני, שאין ביניהם אמון והקשבה - זה ישפיע מאוד על האווירה האישית והמקצועית בצוות. תקדישו את הזמן לעבוד על היחסים - 1:1 לפחות פעם בשבוע; תדאגו להשאיר זה את זה בלופ - לעדכן באופן שוטף בדברים שקורים (גם הפחות טובים), להזמין לישיבות, לכתב על האימיילים וכולי; אם יש ביניכם קונפליקטים תשבו על בירה ותדברו עליהם; ותשקפו זה לזה מה אתם צריכים מהשני על מנת להצליח.
• וכמובן שגם הקשר בין חברי הצוות הוא לא פחות מקריטי. תנסו לשבת כמה שיותר ביחד באותו איזור, תשבו לאכול ביחד צהריים, אפילו דברים קטנים כמו swag משותף או בדיחות פנימיות ממש עושות את ההבדל. וכמובן הכי חשוב - להתחפש ביחד למסיבת פורים בעבודה :)

תהליכי עבודה

• Ceremonies שתפקידם לוודא שהקונטקסט ההדדי נשמר: אנחנו מניחים שגם לכם יש daily, planning והישיבות הקבועות הנוספות - כדאי להשתמש בהם, ובמפגשים קבועים נוספים, על מנת לוודא שהצוות שומר כל הזמן על זרימת המידע והעדכון ההדדי. מנהל המוצר יכול להזמין את הצוות לשיחות עם הלקוחות; אפשר לעשות איזשהו מפגש של ted talks שבהם כל פעם מישהו אחר מהצוות יציג איזשהו נושא - טכנולוגיה שפחות מכירים, מתודולוגיה של מחקר, מחקר מתחרים וכולי; וכמובן להציג בפני הצוות את התוצאות של המחקר האנליטי/הצעות לעיצוב שהמעצב עבד עליהן/המסקנות ממחקר המשתמשים וכולי.
• Offsite הוא כלי חשוב, שיכול ממש לעזור לחבר את כולם לעשייה המשותפת. פעם ברבעון לפחות, וכאשר אתם מרגישים שיש קצת ירידה בתחושת חיבור למשימה, למטרות ולכאבים של הלקוחות, או שחברי הצוות מרוכזים במשימות שלהם ופחות מתעמקים במה ששאר חברי הצוות עושים - כדאי לקחת את הצוות לחצי יום או יום מחוץ לעבודה השוטפת (חשוב שהוא גם יהיה פיזית במקום אחר, ולא בחדר ישיבות במשרד) ולמלא אותו בתוכן שמתאים לפער עליו אתם מנסים לגשר: חשיבה מחדש על הmission של הצוות או על הkpis המובילים שלו; התעמקות במחקר שוק או מחקר משתמשים, עיבוד של התובנות שעולות ממנו והחלטה משותפת איך לשלב את המסקנות האלו בroadmap; או רטרו של הצוות על עבודה על פרויקט מסוים/הרבעון האחרון, שיוביל להחלטה משותפת על הצעדים שתעשו ביחד על מנת לחזק את הנקודות הטובות ולשפר את הנקודות הפחות טובות.
• פרקו את המשימות לחלקים קטנים: נניח שדיברנו, חשבנו, ובסוף יש שני דברים שהצוות רוצה לעשות ומרגיש שיתנו הרבה אימפקט ללקוחות, ואנחנו לא יודעים איך להחליט ביניהם. מה עושים? אחד הדברים שמצאנו שעוזר מאוד לשחרר את החיכוך בהחלטות כאלו, הוא היכולת לפרק אתגרים כאלו לחלקים קטנים. כך אפשר להפגיש את הרעיון עם המציאות בסבבים קצרים ולקבל פידבק אמיתי - כזה שכבר לא מעוגן בדעות ומחשבות ותיאוריות. יש לזה שני יתרונות משמעותיים: הראשון הוא כמובן הולידציה של הפתרון שלנו, והשני והפחות מודגש הוא ההרגשה של הצוות, שכל החלטה שנקבל היא בעלת עלות יחסית קטנה בצעד הראשון. בצורה כזו יש מקום ליותר ניסויים/רעיונות בטווח הקצר, וזו צורת עבודה שמנטרת את כל החיכוך והצורך בתעדוף ברמה המדויקת ביותר. אם הצוות מחליט להשקיע שבוע מאמץ בכיוון שאני חושבת שהוא פחות impactful, יהיה לי הרבה יותר קל להסכים עם הצעד הזה מאשר אם היינו משקיעים באותו כיוון חודש שלם לפני שהיינו מקבלים עליו ולידציה ראשונית.
• יצירת מסגרת עבודה מסודרת: חשוב לייצר תבניות עבודה ברורות, שמאפשרות להתקדם באזורים שלרוב נזנחים: החזרת חובות טכניים, שיפורי תשתית או אפילו סתם שיפורים קטנים שאף פעם לא מגיעים אליהם. זה מאפשר להוריד את העוקץ בכך שאי אפשר ״לבחור לעשות הכל״ ותמיד צריך לתעדף, כי הצוות יודע שהוא מקדיש זמן מוקצב לצרכים ולבעיות שנופלות בין הכסאות. אצלנו עשינו כל מיני דברים שעבדו לנו טוב כמו Bugs Sunday (כל יום ראשון באיטרציה פותרים באגים) או Foundations Iteration (כל רבעון מקדישים שבועיים להחזר חובות והשקעה בתשתית). ככה בעצם אפשר לייצר תחושת שליטה וביטחון בצוות שגם לאזורים האלו נגיע, ולא צריך לנסות לדחוף לספרינט בודד את כל הבעיות בעולם בבת אחת.
• להתעקש על עבודה בקונטקסט גם כאשר יש צרכים עסקיים משמעותיים שמשנים את התמונה: דמיינו שהחברה החליטה שהיא יוצאת לסבב השקעה, או הנפקה, או מנסה להשיג לקוח מאוד גדול שיכול לעזור לה לפרוץ לשוק מסוים עם המון פוטנציאל צמיחה. אלו דברים ש״משנים את חוקי המשחק״ וגורמים לצוותים לשנות את התוכניות שלהם בזמן קצר, על מנת לתרום למאמץ המשותף של כל החברה להגיע לאותה מטרה. בעינינו, גם אם ברור לכולם למה המטרה הזו היא הדבר הכי חשוב שהצוות צריך לעסוק בו כרגע - חשוב לא ״להפיל את המשימה מלמעלה״, אלא ליצור את הקונטקסט וההבנה על חשיבות המשימה, לא פחות מאשר משימות על פיצ׳רים שהצוות בחר לבנות: לשקף את התהליך, כיצד הוא נראה מזוית הראייה של הנהלת החברה, המשקיעים או הלקוח, מה החשיבות שלו ואיך הוא יכול להזניק אותנו קדימה כחברה, ולרתום את כולם לתהליך. זה נכון במיוחד במקרים בהם נדרשת עבודה רבה בזמן קצר (כמו שקורה פעמים רבות לפני השקעה, הנפקה, תהליך compliance וכולי), והצוות יצטרך לעבוד שעות ארוכות על מנת להשיג את המטרה. כך נוצרים שני דברים: א׳ - כולם יעשו את העבודה הטובה ביותר כי הם יבינו לעומק את הצורך (למשל, מה בדיוק המשקיעים יבחנו בסבב ההשקעה) ויעבדו למען המטרה בצורה המדויקת ביותר. ב׳ - הצוות יעבוד עם מלא מוטיבציה ורעל בעיניים, כי הם מבינים בדיוק עד כמה מטורף האימפקט של מה שהם עובדים עליו ומרגישים חלק מהדבר הגדול הזה.

נעה ודניאל המשיכו את הדיון בנושא גם בקהילה, את השאלות והתשובות שלהם תוכלו למצוא פה