SaaS
आप हर दो हफ़्ते में रिलीज़ करते हैं और साल में दो बार उस पर लिखते हैं
सॉफ़्टवेयर टीमों के पास कहने को चीज़ों की कमी नहीं होती। कमी होती है उस व्यक्ति की जो उन्हें कहे, क्योंकि लिखना हमेशा वह काम होता है जिसे रिलीज़ देर से होने पर आगे धकेल दिया जाता है — और इसे हर बार धकेला जाता है, जब तक कि ब्लॉग की सबसे हालिया पोस्ट ग्यारह महीने पुरानी न हो जाए और उसमें "परिचय" लिखा न हो।
समस्या संरचनात्मक है, संपादकीय नहीं
हर टीम जानती है कि उसे अधिक लिखना चाहिए। इंजीनियर लिख सकते हैं; संस्थापक लिख सकता है; आमतौर पर कोई न कोई इसका आनंद भी लेता है। समस्या यह है कि लिखने की अपनी कोई समय-सीमा नहीं होती, और बिना समय-सीमा वाली हर चीज़ हर दो हफ़्ते, हमेशा, समय-सीमा वाली चीज़ से हार जाती है।
एक योजना वह ग़ायब समय-सीमा पूरी करती है। एक तारीख़ वाला स्लॉट, जिससे एक विषय और एक लेखक जुड़ा हो, एक शांत हफ़्ते में किया गया वादा है, जो एक अशांत हफ़्ते में लागू होता है, और ड्राफ़्ट तब भी आ जाता है चाहे किसी को याद हो या नहीं। उसे स्वीकृत करने में मिनट लगते हैं; उसे शून्य से लिखने में वह दोपहर लगती है जो कभी नहीं आती।
यही पूरा तर्क है। यह नहीं कि कोई मॉडल आपकी टीम से बेहतर लिखता है — नहीं लिखता। बात बस इतनी है कि मंगलवार को आपके द्वारा संपादित किया गया ड्राफ़्ट मौजूद होता है, और जो पोस्ट आप लिखना चाहते थे वह मौजूद नहीं होती।
रोडमैप एक योजना है जो आप पहले ही लिख चुके हैं
छह महीनों में से अधिकांश पहले से तय है। आपको लगभग पता है कि अगले दो तिमाहियों में क्या रिलीज़ होगा, उत्पाद के कौन से हिस्से ग़लत समझे जाते हैं, किन इंटीग्रेशन के लिए आपको बार-बार पूछा जाता है, और सपोर्ट में हर हफ़्ते कौन से सवाल आते हैं।
इनमें से हर एक एक विषय है। रोडमैप लय देता है — एक रिलीज़ एक चेंजलॉग प्रविष्टि के बजाय स्लॉट्स की एक श्रृंखला बन जाती है — और सपोर्ट सदाबहार आधा हिस्सा देता है, क्योंकि महीने में बीस बार पूछा गया सवाल एक ऐसा लेख है जिसे एक बार लिखकर हमेशा के लिए लिंक किया जा सकता है।
जगह छोड़ दें। रिलीज़ खिसकती हैं, और बिना खाली स्लॉट वाली योजना एक खिसकी हुई रिलीज़ को उस चीज़ के बारे में तीन पोस्ट बना देती है जो अभी मौजूद नहीं है। चौथाई स्लॉट खाली छोड़ना ढील नहीं है; यह योजना का वह हिस्सा है जो आपकी वास्तविक समय-सारिणी से टकराने पर भी बचा रहता है।
- 1ब्लॉगक्या रिलीज़ हुआ और वह क्यों मौजूद है। पहले समस्या, फिर फ़ीचर।
- 2Facebook / Instagramएक वाक्य वाला संस्करण, उन लोगों के लिए जो कभी चेंजलॉग नहीं खोलेंगे।
- 3ब्लॉगकिसी ने इसे वास्तव में कैसे इस्तेमाल किया। ठोस, अजीब हिस्सों को छोड़े बिना।
- ·अगर यह खिसक जाएस्लॉट रिलीज़ के साथ चलते हैं। जो कुछ मौजूद नहीं है, उसकी कोई घोषणा नहीं होती।
- 4ब्लॉगवह सपोर्ट प्रश्न जिसका उत्तर यह रिलीज़ आख़िरकार देती है, एक बार लिखा गया।
रोडमैप गति तय करता हैसपोर्ट विषय तय करता है
आपका चेंजलॉग कोई सामग्री नहीं है। यह एक रसीद है।
दो लेखक, कभी-कभी तीन
एक जो उत्पाद समझाता है, और एक जो कंपनी के बारे में बात करता है
ये वास्तव में अलग आवाज़ें हैं, और इन्हें मिलाने से वही विशेष नीरसता पैदा होती है जिसके लिए सॉफ़्टवेयर ब्लॉग जाने जाते हैं — एक ऐसी पोस्ट जो न तकनीकी व्याख्या है और न किसी चीज़ का मानवीय विवरण।
तकनीकी लेखक
बताता है कि कोई चीज़ क्या करती है, सटीक रूप से, बिना विशेषणों के। जानता है कि आपका उत्पाद किसके लिए है और किसके लिए नहीं, और ऐसा कहने की उसे अनुमति है। यही वह लेखक है जिसकी पोस्टें सपोर्ट टिकटों से लिंक की जाती हैं।
कंपनी की आवाज़
निर्णयों, समझौतों और आप किस ओर निर्माण कर रहे हैं, इस बारे में लिखता है। उपयोगी एक ऐसे तरीके से जिसे मापना कठिन है पर भर्ती में, सेल्स कॉल में और किसी के बड़े विक्रेता के बजाय छोटे विक्रेता को चुनने के कारण में स्पष्ट है।
उत्तर देने वाला
आपकी नीति के अंतर्गत आने वाली टिप्पणियों को संभालता है। जो संभव है उसका उत्तर देता है, जो संभव नहीं उसे चिह्नित करता है, और रोडमैप के बारे में कभी अनुमान नहीं लगाता। सपोर्ट घटना जैसी कोई भी चीज़ तुरंत किसी व्यक्ति के पास चली जाती है।
स्वीकृति द्वार यहाँ वास्तव में काम कर रहा है
एक बेकरी के लिए, बिना स्वीकृति की पोस्ट एक छोटी शर्मिंदगी है। एक सॉफ़्टवेयर कंपनी के लिए यह सपोर्ट भार है, सेल्स की आपत्ति है, या ऐसा वादा है जिससे किसी ने सहमति नहीं दी। एक मसौदा जो किसी सीमा को थोड़ा ग़लत बताता है, उसे ग्राहक आपके सामने उद्धृत करेगा, और एक मसौदा जो किसी तारीख़ का संकेत देता है, उसे वादा माना जाएगा।
इसलिए यह वह स्थिति है जहाँ ऑटोपायलट सबसे अधिक सावधानी का हक़दार है। एक उचित व्यवस्था यह है कि ऑटोपायलट उन छोटे सोशल स्लॉट पर रहे जो पहले से प्रकाशित किसी बात को दोहराते हैं, और स्वीकृति उन सब पर रहे जो उत्पाद के बारे में कोई दावा करते हैं। कीमत, क्षमता या तारीख़ों से जुड़ी हर चीज़ को स्थायी रूप से किसी व्यक्ति द्वारा पढ़ा जाना चाहिए, और यह लेखक के नियमों में लिख देना उचित है ताकि ऐसे मसौदे क़तार में लगने के बजाय रोके और चिह्नित किए जाएँ।
रिपोर्ट एक छोटी टीम को क्या बताती है
योजनाबद्ध बनाम प्रकाशित वह संख्या है जो मायने रखती है, और एक सॉफ़्टवेयर टीम के लिए यह पहली तिमाही में आमतौर पर असहज करती है। यही एकमात्र ईमानदार माप है यह जानने का कि क्या लेखन फिर से रिलीज़ से हारने लगा है।
प्रतिक्रिया उतनी मायने नहीं रखती जितनी दिखती है। एक तकनीकी लेख अपना दर्शक महीनों में पाता है, दिनों में नहीं, और दूसरे सप्ताह में उसका निर्णय लेना आपको वे लेख हटा देगा जो काम आने वाले थे। शुरुआत में विषय-संतुलन अधिक उपयोगी है: यह दिखाता है कि क्या आप केवल उसी के बारे में लिख रहे हैं जो जारी हुआ, जो मानक विफलता का ढंग है और इसी कारण इतने सॉफ़्टवेयर ब्लॉग अनुच्छेदों वाले चेंजलॉग जैसे लगते हैं।
ईमानदार बात: यदि आपका उत्पाद वास्तव में तकनीकी है, तो सबसे गहरे लेखों को अब भी एक इंजीनियर के एक दोपहर की ज़रूरत होती है। योजना जो बदलती है वह यह है कि वे दोपहरें समय-सारणीबद्ध हो जाती हैं और लेखन का बाक़ी अस्सी प्रतिशत उनसे प्रतिस्पर्धा करना बंद कर देता है।