কেন কাজ ফাঁক দিয়ে হারিয়ে যায় (আর কেন আরেকটা PM টুল এটা ঠিক করবে না)
কাজ বারবার ফাঁক দিয়ে হারাচ্ছে? সমস্যা তোমার টিম বা তোমার টুলে না – সমস্যা টুলগুলোর মাঝের ফাঁকে। এখানে systems-level সমাধান।
By Ellis Keane · 2026-03-12
বাজারের প্রতিটা project management টুল প্রতিশ্রুতি দেয় যে এখানে কিছু হারাবে না, যেটা একটা মজার pitch কারণ average টিম এখন একই সাথে ছয়-সাতটা এই ধরনের জিনিস ব্যবহার করে, প্রতিটা শপথ করে সে-ই single source of truth, আর আসল truth সবগুলোর মধ্যে ছড়িয়ে থাকে আর কোনোটাতেই ঠিকমতো রেকর্ড নেই। কাজ ফাঁক দিয়ে হারানো কোনো একটা টুলের ব্যর্থতা না – এটা কাজকে এমন টুলগুলোর মধ্যে ছড়িয়ে দেওয়ার স্বাভাবিক পরিণতি যেগুলো জানেও না অন্যগুলোর অস্তিত্ব আছে।
এটা আসলে software সমস্যা না। এটা species সমস্যা।
একটা হারানো কাজের ময়নাতদন্ত: ফরেনসিক টাইমলাইন
আমি একটা নির্দিষ্ট কাজের কথা বলতে চাই যেটা গত বছর একটা টিমে ফাঁক দিয়ে হারিয়ে গিয়েছিল – dramatic ছিল বলে না, বরং এতটাই সাধারণ ছিল যে drop ঘটার পর প্রায় এক সপ্তাহ কেউ টেরই পায়নি।
সোমবার, সকাল ১০:১৪। একজন designer একটা Figma file-এ comment করে, settings panel-এর contrast ratio নিয়ে accessibility সমস্যা flag করে। সে lead engineer-কে @-mention করে। Comment Figma-তে বসে থাকে, যেটা এই টিমের কাজ track করার জায়গা না।
সোমবার, সকাল ১১:০২। Engineer notification দেখে, Figma file খোলে, comment পড়ে, reply করে "good catch, I'll file a ticket" – পূর্ণ আন্তরিকতার সাথে, কারণ সে সত্যিই করবে বলে ভাবছে, আর ঠিক পঁয়তাল্লিশ মিনিট পরে একটা PR review-তে টানা পড়ে পুরোটা ভুলে যাবে।
সোমবার, দুপুর ২:৩০। একই accessibility সমস্যা আসন্ন release নিয়ে একটা Slack thread-এ আবার ওঠে – Figma comment-এর সাথে কেউ কানেক্ট করেনি, বরং একজন QA engineer স্বাধীনভাবে Lighthouse audit চালিয়ে একই contrast failure ধরেছে। তিনজন আলোচনা করে, সবাই একমত launch-এর আগে fix করা উচিত, আর কেউ একজন (কে সেটা পরিষ্কার না, যেটাই সমস্যার অংশ) বলে "make sure it's tracked।"
মঙ্গলবার, সকাল ৯:১৫। Standup। কেউ contrast issue mention করে না। Linear-এ নেই, তাই কারও board-এ দেখায় না। Designer ভাবে engineer ticket করেছে। Engineer, যে এখন একটা unrelated refactor-এ ডুবে আছে, সত্যিই ভুলে গেছে। QA engineer ভাবে Slack thread-এ বিষয়টা সামলানো হয়েছে। সবার assumption পুরোপুরি যুক্তিসঙ্গত আর পুরোপুরি ভুল।
বৃহস্পতিবার, বিকেল ৪:০০। Release ship হয়, contrast issue-ও ship হয়। তিন দিন পর একজন low-vision customer support-এর মাধ্যমে রিপোর্ট করে, আর actual fix-এ engineer-এর কুড়ি মিনিট লাগলেও, এর চারপাশের ঝামেলা – support ticket, escalation, কীভাবে miss হলো সেটার retrospective আলোচনা, ক্ষমাপ্রার্থী commit message সহ pull request – সব মিলিয়ে প্রায় একদিন লাগে।
শুক্রবার, retrospective। টিম একমত হয় "better ticket hygiene" দরকার। কেউ Slack bot প্রস্তাব করে। অন্য কেউ weekly triage meeting-এর কথা বলে। দুটোই বুদ্ধিমানের পরামর্শ, যেগুলো আসলে যা ঘটেছে তার প্রায় কিছুই address করে না।
title: "একটা Bug কীভাবে Untracked অবস্থায় Production-এ পৌঁছলো" Mon 10:14 AM|ok|Designer Figma-তে accessibility issue flag করে; lead engineer-কে @-mention Mon 11:02 AM|amber|Engineer ticket করার প্রতিশ্রুতি দেয়; PR review-তে টানা পড়ে ভুলে যায় Mon 2:30 PM|amber|QA স্বাধীনভাবে Slack-এ একই issue তোলে; ownership অস্পষ্ট থাকে Tue 9:15 AM|missed|Standup: issue Linear-এ নেই, mention হয় না – সবাই ভাবে অন্য কেউ করেছে Thu 4:00 PM|missed|Release ship হয়; contrast issue live যায় Fri|amber|Retrospective: টিম "better ticket hygiene" নিয়ে একমত – লক্ষণের চিকিৎসা, কারণের না
আসল ভিলেন tooling না
টাইমলাইন দেখলে বোঝা যায়, সিগন্যাল পুরো সময়ই ছিল – সোমবার সকালে Figma-তে, সোমবার বিকেলে Slack-এ। তিনজন আলাদা মানুষ একই issue চিহ্নিত করেছিল, আলোচনা করেছিল, আর সবাই একমত ছিল এটা গুরুত্বপূর্ণ। তথ্য সঠিক ছিল, দৃশ্যমান ছিল, আর পুরোপুরি অকেজো ছিল, কারণ এটা কখনো সেই একমাত্র জায়গায় পৌঁছায়নি যেখানে visibility action-এ রূপান্তরিত হয়।
তোমার task tracker-এর একটা মৌলিক সীমাবদ্ধতা আছে যেটা marketing material-এ খুব কমই আলোচনা হয়: এটা শুধু সেই কাজ track করতে পারে যেটা কেউ আগে থেকে সেখানে টাইপ করেছে। Figma comment Linear-এর universe-এ নেই। যে Slack conversation-এ তিনজন সিদ্ধান্ত নিল কিছু করা উচিত – সেটাও সেখানে নেই। প্রতিটা টুল একটা closed system যার ভিতরে দারুণ search আছে আর পাশের ঘরে কী হচ্ছে সে সম্পর্কে কোনো ধারণা নেই। Project management industry গত বিশ বছর ধরে ক্রমাগত ভালো walled garden বানিয়েছে, তারপর অবাক হয়েছে কেন দেয়ালগুলোর মাঝের ফাঁকে জিনিস হারায়।
Project management industry গত বিশ বছর ধরে ক্রমাগত ভালো walled garden বানিয়েছে, তারপর অবাক হয়েছে কেন দেয়ালগুলোর মাঝের ফাঁকে জিনিস হারায়। attribution: Ellis Keane
"better integration" দিয়ে সমাধান হবে ভাবলে সুবিধা ছিল, কারণ তাহলে টাকা দিয়ে সমস্যা কেনা যেত। কিন্তু যে engineer বলেছিল "I'll file a ticket" সে অসাবধান ছিল না – একটা PR review-তে তার attention দরকার ছিল, আর Figma comment-এ snooze button নেই, তাই পুরোটা তার memory-র ওপর নির্ভর করেছিল কনটেক্সট সুইচিং survive করার জন্য। যে QA engineer বলেছিল "make sure it's tracked" সে অস্পষ্ট ছিল অবহেলায় না – Slack-এ "someone should track this" বলাটা মনে হয় concrete action, যদিও এটা কাউকে specifically delegate করে না। আমি টিমগুলোকে এই ফাঁক পূরণ করতে intake form, Slack-to-Jira bot, standup-এ "anything not yet ticketed?" mandatory question ব্যবহার করতে দেখেছি – আর সত্যি বলতে, কিছু কিছু কিছুদিন কাজ করে (আমরা তিন মাস Slack bot চালিয়েছিলাম, তারপর মানুষ reflexively ignore করতে শিখে গেছে, যেটা প্রতিটা automated nag-এর চূড়ান্ত পরিণতি)।
অস্বস্তিকর সত্য (আর আমি নিশ্চিত না এর কোনো পরিষ্কার সমাধান আছে, সত্যি বলতে) হলো কর্মক্ষেত্রে কাজ ফাঁক দিয়ে হারানো বেশিরভাগ ক্ষেত্রে মানুষের মনোযোগ যখন অনেক channel-এ ছড়িয়ে থাকে তখন কীভাবে কাজ করে তার পরিণতি। আমরা inconsistent প্রাণী – বিক্ষিপ্ত, ক্লান্ত, bystander effect-এর শিকার – আর কোনো discipline training দিয়ে এই সত্য ঢাকা যায় না যে তুমি আজকে ত্রিশ বার context switch করেছো আর প্রতিবারে তোমার মাথায় যা ছিল তার একটু করে হারিয়েছে।
"কেউ সমস্যা চিহ্নিত করেছে" আর "কেউ সমস্যা track করেছে" – এই দুইয়ের মাঝের ফাঁকেই বেশিরভাগ ফসকে যাওয়া কাজ থাকে। এই ফাঁক মানুষের মনোযোগের সমস্যা, tooling-এর সমস্যা না, আর এই কারণেই আরও টুল যোগ করলে এটা কমে না।
আসলে কী কাজ করে (সৎ সতর্কতা সহ)
এখানে চারটি practice যেগুলো কিছু খরচ করে না আর সত্যিই পার্থক্য আনে। প্রতিটার সীমা কোথায়, সেটাও খোলামেলা বলছি, কারণ কোনোটাকে complete solution বলাটা অসৎ হবে।
Rotating সিগন্যাল owner। প্রতি সপ্তাহে ঘুরিয়ে একজন, যার কাজ হলো Slack thread আর meeting notes scan করা এমন কিছুর জন্য যা track হওয়া উচিত কিন্তু হয়নি। এটা দারুণ কাজ করে যখন চালু থাকে, কারণ bystander problem-কে explicit assignment-এ রূপান্তরিত করে – একজন মানুষ ফাঁকের owner। সীমা হলো সিগন্যাল owner একই সাথে Figma comment, PR review thread আর email monitor করতে পারে না (পারে চেষ্টা করতে, কিন্তু তখন সেটা full-time job হয়ে যায়)।
২৪ ঘণ্টার triage SLA। Potentially actionable যেকোনো কিছু এক দিনের মধ্যে sort হবে: ticket হবে, existing ticket-এর সাথে link হবে, অথবা – আর এই অংশটা বেশিরভাগ টিম বাদ দেয় – কারণ সহ explicitly dismiss হবে। ওই dismissal অত্যন্ত গুরুত্বপূর্ণ। মানে কেউ সিগন্যালটা দেখেছে আর সিদ্ধান্ত নিয়েছে "না।" সিগন্যালকে অনির্দিষ্টকালের জন্য ভাসতে রাখা, কেউ acknowledge না করা – তার চেয়ে অনেক ভালো।
Slack-এ emoji tagging। আমরা ticket emoji ব্যবহার করি মানে "এটার ticket দরকার।" যে কেউ যেকোনো message tag করতে পারে, দুই সেকেন্ড লাগে। সিগন্যাল owner প্রতিদিন সকালে tagged message check করে। বিব্রতকর রকম low-tech আর বিরক্তিকর রকম effective, ঠিক যতক্ষণ না কেউ শুক্রবার বিকেল ৪:৫৫-তে message tag করে আর সোমবার পর্যন্ত কেউ check করে না।
PR review checkpoint। Merge করার আগে: "এই review-তে কোনো comment কি ticket হওয়া দরকার?" একটা প্রশ্ন, হয়তো দশ সেকেন্ড। Refactoring warning আর "we should really fix this later" টাইপ note ধরে ফেলে যেগুলো নাহলে GitHub-এর bottomless archive-এ হারিয়ে যায়।
এগুলো সব ভালো অভ্যাস আর প্রতিটাই recommend করি। কিন্তু একটা common সীমা আছে: এগুলো মানুষের ওপর নির্ভর করে consistently একটা কাজ মনে রাখতে, আর (আবার সেই species সমস্যা) আমরা সেটা করি না। তুমি আরও বেশি drop ধরবে। সব ধরবে না।
যা কাজ করে
- Rotating সিগন্যাল owner – একজন মানুষ, সপ্তাহ ঘুরিয়ে, explicitly টুলগুলোর মাঝের ফাঁকের owner
- ২৪ ঘণ্টার triage SLA – Actionable সিগন্যাল এক দিনের মধ্যে sort হয় বা explicitly dismiss হয়
- Slack-এ emoji tagging – Low-tech, দুই সেকেন্ডের flagging যে সিগন্যালটার ticket দরকার
- PR review checkpoint – Merge-এর আগে এক প্রশ্ন, tracking দরকার এমন comment ধরে ফেলে
যা কাজ করে না
- Individual discipline – মানুষের consistently মনে রাখার ওপর নির্ভরশীল; আমরা সেটা করি না
- Automated nag bot – শেষ পর্যন্ত ignore হয়ে যায়, প্রতিটা automated reminder-এর মতো
- আরও PM টুল যোগ করা – যা কখনো ওখানে enter করা হয়নি তা track করতে পারে না
- "Better integration" – UI-র ফাঁক বন্ধ করে কিন্তু মানুষের মনোযোগের ফাঁক না
টুলের বদলে ফাঁকগুলো দেখা
Sugarbug বানানোর সময় Chris আর আমি বারবার যে প্রশ্নে ফিরে যেতাম: টুলগুলোর বদলে টুলগুলোর মাঝের ফাঁকগুলো দেখা গেলে কেমন হতো?
Sugarbug তাই করে – API দিয়ে তোমার existing setup-এর সাথে কানেক্ট করে আর একটা graph বানায় যেটা বিভিন্ন উৎস থেকে সিগন্যাল লিঙ্ক করে। Figma comment, Slack thread, আর PR review comment সবই একই graph-এ node হয়ে যায়, একে অপরের সাথে আর সংশ্লিষ্ট মানুষদের সাথে লিঙ্কড। কেউ কোনো সিগন্যাল track করছে না বুঝলে, Sugarbug সঠিক মানুষকে সেটা surface করে retrospective-র বিষয় হওয়ার আগেই।
সৎভাবে বলতে চাই, কিছু কঠিন classification সমস্যা নিয়ে আমরা এখনও কাজ করছি। "মিটিংয়ে কেউ চিন্তা করে বলছে" আর "কেউ আসল action item চিহ্নিত করছে" – এই দুটোর মধ্যে সীমারেখা ঠিক কোথায়? সেটা সত্যিই একটা কঠিন সমস্যা, আর আমি নিশ্চিত না কোনো system – আমাদের সহ – ১০০% সময় ঠিক ধরবে। কিন্তু core loop – টুল জুড়ে সিগন্যাল observe করা, কোনটা actionable তা classify করা, আর কোনটা untracked সেটা surface করা – এটা কাজ করে, আর সময়ের সাথে ভালো হয় কারণ তুমি কোনটায় action নিচ্ছো আর কোনটা dismiss করছো তা থেকে শেখে।
---
Sugarbug তোমার টুলগুলোর মাঝের ফাঁক দেখে যাতে কিছু হারিয়ে না যায়। কীভাবে কাজ করে দেখো
---
কাজ ফাঁক দিয়ে হারানোর আসল খরচ
ফরেনসিক টাইমলাইনের accessibility issue-তে ফিরে যাই, কারণ downstream cost-টা লেখার মতো।
Engineering fix-এ কুড়ি মিনিট লেগেছিল। Total cost – support ticket, customer escalation, internal investigation, retrospective আর fix-এর PR – তিনজনের মধ্যে ছড়িয়ে প্রায় একটা পূর্ণ কর্মদিবস। একটা হারানো সিগন্যাল, প্রায় ছয় ঘণ্টা নষ্ট। হিসেবটা আলাদাভাবে ভয়ংকর লাগে না, কিন্তু আমার অভিজ্ঞতায় আট-দশ জনের একটা টিম প্রতি sprint-এ তিন-চারটা সিগন্যাল হারায়, যেটা প্রতি দু'সপ্তাহে ছয়-আট ঘণ্টা নষ্ট সময়ের মতো।
আরও কঠিন যে খরচটা quantify করা (আর আমার সন্দেহ সেটাই বেশি expensive) হলো ambient background anxiety – "আমি কিছু ভুলছি না তো?" এই নিম্নস্তরের গুঞ্জন যেটা multi-tool টিমের প্রতিটা engineer বহন করে। Over-checking, "hey, just confirming we didn't lose track of the thing from Tuesday" DM, আর শুধু এই কারণে status meeting যে কেউ system-কে বিশ্বাস করে না context ধরে রাখতে। এই cognitive overhead কোনো sprint report-এ দেখায় না কিন্তু মানুষ তাদের কাজ সম্পর্কে কেমন অনুভব করে সেটায় একদম দেখায়। For a practical system to address this, see our guide on keeping work from slipping through the cracks. We also cover the dropped-ball pattern in project management for the organisational angle, and recovering after dropping the ball for when something has already been missed.
তোমার inbox-এ সিগন্যাল ইন্টেলিজেন্স পাও।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
Sugarbug কীভাবে কাজ ফাঁক দিয়ে হারানো আটকায়?
Sugarbug API দিয়ে তোমার টুলগুলোর সাথে কানেক্ট করে আর একটা নলেজ গ্রাফ তৈরি করে যেটা সিগন্যাল, মানুষ আর work item-এর মধ্যে relationship ম্যাপ করে। কোনো টুলে actionable কিছু দেখা দিলে কিন্তু কোথাও track হচ্ছে না বুঝলে, Sugarbug সেটা flag করে আর relevant context-এর সাথে কানেক্ট করে যাতে সঠিক মানুষ ফসকে যাওয়া কাজ হওয়ার আগেই action নিতে পারে।
Sugarbug কি একটা project management টুল?
না – এটা তোমার আগে থেকে ব্যবহার করা PM টুলের পাশে বসে। Sugarbug Linear বা Asana বা Jira রিপ্লেস করে না; এটা তোমার টুলগুলোর মধ্যে চলাচল করা সিগন্যাল দেখে আর যেগুলো ফাঁকে হারিয়ে যাচ্ছে সেগুলো ধরে।
টিম project management টুল ব্যবহার করলেও কেন কাজ ফাঁক দিয়ে হারায়?
PM টুল শুধু সেই কাজ track করতে পারে যেটা explicitly সেখানে enter করা হয়েছে, মানে upstream-এর সব কিছুর প্রতি অন্ধ – যে Slack thread-এ কেউ concern flag করেছিল, যে PR comment সমস্যা predict করেছিল, যে meeting-এ decision হয়েছিল কিন্তু কখনো record হয়নি। conversation আর ticket-এর মাঝের ওই ফাঁকেই বেশিরভাগ কাজ ফসকে যায়।
Sugarbug কি আমাদের existing project management setup-এর সাথে কাজ করতে পারে?
হ্যাঁ। তোমার বর্তমান ওয়ার্কফ্লো পুরোপুরি আগের মতোই থাকবে। Sugarbug তোমার existing টুলের সাথে কানেক্ট করে আর ওপরে একটা সিগন্যাল-watching layer যোগ করে – তোমার কাজ করার ধরন বদলাতে বলে না, শুধু তুমি কাজ করতে করতে কম জিনিস হারাও সেটা নিশ্চিত করে।
"আমি কিছু ভুলছি না তো?" এই feeling যদি চেনা লাগে, ঠিক এই সমস্যাটাই সমাধান করতে আমরা Sugarbug বানিয়েছি। ওয়েটলিস্টে যোগ দাও।