
استخدم هذا القالب
إصدار ميزة رائعة ليس مجرد شحن كود - بل هو قيادة عملية التبنّي. باستخدام Trupeer، يمكنك توفير ساعات في التخطيط للإطلاق عبر البدء بقالب مجاني لإصدار الميزة، وتخصيصه باستخدام إرشادات العلامة التجارية الخاصة بك، وتحويل خطط الإطلاق إلى تحديثات فيديو تُوحّد الفرق خلف كل إصدار.
تسير إصدارات الميزات نحو التعثر وفق ترتيب يمكن التنبؤ به. ينتهي البناء متأخرًا، لذلك يتم تخطي موجز الدعم، ثم لا يتم تحديث دليل المساعدة، ثم تُكتب ملاحظات الإصدار بواسطة مهندس قبل النشر بـ عشرين دقيقة، ويتعلم الدعم ما تم شحنه من التذكرة الأولى.
لا شيء من ذلك مشكلة في البناء. إنها مشكلة تنسيق، ويتم حلها بعدّ تنازلي بدلًا من قائمة تحقق.
حمّل قوالب إصدار الميزة
التنسيق | الأفضل لـ |
|---|---|
Excel (.xlsx) | خطة الإصدار، متعقب النطاق، قائمة التحقق من جاهزية الإطلاق (go/no-go) وتقويم الإصدار |
Word (.docx) | ملاحظات الإصدار، موجز الدعم، والإعلان الداخلي |
PowerPoint (.pptx) | عرض مراجعة الإصدار ودعم المبيعات |
الخطة المعتمدة وموجزات قابلة للطباعة | |
Google Docs وSheets | تعاون مباشر خلال أسبوع الإصدار |
مجاني، قابل للتعديل، بدون علامة مائية.
كيفية تخصيص هذا القالب في Trupeer
الخطوة 1: افتح قسم القوالب
انتقل إلى قسم القوالب من التنقل الرئيسي.

الخطوة 2: اختر وافتح قالبًا
انقر على أي قالب تريد العمل عليه لفتحه.

الخطوة 3: وسّع عرض القالب
إذا لزم الأمر، وسّع عرض القالب لرؤية التخطيط الكامل والتفاصيل بوضوح.

الخطوة 4: عدّل القالب
انقر على Edit لبدء تعديل القالب المحدد.

داخل المحرر، يمكنك:
إضافة أقسام جديدة
تحديد أو تحديث قواعد التنسيق
إضافة شعار وضبط موضعه والإعدادات ذات الصلة
الخطوة 5: احفظ قالبك المخصص
بعد إجراء جميع التغييرات اللازمة، انقر على Save لتخزين القالب المحدّث كنسختك الخاصة.

الخطوة 6: المعاينة وضبط القالب بدقة
عندما تريد معرفة كيف يبدو قالبك المخصص، افتح Preview.

من شاشة المعاينة، يمكنك الاستمرار في إجراء تعديلات مباشرة عند الحاجة، لضمان ظهور القالب تمامًا كما تريد.
باستخدام قالب إصدار ميزة يمكنك:
توفير ساعات في التخطيط للإطلاق: تخطَّ الصفحة الفارغة مع بنية مصممة لإطلاق المنتجات.
مواءمة الفرق متعددة التخصصات: أقسام مدمجة للمنتج والتسويق والمبيعات والدعم.
الالتزام بهوية علامتك: طبّق شعارك وخطوطك وألوانك باستخدام Trupeer's brand kit.
تعزيز التبنّي: رسائل مدمجة وخانات تدريب تضمن أن العملاء يستخدمون الميزة فعليًا.
توحيد الإطلاقات: استخدم القالب نفسه لكل إصدار ميزة.
الوصول إلى فرق عالمية: ترجم مواد الإطلاق إلى 65+ لغة بنقرة واحدة.
ما الذي يحتاجه إصدار الميزة فعليًا
ستة مخرجات، خمسة جمهور. معظم الفرق تنتج اثنين.
المخرج | الجمهور | عادةً ما يتولاه | هل يتم تخطيه عند التأخر؟ |
|---|---|---|---|
خطة الإصدار | الهندسة والمنتج | مدير المنتج أو مدير الإصدار | لا |
قائمة التحقق من جاهزية الإطلاق (go/no-go) | صنّاع قرار الإصدار | مدير الإصدار | غالبًا، وهذه هي الخطيرة |
ملاحظات الإصدار | العملاء | تسويق المنتج أو المنتج | تُكتب بسرعة |
موجز الدعم | الدعم والنجاح | المنتج | تقريبًا دائمًا |
دليل المساعدة | عملاء يتعثرون | الكتابة التقنية أو الدعم | تقريبًا دائمًا |
ملاحظة المبيعات والدعم | المبيعات، عند الحاجة | تسويق المنتج | غالبًا |
الاثنان اللذان يتم تخطيهما هما اللذان يحددان كيف سيبدو الأسبوع التالي للإصدار. اجعلهما ضمن العدّ التنازلي بدل التعامل معهما كمتابعات.
العدّ التنازلي للإصدار
التواريخ بالنسبة ليوم الشحن. عدّل الفواصل حسب وتيرتك، لكن حافظ على الترتيب.
T-14: تجميد النطاق
ما الذي سيشمله هذا الإصدار يتم تحديده وكتابته. أي شيء يصل بعد هذه النقطة يدخل في الإصدار التالي ما لم يكن إصلاح عيب.
تضخم النطاق بعد التجميد هو السبب الأكثر شيوعًا لتأخر كل ما يليه. التجميد ليس بيروقراطية؛ بل هو ما يسمح بكتابة موجز الدعم والملاحظات والوثائق اعتمادًا على شيء ثابت.
المخرجات: خطة الإصدار، مع تأكيد النطاق وتعيين كل عنصر.
T-7: جاهزية داخلية
تمت صياغة الوثائق، وتمت صياغة ملاحظات الإصدار، وتمت كتابة موجز الدعم. غير منشور، تمت صياغته.
هذا هو الأسبوع الذي ينضغط عندما يتأخر البناء، والانضغاط هو ما يسبب مشكلة الدعم. إذا تأخر البناء، يتأخر تاريخ الإصدار معه. الشحن في الوقت مع عدم وجود موجز ليس شحنًا في الوقت.
المخرجات: مسودات الملاحظات، ومسودات مقالات المساعدة، وموجز الدعم جاهز للمراجعة.
T-2: تم إطلاع الدعم والمبيعات
يحدث الموجز كجلسة وليس كرسالة بريد إلكتروني. يطرح الدعم الأسئلة التي تكشف ما لم تشرحه الملاحظات، وتُحسّن تلك الأسئلة الملاحظات قبل أن يراها العملاء.
المخرجات: تم إطلاع الدعم، وتمت الإجابة عن أسئلتهم. تم تعديل الملاحظات. تم إرسال دعم المبيعات عند الحاجة.
T-1: go أو no-go
قرار محدد بمعايير محددة، يتخذه أشخاص محددون بالاسم. ليس شعورًا حول ما إذا كانت الأمور تبدو جاهزة.
المخرجات: قرار مُسجّل، وإذا كان no-go فموعد جديد.
T-0: الشحن
نشر، مراقبة، نشر الملاحظات، وتمكين إعلان داخل التطبيق. بالترتيب نفسه، لأن نشر ملاحظات لإصدار فشل في النشر هو نصف ساعة سيئة.
المخرجات: تم الإصدار، الملاحظات مباشرة، والدعم يراقب.
T+1: المراقبة
يتولى شخص ما المراقبة لأول يوم: معدلات الأخطاء، حجم الدعم حسب الموضوع، وتبنّي الميزة الجديدة. ليس الفريق كله يطلّ أحيانًا، بل شخص واحد محدد.
المخرجات: ملاحظة حالة قصيرة للفريق، حتى لو كان كل شيء على ما يرام.
T+7: المراجعة
ما الذي تم شحنه، وما الذي تعطل، وما الذي سمعه الدعم، وما إذا كان أي شخص يستخدمه. ثلاثون دقيقة، وهي ما يجعل الإصدار التالي أفضل.
المخرجات: ملاحظات من المراجعة، وأي تغييرات على العملية.
قالب خطة الإصدار
الحقل | أدخل |
|---|---|
اسم الإصدار والإصدار (version) | 2026.8 أو v3.4.0 |
نوع الإصدار | Major, minor, patch, hotfix |
تاريخ الاستهداف | وتاريخ التجميد |
مدير الإصدار | اسم واحد |
النطاق | كل عنصر، مع المالك والحالة |
خارج النطاق | بشكل صريح، متفق عليه عند التجميد |
الاعتمادات | داخلية وخارجية |
المخاطر | مع المالكين والتخفيف |
خطة التراجع (Rollback) | تم اختبارها، وليست مجرد موثقة |
معايير go/no-go | محددة قبل الاجتماع |
الاتصالات | من يُبلّغ ماذا ومتى |
الوثائق | ما الذي يحتاج كتابة أو تحديث، ومن |
مقاييس النجاح | هدف التبنّي ونافذة المراقبة |
حقل خارج النطاق يستحق مكانه. كتابة ما ليس ضمن هذا الإصدار هي الطريقة لإيقاف نفس المحادثة من تكرار نفسها ثلاث مرات.
معايير go وno-go
حدّد هذه الأمور في التخطيط، وليس في الاجتماع، وإلا سيتحول الاجتماع إلى تفاوض تحت الضغط.
معايير go النموذجية. اكتمال جميع عناصر النطاق أو تأجيلها بشكل صريح. اجتياز مجموعة الاختبارات. عدم وجود عيوب حرجة أو عالية الشدة مفتوحة. تم اختبار خطة التراجع في بيئة شبيهة بالإنتاج. تم إطلاع الدعم والتأكيد على جاهزيته. تم نشر الوثائق أو جاهزيتها للنشر. تم تأكيد المراقبة والتنبيهات ووضعها في مكانها. يوجد مالك محدد متاح لنافذة المراقبة.
no-go تلقائي. أي تراجع غير مُختبر. أي عيب حرج مفتوح. لم يتم إطلاع الدعم. مدير الإصدار غير متاح خلال الـ 24 ساعة القادمة.
خطة التراجع هي الأهم. التراجع المُوثق الذي لم ينفذه أحد هو مجرد فرضية. اختبره، وسجّل متى كانت آخر مرة فعلته فيها.
كتابة ملاحظات الإصدار
أربعة من صفحات هذا البحث تغطي ملاحظات الإصدار، وهذا يخبرك أنها أكثر مخرج يتعثر الناس فيه.
الخطأ الجوهري هو كتابتها من سجل التغييرات (changelog). قائمة التزام (commit) مُعاد تنظيمها إلى نقاط ليست ملاحظات إصدار، لأنها تصف ما الذي غيّرته بدلًا من ما الذي يمكن للقارئ فعله الآن.
ابدأ بما يمكنهم فعله الآن، وليس بما الذي أنشأته.
قسّم حسب نتيجة المستخدم، وليس حسب المكوّن أو الفريق.
اكتب بصيغة المخاطب. "يمكنك الآن التصدير إلى CSV" أفضل من "تم تنفيذ تصدير CSV".
اذكر السبب لأي شيء غير بديهي، في جملة واحدة.
ضمّن الإصلاحات، خصوصًا تلك التي أبلغ عنها العملاء. هذا يُغلق حلقة يتذكرونها.
كن صريحًا بشأن القيود. "يدعم حاليًا حتى 10,000 صف" يمنع تذكرة.
ضع رابطًا للتفاصيل. الملاحظات تُعلن؛ والوثائق تشرح.
اجعل كل إدخال جملتين إلى ثلاث جمل.
تخطَّ التغييرات الداخلية التي لا يمكن لأحد خارج الفريق إدراكها، إلا إذا أثرت على الأداء أو الأمان.
ضعيف وأفضل
ضعيف: تم تنفيذ وظيفة تصدير CSV لوحدة التقارير.
أفضل: يمكنك الآن تصدير أي تقرير بصيغة CSV. ابحث عن زر التصدير في أعلى يمين أي عرض تقرير. مقيد حاليًا بـ 50,000 صف لكل عملية تصدير.
ضعيف: تم إصلاح عدة أخطاء وتحسين الأداء.
أفضل: التقارير التي تحتوي على أكثر من 10,000 صف يتم تحميلها الآن خلال حوالي 3 ثوانٍ بدلًا من انتهاء المهلة. كما أصلحنا المشكلة التي أبلغ عنها بعضكم حيث تتم إعادة تعيين فلاتر التاريخ عند تغيير التبويبات.
ضعيف: تمت إضافة تفاصيل جديدة لصلاحيات المستخدم في لوحة الإدارة.
أفضل: يمكن للمسؤولين الآن منح شخص ما صلاحية الوصول إلى التقارير دون منحه صلاحية الوصول إلى الفوترة. حدّد ذلك لكل مستخدم ضمن Settings وTeam وPermissions. يحتفظ المستخدمون الحاليون بالصلاحيات التي لديهم الآن، لذلك لن يتغير شيء إلا إذا قمت بتغييره.
النمط: ما الذي يمكنك فعله، وأين يوجد، وما هي الحدود، وماذا يحدث للإعدادات الحالية. هذه النقطة الأخيرة تمنع معظم التذاكر المقلقة التي يولدها أي إصدار.
ما الذي يجب تضمينه في ملاحظات الإصدار
العنصر | دائمًا | الملاحظات |
|---|---|---|
الإصدار والتاريخ | نعم | الناس يرجعون إليها في تذاكر الدعم |
الميزات الجديدة | نعم | مجمعة حسب النتيجة |
التحسينات | نعم | فقط إذا كانت ملحوظة |
الإصلاحات | نعم | خصوصًا تلك التي أبلغ عنها العملاء |
التغييرات المسببة لكسر التوافق | نعم، بشكل بارز | في الأعلى، وليس مدفونًا |
الإيقاف التدريجي | نعم | مع تاريخ الإزالة |
المشكلات المعروفة | نعم | أفضل أن تأتي منك بدل أن يتم اكتشافها |
إجراء مطلوب | إذا وُجد | مُعلّم بوضوح في الأعلى |
روابط إلى الوثائق | نعم | لكل ميزة |
التغييرات المسببة لكسر التوافق والإجراءات المطلوبة تُوضع في الأعلى مع إبراز بصري. التغيير المسبب لكسر التوافق الذي يتم اكتشافه في منتصف قائمة التحسينات هو تغيير تم اكتشافه من قبل عميل غاضب.
موجز الدعم
أكثر مخرج يتم تخطيه، والأرخص في الإنتاج.
القسم | المحتويات |
|---|---|
ما الذي سيتم شحنه | لغة بسيطة، فقرة واحدة |
من يتأثر | أي العملاء، أي الخطط، أي المناطق |
ما الذي سيتغير لهم | بشكل ملموس |
أي شيء يجب عليهم فعله | الهجرة، إعادة التهيئة، إعادة الموافقة |
أسئلة محتملة | مع الإجابات مكتوبة |
ما الذي قد يحدث خطأ | وما الذي يجب قوله إذا حدث |
القيود المعروفة | حتى لا يَعِد الدعم بما لا وجود له |
إلى أين يتم التصعيد | شخص محدد لأسبوع الإصدار |
روابط الوثائق | أي شيء سيرسله الدعم للعملاء |
قدّمه كجلسة قبل يومين. الأسئلة التي يطرحها الدعم هي أفضل مراجعة مجانية ستحصل عليها ملاحظات الإصدار، لأن الدعم يعرف ما الذي يسأل عنه العملاء فعليًا، بينما المنتج غالبًا لا يعرف.
أنواع الإصدارات
النوع | يحتوي على | ملاحظات مطلوبة | الوتيرة المعتادة |
|---|---|---|---|
Major | تغييرات مكسرة، قدرات جديدة كبيرة | ملاحظات كاملة، دليل هجرة، تنبيه مسبق | نادرًا |
Minor | ميزات جديدة، متوافقة مع الإصدارات السابقة | ملاحظات كاملة | وتيرة منتظمة |
Patch | إصلاحات أخطاء فقط | ملاحظات مختصرة | حسب الحاجة |
Hotfix | إصلاح إنتاج عاجل | ملاحظة مختصرة، غالبًا بعد وقوع الأمر | استثنائي |
تتجاوز Hotfixes العدّ التنازلي بحكم التعريف، ولهذا تحتاج إلى عملية منفصلة خفيفة بدل افتراض أن العملية العادية سيتم اتباعها. وثّق ما هي عليه قبل أن تحتاجها.
الإصدارات الرئيسية تحتاج تنبيهًا مسبقًا، وليس مجرد ملاحظات في يوم الإصدار. أي شيء مسبب لكسر التوافق يجب الإعلان عنه قبل دورة إصدار واحدة على الأقل، والإيقافات التدريجية تحتاج تاريخ إزالة يُذكر عند الإعلان عنها وليس عند حدوثها.
رايات الميزات (Feature flags) والإطلاق المرحلي
إذا كان بإمكانك إصدار الميزة لنسبة من المستخدمين، فإن معظم المخاطر في هذه الصفحة تختفي.
أطلقها بشكل مظلم (dark)، ثم فعّلها للمستخدمين الداخليين، وبعدها مجموعة صغيرة، ثم تدريجيًا. راقب كل خطوة وارجع للخلف عبر الراية بدلًا من النشر. تصبح الراية آلية التراجع لديك، وهي أسرع وأقل إثارة للقلق من إعادة النشر.
هناك تخصصان يمنعان تحول الأمر إلى فوضى. كل راية تحتاج مالكًا وتاريخ إزالة، وإلا ستتراكم مئات الرايات ولن يعرف أحد أي المسارات تعمل. كما أن ملاحظات الإصدار يجب أن توضح من لديه الميزة، لأن "يمكنك الآن التصدير إلى CSV" مربك للـ 80% الذين لا يمكنهم ذلك بعد.
قياس الإصدار
التبنّي. نسبة المستخدمين المؤهلين الذين استخدموا الميزة في أول 7 و30 و90 يومًا. الرقم الذي يحدد ما إذا كان يستحق البناء.
حجم الدعم حسب الموضوع. يجب أن يرتفع ثم ينخفض. الثبات يعني أن الوثائق أو التصميم غير واضح.
معدل الأخطاء. مقارنة بخط أساس، خلال نافذة المراقبة.
معدل التراجع، عبر الإصدارات. ارتفاعه يعني أن معايير go مرنة أكثر من اللازم.
الوقت من التجميد إلى الشحن. التأخر بشكل متكرر يعني أن التجميد متأخر جدًا.
تفاعل ملاحظات الإصدار، حيث يمكنك قياسه. انخفاض القراءة يستحق معرفته قبل بذل المزيد من الجهد في تحسينها.
حدّد هدف التبنّي قبل الإصدار، ضمن الخطة. تعديل تعريف النجاح بعد رؤية الأرقام هو الطريقة التي تجعل الميزات تُعلن ناجحة بغض النظر.
كيفية تنفيذ إصدار ميزة
جمّد النطاق عند T-14 واكتب ما هو خارج النطاق.
اكتب مسودات الملاحظات والوثائق والموجز عند T-7، قبل اكتمال البناء.
قدّم موجزًا للدعم عند T-2 كجلسة، وعدّل الملاحظات بناءً على أسئلتهم.
اعقد go/no-go حقيقيًا عند T-1 مقابل معايير محددة مسبقًا.
اختبر التراجع قبل، وليس أثناء.
انشر، ثم انشر الملاحظات، بالترتيب نفسه.
عيّن شخصًا واحدًا لمراقبة الوضع لمدة 24 ساعة.
راجع عند T+7، ثلاثون دقيقة، بصدق.
تابع التبنّي بعد 7 و30 و90 يومًا مقابل الهدف في الخطة.
صلّح العملية، وليس فقط الميزة، عندما يحدث خطأ.
أفضل الممارسات
تم تجميد النطاق مع كتابة قائمة خارج النطاق.
تمت صياغة الوثائق والملاحظات قبل اكتمال البناء.
تم إطلاع الدعم في جلسة قبل يومين.
تم الاتفاق على معايير go قبل الاجتماع.
تم اختبار التراجع مع تسجيل التاريخ.
التغييرات المسببة لكسر التوافق في أعلى الملاحظات.
تمت كتابة الملاحظات بناءً على نتائج المستخدم، وليس سجل التغييرات.
مراقب واحد محدد لأول 24 ساعة.
تم تحديد هدف التبنّي قبل الإصدار.
مراجعة في كل مرة، حتى للإصدارات غير المثيرة.
الأخطاء الشائعة
تغيير النطاق بعد التجميد، مع ضغط كل ما يليه.
كتابة ملاحظات الإصدار من رسائل الالتزام (commit messages).
"إصلاحات أخطاء وتحسينات متنوعة" كإدخال.
تغييرات مكسرة مدفونة في منتصف قائمة.
تعلم الدعم عن الإصدار من عميل.
تم تحديث الوثائق بعد أسبوع.
go/no-go كإحساس بدلًا من معايير.
تم توثيق التراجع لكن لم يتم اختباره أبدًا.
تم نشر الملاحظات قبل تأكيد النشر.
لا أحد يراقب بعد الشحن.
رايات ميزات بدون مالك أو تاريخ إزالة.
إعلان النجاح دون تحديد هدف تبنّي مسبقًا.
لا توجد عملية Hotfix، لذلك تتجاوز الإصلاحات العاجلة كل شيء بما في ذلك المنطق.
شحن الوثائق مع الميزة، وليس بعدها
افتح القوالب في Trupeer AI، وطبّق brand kit الخاص بك بحيث تتطابق مواد الإصدار مع منتجك، وعدّل أي قسم مباشرة. الإعداد موجود في دليل القالب.
يتم تخطي الوثائق وموجز الدعم لنفس السبب في كل مرة: كتابتهما يستغرق ساعات لا يملكها أسبوع الإصدار، ووصف واجهة جديدة بالنص عمل بطيء وغير واضح.
سجّل الميزة مرة واحدة، بمجرد أن تصبح قابلة للاختبار، ويُنتج Trupeer AI مقالة المساعدة وجولة فيديو مع تعليق صوتي من نفس المرور. يمنحك ذلك الوثائق ومادة موجز الدعم ولقطة عرض لملاحظات الإصدار من تسجيل واحد تم إجراؤه عند T-7 بدلًا من ثلاث مهام لا يملك أحد وقتًا لها.
ترجمها إلى 65+ لغة حتى يحصل العملاء الدوليون على الإصدار في نفس الوقت مع الجميع، واحتفظ بالمجموعة في قاعدة المعرفة الخاصة بك حتى تكون موجودة عندما تصل أول تذكرة. استخدم التسجيل نفسه لـ تمكين الدعم.
سجّلها. اجعلها بعلامتك. ترجمها. اجعلها Trupeer.
الأسئلة الشائعة
هل يوجد قالب مجاني لإصدار الميزة في Word؟
نعم. نسخة Word تحتوي على قالب ملاحظات الإصدار وموجز الدعم والإعلان الداخلي، ما يعني أنها مستندات يكتب فيها الأشخاص بدلًا من تتبعها. تنزيل مجاني، بدون تسجيل، بدون علامة مائية.
هل يوجد قالب مجاني لإصدار الميزة في Excel؟
نعم، وExcel هو المكان الذي تعيش فيه خطة الإصدار: متعقب النطاق مع المالكين والحالة، قائمة التحقق من جاهزية الإطلاق (go/no-go)، الاعتمادات، المخاطر وتقويم الإصدار. إنه ملف العمل خلال أسبوع الإصدار.
هل يوجد قالب خطة إصدار في Excel؟
نعم، هذا هو ملف Excel الموجود في هذه الصفحة. يغطي النطاق وخارج النطاق والاعتمادات والمخاطر وخطة التراجع ومعايير go/no-go وخطة الاتصالات ومقاييس النجاح، مع تبويب لكل إصدار حتى تبني سجلًا.
هل يوجد قالب خطة إصدار برمجيات في Word؟
نعم. نسخة Word من خطة الإصدار مناسبة لخطة سردية لأصحاب المصلحة أو لعملية تغيير رسمية، بينما نسخة Excel مناسبة للتتبع. تستخدم معظم الفرق Excel لتنفيذها وWord لأي شيء يحتاج إلى اعتماد.
هل يمكنني تنزيل قالب مجاني لإصدار الميزة؟
نعم، كل تنسيق هو تنزيل مجاني بدون الحاجة إلى حساب وبدون إسناد.
هل يوجد قالب مجاني لإصدار الميزة في PDF؟
نعم، كونه خطة معتمدة وإصدارات قابلة للطباعة لقائمة التحقق من جاهزية الإطلاق (go/no-go) وموجز الدعم.
هل يوجد قالب مجاني لإصدار الميزة في PowerPoint؟
نعم. نسخة PowerPoint تغطي عرض مراجعة الإصدار وتمكين المبيعات، شريحة واحدة لكل ميزة مع ما تفعله، ولمن هي، وما الاعتراض الذي تعالجه.
ما هو أفضل قالب مجاني لإصدار الميزة؟
هو الذي يتضمن المخرجات التي يتخطاها الناس. خطة الإصدار سهلة العثور عليها وقالب ملاحظات الإصدار سهل كتابته. ما يحدد ما إذا كان أسبوع الإصدار سيجري بسلاسة هو موجز الدعم ومعايير go/no-go، ولهذا تم تضمين كليهما هنا بدلًا من تركهما كإضافة مفترضة.
ما هو قالب إصدار الميزة؟
مجموعة من المستندات لشحن ميزة: الخطة التي تغطي النطاق والتواريخ، وقائمة التحقق من جاهزية الإطلاق (go/no-go)، وملاحظات الإصدار للعملاء، وموجز الدعم، وتحديث الوثائق. التعامل معه كمستند واحد هو سبب تخطي المخرجات الداخلية.
ما الذي يجب أن تتضمنه ملاحظات الإصدار؟
الإصدار والتاريخ، والميزات الجديدة مجمعة حسب نتيجة المستخدم، والتحسينات الملحوظة، والإصلاحات بما فيها تلك التي أبلغ عنها العملاء، والتغييرات المسببة لكسر التوافق في الأعلى، والإيقافات التدريجية مع تواريخ الإزالة، والمشكلات المعروفة، وأي إجراء مطلوب، وروابط إلى الوثائق.
كيف تكتب ملاحظات إصدار جيدة؟
اكتب بناءً على ما يمكن للمستخدم فعله الآن بدلًا من سجل التغييرات. بصيغة المخاطب، مجمعة حسب النتيجة، جملتان إلى ثلاث جمل لكل إدخال، صريح بشأن القيود، ومحدد بشأن ما يحدث للإعدادات الحالية. ضع التغييرات المسببة لكسر التوافق والإجراءات المطلوبة في الأعلى حيث لا يمكن تفويتها.
ما الفرق بين خطة الإصدار وملاحظات الإصدار؟
خطة الإصدار داخلية وتطلعية: ما الذي سيتم شحنه ومتى ومن يتولاه وما هي آلية التراجع. ملاحظات الإصدار خارجية وتعود للخلف: ما الذي تغير وما يعنيه ذلك للعميل. تحتاج إلى الاثنين، وغالبًا ما يكتبها أشخاص مختلفون.
ما هي معايير go وno-go؟
هي الشروط التي يجب أن تكون صحيحة قبل أن يمضي الإصدار قدمًا، يتم الاتفاق عليها مسبقًا بحيث يكون القرار تحققًا وليس تفاوضًا. عادةً تكون جميع عناصر النطاق مكتملة أو مؤجلة، والاختبارات تمر، ولا توجد عيوب حرجة مفتوحة، وتم اختبار التراجع، وتم إطلاع الدعم، والوثائق جاهزة، والمراقبة في مكانها.
كم قبل الإصدار يجب إطلاع الدعم؟
قبل يومين، كجلسة وليس كرسالة بريد إلكتروني، وبعد صياغة ملاحظات الإصدار حتى يتمكن الدعم من طرح الأسئلة عليها. أسئلتهم هي أفضل مراجعة ستحصل عليها الملاحظات، لأنهم يعرفون ما الذي يسأل عنه العملاء فعليًا.
كيف تقيس إصدار الميزة؟
التبنّي بين المستخدمين المؤهلين بعد 7 و30 و90 يومًا مقابل هدف يتم تحديده قبل الإصدار، وحجم الدعم حسب الموضوع، ومعدل الأخطاء مقارنة بخط الأساس، وعبر الإصدارات معدل التراجع وما إذا كانت الفترة من التجميد إلى الشحن تتأخر.
ما الفرق بين إصدار رئيسي (major) وإصدار ثانوي (minor) وإصدار تصحيحي (patch)؟
يحتوي الإصدار الرئيسي على تغييرات مكسرة أو قدرات جديدة كبيرة ويحتاج تنبيهًا مسبقًا ودليل هجرة. يضيف الإصدار الثانوي ميزات مع الحفاظ على التوافق مع الإصدارات السابقة. الإصدار التصحيحي يصلح العيوب فقط. Hotfixes هي إصلاحات إنتاج عاجلة تتجاوز العدّ التنازلي المعتاد، ولهذا تحتاج إلى عملية خفيفة موثقة خاصة بها.
هل يمكنني تخصيص قالب إصدار الميزة هذا؟
نعم، جميع الإصدارات قابلة للتعديل بالكامل. عدّل فواصل العدّ التنازلي حسب وتيرتك، لأن دورة إصدار أسبوعية لا يمكنها استخدام تجميد لمدة أربعة عشر يومًا. ترتيب الخطوات أهم من التوقيتات المحددة. في Trupeer AI يمكنك أيضًا تطبيق brand kit الخاص بك بحيث تتطابق مواد الإصدار مع منتجك.