मैं अपने कॉलेज के दूसरे वर्ष में एक प्रोग्रामर बन गया, अपने सभी प्रोग्रामिंग पाठ्यक्रमों में उत्कृष्ट प्रदर्शन किया और समस्या-समाधान के लिए एक प्रोग्रामर की मानसिकता विकसित की। अब, तीन साल बाद, एक वीडियो गेम निर्माता के रूप में, जिस प्रोग्रामर मानसिकता पर मुझे बहुत गर्व था, उसने मेरे पहले PoCT (प्रूफ ऑफ़ कॉन्सेप्ट टेक्नोलॉजी) मील के पत्थर में कई बाधाएँ ला दीं। यह स्पष्ट हो गया है कि मानसिकता में बदलाव जरूरी है।

यहाँ मैंने प्रोग्रामर और प्रोड्यूसर माइंडसेट के बीच मुख्य अंतर के रूप में पहचान की है:

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

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

मेरी टीम के प्रोग्रामरों में से एक के शब्दों को उद्धृत करते हुए:
अपने कोड पर काम करते समय, मैं सामान्य रूप से अपने शोर-रद्द करने वाले हेडफ़ोन लगाता था और अपने दिमाग में रहता था। मैं संगीत नहीं सुन रहा था; मुझे अपने कोड्स पर ध्यान केंद्रित करने के लिए बस मौन वातावरण की आवश्यकता थी।

हालाँकि, यदि कोई निर्माता अपनी टीम के साथ बैठकर शोर-रद्द करने वाला हेडफ़ोन लगाता है, तो यह एक बुरा निर्माता है।

निर्माताओं को हर जगह देखने और हर जगह सुनने की जरूरत है।

यह उत्पादकों का कर्तव्य है कि वे अपनी टीम में सभी की प्रगति को ट्रैक करें, यह सुनिश्चित करें कि वे ओवर-स्कोपिंग नहीं कर रहे हैं, और यदि क्रॉस-टीम सहयोग आवश्यक है तो अन्य टीम के उत्पादकों के साथ समन्वय करें।

एक एसडी निर्माता के रूप में, मेरी पीओसीटी के दौरान, मेरी कुर्सी पर बैठने के बाद हर दस से बीस मिनट में, मुझे मेरी टीम या हमारे स्तर के डिजाइन निर्माता, गेम डिजाइनर, लीड प्रोड्यूसर आदि में से किसी ने बुलाया था।

जब भी मैं किसी खास काम पर ज्यादा फोकस करने की कोशिश करती, तो कोई मुझे कॉल करता। PoCT के दौरान, सौभाग्य से, मैंने संतुष्ट किया कि जिसने भी मुझसे बात की, चाहे उन्हें कैलेंडर पर स्पष्टीकरण की आवश्यकता हो या हमारी टीम के किसी विशेषज्ञ से सहायता की आवश्यकता हो, आदि; दुर्भाग्य से, हमारे सामान्य कार्य समय के बाद मुझे अपने सामान पर अतिरिक्त समय देना चाहिए।

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

• अनुमानित घंटों के साथ प्रत्येक कार्यदिवस के लिए एक सूची बनाने की कोशिश करें और क्रंचेस से बचने के लिए सावधानीपूर्वक सूची का पालन करें।
• प्रत्येक बातचीत के लिए एक समय बॉक्स निर्धारित करें और उस समय बॉक्स का सख्ती से पालन करें (दस मिनट एक अच्छा हो सकता है)।

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

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

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

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

आगे।

सेवक नेतृत्व के विचार के अनुसार। उत्पादकों को सही काम करना चाहिए "टीम की सेवा करें" और टीम को जरूरत पड़ने पर सहायता प्रदान करने के लिए तैयार रहें। लेकिन नौकर नेतृत्व का वास्तव में क्या मतलब है? निर्माताओं की टीम की क्या उम्मीदें हैं? वे किस तरह की समस्याओं को उत्पादकों के बिना हल नहीं कर सकते? इस विषय पर विशेष रूप से मेरे भविष्य के ब्लॉग को देखें!

संदर्भ:

[1]: सीखने की मानसिकता: कुछ भी सीखने को कैसे बढ़ाया जाए

[2]: 18 स्किल्स सभी प्रोग्रामर्स के पास होनी चाहिए

[3]: समय पर और प्रभावी प्रतिक्रिया का महत्व