परियोजनाओं को लोगों की आवश्यकता कैसे होती है, या स्टार्टअप क्यों नहीं लेते हैं

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



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

1. उपयोगकर्ता की आंखों के माध्यम से परियोजना को देखना कितना महत्वपूर्ण है

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

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

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

वैसे, सर्गेई गैलिट्स्की तर्क के महत्व के बारे में भी बोलता है (जो नहीं जानता है - एक अरबपति, बिजनेस सीक्रेट्स प्रोग्राम में स्क्रैच से मैग्नेट रिटेल नेटवर्क बनाया), और हम इस विषय पर स्पर्श करेंगे। सामान्य तौर पर, मैं ध्यान देता हूं कि मुझे फ्रिट्ज मोर्गन के बयान पसंद हैं, जिन्होंने लोगों को तर्कवादियों और अंतर्ज्ञान में विभाजित नहीं किया, लेकिन सुझाव दिया कि साक्षर लोगों के लिए, तर्क और अंतर्ज्ञान एक चक्र में, क्रमिक रूप से, एक दूसरे की जगह लेते हैं।

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


आप समय में सिर्फ सोचकर त्रुटि को ठीक कर सकते हैं

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

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

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


वह फिर से उन्नत खोज में लग रहा है।

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

अब पुन: पुनरावृति नियोजन के लिए। अब आप जानते हैं कि उन्नत खोज दो सप्ताह का खोया समय होगा। प्रत्यक्ष मौद्रिक शब्दों में - 10 * N * S (i), जहां N प्रोग्रामर की संख्या है, S (i) प्रत्येक कार्य दिवस का वेतन है। उदाहरण के लिए, $ 100 के एक दिन के साथ तीन प्रोग्रामर के लिए, यह 10x3x100 = $ 3000 होगा, अर्थात लगभग 100,000 रूबल! और अगर आपके पास अभी भी प्रतिस्पर्धी हैं जो इन दो हफ्तों में एक प्रतिस्पर्धात्मक लाभ बनाएंगे, तो नुकसान असमान रूप से अधिक होंगे।

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

इस प्रकार, आपके उपयोगकर्ता की त्वचा में विसर्जन आपको देता है:
1. वर्तमान क्षण में महत्वपूर्ण कार्यों की एक सटीक समझ
2. परिणामस्वरूप, विचार-विमर्श के स्तर पर भी अनावश्यक कार्यक्षमता में कटौती करने की क्षमता - यदि यह उपयोगकर्ता के कार्यों को हल नहीं करता है, तो इसे सुरक्षित रूप से काट दिया जा सकता है।

उसी समय, हम यह निर्धारित करने पर विचार नहीं कर रहे हैं कि वास्तव में आपका उपयोगकर्ता कौन है - यह लेख के दायरे से परे है, और, वैसे, मेरे पसंदीदा पोतापेंको एक ही बात कहते हैं - प्रश्न का 90% "आपका ग्राहक कौन है" 30 के साथ महिला का जवाब देता है। 50 ”, जो पूरी तरह से बकवास है - अर्थात, खरीदार बिल्कुल परिभाषित नहीं है।

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

2. प्रोग्रामर के साथ सही तरीके से संवाद कैसे करें

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

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

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

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


अन्य परियोजना प्रतिभागियों को सही ढंग से जानकारी देने के महत्व को कम करके नहीं आंका जाना चाहिए।

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

वास्तव में, आपको प्रोग्रामर की भाषा में कार्य का वर्णन करने की आवश्यकता है, और आप तकनीकी के जितना करीब सोचते हैं, यह आपके लिए उतना ही आसान होगा। आदर्श विकल्प यूएमएल आरेख (जैसे अनुक्रम आरेख) है जो आसानी से हाथ से खींचा जा सकता है और जल्दी से स्कैन किया जा सकता है (एक स्कैनर की लागत $ 100 है और पहले सप्ताह में भुगतान करता है, प्रति माह आपको घंटों की बात बचाता है - 90% जानकारी नेत्रहीन और केवल 9-10% के बारे में प्रसारित होती है। - कान से)।

इसी समय, एल्गोरिथ्म द्वारा, मैं समझता हूं कि कार्यान्वयन पहले से ही नहीं है, लेकिन यह कैसे काम करना चाहिए। कार्यान्वयन के विकल्प प्रोग्रामर की पसंद पर छोड़ दिए जाते हैं।

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

यदि पसंद किया जाता है, तो आपको एक प्रोग्रामर के साथ काम करने की आवश्यकता है। शुरू करने के लिए, ध्वनि में कार्य पर चर्चा करें, समय पूछें। मान लीजिए, फ़िल्टर वाली तालिका के मामले में, आपने 23 घंटे सुने हैं, और आपको 4 घंटे के लिए कार्य करने की आवश्यकता है। आपके पास देश, रिज़ॉर्ट और दिनांक द्वारा तीन फ़िल्टर - ड्रॉप-डाउन सूची हैं, और तालिका प्रविष्टियों को प्रदर्शित करती है। प्रोग्रामर को कार्य के चरणों को चित्रित करने के लिए कहें, सोचने के लिए आधा घंटा दें, एक सूची प्राप्त करें:
- रिसॉर्ट्स का शब्दकोश, व्यवस्थापक पैनल के साथ बेस स्तर पर देशों - 8 घंटे
- तिथि चयन के लिए कैलेंडर - 1 घंटा
- तालिका में छंटनी - 4 घंटे
- डेटाबेस से चयन और तालिका से आउटपुट - 2 घंटे
- पेजिंग - 4 घंटे
- दिनांक, देश, रिज़ॉर्ट द्वारा फ़िल्टर करें - 4 घंटे

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

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

समय के साथ, प्रोग्रामर समझदार और अधिक अनुभवी होंगे, और कार्य के चरण के आधार पर (नई कार्यक्षमता विकसित करना, या एक परियोजना शुरू करना), वे एक रणनीति चुनेंगे - शिट कोड और माइक्रोट्रिएशन + रिफ़ेक्टरिंग के साथ एक त्वरित भीड़, या आवश्यकताओं को तुरंत लागू करना और सटीक कार्यान्वयन (यदि कहीं जाना नहीं है, तो वहाँ की रणनीति है) डोपिल्का परियोजना)

उपरोक्त सभी, निश्चित रूप से, micromanagement है, लेकिन यह आपको परियोजना के शुरुआती चरणों और 80-90% सटीक कार्यक्षमता में हर दिन रिलीज करने की अनुमति देता है। यदि आप एक दृष्टिकोण जानते हैं जो आपको पहले चरण में अभिनय करने की अनुमति देता है - टिप्पणियों में वर्णन करें।

3. किसी भी परियोजना को लगातार विकसित करने की आवश्यकता क्यों है

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


कभी-कभी प्रोजेक्ट पैंट आकार में नहीं होते हैं

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

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

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

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

मैं आपको शुभकामनाएं देता हूं और टिप्पणियों में अपना अनुभव साझा करने का सुझाव देता हूं।

मेरी एलजे में क्रॉसपोस्ट