FABLS
FABLS उघडा

SaaS

आपण दोन आठवड्यांनी रिलीज करता आणि वर्षात दोनदा त्याबद्दल लिहिता

सॉफ्टवेअर टीमांकडे बोलण्यासारख्या गोष्टींची कमतरता नसते. त्या बोलणाऱ्या व्यक्तीच्या कमतरतेत असतात, कारण रिलीज उशीर झाल्यावर लेखन हे नेहमी बाजूला सारले जाणारे काम असते — आणि ते प्रत्येक वेळी बाजूला सारले जाते, येथपर्यंत की ब्लॉगवरील शेवटची पोस्ट अकरा महिने जुनी असते आणि ती "सादर करत आहोत" अशी असते.

अपयश संरचनात्मक आहे, संपादनात्मक नाही

प्रत्येक टीमला माहीत असते की अधिक लिहिले पाहिजे. अभियंते लिहू शकतात; संस्थापक लिहू शकतात; कोणीतरी त्याचा आनंदही घेत असतो. अडचण अशी की लेखनाची स्वतःची कोणतीही अंतिम मुदत नसते, आणि अंतिम मुदत नसलेली कोणतीही गोष्ट अंतिम मुदत असलेल्या गोष्टीकडून प्रत्येक दोन आठवड्यांनी, कायमची हरते.

योजना गहाळ अंतिम मुदत पुरवते. विषय आणि लेखक जोडलेला तारखांकित स्लॉट ही शांत आठवड्यात केलेली बांधिलकी असते, जी शांत नसलेल्या आठवड्यात लागू होते, आणि कोणीही लक्षात ठेवले किंवा न ठेवला मसुदा तयार होतो. तो मंजूर करण्यास मिनिटे लागतात; तो सुरुवातीपासून लिहिण्यास कधीही येणारे नाही असे एक संध्याकाळचे दुपार लागते.

हाच संपूर्ण युक्तिवाद आहे. मॉडेल आपल्या टीमपेक्षा चांगले लिहिते असे नाही — होत नाही. तर मंगळवारी आपण संपादित करता तो मसुदा अस्तित्वात असतो, आणि आपण लिहिणार होता ती पोस्ट नसते.

रोडमॅप ही आपण आधीच लिहिलेली योजना असते

सहा महिन्यांतील बहुतांश भाग आधीच ठरलेला असतो. पुढील दोन तिमाहीत काय रिलीज होते याची अंदाजे कल्पना असते, उत्पादनाचे कोणते भाग चुकीच्या पद्धतीने समजले जातात, कोणत्या एकत्रीकरणांबद्दल वारंवार विचारले जाते, आणि समर्थनात दर आठवड्याला कोणते प्रश्न येतात हे सुद्धा.

त्यापैकी प्रत्येक गोष्ट एक विषय आहे. रोडमॅप लय पुरवते — एक रिलीज एका चेंजलॉग नोंदीऐवजी स्लॉट्सची मालिका बनते — आणि समर्थन कायमचा अर्धा भाग पुरवते, कारण महिन्यात वीस वेळा विचारला जाणारा प्रश्न म्हणजे एकदा लिहिलेला आणि कायम दुवा दिला जाणारा लेख आहे.

जागा सोडून द्या. रिलीज उशीर होतात, आणि रिकामी स्लॉट नसलेली योजना उशीर झालेल्या रिलीजला अजून अस्तित्वात नसलेल्या गोष्टीबद्दल तीन पोस्टींमध्ये बदलते. चतुर्थांश स्लॉट्स रिकामी ठेवणे हे ढिलाई नाही; ते योजनेचा आपल्या खऱ्या वेळापत्रकाशी टिकणारा भाग आहे.

मोसमीपणा आणि जागा कशा कार्य करतात →

एक रिलीज, तीन पोस्टीचित्र
  • 1ब्लॉगकाय रिलीज झाले आणि ते का अस्तित्वात आहे. आधी समस्या, मग वैशिष्ट्य.
  • 2फेसबुक / इंस्टाग्रामएका वाक्यातील आवृत्ती, चेंजलॉग कधीही उघडणाऱ्या नाहीत अशा लोकांसाठी.
  • 3ब्लॉगकोणी खरोखर ते कसे वापरले. ठोस, अवघड भाग तसेच ठेवून.
  • ·जर ते उशीर झालेस्लॉट रिलीझसोबत हलतात. अस्तित्वात नसलेल्या गोष्टीची घोषणा काहीही करत नाही.
  • 4ब्लॉगया रिलीझमध्ये शेवटी उत्तर मिळणारा सपोर्ट प्रश्न, एकदाच लिहिलेला.

रोडमॅप लय ठरवतोसपोर्ट विषय ठरवतो

तुमचा चेंजलॉग म्हणजे कंटेंट नाही. तो एक पावती आहे.

दोन लेखक, कधी कधी तीन

एक जो उत्पादनाचे स्पष्टीकरण देतो, आणि एक जो कंपनीबद्दल बोलतो

ते खरोखर वेगळे आवाज आहेत, आणि त्यांना एकत्र आणल्याने सॉफ्टवेअर ब्लॉग्सना प्रसिद्ध असलेला तो विशिष्ट निरसपणा येतो — तांत्रिक स्पष्टीकरणही नसलेला आणि माणुसकीचे वर्णनही नसलेला लेख.

तांत्रिक लेखक

एखादी गोष्ट काय करते हे विशेषणांशिवाय, अचूकपणे स्पष्ट करतो. तुमचे उत्पादन कशासाठी आहे आणि कशासाठी नाही हे जाणतो, आणि तसे म्हणण्यास त्याला परवानगी असते. सपोर्ट तिकिटांमधून ज्याच्या लेखांकडे दुवा दिला जातो, तो लेखक असा होतो.

कंपनीचा आवाज

निर्णय, तडजोडी आणि तुम्ही कशाकडे वाटचाल करत आहात याबद्दल लिहितो. मोजणे कठीण पण भरतीत, सेल्स कॉलमध्ये आणि कोणी मोठ्या विक्रेत्याऐवजी लहान विक्रेत्याला का निवडतो यात स्पष्ट दिसणारा उपयुक्तता त्याची असते.

उत्तर देणारा

तुमच्या धोरणानुसार टिप्पण्या हाताळतो. जे शक्य आहे त्याची उत्तरे देतो, जे शक्य नाही ते चिन्हांकित करतो, आणि रोडमॅपबद्दल कधीही अंदाज लावत नाही. सपोर्ट प्रकरणासारखे काहीही आढळल्यास ते लगेच माणसाकडे जाते.

मंजुरीचे गेट येथे खरोखर काम करते

बेकरीसाठी न मंजूर झालेला लेख ही छोटी गफलत असते. सॉफ्टवेअर कंपनीसाठी तो सपोर्टचा भार, सेल्समधील आक्षेप, किंवा कोणीही सहमत न झालेले वचन असतो. मर्यादेचे थोडे चुकीचे वर्णन करणारा मसुदा ग्राहक तुमच्यासमोर उधृत करेल, आणि तारीखेचा इशारा देणारा मसुदा वचन मानला जाईल.

म्हणून ही ती परिस्थिती आहे जिथे ऑटोपायलटला सर्वाधिक सावधगिरीची गरज आहे. योग्य व्यवस्था म्हणजे आधीच प्रकाशित झालेल्या गोष्टी पुन्हा सांगणाऱ्या लहान सोशल स्लॉटवर ऑटोपायलट, आणि उत्पादनाबद्दल दावा करणाऱ्या प्रत्येक गोष्टीवर मंजुरी. किंमत, क्षमता किंवा तारखांबद्दल काहीही कायमचे माणसाने वाचले पाहिजे, आणि ते लेखकाच्या नियमांत लिहून ठेवणे योग्य आहे, जेणेकरून असे मसुदे रांगेत न जाता धरले जाऊन चिन्हांकित होतील.

अहवाल लहान टीमला काय सांगतो

नियोजित विरुद्ध प्रकाशित हाच महत्त्वाचा आकडा आहे, आणि सॉफ्टवेअर टीमसाठी तो पहिल्या तिमाहीत बहुतेक वेळा अस्वस्थ करणारा असतो. लेखन पुन्हा रिलीझकडून हरले आहे का हे मोजण्याचा तो एकमेव प्रामाणिक मार्ग देखील आहे.

प्रतिसाद दिसतो तितका महत्त्वाचा नाही. तांत्रिक लेख दिवसांत नव्हे तर महिन्यांत आपले वाचक शोधतो, आणि दुसऱ्या आठवड्यात त्याचे मूल्यमापन केल्याने जे लेख चालणार होते तेच मागे टाकाल. सुरुवातीला विषयांचे संतुलन अधिक उपयुक्त आहे: ते दाखवते की तुम्ही फक्त प्रकाशित झालेल्या गोष्टींबद्दलच लिहित आहात का, जे प्रमाणित अपयशाचे स्वरूप आहे आणि इतके सॉफ्टवेअर ब्लॉग परिच्छेदांसह चेंजलॉगसारखे का वाचले जातात याचे कारण आहे.

प्रामाणिक भाग: तुमचे उत्पादन खरोखर तांत्रिक असल्यास, सर्वात खोल लेखांसाठी अजूनही एका इंजिनिअरचा एक दुपार लागते. नियोजन काय बदलते ते म्हणजे त्या दुपारी वेळापत्रकात बसवल्या जातात आणि लेखनाचा बाकीचा ऐंशी टक्के भाग त्यांच्याशी स्पर्धा करणे थांबवतो.