الغرض من ملاحظات إصدار المنتج هو إبلاغ فرقك الداخلية (من الهندسة إلى دعم العملاء) وأصحاب المصلحة الخارجيين (العملاء والشركاء) بوجود تغييرات على المنتج. في مجال التكنولوجيا، حيث تتحرك كل الأشياء بسرعة الضوء، فإن تقديم تحديثات المنتج عبر ملاحظات الإصدار هو مشكلة عمرها عقود.
كل شركة عملت بها كانت تعاني من أجل جعل ملاحظات الإصدار "صحيحة". لكن من الصعب أن يكون الأمر صحيحًا؛ أهمية كل تغيير أو إطلاق منتج تختلف بناءً على الجمهور، وكيف يغير ذلك التغيير تفاعل مجموعة معينة مع الميزة، وكيف تستخدم تلك المجموعة المنتج بشكل يومي.
يجب تسليم هذه الاتصالات حول إصدار المنتج (المعروفة عادة بملاحظات الإصدار) للجماهير التي تهتم بأشياء مختلفة. بصفتي قائد تمكين الإيرادات في Guru، فإن الممثلين لدي هم أي شخص تتأثر قدرته على القيام بعمله بخريطة الطريق الخاصة بالمنتج، بما في ذلك:
فرق المنتج/design/الهندسة
فريق المبيعات (عمليات المبيعات، المبيعات الداخلية، ممثلو الحسابات على اختلاف القطاعات)
تجربة العملاء (مدراء النجاح وممثلو الدعم)
فريق التسويق (التسويق للمنتجات، تسويق النمو، العلامة التجارية، المحتوى الذين سيقودون استراتيجية الانتشار و التواصل مع الصحافة للمنتج)
تطوير الأعمال والشركاء
يجب على جميع هؤلاء الشركاء فهم تحديثات المنتج على الفور وتحديد إلى أي درجة يحتاجون إلى تطبيق تلك التحديثات على وظائفهم. يحتاجون أيضًا إلى أن يفكروا في كيفية مساعدتهم لمستخدمي النهاية على فهم تأثير أي تغيير سيترتب عليهم.
يجب على الشخص (أو الفريق) الذي يقوم بصياغة اتصالات الإصدار أن يأخذ جميع الجماهير بعين الاعتبار الذين سيتناولون معرفة المنتج. ما هي تداعيات الإصدار لمهندس خلفية ضد عميل محتمل في صناعة التجزئة؟
كيف لا تقترب من ملاحظات الإصدار
بينما من الصعب الأخذ في الاعتبار احتياجات الجماهير المختلفة، فإنه ببساطة ليس مقاسًا للجميع لمدير المنتج أو مدير تسويق المنتج (PMM) أن يكتب خمسة إصدارات مختلفة من ملاحظات الإصدار الداخلية. من خلال تجربتي، تكون ملاحظات الإصدار إما طويلة جدًا وخارجة عن السياق أو تفتقر إلى الخبرة التقنية الكافية. لا تعطي ملاحظات الإصدار الثابتة هذا الفهم وغالبًا ما تكتب للمؤلف، وليس للشخص الذي يحتاج إلى فهم ما حدث. بصراحة، عادةً ما تكون تلك فرص ضائعة.
جلست في اجتماعات أسبوعية لملاحظات الإصدار مدتها ساعة حيث يتحدث صوت رتيب من إدارة المنتجات عن نقاط رئيسية على الشرائح. بعد انتهاء الاتصال، يتلقى نفس مدير المنتج رسائل بريد إلكتروني ومكالمات هاتفية (تذكر تلك؟)، رسائل Slack، إلخ., من الجميع من دعم العملاء إلى المبيعات الذين يرغبون في معرفة ما تعنيه التغييرات بالنسبة لهم، لعملائهم، وللعملاء المحتملين. إذا فاتتك المكالمة، فقد فاتتك دقة وسياق، وبدلاً من ذلك حصلت على سجل التغييرات الخام.
لكن ليس من دور مدير المنتج القيام بهذا الترجمة المقدسة؛ وظيفتهم هي بناء منتج يحل مشكلة للسوق. إنه دور مدير التسويق للمنتج أن يترجم هذه النية بحيث يفهم السوق قيمتها.
السر في كتابة ملاحظات إصدار البرمجيات الرائعة
أنا معجب كبير بفيلم صوت الموسيقى (مفاجئ، أعلم) وكخبير تيسير، فإن الدروس الخالدة في الفيلم تظل صحيحة. “لنبدأ من البداية/إنها مكان جيد جدًا للبدء” يتردد في ذهني أسبوعيًا. لذلك، في تشكيل أو إعادة تشكيل عملية تسليم المنتج، يجب عليك تعلم اللغة قبل أن تتمكن من تدريس الموضوع.
1. تطوير معجم داخلي
الخطوة الأولى في الغوص في هذه العملية تعني جعل الفريق بالكامل يتحدث نفس اللغة. مشاركة المصطلحات الشائعة تبدو بديهية، لكنها قد لا تحدث عبر منظمتك. عدم معرفة الاختصارات وسوء فهم اللغة يمكن أن يكون منعزلًا، يخلق ارتباكًا وفجوات بين الفرق.
مثال: يستخدم فريق التسويق لدينا مصطلح “إطلاق” لوصف متى وكيف سنذهب إلى السوق بميزة. ومع ذلك، يستخدم فريق الهندسة كلمة “إطلاق” لوصف متى تم إطلاق ميزة في بيئة الحجز الخاصة بنا. الإطلاق الخاص بالميزة هو “منتهي” للهندسة قبل أن يعرف عملاؤنا عنها. كان هذا محيرًا ومتضاربًا داخليًا.
لا أحد يريد أن يكون الشخص الذي يتحدث علنًا معترفًا أنه لا يعرف ما يعنيه شيء ما بصيغة غبية من خلال السؤال عن التعريفات. حلي: في مجموعة عمل متعددة الوظائف (مع تمثيل من الهندسة، المنتج، تسويق المنتج)، نتناول الحل ونوثق تعريفات إصدار المنتج لدينا:
ملاحظة: إذا فشلت أي من البطاقات في تحميل، فقط قم بتحديث الصفحة!
2. ماذا تشمل في ملاحظات الإصدار الخاصة بك
بعد تأسيس لغة مشتركة وتمكن فريقك من التعبير عن مصطلحات الإصدار، يمكنك كتابة ملاحظاتك. أسهل شيء يمكن القيام به هو إنشاء قالب قابل لإعادة الاستخدام لكتابة ملاحظات الإصدار. بهذه الطريقة، يتعرف أصحاب المصلحة على النموذج بعد عدة تكرارات، ويوفر لك عناء الحاجة إلى إعادة اختراع العجلة في كل مرة.
على الأقل، تتضمن ملاحظات الإصدار الجيدة:
تاريخ/تاريخ الإصدار
داخلي وخارجي
وصف للميزة أو الخطأ
المنتج (أو المنتجات) المتأثرة (إذا كان لديك أكثر من واحد)
إذا كان لديك أكثر من منتج برمجي، قد ترغب أيضًا في تضمين أرقام الإصدار
حيث يمكن طرح الأسئلة داخليًا
ملاحظات الإصدار الرائعة، ومع ذلك، تشمل أيضًا:
الأسئلة الشائعة المتوقعة (FAQs)
رابط إلى وثائق جديدة عامة، إذا كانت متاحة
بالنسبة للميزات:
اسم الميزة
لقطات شاشة لما تبدو عليه الميزة
فيديو يظهر كيفية عرض الميزة
لماذا توجد الميزة
كيف تؤثر على شخصيات العملاء/المشترين المعنية
ها هي القالب الذي نستخدمه داخليًا (لا تتردد في نسخه!):
💡ملاحظة: من المفيد تعيين أفراد مسؤولين مباشرة عن هذه المهمة (بدلاً من تركها لمجهود جماعي حيث لا يمتلكها أحد). يجب على مديري الهندسة أو المنتج أن يمتلكوا الجانب التقني من الملاحظات (الاسم/الإصدار/المنتج/التواريخ/لقطات الشاشة)، بينما يجب على مديري تسويق المنتجات أو مهندسي المبيعات أن يمتلكوا المعلومات السياقية (شخصيات المشترين/لماذا تهم).
تنفيذ استراتيجية عملية تسليم المنتج
إنشاء تنسيق اتصال متسق
الآن بعد أن موحدت المصطلحات وكتبت قالبك، الخطوة التالية هي الاتفاق على وسيط تسليم متسق (أي: Slack، البريد الإلكتروني، Loom، Guru، مستندات جوجل) والطريقة. يضمن وسيط التسليم المتسق أن يعرف المعنيون بملاحظات الإصدار أين يجب عليهم الذهاب أو النظر أو الاشتراك (لتحقيق) ليكونوا على دراية بالإصدار.
هذا ضروري أيضًا لـإدارة التغيير لأنك عادةً ما تحتاج إلى إخبار شخص ما بشيء ما عدة مرات لضمان امتصاصه بالكامل. اعتمادًا على نوع الإصدار، والتغييرات في واجهة المستخدم/تجربة المستخدم، وتأثيرها على العميل، سيحتاج جمهور ملاحظات الإصدار إلى المعرفة حول المنتج ضغطًا (للضغط). في Guru، نستخدم كلا الطريقتين للدفع والسحب.
السحب: أين تجد المعرفة
بالنسبة لنا، يمكن لأصحاب المصلحة متابعة قناتنا في Slack #release-notes، حيث يوجد تنسيق متسق وسهل الفهم لكل شيء من إصلاحات الأخطاء إلى ميزات جديدة كليًا. تذكر أن جماهيرك المعنية لا تحتاج فقط إلى أن يكونوا على دراية بأن الإصدارات تحدث (عبر السحب في Slack أو البريد الإلكتروني) ولكن الأهم من ذلك، يحتاجون إلى معرفة لماذا تُعنى تلك الإصدار في السياق.
المعرفة بأن إصدارًا ما فقط سيحدث أو قد حدث ليست ذات قيمة إلا إذا كان فريقك قادرًا حقًا على القيام بشيء ما بها. من أجل تطوير تنسيق متسق يوفر السياق المناسب، استطلعت ممثلي المبيعات، ممثلي تطوير الحسابات، الأفراد في تطوير الأعمال (الكل)، لوضع قالبنا لتسليم المنتج الذي نسميه “بطاقة تحليل الميزة”، والتي يمكنك العثور عليها أعلاه.
عندما يبدأ مدير الهندسة في تطوير ميزة جديدة، يتم تنبيه الأفراد المسؤولين مباشرة عبر Asana لإنشاء بطاقة تحليل الميزة المحددة باستخدام قالب ملاحظات الإصدار. تتحول بطاقة تحليل الميزة الجديدة إلى مصدر موثوق واحد متين أو "عقل الميزة" التي نطلقها. يشمل الخبراء في الموضوع (SME) - مثل PMM وموظفي المبيعات - تفاصيل حول لماذا يعتبر الإصدار ذي قيمة، لمن يُعنى أكثر، وأينما كان ذلك قابلاً للتطبيق، إرشادات حول كيفية عرض الميزة كجزء من قصة أكبر.
يعود أصحاب الملاحظات على الإصدارات، لاسيما ممثلوا الحسابات، إلى نفس البطاقات مرارًا وتكرارًا لأنهم أدركوا أن المعرفة الديناميكية الموجودة في بطاقة تحليل الميزات موثوقة وذات صلة وقابلة للتطبيق. الآن، تتحدث الجماهير معًا وتقرأ من نفس (الكتاب الديناميكي). يعد العودة إلى بطاقة تحليل الميزة جزءًا من طريقة "السحب" لأنها تتم بوتيرة ذاتية، وتتم الاستعداد لمكالمة مبيعات أو دعم، أو إذا كان لدى أحد العملاء المحتملين سؤال حول خريطة الطريق.
الضغط: تقديم المعرفة بشكل استباقي
تدخل طريقة الدفع حينما تكون المعرفة حول إصدار ما حساسة للوقت، وحرجة لفرق معينة. يتم تحقيق ذلك من خلال وظيفة الإعلانات في Guru. استنادًا إلى التأثير على جماهيري الداخلية، أقوم بـدفع إعلان عبر Guru إلى مجموعة ذات صلة. يمكنني بعد ذلك رؤية تقرير عن أولئك الذين اعترفوا أو قرأوا التنبيه وفضح علنًا أولئك الذين لم يفعلوا.
لماذا تعتبر الثقافة المعتمدة على المعرفة هي المفتاح 🗝
على الرغم من كل ما سبق، فإنه ليس بالأمر البسيط حقًا أن نتفق على المصطلحات أو كتابة ملاحظات إصدار ممتازة أو إنشاء آلية لتسليم المنتج الديناميكي. يحتاج الفرق إلى القدرة على التعاون بشأن المعرفة وإعطاء تعليقات مع مرور الوقت. بالنسبة لنا، يعني ذلك أنه عندما يكون لمستهلكي المعرفة (في هذه الحالة، أصحاب الملاحظات) سؤال أو يتعلمون شيء جديد، فإنهم يعلقون على بطاقة تحليل الميزة.
بالنسبة لنا، يعني ذلك أنه عندما يكون لدى مستهلكي المعرفة (في هذه الحالة، أصحاب المصلحة في ملاحظات الإصدار) سؤال أو يتعلمون شيئًا جديدًا، فإنهم يعلقون على بطاقة تحليل الميزات. نحن ندمج أيضًا الأسئلة التي طرحت وأجابت في Slack من خلال التعليق كطريقة لتحسين المعرفة باستمرار. سيفحص خبير الموضوع (عادة PMM) ويقوم بإدخال هذه المعرفة الجديدة أو السؤال ذات الصلة، ويضعه في السياق في بطاقة تحليل الميزة المعينة.
نجعل جميع ملاحظات الإصدار لدينا سهلة الوصول عن طريق وضعها في قسم أو قسم "مقبل" أو "مطلق" من لوحة تحليل الميزات لدينا، حيث يمكن تنظيمها بشكل أفضل داخليًا. وبهذه الطريقة، تكون سهلة المتابعة بمجرد لمحة. إذا لم تكن تستخدم Guru، نوصي بمحاولة إنشاء صفحة لملاحظات الإصدار، أو سجل تغييرات مرتبط.
كما هو الحال مع أي عملية أخرى، فإن هذه العملية تتطور باستمرار. تسليم المنتج وملاحظات الإصدار ليست بالبساطة التي تظهر للوهلة الأولى. كلما تغيرت احتياجات عملك، يجب أن تتغير عملياتك ومسؤولياتك وقوالبك معها. لكن من خلال السعي نحو الفهم السهل والسياق وقابلية الاستخدام، لا يمكنك أن تفشل.
حقيقة: التواصل حول إصدار المنتج متعسر
الغرض من ملاحظات إصدار المنتج هو إبلاغ فرقك الداخلية (من الهندسة إلى دعم العملاء) وأصحاب المصلحة الخارجيين (العملاء والشركاء) بوجود تغييرات على المنتج. في مجال التكنولوجيا، حيث تتحرك كل الأشياء بسرعة الضوء، فإن تقديم تحديثات المنتج عبر ملاحظات الإصدار هو مشكلة عمرها عقود.
كل شركة عملت بها كانت تعاني من أجل جعل ملاحظات الإصدار "صحيحة". لكن من الصعب أن يكون الأمر صحيحًا؛ أهمية كل تغيير أو إطلاق منتج تختلف بناءً على الجمهور، وكيف يغير ذلك التغيير تفاعل مجموعة معينة مع الميزة، وكيف تستخدم تلك المجموعة المنتج بشكل يومي.
يجب تسليم هذه الاتصالات حول إصدار المنتج (المعروفة عادة بملاحظات الإصدار) للجماهير التي تهتم بأشياء مختلفة. بصفتي قائد تمكين الإيرادات في Guru، فإن الممثلين لدي هم أي شخص تتأثر قدرته على القيام بعمله بخريطة الطريق الخاصة بالمنتج، بما في ذلك:
فرق المنتج/design/الهندسة
فريق المبيعات (عمليات المبيعات، المبيعات الداخلية، ممثلو الحسابات على اختلاف القطاعات)
تجربة العملاء (مدراء النجاح وممثلو الدعم)
فريق التسويق (التسويق للمنتجات، تسويق النمو، العلامة التجارية، المحتوى الذين سيقودون استراتيجية الانتشار و التواصل مع الصحافة للمنتج)
تطوير الأعمال والشركاء
يجب على جميع هؤلاء الشركاء فهم تحديثات المنتج على الفور وتحديد إلى أي درجة يحتاجون إلى تطبيق تلك التحديثات على وظائفهم. يحتاجون أيضًا إلى أن يفكروا في كيفية مساعدتهم لمستخدمي النهاية على فهم تأثير أي تغيير سيترتب عليهم.
يجب على الشخص (أو الفريق) الذي يقوم بصياغة اتصالات الإصدار أن يأخذ جميع الجماهير بعين الاعتبار الذين سيتناولون معرفة المنتج. ما هي تداعيات الإصدار لمهندس خلفية ضد عميل محتمل في صناعة التجزئة؟
كيف لا تقترب من ملاحظات الإصدار
بينما من الصعب الأخذ في الاعتبار احتياجات الجماهير المختلفة، فإنه ببساطة ليس مقاسًا للجميع لمدير المنتج أو مدير تسويق المنتج (PMM) أن يكتب خمسة إصدارات مختلفة من ملاحظات الإصدار الداخلية. من خلال تجربتي، تكون ملاحظات الإصدار إما طويلة جدًا وخارجة عن السياق أو تفتقر إلى الخبرة التقنية الكافية. لا تعطي ملاحظات الإصدار الثابتة هذا الفهم وغالبًا ما تكتب للمؤلف، وليس للشخص الذي يحتاج إلى فهم ما حدث. بصراحة، عادةً ما تكون تلك فرص ضائعة.
جلست في اجتماعات أسبوعية لملاحظات الإصدار مدتها ساعة حيث يتحدث صوت رتيب من إدارة المنتجات عن نقاط رئيسية على الشرائح. بعد انتهاء الاتصال، يتلقى نفس مدير المنتج رسائل بريد إلكتروني ومكالمات هاتفية (تذكر تلك؟)، رسائل Slack، إلخ., من الجميع من دعم العملاء إلى المبيعات الذين يرغبون في معرفة ما تعنيه التغييرات بالنسبة لهم، لعملائهم، وللعملاء المحتملين. إذا فاتتك المكالمة، فقد فاتتك دقة وسياق، وبدلاً من ذلك حصلت على سجل التغييرات الخام.
لكن ليس من دور مدير المنتج القيام بهذا الترجمة المقدسة؛ وظيفتهم هي بناء منتج يحل مشكلة للسوق. إنه دور مدير التسويق للمنتج أن يترجم هذه النية بحيث يفهم السوق قيمتها.
السر في كتابة ملاحظات إصدار البرمجيات الرائعة
أنا معجب كبير بفيلم صوت الموسيقى (مفاجئ، أعلم) وكخبير تيسير، فإن الدروس الخالدة في الفيلم تظل صحيحة. “لنبدأ من البداية/إنها مكان جيد جدًا للبدء” يتردد في ذهني أسبوعيًا. لذلك، في تشكيل أو إعادة تشكيل عملية تسليم المنتج، يجب عليك تعلم اللغة قبل أن تتمكن من تدريس الموضوع.
1. تطوير معجم داخلي
الخطوة الأولى في الغوص في هذه العملية تعني جعل الفريق بالكامل يتحدث نفس اللغة. مشاركة المصطلحات الشائعة تبدو بديهية، لكنها قد لا تحدث عبر منظمتك. عدم معرفة الاختصارات وسوء فهم اللغة يمكن أن يكون منعزلًا، يخلق ارتباكًا وفجوات بين الفرق.
مثال: يستخدم فريق التسويق لدينا مصطلح “إطلاق” لوصف متى وكيف سنذهب إلى السوق بميزة. ومع ذلك، يستخدم فريق الهندسة كلمة “إطلاق” لوصف متى تم إطلاق ميزة في بيئة الحجز الخاصة بنا. الإطلاق الخاص بالميزة هو “منتهي” للهندسة قبل أن يعرف عملاؤنا عنها. كان هذا محيرًا ومتضاربًا داخليًا.
لا أحد يريد أن يكون الشخص الذي يتحدث علنًا معترفًا أنه لا يعرف ما يعنيه شيء ما بصيغة غبية من خلال السؤال عن التعريفات. حلي: في مجموعة عمل متعددة الوظائف (مع تمثيل من الهندسة، المنتج، تسويق المنتج)، نتناول الحل ونوثق تعريفات إصدار المنتج لدينا:
ملاحظة: إذا فشلت أي من البطاقات في تحميل، فقط قم بتحديث الصفحة!
2. ماذا تشمل في ملاحظات الإصدار الخاصة بك
بعد تأسيس لغة مشتركة وتمكن فريقك من التعبير عن مصطلحات الإصدار، يمكنك كتابة ملاحظاتك. أسهل شيء يمكن القيام به هو إنشاء قالب قابل لإعادة الاستخدام لكتابة ملاحظات الإصدار. بهذه الطريقة، يتعرف أصحاب المصلحة على النموذج بعد عدة تكرارات، ويوفر لك عناء الحاجة إلى إعادة اختراع العجلة في كل مرة.
على الأقل، تتضمن ملاحظات الإصدار الجيدة:
تاريخ/تاريخ الإصدار
داخلي وخارجي
وصف للميزة أو الخطأ
المنتج (أو المنتجات) المتأثرة (إذا كان لديك أكثر من واحد)
إذا كان لديك أكثر من منتج برمجي، قد ترغب أيضًا في تضمين أرقام الإصدار
حيث يمكن طرح الأسئلة داخليًا
ملاحظات الإصدار الرائعة، ومع ذلك، تشمل أيضًا:
الأسئلة الشائعة المتوقعة (FAQs)
رابط إلى وثائق جديدة عامة، إذا كانت متاحة
بالنسبة للميزات:
اسم الميزة
لقطات شاشة لما تبدو عليه الميزة
فيديو يظهر كيفية عرض الميزة
لماذا توجد الميزة
كيف تؤثر على شخصيات العملاء/المشترين المعنية
ها هي القالب الذي نستخدمه داخليًا (لا تتردد في نسخه!):
💡ملاحظة: من المفيد تعيين أفراد مسؤولين مباشرة عن هذه المهمة (بدلاً من تركها لمجهود جماعي حيث لا يمتلكها أحد). يجب على مديري الهندسة أو المنتج أن يمتلكوا الجانب التقني من الملاحظات (الاسم/الإصدار/المنتج/التواريخ/لقطات الشاشة)، بينما يجب على مديري تسويق المنتجات أو مهندسي المبيعات أن يمتلكوا المعلومات السياقية (شخصيات المشترين/لماذا تهم).
تنفيذ استراتيجية عملية تسليم المنتج
إنشاء تنسيق اتصال متسق
الآن بعد أن موحدت المصطلحات وكتبت قالبك، الخطوة التالية هي الاتفاق على وسيط تسليم متسق (أي: Slack، البريد الإلكتروني، Loom، Guru، مستندات جوجل) والطريقة. يضمن وسيط التسليم المتسق أن يعرف المعنيون بملاحظات الإصدار أين يجب عليهم الذهاب أو النظر أو الاشتراك (لتحقيق) ليكونوا على دراية بالإصدار.
هذا ضروري أيضًا لـإدارة التغيير لأنك عادةً ما تحتاج إلى إخبار شخص ما بشيء ما عدة مرات لضمان امتصاصه بالكامل. اعتمادًا على نوع الإصدار، والتغييرات في واجهة المستخدم/تجربة المستخدم، وتأثيرها على العميل، سيحتاج جمهور ملاحظات الإصدار إلى المعرفة حول المنتج ضغطًا (للضغط). في Guru، نستخدم كلا الطريقتين للدفع والسحب.
السحب: أين تجد المعرفة
بالنسبة لنا، يمكن لأصحاب المصلحة متابعة قناتنا في Slack #release-notes، حيث يوجد تنسيق متسق وسهل الفهم لكل شيء من إصلاحات الأخطاء إلى ميزات جديدة كليًا. تذكر أن جماهيرك المعنية لا تحتاج فقط إلى أن يكونوا على دراية بأن الإصدارات تحدث (عبر السحب في Slack أو البريد الإلكتروني) ولكن الأهم من ذلك، يحتاجون إلى معرفة لماذا تُعنى تلك الإصدار في السياق.
المعرفة بأن إصدارًا ما فقط سيحدث أو قد حدث ليست ذات قيمة إلا إذا كان فريقك قادرًا حقًا على القيام بشيء ما بها. من أجل تطوير تنسيق متسق يوفر السياق المناسب، استطلعت ممثلي المبيعات، ممثلي تطوير الحسابات، الأفراد في تطوير الأعمال (الكل)، لوضع قالبنا لتسليم المنتج الذي نسميه “بطاقة تحليل الميزة”، والتي يمكنك العثور عليها أعلاه.
عندما يبدأ مدير الهندسة في تطوير ميزة جديدة، يتم تنبيه الأفراد المسؤولين مباشرة عبر Asana لإنشاء بطاقة تحليل الميزة المحددة باستخدام قالب ملاحظات الإصدار. تتحول بطاقة تحليل الميزة الجديدة إلى مصدر موثوق واحد متين أو "عقل الميزة" التي نطلقها. يشمل الخبراء في الموضوع (SME) - مثل PMM وموظفي المبيعات - تفاصيل حول لماذا يعتبر الإصدار ذي قيمة، لمن يُعنى أكثر، وأينما كان ذلك قابلاً للتطبيق، إرشادات حول كيفية عرض الميزة كجزء من قصة أكبر.
يعود أصحاب الملاحظات على الإصدارات، لاسيما ممثلوا الحسابات، إلى نفس البطاقات مرارًا وتكرارًا لأنهم أدركوا أن المعرفة الديناميكية الموجودة في بطاقة تحليل الميزات موثوقة وذات صلة وقابلة للتطبيق. الآن، تتحدث الجماهير معًا وتقرأ من نفس (الكتاب الديناميكي). يعد العودة إلى بطاقة تحليل الميزة جزءًا من طريقة "السحب" لأنها تتم بوتيرة ذاتية، وتتم الاستعداد لمكالمة مبيعات أو دعم، أو إذا كان لدى أحد العملاء المحتملين سؤال حول خريطة الطريق.
الضغط: تقديم المعرفة بشكل استباقي
تدخل طريقة الدفع حينما تكون المعرفة حول إصدار ما حساسة للوقت، وحرجة لفرق معينة. يتم تحقيق ذلك من خلال وظيفة الإعلانات في Guru. استنادًا إلى التأثير على جماهيري الداخلية، أقوم بـدفع إعلان عبر Guru إلى مجموعة ذات صلة. يمكنني بعد ذلك رؤية تقرير عن أولئك الذين اعترفوا أو قرأوا التنبيه وفضح علنًا أولئك الذين لم يفعلوا.
لماذا تعتبر الثقافة المعتمدة على المعرفة هي المفتاح 🗝
على الرغم من كل ما سبق، فإنه ليس بالأمر البسيط حقًا أن نتفق على المصطلحات أو كتابة ملاحظات إصدار ممتازة أو إنشاء آلية لتسليم المنتج الديناميكي. يحتاج الفرق إلى القدرة على التعاون بشأن المعرفة وإعطاء تعليقات مع مرور الوقت. بالنسبة لنا، يعني ذلك أنه عندما يكون لمستهلكي المعرفة (في هذه الحالة، أصحاب الملاحظات) سؤال أو يتعلمون شيء جديد، فإنهم يعلقون على بطاقة تحليل الميزة.
بالنسبة لنا، يعني ذلك أنه عندما يكون لدى مستهلكي المعرفة (في هذه الحالة، أصحاب المصلحة في ملاحظات الإصدار) سؤال أو يتعلمون شيئًا جديدًا، فإنهم يعلقون على بطاقة تحليل الميزات. نحن ندمج أيضًا الأسئلة التي طرحت وأجابت في Slack من خلال التعليق كطريقة لتحسين المعرفة باستمرار. سيفحص خبير الموضوع (عادة PMM) ويقوم بإدخال هذه المعرفة الجديدة أو السؤال ذات الصلة، ويضعه في السياق في بطاقة تحليل الميزة المعينة.
نجعل جميع ملاحظات الإصدار لدينا سهلة الوصول عن طريق وضعها في قسم أو قسم "مقبل" أو "مطلق" من لوحة تحليل الميزات لدينا، حيث يمكن تنظيمها بشكل أفضل داخليًا. وبهذه الطريقة، تكون سهلة المتابعة بمجرد لمحة. إذا لم تكن تستخدم Guru، نوصي بمحاولة إنشاء صفحة لملاحظات الإصدار، أو سجل تغييرات مرتبط.
كما هو الحال مع أي عملية أخرى، فإن هذه العملية تتطور باستمرار. تسليم المنتج وملاحظات الإصدار ليست بالبساطة التي تظهر للوهلة الأولى. كلما تغيرت احتياجات عملك، يجب أن تتغير عملياتك ومسؤولياتك وقوالبك معها. لكن من خلال السعي نحو الفهم السهل والسياق وقابلية الاستخدام، لا يمكنك أن تفشل.
تجربة قوة منصة Guru بشكل مباشر - قم بجولة تفاعلية في المنتج
