FABLS
افتح FABLS

SaaS

بتطلق إصدار كل أسبوعين وبتكتب عنه مرتين في السنة

فرق السوفتوير مش ناقصها حاجة تتقال عنها. ناقصها الشخص اللي يقولها، لأن الكتابة دايمًا المهمة اللي بتتأجل لما الإصدار يتأخر — وبتتأجل كل مرة، لحد ما آخر بوست في البلوج يبقى عمره حداشر شهر وبيقول "نقدم لكم".

المشكلة هيكلية، مش تحريرية

كل فريق عارف إنه المفروض يكتب أكتر. المهندسين يقدروا يكتبوا؛ المؤسس يقدر يكتب؛ وفي حد عادةً بيستمتع بيها. المشكلة إن الكتابة ملهاش ديدلاين بتاعها، وأي حاجة من غير ديدلاين بتخسر قدام أي حاجة عندها ديدلاين، كل أسبوعين، للأبد.

الخطة بتوفر الديدلاين الناقص. خانة بتاريخ وليها موضوع وكاتب هي التزام اتعمل في أسبوع هادي، وبيتنفذ في أسبوع مش هادي، والمسودة بتظهر سواء حد فكر فيها أو لأ. الموافقة عليها بتاخد دقايق؛ كتابتها من الصفر بتاخد ظهيرة عمرك ما هتتوفر.

ده كامل الحجة. مش إن موديل بيكتب أحسن من فريقك — مش بيكتب أحسن. الموضوع إن مسودة هتعدلها يوم التلاتاء موجودة، والبوست اللي كنت ناوي تكتبه مش موجود.

خارطة الطريق دي خطة انت كتبتها خلاص

أغلب الست شهور متقررة خلاص. عارف تقريبًا إيه اللي هيطلع في الربعين الجايين، أنهي أجزاء من المنتج الناس فاهماها غلط، أنهي تكاملات الناس بتطلبها على طول، وأنهي أسئلة بتوصل للدعم كل أسبوع.

كل واحدة من دول موضوع. خارطة الطريق بتوفر الإيقاع — الإصدار الواحد بيبقى سلسلة خانات مش مدخل واحد في سجل التغييرات — والدعم بيدي النص الدايم، لأن سؤال بيتسأل عشرين مرة في الشهر يستاهل يتكتب مرة ويتلنك عليه للأبد.

سيب فضاوات. الإصدارات بتتأخر، والخطة اللي مافيهاش خانات فاضية بتخلي إصدار متأخر يبقى تلات بوستات عن حاجة لسه مش موجودة. ربع الخانات فاضية مش تقصير؛ ده الجزء من الخطة اللي بيعيش بعد ما يخبط في جدولك الحقيقي.

المواسم والفضاوات بيشتغلوا إزاي →

إصدار واحد، تلات بوستاترسم توضيحي
  • 1بلوجإيه اللي نزل وليه اتعمل أصلاً. المشكلة الأول، الميزة بعدها.
  • 2فيسبوك / إنستجرامالنسخة في جملة واحدة، للي عمرهم ما هيفتحوا changelog.
  • 3بلوجإزاي حد استخدمها فعلاً. بشكل ملموس، وبالأجزاء المزعجة زي ما هي.
  • ·لو اتأخرالمواعيد بتتحرك مع الإصدار. مفيش حاجة بتتعلن عن حاجة مش موجودة.
  • 4بلوجسؤال الدعم اللي الإصدار ده أخيراً بيجاوب عليه، مكتوب مرة واحدة.

خطة الطريق هي اللي بتحدد الإيقاعالدعم هو اللي بيحدد المواضيع

الـ changelog بتاعك مش محتوى. ده إيصال.

كاتبين، وساعات تلاتة

اللي بيشرح المنتج، واللي بيتكلم عن الشركة

دول أصوات مختلفة فعلاً، ودمجهم بيطلع النوع ده من الرطانة اللي مدونات السوفتوير معروفة بيها — بوست لا هو شرح تقني ولا هو حكاية إنسانية عن أي حاجة.

الكاتب التقني

بيشرح الحاجة بتاعة إيه، بدقة، ومن غير صفات. عارف منتجك مينفعش لإيه ومنفعش لإيه، ومسموح له يقول كده. ده الكاتب اللي بوستاته بتتنقل من تذاكر الدعم.

صوت الشركة

بيكتب عن القرارات، والمقايضات، وإنت بتبني ناحية إيه. مفيد بطريقة صعبة تتقاس وواضحة في التوظيف، وفي مكالمات البيع، وفي سبب اختيار أي حد مورّد صغير على كبير.

اللي بيجاوب

بيتعامل مع التعليقات تحت سياستك. بيجاوب اللي يقدر عليه، وبيعلّم على اللي مش قادر، وعمره ما بيخمن عن خطة الطريق. أي حاجة شبه حادثة دعم بتروح لإنسان على طول.

بوابة الموافقة هنا بتشتغل شغل حقيقي

بالنسبة لمخبز، بوست مش معتمد هو إحراج صغير. بالنسبة لشركة سوفتوير هو حمل دعم، أو اعتراض في البيع، أو وعد محدش وافق عليه. مسودة بتوصف حد بشكل غلط شوية، العميل هيرجّعهالك، ومسودة بتلمّح لتاريخ، هتتعامل كوعد.

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

التقرير بيقول إيه لفريق صغير

المخطط مقابل المنشور هو الرقم المهم، وللأفريق السوفتوير عادةً بيكون مزعج في الربع الأول. وهو كمان المقياس الوحيد الصادق لمعرفة الكتابة بقت بتخسر قدام الإصدار تاني ولا لأ.

الاستقبال أهم مما باين أقل. المقالة التقنية بتلاقي جمهورها على شهور، مش أيام، وتقييمها في الأسبوع التاني هيخليك تتخلى عن القطع اللي كانت هتنجح. توازن المواضيع أنفع بدري: بيوريك إنت بتكتب بس عن اللي اتنشر، ودي أشهر طريقة فشل وسبب إن مدونات السوفتوير كتير بتتقري زي changelog بفقرات.

الجزء الصادق: لو منتجك تقني فعلاً، أعمق القطع لسه محتاجة مهندس يوم بعد الظهر. اللي الخطة بتغيّره إن أيام الظهر دي بتتحدد مواعيدها، و80% التانية من الكتابة بتوقف عن التنافس معاها.