2008-08-16 23 views
21

कोडप्लेक्स टीम की Slack समय नीति है, और यह उनके लिए बहुत अच्छी तरह से काम कर रही है।क्या आपके पास "धीमा" समय है?

  • जिम न्यूकिर्क और मैंने इसे xUnit.net प्रोजेक्ट पर काम करने के लिए उपयोग किया।
  • जोनाथन वानागल ने इसे SvnBridge पर काम करने के लिए उपयोग किया।
  • स्कॉट डेंसमोर और मैंने इसे ObjectBuilder 2.0 प्रोटोटाइप पर काम करने के लिए उपयोग किया।

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

क्या आपने अपनी टीम पर औपचारिक स्लैक नीति बनाई है? काम कैसे बना?

संपादित: मुझे अभी एहसास हुआ कि मैंने स्लैक को परिभाषित नहीं किया है। जिन लोगों ने पुस्तक नहीं पढ़ी है, उनके लिए स्लैक Google का "20% समय" है: आपको अपने दिन/सप्ताह/महीने/वर्ष का कुछ टुकड़ा दिया जाता है जिस पर उन चीज़ों पर काम करना है जो आपके लिए सीधे संबंधित नहीं हैं दिन-प्रति-दिन की नौकरी, लेकिन अप्रत्यक्ष लाभ हो सकता है (जाहिर है यदि आप ऐसी चीजों पर काम करते हैं जो आपकी नौकरी या आपकी कंपनी के लिए पूरी तरह से उपयोगी नहीं हैं, तो आपका प्रबंधक शायद आपके द्वारा समय व्यतीत करने के तरीके से बहुत अच्छा नहीं सोच पाएगा: -p)।

उत्तर

19

मैं इस विषय पर Google की नीति का उल्लेख करना चाहता हूं।
दिन के 20% निजी परियोजनाओं और शोध के लिए इस्तेमाल किया जाना चाहिए।

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

तो, यदि आप प्रबंधक हैं: अपने डेवलपर्स को अब और फिर ढीला होने दें। उन्हें सामान करने के नए तरीकों पर चर्चा करने के लिए टीम के साथ छोटे सेमिनार आयोजित करने के लिए प्रोत्साहित करें।

यदि आप एक डेवलपर हैं: अपने शिल्प को पढ़ें, सीखें और प्यार करें। जब तक आप अपनी नौकरी करने के सर्वोत्तम तरीकों को सीखने में कुछ समय देने के इच्छुक हैं, तब तक दुनिया में सबसे अच्छी नौकरियों में से एक है।

+1

कोड आलसी होने के बारे में वास्तव में पुन: उपयोग है? – Nick

1

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

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

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

5

मैंने कभी भी कहीं भी काम नहीं किया है जहां औपचारिक नीति थी, लेकिन मुझे हमेशा थोड़ा आर & डी/टूल-बिल्डिंग समय में निचोड़ना था।अक्सर बार मुझे उत्पादकता लाभ मिलेगा जो मुझे और भी 'ढीला' समय की अनुमति देगा।

8

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

उसने कहा, मुझे पालतू परियोजनाओं पर काम करने के लिए ढीला समय उपलब्ध होना अच्छा लगेगा, लेकिन कोई ग्राहक कभी इसके लिए भुगतान करने के लिए सहमत नहीं होगा।

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

1

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

नीति डेवलपर को प्रशिक्षण के लिए ढीले समय का उपयोग करने, कंपनी का उपयोग करने के लिए कुछ नया बनाने या कंपनी के भीतर उपकरण बनाने की सुविधा देता है ताकि चीजों को अपने लिए आसान बना दिया जा सके। यह हमारे लिए अच्छा काम किया है। हमें लगता है कि यह एक शानदार लाभ है।

1

हमारे पास मेरी टीम में औपचारिक नीति नहीं है - अधिकतर क्योंकि ऐसा करने के लिए इतना ही काम है कि यह उचित होगा। जो बहुत विडंबनापूर्ण है।

मैंने कम से कम टीम में इस सार के सार को इंजेक्ट करने के लिए "विकास मीटिंग्स" की नींव में कुछ औपचारिक चीजें करना शुरू कर दिया है। इसका एक उदाहरण एक विकास परियोजना है जिसका उद्देश्य नई प्रौद्योगिकियों को पढ़ाना और इसके अंत में एक अच्छा ऐप बनाना है।

यह शुरुआती दिन है, हम देखेंगे कि यह कैसा चल रहा है।

संबंधित मुद्दे