एक PM कैसे कला उत्पादन को बदल सकता है: AAA गेमिंग में एक केस स्टडी

अस्वीकरण

प्रोजेक्ट मैनेजर के रूप में काम करते समय, मैंने अक्सर ऐसी टिप्पणियाँ सुनीं: "हमें PM की आखिर जरूरत ही क्यों है? वे वास्तव में करते क्या हैं? वे केवल बातें करते हैं और कुछ नहीं।" यह काफी आम राय है।

इसलिए मैंने एक लेख तैयार किया कि PM वास्तव में (अपनी टीम के साथ) क्या कर सकते हैं और वह काम किसी प्रोजेक्ट के लिए कितना प्रभावशाली हो सकता है। जैसा कि हम PM और प्रोड्यूसर्स को पसंद है — नंबर्स, टेबल्स और चार्ट्स के साथ। इसमें आर्ट पाइपलाइन, डेली रूटिंग ऑप्टिमाइजेशन और JIRA एटीकेट के बारे में तीन भाग हैं।

यह केस मेरे व्यक्तिगत अनुभव से आया है और इस पर केंद्रित है कि हमने एक AAA प्रोजेक्ट पर शुरुआत से Cosmetics विभाग कैसे बनाया और अंततः आर्ट प्रोडक्शन को ऑप्टिमाइज़ किया, इसे 3.3 गुना तेज़ कर दिया।

बहुत-बहुत धन्यवाद। पढ़ने का आनंद लें।

आर्ट पाइपलाइन

केस

एक बार मैं प्रोडक्शन में प्रोजेक्ट मैनेजर के रूप में मूव हुआ एक मिशन के साथ: एक cosmetics विभाग बनाना जो बैटल पासेज और इन-गेम इवेंट्स के लिए स्किन्स (और अधिक) डिलीवर करेगा।

उसी समय, हमारे पास पहले से ही एक कैरेक्टर आर्ट विभाग था। उन्होंने पूर्णता के विभिन्न चरणों में आठ कैरेक्टर और ज्यामिति परिवर्तनों के साथ एक हाई-टियर स्किन बनाई थी। उस एकल स्किन को बनाने में कलाकार को 16 महीने लगे।

मेरा कार्य एक कार्यशील प्रोडक्शन पाइपलाइन स्थापित करना और रिलीज़ तिथि तक पब्लिशर की आवश्यकताओं को पूरी तरह से पूरा करना था: नई ज्यामिति के साथ 21+ स्किन्स और 40+ रीकलर्स। उसके बाद, हमें हर महीने विभिन्न प्रकार की 7+ स्किन्स रिलीज़ करनी थीं — और अगले वर्ष, उन संख्याओं को दोगुना करना था।

कार्य

सबसे पहले, मैंने पिछले अनुभव और मेशेज़ (कैरेक्टर्स और एक स्किन) की वर्तमान प्रोडक्शन गति का विश्लेषण किया। Jira से डेटा और ढेर सारी Excel शीट्स का उपयोग करके, हमने कई कमजोर बिंदुओं की पहचान की।

आर्ट प्रोडक्शन रोडमैप

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

मानक की कमी

हर मेश को R&D फीचर के रूप में माना जाता था। जब हमने विभिन्न केसेज़ में L0/L1/L2 चरणों की तुलना की, तो हमने पाया कि वे पूरी तरह से अलग-अलग समय लेते थे — क्लीन टाइम (लॉग किए गए घंटे) और डर्टी टाइम (टास्क क्रिएशन, इसे "in progress" में मूव करने, और "done" मार्क करने के बीच का अंतर) दोनों। समान प्रकार के मेशेज़ के लिए टास्क की संख्या भी काफी भिन्न थी, और उनमें से कुछ में ऐसे विवरण थे जिन्हें समझना लगभग असंभव था।

एक अलग चीज़ जो सामने आई: टास्क को सौंपे गए एक कलाकार ने शुरू से अंत तक मेश पर काम किया (assignee history से देखते हुए)। और प्रोडक्शन के दौरान, ऐसे कोई तार्किक बिंदु नहीं थे जहाँ वह गुणवत्ता या समय खोए बिना इसे किसी और को सौंप सकता था। पूरा टास्क काम के एक विशाल, निरंतर ब्लॉक की तरह दिखता था।

प्रक्रिया पारदर्शिता की कमी

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

पुनरावृत्तियों की संख्या

बुनियादी स्टेटस हिस्ट्री से भी यह स्पष्ट था कि टास्क रिव्यू में गया, फिर वापस आया, फिर रिव्यू में वापस गया, और फिर काम पर वापस आया। और यह उन टिप्पणियों की पूर्ण अनुपस्थिति का उल्लेख नहीं है जो बताती हों कि टास्क को काम पर क्यों लौटाया जा रहा था और फिर वापस भेजा गया — एक भी शब्द नहीं।

हम अपने छोटे से Illuminati सर्कल — मैं (PM के रूप में), प्रिंसिपल आर्टिस्ट, और आर्ट लीड — के साथ एकत्र हुए और काम में लग गए।

समाधान

शुरुआत करने के लिए, हमने शीर्ष स्तर पर भ्रम को रोकने के लिए दो महत्वपूर्ण हाई-लेवल निर्णय लिए।

हमने ग्रेड्स पेश किए

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

"एक स्किन = एक epic = एक branch" नियम

मैंने यह संगठनात्मक नियम कैरेक्टर डेवलपमेंट टीम से उधार लिया। एक epic में डेवलपमेंट साइड पर स्किन से संबंधित सभी काम शामिल होते हैं। प्रत्येक epic में उस स्किन के लिए समर्पित एक single branch और एक single pull request होता है। बदले में, epic को आसान नेविगेशन के लिए संबंधित सीज़न (या इवेंट) initiative/feature से लिंक किया गया था।

यह हमारा शुरुआती बिंदु था। वहां से, हमने पूरे वर्कफ़्लो को फिर से बनाया।

हमने L0–L1–L2 से छुटकारा पा लिया

इसके बजाय, हमने वास्तविक प्रोडक्शन लॉजिक के अनुसार प्रोडक्शन को विभाजित किया: Design → Geometry → Textures → Implementation।

प्रत्येक चरण को छोटे तार्किक चरणों में विभाजित किया गया, उदाहरण के लिए: \n Concept: Moodboard – 2D Sketch – 3D Sketch (यदि आवश्यक हो) \n Geometry: Low Res – High Res – FBX File Import \n Implementation: Rig – GD Setup – Art Review – QA

स्किन को भी तीन भागों में विभाजित किया गया: बॉडी, हथियार, और मॉड्यूल। मतलब कि उसके बाद से हमारे पास तीन अलग-अलग टास्क हो सकते थे, जैसे: \n Body – Geometry Low Res, \n Weapon – Geometry Low Res, \n Modules – Geometry Low Res।

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

नया आर्ट प्रोडक्शन रोडमैप

मूल रूप से, हमने जो कुछ भी ऊपर किया था उसे क्रियाओं के क्रम के रूप में रखा गया था। इस चार्ट ने हमें — और किसी भी PM को जिसे बीमारी की छुट्टी या छुट्टी के दौरान मुझे बदलने की आवश्यकता हो सकती है — यह समझने में मदद की कि कहाँ और कौन सी प्रक्रियाओं को समय बचाने के लिए समानांतर में चलाया जा सकता है।

Epics और tasks के लिए यूनिफाइड फॉर्मेटिंग

Epic में अब केवल स्किन के ग्रेड से सख्ती से संबंधित टास्क शामिल थे — कुछ भी अतिरिक्त नहीं।

प्रत्येक epic में इसके विवरण में स्किन की concept शामिल थी, साथ ही प्रोड्यूसर से acceptance criteria भी।

इसने भ्रम को कम किया और कलाकार को प्रत्येक चरण में क्या अपेक्षित था, इसकी स्पष्ट समझ दी। (बाद में हमने टास्क विवरणों को और भी परिष्कृत किया, लेकिन वह daily routine के विषय से संबंधित है, जो आगे आता है।)

मैंने Confluence में एक Mira board के साथ एक अलग सेक्शन भी सेट किया जहाँ प्रत्येक टास्क के लिए ये सभी विवरण सूचीबद्ध थे, प्रोजेक्ट मैनेजर के लिए टिप्पणियों के साथ जो बताता था कि कब और कौन सा टास्क बनाया जाना चाहिए, साथ ही एक Jira फॉर्मूला जिसे बस टास्क बॉडी में कॉपी और पेस्ट किया जा सकता था।

अनुमान

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

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

अब कलाकार देख सकता था कि उनके पास प्रत्येक टास्क के लिए कितना समय है और वे इसे खत्म करने के कितने करीब हैं। उचित संचार के साथ, यह एक सपोर्ट टूल बन गया। यदि किसी कलाकार को दिखाई देता कि उनके पास एक टास्क के लिए तीन दिन बचे हैं लेकिन समझ गए कि वे इसे पूरा नहीं कर पाएंगे — तो वे सक्रिय रूप से मुझे बता सकते थे।

इसका मतलब था कि मुझे डेवलपर को "control" करने की आवश्यकता नहीं थी; उनके पास मेरी मदद करने और जहाँ हम डेडलाइन मिस कर सकते हैं वहाँ red flag उठाने के सभी टूल थे।

परिणामस्वरूप, हम डेवलपर स्वायत्तता हासिल करने में सफल रहे। एक epic खोलते समय, कलाकार को एक तैयार, पूरी तरह से तैयार टास्क मिलता था जिसे वे तुरंत शुरू कर सकते थे — भले ही वे शुरुआत में पूरी तरह से सुनिश्चित न हों कि क्या करना है। हमने रिव्यू सेशन्स और मूल्यांकन मानदंड को पारदर्शी बना दिया।

परिणाम

सीधे मुद्दे पर। केवल नंबर्स।

यही केस है।

\ \ \