हेनरिक निबरग द्वारा "हम समय की रिपोर्ट से कैसे छुटकारा पाएं" का अनुवाद

हम पूर्ण कार्य पर रिपोर्ट से कैसे छुटकारा पा सकते हैं?

समय की बर्बादी से छुटकारा पाने की कहानी

परिचय

क्या आपको कभी प्रगति रिपोर्ट के साथ काम करना पड़ा है? उन्हें भरें? उन्हें मंजूर है? उन्हें कार्यालय के चारों ओर ले?

क्या यह अच्छा करने के लिए समय बिताने जैसा था?



कथन १ : प्रगति रिपोर्ट कभी-कभी उपयोगी होती है।

कथन २ : लेकिन बहुत बार ऐसा कुछ भी नहीं होता है।

कहानी

एक बार एक सॉफ्टवेयर डेवलपमेंट कंपनी थी और मुझे विकास विभाग के प्रमुख की नौकरी मिल गई।

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



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



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



फिर, योजना और लेखा मॉड्यूल ने किसी अर्जित डेवलपर की मृत मृत्यु के बारे में कोई चेतावनी क्यों जारी नहीं की? यदि यह मॉड्यूल इतनी सरल और महत्वपूर्ण बात भी नहीं कर सकता है, तो यह क्या है? एक ट्रेंडी मॉनिटरिंग सिस्टम के साथ एक हवाई जहाज या एक परमाणु ऊर्जा संयंत्र की कल्पना करें जो सभी संभावित जानकारी दर्ज करता है, लेकिन कभी भी चेतावनी नहीं देता है जब कुछ स्पष्ट रूप से हो जाता है ...



सौभाग्य से, मैं इस चेतावनी के संकेत देख सकता था, और इसलिए, जब से मैं डेवलपर्स के साथ बैठा था (और मुझे खुशी थी कि मैंने कार्यालय में व्यक्तिगत कमरे से इनकार कर दिया था जो मुझे शुरुआत में पेश किया गया था)।



लंबे समय के लिए, थोड़े समय के लिए, लेकिन कुछ हफ्तों के बाद मुख्य समस्याएं पहले से ही कम या ज्यादा नियंत्रण में थीं, इसलिए मुझे काम पर रिपोर्ट मिल गई। उस समय तक, मुझे बहुत सी अलग-अलग रिपोर्टें करनी थीं, लेकिन इसके अलावा सभी कमियों के अलावा, एक फायदा यह था: अन्य बेकार प्रक्रियाओं के लिए कोई जगह नहीं थी।



काम पर रिपोर्टों ने न केवल मुझे परेशान किया, मैं उत्सुक था। हमें उनकी आवश्यकता क्यों है? वे कहाँ से आते हैं और फिर वे कहाँ जाते हैं? तो मैंने पूछना शुरू किया।



मेरे बॉस (सीईओ) ने कहा कि उन्हें बहीखाता की जरूरत है। लेखा ने कहा, उन्हें कार्मिक विभाग की आवश्यकता है। कार्मिक विभाग ने कहा कि उन्हें कंपनी की जरूरत है, जिसे हमने पेरोल आउटसोर्स किया है। और इसी तरह। यह मेरी पृष्ठभूमि परियोजना बन गई - जब मेरे पास थोड़ा समय था, मैंने "प्रगति रिपोर्ट के रहस्य" की अपनी जांच जारी रखी।



अंत में, मुझे पता चला कि कागजात के साथ क्या हो रहा था। हाथ से हाथ ट्रांसफर की एक श्रृंखला के बाद, उन्होंने उस आउटसोर्सिंग कंपनी में अपना जीवन समाप्त कर लिया, जहां प्रत्येक रिपोर्ट को मैन्युअल रूप से इलेक्ट्रॉनिक कर्मियों के लेखा प्रणाली में अंकित किया गया था।

हम्म ...







मड़ैया ...



ठीक है, अर्थात्, मेरा मतलब है कि सामान्य तौर पर यह बहुत प्रभावी नहीं है।



मेरे दिल में एक आईटी geek होने के नाते, मैंने तुरंत इस प्रक्रिया को सरल बनाने के बारे में सोचना शुरू कर दिया। इसलिए, प्रत्येक डेवलपर अपना काम ऑनलाइन भर सकता है, उनकी स्थानीय टीम लीड भी ऑनलाइन सभी रिपोर्टों को देखती है और उन्हें स्वीकृत करने के लिए ओके पर क्लिक करती है, फिर मैं उच्च-स्तरीय परिणामों को देखता हूं और उन्हें स्वीकार करने के लिए ओके भी क्लिक करता हूं और यह सब आउटसोर्सिंग कंपनी द्वारा स्वचालित रूप से भेजा जाता है। वाह, सब कुछ बहुत चिकनी है। हम्म, शायद इस सिस्टम को एक्लिप्स से कनेक्ट करें ताकि यह स्वचालित रूप से प्रदर्शन किए गए कार्य में समय लॉग करे, जिसके आधार पर कंप्यूटर पर विकास परियोजना खुली है? हो सकता है कि हम आउटसोर्सिंग कंपनी द्वारा इस्तेमाल किए गए कार्मिक लेखा प्रणाली के साथ सीधे एकीकृत कर सकते हैं? यह SOA पर अच्छी तरह से गिरने की संभावना है ...

एक पल रुकिए।



"प्रभावी ढंग से करने से ज्यादा बेकार कुछ भी नहीं है जो करने की आवश्यकता नहीं है।"

- पीटर ड्रकर



मैंने अपने आप को याद दिलाया कि मेरा प्रारंभिक प्रश्न प्रदर्शन किए गए कार्यों पर रिपोर्ट की प्रभावशीलता था, न कि उनके प्रदर्शन (दक्षता)।

• प्रदर्शन - इसके इनपुट के लिए सिस्टम के आउटपुट का अनुपात।
  
  उदाहरण: प्रति घंटे कोड की लाइनों की संख्या।
• क्षमता वांछित परिणामों का उत्पादन करने की क्षमता का गुण है।
  
  उदाहरण: प्रति रिलीज़ ROI।

मुझे अभी भी नहीं पता था कि पूर्ण कार्य पर रिपोर्टों का उपयोग क्यों किया गया था। मुझे जो उत्तर प्राप्त हुए, वे अक्सर "हम काम करते हैं, क्योंकि यह हमारा मानक है" (जो हमें टाइप करना चाहिए, क्योंकि हमें अवश्य करना चाहिए) टाइप के बारे में बेवकूफी थी। जो काम उन्होंने किए थे, उन खबरों के बारे में उन्होंने मुझे कुछ नहीं बताया, लेकिन मैं वास्तव में जानना चाहता था कि इन नंबरों की जरूरत क्यों थी।



इसलिए मैंने अलग तरह से सवाल पूछना शुरू किया। पूछने के बजाय "मुझे काम पूरा होने पर रिपोर्ट की आवश्यकता क्यों है", मैंने पूछना शुरू किया, "अगर हम" रिपोर्ट "खो देते हैं या" हम अनजाने में क्या करते हैं तो "क्या होता है?"



परिणामस्वरूप, रिपोर्टों का वास्तविक उद्देश्य सामने आया। प्रसंस्करण के लिए मुआवजे का भुगतान करने के लिए उनकी गणना करने के लिए मुख्य चीज का उपयोग किया गया था। अन्य लक्ष्य भी थे, लेकिन वे पहले से ही अन्य रिपोर्टों से आच्छादित थे। इसलिए एकमात्र महत्वपूर्ण लक्ष्य प्रसंस्करण के लिए सटीक गणना था। और, उन्हें स्वीडिश उद्योग की एक परंपरा "फ्लेक्स टाइम" की गणना करने की भी आवश्यकता थी, जो वास्तव में, लोगों को कभी-कभी काम करने की अनुमति देता है, अगर दूसरे दिन वे जल्दी पहुंचे। प्रगति रिपोर्टों का उपयोग यह पुष्टि करने के लिए किया गया था कि सब कुछ कम से कम 40 घंटे एक सप्ताह + एक्स, जहां एक्स ओवरटाइम होता है।



सत्य का मीठा स्वाद।



अब, सच्चाई से लैस, मैंने कई डेवलपर्स को इकट्ठा किया और उनसे एक बयानबाजी की - "क्या आप काम पर रिपोर्ट भरना चाहते हैं"? उनके चेहरों पर अभिव्यक्ति का जवाब था, जिसकी मुझे ज़रूरत थी:







फिर मैंने ऐसे ही जारी रखा:



“अब हम ओवरटाइम गिनने के लिए इन रिपोर्टों का उपयोग करते हैं। लेकिन रिपोर्ट भरना निराशाजनक है, और ओवरटाइम काम करना और भी निराशाजनक है। हम सभी जानते हैं कि ज़ोंबी कोडिंग के पूरे सप्ताह की तुलना में ऊर्जावान, प्रेरित, केंद्रित विकास का एक घंटा अधिक फायदेमंद है। ”



(ऑफहैंड, मुझे एक भी विशिष्ट लिंक याद नहीं है, ठीक है, मैं पहले से ही अध्ययन का ट्रैक खो चुका हूं जो बताता है कि कार्य सप्ताह की अवधि और उत्पादित मूल्य के बीच का संबंध छोटा है या नहीं, कम से कम जब यह सॉफ्टवेयर विकास जैसे रचनात्मक कार्य के लिए आता है। प्रेरणा महत्वपूर्ण है। और ध्यान केंद्रित, घंटे नहीं)।



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



“बेशक, कभी-कभी अपवाद भी हो सकते हैं। ऐसे मामलों में, पारंपरिक प्रसंस्करण मुआवजा प्रणाली काम करेगी। हम ऐसे मामलों को कम करने और प्रत्येक व्यक्तिगत मामले में उनसे निपटने की कोशिश करेंगे। अगर संदेह है, तो मुझे बुलाओ। ”



"सामान्य के लिए प्रबंधित करें और अपवादों को असाधारण मानें"

- एडवर्ड्स डेमिंग



"ठीक है, अंत में। मुझे परवाह नहीं है कि आप प्रति सप्ताह कितने घंटे काम करते हैं, जब तक कि यह लगभग पूरे समय मानक से मेल खाता है। यह मुझे चिंतित करता है कि जब आप काम करते हैं तो आप केंद्रित और प्रेरित होते हैं। क्या मैं इस जिम्मेदारी को लेने के लिए आप पर भरोसा कर सकता हूं? "



हर कोई उत्साह से सिर हिलाता है।



मैंने साहस जुटाया, सीईओ के पास गया, और उनसे कहा कि हम अब किए गए काम पर रिपोर्ट नहीं भेजेंगे। संवाद कुछ इस तरह रहा:



Me: "हम अब काम पूरा होने पर रिपोर्ट नहीं भेजेंगे"

सीईओ: "क्यों?"

मैं: "यह समय की बर्बादी है।"

CEO: "और कार्मिक विभाग परेशान नहीं होगा?"

मैं: "मैं उन्हें वही दूंगा जो उन्हें अधिक कुशल तरीके से चाहिए।"

सीईओ: "ठीक है, अच्छा है।"

वाह, यह मेरी अपेक्षा से अधिक आसान था। मैं विभिन्न मुद्दों के लिए तैयार हो गया ... मुझे वह सीईओ पसंद आया: ओ)

फिर मैं तख्ते पर गया।

Me: "हम अब पूर्ण कार्य पर रिपोर्ट नहीं भेजेंगे।"

कार्मिक: “लेकिन आपको करना चाहिए। यह मानक है! ”

मैं: "मानक बदल रहा है, मैंने अभी सीईओ से बात की है" (ठीक है, हाँ, मैंने थोड़ा झूठ बोला, मैं मानता हूँ)।

कार्मिक: "अब हम कैसे जानते हैं कि लोगों को कितना भुगतान करना है?"

मैं: “आपके पास सभी के रोजगार अनुबंध हैं। बस सभी को उनके सामान्य मासिक वेतन का भुगतान करें। ”

कार्मिक: "ओवरटाइम के बारे में क्या?"

मैं: “वह अब लगभग कभी नहीं रहेगा। अगर ऐसा होता है, तो मैं आपको बता दूंगा। बाकी समय, सप्ताह में 40 घंटे गिनें। ”

कार्मिक: "लेकिन हम अपनी प्रक्रियाओं और मानकों को बदलना नहीं चाहते हैं, शायद आप पहले की तरह ही रिपोर्ट भेजेंगे?"

I: “मैं उन्हें सप्ताह में 40 घंटे स्वचालित रूप से उत्पन्न कर सकता हूं और प्रत्येक सप्ताह मेल द्वारा स्वचालित रूप से आपके पास भेजा जाता हूं। क्या आपको इसकी आवश्यकता है? ”

कार्मिक: "हम्म, यह बहुत बेवकूफ निकला।"

मैं: “तो ठीक है, मैं उन्हें नहीं भेजूंगा। अगर तुम चाहो आप यह मान सकते हैं कि आपको हमसे 40-घंटे की रिपोर्ट मिलती है, और सिस्टम में यह सब दर्ज करें, जैसा कि आप आमतौर पर करते हैं। हम कम कागज़ पर हाथापाई करेंगे, और आपको देर से रिपोर्ट करने के लिए मुझे नहीं मारना होगा। "

कार्मिक: "ठीक है, काफी सही है, चलो कोशिश करते हैं।"

काम पूरा होने की रिपोर्ट के बारे में किसी और ने नहीं कहा।

इतिहास का नैतिक

1. कई संगठन बेकार में मानकों द्वारा निर्धारित सभी प्रकार की प्रक्रियाओं को निष्पादित करने में बहुत समय बिताते हैं - विभिन्न बेकार नियम, अभ्यास और प्रक्रियाएं। इस पर नए सिरे से विचार करें। इसे सकारात्मक रूप से लें - ये सुधार के अच्छे अवसर हैं।
2. यहां तक ​​कि पहली नज़र की प्रक्रिया में सबसे बेकार भी एक लक्ष्य है।
3. यदि आप बेकार प्रक्रिया से इनकार करने के लिए प्रतिरोध का सामना करते हैं, तो इसका कारण खोजें। पता करें कि इस प्रक्रिया को बंद करने की क्या जरूरत है। इस आवश्यकता को बंद करने के लिए एक कम खर्चीला और बेकार तरीका सुझाएं।
4. लगातार बने रहें। प्रक्रिया को खत्म करने में समय लगता है, जो संगठन में गहरा "घनीभूत" है।
5. इस प्रक्रिया की शुरुआत करने वाले पूर्ववर्तियों को दोष न दें। सबसे अधिक संभावना है, यह अतीत में एक वास्तविक समस्या का एक अच्छा समाधान था। हालांकि यह नहीं हो सकता था। सामान्य तौर पर, यह अब महत्वपूर्ण नहीं है, भविष्य पर ध्यान दें।
   
   "चीजें वे जिस तरह से हैं क्योंकि वे उस तरह से मिल गए हैं" - जेरी वेनबर्ग
6. प्रदर्शन के साथ दक्षता को भ्रमित न करें। पहले दक्षता पर ध्यान दें, और उसके बाद ही उत्पादकता पर।
7. एक घंटे प्रयास का एक उपाय है, न कि मूल्य का माप।

पूछे जाने वाले प्रश्न

ओवरटाइम जैसी किसी चीज़ के बाद, यह इस तथ्य को जन्म नहीं देता है कि आपने कम समय करना शुरू किया था

ठीक है, जिसके कारण कोड कम लिखा जा रहा है। कम बुरा कोड। कम महत्वपूर्ण कोड। कम कचरा। और इसलिए, कीड़े को पकड़ने के लिए कम समय, समर्थन सेवा को आतंक कॉल का जवाब देने के लिए जब सिस्टम दुर्घटनाग्रस्त हो गया, कीड़े की सूची बनाए रखने के लिए, सुधार जारी करने के लिए और एक कुटिल कोड को डिक्रिप्ट करने के लिए।



और इसका मतलब है कि एक अच्छा कोड लिखने के लिए अधिक समय।



हम सभी ने ओवरटाइम छोड़ने के बाद उत्पादकता में एक स्पष्ट और चिह्नित सुधार देखा। समय के प्रति उपयोगकर्ता मूल्य के संदर्भ में उत्पादकता।

क्या आपको कभी घंटों काम करने की आवश्यकता नहीं है?

ओह, कभी-कभी किसी विशेष परियोजना पर कितना समय खर्च किया जाता है, यह जानने के लिए पूरी तरह से सही कारण हैं, उदाहरण के लिए, अगर कोई बाहरी ग्राहक है जिसे बिल करने की आवश्यकता है। लेकिन यह पूरा काम पर रिपोर्ट के बिना करना आसान है। यदि 8 लोगों की एक टीम ने प्रोजेक्ट एक्स पर काम करने में 3 स्प्रिंट खर्च किए, और प्रत्येक स्प्रिंट में 2 सप्ताह लगे, तो हम मोटे तौर पर मान सकते हैं कि 8 लोगों ने 3 × 2 सप्ताह के लिए पूर्णकालिक काम किया। कुल 40 घंटे x 6 सप्ताह x 8 लोग = 1920 घंटे। सच है, यह हो सकता है कि वे एक ही समय में उत्पाद वाई का समर्थन करने में अपना समय बिताते हैं। इस मामले में, प्रत्येक पूर्वव्यापी में, मैं टीम से मोटे तौर पर अनुमान लगाने के लिए कहता हूं कि उन्होंने प्रोजेक्ट वाई पर कितने प्रतिशत काम किया, उदाहरण के लिए, 80% / 20%। गणना में इसे ध्यान में रखना काफी आसान है।



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



हालांकि, मैं यहां अधिक सावधान रहूंगा। मल्टीटास्किंग आमतौर पर एक बहुत बुरा विचार है। अगर हमें इस बात पर ध्यान देने के लिए एक जटिल प्रणाली बनानी है कि कैसे लोग परियोजनाओं के लिए अपना समय आवंटित करते हैं, तो हम निश्चित रूप से उस पर ध्यान केंद्रित नहीं कर रहे हैं - हमें समस्या को ठीक करना चाहिए (समानांतर में एक ही बार में कई परियोजनाएं करना) और न ही लक्षण (काम पर काम करने में समस्याएं) )।



मान लीजिए कि मैंने सोमवार को चार अलग-अलग परियोजनाओं पर काम किया, प्रत्येक में 2 घंटे, कुल 8 घंटे। मैं पूर्ण कार्य के लिए लेखांकन की प्रणाली में प्रत्येक परियोजना के लिए 2 घंटे का निशान लगाऊंगा, लेकिन इन सभी "संदर्भ स्विच" के साथ प्रभावी समय प्रति परियोजना 30-60 मिनट के करीब होगा। इसलिए दिन का अधिकांश समय बर्बाद हो गया।



एक टाइम ट्रैकिंग सिस्टम जो समय की बर्बादी करता है, वह खुद समय की बर्बादी है।

यदि हर कोई एक समय में केवल एक परियोजना पर काम करता है, तो किए गए काम को सीखना तुच्छ हो जाता है।

क्या यह संभव है कि कुछ डेवलपर्स ने ओवरटाइम के लिए बहुत अधिक धन प्राप्त करना बंद कर दिया हो?

मैंने अपनी सैलरी बढ़ा दी ताकि ओवरटाइम का मुआवजा अब ड्राइविंग फोर्स को न मिले। वृद्धि कई मामलों में महत्वपूर्ण थी। किसी ने इसके बारे में शिकायत नहीं की, किसी ने पुरानी प्रणाली पर स्विच करने का सुझाव नहीं दिया।



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



ओवरटाइट के लिए लोगों को भुगतान करना सभी की बेवकूफी भरी चीजों में से एक था, इसने हमें बहुत थका देने वाले डेवलपर्स और एक "तकनीकी ऋण" (बहुत कुटिल कोड, खामियों, आदि, बाद के लिए विलंबित) दिया।

आगे क्या हुआ?

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



यह लेख उस कहानी का दूसरा पक्ष है। सबसे महत्वपूर्ण बात, हम कभी भी वह नहीं कर पाएंगे जो हमने किया था अगर हमने लगातार किए गए समय के सभी कचरे को लगातार आक्रामक रूप से साफ करना जारी रखा (पूरा काम पर रिपोर्ट सिर्फ एक उदाहरण था)। हम्म ... शब्द "झुक" तुरंत मेरे सिर में क्यों आया? :)



यह सब 2006 में हुआ था। तब से, मैंने कभी भी किसी भी घंटे की मेज को छुआ या भरा नहीं है - भले ही मैं पिछले 4 वर्षों से परामर्श कर रहा हूं। यदि भविष्य के ग्राहक इस प्रश्न को उठाते हैं, तो मैं उनकी वास्तविक आवश्यकता का पता लगाऊंगा और इसे बंद करने का एक वैकल्पिक तरीका खोजूंगा।