एक बड़े वेब प्रोजेक्ट की विशेषताएं और जोखिम। क्लाइंट और डेवलपर के बीच काम कैसे करें

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

बड़े प्रोजेक्ट की पहचान कैसे करें?

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

हमने कई संकेत दिए:

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

एक बड़ी परियोजना की विशेषताएं

परियोजना प्रबंधन जोखिमों की संभावना में कमी है। एक बड़ी परियोजना में, विशेष जोखिम हैं:

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

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

ग्राहक समस्याएँ

सामान्यतया, ग्राहक और डेवलपर विकास प्रक्रिया के लगभग समान पक्ष होते हैं, और उनके समान जोखिम होते हैं। क्लाइंट क्या सवाल करता है (या क्या करना चाहिए), जिसने कुछ असामान्य और बड़ा करने का फैसला किया - एक बड़ी वेब परियोजना:

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

डेवलपर प्रश्न

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

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

मुख्य जोखिम

एक बड़ी परियोजना के आम जोखिम हैं जो हमेशा होते हैं। वेब प्रौद्योगिकियों के लिए भी विशिष्टताएं हैं। यहाँ सबसे महत्वपूर्ण हैं:

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

प्रमुख निर्णय प्रश्न

एक परियोजना बनाते समय, सबसे महत्वपूर्ण बात वे लोग हैं जो इसके लिए जिम्मेदार होंगे। कोई भी तकनीक दिमाग और परियोजना के मुद्दों को हल करने की इच्छा को प्रतिस्थापित नहीं कर सकती है। ये किस तरह के लोग होने चाहिए? उन्हें चाहिए:

• ऐसे कार्यों में अनुभव है (परियोजना आकार मानदंड)
• इस विचार को समझेंगे और "आग पकड़ेंगे", परियोजना करना चाहेंगे
• आपसे वो सवाल पूछेगा जो आपने खुद नहीं पूछे थे
• आपके लिए अच्छा रहेगा। आप इन लोगों के साथ बहुत संवाद करेंगे, और अगर कोई भावनात्मक संपर्क नहीं है, तो समस्याओं से बचा नहीं जा सकता है

शायद इस तरह के एक डेवलपर आपको एक सुपरमैन, एक आदर्श ठेकेदार लगता है जो प्रकृति में नहीं है? शायद ऐसा है। लेकिन आम तौर पर बोलते हुए, वेब डेवलपर्स की कई सभ्य टीम हैं, और एक विकल्प है।
आपको बस इसे करने की जरूरत है, और इसे होशपूर्वक करें।

इंटरेक्शन तकनीक: आदर्श और वास्तविकता

सिद्धांत रूप में, सब कुछ सरल है।

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

उनके तर्क में, सब कुछ सच है। कलाकार पूरी तरह से अलग है।

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

उनके तर्क में, सब कुछ सच है। संघर्ष के लिए प्राथमिकताओं और पूर्व शर्त में विरोधाभास है।
व्यवहार में, सब कुछ अलग है।

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

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

परियोजना मूल्यांकन और योजना

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

• 
  , , 10 ( , , ), .
• ,
  . 10-30% . , , , , . , .
• छोटे भागों में विकास
  यह दृष्टिकोण तेजी से लोकप्रिय हो रहा है। 2 सप्ताह से 3 महीने तक चलने वाले छोटे भागों में विकास किया जाता है, जिसके लिए कार्य बहुत बड़े नहीं होते हैं। प्रत्येक भाग का भुगतान किया जाता है, प्रत्येक भाग लॉन्च किया जाता है और परियोजना की क्षमताओं का विस्तार करता है। तकनीक अच्छी है कि ग्राहक के पास हमेशा एक उत्पाद होता है जिसका उपयोग किया जा सकता है। कई जोखिम नहीं हैं: संपर्क का नुकसान, बड़े टीके, परीक्षण की कमी। नुकसान भी हैं: कोई नहीं जानता कि कितने सर्विंग्स की आवश्यकता होगी, अंतिम लागत और विकास का समय क्या होगा। ग्राहक अक्सर इसे पसंद नहीं करता है।
  हालांकि, यह सममित है: डेवलपर कभी भी पूरे कार्य को नहीं जानता है, जिसे वह अक्सर नापसंद करता है।

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

समझौते और खेल के नियम

विरोधाभास यह है कि अधिकांश डेवलपर्स कुछ भी नहीं के बारे में एक मानक अनुबंध लागू करते हैं। इस तरह के एक समझौते में शर्तों, दायित्वों, जिम्मेदारी का विभाजन, सामग्रियों की प्रस्तुति, आदि को ठीक नहीं किया जाता है। हाल ही में प्रकाशित एक अध्ययन के अनुसार, 30% साइटें बिना किसी अनुबंध के बनाई जाती हैं। यदि व्यवसाय कार्ड साइटें बनाते समय इसे छोड़ा जा सकता है, लेकिन हजारों मानव-घंटे की परियोजनाएं एक कमजोर अनुबंध के तहत नहीं की जा सकती हैं। तो, अनुबंध क्या होना चाहिए:

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

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

कार्य प्रलेखन

दस्तावेज़ काम के संगठन का एक महत्वपूर्ण हिस्सा हैं। मुझे उन परियोजनाओं से निपटना पड़ा जहां नियमों, निर्देशों, विनिर्देशों की कुल संख्या कई दर्जन तक पहुंच गई। दस्तावेज़ रामबाण नहीं हैं, और कोई सार्वभौमिक नुस्खा नहीं है। एक बड़ी परियोजना की बारीकियां क्या हैं:

• बहुत सारी जानकारी
• उच्च कठिनाई
• विवरण पहले अज्ञात हैं, और फिर शोधन होता है।

डोमिनोज़ प्रोजेक्ट में हमने किस योजना का उपयोग किया, और इसने अच्छा काम किया:

• अनुबंध में समस्या का संक्षिप्त विवरण। पाठ की 6 शीट, जहां प्रतिबंध संकेत दिए गए हैं: 30 से अधिक प्रकार के विज्ञापन नहीं, 10 से अधिक एक्सचेंज फ़ाइल प्रारूप नहीं, सभी डेटा प्रविष्टि रूपों में 300 से अधिक फ़ील्ड नहीं। ये सीमाएं बहुत महत्वपूर्ण हैं।
• हमने वास्तव में एक्सुर के आधार पर तकनीकी कार्य किया था, जहां हमने लाइव क्लिक करने योग्य लेआउट बनाए थे, विज्ञापनों के राज्य के परिवर्तन के दस्तावेज वाले कई चित्र
• टीके पाठ को Google डॉक्स में लिखा, पढ़ा, चर्चा किया गया था

टीके बहुत बड़ा निकला, लेकिन लेखन और संपादन की प्रक्रिया में यह स्पष्ट और सामूहिक रूप से चर्चा में था।

विकास ट्रैकिंग

जब कार्य पर हस्ताक्षर किए जाते हैं और उत्पादन शुरू होता है, तो कुछ चीजें बस आवश्यक होती हैं:

• गैंट चार्ट जहां वास्तविक और वास्तविक तिथियों पर ध्यान दिया जाना चाहिए
• बग ट्रैकर, जहां इसकी सीमित पहुंच और डाउनलोड है
• ग्राहकों के साथ नियमित बैठकें (खासकर यदि परियोजना एक विशाल टुकड़े में की जाती है)
  

जो बेहद उपयोगी होगा, लेकिन दुर्भाग्य से हमने नहीं किया।

• टीके में अपरिहार्य परिवर्तन त्रुटियों, स्पष्टीकरण (उदाहरण के लिए, एक तहखाने के क्षेत्र को एक निजी घर में जोड़ा) के सुधार के कारण परिवर्तन शीट में दर्ज किया जाना चाहिए। हमने उन्हें मेल में बिखरे हुए पाया।
• उठाए गए हर कदम को परीक्षणों द्वारा जांचा जाना चाहिए, अधिमानतः स्वचालित। और परीक्षणों को लागू करने से पहले खुद को तैयार करने की आवश्यकता है।

परियोजना का वितरण। लोड परीक्षण।

प्रोजेक्ट सबमिट करते समय, वे हमेशा उपयोगकर्ता परीक्षण करते हैं, कभी-कभी यूनिट कोड परीक्षण करते हैं। हमारा मानना ​​है कि एक अन्य प्रकार का परीक्षण बेहद महत्वपूर्ण है: तनावपूर्ण।
मैं आपको डोमिनोज़ के उदाहरण पर बताऊंगा:

• अनुबंध में राइट हमने साझा होस्टिंग पर काम करने के लिए साइट की आवश्यकताओं को लिखा: 200 हजार पेज व्यू (लगभग 3 पेज प्रति सेकंड), औसत पेज पीढ़ी का समय 0.5 एस तक, त्रुटि दर 50? 1% से अधिक नहीं
• परियोजना की ख़ासियत यह है कि डेटा को बहुत तीव्रता से अपडेट किया जाता है और कैशिंग तंत्र बहुत कुशलता से काम नहीं करता है
• परियोजना की डिलीवरी के बाद, हमने एक परीक्षण किया (टिम्बेव, टैरिफ इटर्नो की मेजबानी)। औसत पीढ़ी का समय लगभग 0.2 सेकंड था, इसमें 500 त्रुटियां नहीं थीं। 200,000 साइट दृश्य आसानी से पारित हुए
• 10 , . .
• , .

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

निष्कर्ष

एक बड़ी परियोजना उतनी डरावनी नहीं है जितनी यह लग सकती है। सब कुछ हल हो जाता है अगर ग्राहक और डेवलपर के पास सामान्य ज्ञान, अनुभव और मुद्दों को हल करने की इच्छा है। हम मानते हैं कि:

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

और एक और निष्कर्ष

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