आपण हे स्वयंचलित करावे? अंकगणित जे ठरवते

इंटरनेट ऑटोमेशन कॅल्क्युलेटरने भरलेले आहे. "दर आठवड्याला वाचवलेले तास × तासाचा खर्च" टाइप करा आणि कॅल्क्युलेटर तुम्हाला आत्मविश्वासाने सांगतो की तुमचे इनव्हॉइस रिमाइंडर्स स्वयंचलित केल्याने वर्षाला ₹4.7 लाखांची बचत होईल. तो आकडा चुकीचा नाही, अगदी. बहुतेक लहान ऑटोमेशनला विजयापासून तोट्यात बदलणारा शब्द फक्त गहाळ आहे.

गहाळ शब्द देखभाल आहे. "आम्हाला कदाचित एक किंवा दोनदा त्यात बदल करावा लागेल" असे नाही, परंतु UI बदल, API ब्रेकेज, एज केसेस, क्रेडेन्शियल रोटेशन, सायलेंट फेल्युअर आणि दर तीन आठवड्यांनी येणारी "मला आणखी एक इफ-स्टेटमेंट जोडणे आवश्यक आहे" ची विशिष्ट आवृत्ती यांद्वारे ऑटोमेशन कार्यरत ठेवण्याची प्रामाणिक, चालू असलेली किंमत. एकदा तुम्ही अंकगणितामध्ये मेंटेनन्स टर्म जोडला की, तुम्ही तयार करणार असलेल्या अंदाजे अर्ध्या ऑटोमेशन्स नकारात्मक येतात आणि बाकीचे अर्धे कॅल्क्युलेटरने वचन दिलेल्या पेक्षा खूपच लहान होतात.

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

विक्रेता कॅल्क्युलेटर वगळले जाणारे एक-लाइन सूत्र

ऑटोमेशनच्या निव्वळ वार्षिक मूल्यासाठी योग्य सूत्र आहे:

नेट = (प्रति कालावधी वाचवलेले तास × तासाचा खर्च × प्रति वर्ष कालावधी) - बिल्ड खर्च परिशोधित − देखभाल खर्च प्रति वर्ष − अयशस्वी खर्च प्रति वर्ष

मी पाहिलेला प्रत्येक विक्रेता ROI कॅल्क्युलेटर प्रथम टर्म योग्य, दुसऱ्या वेळी जेश्चर करतो आणि तिसरा आणि चौथा पूर्णपणे दुर्लक्ष करतो. मला प्रामाणिकपणे प्रत्येकाचे नाव सांगू द्या.

प्रति कालावधी वाचवलेले तास × प्रति तास खर्च × प्रति वर्ष कालावधी. एकूण लाभ. येथे पुराणमतवादी व्हा - तुमच्या डोक्यातील संख्या जवळजवळ नेहमीच जास्त असते जे तुम्ही काम पूर्ण केल्यावर प्रत्यक्षात घडते. BrowserStack's own automation-ROI guide स्पष्टपणे म्हणतो की "त्रुटीचा सर्वात मोठा स्त्रोत म्हणजे वेळ-जतन केलेली आकृती आहे, म्हणून पुराणमतवादी व्हा आणि कार्याला वेळ द्या कारण ते मेमरीवर विश्वास ठेवण्याऐवजी काही वेळा घडते." तीन वेळा वेळ काढा, मध्यक घ्या, नंतर चांगल्या मापासाठी 20% वजा करा.

बिल्डची किंमत अमोर्टाइज्ड. ऑटोमेशन तयार करण्याचा एक वेळचा खर्च, तुम्ही ते चालवण्याची प्रामाणिकपणे अपेक्षा करता त्या वर्षांच्या संख्येने भागून. सरासरी ऑटोमेशन ब्रेक होण्यापूर्वी किंवा बदलण्यापूर्वी सुमारे अठरा महिने चालत असले तरीही तीन वर्षांहून कमी कालावधीत कोणीही हे रद्द करत नाही. 3 नव्हे तर 1.5 वर्षांहून अधिक काळ अमर्यादित करा.

दर वर्षी देखभाल खर्च. ते कार्यरत ठेवण्याचा चालू खर्च. ही गहाळ संज्ञा आहे. वास्तविक ऑटोमेशन्स बिल्ड खर्चाच्या 15% आणि 40% दरम्यान खर्च करतात, दरवर्षी, देखभालीवर — test-automation research ही श्रेणी विशेषतः ठेवते. कमी टोकाला लहान ऑटोमेशन (क्वचितच बदलणारे API, एक स्थिर इनपुट स्वरूप), उच्च टोकाला जटिल ऑटोमेशन. चूक शून्य गृहीत आहे.

अयशस्वी खर्च दर वर्षी. ऑटोमेशन चुकीचे चालते आणि काहीतरी अन-करावे लागते तेव्हाची किंमत. हे एक बग बजेट नाही; ही प्रामाणिक अपेक्षा आहे की ऑटोमेशन अधूनमधून आउटपुट तयार करेल जे सुधारण्यासाठी तुमचा वेळ, विश्वासार्हता किंवा पैसा खर्च होईल. लो-स्टेक ऑटोमेशनसाठी (अहवाल स्वरूपित करणे), हे शून्याच्या जवळ आहे. ग्राहकाला तोंड देणाऱ्या ऑटोमेशनसाठी (ईमेल पाठवणे, इन्व्हेंटरी हलवणे), हे सहज स्थूल लाभापेक्षा जास्त असू शकते.

चार अटी प्रामाणिकपणे जोडा आणि चित्र बदलेल. एक "माय इनव्हॉइसिंग रिमाइंडर ईमेल स्वयंचलित करा" प्रकल्प ज्याचा साधा कॅल्क्युलेटर वर्षभरात +₹2 लाख स्कोअर करतो आणि प्रामाणिक देखभाल आणि अयशस्वी खर्चानंतर अनेकदा +₹40k वर स्कोअर करतो — तरीही सकारात्मक, परंतु ते इतके लहान आहे की ते त्याच वेळी तुम्ही करू शकत असलेल्या इतर गोष्टींशी स्पर्धा करते.

5-तास-एक महिना मजला

सर्वात वाईट ऑटोमेशन वाचवणारा एकच नियम आहे: जर टास्क महिन्यातून किमान ५ तास लागत नसेल आणि तुम्ही अर्थपूर्ण त्रुटी खर्च ओळखू शकत नसाल तर ते स्वयंचलित करू नका.

तो माझा नंबर नाही; हे industry rule of thumb आहे की अगदी साध्या ऑटोमेशनसाठी बिल्ड-आणि-मेंटेनन्स सायकल पहिल्या वर्षात साधारणत: 6-15 तास घेते आणि जर टास्क महिन्यातून फक्त 3 तास वाचत असेल तर त्याचे मूल्य परत येण्याआधी तुम्ही सहा महिने खर्च केले असतील - ज्या दरम्यान अंतर्निहित प्रणाली सहसा पुरेशी बदलली आहे की ऑटोमेशनला निराकरण करणे आवश्यक आहे.

5-तास मजला उदार आहे. त्याच्या खाली, अंकगणित जवळजवळ कधीच काम करत नाही, आणि ऑटोमेशन तयार करण्याचा मोह मूलत: सौंदर्याचा आहे — "आम्हाला हे वेगळ्या पद्धतीने करण्याची गरज आहे" ऐवजी "संगणकाने हे केले तर ते व्यवस्थित होईल का"

माझ्या अनुभवानुसार, तीन विशिष्ट कार्ये जी नेहमी 5-तासांच्या मजल्यावरील चाचणीत अपयशी ठरतात:

• स्वतःला एक साप्ताहिक सारांश ईमेल. तुम्ही ईमेल एकदा वाचाल, त्यात काय सारांश आहे ते बदलण्याचा निर्णय घ्याल आणि पुढील महिन्यात क्वेरी बदलण्यात घालवाल. या कार्याला मूलतः आठवड्यातून 20 मिनिटे लागली; ऑटोमेशन तयार होण्यासाठी 4 तास आणि देखभाल करण्यासाठी महिन्याला 30 मिनिटे लागतात. कार्य स्वहस्ते करा आणि आपण करत असताना त्याबद्दल विचार करा. - मासिक आकार बदलणारा अहवालाचे स्वरूपन. दर महिन्याला भागधारकाला "फक्त एक स्तंभ" किंवा "यावेळी X द्वारे गटबद्ध" हवा असतो. हे स्वयंचलित करणे म्हणजे हलणारे लक्ष्य स्वयंचलित करणे; देखभाल टर्म वरचढ आहे. स्वरूप सहा महिन्यांसाठी स्थिर होईपर्यंत ते व्यक्तिचलितपणे करा, नंतर स्वयंचलित करा. - स्वतःसाठी एक "उपयुक्त" स्मरणपत्र ज्याकडे तुम्ही दुर्लक्ष कराल. ऑटोमेशन जे वाचक त्यांच्या आउटपुटवर कार्य करतील असे गृहीत धरतात त्यांना त्या आउटपुटवर कार्य करण्याचे वाचकाने आधीच ठरवलेले असणे आवश्यक आहे. जर तुम्ही मानसिक नोटवर कार्य करत नसाल, तर तुम्ही स्वयंचलित आवृत्तीवर कार्य करणार नाही — तुम्हाला फक्त अधिक कार्यक्षमतेने न वागण्याची आठवण करून दिली जाईल.

देखभाल-खर्चाच्या आकाराची चूक

मेंटेनन्स टर्म म्हणजे लोक ज्याचे सर्वात आश्चर्यचकित आहेत, त्यामुळे विशिष्ट यंत्रणेचे नाव देणे योग्य आहे.

ऑटोमेशन मेंटेनन्स "आम्हाला बग फिक्स करावे लागेल" असे नाही. ऑटोमेशनला त्याच्या आजूबाजूला बदलणाऱ्या इतर सर्व गोष्टींशी समक्रमित ठेवण्याची ही सततची किंमत आहे. ठोसपणे, सामान्य लघु-व्यवसाय ऑटोमेशनमध्ये, ज्यामध्ये हे समाविष्ट आहे:

• UI/DOM बदलते जे काही ऑटोमेशन स्पर्श करते. प्रत्येक वेळी तुम्ही ज्या टूलचा विक्रेता निवडक बदलतो, पृष्ठ पुन्हा डिझाइन करतो किंवा बटण हलवतो तेव्हा तुमचे ऑटोमेशन खंडित होते. चांगल्या-डिझाइन केलेल्या API-बॅक्ड ऑटोमेशनवर हे शून्य आहे; UI-स्क्रॅपर ऑटोमेशनवर हा बहुतांश देखभाल खर्च आहे. - API आवृत्ती नापसंत. प्रत्येक 6-24 महिन्यांनी तुमचे अपस्ट्रीम API नवीन आवृत्ती सादर करेल आणि विशिष्ट तारखेला जुनी नापसंत करेल. तुमच्या ऑटोमेशनला त्या तारखेला कोड बदलण्याची आवश्यकता आहे; यादृच्छिक मंगळवारी ऑटोमेशन शांतपणे कसे मरतात हे गहाळ आहे. - क्रेडेन्शियल रोटेशन. OAuth टोकन कालबाह्य होतात. API की फिरवाव्या लागतील. ऑटोमेशन ज्याचे टोकन रविवारी पहाटे 3 वाजता कालबाह्य झाले ते ऑटोमेशन आहे जे सोमवारी सकाळी 10 वाजेपर्यंत कोणीतरी लक्षात आल्यावर कोणतेही आउटपुट तयार करत नाही. रोटेशन स्वतः स्वयंचलित करण्यासाठी बहुतेकदा मूळ ऑटोमेशनपेक्षा अधिक पायाभूत सुविधांची आवश्यकता असते. - डेटा-आकार प्रवाह. स्त्रोत स्प्रेडशीटमधील स्तंभांचे नाव बदलले जाते. तुम्ही पार्स करत असलेल्या अहवालाला नवीन शीर्षलेख पंक्ती मिळते. ग्राहकाचे निर्यात स्वरूप एका स्तंभाने बदलते. प्रत्येक स्त्रोतातील एक छोटासा बदल आणि ऑटोमेशनचा पूर्ण ब्रेक आहे, जो मोठ्याने अपयशी ठरलेल्या प्रतिपादनाद्वारे पकडता येतो. - मूक अपयश. ऑटोमेशन चालते, प्रक्रिया करण्यासाठी काहीही सापडत नाही आणि यशाचा अहवाल देते. ही देखभालीची एक श्रेणी आहे जी मूलत: "तुमच्याशी खोटे बोललेले ऑटोमेशन पकडण्याची किंमत" आहे आणि विशिष्ट निराकरणे the automation failure nobody catches: the workflow that runs green and does nothing मध्ये आहेत.

यापैकी प्रत्येक एक मेंटेनन्स इव्हेंट आहे आणि प्रत्येकाला 30-60 मिनिटांचा खर्च येतो जेव्हा तो हिट होतो. दिलेल्या ऑटोमेशनसाठी तुम्ही यापैकी किती इव्हेंट्सची प्रतिवर्षी अपेक्षा करता ते जोडल्यास, तुमच्याकडे तुमची देखभाल-तासांची आकडेवारी असेल. चांगल्या-डिझाइन केलेल्या API-बॅक्ड ऑटोमेशनसाठी, वर्षातून 4-8 तास. UI-स्क्रॅपिंग ऑटोमेशनसाठी, 20-40 तास. पाच वेगवेगळ्या प्रणालींना स्पर्श करणाऱ्या ऑटोमेशनसाठी, त्यांची बेरीज करा.

तुमच्या तासाच्या खर्चाने गुणाकार करा. ती तुमची देखभाल-खर्चाची मुदत आहे.

काहीही बनवण्याआधी चालायचे पाच प्रश्न

तुम्ही कोडची एक ओळ लिहिण्यापूर्वी (किंवा n8n कॅनव्हासवर नोड टाका, किंवा Zapier zap कॉन्फिगर करा), या पाचही प्रत्येकी एका वाक्यात उत्तर द्या.

१. या कामाला दरमहा किती तास लागतात, प्रामाणिकपणे वेळेवर? "सुमारे एक तास" नाही; तीन वास्तविक वेळेचा मध्यक. महिन्याला 5 तासांपेक्षा कमी असल्यास आणि कोणतीही सामग्री त्रुटी खर्च नसल्यास, येथे थांबा.

२. जेव्हा ऑटोमेशन चुकीचे होते तेव्हा अयशस्वी मोड काय आहे? वर्ग 1 — मला एका तासात लक्षात आले आणि ते दुरुस्त केले, कोणतेही बाह्य नुकसान नाही. वर्ग 2 — मी करण्यापूर्वी ग्राहक लक्षात येईल, परंतु निराकरण जलद आहे. वर्ग 3 - बाहेरील कोणीतरी लक्षात येईपर्यंत नुकसान संयुगे शांतपणे होते. वर्ग 3 ऑटोमेशन जवळजवळ कधीही हाताने करता येण्याजोग्या कार्यांसाठी तयार केले जाऊ नये.

३. ऑटोमेशन कोणत्या अपस्ट्रीम सिस्टमवर अवलंबून असते आणि ते किती वेळा बदलतात? एक API जो वर्षातून एकदा बदलतो ते ठीक आहे. त्रैमासिक पुनर्रचना करणारे पाच UI नाही.

४. रविवारी रात्री 11 वाजता ऑटोमेशन खंडित झाल्यावर ते कोणाच्या मालकीचे आहे? जर उत्तर "कोणीही नाही" किंवा "आम्ही ते शोधून काढू", तर ऑटोमेशन आधीपासूनच बांधकामानुसार वर्ग 3 आहे — तुम्ही कर्मचारी नसलेल्या समर्थन दायित्वामध्ये तुमचा मार्ग स्वयंचलित करत आहात.

५. वाचलेल्या वेळेचे तुम्ही काय करणार आहात? जर "अधिक वेळ द्या" असे उत्तर असेल, तर ऑटोमेशन ही जीवनशैलीची निवड आहे ज्यामध्ये देखभाल बिल संलग्न आहे. जर उत्तर ऑटोमेशनपेक्षा अधिक मौल्यवान एखादी विशिष्ट गोष्ट असेल, तर तुमच्याकडे एक व्यवसाय आहे.

त्या पाचपैकी कोणतेही उत्तर अस्वस्थ असल्यास, ऑटोमेशन अद्याप अस्तित्वात नसावे. असा ठाम दावा आहे; मी ते धरून आहे. प्रश्न 2, 3 किंवा 4 अयशस्वी होणारे कार्य स्वयंचलित करणे तुम्हाला अशा प्रणालीसाठी जबाबदार बनवते जी तुम्ही न निवडलेल्या वेळी तुम्हाला दंश करेल.

चार ऑटोमेशन जे जवळजवळ नेहमीच पैसे देतात

संतुलनासाठी, येथे ऑटोमेशनचे चार आकार दिले आहेत जे अंकगणित सर्वात विश्वासार्हपणे पास करतात, अंदाजे क्रमाने मी ते तयार करण्याची शिफारस करतो.

बॅकअप आणि लॉग फ्लश. उच्च वारंवारता, लहान प्रति-इंस्टन्स खर्च, न केल्यास आपत्तीजनक अपयश खर्च. बिल्ड कॉस्ट लहान आहे, देखभाल खर्च लहान आहे (क्रेडेन्शियल आणि स्टोरेज), आणि ऑटोमॅटिंग न करण्याची अयशस्वी किंमत म्हणजे डिस्क अयशस्वी झाल्याचा दिवस आणि तुम्हाला कळते की तुमचे "नियमित बॅकअप" मार्चमध्ये शेवटचे चालवले गेले होते. प्रथम स्वयंचलित करा.

अनुपालन आणि रेकॉर्ड-कीपिंग. कोणतेही कार्य जे ऑडिट कारणास्तव निश्चित कॅडेन्सवर करावे लागेल — SOC 2 पुरावे संकलन, कर भरणे, सदस्यांच्या संमती नोंदी. ही अशी कार्ये आहेत ज्यांची अयशस्वी किंमत "ऑडिटर पुरावे स्वीकारत नाही" आहे आणि ज्यांच्या देखभाल खर्चास बंधन आहे कारण आवश्यकता स्वतःच स्थिर आहे.

क्रॉस-सिस्टम सामंजस्य. तुलना करणे "जाहिरात प्लॅटफॉर्म X म्हणतो, CRM म्हणते Y, बीजक Z म्हणतो" हे नेमके असे कार्य आहे जिथे मानवी तुलना जोडलेल्या लहान विसंगती चुकवते. उच्च व्हॉल्यूम, त्रुटी खर्च मोजता येण्याजोगा, स्कीमा स्थिर असल्यास देखभाल खर्च कमी.

बाहेरील लोकांसाठी दररोजचे स्कॅन. पूर्ण अहवाल नाही — एक स्कॅन जे सर्व काही सामान्य असताना शून्य आउटपुट तयार करते आणि ते नसताना एक विशिष्ट सूचना तयार करते. "मला दररोज सकाळी पाहण्यासाठी संख्या द्या" ऐवजी "काहीतरी चूक असल्यास मला कळवा" असा हा आकार आहे आणि आउटपुट लहान असल्यामुळे देखभाल टर्म लहान आहे.

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

तुमच्या "गोष्टी मी स्वयंचलित केल्या पाहिजेत" च्या सूचीबद्दल प्रत्यक्षात काय करावे

काहीही तयार करण्यापूर्वी या आठवड्यात दोन व्यायाम करणे योग्य आहे.

व्यायाम 1. तुमची "मला स्वयंचलित करायला पाहिजे अशा गोष्टी" ची यादी घ्या आणि वरील पाच-प्रश्न चाचणीद्वारे प्रत्येकी लिखित स्वरूपात चालवा. प्रश्न 1, 2, किंवा 4 अयशस्वी होणारे कोणतेही, ते ओलांडून टाका. उत्तीर्ण होणारे कोणतेही, "पात्र" यादीमध्ये ठेवा.

व्यायाम 2. प्रत्येक पात्र ऑटोमेशनसाठी, प्रामाणिक चार-मुदतीच्या अंकगणिताची गणना करा — ढोबळ लाभ, वजा अमोर्टाइज्ड बिल्ड कॉस्ट, वजा 25% बिल्ड कॉस्ट प्रति वर्ष देखभाल (प्रश्न 3 वर आधारित 15% किंवा 40% पर्यंत समायोजित करा), वजा अयशस्वी-खर्च अंदाज. निव्वळ वार्षिक मूल्यानुसार रँक. सर्वात वरचा भाग तयार करा, त्यानंतर दुसरा बांधण्याआधी सहा महिन्यांसाठी वास्तविक देखभाल खर्च काढा.

बऱ्याच लोकांच्या "स्वयंचलित करण्याच्या गोष्टी" सूचीमध्ये दहा आयटम आहेत. व्यायाम 1 नंतर ते सहसा चार असते. व्यायाम 2 नंतर ते सहसा दोन असतात, आणि त्यापैकी एकाचा मोबदला अपेक्षेपेक्षा खूपच कमी असतो. तेच प्रामाणिक उत्तर आहे, आणि वीकेंडला काहीतरी तयार करण्याआधी ज्याचा ROI तुम्ही योग्यरितीने मोजला नाही.

मोठे तत्व

व्यवसायाचे मूल्य म्हणजे तुमच्या संदर्भातील कोणीतरी विशिष्ट निर्णय घेऊ शकते. ऑटोमेशन केवळ त्या कार्यांसाठी तयार करणे योग्य आहे ज्यांना त्या संदर्भाची आवश्यकता नसते — ज्या कार्यांमध्ये मशीन, समान इनपुट्स देऊन, सक्षम मनुष्य समान आउटपुट तयार करते. तुमचा संदर्भ आवश्यक असलेल्या कार्याविरुद्ध तुम्ही तयार केलेले प्रत्येक ऑटोमेशन हा एक निर्णय आहे जो तुम्ही तुमच्या स्वतःच्या निर्णयातून काढून टाकला आहे आणि अशा प्रणालीला सोपवला आहे जो एक दिवस चुकीचा होईल अशा प्रकारे तुम्ही सहजपणे दुरुस्त करू शकत नाही.

परिणाम असा आहे की सर्वोच्च-लीव्हरेज ऑटोमेशन, नेहमी, निर्णयाभोवती यांत्रिक कार्य करते जेणेकरुन तुम्हाला निर्णय घेण्यास अधिक वेळ मिळेल. "संपूर्ण गोष्ट स्वयंचलित" नाही तर "निर्णयासाठी आवश्यक असलेले लक्ष वेधून घेणाऱ्या गोष्टीचे भाग स्वयंचलित करा". "चला सर्व काही स्वयंचलित करूया" या महत्त्वाकांक्षेपेक्षा ते खूपच लहान ऑटोमेशन आहे आणि ते जवळजवळ नेहमीच पैसे देते.

हे बाकीच्या कामात कुठे बसते

वरील अंकगणित "मी ते बांधले पाहिजे" हा प्रश्न आहे. तुमचे उत्तर होय असल्यास, पुढील प्रश्न — परिणामी एजंटला किती अधिकार द्यायचे, तो काय करतो याबद्दल काय नोंदवायचे — हे अनुक्रमे deciding what an AI agent is allowed to touch आणि what to log when an AI agent acts on your behalf चे पदार्थ आहेत.

जर तुमची समस्या अशी आहे की तुम्ही अनेक ऑटोमेशन तयार केले आहेत आणि त्यापैकी एक शांत झाला आहे — पाइपलाइन हिरवीगार आहे आणि काहीही तयार करत नाही — निदान आणि निराकरण नमुना the automation failure nobody catches: the workflow that runs green and does nothing मध्ये आहेत. पुढील तयार करण्याचा निर्णय घेण्यापूर्वी वरील अंकगणितामध्ये अपयशाची किंमत जोडा.

वारंवार विचारले जाणारे प्रश्न

मी किती काळासाठी बिल्डची किंमत चुकती करावी?

1.5 वर्षांपेक्षा जास्त, तीन नाही. सरासरी लघु-व्यवसाय ऑटोमेशन खंडित होण्यापूर्वी किंवा बदलण्याआधी अंदाजे अठरा महिने चालते, त्यामुळे दीर्घ कर्जमाफी विंडो अंकगणिताला अशा प्रकारे चापलूस करते की वास्तविकता नाही.

माझ्याकडे ऐतिहासिक डेटा नसल्यास मी किती देखभाल टक्केवारी वापरावी?

प्रति वर्ष बिल्ड खर्चाच्या 25% पासून प्रारंभ करा आणि स्थिर प्रणालीला स्पर्श करणाऱ्या चांगल्या-डिझाइन केलेल्या API-बॅक्ड ऑटोमेशनसाठी 15% पर्यंत समायोजित करा किंवा UI स्क्रॅप करणाऱ्या किंवा एकाधिक अपस्ट्रीम्स पसरलेल्या कोणत्याही गोष्टीसाठी 40% पर्यंत समायोजित करा. Test-automation research तेथे वास्तविक-जागतिक श्रेणी ठेवते आणि शून्य असे गृहीत धरणे ही चूक आहे जी यापैकी अर्ध्या प्रकल्पांना विजयापासून तोट्यापर्यंत फ्लिप करते.

जर मला ते करणे आवडत नसेल तर मी असे कार्य स्वयंचलित करावे का ज्याला महिन्यातून फक्त 3 तास लागतात?

नाही. 5-तास-एक-महिन्याच्या मजल्याच्या खाली, अंतर्निहित प्रणाली स्थिर राहण्यापेक्षा बिल्ड-आणि-देखभाल चक्र परतफेड करण्यासाठी जास्त वेळ घेते, म्हणून तुम्ही वेळेची बचत करण्याऐवजी ऑटोमेशन दुरुस्त करण्यात बहुतेक प्रथम वर्ष घालवाल. ते स्वहस्ते करा किंवा कार्य पुन्हा डिझाइन करा जेणेकरून त्याची अजिबात गरज नाही.

एखादे कार्य ५ तासांपेक्षा कमी वेळ वाचवत असेल परंतु त्रुटीची किंमत जास्त असेल तर?

मग मजला लागू होत नाही — अंकगणित अयशस्वी-खर्च टर्मद्वारे चालविले जात आहे, तास-जतन केलेल्या टर्मद्वारे नाही. बॅकअप, अनुपालन पुरावा आणि क्रॉस-सिस्टम सामंजस्य या सर्व गोष्टी एररच्या खर्चावर खर्च करतात, जरी वाचलेला वेळ कमी असतो, कारण कार्य वगळण्याची किंमत ही संख्या कार्य करते.

मी Zapier वापरावे की कोडमध्ये बनवावे?

रविवारी रात्री 11 वाजता ब्रेक झाल्यावर तुम्ही किंवा तुमच्या टीममधील कोणीही कोणीही सांभाळू शकता. मेंटेनन्स टर्म अंकगणितावर वर्चस्व गाजवते, आणि टीममधील कोणीही एक साधन डीबग करू शकत नाही जे प्रत्येक लहान ब्रेकला मोठ्यामध्ये बदलते — दोन पर्यायांमधील बिल्ड किमतीतील फरकापेक्षा हा एक मोठा घटक आहे.

API आवृत्ती नापसंत किती वेळा माझे ऑटोमेशन खंडित करेल?

प्रति अपस्ट्रीम API प्रत्येक 6 ते 24 महिन्यांनी आवश्यक कोड बदलण्याची अपेक्षा करा, ज्या तारखेला विक्रेता निवडतो आणि तुम्ही करत नाही. तुमचा रिॲलिस्टिक डेप्रिकेशन-चालित देखभाल लोड मिळविण्यासाठी अपस्ट्रीम API ची संख्या त्या कॅडेन्सने गुणाकार करा आणि शीर्षस्थानी क्रेडेंशियल रोटेशन जोडा.

जर कार्य दर महिन्याला आकार बदलत असेल तर काय - तरीही मी ते स्वयंचलित करावे?

नाही, सहा महिने आकार स्थिर होईपर्यंत प्रतीक्षा करा. मूव्हिंग टार्गेट ऑटोमॅट करणे म्हणजे पहिल्या दिवसापासून मेंटेनन्स टर्म वर्चस्व गाजवते कारण तुम्ही हे काम मॅन्युअली केले असते तितक्या वेळा तुम्ही ऑटोमेशनची पुनर्बांधणी करत आहात. इनपुटची स्थिरता ही एक पूर्वअट आहे, चांगली असणे नाही.

एक-वाक्य आवृत्ती

प्रत्येक ऑटोमेशन-आरओआय कॅल्क्युलेटर देखभाल आणि अयशस्वी खर्चाकडे दुर्लक्ष करतो, म्हणून त्यांना स्पष्टपणे जोडा — देखभालीसाठी प्रति वर्ष बिल्ड खर्चाच्या 15-40%, तसेच वास्तविक अपयश-खर्च अंदाज — आणि काहीही बांधण्यापूर्वी 5-तास-प्रति-महिना मजला लागू करा; स्वयंचलित बॅकअप, अनुपालन आणि क्रॉस-सिस्टम सामंजस्य विश्वसनीयपणे करा आणि ज्या कार्यांच्या अपयशी मोडमध्ये तुम्हाला आराम करण्यासाठी रविवारी रात्री 11 वाजता वैयक्तिकरित्या पोहोचणे आवश्यक आहे अशा कार्यांना स्वयंचलित करण्यास नकार द्या.