छूटे हुए काम इंसानी समस्या नहीं हैं
प्रोजेक्ट मैनेजमेंट में छूटे हुए काम अनुशासन की कमी नहीं हैं – जानें कब आपकी टीम को इन्हें पकड़ने के लिए एक सिस्टम की ज़रूरत है।
By Ellis Keane · 2026-03-17
अगर आपकी टीम इतनी छोटी है कि आप सब साथ लंच कर सकते हैं (या कम से कम सैद्धांतिक रूप से कर सकते थे, अगर कभी एक ही शहर में एक ही समय पर होते), तो शायद आपको यह पढ़ने की ज़रूरत नहीं है। टैब बंद करें। जाकर कुछ बनाएं। आपके पैमाने पर छूटे हुए काम की समस्या एक बुधवार दोपहर के Slack रिमाइंडर भर से हल हो सकती है – और यह मैं सच में कह रहा हूँ।
अभी भी यहाँ हैं? ठीक है। तो बात करते हैं प्रोजेक्ट मैनेजमेंट में छूटे हुए काम की – और खासतौर पर इस बारे में कि एक निश्चित आकार के बाद टीम पहुँचने पर आम सलाह काम क्यों नहीं करती।
आगे बढ़ने से पहले
हम एक ऐसा टूल बना रहे हैं जो इस समस्या को हल करता है (Sugarbug – मैं झूठ बोलूँगा अगर यह न कहूँ), लेकिन ईमानदार जवाब यह है कि यह पढ़ने वाली ज़्यादातर टीमों को अभी हमारे बनाए हुए टूल की ज़रूरत नहीं है। शायद कभी नहीं भी। उन्हें समझने की ज़रूरत है कि काम छूटते क्यों हैं, क्योंकि समाधान कारण पर निर्भर करता है – और कारण लगभग कभी वह नहीं होता जो लोग सोचते हैं।
काम क्यों छूटते हैं
ज़्यादातर मैनेजरों से पूछें कि काम क्यों छूटते हैं और आपको एक जानी-पहचानी सूची मिलेगी: किसी ने भुला दिया, किसी ने ध्यान नहीं दिया, किसी ने प्रोसेस का पालन नहीं किया। तो समाधान हुआ बेहतर प्रोसेस, ज़्यादा रिमाइंडर, शायद एक standup बॉट जो हर सुबह सबको नज जे।
और देखिए, कभी-कभी यही असली समस्या होती है। अगर आपके इंजीनियर ने Linear टिकट अपडेट करना भूल गया और PM ने sprint review से पहले जाँच नहीं की, तो यह एक इंसानी चूक और प्रोसेस गैप है। एक चेकलिस्ट जोड़ें। आगे बढ़ें।
लेकिन यह वह किस्म का छूटा हुआ काम नहीं है जो engineering managers को रात को जगाए रखता है। वह जो सच में दर्द देता है, वह है जब सबने अपना काम किया, अपना प्रोसेस फॉलो किया, अपने टूल अपडेट किए – और फिर भी कुछ गैप में से गिर गया। क्योंकि गैप किसी इंसान और उसके टास्क के बीच नहीं है। यह एक टूल और दूसरे टूल के बीच है।
समझाता हूँ। एक इंजीनियर एक PR शिप करता है जो एक GitHub issue बंद कर देता है। वह issue एक Linear टिकट से जुड़ा था और टिकट "Done" हो गया। बढ़िया। बस यह हुआ कि मूल अनुरोध तीन हफ्ते पहले एक Slack बातचीत से आया था जिसमें PM ने एक follow-up requirement का भी ज़िक्र किया था – जिसे किसी ने अलग टास्क के रूप में कभी दर्ज नहीं किया। वह follow-up फरवरी के एक Slack थ्रेड में रहता है। वह Linear में नहीं है। GitHub में नहीं है। किसी के sprint में नहीं है। तकनीकी रूप से यह एक छूटा हुआ काम है – लेकिन किसी एक इंसान ने इसे नहीं छोड़ा। यह Slack और टास्क ट्रैकर के बीच के स्ट्रक्चरल गैप से गिर गया।
यह पैटर्न हर जगह दिखता है एक बार जब आप ध्यान देना शुरू कर दें। एक designer Figma में एक कमेंट छोड़ता है यह बताते हुए कि एक edge case Notion के spec से विरोधाभास रखता है – लेकिन feature पर काम करने वाला इंजीनियर कभी Figma नहीं देखता और PM कमेंट कभी नहीं देखता क्योंकि वह Linear में रहता है। एक customer success lead एक call में feature का वादा करता है, इसे email में summarize करता है, और यह engineering backlog तक कभी नहीं पहुँचता क्योंकि कोई उस खास गैप को नहीं पाटता। एक incident post-mortem तीन follow-up items की पहचान करता है, दस्तावेज़ Slack में शेयर होता है, और तीन में से दो कभी tracked tasks नहीं बनते क्योंकि जो व्यक्ति यह आमतौर पर करता है वह उस हफ्ते बीमार था।
प्रोजेक्ट मैनेजमेंट में सबसे नुकसानदेह छूटे हुए काम टूल्स के बीच के गैप में होते हैं – न कि लोगों और उनकी टास्क लिस्ट के बीच के गैप में।
प्रोसेस का समाधान (और यह कहाँ काम करना बंद करता है)
मुझे सच में विश्वास है कि अच्छे प्रोसेस ज़्यादातर टीमों की ज़्यादातर समस्याएं सुलझा देते हैं। यहाँ वह है जो काम करता है – और मैं यह बिना किसी छिपे इरादे के शेयर कर रहा हूँ, क्योंकि (ईमानदारी से) हम लॉन्च से पहले हैं और अभी सबसे अच्छी चीज़ जो हम कर सकते हैं वह है उपयोगी होकर भरोसा बनाना।
साप्ताहिक समीक्षा। एक व्यक्ति – आदर्श रूप से PM या engineering lead – हर शुक्रवार 30 मिनट Slack थ्रेड्स, मीटिंग नोट्स और ईमेल देखने में बिताता है ताकि वह सब कुछ पकड़ सके जो discuss तो हुआ लेकिन कभी track नहीं हुआ। थकाऊ? बिल्कुल। प्रभावी? एक हद तक, हाँ।
निर्णय लॉग। हर वह निर्णय जो किसी Slack थ्रेड या मीटिंग से निकलता है, उसे तारीख, निर्णयकर्ता और follow-up के साथ एक shared doc (Notion, Google Docs, कोई भी) में paste किया जाता है। यह सरल लगता है, और है भी – जब तक आप एक हफ्ते में चार channels में पंद्रह निर्णय नहीं ले रहे हों और कोई याद न रखे कि कौन से log हुए।
लिंकिंग अनुशासन। हर PR अपने Linear टिकट को reference करता है। हर Linear टिकट उस Slack थ्रेड से लिंक करता है जहाँ requirement discuss हुई। हर Notion spec अपने Linear epic से लिंक करता है। अगर कोई chain तोड़ता है – और कोई तोड़ेगा, यह if का नहीं बल्कि when का सवाल है – तो visibility भी टूट जाती है।
ये सब अच्छी practices हैं। हम खुद इन तीनों के versions इस्तेमाल करते हैं। लेकिन इनमें एक common failure mode है: ये इस बात पर निर्भर हैं कि इंसान हर बार, हमेशा के लिए, एक छोटा, उबाऊ काम consistently करें। और इस पर research निराशाजनक है – मुझे cite करने की भी ज़रूरत नहीं। अगर आपने पाँच से ज़्यादा लोगों की टीम manage की है, तो आप पहले से जानते हैं।
जब प्रोसेस समाधान scale करना बंद करे
एक threshold है, और काश मैं आपको एक सटीक संख्या दे सकता, लेकिन हमने अभी तक यह नहीं निकाला है (सच में, यह शायद टीम और उनके अनुशासन के हिसाब से बदलता है)। हमारी working heuristic – और मैं स्पष्ट करना चाहता हूँ कि यह एक heuristic है, benchmarked data नहीं – यह है कि चीज़ें कहीं चार-पाँच टूल्स, दस से ज़्यादा लोगों और कई parallel workstreams के आसपास टूटने लगती हैं।
इसलिए नहीं कि कोई आलसी हो गया। इसलिए नहीं कि प्रोसेस खराब था। बल्कि इसलिए कि टूल्स के बीच connections की मात्रा किसी एक इंसान की उन्हें manually track करने की क्षमता से आगे निकल जाती है। साप्ताहिक समीक्षा 30 की बजाय 90 मिनट लेती है, और PM उसे skim करने लगता है। निर्णय लॉग पुराना पड़ जाता है क्योंकि जो इसे maintain करता था वह छुट्टी पर गया और किसी ने इसे pick up नहीं किया। लिंकिंग अनुशासन Linear और GitHub के लिए टिकता है लेकिन Slack और Figma के लिए टूट जाता है क्योंकि उन टूल्स में उसी तरह के structured references नहीं हैं।
यह – और मैं यह साफ कहना चाहता हूँ – एक scaling problem है, अनुशासन की समस्या नहीं। मैंने सच में बेहतरीन PMs और engineering leads को इससे जूझते देखा है – ऐसे लोग जो अपनी टीम को बहुत अनुशासन से चलाते हैं और गहराई से परवाह करते हैं कि कुछ भी न छूटे। एक निश्चित पैमाने पर, समस्या समाधान से बड़ी हो जाती है। यह इंसान की नाकामी नहीं है – यह टूल इकोसिस्टम की नाकामी है कि वह खुद को आपस में connect नहीं करता।
"अपने tooling में sophisticated होने का इनाम है छूटे हुए काम के लिए एक और जटिल failure surface। मुझे यह बेहद ironic लगता है।" – Ellis Keane
और यहाँ वह हिस्सा है जो मुझे सच में अनुचित लगता है: आपकी टीम अपने टूल्स जितनी बेहतर तरह से इस्तेमाल करती है, cross-tool gaps के लिए उतनी ज़्यादा surface area होती है। एक टीम जो Linear धार्मिक रूप से इस्तेमाल करती है, Notion specs को up-to-date रखती है, Figma में active reviews करती है, और well-organised Slack channels में communicate करती है – उसके पास उस टीम से ज़्यादा handoff points हैं जो सिर्फ ईमेल और spreadsheet इस्तेमाल करती है।
आपके टूल्स क्यों मदद नहीं कर सकते
यह वह बात है जो मुझे इस पूरी समस्या के बारे में सच में interesting लगती है, और जो पर्याप्त discuss नहीं होती: आपके टूल्स बिल्कुल वही कर रहे हैं जिनके लिए वे design हुए थे। Linear, Linear issues track करने में बेहतरीन है। GitHub, code changes track करने में बेहतरीन है। Notion, documents organize करने में बेहतरीन है। Slack... Slack होने में बेहतरीन है (चाहे अच्छा हो या बुरा)।
लेकिन इनमें से कोई भी आपस में connections track करने के लिए design नहीं हुआ था। और काम – असली काम – एक टूल के अंदर नहीं होता, यह सभी में flow करता है। टूल्स के बीच handoff points वहाँ हैं जहाँ चीज़ें गायब होती हैं, और किसी एक टूल को improve करने से यह ठीक नहीं होता। आप Linear को issues track करने में बेहतर बना सकते हैं – लेकिन यह मदद नहीं करता जब issue पहली जगह एक Slack बातचीत के आधार पर बनाया जाना चाहिए था जो उस channel में हुई जिसे engineering lead monitor नहीं करता।
इसे सच में क्या ठीक करेगा
मैं इस पोस्ट में product चीज़ों के बारे में जानबूझकर vague रहा हूँ, और यह intentional है – मैं चाहता था कि यह उपयोगी हो चाहे आप हमारे बनाए कुछ भी इस्तेमाल करें या न करें। लेकिन चूँकि आप यहाँ तक पहुँच गए हैं (और मैं इसकी सराहना करता हूँ), तो मुझे इस बारे में honest रहने दें कि मुझे लगता है असली समाधान कैसा दिखता है।
यह कोई बेहतर task tracker नहीं है। यह कोई बेहतर process नहीं है। यह कोई standup bot, साप्ताहिक review या shared spreadsheet नहीं है। ये सब मदद करते हैं, और छोटे पैमाने पर पर्याप्त हैं – लेकिन सब symptom का इलाज करते हैं।
असली समाधान कुछ ऐसा है जो आपके टूल्स के बीच connections देखे और flag करे जब कुछ ठीक न लगे। जब कोई Slack निर्णय ticket नहीं बनता। जब एक GitHub PR एक issue बंद करता है लेकिन unresolved comments हैं। जब एक Notion spec एक ऐसी requirement reference करता है जो किसी conversation में deprioritize हो गई जो spec author ने कभी देखी ही नहीं।
इसे concrete बनाते हैं: मान लीजिए आपका system Slack और Linear दोनों देख रहा है। यह #engineering में एक conversation देखता है जहाँ कोई कहता है "हमें वह case भी handle करना चाहिए जहाँ user ने email verify नहीं की है" – यह एक नई requirement है। अगर यह requirement, मान लीजिए 48 घंटों में, Linear ticket के रूप में नहीं आती, तो system इसे flag करता है। कोई चिल्लाने वाली notification नहीं (किसी को और ज़्यादा नहीं चाहिए), बल्कि एक "decisions not yet tracked" view में एक entry के रूप में जिसे PM अपनी Friday review के दौरान देख सकता है। यही बात GitHub PRs के लिए भी जो Linear tickets बंद करते हैं लेकिन अभी भी open review comments हैं, या Notion specs के लिए जो ऐसे features reference करते हैं जो spec लिखे जाने के बाद से deprioritize हो चुके हैं।
चाहे आप इसे internally बनाएं (कुछ टीमें करती हैं, webhooks, message queue और थोड़े glue code के साथ), कोई off-the-shelf solution इस्तेमाल करें, या बस छूटे हुए काम को business की cost मान लें – यह आपका निर्णय है। हम इस जवाब का एक version बना रहे हैं, लेकिन यह एकमात्र version नहीं है, और बहुत सी टीमों के लिए अभी सही नहीं है।
अगर आप जानना चाहते हैं कि यह आपके लिए कब सही हो सकता है, तो यह है मेरी ईमानदार heuristic: अगर आपकी साप्ताहिक समीक्षा 30 मिनट से ज़्यादा लेती है और फिर भी चीज़ें छूट जाती हैं, तो आप manual approach से आगे निकल चुके हैं।
---
जब साप्ताहिक समीक्षा 30 मिनट से ज़्यादा लेती है और चीज़ें फिर भी छूट जाती हैं, तो आप manual approach से आगे निकल चुके हैं। Sugarbug गैप्स को automatically monitor करता है।
Q: Sugarbug प्रोजेक्ट मैनेजमेंट में छूटे हुए काम को कैसे रोकता है? A: Sugarbug आपके सभी टूल्स – Linear, GitHub, Slack, Figma, Notion – में एक नॉलेज ग्राफ़ बनाता है और कार्यों, बातचीत व निर्णयों को उनके बीच ट्रैक करता है। जब कुछ रुक जाता है या मूल अनुरोध से उसका संबंध टूट जाता है, तो Sugarbug उसे गैप में गिरने से पहले सामने ला देता है। यह कोई reminder system नहीं है – यह टूल्स भर में items के बीच relationships को समझता है और flag करता है जब वे टूटती हैं।
Q: क्या Sugarbug उन कार्यों को पकड़ सकता है जो Slack में discuss हुए लेकिन कभी log नहीं हुए? A: हाँ। Sugarbug Slack की बातचीत monitor करता है और पहचानता है कि कब कोई निर्णय या action item discuss हुआ लेकिन Linear में task या GitHub में ticket के रूप में कभी नहीं दिखा। यह gap flag करता है ताकि कोई action ले सके। हम अभी यह refine कर रहे हैं कि इसे कितना aggressively flag करना चाहिए (किसी को बाकी सब के ऊपर और notification fatigue नहीं चाहिए), लेकिन core detection काम करती है।
Q: क्या छूटे हुए काम को ठीक करने के लिए मुझे टूल चाहिए, या यह process की समस्या है? A: ईमानदारी से, यह scale पर निर्भर करता है। दो या तीन टूल वाली छोटी टीमें आमतौर पर बेहतर आदतों से इसे ठीक कर सकती हैं – साप्ताहिक review, shared doc, linking discipline। लेकिन जब आप चार-पाँच टूल्स और दस-से-ज़्यादा लोगों से आगे निकल जाते हैं, तो manual approach scale करना बंद कर देता है और आपको कुछ ऐसा चाहिए जो connections को automatically track करे। Threshold हर टीम के लिए अलग होती है, लेकिन जब आप उस पर पहुँचेंगे तो पता चल जाएगा।
Q: टास्क ट्रैकर और प्रोजेक्ट मैनेजमेंट के लिए सिग्नल इंटेलिजेंस सिस्टम में क्या अंतर है? A: टास्क ट्रैकर वह record करता है जो आप उसे बताते हैं। सिग्नल इंटेलिजेंस सिस्टम देखता है कि आपके सभी टूल्स में वास्तव में क्या हो रहा है और flag करता है जब कुछ ठीक नहीं लगता – कोई task जो done mark है लेकिन unresolved comments हैं, कोई निर्णय जो Slack में लिया गया लेकिन spec में reflect नहीं हुआ। यह वे चीज़ें पकड़ता है जिन्हें इंसान log करना भूल जाते हैं – जो हमारे अनुभव में इन ज़्यादातर gaps की असली जड़ है।