कस्टम SaaS
आपकी टीम वास्तव में जो काम करती है, उसके लिए सॉफ़्टवेयर।
हम आंतरिक टूल, ग्राहक पोर्टल और SaaS उत्पाद बनाते हैं। किसी परियोजना की शुरुआत ईमेल से आने वाले अनुरोधों, स्प्रेडशीट के बीच बार-बार कॉपी की जाने वाली जानकारी या ग्राहकों के बार-बार स्थिति पूछने से हो सकती है। पहला काम उस कार्यप्रवाह को समझना और यह तय करना है कि उसके किस हिस्से को सॉफ़्टवेयर से बदलना उपयोगी होगा।
क्या बनाना है, यह तय करने से पहले
एक उपयोगी विवरण में काम, उसे करने वाले लोग और कुछ गलत होने पर क्या होता है, यह बताया जाता है। केवल स्क्रीन की सूची पर्याप्त नहीं है।
पहले वास्तविक कार्यप्रवाह
काम कौन शुरू करता है, उसके पास क्या जानकारी होती है और अगला कदम किसे उठाना होता है? अपवादों सहित किसी वास्तविक अनुरोध या काम को देखें।
सबसे छोटा उपयोगी दायरा
कार्यप्रवाह का ऐसा एक हिस्सा चुनें जिसे लोग इस्तेमाल करके परख सकें। तय करें कि क्या मौजूदा टूल में रहेगा और पहली रिलीज़ को किसकी जगह लेनी है।
जो देते हैं उसका संचालन भी करते हैं
इस पर सहमति बनाएँ कि पहुँच, डेटा, सहायता और भविष्य के बदलावों की ज़िम्मेदारी किसकी है। सफलतापूर्वक संचालन शुरू करने के लिए त्रुटियों का पता लगाने और विफलता होने पर बहाल करने का तरीका भी चाहिए।
हम क्या बनाते हैं
आंतरिक टूल से लेकर ग्राहक-सामना करने वाले उत्पादों तक।
01
आंतरिक संचालन टूल
व्यवसाय चलाने वाले लोगों के लिए अनुरोध लेना, काम की कतारें, रिपोर्ट और प्रणालियों को जोड़ना। उपयोगी माप यह है कि क्या टीम हाथ से काम सौंपने की प्रक्रिया कम करके काम पूरा कर सकती है।
02
ग्राहक पोर्टल
ग्राहकों या साझेदारों के लिए जानकारी जमा करने, प्रगति देखने, काम मंज़ूर करने और दस्तावेज़ खोजने की जगह। पहुँच के नियम उस जानकारी के अनुरूप होने चाहिए जिसका उपयोग हर खाते को करने की अनुमति है।
03
SaaS उत्पाद
ग्राहकों के उपयोग के लिए उत्पाद, जिनमें खाते, शुरुआत करने की प्रक्रिया और वे कार्यप्रवाह हों जिनका लोग बार-बार उपयोग करते हैं। शुरुआती सुविधाओं के साथ बिलिंग, सहायता और उत्पाद में बदलावों की योजना भी बननी चाहिए।
कब अपनी ज़रूरत के अनुसार सॉफ़्टवेयर बनाने पर चर्चा उपयोगी है
पहले पहचानें कि मौजूदा टूल कौन-सा काम पर्याप्त रूप से नहीं कर पा रहे हैं। विशेष रूप से बनाए गए सॉफ़्टवेयर के साथ लचीलेपन के अलावा रखरखाव की ज़िम्मेदारियाँ भी आती हैं।
कार्यप्रवाह की बाधाएँ
मैन्युअल चरण, स्प्रेडशीट के दोहराव और हस्तांतरण जो टीम को धीमा करते हैं, आम तौर पर शुरुआत के सबसे तेज़ क्षेत्र होते हैं।
बिखरी हुई प्रणालियाँ
ग्राहक का रिकॉर्ड, भुगतान और सहायता का अनुरोध अलग-अलग प्रणालियों में हो सकते हैं। प्रणालियों को जोड़कर ज़रूरी जानकारी एक साथ लाई जा सकती है, बिना टीम के हर मौजूदा टूल को बदले।
सेवा से सॉफ़्टवेयर में बदलाव
यदि टीम बार-बार वही सेवा प्रक्रिया दोहरा रही हो, तो हम पहले दोहराए जा सकने वाले हिस्सों को उत्पाद बनाने में मदद करते हैं।
ग्राहक अनुभव की कमियाँ
पोर्टल, कार्यप्रवाह की दृश्यता और स्वयं-सेवा सुविधाएँ जटिल सेवा प्रक्रिया को उत्पाद जैसे अनुभव में बदल सकती हैं।
परियोजना का रूप तय करने के तीन उदाहरण
ये सॉफ़्टवेयर के कार्य-दायरे के उदाहरण हैं, पूरे किए गए ग्राहक प्रोजेक्टों के दावे नहीं।
संचालन के काम की साझा जानकारी
एक टीम फ़ॉर्म और ईमेल से अनुरोध प्राप्त करती है, स्प्रेडशीट में उनका हिसाब रखती है और चैट में स्थिति पूछती है। एक आंतरिक टूल हर अनुरोध दर्ज कर सकता है, ज़िम्मेदार व्यक्ति तय कर सकता है, स्थिति दिखा सकता है और इस दौरान लिए गए निर्णय सुरक्षित रख सकता है।
- जब संचालकों को काम, जोखिम और कार्य-निष्पादन का साप्ताहिक दृश्य चाहिए, तब उपयुक्त
- अक्सर अनुरोध लेना, जिम्मेदारी, स्थिति और रिपोर्टिंग एक ही जगह जोड़ता है
ग्राहक या साझेदार पोर्टल
ग्राहक को जानकारी जमा करनी, दस्तावेज़ देखना, किसी चरण को मंज़ूरी देना या प्रगति देखनी होती है। पोर्टल इन कामों को एक जगह ला सकता है, जहाँ अनुमतियाँ तय करती हैं कि प्रत्येक व्यक्ति क्या देख और बदल सकता है।
- अनुमोदन, दस्तावेज़ आदान-प्रदान, समय-सारिणी की दृश्यता और स्वयं-सेवा कार्यों के लिए उपयुक्त
- आम तौर पर ग्राहक का भरोसा और आंतरिक सहायता का बोझ, दोनों बेहतर करता है
बार-बार दी जाने वाली सेवा को सॉफ़्टवेयर के माध्यम से उपलब्ध कराना
एक सेवा टीम हर ग्राहक के लिए एक ही क्रम अपनाती है। सॉफ़्टवेयर दोहराए जा सकने वाले चरण संभाल सकता है, अपवाद दर्ज कर सकता है और विवेक की आवश्यकता वाले निर्णय ज़िम्मेदार लोगों के पास छोड़ सकता है।
- जब एक ही प्रक्रिया बहुत अधिक अंतर के साथ मैन्युअल रूप से दोहराई जा रही हो, तब उपयुक्त
- अक्सर सेवा देने से सॉफ़्टवेयर उत्पाद की ओर पहला ठोस कदम
हम साथ कैसे काम करते हैं
समस्या को समझें, संभाले जा सकने वाले दायरे की रिलीज़ पर सहमति बनाएँ, फिर तय करें कि उसके लिए सहायता कैसे दी जाएगी।
खोज स्प्रिंट
वर्तमान प्रक्रिया का उपयोग करने वाले लोगों के साथ उसे शुरू से अंत तक देखें। उपयोगकर्ताओं, डेटा स्रोतों, अनुमतियों, जुड़ने वाली प्रणालियों, सीमाओं और उस निर्णय को पहचानें जिसे परियोजना से बेहतर बनाना है।
बनाएँ और उपलब्ध कराएँ
क्या शामिल होगा और क्या बाद के लिए रखा जाएगा, इस पर सहमति बनाएँ। टीम के साथ काम कर रहे बदलावों की समीक्षा करें, महत्वपूर्ण कार्यों और विफलता की स्थितियों को परखें, और रिलीज़ तथा पिछली स्थिति में लौटने के चरण तैयार करें।
संचालन
प्रणाली कैसे चलती है और उसका ज़िम्मेदार कौन है, इसे लिखित रूप दें। अगला बदलाव तय करने से पहले त्रुटियों, उपयोग और सहायता से जुड़े सवालों की समीक्षा करें।
आपको क्या मिलता है
ऐसे परिणाम जो उत्पाद को उपयोगी, रखरखाव योग्य और संचालन में आसान बनाए रखें।
उत्पाद और निर्माण
- खोज के नोट्स और दायरे का प्रस्ताव
- छोटे हिस्सों में दिया गया काम करने वाला MVP
- दस्तावेज़ और स्पष्ट हस्तांतरण
संचालन और सुधार
- विश्लेषण योजना और प्रमुख इवेंट
- निगरानी, त्रुटि रिपोर्टिंग और प्रदर्शन बजट
- अगले सुधारों और सहायता के लिए बैकलॉग
आंतरिक टूल से टिकाऊ उत्पाद तक
हमें ऐसे सॉफ़्टवेयर रास्ते पसंद हैं जो वास्तविक उपयोग से शुरू हों और समय के साथ अधिक स्पष्ट उत्पाद के रूप में परिपक्व हों।
कार्यप्रवाह को साबित करें
संचालक की वास्तविक समस्या, सीमित उपयोगकर्ता समूह और पहले व बाद के स्पष्ट परिणाम से शुरुआत करें।
दोहराई जा सकने वाली परत को उत्पाद बनाएँ
कार्यप्रवाह स्थिर होने पर हम UI सरल करते हैं, अनुमतियाँ बेहतर करते हैं और प्रणाली को एक टीम से आगे इस्तेमाल योग्य बनाते हैं।
निरंतर उपयोग के लिए संचालन
उत्पाद के चरण में ध्यान भरोसेमंद कामकाज, शुरुआती उपयोग की सहायता, उपयोग की दृश्यता और सहायता के बोझ को कम करने पर जाता है।
पोर्टफ़ोलियो का संदर्भ
निर्माण से उत्पाद तक की यह सोच NaviVision के व्यापक सॉफ़्टवेयर पोर्टफ़ोलियो में भी दिखती है, जिसमें PickleRickle और PlanAndPlay जैसे उद्यम शामिल हैं।
गुणवत्ता, प्रदर्शन और सुलभता
पहले दिन से संचालकों के अनुकूल बुनियादी विकल्प।
प्रदर्शन
तेज़ पेज, समझदारीपूर्ण कैशिंग और बढ़ने के साथ बंडल छोटे रखने की योजना।
बुनियादी सुरक्षा
न्यूनतम आवश्यक अधिकारों वाली पहुँच, सुरक्षित प्रमाणीकरण तरीके और उपयोगकर्ता डेटा का सुरक्षित प्रबंधन।
सुलभता और SEO
कई भाषाई क्षेत्रों के लिए बना अर्थपूर्ण HTML, फ़ोकस अवस्थाएँ, मेटाडेटा और सामग्री संरचना।
परियोजना शुरू करने के लिए क्या तैयार होना चाहिए
कार्यप्रवाह जानने वाला व्यक्ति, दायरा तय करने वाला व्यक्ति और संबंधित प्रणालियों तक पहुँच।
मैन्युअल काम बदलने वाले संचालक
ईमेल, स्प्रेडशीट और दोहराए जाने वाले समन्वय में उलझी टीमों को केंद्रित आंतरिक प्रणाली से आम तौर पर जल्दी मूल्य मिलता है।
विशेषज्ञता को उत्पाद बनाने वाली सेवा टीमें
जब सेवा के चरण दोहराए जा सकते हों, तो सॉफ़्टवेयर पीछे की विशेषज्ञता को कम किए बिना कार्यप्रवाह मानकीकृत कर सकता है।
ऐसी टीमें जो काम का एक तय हिस्सा सौंपना चाहती हैं
स्पष्ट समस्या और निर्णयों की ज़िम्मेदारी लेने वाला व्यक्ति होने पर दायरे पर सहमति और प्रगति की समीक्षा संभव होती है। यदि आपकी विकास टीम पहले से है, तो बताएँ कि आप हमें कौन-सा हिस्सा सौंपना चाहते हैं और वह उनके काम से कैसे जुड़ता है।
अक्सर पूछे जाने वाले सवाल
कस्टम निर्माण और उत्पाद कार्य के आम सवाल।
क्या आप MVP बनाते हैं या पूर्ण उत्पाद?
दोनों। हम आम तौर पर कार्यप्रवाह और मूल्य साबित करने वाले MVP से शुरुआत करते हैं, फिर टिकाऊ उत्पाद की ओर सुधार करते हैं।
क्या आप हमारी आंतरिक टीम के साथ काम कर सकते हैं?
हाँ। हम आपकी टीम को मज़बूत कर सकते हैं, केंद्रित कार्यधारा संभाल सकते हैं और साफ़ दस्तावेज़ व हस्तांतरण दे सकते हैं।
आप दायरे और समय को कैसे देखते हैं?
दायरा कार्यप्रवाह, प्रणालियों के जुड़ाव, पहुँच की आवश्यकताओं और स्थानांतरित किए जाने वाले डेटा या काम पर निर्भर करता है। काम पूरा करने की योजना तय करने से पहले हम इन पर चर्चा करते हैं। आवश्यकताओं में बदलावों पर स्पष्ट रूप से विचार होना चाहिए, न कि उन्हें चुपचाप उसी समय-सीमा में जोड़ दिया जाए।
हम कैसे शुरू करें?
लक्ष्य, सीमाएँ और समय [email protected] पर भेजें।
कुछ बनाने का विचार है?
काम का विवरण, मौजूदा प्रक्रिया का उपयोग करने वाले लोग और संबंधित टूल बताएँ। यदि किसी वास्तविक आयोजन या घटना के कारण समय-सीमा है, तो उसे शामिल करें। शुरुआती पूछताछ में पासवर्ड, एक्सेस टोकन या ग्राहक रिकॉर्ड न भेजें।
सॉफ़्टवेयर के काम के विवरण में क्या होना चाहिए
एक वास्तविक काम को शुरू से अंत तक समझाएँ। इसमें बताएँ कि उसे कौन शुरू करता है, उसे किस जानकारी की ज़रूरत होती है, वह कौन-से टूल इस्तेमाल करता है और काम कहाँ देर से होता है या दोहराया जाता है। फिर सीमाएँ बताएँ: किसे पहुँच चाहिए, क्या डेटा मौजूदा प्रणाली से ले जाना है, किन प्रणालियों को जोड़ना है और बदलावों की मंज़ूरी कौन दे सकता है। पहले से सॉफ़्टवेयर का डिज़ाइन किए बिना दायरे पर चर्चा शुरू करने के लिए इतना पर्याप्त है।