आपका प्रोजेक्ट चैट किसी अलग ऐप में नहीं होना चाहिए

आपके टास्क एक टूल में हैं। फाइलें दूसरे में। बातचीत तीसरे में। और किसी तरह आपकी टीम को एकजुट रहना है। यही अधिकांश छोटी टीमों, फ्रीलांसरों और छात्र समूहों का डिफ़ॉल्ट सेटअप है। Trello या Asana में काम ट्रैक करते हैं, Google Drive या Dropbox से फाइलें शेयर करते हैं, और Slack या Discord पर बात करते हैं। कम से कम तीन टूल, हर एक का अपना नोटिफिकेशन सिस्टम, अपनी सर्च और अपना सच का संस्करण। नतीजा यह है कि प्रोजेक्ट का कॉन्टेक्स्ट प्लेटफॉर्म के पार बिखर जाता है। एक निर्णय Slack में होता है। उस निर्णय को दर्शाने वाला टास्क प्रोजेक्ट बोर्ड में होता है। टास्क से संबंधित फाइल Drive में होती है। पूरी तस्वीर समझने के लिए किसी को तीन अलग-अलग जगहें जाँचनी पड़ती हैं। और अगर वे उस वक्त ऑनलाइन नहीं थे जब Slack संदेश भेजा गया था, तो शायद वे उसे कभी देख ही न पाएं। यह केवल असुविधा नहीं है। यह गलत संवाद, दोहरे काम और चूके हुए काम का एक असली स्रोत है। जब लोग वह बातचीत नहीं ढूंढ पाते जो किसी टास्क को समझाती है, तो वे या तो अनुमान लगाते हैं या किसी को बीच में टोककर पूछते हैं। दोनों कुशल नहीं हैं।

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

IndieDevBoard में हर प्रोजेक्ट के अंदर टीम चैट शामिल है। आप अपना प्रोजेक्ट खोलते हैं, चैट में जाते हैं, और आपकी बातचीत आपके Kanban बोर्ड, टाइमलाइन, नोटबुक और फाइलों के साथ वहीं मौजूद है। तत्काल फायदा यह है कि संदेश उस काम से जुड़े रहते हैं जिसके बारे में वे हैं। जब कोई किसी टास्क के बारे में पूछता है, तो टास्क एक क्लिक दूर है। जब कोई कोई निर्णय शेयर करता है, तो वह उसी वर्कस्पेस में है जहाँ प्रासंगिक माइलस्टोन और नोट्स रहते हैं। कॉन्टेक्स्ट किसी अलग ऐप में गायब नहीं होता। इससे ऑनबोर्डिंग की समस्या भी हल होती है। जब कोई नया टीम सदस्य प्रोजेक्ट से जुड़ता है, तो उन्हें कॉन्टेक्स्ट में पूरी चैट हिस्ट्री मिलती है। वे उन बातचीतों को देख सकते हैं जिन्होंने प्रोजेक्ट को आकार दिया, असल काम के साथ। Slack में उन्हें कई चैनलों में खोजना पड़ता और फिर भी आधी प्रासंगिक चर्चाएं छूट जातीं। एक और कम आंकी गई फायदा है प्रोजेक्ट आर्काइविंग। जब कोई प्रोजेक्ट खत्म होता है, तो चैट उसके साथ चली जाती है। आपके पास zombie Slack चैनल नहीं बचते जिन्हें कोई आर्काइव करना याद नहीं रखता। प्रोजेक्ट हो गया, बातचीत संरक्षित है, और आपका मुख्य संचार टूल किसी अव्यवस्था से भरा नहीं होता।

छोटी टीमें अक्सर synchronous संचार को डिफ़ॉल्ट बना लेती हैं। किसी का सवाल है, वह Slack में पोस्ट करता है, और अभी जवाब की उम्मीद रखता है। यह तब काम करता है जब सभी एक साथ ऑनलाइन हों, लेकिन टाइमज़ोन अंतर, लचीले शेड्यूल, या गहरे फोकस समय की जरूरत वाले टीम सदस्यों के साथ यह जल्दी टूट जाता है। दैनिक standups और लगातार Slack pings का छुपा हुआ सच यह है कि वे गहरे काम को बाधित करते हैं। हर नोटिफिकेशन एक कॉन्टेक्स्ट स्विच है। शोध लगातार दिखाता है कि किसी रुकावट के बाद पूरी तरह से फोकस वापस पाने में लगभग 23 मिनट लगते हैं। अगर आपकी टीम एक दिन में छह बार एक-दूसरे को ping करती है, तो हर व्यक्ति के दो घंटे से अधिक उत्पादक समय बर्बाद हो जाते हैं। Async संचार अलग तरह से काम करता है। आप एक अपडेट या सवाल पोस्ट करते हैं, और लोग जब तैयार हों तब जवाब देते हैं। बातचीत अभी भी वहाँ है। कुछ खोया नहीं। लेकिन किसी को real-time में भाग लेने के लिए अपना काम छोड़ना नहीं पड़ा। छोटी टीमों के लिए सबसे अच्छा सेटअप है async by default, sync जब जरूरी हो। अपडेट, सवाल और निर्णयों के लिए प्रोजेक्ट चैट का उपयोग करें जिन्हें तुरंत जवाब की जरूरत नहीं है। जब वास्तव में real-time चर्चा की जरूरत हो तब call करें। यह संतुलन लोगों को सूचित रखता है बिना उनके focused काम करने की क्षमता को नष्ट किए। प्रोजेक्ट वर्कस्पेस के अंदर चैट होना इसे स्वाभाविक रूप से सपोर्ट करता है। संदेश persistent और प्रोजेक्ट से जुड़े होते हैं। लोग तब चेक करते हैं जब वे प्रोजेक्ट चेक करते हैं। तुरंत जवाब देने का दबाव नहीं होता क्योंकि कॉन्टेक्स्ट संरक्षित और दिखाई देता है जब भी वे इसतक पहुँचते हैं।

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

प्रोजेक्ट-स्तरीय चैट सभी टीम संचार का विकल्प नहीं है। अगर आपके संगठन में सैकड़ों लोग हैं, तो आपको अभी भी एक कंपनी-व्यापी संचार प्लेटफॉर्म चाहिए। Slack घोषणाओं, सामाजिक चैनलों, क्रॉस-टीम चर्चाओं और उन random watercooler बातचीतों के लिए बढ़िया है जो remote टीमों को इंसानी बनाए रखती हैं। तर्क यह नहीं है कि Slack बुरा है। तर्क यह है कि Slack प्रोजेक्ट-विशिष्ट चर्चाओं के लिए सही जगह नहीं है जिन्हें काम से जुड़े रहने की जरूरत है। Slack का उपयोग कंपनी के लिए करें। प्रोजेक्ट चैट का उपयोग प्रोजेक्ट के लिए करें। इसी तरह, अगर आप open-source समुदायों या गेमिंग ग्रुप का हिस्सा हैं, तो Discord एक अलग उद्देश्य पूरा करता है। यह एक community टूल है, project management टूल नहीं। दोनों साथ-साथ रह सकते हैं। लक्ष्य है बातचीत को वहाँ रखना जहाँ वह संबंधित हो। कंपनी-व्यापी चीज़ें कंपनी-व्यापी टूल में जाती हैं। प्रोजेक्ट-विशिष्ट बातचीत प्रोजेक्ट में जाती है। जब आप दोनों को मिलाना बंद करते हैं, तो दोनों साफ हो जाते हैं।

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