सॉफ्टवेयर मैनेजर जो डेवलपर्स बनाता है वह प्रोजेक्ट मैनेजमेंट करता है

Question

मैं एक सॉफ्टवेयर डेवलपर हूँ जो एक एम्बेडेड सिस्टम कंपनी में काम करता है। हमारे पास एक परियोजना प्रबंधक है, जो समग्र परियोजना अनुसूची (विद्युत, गुणवत्ता, सॉफ्टवेयर और निर्माण सहित) का ख्याल रखता है इसलिए उसका सॉफ्टवेयर अनुसूची बहुत संक्षिप्त है।

हमारे पास एक सॉफ्टवेयर मैनेजर भी है, जो मेरा बॉस है। वह मुझे सॉफ्टवेयर शेड्यूल, डिज़ाइन डॉक्यूमेंट्स (हाई और लो लेवल डिज़ाइन), SRS, चेंज मैनेजमेंट, वेरिफिकेशन प्लान्स और रिपोर्ट्स, रिलीज़ मैनेजमेंट, रिव्यूज़, और निश्चित रूप से सॉफ्टवेयर बनाए रखने के लिए लिखता है।

हमारे पास पूरी सॉफ्टवेयर टीम (10 सदस्यों) के लिए केवल एक टेस्ट इंजीनियर है, और किसी भी समय, कुछ परियोजनाएं चल रही हैं।

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

1. वह डिजाइन को सर्वोपरि मानते हैं, कोडिंग "बस डिजाइन नीचे लिख रहा है", यह बहुत लंबा नहीं होना चाहिए, और "सभी कोड को हार्डवेयर तैयार होने से पहले लिखा जाना चाहिए"।
2. एक केंद्रीय और वितरित संस्करण नियंत्रण के बीच अंतर को नहीं समझता है, भले ही हमने उसे वितरित मॉडल के साथ सहयोग करना आसान बताया हो।
3. कोड को नहीं समझता है, और हर बग और उसके प्रस्तावित समाधान को समझना चाहता है।
4. डेवलपर द्वारा विश्वास सत्यापन किया जाना चाहिए, और परीक्षक द्वारा सत्यापन किया जाना चाहिए। हालाँकि, हमारा सत्यापन केवल यह जाँचता है कि कार्यान्वयन सही है (हम इकाई परीक्षण नहीं लिखते हैं, यह अनुसूची में कभी नहीं माना जाता है), और सत्यापन ब्लैक बॉक्स परीक्षण है, इसलिए इकाइयाँ परीक्षण गायब हैं।

मैं वास्तव में उलझन में हूँ।

1. क्या मैं इन सभी दस्तावेजों को बनाए रखने के लिए जिम्मेदार हूं? यह मुझे लगता है जैसे मैं सॉफ्टवेयर प्रोजेक्ट मैनेजमेंट कर रहा हूं, संक्षेप में। मैं तकनीकी दस्तावेज के साथ ठीक हूं, लेकिन मेरा मानना ​​है कि डेवलपर द्वारा शेड्यूलिंग / प्लानिंग नहीं की जानी चाहिए।
2. मुझे वास्तव में दस्तावेज़ बनाना पसंद नहीं है, मैं समस्याओं को हल करना और कोड लिखना चाहता हूं। मेरे अनुभव में, डिज़ाइन दस्तावेज़ बनाना केवल एक हद तक मदद करता है, कभी भी बेहतर या तेज़ कोड का समाधान नहीं।
3. मुझे लगता है कि बॉस वास्तव में बेहतर उत्पाद बनाने के बारे में परवाह नहीं करते हैं, लेकिन केवल प्रबंधन की नजर में एक अच्छा प्रबंधक होने के बारे में।

मैं क्या कर सकता हूँ? इस पूरे साल मैंने 3 महीने की वास्तविक कोडिंग की है, बाकी सिर्फ दस्तावेजों को बनाने और ग्राहकों से बग रिपोर्ट का इंतजार करने में खर्च हुई है।

Comments

यदि वह आपका बॉस है और कहता है कि आप उन दस्तावेजों के लिए जिम्मेदार हैं, तो आप जिम्मेदार हैं।

— ऋग्वेद

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

— maple_shaft

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

@hdman अब थोड़ा अलग है। पीएम को गैंट चार्ट, संसाधन आवंटन और ट्रेसबिलिटी मैट्रिक्स करना चाहिए। फिर पीएम क्या करते हैं?

— maple_shaft

@maple_shaft मैं एक युवा लड़का हूं, और मैं चीजें बनाना, कोड बनाना और नया सामान आज़माना चाहता हूं। मैं वास्तव में परियोजना प्रबंधन को एक कैरियर विकल्प के रूप में लेने में दिलचस्पी नहीं रखता हूं। मुझे लगता है कि यह बदलाव का समय हो सकता है।

Answer 1

आप एक सॉफ्टवेयर इंजीनियर की तरह लग रहे हैं।

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

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

वह डिजाइन को सर्वोपरि मानते हैं, कोडिंग "बस डिजाइन को लिख रहा है"

यदि परियोजना प्रबंधक डिजाइन दस्तावेजों को सर्वोपरि मानता है तो वह इस प्रक्रिया में दस्तावेजों को एक सुपुर्दगी के रूप में लेने की अपेक्षा करता है। यह आपकी ओर से व्यर्थ समय नहीं है अगर उसे लगता है कि वे महत्वपूर्ण हैं जो आपके समय का 80% इसे आवंटित कर सकें।

यह बहुत लंबा नहीं होना चाहिए, और "सभी कोड को हार्डवेयर तैयार होने से पहले लिखा जाना चाहिए"।

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

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

(2) एक केंद्रीय और वितरित संस्करण नियंत्रण के बीच अंतर को नहीं समझता है।

उसकी देखभाल क्यों करनी चाहिए? यह मील के पत्थर को कैसे प्रभावित करता है? यह नहीं है

3) कोड को नहीं समझता है, और हर बग और उसके प्रस्तावित समाधान को समझना चाहता है

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

(4) विश्वास सत्यापन डेवलपर द्वारा किया जाना चाहिए, और परीक्षक द्वारा सत्यापन किया जाना चाहिए।

इस भावना के साथ क्या गलत है? गुणवत्ता आश्वासन भूमिका में परीक्षकों को मान्य विशेषताओं और आवश्यकताओं से संबंधित होना चाहिए। डेवलपर्स को परीक्षण करने से पहले अपने काम को सत्यापित करने और परीक्षण करने का हर संभव प्रयास करना चाहिए।

मुझे वास्तव में दस्तावेज़ बनाना पसंद नहीं है, मैं समस्याओं को हल करना और कोड लिखना चाहता हूं।

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

मेरे अनुभव में, डिज़ाइन दस्तावेज़ बनाना केवल एक हद तक मदद करता है, कभी भी बेहतर या तेज़ कोड का समाधान नहीं।

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

इस तथ्य का तथ्य यह है कि सबसे अच्छा तकनीकी दस्तावेज कोड ही है।

मुझे लगता है कि बॉस वास्तव में बेहतर उत्पाद बनाने के बारे में परवाह नहीं करते हैं, लेकिन केवल प्रबंधन की नजर में एक अच्छा प्रबंधक होने के बारे में

मुझे लगता है कि वह देखभाल करता है क्योंकि उत्पाद उसका वार्ड है और यदि परियोजनाएं और सुविधाएँ पूरी नहीं हुई हैं और ग्राहक खुश नहीं हैं तो ऊपरी प्रबंधन उसकी बहुत परवाह नहीं करेगा। समस्या यह है कि आवश्यक गुणवत्ता सुधारों के बारे में आपका दृष्टिकोण उसके और ऊपरी प्रबंधन से मेल नहीं खाता है, और ग्राहकों की धारणा यह महसूस करती है कि वे महत्वपूर्ण हैं।

यह समझने की कोशिश करें कि उत्पाद के लिए वास्तव में क्या महत्वपूर्ण है, क्योंकि जब आप किसी प्रक्रिया की दक्षता को 3 गुना बढ़ा सकते हैं, यदि आप ऐसा करने में पूरा सप्ताह व्यतीत करते हैं तो यह एक अन्य महत्वपूर्ण विशेषता की लागत पर है जो ग्राहक की मांग है।

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

Comments

उत्तर के लिए धन्यवाद, मैं कुछ बिंदुओं पर सहमत हूं। लेकिन फिर सॉफ्टवेयर मैनेजर की भूमिका क्या है?

Answer 2

कुछ हद तक, मैं आपके प्रोजेक्ट मैनेजर से सहमत हूं। सॉफ़्टवेयर विकास कोडिंग सुविधाओं से परे जाता है। :-)

आपकी स्थिति को देखते हुए, मैं उसके पास जाऊंगा और समझाऊंगा कि उसके अनुरोध में आपका 80% समय लग रहा है, और यह समझने की कोशिश करें कि उसके लिए यह महत्वपूर्ण क्यों है कि आप इस समय को विकसित करने के बजाय दस्तावेज़ीकरण बनाए रखें (जो कोडिंग से परे है)।

एक सॉफ्टवेयर कंपनी FYI, Atlassion , में एक QA व्यक्ति के लिए 13 डेवलपर्स का अनुपात है और अधिकांश परीक्षण (योजना और निष्पादन) डेवलपर्स द्वारा किया जाता है। मैंने इसे एजाइल 2012 में अपनी प्रस्तुतियों में से एक के दौरान सीखा है और हमारी टीम इस समय इस अभ्यास का अनुकरण करने की कोशिश कर रही है।

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

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

Comments

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

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

— डेविड नेगड

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

Answer 3

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

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

इसके अलावा, एक सख्त व्यवसायिक दृष्टिकोण से, क्यूए को काम पर रखना डेवलपर्स को काम पर रखने से सस्ता है। यदि टीमों के पास अच्छा QA / DEV अनुपात है, तो आप खर्च किए गए धन के लिए अधिक जमीन को कवर करने में सक्षम होंगे।

Comments

QA can be replaced by automated testing depending on your domain-1 मैं इससे असहमत हूं। स्वचालित परीक्षण की कोई राशि QA के लिए एक व्यवहार्य प्रतिस्थापन नहीं है, विशेषकर जब विशेष हार्डवेयर इसमें शामिल होता है।

— maple_shaft

@maple_shaft सही किया गया। मेरा मतलब था कि QA को आपके डोमेन के आधार पर एक हद तक बदला जा सकता है। उदाहरण के लिए यदि यह कुछ मशीनरी के लिए एक नियंत्रक उपकरण है जिसे आप जानते हैं कि दिए गए कुछ इनपुट से आपको कुछ आउटपुट की उम्मीद है - यह स्वचालित रूप से परीक्षण किया जा सकता है। हालाँकि अगर यह एक GUI एप्लिकेशन है, तो वास्तविक लोगों के आस-पास बैठने और उस पर प्रहार करने का कोई तरीका नहीं है।

— 18

बहुत बढ़िया! यह अब अधिक समझ में आता है। मैं अपने downvote, +1 उलट

— maple_shaft

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

Answer 4

सीएमएमआई कार्यान्वयन मैंने देखा है या सीधे सुना है कि सभी प्रक्रिया और प्रलेखन भारी रहे हैं; आपके आकाओं का मानना ​​है कि कार्यान्वयन को विस्तृत बनाने के लिए दस्तावेज़ीकरण पर्याप्त विस्तृत होना चाहिए ताकि यह सुनिश्चित हो सके कि उसकी अपेक्षा समान है।

यदि आप दस्तावेज़ लेखन / रखरखाव का एक असमान हिस्सा प्राप्त कर रहे हैं, तो पूछें कि यह अधिक समान रूप से वितरित किया जाना उचित है। यदि अन्य डेवलपर्स के पास अनुपात कोडिंग के समान दस्तावेज हैं और आप अपना अधिकांश समय कोड लिखना चाहते हैं; यह एक नया नियोक्ता खोजने पर विचार करने का समय हो सकता है।

Comments

बिल्कुल सही। वह पूरी तरह से सीएमएमआई के बारे में है। अब हम स्तर 3 पर हैं, वह 5 के स्तर पर जाना चाहता है। 'लीड' ज्यादातर नियोजन / शेड्यूलिंग कार्य करता है, जो मैं अभी कर रहा हूं। लेकिन हमारी संगठन संरचना सभी एसईएस को समान बनाती है, इसलिए एक व्यक्ति को लीड के रूप में चुना जाता है और यह सब काम दिया जाता है, प्रति स्थायी कोई सीसा नहीं है।

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

@hdman इसमें कुछ भी गलत नहीं है और यह जरूरी नहीं कि यह आपकी या उनकी गलती हो। कभी-कभी लोग सिर्फ एक पर्यावरण के अनुकूल नहीं होते हैं।

— मेपल_शाफ्ट

हाँ, मुझे लगता है कि यह एक संस्कृति मुद्दा हो सकता है।

5 स्तर पर कागजी कार्रवाई का बोझ बड़े पैमाने पर होने जा रहा है; लगता है कि यह निश्चित रूप से भागने का समय है।

— दान

Answer 5

आप चिकित्सा प्रणालियों के बारे में बात कर रहे हैं ... इसलिए सुरक्षा सर्वोपरि है - और इसलिए प्रलेखन (विशेष रूप से ट्रेसबिलिटी) आवश्यक है।

एक परीक्षक थोड़ा हल्का लगता है, लेकिन इसके अलावा, हाँ - प्रलेखन सुनिश्चित करने के लिए आप जिम्मेदार हैं।

चिकित्सा जगत में मेरा अनुभव सीमित है, लेकिन एयरोस्पेस / रक्षा की दुनिया में हमारे पास Do-178B (अब C) है जो एक जीवनचक्र मॉडल को निर्धारित करता है जो आवश्यक परीक्षण और परीक्षण के स्तर को निर्दिष्ट करता है (सुरक्षा महत्वपूर्णता के आधार पर) विशेष रूप से सॉफ्टवेयर के डिजाइन आश्वासन स्तर], और मोटर वाहन की दुनिया में हमारे पास ISO26262 है जो इसी तरह है।

यदि प्रलेखन जगह में नहीं है, तो उत्पाद प्रमाणित नहीं होता है।

लेकिन महत्वपूर्ण बात यह है कि अपने उत्पाद को बेहतर बनाने के लिए आवश्यक दस्तावेज के साथ काम करना है ... कोशिश मत करो और रिवर्स-इंजीनियर प्रलेखन को एक विचार के रूप में समझो क्योंकि तब यह कोई वास्तविक दुनिया उद्देश्य नहीं करता है।