एका छोट्या प्रोग्रामने 100+ दशलक्ष रूबल/महिना नफ्यासह एका लहान कार्यालयाचे फेडरल कंपनीत रूपांतर कसे केले

डिसेंबर 2008 च्या शेवटी, विद्यमान व्यवसाय प्रक्रिया स्वयंचलित करण्याच्या उद्दिष्टाने मला पर्ममधील एका टॅक्सी सेवेसाठी आमंत्रित केले गेले. सर्वसाधारणपणे, मला तीन मूलभूत कार्ये देण्यात आली होती:


• टॅक्सी चालकांसाठी मोबाईल ऍप्लिकेशनसह कॉल सेंटरसाठी सॉफ्टवेअर पॅकेज विकसित करा आणि अंतर्गत व्यवसाय प्रक्रिया स्वयंचलित करा.
• सर्व काही कमीत कमी वेळेत करायचे होते.
• तृतीय-पक्ष विकसकांकडून खरेदी करण्याऐवजी तुमचे स्वतःचे सॉफ्टवेअर घ्या, जे भविष्यात, व्यवसाय विकसित होत असताना, सतत बदलत्या बाजार परिस्थितीनुसार स्वतंत्रपणे मोजले जाऊ शकते.

तेव्हा हा बाजार कसा चालतो आणि त्यातील बारकावे मला समजले नव्हते, पण तरीही दोन गोष्टी माझ्या लक्षात आल्या होत्या. कॉल सेंटर हे ओपन सोर्स अॅस्टरिस्क सॉफ्टवेअर PBX च्या आधारावर बनवले गेले पाहिजे. कॉल सेंटर आणि मोबाईल ऍप्लिकेशन यांच्यातील माहितीची देवाणघेवाण हे मूलत: क्लायंट-सर्व्हर सोल्यूशन आहे ज्यामध्ये भविष्यातील प्रकल्पाचे आर्किटेक्चर आणि प्रोग्रामिंग डिझाइन करण्यासाठी सर्व संबंधित पॅटर्न आहेत.

प्रकल्पाची कामे, मुदती आणि खर्चाचे प्राथमिक मूल्यांकन केल्यानंतर आणि टॅक्सी सेवेच्या मालकाशी सर्व आवश्यक मुद्द्यांवर सहमती दिल्यानंतर, मी जानेवारी 2009 मध्ये काम सुरू केले.

पुढे बघून, मी लगेच म्हणेन. परिणाम म्हणजे रशियामधील 60 आणि कझाकस्तानमधील 12 शहरांमध्ये 2+ सर्व्हरवर चालणारे स्केलेबल प्लॅटफॉर्म. कंपनीचा एकूण नफा 100+ दशलक्ष रूबल/महिना होता.

पहिला टप्पा. प्रोटोटाइप

त्यावेळेस मला आयपी टेलिफोनीचा कोणताही व्यावहारिक अनुभव नव्हता आणि "होम" प्रयोगांचा भाग म्हणून मी केवळ तारकाशी परिचित होतो, मोबाइल ऍप्लिकेशन आणि सर्व्हरच्या भागाच्या विकासासह काम सुरू करण्याचा निर्णय घेण्यात आला. त्याच वेळी, इतर कार्यांवरील ज्ञानातील अंतर बंद करणे.

जर मोबाईल ऍप्लिकेशनसह सर्वकाही कमी-अधिक स्पष्ट होते. त्या वेळी, हे फक्त साध्या पुश-बटण फोनसाठी जावामध्ये लिहिले जाऊ शकते, परंतु मोबाइल क्लायंटला सर्व्हर देणारा सर्व्हर लिहिणे थोडे अधिक क्लिष्ट होते:

• कोणते सर्व्हर ओएस वापरले जाईल;
• एखाद्या कार्यासाठी प्रोग्रामिंग भाषा निवडली जाते या तर्कावर आधारित, उलट नाही, आणि मुद्दा 1 लक्षात घेऊन, समस्या सोडवण्यासाठी कोणती प्रोग्रामिंग भाषा इष्टतम असेल;
• डिझाइन दरम्यान, सेवेवर अपेक्षित भविष्यातील उच्च भार विचारात घेणे आवश्यक होते;
• कोणता डेटाबेस उच्च भारांखाली दोष सहिष्णुतेची हमी देऊ शकतो आणि विनंत्यांची संख्या वाढत असताना वेगवान डेटाबेस प्रतिसाद वेळ कसा राखायचा;
• विकासाचा वेग आणि कोड पटकन मोजण्याची क्षमता हे निर्णायक घटक होते
• उपकरणांची किंमत आणि भविष्यात त्याची देखभाल (ग्राहकाच्या अटींपैकी एक म्हणजे सर्व्हर त्याच्या नियंत्रणाखाली असलेल्या प्रदेशात असणे आवश्यक आहे);
• प्लॅटफॉर्मवरील कामाच्या पुढील टप्प्यात आवश्यक असलेल्या विकासकांची किंमत;

तसेच डिझाइन आणि विकासाशी संबंधित इतर अनेक समस्या.

प्रकल्पावर काम सुरू करण्यापूर्वी, मी व्यवसाय मालकास खालील धोरणात्मक निर्णय प्रस्तावित केला: प्रकल्प खूपच गुंतागुंतीचा असल्याने, त्याच्या अंमलबजावणीसाठी लक्षणीय वेळ लागेल, म्हणून प्रथम मी एक MVP आवृत्ती तयार करतो, ज्याला जास्त वेळ लागणार नाही आणि पैसे, परंतु जे त्याच्या कंपनीला आधीपासूनच “येथे आणि आता” बाजारात स्पर्धात्मक फायदा मिळवू देईल आणि टॅक्सी सेवा म्हणून त्याची क्षमता देखील वाढवेल. या बदल्यात, असे मध्यवर्ती उपाय मला अधिक विचारपूर्वक अंतिम समाधानाची रचना करण्यासाठी आणि तांत्रिक प्रयोगांसाठी वेळ देईल. त्याच वेळी, अंमलात आणलेले सॉफ्टवेअर सोल्यूशन योग्यरित्या डिझाइन केले जाण्याची हमी दिली जाणार नाही आणि भविष्यात मूलत: पुन्हा डिझाइन किंवा पुनर्स्थित केले जाऊ शकते, परंतु ते "प्रतिस्पर्ध्यांपासून दूर जाण्यासाठी" किमान आवश्यक कार्यक्षमता निश्चितपणे पार पाडेल. टॅक्सीच्या संस्थापकांना ही कल्पना आवडली, म्हणून शेवटी त्यांनी ते केले.

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

तिसर्‍या आठवड्याच्या अखेरीस, काम सुरू केल्यानंतर आणि इंटरनेटवरील स्वारस्याच्या मुद्द्यांचा अभ्यास केल्यानंतर, व्यवसाय मालकाच्या इच्छेनुसार, तसेच त्या वेळी माझे स्वतःचे ज्ञान आणि क्षमता लक्षात घेऊन, खालील स्टॅक लागू करण्याचा निर्णय घेण्यात आला. :

• डेटाबेस सर्व्हर: MsSQL (डेटाबेस फाइल मर्यादा 2GB पर्यंत विनामूल्य आवृत्ती);
• विंडोजच्या अंतर्गत डेल्फीमध्ये मोबाइल क्लायंटला सेवा देणाऱ्या सर्व्हरचा विकास, कारण आधीपासूनच एक विंडोज सर्व्हर होता ज्यावर डेटाबेस स्थापित केला जाईल, तसेच विकास वातावरण स्वतःच जलद विकासाची सुविधा देते;
• 2009 मध्ये मोबाईल फोनवरील इंटरनेटचा कमी वेग लक्षात घेता, क्लायंट आणि सर्व्हरमधील एक्सचेंज प्रोटोकॉल बायनरी असणे आवश्यक आहे. हे प्रसारित डेटा पॅकेट्सचा आकार कमी करेल आणि परिणामी, सर्व्हरसह क्लायंटच्या कार्याची स्थिरता वाढवेल;

प्रोटोकॉल आणि डेटाबेस डिझाइन करण्यासाठी आणखी दोन आठवडे गेले. परिणाम म्हणजे 12 पॅकेजेस जे मोबाइल क्लायंट आणि सर्व्हर आणि डेटाबेसमधील सुमारे 20 टेबलमधील सर्व आवश्यक डेटाची देवाणघेवाण सुनिश्चित करतात. मी कामाचा हा भाग भविष्याचा विचार करून केला आहे, जरी मला तंत्रज्ञानाचा स्टॅक पूर्णपणे बदलायचा असला तरी, पॅकेजेस आणि डेटाबेसची रचना अपरिवर्तित राहिली पाहिजे.

तयारीच्या कामानंतर, कल्पनेची व्यावहारिक अंमलबजावणी सुरू करणे शक्य झाले. प्रक्रियेला थोडा वेग देण्यासाठी आणि इतर कामांसाठी वेळ मोकळा करण्यासाठी, मी मोबाइल ऍप्लिकेशनची एक मसुदा आवृत्ती बनवली, UI, अंशतः UX, स्केच केले आणि प्रोजेक्टमध्ये एका परिचित जावा प्रोग्रामरचा समावेश केला. आणि त्याने सर्व्हर-साइड विकास, डिझाइन आणि चाचणीवर लक्ष केंद्रित केले.

MVP वर कामाच्या दुसऱ्या महिन्याच्या शेवटी, सर्व्हर आणि क्लायंट प्रोटोटाइपची पहिली आवृत्ती तयार होती.

आणि तिसऱ्या महिन्याच्या अखेरीस, सिंथेटिक चाचण्या आणि फील्ड चाचण्या, दोष निराकरणे, प्रोटोकॉल आणि डेटाबेसमध्ये किरकोळ सुधारणा केल्यानंतर, अनुप्रयोग उत्पादनासाठी तयार होता. जे केले होते.

या क्षणापासून प्रकल्पाचा सर्वात मनोरंजक आणि सर्वात कठीण भाग सुरू होतो.

नवीन सॉफ्टवेअरमध्ये ड्रायव्हर्सच्या संक्रमणादरम्यान, 24-तास ड्युटी आयोजित करण्यात आली होती. दिवसभरात कामाच्या वेळेत सगळ्यांना येणं शक्य नसल्यामुळे. याव्यतिरिक्त, प्रशासकीयदृष्ट्या, कंपनीच्या संस्थापकाच्या दृढ-इच्छेने निर्णय घेऊन, ते अशा प्रकारे आयोजित केले गेले की लॉगिन/पासवर्ड टॅक्सी सेवेच्या व्यवस्थापकाद्वारे प्रविष्ट केला गेला आणि ते ड्रायव्हरला कळवले गेले नाहीत. माझ्या बाजूने, अपयश आणि अनपेक्षित परिस्थितीत वापरकर्त्यांसाठी तांत्रिक समर्थन आवश्यक होते.

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

मोबाईल ऍप्लिकेशनचे आर्किटेक्चर सोपे होते आणि सर्व्हरच्या तुलनेत त्यात लक्षणीय कमी बग होते. त्यामुळे कामाचा मुख्य भर सर्व्हरच्या बाजूने होता. फोनवरील इंटरनेट हरवल्यावर आणि सत्र पुन्हा पुनर्संचयित केल्यावर सर्व्हरवरून डिस्कनेक्शनची समस्या ही अनुप्रयोगातील सर्वात गंभीर समस्या होती. आणि इंटरनेट बरेचदा गायब झाले. प्रथम, त्या वर्षांत फोनवर इंटरनेट पुरेसे स्थिर नव्हते. दुसरे म्हणजे, असे बरेच आंधळे स्पॉट होते जिथे इंटरनेट फक्त कार्य करत नव्हते. आम्ही ही समस्या जवळजवळ तात्काळ ओळखली आणि 24 तासांच्या आत पूर्वी स्थापित केलेले सर्व अनुप्रयोग निराकरण आणि अद्यतनित केले.

सर्व्हरमध्ये प्रामुख्याने ऑर्डर वितरण अल्गोरिदममध्ये त्रुटी होत्या आणि क्लायंटच्या काही विनंत्यांची चुकीची प्रक्रिया होती. त्रुटी ओळखल्यानंतर, मी सर्व्हर दुरुस्त केला आणि अद्यतनित केला.

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

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

येथे टॅक्सी सेवांचे संचालक आणि फोरमन यांचे अमूल्य सहाय्य लक्षात घेणे आवश्यक आहे, ज्यांनी ड्रायव्हर्सना नवीन सॉफ्टवेअरमध्ये स्थानांतरित करण्याच्या परिस्थितीची जटिलता जास्तीत जास्त समजून घेऊन, चोवीस तास ड्रायव्हर्ससह काम केले. खरं तर, फोनवर नवीन प्रोग्राम्सची स्थापना पूर्ण केल्यानंतर, आम्ही एकही ड्रायव्हर गमावला नाही. आणि त्यांनी क्लायंट न काढण्याच्या टक्केवारीत गंभीरपणे वाढ केली नाही, जी लवकरच सामान्य स्तरावर परत आली.

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

पुढे चालू..

स्त्रोत: www.habr.com