מטרת הערות השקת המוצר היא ליידע את הצוותים הפנימיים שלך (מהנדסה ועד תמיכת לקוחות) ואת בעלי העניין החיצוניים שלך (לקוחות ושותפים) שנעשו שינויים במוצר. בתחום הטכנולוגי, שבו הכל מתפתח במהירות האור, הספקת עדכוני מוצר באמצעות הערות השקה היא בעיה שכמעט נראית עתיקה.
כל חברה שבה עבדתי חוותה קושי בהעברת הערות השקה "נכונה". אבל זה קשה להשגה; החשיבות של כל שינוי או השקת מוצר משתנה בהתאם לקהל, איך השינוי משפיע על האינטראקציה של קבוצה מסוימת עם המאפיין, ואיך אותה קבוצה משתמשת במוצר הכללי יום יום.
התקשורות על השקת המוצר (המכונות בדרך כלל הערות השקה) חייבות להיות מועברות לקהלים שמעוניינים בדברים שונים. כמנהיג בחלופת הכנסות ב-Guru, המייצגים שלי הם כל מי שהיכולת שלו לעשות את עבודתו מופיעה כמושפעת מהתוכנית המוצרית, כולל:
צוותי המוצר/עיצוב/מהנדסה
צוות המכירות (תפעול מכירות, מכירות פנימיות, מנהלי חשבונות לפי סגמנטים)
חווית לקוח (מנהלי הצלחה ונציגי תמיכה)
צוות השיווק (שיווק מוצר, שיווק גידול, מותג, תוכן שיובילו את אסטרטגיית ה-GTM וכלי הפצה לעיתונות עבור המוצר)
פיתוח עסקי ושותפים
כל השותפים הללו חייבים לקלוט את עדכוני המוצר ולברר מיד באיזה מידה הם צריכים להחיל את העדכונים הללו על עבודתם. הם גם צריכים לשקול איך הם יכולים לעזור למשתמשים הסופיים להבין את ההשפעה של כל שינוי על הם.
האדם (או הצוות) שמבצע את התקשורת על השקה צריך לשקול את כל הקהלים שיגבושו את הידע המוצרי. מהן ההשלכות של השקה מהנדס הקצה לעומת לקוח פוטנציאלי בתעשיית הקמעונאות?
איך לא לגשת להערות השקה
בעוד שזה קשה לקחת בחשבון את הצרכים של קהלים שונים, זה הופך גם לפשוט לא תהליך המוגן עבור מנהל מוצר או מנהל שיווק מוצר (PMM) לכתוב חמישה גרסאות שונות של הערות פנימיות. מניסיוני, הערות השקה או ארוכות מדי וחסרות הקשר או שאין בהן מספיק תוכן טכני. הערות השקה סטטיות אינן מספקות לנו את התובנות הללו ולעיתים נכתבות עבור המחבר, ולא עבור האדם שצריך להבין מה השתנה. באמת, לרוב מדובר בהזדמנויות שהוחמצו.
ישבתי במשך שעה משואית בשיחות הערות השקה שבהן קול מונוטוני ממנהל המוצר מדבר על נקודות על שקפים. לאחר סיום השיחה, אותו מנהל מוצר מקבל מיילים, שיחות טלפון (זוכר את זה?), סלוקים וכו' מכולם מצוות תמיכת לקוחות ועד מכירות שרוצים לדעת מה משמעות השינויים עבורם, לקוחותיהם והפוטנציאליים שלהם. אם החמצת את השיחה, החמצת את הניואנסים וההקשר, ובמקום זאת קיבלת רק את יומן השינויים הגולמי.
אבל זה לא תפקידו של מנהל המוצר לעשות את התרגום הקדוש הזה; תפקידם לבנות מוצר שיפתור בעיה בשוק. זו העבודה של ה-PMM לתרגם את הכוונה כך שהשוק יבין מה הערך שלו.
הסוד לכתיבת הערות השקת תוכנה מצוינות
אני מעריץ גדול של צלילי המוזיקה (מזעזע, אני יודע) וזה מקצועי לתמיכה, הלקחים הנצחיים בסרט מתאימים לי. “בואו נתחיל מההתחלה/זה מקום מאוד טוב להתחיל”, עובר בראשי על בסיס שבועי. אז, בעיצוב או שינוי תהליך שתוצג מוצר, אתה חייב ללמוד את השפה לפני שתוכל להוראות מקצוע.
1. פיתוח מיני בלשון פנימית
השלב הראשון של חקירת התהליך הזה הוא לגרום לכל הצוות לדבר באותה שפה. שיתוף מונחים משותפים נראה מובן מאליו, אבל זה עשוי לא קורה בתוך הארגון שלך. אי ידיעת ראשי תיבות והבנה לא נכונה של השפה יכולה להיות מבודדת, ליצור בלבול ומחיצות בין הצוותים.
דוגמה: צוות השיווק שלנו משתמש במונח “השקה” כדי לתאר מתי ואיך אנו נלך לשוק עם תכונה. עם זאת, צוות ההנדסה משתמש במילה “השקה” כדי לתאר מתי תכונה הושקה לסביבת הבדיקה שלנו. ההשקה הספציפית לתכונה היא “גמורה” עבור ההנדסה לפני שלקוחותינו מודעים לכך. זו הייתה חלשה ומביאה למתיחות פנימית.
אף אחד לא רוצה להיות זה שידבר בפומבי מודה שהוא לא יודע מה משהו אומר, טיפשי, על ידי בקשת הגדרות. הפתרון שלנו: בקבוצת עבודה משותפת (עם ייצוג מההנדסה, מוצר, שיווק מוצר), נפרסנו את הניואנסים ותיעדנו ההגדרות שלנו לגבי השקת המוצר:
הערה: אם אחת מהכרטיסים לא מצליחים לטעון, פשוט רעננו את העמוד!
2. מה לכלול בהערות השקה שלך
לאחר שפה משותפת הוקמה וצוותך מסוגל לבטא את המונחים של ההשקה, תוכל לכתוב את ההערות שלך. הדבר הקל ביותר לעשות הוא ליצור תבנית ניתנת לשימוש מחדש לכתיבת הערות השקה. כך, בעלי העניין יקלטו את הפורמט לאחר כמה חזרות, ובכך מציל אותך מהצורך להמציא מחדש כל פעם.
לפחות, הערות השקה טובות כוללות:
תאריך/י התאריך של ההשקה
פנימיים וחיצוניים
תיאור המאפיין או הבאג
המוצר/ים המושפעים (אם יש לך יותר מאחד)
אם יש לך כמה מוצרים תוכנה, ייתכן שתרצה לכלול גם מספרי גרסה
איפה אפשר לשאול שאלות פנימיות
לעומת זאת, הערות השקה מצוינות כוללות גם:
שאלות נפוצות מצופות (שאלות נפוצות)
קישור לתיעוד ציבורי חדש, אם זמין
עבור תכונות:
שם המאפיין
תמונות מסך של איך המאפיין נראה
וידאו על איך להדגים את המאפיין
למה המאפיין קיים
איך זה משפיע על דמויות לקוחות/קונים רלוונטיות
הנה התבנית שאנחנו משתמשים בה פנימית (אל תהסס להעתיק!):
💡הערה: זה מועיל לקבוע אנשים ישירים אחראיים למשימה זו (במקום להשאיר את זה למאמצים קבוצתיים שאין להם בעלות). מנהל ההנדסה או מנהלי המוצר צריכים לשלוט בצד הטכני של ההערות (שם/גרסה/מוצר/תאריכים/תמונות מסך), בעוד שמנהלי השיווק מוצר או מהנדסי מכירות צריכים לשלוט במידע ההקשרי (דמויות לקוח/למה זה חשוב).
יישום אסטרטגיות תהליך מסירה של מוצר
צור פורמט תקשורת עקבית
עכשיו כשמאחד את המונחים וכתוב את התבנית שלך, השלב הבא הוא להסכים על אמצעי מסירה עקיב (כלומר: Slack, מייל, Loom, Guru, Google Docs) ושיטתיות. אמצעי מסירה עקבי מבטיח שלבעלי ההערות על ההשקה ידוע איפה הם צריכים ללכת או להסתכל או להירשם (כדי למשוך) כדי להיות מודע להשקה.
זה גם חיוני עבור ניהול השינויים מכיוון שאתה בדרך כלל צריך לומר למישהו משהו כמה פעמים כדי להבטיח שהם סופגים את זה לחלוטין. בהתאם לסוג ההשקה, השינויים ל-UI/UX (ממשק משתמש וחווית משתמש), וההשפעה על הלקוח, הקהל של ההערות על השקה שלך יידרש לדחוף ידע על המוצר (לדחוף). ב-Guru אנחנו משתמשים בשני שיטות דחיפה ומשיכה.
המשיכה: היכן למצוא ידע
בשבילנו, בעלי העניין יכולים לעקוב אחרי הערות השקה שלנו בערוץ Slack #release-notes, שם יש פורמט עקבי וקל לעיכול עבור כל דבר מתיקונים לבאגים ועד תכונות חדשות. שמור על כך שהקהל שלך לא רק צריך להיות מודע לכך שההוצאות מתבצעות (באמצעות המשיכה ב-Slack או מייל) אך יותר חשוב, הם צריכים לדעת למה ההשקה הזו חשובה בהקשר.
הידע שצריכת שינוי פשוט תתרחש או התרחשה אינו בעל ערך אלא אם כן הצוות שלך יכול לעשות איתו משהו. כדי לפתח פורמט עקבי שיספק הקשר מתאים, סקרתי אנשי מכירות, אנשי פיתוח חשבון, אנשים שעניינים עסקיים (העבודה), כדי לקבוע את התבנית שלנו למסירת מוצר שקרויה “כרטיס פירוק תכונה”, שתוכל למצוא לעיל.
כאשר מנהל הנדסה מתחיל לפתח תכונה חדשה, אנשים ישירים אחראיים מתודעים באמצעות Asana כדי ליצור את כרטיס פירוק התכונה הספציפי עם תבנית הערות השקה. כרטיס פירוק התכונה החדש הופך למערכת המקיפה, המקור האחד או "מוח התכונה" שאנחנו משיקים. מומחי נושא (SME) - כמו PMM ומהנדסי מכירות - כוללים פרטים על למה ההשקה בעלת ערך, למי זה הכי חשוב, ואיפה יש לכוון, הכוונה כיצד להציג את המאפיין כחלק מסיפור רחב יותר.
בעלי ההערות על ההשקה, במיוחד מנהלי החשבון, פונים שוב ושוב לאותם כרטיסים כי הם למדו שהידע הדינמי בכרטיס פירוק התכונה הוא מהימן, רלוונטי וניתן ליישם. כעת, הקהלים מדברים באותה שפה וקוראים מאותן (דינמיות) מחברות. חזרה לכרטיס פירוק התכונה היא עדיין חלק משיטת "משיכה" מכיוון שזה נעשה באופן עצמאי, ונעשה כדי להתכונן לשיחת מכירות או תמיכה, או אם לפוטנציאל יש שאלה על התוכנית.
הדחיפה: סיפוק ידע באופן פרואקטיבי
שיטת הדחיפה נכנסת לתמונה כאשר ידע על שחרור הוא רגיש בזמן, וחיוני לצוותים מסוימים. כאן, זה מושג באמצעות פונקציית ההודעות של Guru. בהתבסס על ההשפעה על הקהלים הפנימיים שלי, אני דוחף הודעה דרך Guru לקבוצת ממוקדת רלוונטית. אחר כך אני יכול לראות דוח על אלה שהAcknowledged או קראו את האזהרה ולהזכיר ציבורית לאלה שלא.
למה תרבות מונעת ידע היא המפתח 🗝
למרות כל מה שנאמר, זה לא ממש פשוט להסכים על ניהול מונחים, לכתוב הערות השקה מצוינות, וליצור מנגנון למסירה דינמית של המוצר. הצוותים חייבים להיות מסוגלים לשתף פעולה על הידע ולתת משוב על פני זמן. סיפוק משוב ושיפור ידע על ידי שיתוף אותו הוא חלק מהתפקידים והאחריות של כל מי בצוות.
בשבילנו, זה אומר שכאשר צרכני ידע (במקרה זה, בעלי ההערות על השקה) יש שאלה או לומדים משהו חדש, הם מגיבים על כרטיס פירוק התכונה. אנו גם משלבים שאלות שהוצגו ונענו בדרך סלוק כדי לשפר ידע בצורה מתמשכת. מומחה הנושא (בדרך כלל ה-PMM) יסקור וישלב את הידע החדש הזה או שאלה רלוונטית, שמניחים אותו בהקשר בכרטיס פירוק התכונה הספציפית.
אנו גם מקנים לכל ההערות על ההשקה שלנו גישה קלה בכך שמכניסים אותן בקטע ה Upcoming או ה- Launched של לוח פירוק התכונה שלנו, שם ניתן לארגן אתן באופן פנימי. כך שהן קלות לעקיבה במבט אחד. אם אינך משתמש ב-Guru, אנו ממליצים לנסות ליצור דף הערות השקה, או יומן שינויים מקושר.
כמו בכל תהליך אחר, גם תהליך זה מתפתח כל הזמן. מסירת מוצרים והערות השקה אינן פשוטות כמו אחת ונגמר. כאשר הצרכים של העסק שלך משתנים, התהליך שלך, האחריות שלך ותבניותיך צריכות להשתנות יחד איתן. אבל בכך ששואפים להבנה קלה, הקשר ושימושיות, לא אפשרי להפסיד.
עובדה: התקשורת על השקת המוצר בעייתית
מטרת הערות השקת המוצר היא ליידע את הצוותים הפנימיים שלך (מהנדסה ועד תמיכת לקוחות) ואת בעלי העניין החיצוניים שלך (לקוחות ושותפים) שנעשו שינויים במוצר. בתחום הטכנולוגי, שבו הכל מתפתח במהירות האור, הספקת עדכוני מוצר באמצעות הערות השקה היא בעיה שכמעט נראית עתיקה.
כל חברה שבה עבדתי חוותה קושי בהעברת הערות השקה "נכונה". אבל זה קשה להשגה; החשיבות של כל שינוי או השקת מוצר משתנה בהתאם לקהל, איך השינוי משפיע על האינטראקציה של קבוצה מסוימת עם המאפיין, ואיך אותה קבוצה משתמשת במוצר הכללי יום יום.
התקשורות על השקת המוצר (המכונות בדרך כלל הערות השקה) חייבות להיות מועברות לקהלים שמעוניינים בדברים שונים. כמנהיג בחלופת הכנסות ב-Guru, המייצגים שלי הם כל מי שהיכולת שלו לעשות את עבודתו מופיעה כמושפעת מהתוכנית המוצרית, כולל:
צוותי המוצר/עיצוב/מהנדסה
צוות המכירות (תפעול מכירות, מכירות פנימיות, מנהלי חשבונות לפי סגמנטים)
חווית לקוח (מנהלי הצלחה ונציגי תמיכה)
צוות השיווק (שיווק מוצר, שיווק גידול, מותג, תוכן שיובילו את אסטרטגיית ה-GTM וכלי הפצה לעיתונות עבור המוצר)
פיתוח עסקי ושותפים
כל השותפים הללו חייבים לקלוט את עדכוני המוצר ולברר מיד באיזה מידה הם צריכים להחיל את העדכונים הללו על עבודתם. הם גם צריכים לשקול איך הם יכולים לעזור למשתמשים הסופיים להבין את ההשפעה של כל שינוי על הם.
האדם (או הצוות) שמבצע את התקשורת על השקה צריך לשקול את כל הקהלים שיגבושו את הידע המוצרי. מהן ההשלכות של השקה מהנדס הקצה לעומת לקוח פוטנציאלי בתעשיית הקמעונאות?
איך לא לגשת להערות השקה
בעוד שזה קשה לקחת בחשבון את הצרכים של קהלים שונים, זה הופך גם לפשוט לא תהליך המוגן עבור מנהל מוצר או מנהל שיווק מוצר (PMM) לכתוב חמישה גרסאות שונות של הערות פנימיות. מניסיוני, הערות השקה או ארוכות מדי וחסרות הקשר או שאין בהן מספיק תוכן טכני. הערות השקה סטטיות אינן מספקות לנו את התובנות הללו ולעיתים נכתבות עבור המחבר, ולא עבור האדם שצריך להבין מה השתנה. באמת, לרוב מדובר בהזדמנויות שהוחמצו.
ישבתי במשך שעה משואית בשיחות הערות השקה שבהן קול מונוטוני ממנהל המוצר מדבר על נקודות על שקפים. לאחר סיום השיחה, אותו מנהל מוצר מקבל מיילים, שיחות טלפון (זוכר את זה?), סלוקים וכו' מכולם מצוות תמיכת לקוחות ועד מכירות שרוצים לדעת מה משמעות השינויים עבורם, לקוחותיהם והפוטנציאליים שלהם. אם החמצת את השיחה, החמצת את הניואנסים וההקשר, ובמקום זאת קיבלת רק את יומן השינויים הגולמי.
אבל זה לא תפקידו של מנהל המוצר לעשות את התרגום הקדוש הזה; תפקידם לבנות מוצר שיפתור בעיה בשוק. זו העבודה של ה-PMM לתרגם את הכוונה כך שהשוק יבין מה הערך שלו.
הסוד לכתיבת הערות השקת תוכנה מצוינות
אני מעריץ גדול של צלילי המוזיקה (מזעזע, אני יודע) וזה מקצועי לתמיכה, הלקחים הנצחיים בסרט מתאימים לי. “בואו נתחיל מההתחלה/זה מקום מאוד טוב להתחיל”, עובר בראשי על בסיס שבועי. אז, בעיצוב או שינוי תהליך שתוצג מוצר, אתה חייב ללמוד את השפה לפני שתוכל להוראות מקצוע.
1. פיתוח מיני בלשון פנימית
השלב הראשון של חקירת התהליך הזה הוא לגרום לכל הצוות לדבר באותה שפה. שיתוף מונחים משותפים נראה מובן מאליו, אבל זה עשוי לא קורה בתוך הארגון שלך. אי ידיעת ראשי תיבות והבנה לא נכונה של השפה יכולה להיות מבודדת, ליצור בלבול ומחיצות בין הצוותים.
דוגמה: צוות השיווק שלנו משתמש במונח “השקה” כדי לתאר מתי ואיך אנו נלך לשוק עם תכונה. עם זאת, צוות ההנדסה משתמש במילה “השקה” כדי לתאר מתי תכונה הושקה לסביבת הבדיקה שלנו. ההשקה הספציפית לתכונה היא “גמורה” עבור ההנדסה לפני שלקוחותינו מודעים לכך. זו הייתה חלשה ומביאה למתיחות פנימית.
אף אחד לא רוצה להיות זה שידבר בפומבי מודה שהוא לא יודע מה משהו אומר, טיפשי, על ידי בקשת הגדרות. הפתרון שלנו: בקבוצת עבודה משותפת (עם ייצוג מההנדסה, מוצר, שיווק מוצר), נפרסנו את הניואנסים ותיעדנו ההגדרות שלנו לגבי השקת המוצר:
הערה: אם אחת מהכרטיסים לא מצליחים לטעון, פשוט רעננו את העמוד!
2. מה לכלול בהערות השקה שלך
לאחר שפה משותפת הוקמה וצוותך מסוגל לבטא את המונחים של ההשקה, תוכל לכתוב את ההערות שלך. הדבר הקל ביותר לעשות הוא ליצור תבנית ניתנת לשימוש מחדש לכתיבת הערות השקה. כך, בעלי העניין יקלטו את הפורמט לאחר כמה חזרות, ובכך מציל אותך מהצורך להמציא מחדש כל פעם.
לפחות, הערות השקה טובות כוללות:
תאריך/י התאריך של ההשקה
פנימיים וחיצוניים
תיאור המאפיין או הבאג
המוצר/ים המושפעים (אם יש לך יותר מאחד)
אם יש לך כמה מוצרים תוכנה, ייתכן שתרצה לכלול גם מספרי גרסה
איפה אפשר לשאול שאלות פנימיות
לעומת זאת, הערות השקה מצוינות כוללות גם:
שאלות נפוצות מצופות (שאלות נפוצות)
קישור לתיעוד ציבורי חדש, אם זמין
עבור תכונות:
שם המאפיין
תמונות מסך של איך המאפיין נראה
וידאו על איך להדגים את המאפיין
למה המאפיין קיים
איך זה משפיע על דמויות לקוחות/קונים רלוונטיות
הנה התבנית שאנחנו משתמשים בה פנימית (אל תהסס להעתיק!):
💡הערה: זה מועיל לקבוע אנשים ישירים אחראיים למשימה זו (במקום להשאיר את זה למאמצים קבוצתיים שאין להם בעלות). מנהל ההנדסה או מנהלי המוצר צריכים לשלוט בצד הטכני של ההערות (שם/גרסה/מוצר/תאריכים/תמונות מסך), בעוד שמנהלי השיווק מוצר או מהנדסי מכירות צריכים לשלוט במידע ההקשרי (דמויות לקוח/למה זה חשוב).
יישום אסטרטגיות תהליך מסירה של מוצר
צור פורמט תקשורת עקבית
עכשיו כשמאחד את המונחים וכתוב את התבנית שלך, השלב הבא הוא להסכים על אמצעי מסירה עקיב (כלומר: Slack, מייל, Loom, Guru, Google Docs) ושיטתיות. אמצעי מסירה עקבי מבטיח שלבעלי ההערות על ההשקה ידוע איפה הם צריכים ללכת או להסתכל או להירשם (כדי למשוך) כדי להיות מודע להשקה.
זה גם חיוני עבור ניהול השינויים מכיוון שאתה בדרך כלל צריך לומר למישהו משהו כמה פעמים כדי להבטיח שהם סופגים את זה לחלוטין. בהתאם לסוג ההשקה, השינויים ל-UI/UX (ממשק משתמש וחווית משתמש), וההשפעה על הלקוח, הקהל של ההערות על השקה שלך יידרש לדחוף ידע על המוצר (לדחוף). ב-Guru אנחנו משתמשים בשני שיטות דחיפה ומשיכה.
המשיכה: היכן למצוא ידע
בשבילנו, בעלי העניין יכולים לעקוב אחרי הערות השקה שלנו בערוץ Slack #release-notes, שם יש פורמט עקבי וקל לעיכול עבור כל דבר מתיקונים לבאגים ועד תכונות חדשות. שמור על כך שהקהל שלך לא רק צריך להיות מודע לכך שההוצאות מתבצעות (באמצעות המשיכה ב-Slack או מייל) אך יותר חשוב, הם צריכים לדעת למה ההשקה הזו חשובה בהקשר.
הידע שצריכת שינוי פשוט תתרחש או התרחשה אינו בעל ערך אלא אם כן הצוות שלך יכול לעשות איתו משהו. כדי לפתח פורמט עקבי שיספק הקשר מתאים, סקרתי אנשי מכירות, אנשי פיתוח חשבון, אנשים שעניינים עסקיים (העבודה), כדי לקבוע את התבנית שלנו למסירת מוצר שקרויה “כרטיס פירוק תכונה”, שתוכל למצוא לעיל.
כאשר מנהל הנדסה מתחיל לפתח תכונה חדשה, אנשים ישירים אחראיים מתודעים באמצעות Asana כדי ליצור את כרטיס פירוק התכונה הספציפי עם תבנית הערות השקה. כרטיס פירוק התכונה החדש הופך למערכת המקיפה, המקור האחד או "מוח התכונה" שאנחנו משיקים. מומחי נושא (SME) - כמו PMM ומהנדסי מכירות - כוללים פרטים על למה ההשקה בעלת ערך, למי זה הכי חשוב, ואיפה יש לכוון, הכוונה כיצד להציג את המאפיין כחלק מסיפור רחב יותר.
בעלי ההערות על ההשקה, במיוחד מנהלי החשבון, פונים שוב ושוב לאותם כרטיסים כי הם למדו שהידע הדינמי בכרטיס פירוק התכונה הוא מהימן, רלוונטי וניתן ליישם. כעת, הקהלים מדברים באותה שפה וקוראים מאותן (דינמיות) מחברות. חזרה לכרטיס פירוק התכונה היא עדיין חלק משיטת "משיכה" מכיוון שזה נעשה באופן עצמאי, ונעשה כדי להתכונן לשיחת מכירות או תמיכה, או אם לפוטנציאל יש שאלה על התוכנית.
הדחיפה: סיפוק ידע באופן פרואקטיבי
שיטת הדחיפה נכנסת לתמונה כאשר ידע על שחרור הוא רגיש בזמן, וחיוני לצוותים מסוימים. כאן, זה מושג באמצעות פונקציית ההודעות של Guru. בהתבסס על ההשפעה על הקהלים הפנימיים שלי, אני דוחף הודעה דרך Guru לקבוצת ממוקדת רלוונטית. אחר כך אני יכול לראות דוח על אלה שהAcknowledged או קראו את האזהרה ולהזכיר ציבורית לאלה שלא.
למה תרבות מונעת ידע היא המפתח 🗝
למרות כל מה שנאמר, זה לא ממש פשוט להסכים על ניהול מונחים, לכתוב הערות השקה מצוינות, וליצור מנגנון למסירה דינמית של המוצר. הצוותים חייבים להיות מסוגלים לשתף פעולה על הידע ולתת משוב על פני זמן. סיפוק משוב ושיפור ידע על ידי שיתוף אותו הוא חלק מהתפקידים והאחריות של כל מי בצוות.
בשבילנו, זה אומר שכאשר צרכני ידע (במקרה זה, בעלי ההערות על השקה) יש שאלה או לומדים משהו חדש, הם מגיבים על כרטיס פירוק התכונה. אנו גם משלבים שאלות שהוצגו ונענו בדרך סלוק כדי לשפר ידע בצורה מתמשכת. מומחה הנושא (בדרך כלל ה-PMM) יסקור וישלב את הידע החדש הזה או שאלה רלוונטית, שמניחים אותו בהקשר בכרטיס פירוק התכונה הספציפית.
אנו גם מקנים לכל ההערות על ההשקה שלנו גישה קלה בכך שמכניסים אותן בקטע ה Upcoming או ה- Launched של לוח פירוק התכונה שלנו, שם ניתן לארגן אתן באופן פנימי. כך שהן קלות לעקיבה במבט אחד. אם אינך משתמש ב-Guru, אנו ממליצים לנסות ליצור דף הערות השקה, או יומן שינויים מקושר.
כמו בכל תהליך אחר, גם תהליך זה מתפתח כל הזמן. מסירת מוצרים והערות השקה אינן פשוטות כמו אחת ונגמר. כאשר הצרכים של העסק שלך משתנים, התהליך שלך, האחריות שלך ותבניותיך צריכות להשתנות יחד איתן. אבל בכך ששואפים להבנה קלה, הקשר ושימושיות, לא אפשרי להפסיד.
חוויית הפלטפורמה של Guru מהלך ראשון – קח את סיור המוצר האינטראקטיבי שלנו
