שלום, שמי לילך נחמיאס, ראשת צוות Archive בחברת Own, המאפשרת למעל 6,500 לקוחותיה ברחבי העולם, לנהל את המידע המניע את העסקים שלהן, באופן עצמאי ובטוח על גבי אפליקציות SAAS.
כשהצטרפתי ל-Own ב-2019, התחלתי כמפתחת Backend במוצר יחסית חדש שהחברה השיקה. בזמנו, היו למוצר שעבדתי עליו 17 לקוחות ובתוך 4 שנים גדלנו למעל 1000 לקוחות. עם הגדילה של הקבוצה קודמתי לתפקיד ניהולי והיום אני מנהלת צוות של 6 מפתחים. וכמובן שעם הלקוחות מגיעות גם הדרישות ליכולות חדשות במוצר.
מתוקף תפקידי כמנהלת צוות בפיתוח, אני נתקלת לא אחת בבקשות ממנהל המוצר לפתח epics גדולים ומורכבים. בתיאוריה, צוות הפיתוח יעבוד כל האלמנטים ב-epic ויגיש לכלל הלקוחות מוצר אחיד מושלם. בפועל, בכל רגע נתון אנחנו עובדים על מספר epics למגוון לקוחות. אלו משימות שדורשות זמן, ועלי מוטלת המשימה לדלוור.
כדי לייצר ערך עבור הלקוח, מנהל המוצר ואני, ממפים יחד את האלמנטים הקריטיים שאיתם ניתן להתקדם לפרודקשן בשלב הראשון, שיתנו מענה מהיר ויעיל ללקוח, וגם יאפשרו לו להשיב פידבק לצוות הפיתוח, איתו נטייב את עבודת הפרודקשן לשלב הבא.
אז איך אנחנו עושים את זה?
מיפוי - כשמגיע רעיון ממנהל המוצר, בתור נציגת הפיתוח שמכירה את היכולות, אני בשלב ראשון ממפה את הדרישות על מנת לבדוק מה התהליך הכי מתאים לאיזו דרישה. חלק מהדרישות אנסה להתאים למימוש קיים, על מנת לחסוך בזמן, חלק אחר, שאולי דורש זמן לפיתוח ושאינו קריטי לשלב זה, אדחה לשלב מתקדם, ואתמקד בתעדוף הדרישות שהכי קריטי לטפל בהן בשלב הראשוני.
מו״מ - כמובן שלא על הכל יסכים איתי מנהל המוצר, שמייצג את הלקוח. זה הזמן להיכנס לדיון משותף, לשטוח בפניו את התעדופים וההמלצות שלי מבחינת מורכבות היישום והערכות הזמנים, להסביר למה יש דברים שבעדיפות נמוכה כרגע, לשמוע ממנו מה קריטי ללקוח ולהתאים את תכנית העבודה בהתאם. הדיון הפתוח הזה מאפשר לנו לקבוע מה ואיך נדלוור מהר יותר, עם מה אפשר לחכות איתו ולדלוור בהמשך, מה נרצה לשחרר עכשיו ולקבל עליו פידבקים, ולנסות להבין האם אנחנו פותרים את הבעיה הנכונה תוך שאנחנו נותנים מענה למספר לקוחות שונים בו זמנית.
המו״מ הזה תורם לשקיפות ולשיח פתוח שמייעל את העבודה המשותפת.
תכנית עבודה - אחרי שיישרנו קו עם מנהל המוצר, אגדיר את ה-core functionality הכי חשוב ומינימלי, שיקבע על-ידי תעדופים למשימות.
בכדי להתקדם מהר יותר לדילוור ולעמוד בדרישות הלקוח, תוך כדי הקפדה על קבלת פידבק מהיר,
הצוות יעבוד תחת feature flags פנימיים. כל חבר צוות רלוונטי בארגון (מאנשי מכירות ועד לאנשים הטכניים) יהיה חשוף למשימה, יבדוק אותה ויוכל לתת עליה פידבק מהיר ואיכותי עוד לפני שהפיצ׳ר מגיע לפרודקשן, ובכך להתקדם מהר יותר לעבר פיתוח פתרונות יעילים עבור הלקוח שלנו.
פרקטיקה - כבר משלבי הפיתוח הראשונים אנחנו דואגים לייצר דמואים לכל ה-stakeholders הרלוונטיים לתהליך; צוות המוצר, צוות ה-ux והכתבים הטכניים. אפילו אם אין משהו ״משמעותי״ לראות - רק מסך עם שדות שלא עובדים עדין, חשוב לנו לייצר את התמונה המלאה כדי לקבל פידבק. בכל דמו קטן כזה שמראה חלק, אנחנו עוצרים וחושבים האם אנחנו בכיוון הנכון ועושים את הדבר הנכון שמביא את הערך ללקוח.
היו הרבה פעמים שהמשך הפיתוח השתנה בעקבות אותו פידבק מוקדם, גילינו שהדמואים הללו תורמים ליישום של תהליכי agile, מקצרים את תהליך הפיתוח ומדייקים את התוצר.
פידבק מהיר - אז למה אנחנו בעצם מקפידים על הדמואים? כי הם משקפים את סטאטוס ההתקדמות של הצוות, הם עוזרים למנהל המוצר להבין באיזה שלב נמצא הצוות מבחינת פיתוח, מה חסר ומה צריך לשנות ולשפר, מעלה פערים - כי אין כמו מראית עיניים, וגם עוזר לתפוס באגים בשלבים ראשוניים שקשה לזהות ב-code review ולזהות דברים שפספסנו בדרך, עוד בשלב ה-design. בעזרת ההכוונה של מנהל המוצר, שמכיר את הלקוח והצרכים שלו, אנחנו מקצרים את הטווחים גם לפידבק מהיר מהלקוח.
קריאת הבלוג 
האזנה לפרק 
שאלות / פידבק
