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