खुशी का औद्योगिक उत्पादन

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

शायद किसी के लिए मैं इस तरह दिखूंगा:

कार्य अनुभव के बारे में

2003 के अंत में, एक तरफ, मुझे एहसास हुआ कि मुझे वास्तव में विकास की सच्ची प्रथा की कमी थी, क्योंकि एक शिक्षण और सीखने के कार्य उद्योग के जीवन की पूरी तस्वीर प्रदान नहीं करते हैं, दूसरी तरफ, कमाई का सवाल सीधा उठता है। प्रोग्रामिंग शिक्षकों के जीवन से अलगाव की समस्या पहले से सभी को पता है। यह प्रोग्रामर के बीच धारणा के कारणों में से एक है कि विश्वविद्यालय में अध्ययन बिल्कुल बेकार है और आपको बस काम करना शुरू करना होगा। मैं इस विषय पर लंबे समय तक बात कर सकता हूं, इसलिए अब मैं सिर्फ इतना कहूंगा: मैं इस राय से सहमत नहीं हूं, और बाद में चर्चाओं को छोड़ दें। मैंने तय किया कि मुझे जाना है, अभ्यास में अनुभव हासिल करना है और फिर अकादमिक शिक्षा और उद्योग की जरूरतों के बीच अंतर को पाटने के लिए पहले से ही ज्ञान का एक निश्चित निकाय रखने वाले विश्वविद्यालय में वापस आना है।
यह इस तथ्य में व्यक्त किया गया था कि 2009 के बाद से मैं "आधुनिक सॉफ्टवेयर विकास प्रथाओं" के हकदार 3-5 वर्ष के छात्रों के लिए ओम्स्क स्टेट यूनिवर्सिटी में एक विशेष पाठ्यक्रम पढ़ रहा हूं, जहां मैं उन्हें अभ्यास में कई ऐसे कौशल सिखाता हूं जो वास्तविक कार्य में आवश्यक होते हैं और जिनमें ताजा स्नातकों की कमी होती है वे अपनी पहली नौकरी की तलाश में हैं। विशेष रूप से, ये हैं: टीमवर्क, विकास प्रक्रियाएं, उपकरण (संस्करण नियंत्रण प्रणाली, स्वचालित विधानसभाएं, कार्य ट्रैकर, निरंतर एकीकरण)। उच्च-गुणवत्ता कोड, उचित दस्तावेज और लॉगिंग, यूनिट परीक्षण आदि लिखने पर बहुत ध्यान दिया जाता है। पाठ्यक्रम के हिस्से के रूप में, छात्र जावा, पायथन और रूबी में विभिन्न वेब फ्रेमवर्क का उपयोग करते हुए 2-3 लोगों के लिए एक टीम प्रोजेक्ट करते हैं, जिसकी हम रास्ते में तुलना भी करते हैं।
इसलिए, 2003 में, मैंने ओम्स्क स्टेट यूनिवर्सिटी को छोड़ दिया और तेल और गैस पाइपलाइनों के डिजाइन में लगी एक सफल कंपनी के सॉफ्टवेयर डेवलपमेंट विभाग में नौकरी पा ली, जहाँ मैं आंतरिक काम के स्वचालन में लगा हुआ था।
ओम्स्क में उस समय यह सबसे बड़े करदाताओं में से एक था। इसके अलावा, आंतरिक स्वचालन के लिए सॉफ्टवेयर के विकास के लिए 2 बड़े विभाग थे। उनमें से एक ने एक बाहरी ग्राहक के लिए सॉफ्टवेयर भी विकसित किया - ट्रांसनेफ्ट। वहां मुझे पता चला कि कर्मियों पर ध्यान देने के साथ आंतरिक नीति क्या है और यह कैसे उन लोगों के लिए नियंत्रण के हस्तांतरण के साथ ढह जाता है, जिन्होंने एक कंपनी नहीं बनाई थी, लेकिन बस एक मौजूदा कंपनी में निवेश किया था, एक नियंत्रित हिस्सेदारी प्राप्त की थी। बहुत बाद में दी मार्को और लिस्टर की किताब "द ह्यूमन फैक्टर" को पढ़कर, मैं आंसुओं के माध्यम से हँसा जब उन्होंने एक ऐसी ही स्थिति का वर्णन किया जहाँ पूरी तरह से लोगों को छोड़ दिया, और जिन लोगों ने अभी भी नहीं छोड़ा है और सोचते हैं: "हर कोई पहले ही छोड़ चुका है, मैं अकेला हूँ मैं अभी भी एक बेवकूफ हूँ, मैं जाऊँगा और छोड़ भी दूँगा, और एक नीली लौ के साथ जलूँगा। ”
2009 में, बड़ी संख्या में उत्कृष्ट डिजाइन विशेषज्ञों और सर्वेक्षकों के प्रस्थान की पृष्ठभूमि के खिलाफ - कंपनी की नींव - मुझे एक नवजात आउटसोर्सिंग कंपनी में काम करने का प्रस्ताव मिला, जिसमें उस समय 10 से कम लोग शामिल थे।
मैं वहां तीसरा डेवलपर था। मैं तुरंत थोड़ा चिंतित था कि केवल 3 डेवलपर्स थे, लेकिन कर्मचारियों पर, सामान्य निदेशक के अलावा, एक वकील, बाज़ारिया, कार्मिक अधिकारी, एकाउंटेंट और परियोजना प्रबंधक था। दुर्भाग्य से, अंत में इस कार्यालय का दुखद इतिहास इसके पूरे अस्तित्व में समान वितरण के साथ जुड़ा हुआ है।


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


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


कभी-कभी इस तरह भी:


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

समस्या के बारे में

मेरी टीम और मैं नियमित रूप से मास्को, नोवोसिबिर्स्क, येकातेरिनबर्ग और समारा में विभिन्न आईटी सम्मेलनों में भाग लेते हैं। और हाल ही में, मुझे एक प्रश्न से पीड़ा होने लगी कि मैं एक वक्ता से पूछना चाहता हूं जो विकास प्रक्रिया के सामान्य दृष्टिकोणों के बारे में बात करता है, प्रौद्योगिकियों के संयोजन के कुछ प्रकार के आवेदन के बारे में। आदि: "ठीक है, यह सब बहुत अच्छा है, लेकिन आपने ग्राहक के लिए क्या समस्या हल की है?"
कोडफेस्ट -2018 मैक्सिम तकाचुक वाला स्पीकर अपनी रिपोर्ट "हार्ड रॉक डिजाइन" कोडफेस्ट .ru/program/2012-03/hard-rock-design के साथ समाप्त हुआ । यह एक अफ़सोस की बात है कि उनकी रिपोर्ट की घोषणा पीएम + एचआर सेक्शन में की गई थी और न ही सभी डेवलपर्स जो उनकी बात सुनने आए थे, बल्कि ज्यादातर मैनेजर और डिज़ाइनर थे। और उन्होंने इस तथ्य के बारे में बात की - अपने घंटी टॉवर से, निश्चित रूप से - कि डिजाइनर को परियोजना पर काम करने की पूरी प्रक्रिया में भाग लेना चाहिए, आवश्यकताओं के प्रारंभिक संग्रह से शुरू करना, एक सक्रिय स्थिति लेना, विकसित उत्पाद और उपयोगकर्ताओं (उपभोक्ताओं) के दर्शकों के उद्देश्य को गहराई से समझना चाहिए। उन्होंने बहुत भावनात्मक रूप से बात की, यह महसूस किया गया कि समस्या का सामना करना पड़ा और लगातार ऐसे डिजाइनरों से निपटना पड़ा जो इसे नहीं समझते हैं। और मैं हॉल में बैठ गया और मानसिक रूप से "डेवलपर" शब्द को "डेवलपर", "परीक्षक", आदि में बदल दिया।

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

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

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

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

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

जीवन के किस्से

उपरोक्त वर्णन करने के लिए, मैं आपको कुछ परियोजनाओं के बारे में बताऊंगा जिन्हें मुझे डेवलपर या प्रबंधक के रूप में काम करना था।
इसलिए, कंपनी ट्रंक पाइपलाइनों के डिजाइन में लगी हुई है। सॉफ्टवेयर विकास विभाग को पारिस्थितिकी विभाग के लिए एक छोटा सा कार्यक्रम लिखने का काम दिया गया था। स्रोत डेटा:

• ओ विभाग जहां हर कोई Borland C ++ बिल्डर पर डिजाइन और सर्वेक्षण कार्य के स्वचालन के लिए डेस्कटॉप एप्लिकेशन लिखता है;
• o एक नवागंतुक जो अभी बस गया है और बहुत जटिल डेस्कटॉप एप्लिकेशन नहीं लिख सकता है;
• o पारिस्थितिकी विभाग, जो एक्सेल तालिकाओं के एक सेट का उपयोग करके निर्माण कार्य के दौरान प्रदूषक उत्सर्जन की गणना करता है।

थोड़ा और विभाग के बारे में:


3 डी योजनाओं (ओपनजीएल और जो पहले से ही यार्ड में है) में 2 डी ग्राफिक्स का एक अलग पुस्तकालय लिखा गया था। मेमोरी में डेटा संग्रहीत करने की अपनी स्वयं की चालाक संरचना लिखी गई है - एक लिंक की गई सूची के संयोजन का एक प्रकार और सीधी पहुंच के साथ एक संरचना, अर्थात्। सरणी। उपयोग के लिए, एक बहुत ही निम्न-स्तरीय दृष्टिकोण का उपयोग किया जाता है, न केवल गर्भपात में, बल्कि एपीआई स्तर पर भी ठोस पता अंकगणित में कोई सार नहीं है। एक ग्रिड लिखा जाता है, जो इनपुट में मेमोरी में एक पता प्राप्त करता है और इस शुरुआत के बारे में पता गणनाओं का उपयोग करके अपने सभी डेटा लेता है। 1 बाइट के अंदर कहीं शिफ्ट होने से सब कुछ नष्ट हो जाता है। अधिकांश महाकाव्य इसका नाम है: "myGrid"।
एक युवा सेनानी के लिए - अर्थात मेरे लिए - वे बिल्डर पर भविष्य के कार्यक्रम के घटकों के रूप में यह सब उपयोग करने का प्रस्ताव करते हैं, जो एक्सेलस गणना की वर्तमान चिड़ियाघर को बदल देगा। ग्राहक - चाची 45 और ऊपर (बॉस) और लड़कियों के बारे में 25 (साधारण कलाकार) - विशेष रूप से गणना की श्रेणियों में सोचते हैं, जिसे वे असंबंधित भागों के रूप में समझते हैं और उनके दृष्टिकोण से, विकास वृद्धिशील है - गणना एक-एक करके दोहराई जाती है और लगभग ले जाती है उसी समय
लगभग एक महीने, मैंने ईमानदारी से बिल्डर पर सब कुछ किया, मेगा-ग्रिड के माध्यम से दर्ज किया गया डेटा मेमोरी में मेगा-स्ट्रक्चर में गिर गया, जिसे जब डिस्क पर सहेजा गया तो बस बाइनरी फ़ाइल में गिरा दिया गया और फिर फाइल से मेमोरी में पढ़ने के दौरान गुलाब हो गया। लेकिन मैंने विद्रोह कर दिया। उसने विभाग के प्रमुख को बताया कि कार्य में खुले तौर पर एक डेटाबेस का उपयोग शामिल है - विशेष रूप से आवश्यक बहु-उपयोगकर्ता मोड पर विचार करना। एक और महीने की लड़ाई और मुझे अनुमति मिल गई। वे जावा + ओरेकल में एक कॉर्पोरेट सूचना प्रणाली (सीआईएस) बनाने वाले थे, और मुझे इस सीआईएस के हिस्से के रूप में सिस्टम बनाने का अवसर मिला।
जितना अधिक मैं कार्य में डूब गया, उतना ही मुझे एहसास हुआ कि गणना न केवल परस्पर जुड़ी हुई थी, बल्कि अधिकांश भाग के लिए डेटा उनके लिए विभिन्न मानक और संदर्भ पुस्तकों में था, या वे अन्य विभागों के कर्मचारियों से आए थे। इस बात की समझ थी कि वास्तव में किस प्रकार के पारिस्थितिक तंत्रविदों की जरूरत है और यह थोड़ा ऐसा दिखता है जैसा उन्होंने बताया। मैं उनके विभाग में अटक गया, ऐसे सवाल पूछे जो मुझे दिए गए गणना के ढांचे से बहुत आगे निकल गए, परिणामस्वरूप, धीरे-धीरे मैंने पूरे संस्थान के यांत्रिकी में विलम्ब कर दिया।
मैंने वही किया जो उन्हें वास्तव में चाहिए था, जितना उन्होंने पूछा था, उससे कहीं अधिक, लेकिन शुरुआत में जितना चाहिए था, उससे कहीं अधिक समय लगा। बाकी के लिए मूल गणना के साथ पहले संस्करण के लिए छह महीने और पूरा करने के लिए 2.5 साल। इस समय के दौरान, मुझे पहले 1-2 महीनों में एक दृश्यमान परिणाम की कमी के लिए लगभग निकाल दिया गया था (मैं पहले से ही याद नहीं है) और विभाग के प्रमुख और तत्कालीन आईटी निदेशक, जो प्रोग्रामर से नहीं थे, लेकिन डिजाइन इंजीनियरों से संबंध खराब थे।
फिर मैंने अपने वरिष्ठों की दहलीज को ऊंचा करना शुरू कर दिया, स्वचालन की प्रक्रिया शुरू करने और अनुसंधान और डिजाइन की पूरी प्रक्रिया का एक मॉडल बनाने की कोशिश कर रहा था, क्योंकि उस समय, जैसा कि मैंने सोचा था, मैं व्यावहारिक रूप से एकमात्र व्यक्ति था जिसने इनपुट और आउटपुट डेटा प्रवाह के संदर्भ में संस्थान के सभी विभागों के काम का अध्ययन किया। परियोजना के डिजिटल मॉडल के स्तर पर। एक सीआईएस विभाग भी था, लेकिन वे पाठ दस्तावेजों के प्रकारों में अधिक रुचि रखते थे, और ड्राइंग को साधारण बाइनरी फाइलें माना जाता था। मेरे लिए, मुख्य एक मॉडल था, और सभी ड्रॉइंग और टेक्स्ट डॉक्यूमेंट केवल ऐसी रिपोर्टें थीं, जिन्हें किसी भी समय मॉडल बनाया जा सकता है।
परिणामस्वरूप, यह वैश्विक प्रणाली नौकरशाही और आर्थिक कारणों के एक समूह के कारण कभी प्रकट नहीं हुई, और मैंने छोड़ दिया। वैसे, इस प्रक्रिया का टुकड़ा-टुकड़ा स्वचालन अन्य डिजाइन संस्थानों में उपलब्ध है, और आईटी कंपनियों में से एक वाणिज्यिक उत्पाद पर पैसा बनाती है जो कि इसके बारे में मेरे अंतिम ज्ञान के समय कवर किया गया था (2010) 60 प्रतिशत जो मैंने 2006 में कल्पना की थी। सर्वेक्षण कार्य (जियोडेसी, जियोलॉजी, आदि) को कवर करने वाले कई उत्पाद हैं जो अंदर मॉडल का उपयोग करते हैं, और ऑटोकैड प्रारूप में एक रिपोर्ट के रूप में चित्र प्राप्त करते हैं। लेकिन, दुर्भाग्य से, पाइपलाइन के डिजाइन में उनकी कोई निरंतरता नहीं है।

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

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

आदर्श गोलाकार डेवलपर को वैक्यूम में क्या करना चाहिए:
1. विभाग के एक साधारण कर्मचारी के मूल जस्कि को स्वयं करने के लिए अंदर से सभी प्रक्रियाओं का अध्ययन करने के लिए कुछ समय के लिए विभाग को पूरी तरह से डुबो कर व्यावसायिक डोमेन का अध्ययन करके शुरू करें।
2. एक सप्ताह के भीतर, अधिकतम दो, विजुअल बेसिक में कई मैक्रोज़ लिखें, जो दूसरों के लिए स्रोत डेटा के रूप में कुछ गणनाओं के परिणामों का उपयोग सुनिश्चित करेंगे, साथ ही साथ एक्सेल में सबसे अधिक बार उपयोग की जाने वाली निर्देशिकाओं को डिजिटाइज़ करेंगे, जो एक तिहाई के बारे में काम का त्वरण देगा।
3. पास में पहले से ही आंशिक रूप से खुश ग्राहक होने के नाते, शांति से एक वास्तविक प्रणाली विकसित करें, पहले से ही सभी जूसकी और मुख्य जोखिमों को समझें, जो विकास प्रक्रिया को एक तिहाई से भी कम कर देगा।
पहली नज़र में, उदाहरण ऊपर वर्णित समस्या और लक्षणों में फिट नहीं होता है। दूसरी नज़र में, यह जिस तरह से है। चूंकि ग्राहक की समस्याओं और सर्वोत्तम संभव तरीके से उन्हें हल करने के प्रयासों का अध्ययन करने के लिए एक डेवलपर की उपस्थिति बहुत प्रेरित थी (इसके अलावा मैक्रोज़ के साथ प्रारंभिक त्रुटि, उनकी अनुपस्थिति के साथ और अधिक सटीक रूप से)। समस्या यह है कि हर कोई जो आसपास था, कंपनी में समग्र स्थिति में सुधार करने के लिए पूरी तरह से प्रेरित नहीं था। सवाल यह है कि क्या मुझे वास्तव में किसी और की ज़रूरत है जिसे मैंने नियमित रूप से सुना। और एक बिंदु पर, धैर्य तड़क गया।

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

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

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

प्रबंधक को पता था कि हमारे पास एक बड़ा तकनीकी जोखिम है - वीडियो रिकॉर्डिंग और स्ट्रीमिंग। गंभीर चिंताएं थीं कि एक महीने में डेवलपर के पास मुख्य कैमरों के स्वरूपों का अध्ययन करने और ग्राहक को वीडियो स्ट्रीम रिकॉर्ड करने की संभावना प्रदर्शित करने के लिए कुछ सुपाच्य लिखने के लिए समय नहीं होगा। इसलिए, उन्होंने आशा व्यक्त की कि मैं जल्दी से व्यवस्थापक पैनल को रिवाइव करूंगा, जिसका उपयोग ग्राहकों की आंखों को धुंधला करने के लिए किया जा सकता है, उन्हें टिप्पणियों और इच्छाओं से दूर किया जाएगा और थोड़ी देर के लिए वीडियो के बारे में भूल जाएंगे, जिससे दूसरे डेवलपर को पैंतरेबाज़ी करने का समय मिलेगा।
हालाँकि, ये सभी विचार केवल प्रबंधक के दिमाग में थे। डेवलपर्स ने समय सीमा - 3 महीने देखी - और विशेष रूप से चिंतित नहीं थे। हम व्यावहारिक रूप से ग्राहक के साथ व्यक्तिगत रूप से संवाद नहीं करते हैं; प्रबंधक इसमें लगे हुए थे। आदेश के रूप में हमारे पास जानकारी पहले से ही पहुंच गई थी, जिसके साथ हमने तर्क दिया और कुछ स्थानों पर प्रबंधक द्वारा निर्धारित समय सीमा में देरी करते हुए इसे अपने तरीके से किया। हम निश्चित रूप से कुल समय सीमा (प्लस या माइनस) को पूरा करेंगे। लेकिन हमारे पास वादा किए गए महीने के बाद कोई भी कार्य प्रणाली नहीं थी, क्योंकि मैं और दूसरा डेवलपर दोनों अपने लक्ष्य का पीछा करते थे, ग्राहक की बहुत देखभाल नहीं करते थे - हमारे लिए वह सिर्फ एक स्काइप और ईमेल था। इसलिए, मैंने अपने लिए एक पत्थर से दो पक्षियों को मारने के लिए एक नया ढांचा विकसित करने का विकल्प चुना। प्रबंधक ने इस मामले को नहीं रोका, हालांकि उन्हें संदेह था कि मेरे पास अध्ययन के साथ समय सीमा को पूरा करने का समय नहीं होगा।
नतीजतन, ग्राहक की नजर में संपूर्ण रूप से प्रबंधक और कंपनी का अधिकार बहुत हिल गया, संचार में व्यवधान शुरू हो गया और पहले मौद्रिक किश्त स्थगित हो गई।
कोई कह सकता है कि समस्या एक उचित विकास प्रक्रिया की कमी है। यह एक घोटाला होगा और खुशी आएगी। हालाँकि, यहाँ बिंदु अभी भी प्रक्रिया या उसकी अनुपस्थिति नहीं है - हमारे पास किसी भी स्वीकृति मानदंड के साथ वर्णित ढलान के साथ पुनरावृत्तियाँ थीं - तथ्य यह है कि हमने ग्राहक की समस्या को एक साथ हल नहीं किया है। समय सीमा के बदलाव के कारण ग्राहक द्वारा खोए गए लाभ के बारे में मुझे निश्चित रूप से सिरदर्द नहीं है।
पर्यावरणविदों के साथ पिछले अनुभव को ध्यान में रखते हुए, मैं निश्चित रूप से प्रेरित होऊंगा और उस दिशा में सोचूंगा, जिसमें मैं प्रबंधक को भी पसंद नहीं करूंगा, लेकिन ग्राहक, क्योंकि प्रबंधक को परीक्षण शुरू करने के लिए प्रोटोटाइप शुरू करने की तुलना में फ्राइंग पैन से कवर करने में अधिक रुचि थी और संभवत: विकलांगों के लिए भी व्यावसायिक उपयोग। लेकिन - उसने ठीक से फाइल नहीं किया, और मैंने पर्याप्त उत्सुकता नहीं दिखाई। उस समय इसकी तकनीकी विशेषताओं के साथ नई रूपरेखा ने मुझे बहुत अधिक दिलचस्पी दी। उनकी पसंद भी, अंत में असफल रही, अध्ययन को अस्वीकार्य रूप से लंबा समय लगा। इस कार्य के लिए, आप गतिशील भाषाओं में से एक और Django या रेल जैसी एक रूपरेखा चुन सकते हैं।

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

एक छोटे आउटसोर्स के दिवालियापन से दो हफ्ते पहले, मैं एक बड़ी आउटसोर्सिंग कंपनी की एक शाखा में काम करने गया।
मैं वहाँ दिलचस्प हो गया। मैं शहर में एक अत्यधिक सम्मानित कंपनी की जरूरतों के खिलाफ अपने कौशल की जांच करने के लिए, जिज्ञासा से बाहर एक साक्षात्कार के लिए आया था। और मैं साक्षात्कारकर्ता पर पूरी तरह से मोहित हो गया। हमने विभिन्न तकनीकी मुद्दों के बारे में उनके साथ बहुत अच्छी तरह से बात की और मैंने महसूस किया कि वह बहुत शांत थे, आप उनसे बहुत कुछ सीख सकते हैं। वह, जैसा कि यह निकला, मुझे भी काफी सराहना मिली कि हेडहंटर्स सक्रिय रूप से लुभाने लगे। अंतिम निर्णय इस तथ्य से प्रभावित था कि मेरा साक्षात्कारकर्ता विकास टीम की टीम लीड होगी जिसमें मुझे शामिल होना था।
मैंने ईमानदारी से शाखा निदेशक और प्रबंधक को चेतावनी दी कि मेरी अपनी छोटी टीम है, जिसे मैं समानांतर रूप से निभाऊंगा, सहमति प्राप्त की और टीम में शामिल होना शुरू किया। 45 लोगों की परियोजना टीम, जिनमें से एक तिहाई से भी कम डेवलपर्स ने मुझे थोड़ा आश्चर्यचकित किया। इस मामले में, काफी अधिक परीक्षक, कई प्रतिष्ठित विश्लेषक थे, प्रत्येक टीम का अपना नेता और सबसे अधिक - वास्तुकार, परियोजना प्रबंधक और कार्यक्रम प्रबंधक है।
यह परियोजना लंबे समय से चल रही है। यह फोरट्रान पर 30 साल तक मौजूद रहा, फिर 2000-2001 में इसे फिर से लिखा गया, जिससे यह जावा + ओरेकल में एक वेब प्रोजेक्ट बन गया। उसी समय, इंटरफ़ेस की उपस्थिति पूरी तरह से संरक्षित थी।ऐसा नहीं है क्योंकि उपयोगकर्ताओं को इसके लिए उपयोग किया जाता है, बल्कि इसलिए कि एक भी डेवलपर पूरी तरह से समझ नहीं पाया कि सिस्टम का सार क्या था और डेटा प्रविष्टि के लिए इन सभी स्क्रीन का क्या मतलब है। कंपनी में परियोजना के अस्तित्व के दौरान, 100 से अधिक डेवलपर्स ने इसे बदल दिया है, मुझे पता नहीं कितने परीक्षक और विश्लेषक हैं। नतीजतन, जिस टीम में मैं गया, वहां एक भी व्यक्ति नहीं था जो पूरी तरह से सिस्टम को समझेगा। यहां तक ​​कि विश्लेषकों, जिन्होंने मुझे असंगत शब्दों के साथ खुश किया, उपयोगकर्ताओं के लक्ष्यों और जरूरतों के बारे में अधिकांश सवालों के जवाब नहीं दे सके।
यह सब इस तथ्य के कारण था कि पैच लगाने की विधि द्वारा विकास किया गया था। विश्लेषकों और परीक्षकों द्वारा बनाई गई प्रणाली पर दस्तावेज़, अक्सर कोड की वर्तमान स्थिति के अनुरूप नहीं थे, क्योंकि प्रत्येक डेवलपर को उन्हें पढ़ने और वहां लिखी गई सभी चीजों को निष्पादित करने का धैर्य नहीं था। कुछ उपयोगकर्ता कहानियों के अनुसार, ग्राहक और विकास टीम के पास एक ही कार्यक्षमता के दो अलग-अलग चित्र थे।
यह इस परियोजना पर था कि मैंने अपने द्वारा उठाए गए अधिकांश लक्षणों का अवलोकन किया। व्यवसाय डोमेन को समझने की मेरी इच्छा हैरान थी। आखिरकार, एक छोटे से कार्य को करना बहुत आसान है, इस तथ्य को उजागर किए बिना कि माना जाता है कि यह चिंता नहीं करता है। मुझे जो परेशान करता था, वह यह कि प्रयोज्य के दृष्टिकोण से प्रणाली, सबसे खराब उदाहरण था जिसे मैंने कभी देखा था। इसके साथ काम करने के लिए उपयोगकर्ता प्रशिक्षण का समय बहुत बड़ा था। उपयोगकर्ता को बड़ी संख्या में मान्य पैरामीटर मान और उनके संयोजन को ध्यान में रखने के लिए मजबूर किया गया था, क्योंकि सिस्टम ने कोई संकेत नहीं दिया था और यहां तक ​​कि विशाल रूप सत्यापन ने अक्सर केवल संदेश "त्रुटि!" दिखाया था, पृष्ठ को सभी दर्ज किए गए डेटा को साफ़ करने के साथ ओवरलोड करते हुए, जिसके बाद दुर्भाग्यपूर्ण उपयोगकर्ता को प्रवेश करने के लिए मजबूर किया गया था! सब फिर से।
इसी समय, मुख्य रूप से परियोजना पर काम करने वाले लोग तकनीकी रूप से बहुत सक्षम थे, उपयोग की गई और संबंधित प्रौद्योगिकियों की भारी संख्या में पारंगत थे। फिर भी, बहुतों की आँखों में मैंने लालसा देखी। कंपनी, जो शहर के लगभग सबसे अच्छे डेवलपर्स को साथ लाती है, इन संसाधनों का बहुत ही अजीब तरीके से निपटारा करती है। ऐसी परियोजनाएं थीं जहां एक छोटी सी विकास टीम और शाब्दिक रूप से 1-2 परीक्षकों ने एक निरंतर मोड में ओवरटाइम काम किया, जबकि हम अक्सर कोने से कोने तक भटकते थे, न जाने क्या करना चाहिए जब कोड परीक्षण के लिए दिया गया था, और अगले पुनरावृत्ति अभी तक शुरू नहीं हुई थी। लेकिन उनकी बैठकों में कार्यक्रम प्रबंधकों ने अपने लोगों को दूर रखने की पूरी कोशिश की, उन्हें नहीं दिया, जिन्होंने इसकी तत्काल आवश्यकता थी, क्योंकि वे समझते थे कि शायद उन्हें वापस नहीं दिया जाए, भले ही वे आवश्यक हों। इतने सारे डेवलपर्स कंपनी के अंदर बैठे हैं,फ्रीलांस पर कमाया, उस पर कार्य दिवस के थोक खर्च।
इसका परिणाम कई काफी सक्रिय कर्मचारियों का प्रस्थान था जिन्होंने अंततः शहर की गतिशील रूप से विकासशील कंपनियों में नेतृत्व के पदों को ग्रहण किया या इसे छोड़ दिया। वे पिछली कंपनी के भीतर अपने विचारों को लागू करने के लिए तैयार थे, लेकिन इन पहलों को प्रबंधन के ध्यान के बिना छोड़ दिया गया था, क्योंकि प्रबंधन के उच्च स्तर पर, अंत उपयोगकर्ताओं की समस्याएं और यहां तक ​​कि विकास टीम की आंतरिक समस्याएं भी अब दिखाई नहीं देती हैं।

अपने लिए, मैंने निम्नलिखित निष्कर्ष निकाले, जो इस मामले में अत्यधिक विवादास्पद हैं, क्योंकि बड़ी संख्या में ऐसे लोग हैं जो बड़े पदानुक्रम में निर्मित संरचना में पूरी तरह से सहज महसूस करते हैं:
1. इस तरह की संरचना में, उन लोगों का एक समूह जो ज़िम्मेदारी नहीं लेना चाहते हैं और "स्थिरता" को महत्व देते हैं। यह इस तथ्य की ओर जाता है कि उन दुर्लभ क्षणों में जब चेकर्स के साथ एक नई परियोजना को जल्दी से मंथन करने की आवश्यकता होती है, कोई भी इस प्रकार की गतिविधि के लिए तैयार नहीं होता है। इसलिए, ऐसी कंपनियां उबाऊ और लंबे समय तक चलने वाली कंपनियों के रूप में आती हैं, क्योंकि वे पहले से ही विकास में हैं।
2. अगर एक अलग प्रकार की परियोजनाएं अभी भी लीक हो जाती हैं, तो सब कुछ पहले से मज़ेदार और दिलचस्प लगता है। सबसे अधिक बार, वहाँ डेवलपर्स नए आये हुए कर्मचारी या उत्साही होते हैं जो अन्य परियोजनाओं से बच गए हैं। हालाँकि, अन्य प्रोजेक्ट्स की आधी सोई हुई टीमों के पड़ोस जो कि गलियारों में लगातार चैट करने वाले हैं या किचन में चाय का समय रखते हैं, या जो स्पष्ट रूप से काम के घंटों के दौरान मछली पकड़ने जाते हैं, वे आपको आश्चर्यचकित करते हैं - वास्तव में मुझे कड़ी मेहनत क्यों करनी पड़ती है, जब बहुत सारे लोगों को लगभग कुछ भी नहीं मिलता है। जिसके पास बहुत सारा खाली समय है। यह बहुत जल्दी प्रेरणा कम कर देता है। इसके अलावा, केवल वेतन और पदोन्नति के लिए संभावनाएं लोगों को पकड़ने लगती हैं। हालांकि, बहुत से लोग अंततः स्टार्टअप, छोटी लेकिन मजेदार टीमों या फ्रीलांस में जाते हैं।
3. छोटी टीमों में प्रोग्रामर की आबादी के प्रति व्यक्ति की खुशी का प्रतिशत, जिसमें प्रबंधन के पदानुक्रम के कई स्तर नहीं हैं, बहुत अधिक है। व्यक्तिगत रूप से, मैं ऐसी टीमों से बहुत अधिक प्रभावित हूं। जलती हुई आंखों वाले लोगों के बीच होना बहुत अच्छा है। इसलिए, मैं एक कंपनी के भीतर उल्लिखित प्रकार की टीमों और परियोजनाओं के संयोजन की सिफारिश नहीं करूंगा।
4. छोटी टीमों में ग्राहकों की इच्छाओं की प्रतिक्रिया दर अधिक होती है, जिससे ग्राहकों की खुशी का स्तर बढ़ जाता है। हर ग्राहक अभी भी "एक मौका लेने" के लिए तैयार नहीं है और एक छोटे लेकिन गर्वित आउटसोर्सर को किराए पर लेता है। हालांकि, वे हमारी खुशी के लिए हैं।

खुशी के प्यार का फॉर्मूला

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

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

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