क्यों हम टीके कभी नहीं बनाते हैं। बदले में क्या?

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



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

उपयोगकर्ता को एक TOR बनाना होगा

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

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

टीके के लिए किसे जाने की आवश्यकता है?

जो प्रक्रियाओं का निर्माण करता है। ये विभागों के प्रमुख और प्रमुखों, नियोजन विभागों आदि के प्रमुख हो सकते हैं।

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

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

यदि व्यवसाय प्रक्रिया औपचारिक नहीं है तो क्या होगा?

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

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

वाक्पटु प्रोटोटाइप

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

लेकिन टीके के बिना कैसे?

हमने TK को कुछ समस्या मानचित्रों से बदल दिया। यह समाधान के लिए कार्यों का सारांश है, जिसे फ्रीस्टाइल में लिखा गया है। समस्या हल करना = समझौते को पूरा करना। सब कुछ सरल है।

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

संक्षेप में कहना

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

अपने व्यवसाय में गुड लक!