आपके सॉफ़्टवेयर प्रोजेक्ट में देरी क्यों हो रही है (और इसके बारे में क्या करें)

स्टैंडिश ग्रुप की 2024 CHAOS रिपोर्ट में यह पाया गया66% सॉफ़्टवेयर प्रोजेक्ट अपनी समयसीमा या बजट से अधिक हैं. पांच में से एक को तुरंत रद्द कर दिया जाता है। ये संख्याएँ एक दशक से भी अधिक समय से लगातार स्थिर बनी हुई हैं।

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

1. स्कोप क्रीप खराब कोड की तुलना में अधिक परियोजनाओं को नष्ट कर देता है

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

यहां वह गणित है जो गुंजाइश को इतना विनाशकारी बना देता है:सप्ताह 1 में आवश्यकताओं में बदलाव के लिए लगभग 1 घंटे का इंजीनियरिंग समय खर्च होता है। सप्ताह 8 में समान परिवर्तन की लागत 10 गुना अधिक है. सप्ताह 8 तक, कोडबेस में मूल डिज़ाइन के शीर्ष पर निर्भरताएँ निर्मित हो जाती हैं। दिशा बदलने का अर्थ है कार्यशील कोड को पुनः सक्रिय करना, परीक्षणों को अद्यतन करना, एकीकरणों को पुनः सत्यापित करना और उन सुविधाओं का पुनः परीक्षण करना जिन पर आपने पहले ही हस्ताक्षर कर दिए हैं।

आईबीएम सिस्टम साइंसेज इंस्टीट्यूट ने डेटा प्रकाशित किया है जिसमें दिखाया गया है कि रखरखाव चरण के दौरान पाए गए दोषों को डिजाइन चरण के दौरान पाए गए दोषों की तुलना में ठीक करने में 100 गुना अधिक लागत आती है। आवश्यकताएँ परिवर्तन समान लागत वक्र का अनुसरण करते हैं।

इसके बजाय क्या करें:कोई भी कोड लिखे जाने से पहले एक उत्पाद आवश्यकता दस्तावेज़ (पीआरडी) लिखें। प्रत्येक सुविधा, प्रत्येक उपयोगकर्ता प्रवाह और प्रत्येक एपीआई समापन बिंदु को सूचीबद्ध करें। प्रत्येक हितधारक से साइन-ऑफ प्राप्त करें। फिर पीआरडी को एक अनुबंध के रूप में मानें। नए विचार "v2 बैकलॉग" में जाते हैं, वर्तमान स्प्रिंट में नहीं। सावी में, हम विकास शुरू होने से पहले आवश्यकताओं की परिभाषा पर 1-2 सप्ताह बिताते हैं। योजना में $1,500 का निवेश मध्य-परियोजना पुनर्कार्य में $10,000+ बचाता है।

2. संचार परतें सप्ताह जोड़ती हैं, स्पष्टता नहीं

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

इस श्रृंखला में प्रत्येक हैंडऑफ़ दो समस्याएं पेश करता है। सबसे पहले, सूचना हानि. आपके मूल अनुरोध में बारीकियाँ थीं; जब तक यह डेवलपर तक पहुंचता है, तब तक इसे तीन बार व्याख्यायित किया जा चुका होता है। दूसरा, विलंबता. प्रत्येक हैंडऑफ़ में 4-24 घंटे का प्रतीक्षा समय जुड़ जाता है। एक प्रश्न जिसे 5 मिनट की कॉल में हल किया जा सकता है उसे संचार श्रृंखला के माध्यम से चक्कर लगाने में 3 दिन लगते हैं।

प्रोजेक्ट मैनेजमेंट इंस्टीट्यूट के एक अध्ययन में यह पाया गयाखराब संचार के कारण परियोजना बजट का 56% जोखिम में है. $50,000 की परियोजना पर, यानी $28,000 ग़लत संचार बर्बादी के संपर्क में है।

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

3. गलत टीम संयोजन से हैंडऑफ़ पर बजट ख़राब हो जाता है

कई एजेंसियों के कर्मचारी 4-6 डेवलपर्स के साथ प्रोजेक्ट करते हैं: दो फ्रंटएंड, दो बैकएंड, एक क्यूए इंजीनियर और एक डेवऑप्स व्यक्ति। यह उत्पादक लगता है. व्यवहार में, यह एक समन्वय कर बनाता है जो कुल बजट का 30-40% खाता है।

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

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

इसके बजाय क्या करें:स्टाफ 1-2 वरिष्ठ फ़ुल-स्टैक इंजीनियरों के साथ प्रोजेक्ट करता है जिनके पास संपूर्ण कोडबेस होता है। एक इंजीनियर जो एपीआई बनाता है, फ्रंटएंड लिखता है, डेटाबेस कॉन्फ़िगर करता है, और एप्लिकेशन को तैनात करता है, उसके पास शून्य हैंडऑफ़ ओवरहेड होता है। सावी में, यह हमारा डिफ़ॉल्ट है। एक अकेला वरिष्ठ इंजीनियर 5 सप्ताह में 20,000 डॉलर का प्रोजेक्ट भेजता है, वही प्रोजेक्ट 12 सप्ताह में भेजने वाले चार जूनियरों की टीम से बेहतर प्रदर्शन करता है, जिसमें अधिक बग और उच्च कुल लागत होती है।

4. सुविधाओं के लिए कोई परिभाषित "पूर्ण" मानदंड नहीं

"उपयोगकर्ता डैशबोर्ड बनाएं" कोई फीचर विशिष्टता नहीं है। यह एक वार्तालाप आरंभकर्ता है. स्पष्ट स्वीकृति मानदंड के बिना, इंजीनियर धारणाएँ बनाते हैं। कभी-कभी वे धारणाएँ ग्राहक की इच्छा से मेल खाती हैं। अक्सर, वे ऐसा नहीं करते.

परिणाम: इंजीनियर तीन चार्ट और एक डेटा तालिका के साथ एक डैशबोर्ड बनाता है। ग्राहक को पांच चार्ट, एक दिनांक सीमा फ़िल्टर, एक सीएसवी निर्यात बटन और एक तुलना दृश्य की उम्मीद थी। इंजीनियर इसका पुनर्निर्माण करता है। ग्राहक पुनर्निर्माण पर प्रतिक्रिया देता है। जिस सुविधा में 3 दिन लगने चाहिए थे उसमें 10 लग गए।

यह पैटर्न इतना सामान्य है कि परियोजना प्रबंधन में इसका एक नाम है:"90% हो गया" जाल. एक फीचर हफ्तों तक "लगभग समाप्त" पर पड़ा रहता है क्योंकि किसी ने भी यह परिभाषित नहीं किया है कि "समाप्त" कैसा दिखता है। इंजीनियर चमकाते रहते हैं. ग्राहक परिवर्तन का अनुरोध करते रहते हैं। प्रोजेक्ट में समय बर्बाद होता है।

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

5. एकीकरण जटिलता को कम आंकना

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

उस "एक दिवसीय कार्य" में एक वरिष्ठ इंजीनियर को 3-5 दिन और एक कनिष्ठ को 7-10 दिन लगते हैं। इस कम अनुमान को 3-4 एकीकरणों (पेमेंट गेटवे, ईमेल प्रदाता, एनालिटिक्स, केवाईसी) में गुणा करें, और आपने एक ऐसे प्रोजेक्ट में 2-4 सप्ताह जोड़ दिए हैं जिसके लिए किसी ने बजट नहीं बनाया था।

तृतीय-पक्ष API गुणवत्ता में बेतहाशा भिन्नता होती है। स्ट्राइप में उत्कृष्ट दस्तावेज़ीकरण और सैंडबॉक्स वातावरण है। कई उद्योग-विशिष्ट एपीआई (बैंकिंग, लॉजिस्टिक्स, सरकार) में अधूरे दस्तावेज़, अविश्वसनीय सैंडबॉक्स और समर्थन टीमें हैं जो 48-72 घंटों में जवाब देती हैं। प्रत्येक खराब दस्तावेजित एपीआई अनुमानित एकीकरण समय को 2-3 गुना जोड़ता है।

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

6. बिग बैंग लॉन्च बड़ी बैंग विफलताएं पैदा करते हैं

"सब कुछ बनाएं, एक बार लॉन्च करें" दृष्टिकोण सॉफ्टवेयर विकास में सबसे जोखिम भरी डिलीवरी रणनीति है। टीमें 3-6 महीने अलगाव में निर्माण कार्य में बिताती हैं। विकास टीम के बाहर कोई भी उत्पाद नहीं देखता है। लॉन्च के दिन, दर्जनों सुविधाओं का एक साथ उत्पादन शुरू हुआ। बग यौगिक. उपयोगकर्ताओं को टूटे हुए प्रवाह का सामना करना पड़ता है। टीम अगले 2 सप्ताह पुनरावृत्ति करने के बजाय अग्निशमन मोड में बिताती है।

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

इसके बजाय क्या करें:क्रमिक रूप से शिप करें. परियोजना को 1-2 सप्ताह के मील के पत्थर में विभाजित करें, प्रत्येक एक कार्यशील, तैनाती योग्य सुविधा का उत्पादन करता है। सावी में, हम साप्ताहिक डेमो चलाते हैं जहां ग्राहक काम कर रहे सॉफ़्टवेयर को देखता है, वास्तविक प्रवाह पर क्लिक करता है, और लाइव स्टेजिंग वातावरण पर प्रतिक्रिया देता है। यदि कुछ गलत है, तो हम उसे दूसरे सप्ताह में पकड़ लेते हैं, 12वें सप्ताह में नहीं।

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

अपना अगला प्रोजेक्ट शुरू करने से पहले एक चेकलिस्ट

ये छह समस्याएं अपरिहार्य नहीं हैं। वे प्रक्रिया विफलताएं हैं, और प्रक्रिया विफलताओं में प्रक्रिया समाधान हैं। आपका अगला प्रोजेक्ट शुरू होने से पहले, इन छह शर्तों को सत्यापित करें:

• आवश्यकताएँ लिखी और हस्ताक्षरित हैं।प्रत्येक सुविधा के लिए स्वीकृति मानदंड हैं। हितधारक लिखित रूप में गुंजाइश पर सहमत हुए, किसी कॉल पर नहीं जिसका किसी ने दस्तावेजीकरण नहीं किया।
• आप अपना उत्पाद बनाने वाले इंजीनियर से बात कर सकते हैं।आपकी आवश्यकताओं का अनुवाद करने वाला कोई मध्यस्थ नहीं। स्लैक, ईमेल या वीडियो कॉल के माध्यम से सीधी पहुंच।
• टीम छोटी और सीनियर है.1-2 पूर्ण-स्टैक इंजीनियर जिनके पास संपूर्ण कोडबेस है। फ्रंटएंड, बैकएंड, क्यूए और डेवऑप्स के बीच हैंडऑफ़ वाली 6-व्यक्ति टीम नहीं।
• प्रत्येक सुविधा की एक "पूर्ण" परिभाषा होती है।परीक्षण योग्य, विशिष्ट स्थितियाँ। "डैशबोर्ड बनाएं" नहीं बल्कि "सीएसवी निर्यात के साथ राजस्व, ऑर्डर और रूपांतरण दर प्रदर्शित करें।"
• एकीकरणों का प्रोटोटाइप जल्दी तैयार किया जाता है।सबसे जोखिम भरे तृतीय-पक्ष कनेक्शन का परीक्षण सप्ताह 1 में किया जाता है, न कि सप्ताह 8 में।
• आप हर सप्ताह कार्यशील सॉफ़्टवेयर देखते हैं।मंचन के माहौल पर साप्ताहिक डेमो। वास्तविक क्लिक, वास्तविक डेटा, वास्तविक फीडबैक लूप।

सभी छह बक्सों की जांच करने वाली परियोजनाएं समय पर भेजी जाती हैं। जो परियोजनाएँ उनमें से एक को भी छोड़ देती हैं वे देर से चलती हैं। सहसंबंध वह सुसंगत है.

अक्सर पूछे जाने वाले प्रश्नों