आप अपनी डेडलाइन के साथ किसे प्रभावित करने की कोशिश कर रहे हैं?

संकेत: जाहिर है कि आपके उपयोगकर्ता नहीं हैं।

अपना हाथ उन लोगों के लिए उठाएं जिनकी कंपनी ने "ग्राहक अभिविन्यास" को अपने कॉर्पोरेट मूल्यों में से एक के रूप में घोषित किया है। आप में से जो लोग इस ग्रन्थ को हैबे पर पढ़ते हैं और वे दर्शकों को नहीं देखते हैं: लगभग पूरे कमरे में एक हाथ बढ़ा है, पीछे से कुछ लोगों को छोड़कर।

वे ओरेकल में काम करते हैं।

ग्राहक संतुष्टि ओरेकल के कॉर्पोरेट मूल्यों में से एक है। लेकिन कॉर्पोरेट मूल्य - वे एक जिम सदस्यता की तरह हैं - यह सिर्फ उनके पास करने के लिए पर्याप्त नहीं है।

ग्राहक जुनून एक उपयोगी चीज है, लेकिन एक और चीज है जो कई कंपनियों से जुड़ी हुई है वह है समय। डेडलाइन अच्छी है। "जब मैं समाप्त करूंगा तो यह तैयार हो जाएगा" एक ही एप्लिकेशन पर काम करने वाले दो लोगों के लिए एक महान (या यहां तक ​​कि अनुशंसित) रणनीति हो सकती है। लेकिन जब आप एक कंपनी में दो सौ से अधिक कर्मचारियों के साथ काम करते हैं, तो आपको कुछ समझने की आवश्यकता है कि क्या हो रहा है; जब आपके उपयोगकर्ता आपके नए सीटी और फ़ार्ट्स का उपयोग करने में सक्षम होंगे, तो एक मोटा विचार।

मैं यह कहने की हिम्मत करता हूं कि हार्ड-सेट डेडलाइन खराब समय सीमा है, और यदि आपकी कंपनी ऐसी है, तो आपको संभवतः आगे भी जाना चाहिए और कॉर्पोरेट मूल्यों की सूची से "ग्राहक फ़ोकस" आइटम को हटा देना चाहिए। क्योंकि, यह विश्वास है या नहीं, उपयोगकर्ताओं को फिसड्डी स्प्रिंट के बारे में परवाह नहीं है।

मुख्य रूप से समय-सीमा ग्राहकों की नहीं, बल्कि प्रबंधन की होती है।

मुख्य लक्ष्य लक्ष्य है

या स्प्रिंट की आवश्यकता क्यों है, यह एक भयानक अभ्यास है

समय अच्छा है, वे तात्कालिकता की भावना पैदा करते हैं, अपनी प्रक्रियाओं की भविष्यवाणी सुनिश्चित करते हैं, और इसलिए आपको उनके पास होना चाहिए।

लेकिन अच्छी और बुरी शर्तें हैं। और ऐसी कंपनियां हैं जिनमें समय सीमा पत्थर में सेट की गई है, और जो बर्खास्तगी से एक कदम पर समय सीमा को भरते हैं। और तब समस्याएं शुरू होती हैं।

मैं एक विकास संस्कृति के बारे में बात कर रहा हूँ जिसमें यह स्प्रिंट के दौरान लक्ष्यों को स्थिर करने के लिए प्रथागत है: जब हर कोई बहुत शुरुआत में इकट्ठा होता है, तो वे कार्यों का मूल्यांकन करते हैं, निश्चित रूप से केवल फाइबोनैचि संख्याओं का उपयोग करते हैं, और इन बैठकों में जो भी निर्णय लिया जाएगा, यह सब पूरा होने से पहले होना चाहिए। स्प्रिंट - कुछ भी नहीं बदलता है और बर्दाश्त नहीं किया जाता है। सिद्धांत रूप में, यह भयानक लगता है, लेकिन मुझे लगता है कि इस तरह की रणनीति किसी भी परिदृश्य में खो रही है:

स्थिति ए। मान लीजिए कि एक डेवलपर पार्किंसंस कानून पर काबू पाता है और पहले से कार्य बंद कर देता है। इस मामले में, या तो डेवलपर अगली सुबह स्टैंड-अप पर इसकी रिपोर्ट नहीं करता है, क्योंकि हे, ठीक है, वह यह नहीं कह सकता कि उसके पास करने के लिए कुछ भी नहीं है। या उसका प्रबंधक उसे स्प्रिंट फ्रीज करके अधिक कार्य सौंपता है, क्योंकि अच्छी तरह से, उसके पास एक डेवलपर हो सकता है जो कुछ भी नहीं करता है, ठीक है, कुछ भी नहीं ।

स्थिति बी । डेवलपर, डेवलपर होने के नाते, अनुसूची के पीछे है। पर्यावरण को स्थापित करने में समस्याएं उम्मीद से अधिक समय लेती हैं, और उन्हें अब यकीन नहीं है कि उनके पास सप्ताह के अंत से पहले सब कुछ करने का समय होगा।

अगली बैठक में वह क्या रिपोर्ट करता है, जिस पर प्रोजेक्ट मैनेजर जवाब देता है: “ठीक है, मैंने तुम्हें सुना। लेकिन हमने एक प्रतिबद्धता बनाई, तो क्या आप समय पर सब कुछ पूरा करने की कोशिश कर सकते हैं? ” उसी समय, प्रबंधक का एक चित्र स्कैन करता है कि कैसे उसे विकास कंपनी के उपाध्यक्ष को साप्ताहिक सिंक-अप में रिलीज में देरी की व्याख्या करनी है, जो बदले में, उसे निर्देशात्मक सलाह "बस करो" देता है , इसलिए यह सिर्फ बेहतर है तनाव और करने की कोशिश करो।

इसलिए, एक डेवलपर होने के नाते, कुछ रातों के लिए, या शायद एक सप्ताहांत के लिए छोड़ देता है, और समय पर काम पूरा करता है। और उनके प्रबंधक अगली रैली में उनके प्रयासों की सराहना करते हैं । व्यापार कुछ।

या यह इतना चिकना नहीं है? समय सीमा पूरी हुई, और काम सफलतापूर्वक किया गया, लेकिन गलत मिसाल कायम हुई। उभरी हुई आँखों वाले एक हाल ही में काम करने वाले छात्र को संकेत मिला कि सप्ताहांत पर प्रसंस्करण सही है ।

और हमने समय सीमा पूरा न होने पर भी दुखद परिदृश्य पर चर्चा नहीं की, कार्य अगले स्प्रिंट में चला जाता है, और प्रबंधक को विकास के उपाध्यक्ष से पहले अपने अगले साप्ताहिक सिंक-अप में देरी का औचित्य साबित करना होगा और नैतिक सलाह सुनना होगा।

क्या आपको कोई समस्या दिखाई देती है? किसी भी समय किसी ने सवाल नहीं पूछा: "सुनो, अगर हम इसे अगले स्प्रिंट में स्थानांतरित करते हैं और किसी के लिए कोई बहाना नहीं बनाते हैं तो क्या होगा? यह उपयोगकर्ताओं को कैसे प्रभावित करेगा? ”

बहुत अधिक बार यह होना चाहिए, समय सीमा स्व-सम्मोहन है। और उनसे कैसे निपटें - भी।

आदर्श समाधान केवल इच्छुक पक्षों से बात करना होगा - उत्पाद टीम या बिक्री टीम, यह पता लगाने से कि अगर देरी से ग्राहक को नुकसान हो सकता है। और अगर यह मामला है, तो निश्चित रूप से अतिरिक्त घंटे आवंटित करें, और शायद सप्ताहांत पर काम करें। इस मामले में, युवा छात्र को एक संकेत प्राप्त होगा कि कंपनी वास्तव में अपने ग्राहकों के बारे में परवाह करती है, न कि अपने स्प्रिंट के बारे में।

ठंडी स्प्रिंट के साथ एक और समस्या है। मान लीजिए कि आपको एक ग्राहक से एक अनुरोध मिला-एक संभावित तुच्छ और कम प्राथमिकता वाले बग को ठीक करने के लिए। डेवलपर एक दिन में इसका सामना करेगा। लेकिन आप ^टीएम प्रक्रिया का पालन कर रहे हैं, जिसका अर्थ है कि कार्य आपकी टीम के बैकलॉग में जोड़ा गया है और शायद यह कुछ महीनों के बाद याद किया जाएगा। लेकिन आपने उपयोगकर्ता को खुश करने का अवसर खो दिया है! आप कुछ दिनों में इससे निपट सकते हैं, और उपयोगकर्ता को ईमेल के माध्यम से सूचित कर सकते हैं कि उसकी समस्या हल हो गई है। लोग ऐसे क्षणों को याद करते हैं, और यह ऐसी चीजें हैं जो उन्हें अपने दोस्तों को अपने उत्पाद की सलाह देते हैं।

प्रक्रियाओं के साथ बहुत दूर मत जाओ - क्योंकि उनकी वजह से आप अपने लक्ष्य को याद कर सकते हैं। ¹

मेरा यह भी मानना ​​है कि संचार संस्कृति के स्तर पर अधिक मूलभूत समस्याओं के परिणामस्वरूप, कंपनी में निहित पारस्परिक अविश्वास या किसी अन्य प्रतिबंधात्मक व्यवहार का संकेत है।

डेडलाइन क्यों भयानक हैं?

1. वे झूठी उम्मीदों का निर्माण करते हैं, जो आपके कॉर्पोरेट मूल्यों में लिखा गया है। क्योंकि आपके कॉर्पोरेट मूल्य आपके मूल्य नहीं हैं, आपके वास्तविक मूल्य अलिखित अपेक्षाएँ और पूर्वाग्रह (अच्छे और बुरे दोनों) हैं।
2. यदि आप कठोर परिस्थितियों में डालते हैं तो लोग कोने काट देंगे । कोई परीक्षण के लिए स्कोर करेगा, कोई दस्तावेज को अपडेट नहीं करेगा। आप रिलीज को समय पर भेजते हैं, लेकिन किस कीमत पर?
3. कोई भी नए समाधान की खोज में समय बिताने के लिए सहमत नहीं है, जबकि प्रबंधक समय पर पूरा किए गए कार्यों के लिए प्रार्थना करते हैं। हर कोई एमवीसी ढांचे पर फ्रंट-एंड लिखेगा जब तक कि फेसबुक पर किसी को कुछ समय सीमा के माध्यम से नहीं मिलता।

तो, समय सीमा के बिना काम करें?

बिल्कुल नहीं। समय सीमा निर्धारित करें, लेकिन उन्हें लचीला बनाएं। आपकी समय सीमा कितनी लचीली हो सकती है, यह आपका लक्ष्य है। यदि समय सीमा को पूरा करने में विफलता से एक मिलियन डॉलर का नुकसान हो सकता है, तो आपका लचीलापन शून्य होना चाहिए। लेकिन अगर यह एक और विशेषता है, तो पैंतरेबाज़ी के लिए हमेशा जगह है। आप आकाश में अपनी उंगली से फिबोनाची संख्याओं को खेलने के बजाय, तारीखों का अनुमान लगाने के लिए अधिक जटिल संभावित तरीकों के साथ प्रयोग कर सकते हैं। ²

लेकिन फ्रीज स्प्रिंट एक बहुत ही निर्णय है।

^1. 2016 में शेयरधारकों को लिखे एक पत्र में जेफ बेजोस ने इस विषय पर अच्छी बात की। उन्होंने सलाह दी कि "कंपनी के भीतर लोगों के बीच सामंजस्य का विरोध करें।"

^2. जोएल स्पोलस्की ने अपने लेख "एविडेंस बेस्ड शेड्यूलिंग" ( हैबे में अनुवाद ) में समय सीमा का अनुमान लगाने के लिए उन्नत तरीकों के बारे में बात की है।