👓 🕗 🏭 निगम के अंदर स्टार्टअप 🌒 🚘 👷🏼

नमस्ते, मेरा नाम एंड्री वैनिन है और मैं ब्रोकरेज और फिनटेक उत्पादों को विकसित और लॉन्च कर रहा हूं। आज ठीक एक साल है जब मैं बीसीएस में काम करता हूं, जहां आठ लोगों की टीम में हम fintarget.ru प्रोजेक्ट विकसित कर रहे हैं।

नीचे एक बड़ी कंपनी में स्टार्टअप को लागू करने के तरीके के बारे में एक (नहीं) बड़ी कहानी है, इसे बाजार में जारी करें और एक ही समय में मेमो और अनुमोदन के टन के बीच जला नहीं करें।

पहचान

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

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

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

तुम्हारे प्राप्तांक पर

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

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

लेकिन समय सीमा की घोषणा की गई - सितंबर में रिलीज करने के लिए। और हम काम करने बैठ गए।

डबल धुरी

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

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

लगभग तुरंत, समग्र चित्र के स्तरीकरण की समस्या उत्पन्न हुई - विपणन को पता नहीं था कि हम तकनीकी रूप से क्या कर रहे थे, और डेवलपर्स को यह समझ में नहीं आया कि यह सब कैसे दिखना चाहिए था। मई की छुट्टियों से पहले, हमने पहले संगम खोला और स्क्रीन का वर्णन करने के लिए बैठ गए।

मध्य मई तक, उत्पाद और मेरे सिर पर केवल एल्गोरिदम और स्क्रीन का वर्णन करने वाले लगभग पचास पृष्ठों में कैसे काम करना चाहिए, इसकी विस्तृत समझ है। यह एक बड़ा जोखिम था (पेशेवरों द्वारा चाल चली गई थी! दोहराएं नहीं - यह खतरनाक है!), लेकिन एक ही समय में टीम के प्रत्येक सदस्य को पता था कि क्या करना है और दो महीने पहले काम के साथ लोड किया गया था।

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

हालाँकि, लगभग तुरंत यह स्पष्ट हो गया कि हम आंतरिक वेब सर्किट में भी फिट नहीं हो पाएंगे, और ग्राहक उस समय एकमात्र बचत समाधान पर सहमत थे - हम अपनी ब्रांडिंग और समर्थन टीम के साथ अपने स्वयं के वेब-आधारित उत्पाद मोर्चा बनाते हैं। विभाग के अंदर, हमने जल्दबाजी में उत्पाद के नाम के लिए एक प्रतियोगिता की घोषणा की और आखिरकार उस विकल्प को चुना जो पहले से ही आवाज उठा रहा था, क्योंकि मेरे व्यक्तिगत गुल्लक में एक अच्छा डोमेन था, और सभी के लिए मतदान और रचनात्मक करने के लिए बेहतर कुछ भी नहीं था। तो ब्रांड fintarget.ru दिखाई दिया। और वह दूसरा, महत्वपूर्ण मोड़ था।

टीम के बारे में

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

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

सितारे एक साथ आए और हम रिश्तों की एक श्रृंखला खोजने में कामयाब रहे, जिसमें प्रत्येक और हर किसी के पास काम के अलावा कुछ और बात करने के लिए हमेशा कुछ था। और जब आपने संचार का निर्माण किया है - आप शांति से भूमिकाओं के वितरण से निपट सकते हैं।

डिबगिंग टीम प्रक्रियाओं के चरण में, हमने ऐसी हाइब्रिड योजना बनाई है कि यह किसी भी मौजूदा टेम्पलेट में फिट नहीं होती है।

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

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

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

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

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

तीन महीने के लिए इस परियोजना के नायक ने एक दर्जन से अधिक विभिन्न सेवाओं का खर्च किया, एक दर्जन नई प्रक्रियाओं का वर्णन और दस्तावेज किया, और यह वह था जिसने बड़ी कंपनियों के भीतर स्टार्टअप बनाने की असंभवता के लोकप्रिय सिद्धांत का खंडन किया।

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

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

घटना के पेड़

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

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

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

इस कहानी के विवरण में एक अलग लेख है, लेकिन जो कुंजी हासिल की गई है, उसमें कई बिंदु शामिल हैं:

. « – – crm– – – – », , ,
- « - », « » .
"प्रीप्रोड" परीक्षण दृष्टिकोण ने डेवलपर्स की भागीदारी में बहुत वृद्धि की है, जिससे बाहरी दुनिया में उत्पाद को जारी करने से पहले UX का परीक्षण करना संभव हो गया है और परियोजना के लिए सबसे महत्वपूर्ण बात, वास्तविक बाजार और क्लाइंट डेटा पर सिस्टम एल्गोरिदम के सही संचालन को डिबग करना है।

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

इसका परिणाम क्या है

परियोजना के कामकाजी एमवीपी को अगस्त के अंत में इकट्ठा किया गया था, समानांतर में, NAUFOR में कार्यक्रम को मान्यता देने के लिए एमुलेटर का एक संस्करण लागू किया गया था और सॉफ्टवेयर के पंजीकरण के लिए सहायक दस्तावेज के एक सौ पचास पृष्ठ लिखे गए थे। 31 अगस्त को टीम के हर्षित चीखों के लिए सिस्टम पर पहला वास्तविक लेनदेन हुआ। कंपनी के दस्तावेजों और ग्राहक नियमों में कानूनी बदलाव 1 सितंबर को लागू हुए, और सिस्टम को मान्यता मिलने से पहले, हमारे पास इंटरफेस को डिबग करने और चाटने का समय था।

एमवीपी में, हमारे पास न तो मुद्रा खाते थे, न ही वायदा, और न ही हमारे स्वयं के ब्रोकरेज खाते, लेकिन मुख्य कार्य पूरा हो गया था - बुनियादी ढांचे को लागू किया गया था, प्रीप्रेड एक ठेस बन गई, ग्राहक सेवा लागू की गई।

17 सितंबर को, फ़िन्टरगेट सॉफ़्टवेयर को मान्यता प्राप्त ऑटो-फॉलो कार्यक्रमों के रजिस्टर में जोड़ा गया था, और अगले दिन हमने पहले ग्राहकों को सिस्टम से जोड़ा। कार्यक्षमता का विस्तार करने और MVP को पूर्ण विकसित और आत्मनिर्भर उत्पाद की स्थिति में लाने के लिए अभी भी बहुत काम किया गया था, लेकिन यह पूरी तरह से अलग और कम दिलचस्प कहानी है: रिलीज़, स्प्रिंट, बैकलॉग और अंतहीन क्लाइंट एनालिटिक्स।