एक छोटी कंपनी में जोड़ी प्रोग्रामिंग / सहयोग


20

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

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

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

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

मेरा सवाल यह है कि क्या कभी कोई एक समान स्थिति में रहा है, और उनके लिए क्या काम किया है?

मुझे लगता है कि यह एक आकार-फिट-सभी स्थिति नहीं है, लेकिन मैं एक शॉट के लिए कई दृष्टिकोण देने को तैयार हूं।

हम सभी एक सामान्य क्षेत्र में काम करते हैं, डेवलपर्स के पास अलग-अलग कार्यालय / कक्ष नहीं हैं।


2
क्या आपके और अन्य डेवलपर्स के पास अलग-अलग कार्यालय, कक्ष हैं, या एक सामान्य क्षेत्र में बैठते हैं?

@ शत हम सभी एक सामान्य क्षेत्र में काम करते हैं।
रयान विलियम्स

जवाबों:


12

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

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

और, यदि यह दृष्टिकोण, आपकी कंपनी द्वारा एक बार में संभाल सकने वाली परियोजनाओं की संख्या को सीमित करता है, तो आप इस सहयोगी जोड़ी को दो परियोजनाओं को एक साथ सौंप सकते हैं।

हमने हाल ही में इस दृष्टिकोण के साथ प्रयोग किया है, जिसमें से एक में एपिस के साथ मॉडल + एकीकरण और दूसरे प्रोग्रामर के दृष्टिकोण और नियंत्रक को विकसित करना है । हमने इस सेटिंग के निम्नलिखित लाभ पाए हैं:

  1. कोड संरचना बहुत बेहतर तरीके से परिणाम की तुलना में अगर केवल एक परियोजना के सभी पहलुओं पर काम कर रहा है।
  2. हमें उन्हें भंडार आदि के लिए कोड करने के बारे में याद दिलाना नहीं है।
  3. उन्हें इसके लिए हमारे समर्पित क्यूए पर पूरी तरह से भरोसा करने के बजाय, एक दूसरे के कोड के परीक्षण में कुछ प्रयास करने होंगे।

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

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

7

मेरी राय में, जोड़ी प्रोग्रामिंग आपके द्वारा उठाए गए मुद्दे का समाधान नहीं है।

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

इस गतिशील के बिना जोड़ी प्रोग्रामिंग का लाभ खो जाता है।

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


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

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

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

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

@RyanWilliams कोड समीक्षाएँ "उनकी गर्दन नीचे साँस लेने" के बारे में नहीं हैं। यह आपको नियंत्रित करने के बारे में नहीं है। हमारे स्थान पर, हम एक मंच के रूप में ReviewBoard का उपयोग करते हैं और प्रत्येक अन्य कोड पर टिप्पणी करते हैं । कोई "पदानुक्रम" नहीं है। इस मामले में सीखना "निहित" है। वे आपके और उनके कोड को पढ़ना सीखते हैं, आपके और अन्य देव प्रश्नों और उन प्रश्नों के उत्तर / टिप्पणियों से। और उन्हें कोड आधार के अन्य हिस्सों का पता चल जाता है, जो कि काफी फायदेमंद है IMHO।
जोहान्स एस।

5

TL; DR : मुझे नहीं लगता कि जोड़ी प्रोग्रामिंग आपके लिए काम करेगी। इसके बजाय आपको लोगों को उनके कोड की दीर्घकालिक गुणवत्ता के बारे में चिंतित करने की कोशिश करनी चाहिए और उन्हें जवाब खोजने के लिए तैयार करना चाहिए । यह अनौपचारिक रूप से किया जाना है।


संस्कृति और गुणवत्ता के बारे में

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

दूसरे शब्दों में, आप उस सूट की तरह नहीं दिखना चाहते हैं, जो नवीनतम buzzwords के आसपास आता है, तब भी जब आप हैं। अधिकांश प्रोग्रामर मुझे पता है कि आप मानसिक रूप से पृष्ठभूमि शोर के रूप में टैग करेंगे। एक कॉर्पोरेट मधुमक्खी मत बनो।

मेरी राय में, प्राथमिक प्रश्न जो आपको खुद से पूछना चाहिए था "क्या मैं उस गुणवत्ता और व्यावसायिक मूल्य से खुश हूं जो मेरे संगठन द्वारा रखे गए कोड की गुणवत्ता और व्यावसायिक मूल्य से है?" और यदि इसका उत्तर नकारात्मक है, तो आपको पूछना चाहिए कि "मैं इसे कैसे घुमाऊँ?"।

अंतत:, गुणवत्ता और मूल्य मानवीय परिभाषाएं हैं जो आप या आपके संगठन के किसी अन्य व्यक्ति के बारे में सोच सकते हैं (और चाहिए)।

जोड़ी प्रोग्रामिंग और micromanagement

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

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

आपकी स्थिति के लिए, मैं कहूंगा कि चूंकि आप एक छोटी टीम हैं और आप वास्तविक अनुभव के साथ केवल एक ही हैं (यह वही है जो आपकी पोस्ट मुझे अच्छी लगती है), जोड़ी-प्रोग्रामिंग या अधिकांश समय कोड की समीक्षा करना। 'काम है। आपके पास केवल 24 घंटे हैं। इसके बजाय, कुछ समाधान जिन पर आप विचार कर सकते हैं:

  • उपयुक्त भाषा टैग के तहत SO में भाग लेने के लिए उन्हें प्रोत्साहित करें, या कोड समीक्षा एसई पर समीक्षा के लिए कुछ कोड स्निपेट पोस्ट करें। थोड़ी अनौपचारिक प्रतियोगिता शुरू करें जो प्रति सप्ताह सबसे अधिक एसओ प्रतिनिधि अंक प्राप्त कर सकती है।

    SO नौसिखिया डेवलपर्स के लिए चमत्कार कर सकता है क्योंकि यह लगातार प्रतिक्रिया प्रदान करता है और समुदाय के दिल की धड़कन का अनुसरण करता है।

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


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

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

4

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

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


एक लोकप्रिय राय लगती है। मुझे कोड समीक्षाओं का विचार पसंद है। लेकिन मेरे दिमाग में मुझे लगता है कि उनके व्यक्तित्व और कौशल के स्तर के साथ, यह मुझे होने जा रहा है जो समीक्षा कर रहा है, और वे सिर्फ सुन रहे हैं (ज्यादातर बिन बुलाए)। लेकिन शायद उन्हें और अधिक शामिल करने का एक तरीका है। मुझे लगता है कि मुझे उस पर चिंतन करना होगा।
रयान विलियम्स

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

2

मेरा सवाल यह है कि क्या कभी कोई एक समान स्थिति में रहा है, और उनके लिए क्या काम किया है।

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

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

तथ्य की बात के रूप में, मैं (सबसे उन्नत डेवलपर के रूप में) दूसरों की राय के लिए पूछता हूं / वे मेरी तुलना में अधिक मदद करते हैं, क्योंकि मैं बाहरी आंख के इनपुट को महत्व देता हूं।

ऐसा लगता है कि आप इसे तार्किक प्रगति के रूप में फ्रेम कर सकते हैं जो आप वर्तमान में कर रहे हैं।


मेरी चिंता यह है कि मुझे यकीन नहीं है कि वे "मेंटॉर" बनना चाहते हैं। वे दोनों मुझसे बड़े हैं और एक (काफी पुराने) वास्तव में मेरे पास कुछ वर्षों का अनुभव है। लेकिन मुझे आपकी सलाह का दूसरा हिस्सा पसंद है।
रेयान विलियम्स

और कुछ करने से पहले चिंता करना स्वाभाविक है - क्योंकि आपके पास जानकारी नहीं है। मेरा अनुभव यह रहा है कि यदि आप ऐसा करते हैं, तो लोग समझेंगे कि आप चिंतित नहीं हैं, और यह कि आप तनावमुक्त हैं और वे साथ जाएंगे। और फिर अगर यह काम करता है - जारी रखें, और यदि यह नहीं है - कुछ और प्रयास करें।
dcaswell

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

0

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

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

मैंने पाया है कि समय के साथ (एक छोटी सी टीम में) लोग अन्य लोगों के साथ तालमेल बिठाते हैं और सिंक्रनाइज़ करते हैं। सूक्ष्म प्रबंधन या किसी को यह बताने की आवश्यकता नहीं है कि वे हर समय गलत क्या कर रहे हैं।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.