FABLS
פתח את FABLS

SaaS

אתם משחררים כל שבועיים וכותבים על זה פעמיים בשנה

צוותי תוכנה לא חסרים דברים לומר. הם חסרים את האדם שאומר אותם, כי כתיבה היא תמיד המשימה שנדחית כשהשחרור מתעכב — והיא נדחית בכל פעם, עד שהפוסט האחרון בבלוג בן אחד־עשר חודשים ונפתח ב"מציגים".

הכשל מבני, לא עריכתי

כל צוות יודע שצריך לכתוב יותר. המהנדסים יודעים לכתוב; המייסד יודע לכתוב; בדרך כלל יש מישהו שנהנה מזה. הבעיה היא שלכתיבה אין דד־ליין משלה, וכל דבר בלי דד־ליין מפסיד לכל דבר עם כזה, כל שבועיים, תמיד.

תוכנית מספקת את הדד־ליין החסר. סלוט עם תאריך, נושא וכותב מצורפים הוא התחייבות שנעשתה בשבוע רגוע ומיושמת בשבוע שאינו רגוע, והטיוטה מופיעה בין אם מישהו זכר ובין אם לא. אישור שלה לוקח דקות; כתיבה מאפס לוקחת אחר־צהריים שלעולם לא מגיעים.

זו כל הטענה. זה לא שמודל כותב טוב יותר מהצוות שלכם — הוא לא. זה שטיוטה שאתם עורכים ביום שלישי קיימת, ופוסט שהתכוונתם לכתוב לא.

מפת דרכים היא תוכנית שכבר כתבתם

רוב חצי השנה כבר הוחלט. אתם יודעים בערך מה ייצא ברבעונים הקרובים, אילו חלקים במוצר מובנים לא נכון, אילו אינטגרציות מבקשים מכם שוב ושוב, ואילו שאלות מגיעות לתמיכה כל שבוע.

כל אחד מאלה הוא נושא. מפת הדרכים מספקת את הקצב — שחרור הופך לרצף סלוטים ולא לרשומת יומן שינויים אחת — והתמיכה מספקת את החצי הנצחי, כי שאלה שנשאלת עשרים פעמים בחודש היא פיסה ששווה לכתוב פעם אחת ולקשר אליה לנצח.

השאירו רווחים. שחרורים מתעכבים, ותוכנית בלי סלוטים ריקים הופכת שחרור שהתעכב לשלושה פוסטים על דבר שעדיין לא קיים. רבע מהסלוטים שנשארים פתוחים זה לא פינוק; זה החלק בתוכנית ששורד מגע עם לוח הזמנים האמיתי שלכם.

איך עונתיות ורווחים עובדים →

שחרור אחד, שלושה פוסטיםאיור
  • 1בלוגמה יצא ולמה הוא קיים. קודם הבעיה, אחר כך היכולת.
  • 2פייסבוק / אינסטגרםהגרסה במשפט אחד, למי שלעולם לא יפתח יומן שינויים.
  • 3בלוגאיך מישהו באמת השתמש בזה. קונקרטי, עם החלקים המביכים נשארים בפנים.
  • ·אם זה מתעכבהמשבצות זזות עם המהדורה. שום דבר לא מכריז על דבר שלא קיים.
  • 4בלוגשאלת התמיכה שהמהדורה הזו סוף סוף עונה עליה, נכתבת פעם אחת.

מפת הדרכים קובעת את הקצבהתמיכה קובעת את הנושאים

היומן שלך הוא לא תוכן. הוא קבלה.

שני כותבים, לפעמים שלושה

זה שמסביר את המוצר, וזה שמדבר על החברה

אלה באמת שני קולות שונים, ומיזוג שלהם מייצר את השטיחות המוכרת של בלוגים של תוכנה — פוסט שהוא לא הסבר טכני ולא סיפור אנושי על שום דבר.

הכותב הטכני

מסביר מה דבר עושה, במדויק, בלי תארים. יודע למה המוצר שלך מיועד ולמה לא, ומותר לו לומר את זה. זה הכותב שהפוסטים שלו מקושרים מפניות תמיכה.

הקול החברתי

כותב על החלטות, פשרות ולאן אתם בונים לכיוון. שימושי בדרך שקשה למדוד וברורה בגיוס, בשיחות מכירה ובסיבה שבגללה מישהו בוחר ספק קטן על פני גדול.

זה שעונה

מטפל בתגובות לפי המדיניות שלך. עונה על מה שהוא יכול, מסמן את מה שהוא לא יכול, ולעולם לא משוער לגבי מפת דרכים. כל דבר שנראה כמו תקרית תמיכה עובר מיד לאדם.

שער האישור עושה כאן עבודה אמיתית

למאפייה, פוסט לא מאושר זו מבוכה קטנה. לחברת תוכנה זו עומס תמיכה, התנגדות מכירה, או התחייבות שאף אחד לא הסכים לה. טיוטה שמתארת מגבלה בצורה שגויה במקצת תוחזר אליך על ידי לקוח, וטיוטה שמרמזת על תאריך תיחשב הבטחה.

לכן זה המקרה שבו אוטומט מצדיע את הזהירות הרבה ביותר. סידור סביר הוא אוטומט על משבצות הרשתות החברתיות הקצרות שחוזרות על משהו שכבר פורסם, ואישור על כל דבר שטוען טענה על המוצר. כל דבר על תמחור, קיבולת או תאריכים צריך להיקרא על ידי אדם באופן קבוע, וכדאי לכתוב את זה בכללי הכותב כדי שטיוטות מהסוג הזה ייעצרו וייסמנו ולא ייכנסו לתור.

מה הדוח מספר לצוות קטן

מתוכנן מול פורסם הוא המספר שחשוב, ולצוות תוכנה הוא בדרך כלל לא נעים ברבעון הראשון. זה גם המדד היחיד הכנה לשאלה אם הכתיבה הפסיקה שוב להפסיד למהדורה.

ההתקבלות חשובה פחות ממה שנדמה. פיסה טכנית מוצאת את הקהל שלה על פני חודשים, לא ימים, ושיפוט שלה בשבוע השני יגרום לך לגמור את הפיסות שהיו עומדות לעבוד. מאזן הנושאים שימושי יותר בהתחלה: הוא מראה אם אתה כותב רק על מה שיצא, שהוא מצב הכישלון הסטנדרטי והסיבה שכל כך הרבה בלוגים של תוכנה נקראים כמו יומן שינויים עם פסקאות.

החלק הכנה: אם המוצר שלך באמת טכני, הפיסות העמוקות ביותר עדיין צריכות מהנדס לאחר צהריים אחד. מה שתוכנית משנה הוא שהאחרי הצהריים האלה מתוזמנים, וששמונים האחוזים האחרים של הכתיבה מפסיקים להתחרות בהם.