- काम उपलब्ध समय को भरने के लिए फैल जाता है, इसलिए बिना deadline वाले projects ज़रूरत से ज़्यादा लंबे हो जाते हैं और feature additions व scope creep के प्रति संवेदनशील होते हैं
- चुनौतीपूर्ण लेकिन असंभव नहीं deadlines टीम को scope·resources·time के संतुलन पर फिर से सोचने के लिए मजबूर करती हैं, जिससे वे अधिक स्पष्ट चुनाव कर पाती हैं
- deadline गुणवत्ता घटाने का साधन नहीं है; स्वस्थ माहौल में यह innovation और creativity को बाहर लाने वाली time limit की तरह काम कर सकती है
- requests और software projects, दोनों में अगर completion time को स्पष्ट रूप से प्रस्तावित किया जाए और negotiation के लिए खुला रखा जाए, तो response rate, execution speed, और संगठन का tempo और rhythm बेहतर होता है
- संगठन जितना बड़ा होता है, काम के फैलने की ताकत उतनी बढ़ती है, इसलिए साप्ताहिक planning·execution·sharing जैसे reporting rhythms तेज़ shipping में मदद करने वाले व्यावहारिक तंत्र बन जाते हैं
deadline न हो तो काम फैल जाता है
- Parkinson's Law कहता है कि “काम उसे पूरा करने के लिए उपलब्ध समय को भरने तक फैलता है”
- बिना deadline वाले projects वास्तव में जितना समय चाहिए उससे कहीं ज़्यादा समय ले सकते हैं
- अगर self-imposed deadline भी न हो, तो urgency गायब हो जाती है
- feature additions और scope creep होने की संभावना बढ़ जाती है
- असली बात यह नहीं है कि हर हाल में कम समय में काम ठूंस दिया जाए, बल्कि यह है कि project constraints को सचेत रूप से संभाला जाए
Iron Triangle के नज़रिए से deadline की भूमिका
- Iron Triangle project की तीन constraints को एक साथ देखने में मदद करता है
- scope: जो काम पूरा करना है
- resources: लोग और tools जो काम के लिए उपलब्ध हैं
- time: काम पूरा करने के लिए दिया गया समय
- एक तत्व बदलने पर बाकी पर भी असर पड़ता है
- ज़्यादा काम करना है तो ज़्यादा लोग या ज़्यादा समय चाहिए
- “good, fast, cheap” में से दो चुने जा सकते हैं, लेकिन तीनों एक साथ नहीं मिलते
- जब time constraint ढीली होती है, तो टीम project का scope बचे हुए समय को भरने की दिशा में बढ़ने लगता है
अच्छी और बुरी deadline में फर्क
- deadline के खिलाफ आम तर्क यह है कि “fake deadlines” खराब नतीजे देती हैं
- लेकिन समस्या अक्सर deadline नाम की विधि में नहीं, बल्कि उसके गलत इस्तेमाल में होती है
- स्वस्थ माहौल में चुनौतीपूर्ण timebox तय किया जाए, तो innovation और creativity निकलकर आ सकती है
- इसके उलट, toxic environment में असंभव timebox लगा दिया जाए, तो अनुमानित नकारात्मक परिणाम सामने आते हैं
- अच्छी deadline बाहरी accountability बनाती है और यह साफ़ करने में मदद करती है कि क्या शामिल होगा और क्या नहीं
communication में भी deadline काम करती है
- किसी से काम मांगते समय यह बेहतर है कि पहले एक स्पष्ट सुझाया गया समय बताया जाए कि कब तक काम पूरा होना अच्छा रहेगा
- प्रस्ताव स्पष्ट होना चाहिए, लेकिन negotiation के लिए खुला भी रहना चाहिए
- किसी survey को “कभी भी भर सकते हैं” कहकर भेजने और “कल तक भरना ज़रूरी है” कहकर भेजने में नतीजों का फर्क होता है
- deadline होने पर तेज़ और बेहतर response rate मिल सकती है
- बड़ी कंपनियों में यही फर्क एक साल तक दोहराया जाए तो बहुत बड़ा होकर जमा होता है
साप्ताहिक rhythm से execution बढ़ाना
- प्रभावी leadership के लिए स्पष्ट tempo और rhythm महत्वपूर्ण हैं
- जब deadline आरामदायक सीमा की किनारी पर होती है, तभी वास्तविक प्रगति पैदा हो सकती है
- उदाहरण के लिए, अगर prototype में एक महीना लगने का अनुमान है, तो टीम को यह चुनौती दी जा सकती है कि इस weekend तक क्या deliver किया जा सकता है
- लोग अक्सर एक हफ्ते में किया जा सकने वाला काम कम आंकते हैं
- कई teams, projects और tasks में साप्ताहिक reporting rhythm डाली जा सकती है
- टीम हर हफ्ते planning करती है और execution करती है
- progress को ऐसी जगह share किया जाता है जहाँ सभी देख सकें
- शुक्रवार दोपहर प्रगति को समेटकर share करने की आदत बनती है
- deadline, elegance, good intentions, और इस समझ के साथ कि लोग कैसे चलते हैं और अच्छा महसूस करते हुए काम करते हैं, इस्तेमाल की जाए तो एक शक्तिशाली tool बन जाती है
- संगठन जितना बड़ा होता है, उतना ही ज़्यादा उसे Parkinson's Law से लड़ना पड़ता है, और इसमें सफल होने पर दसियों हज़ार लोगों के संगठन में भी तेज़ shipping संभव होती है
1 टिप्पणियां
Hacker News की राय
नई नौकरी में कुछ हफ्तों बाद मेरे बॉस ने एक बार कहा था, “हमारे यहाँ काम की एक रफ्तार है, और तुम्हें भी उसी रफ्तार से चलना होगा… अगर leadership को लगे कि हम इससे कहीं ज़्यादा तेज़ डिलीवर कर सकते हैं, तो वे हमेशा वही उम्मीद करेंगे”
जब तक मैंने वह नौकरी छोड़ी, तब तक मैं सोमवार दोपहर के खाने से पहले ही हफ़्ते भर का काम खत्म कर देता था, और बाकी समय सिर्फ़ हाथ बना रहे इसलिए exploratory projects करता था। इसलिए मैंने Parkinson's Law को पूरी तरह विकृत रूप में काम करते भी देखा है
लेकिन गलत चीज़ को जल्दी ship करना, बस गलत चीज़ को ship करना ही है, और यह तब स्वाभाविक रूप से होता है जब आप ज़बरदस्ती निचोड़ने की कोशिश करते हैं। मैं अक्सर कहता हूँ, “जब आप 5 million dollar की समस्या को 1 million dollar में हल करना चाहते हैं, तो आप ऐसे बुरे फ़ैसले करने पर मजबूर हो जाते हैं जो असली समस्या हल ही नहीं करते, और आख़िर में ट्रेन को वापस मोड़कर पटरी फिर से बिछाने में 10 million dollar लग जाते हैं।” कई बार टीम जो “shortcut” चुनती है, वही असल में लंबा रास्ता बन जाता है, क्योंकि या तो वह requirements पूरी नहीं करता, या इतनी जल्दबाज़ी में चुना जाता है कि planning छूट जाती है और program और भी लंबा खिंचता है
मुख्य बात यह है कि लोग सुधार के लिए समय और resources को फिर से निवेश करने की अहमियत को ठीक से नहीं समझते। खाली समय विफलता नहीं है; यह उस समय की तैयारी का तरीका है जब intensity ज़्यादा होगी। कभी-कभी छोटे-मोटे कामों के लिए अतिरिक्त समय होना भी एक healthy स्थिति होती है
आजकल लोग optimization के विचार पर कुछ ज़्यादा ही अटके हुए लगते हैं, लेकिन जब समय हर पल किसी न किसी चीज़ से भरा रहता है, उससे पैदा होने वाली गंभीर समस्याओं को हम लगातार नज़रअंदाज़ कर रहे हैं
उनकी नज़र से देखें तो अगर वैसे भी उन्हें complex projects पर लंबे घंटे देने के लिए मजबूर किया जाना है, तो कम से कम वहाँ काम करना बेहतर है जहाँ पैसे ज़्यादा मिलें। आख़िर में कंपनी में वही लोग बचते हैं जो मेहनती तो होते हैं, लेकिन उतने सक्षम नहीं। एक healthy कंपनी में ऐसे लोगों का मिश्रण होना चाहिए जो कठिन लेकिन सीधे-सादे काम खुशी से कर लें, और ऐसे भी जो जलते हुए कूड़े के ढेर जैसे projects को बचाकर फिर पाँच कप coffee पी लें
Scotty: “असल में कितना समय लगेगा?”
Geordi La Forge: “एक घंटा!”
Scotty: “तुमने उन्हें सचमुच वही असली समय तो नहीं बता दिया?”
Geordi La Forge: “बिल्कुल वही बताया”
Scotty: “बेटा, अगर तुम चाहते हो कि लोग तुम्हें चमत्कार करने वाला इंसान समझें, तो तुम्हें अभी बहुत कुछ सीखना है”
इसे सलाह की तरह लेना अजीब है। अगर आप 50 dollar की समस्या को 5000 dollar में हल करना चाहें, तो लगभग 5000 dollar बर्बाद कर देंगे, और अगला project 7000 dollar का हो जाएगा
एक बड़े cloud provider में काम करते हुए मैंने इसे सीधे देखा है
शुरुआत में यह बात मुझे बहुत खलती थी कि हर काम में इतना समय क्यों लगता है। इससे पहले मैं ऐसे startup में था जहाँ समय और पैसे दोनों का दबाव था, सब कुछ तुरंत करना पड़ता था, और काम खत्म करने का स्पष्ट incentive होता था
उस cloud provider में ठीक उल्टा था। सब कुछ धीमा था। जो काम एक दिन में हो सकता था, उसमें एक हफ़्ता लगता था; जो एक हफ़्ते में हो सकता था, उसमें एक महीना लग जाता था। पहले मैं इसे इस तरह justify करता था कि यहाँ review process ज़्यादा है, details की checking ज़्यादा है
पीछे मुड़कर देखने पर लगा कि यह Parkinson's Law का domino effect था। कंपनी के पास इतना पैसा था कि वह सबको लगभग हमेशा के लिए salary दे सकती थी, इसलिए financial constraints गायब हो गए थे। time constraints को भी किसी न किसी explanation से टाला जा सकता था। इसलिए काम बस कभी-न-कभी पूरा हो जाता था। अगर आप किसी दूसरी team पर निर्भर हैं, तो वह team भी अपनी external accountability कभी-न-कभी पूरी करती थी, और इस वजह से मेरा काम भी धीमा पड़ जाता था
और बड़े संगठन इसका जवाब timeline बढ़ाकर देते हैं। directors या VPs खुद implementation नहीं कर सकते, इसलिए उनके पास और करने को कुछ नहीं होता, और बढ़ी हुई timeline फिर और ज़्यादा waste से भर जाती है
लगातार डटे रहने वाले और creative लोग अक्सर बस धक्का मारते हुए बड़ी companies को हरा देते हैं। हाल का उदाहरण Cursor AI है। Microsoft, Cursor बनाने के लिए लगभग आदर्श स्थिति में था। उसके अपने teams और OpenAI के ज़रिए सबसे ज़्यादा AI knowledge थी, AI computation के लिए विशाल data centers थे, और सबसे ज़्यादा इस्तेमाल होने वाला code editor Visual Studio Code भी था। फिर भी Cursor आया और उसने बेहतर product बनाया
Jeff Bezos ने कहा था, “your margin is my opportunity.” यही बात bureaucracy पर भी लागू होती है। जहाँ भी bureaucracy हो, आप सोच सकते हैं, “your bureaucracy is my opportunity”
उदाहरण के लिए, अगर आप किसी करीबी दोस्त के साथ कुछ कर रहे हों, तो आप हमेशा उम्मीद से ज़्यादा करेंगे, लेकिन किसी विशाल corporation के लिए वैसी परवाह पैदा ही नहीं होती
शुरुआती capitalism की आकर्षक efficiency decentralized और छोटे पैमाने की संरचनाओं से आई थी। किसी देश को ऊपर से नीचे तक पूरी तरह चलाया नहीं जा सकता; सबसे efficient तरीका यह है कि नीचे के लोग अपना काम खुद करें
लेकिन अब कुछ companies ज़्यादातर देशों से भी बड़ी हो गई हैं, और हम फिर उसी शुरुआती बिंदु पर लौट आए हैं। बस इस बार transparency और democratic regulation गायब हैं
हमें बड़े systems और complexity को संभालने का कोई बेहतर तरीका चाहिए
लेकिन “क्यों” के बारे में मेरा निष्कर्ष अलग था। law firms मूल रूप से risk-averse होती हैं। इसलिए details verify करने में समय लगता है, और यह समय या लागत से ज़्यादा महत्वपूर्ण माना जाता है
मैं इसे project management की तीन सीमाओं—quality, time, cost—के नज़रिए से देखता हूँ। law firm, और शायद वह cloud provider भी, quality को प्राथमिकता दे रहे थे। तब time या cost में से किसी एक को चोट लगती ही है
high quality + fast = expensive. high quality + low cost = slow
हर व्यक्ति अलग चीज़ों से motivate होता है। कोई दबाव से, कोई reward से, कोई problem solving से motivate होता है
समस्या यह है कि अगर किसी ऐसी strategy को, जो कुछ लोगों के लिए motivation बनती है, सब पर एकसाथ लागू कर दिया जाए, तो अलग तरह की motivation से चलने वाले लोगों की प्रेरणा कमज़ोर पड़ सकती है या उल्टा टूट भी सकती है
व्यक्तिगत रूप से मेरी motivation problem solving है, और यह काम करने वाले समाधान को release करने के अर्थ से बहुत मज़बूती से जुड़ी है। कृत्रिम deadlines, दिखावटी recognition events, और reward में rounding error जितना छोटा monetary compensation उल्टा उत्साह कम कर देता है। सब अलग हैं
लेकिन मैं इस लेख के उस आधार से भी सहमत हूँ कि deadlines मुझे आगे धकेल सकती हैं। व्यक्तिगत रूप से मुझे पसंद है कि deadlines project की value के अनुसार तय हों। वह value budget भी हो सकती है या कोई और external constraint भी
यह विचार मुझे सैद्धांतिक रूप से पसंद है। अनुभव के आधार पर भी यह एक अच्छी observation लगती है। लेकिन solution को लेकर मतभेद है
यह इस बात पर निर्भर कर सकता है कि आप आसपास के लोगों के मन को कैसे model करते हैं, लेकिन ऐसे लेखों में अक्सर solution को universal की तरह पेश किया जाता है। मेरे अनुभव में deadlines, खासकर self-imposed deadlines, कुछ लोगों के लिए, मान लें लगभग 40%, बहुत प्रभावी होती हैं, लेकिन यह कोई रामबाण नहीं है
Parkinson's law को समझाने वाला, और अलग-अलग लोगों पर काम करने वाले विभिन्न solutions सुझाने वाला कोई अधिक सामान्य सिद्धांत हो तो अच्छा होगा
“मुझे deadlines पसंद हैं। जब वे निकल जाती हैं तो जो
whooshजैसी आवाज़ आती है, वह मुझे पसंद है।” - Douglas Adamsमेरे लिए deadline हो या न हो, बहुत ज़्यादा फ़र्क नहीं पड़ता। क्योंकि मेरा दिमाग समय को उस तरह महत्वपूर्ण रूप में दर्ज ही नहीं करता
बेशक इसे manage करने की strategies हैं, और दवा भी कुछ हद तक मदद करती है। लेकिन अगर मैं खुद deadline तय करूँ, तो उसके निभने की संभावना नहीं है
deadline-setting ruling class तक कैसे पहुँचा जाता है, यह तो नहीं पता, लेकिन ईमानदार काम, बारीक ध्यान, और साबित किए जा सकने वाले परिणामों से तो यह निश्चित ही नहीं होता
मैं पूरी तरह आश्वस्त नहीं हूँ। सबसे बड़ी समस्या यह है कि अगर managers को सिखा दिया जाए कि “Parkinson's law वास्तविक है”, तो उनमें irrational deadlines तय करने की प्रवृत्ति पैदा हो जाती है, और उसका नुकसान सबको उठाना पड़ता है
बेशक “हमें ज़्यादा फ़र्क नहीं पड़ता, इसलिए 10 साल बाद भी release करो तो चलेगा” दूसरी तरफ़ का चरम है
यह बिल्कुल सच नहीं है कि developers को मूल रूप से अपने काम के release होने की परवाह नहीं होती। अगर परवाह नहीं है, तो वह deadline की कमी नहीं बल्कि company की समस्या है। अगर आप extreme deadlines लगा भी दें और developers को फिर भी परवाह न हो, तो वे deadline पूरी करने के लिए बस कचरा बना देंगे
management का काम अधीनस्थों को धोखा देकर उनसे ज़्यादा काम करवाना नहीं है। काम यह है कि employees सचमुच परवाह करें। जिन developers को मैं जानता हूँ, मुझे मिलाकर, वे कुछ भी release न करने या कचरा release करने की तुलना में customers को अच्छा product देने पर ज़्यादा खुश होते हैं
लेकिन अगर मुझे ऐसी स्थिति में डाल दिया जाए जहाँ मैं परवाह करना बंद कर दूँ और संबंध hostile हो जाएँ, तो मैं खुद को बचाने के लिए manager को manipulate करूँगा। मैं अपने mental health को optimize करूँगा, और उसमें नौकरी बचाए रखना और burnout से बचना भी शामिल है। managers को यह विचार पसंद नहीं आएगा, यह तय है, लेकिन अगर मूल लेख में कुछ जोड़ना हो तो वह होगा, “manager manipulation भी वास्तविक है, ज़रूरत पड़े तो इसका इस्तेमाल करो”
मेरे हिसाब से यह लेख deadlines के मामले में मूल बात चूक गया है
deadlines की मुख्य समस्या यह नहीं है कि “उन्हें ग़लत लागू किया जाता है”, बल्कि यह है कि वे आमतौर पर किसी और की priorities को दर्शाती हैं, और वे मेरी priorities से मेल नहीं खातीं
अगर deadlines मेरी सबसे efficient prioritization method से पूरी तरह मेल खातीं, तो वे काम कर सकती थीं, लेकिन उस स्थिति में शुरुआत से deadline की ज़रूरत ही नहीं होती। मैं आलस्य की बात नहीं कर रहा; Parkinson's law और inefficiency की चर्चा करते समय हम शुरू से good faith मानते हैं। जैसे ही आप deadline लाते हैं, आप मेरे work distribution को बदल देते हैं, और भले ही किसी खास workload को घटा दें, कुल मिलाकर work distribution की Shannon entropy बढ़ा देते हैं
उदाहरण के लिए मान लीजिए कि मेहमान 1 घंटे बाद आने वाले हैं। सफ़ाई में 45 मिनट लगते हैं, और खाना बनाने में 15 मिनट की तैयारी और 45 मिनट oven में baking चाहिए। मैं अपने तरीके से करूँ तो पहले खाना तैयार करूँगा, और baking के दौरान सफ़ाई करूँगा। तब deadline पूरी हो जाएगी
समस्या तब आती है जब मेरी पत्नी कहती है कि पहले घर साफ़ करो। बधाई हो। अब मेहमानों को खाने के लिए 45 मिनट इंतज़ार करना पड़ेगा
बाहर से थोपी गई ज़्यादातर deadlines भी यही असर पैदा करती हैं। वे “सफ़ाई” को बहुत जल्दी ख़त्म करवा देती हैं, लेकिन उसके ripple effects को पूरी तरह नज़रअंदाज़ करती हैं। आमतौर पर इसलिए कि उन्हें दूसरे कामों में दिलचस्पी ही नहीं होती। वे तभी ध्यान देते हैं जब पहले के ripple effects निपटाने के कारण अगली तय की हुई deadline छूट जाती है
विडंबना यह है कि इसी वजह से लोग दूसरों से और “तेज़” काम करवाने के लिए और भी तंग deadlines तय करते जाते हैं। जाहिर है, इससे ripple effects और बढ़ते हैं, और अंत में सब कुछ ठप हो जाता है
https://news.ycombinator.com/item?id=30000296
यह Parkinson's law की इस व्याख्या के उलट एक नज़रिया है, और मुझे लगता है कि मूल उद्धरण की मंशा की तुलना में मौजूदा व्याख्या अत्यधिक सरल बना दी गई है
परिभाषा के अनुसार, ज़्यादातर लोग, सही temporal order जैसे सभी confounding variables को adjust कर लेने के बाद भी, मेज़ पर बैठे बाकी सभी लोगों की असली priorities समझ नहीं सकते
हफ़्ते में एक बार होने वाली 30 मिनट की meeting में तो यह और भी असंभव है। क्योंकि सभी की intelligence मोटे तौर पर समान होती है
उदाहरण के लिए, 10 लोगों की committee में अगर chair सचमुच एक literal genius हो, और बाकी 9 सदस्य साधारण और आसानी से अनुमान लगाए जा सकने वाले हों, तो यह बहुत असाधारण स्थिति होगी। ऐसी ही स्थिति होनी चाहिए ताकि chair उन बाकी 9 लोगों में से हर एक के बारे में ठीक-ठीक अनुमान लगा सके कि कौन क्या करेगा
टालमटोल करने वाले व्यक्ति के रूप में मैं पक्का कह सकता हूँ कि इसका उल्टा कथन निश्चित रूप से सही नहीं है। काम बची हुई उपलब्ध समय-सीमा के हिसाब से छोटा नहीं हो जाता
इसलिए, जैसा यह लेख समर्थन करता है, मनमानी deadlines तय करना सबसे खराब विचार है। खासकर लंबे समय तक चलने वाले कामों में, यह टीम को death march की ओर धकेलता है और अंततः project collapse तक ले जाता है
मेरे लिए सबसे अच्छा तरीका यह है कि टीम छोटे increments परिभाषित करे, और उन increments को बनाते समय जो समस्याएँ आती हैं, उन्हें सदस्यों के साथ मिलकर debug किया जाए। इसके लिए deadline की ज़रूरत नहीं है; ज़रूरत है नज़दीकी involvement की, work flow पर फोकस की, और इस बात पर बार-बार चर्चा की कि अभी चल रहा सबसे हालिया काम अब भी मूल्यवान है या नहीं
काम के फैल जाने की समस्या का समाधान कम-मूल्य वाले काम को काट देना है। deadline तय करना सिर्फ़ गैर-समर्पित या अनुभवहीन managers के लिए आलसी जवाब है
दूसरी बात, आपने जो “छोटे increments” वाला approach बताया, वह हर शुक्रवार worker द्वारा status update देने के तरीके से काफ़ी अच्छी तरह मेल खाता है। क्योंकि शुक्रवार को रिपोर्ट करने लायक ठोस नतीजा होने के लिए, यह तय करना पड़ता है कि एक हफ़्ते में क्या हासिल किया जा सकता है
लेखक एक अहम बात छोड़ गया। यह तरीका काम करे, इसके लिए पहले सही environment होना ज़रूरी है
सहायक और स्वस्थ culture के बिना, कड़ी deadlines फ़ायदे से ज़्यादा नुकसान कर सकती हैं
सफल होने के लिए, गलतियों को सज़ा का कारण नहीं बल्कि सीखने का अवसर माना जाना चाहिए, लोगों को मशीन के पुर्ज़ों की तरह नहीं बल्कि सम्मानित और मूल्यवान महसूस होना चाहिए, और management को goals और decisions पारदर्शी रूप से साझा करने चाहिए ताकि trust बने और टीम की मेहनत एक साझा vision के साथ aligned रहे
उतना ही महत्वपूर्ण यह है कि कड़ी deadlines के लगातार दौर के बाद टीम को दबाव में लिए गए जल्दबाज़ फ़ैसलों को सुधारने, technical debt कम करने, और नए tools या technologies को explore करने का समय मिलना चाहिए ताकि क्षमता और मनोबल बढ़े
इस बुनियादी culture के बिना लेख के विचारों को लागू करना एक हानिकारक work environment बनाने का बड़ा जोखिम है
गलत environment में कड़ी deadlines अत्यधिक stress और burnout की ओर ले जा सकती हैं, जिससे प्रगति धीमी पड़ सकती है या लोगों के नौकरी छोड़ने की दर बढ़ सकती है। अगर लोग अपनी क्षमता को लेकर आश्वस्त न हों या गलती से डरते हों, तो decision paralysis पैदा हो सकता है, जिसे मैं “team freeze” कहता हूँ। जल्दी-जल्दी किए गए व्यक्तिगत योगदान एक संगठित whole में integrate नहीं हो पाते, जिससे collaboration बिखर सकता है। अगर management “ivory tower” में बैठकर ज़मीनी हक़ीक़त से कटी हुई मनमानी deadlines थोपे, तो priorities बिगड़ सकती हैं और अनिश्चितता बढ़ सकती है। सबसे बुरे हालात में, इससे वित्तीय अस्थिरता की अफ़वाहें भी फैल सकती हैं, जो टीम के फोकस को भटका दें। जो सदस्य खुद को अप्रशंसित महसूस करते हैं, उनके लिए अपेक्षा से अधिक करना या अपने अनोखे ideas देना मुश्किल हो जाता है, और उनकी व्यक्तिगत क्षमता भी दब जाती है
इसके अलावा, अगर deadlines बिना विराम के रोज़मर्रा की बात बन जाएँ, तो टीम अपनी गति और motivation खो देती है। लगातार sprint जैसी दबावपूर्ण स्थिति diminishing returns पैदा करती है, और अनसुलझी technical debt software में लंबे समय की पीड़ा के बिंदु छोड़ जाती है। समय बीतने के साथ टीम को लगने लगता है कि वह बिना बाहर निकलने के मौके के बस गड्ढा ही खोद रही है
इस thread में लगता है कि लोग दो अलग-अलग स्थितियों की बात कर रहे हैं। एक है high-pressure environment जहाँ पूरे साल वास्तविक ज़रूरत से 50% कम deadlines लगातार बनी रहती हैं, और दूसरी है वह स्थिति जहाँ analysis paralysis से बचने और काम को आगे बढ़ाने के लिए कोई व्यक्ति निजी चुनौती के रूप में अपनी इच्छित completion date तय करता है
दूसरा मामला ज़्यादा उस rally driver जैसा है जो फोकस बनाए रखने और आगे बढ़ते रहने के लिए लक्ष्य तय करता है
एक तरह से 5-day workweek भी एक deadline है। क्योंकि काम शुक्रवार तक पूरा करना होता है
यह “deadline” output को मजबूर करने वाला एक तंत्र है
लेकिन जानते हैं इससे भी बेहतर deadline क्या है?
4-day workweek
यह मज़ाक जैसा लग सकता है, लेकिन अगर कृत्रिम रूप से workweek छोटा कर दिया जाए, तो आप और तेज़ी से काम करते हैं
यही Parkinson's law के काम करने का तरीका है