ফসকে যাওয়া কাজ মানুষের সমস্যা না
প্রজেক্ট ম্যানেজমেন্টে ফসকে যাওয়া কাজ কেন ডিসিপ্লিন বা মেমোরির সমস্যা না, আর কখন তোমার টিমের সত্যিই একটা সিস্টেম দরকার সেগুলো ধরতে।
By Ellis Keane · 2026-03-17
তোমার টিম যদি এত ছোট হয় যে সবাই একসাথে লাঞ্চ করতে পারো (অথবা অন্তত hypothetically পারতে, যদি কখনও একই শহরে একই সময়ে থাকতে), তাহলে সম্ভবত এটা পড়ার দরকার নেই। ট্যাব বন্ধ করো। কিছু বানাতে যাও। তোমাদের স্কেলে ফসকে যাওয়া কাজের সমস্যা একটা বুধবার বিকেলের Slack reminder দিয়েই সমাধান হয়ে যায়, আর এটা আমি একদম আন্তরিকভাবে বলছি।
এখনও আছো? ঠিক আছে, তাহলে প্রজেক্ট ম্যানেজমেন্টে ফসকে যাওয়া কাজ নিয়ে কথা বলি – আর বিশেষ করে, টিম একটা নির্দিষ্ট সাইজে পৌঁছালে স্ট্যান্ডার্ড পরামর্শ কেন কাজ করে না সেটা নিয়ে।
আরেকটু এগোনোর আগে
এই সমস্যা নিয়ে আমরা একটা টুল বানাচ্ছি (Sugarbug – না বানাচ্ছি বললে মিথ্যা হবে), কিন্তু সত্যি কথা হলো এই লেখা পড়া বেশিরভাগ টিমের আমাদের যেটা বানাচ্ছি সেটা এখনই দরকার নেই। হয়তো কখনোই না। তাদের আগে বোঝা দরকার কেন কাজ ফসকে যায়, কারণ সমাধান নির্ভর করে কারণের ওপর, আর কারণটা মানুষ যেটা ভাবে সেটা প্রায় কখনোই না।
কেন কাজ ফসকে যায়
বেশিরভাগ ম্যানেজারকে জিজ্ঞেস করো কেন কাজ ফসকে যায়, একই চেনা লিস্ট শুনবে: কেউ ভুলে গেছে, কেউ মন দেয়নি, কেউ প্রসেস ফলো করেনি। তাই সমাধানও সেই একই: ভালো প্রসেস, বেশি reminder, হয়তো একটা standup bot যেটা প্রতিদিন সকালে খোঁচা দেয়।
আর দেখো, কখনও কখনও সত্যিই এটাই সমস্যা। তোমার এক engineer Linear ticket আপডেট করতে ভুলেছে আর PM sprint review-এর আগে চেক করেনি – এটা মানুষের lapse আর process-এর gap। ঠিক আছে। Checklist যোগ করো। এগিয়ে যাও।
কিন্তু যে ধরনের ফসকে যাওয়া কাজ engineering manager-দের রাত জাগায়, সেটা এটা না। আসল কষ্টের টাইপটা হলো যেখানে সবাই নিজের কাজ করেছে, প্রসেস মেনেছে, টুল আপডেট করেছে – তারপরও কিছু একটা gap দিয়ে পড়ে গেছে। কারণ gap-টা মানুষ আর তার task-এর মধ্যে না। Gap-টা এক টুল আর আরেক টুলের মধ্যে।
আমি কী বলতে চাই বলি। একজন engineer একটা PR ship করল যেটা একটা GitHub issue close করল। Issue-টা একটা Linear ticket-এর সাথে linked ছিল, আর ticket "Done"-এ চলে গেল। দারুণ। কিন্তু original request এসেছিল তিন সপ্তাহ আগে একটা Slack কথোপকথন থেকে, যেখানে PM একটা follow-up requirement-ও বলেছিল যেটা কেউ আলাদা task হিসেবে লগ করেনি। ওই follow-up রয়ে গেছে ফেব্রুয়ারির একটা Slack thread-এ। এটা Linear-এ নেই। GitHub-এ নেই। কারও sprint-এ নেই। টেকনিক্যালি এটা ফসকে যাওয়া কাজ, কিন্তু কোনো একক মানুষ এটা ফেলেনি – এটা Slack আর task tracker-এর মধ্যকার structural gap দিয়ে পড়ে গেছে।
এই pattern সবখানে দেখা যায় একবার খেয়াল করলে। একজন designer Figma-তে comment দিল যে একটা edge case Notion-এর spec-এর সাথে contradict করছে, কিন্তু feature নিয়ে কাজ করা engineer Figma চেকই করল না, আর PM comment দেখল না কারণ সে থাকে Linear-এ। Customer success lead কলে একটা feature promise করল, email-এ summary দিল, আর সেটা engineering backlog-এ কখনো গেল না কারণ ওই নির্দিষ্ট gap-টা কেউ bridge করেনি। Incident post-mortem-এ তিনটা follow-up item বের হলো, doc Slack-এ share হলো, আর তিনটার মধ্যে দুইটা tracked task হলোই না কারণ যে মানুষটা সাধারণত এটা করত সে ওই সপ্তাহে অসুস্থ ছিল।
প্রজেক্ট ম্যানেজমেন্টে সবচেয়ে ক্ষতিকর ফসকে যাওয়া কাজ হয় টুলগুলোর মাঝের gap-এ, মানুষ আর তাদের task list-এর gap-এ না।
প্রসেস দিয়ে ঠিক করা (আর কোথায় গিয়ে থামে)
আমি সত্যিই বিশ্বাস করি ভালো process বেশিরভাগ টিমের বেশিরভাগ সমস্যা সমাধান করে। কী কাজ করে বলি, আর এটা কোনো গোপন উদ্দেশ্য ছাড়াই বলছি কারণ (ন্যায্যভাবে বলতে) আমরা এখনো pre-launch-এ, আর এই মুহূর্তে সবচেয়ে ভালো কাজ হলো কাজে লাগে এমন কিছু দিয়ে বিশ্বাস তৈরি করা।
সাপ্তাহিক sweep। একজন মানুষ, ideally PM বা engineering lead, প্রতি শুক্রবার ৩০ মিনিট খরচ করে Slack thread, meeting note, আর email ঘেঁটে দেখে কী আলোচনা হয়েছে কিন্তু track হয়নি। বিরক্তিকর? একদম। কার্যকর? আশ্চর্যজনকভাবে হ্যাঁ, একটা পয়েন্ট পর্যন্ত।
Decision log। Slack thread বা meeting থেকে বের হওয়া প্রতিটা সিদ্ধান্ত একটা shared doc-এ পেস্ট হবে (Notion, Google Docs, যেটাই হোক) – তারিখ, কে সিদ্ধান্ত নিল, আর follow-up কী সেটা সহ। শুনতে সহজ, আসলেও সহজ – যতক্ষণ না তুমি চারটা channel-এ সপ্তাহে পনেরোটা সিদ্ধান্ত নিচ্ছো আর কেউ মনে রাখতে পারছে না কোনগুলো লগ হয়েছে।
Linking discipline। প্রতিটা PR তার Linear ticket reference করবে। প্রতিটা Linear ticket সেই Slack thread-এ link করবে যেখানে requirement আলোচনা হয়েছে। প্রতিটা Notion spec তার Linear epic-এ link করবে। কেউ chain ভাঙলেই (আর কেউ না কেউ ভাঙবেই – if না, when), visibility-ও সাথে ভেঙে যায়।
এগুলো সবই ভালো practice। আমরা নিজেরাও তিনটারই version ব্যবহার করি। কিন্তু এদের একটা common failure mode আছে: এগুলো নির্ভর করে মানুষের ওপর যেন একটা ছোট, boring কাজ প্রতিবার, সবসময়, চিরদিন করে যায়। আর এ বিষয়ে research উৎসাহব্যঞ্জক না (যদিও research cite না করলেও চলে – পাঁচজনের বেশি টিম manage করলে তুমি নিজেই জানো)।
প্রসেস দিয়ে ঠিক করা কখন স্কেল করা বন্ধ করে
একটা threshold আছে, আর আমি ইচ্ছে করলেও exact number দিতে পারব না কারণ এখনো সেটা বের করতে পারিনি (সত্যি বলতে, এটা সম্ভবত টিমভেদে আর মানুষ কতটা disciplined তার ওপর বদলায়)। আমাদের working heuristic – আর পরিষ্কার বলছি এটা heuristic, benchmark করা data না – হলো প্রায় চার বা পাঁচটা টুল, দশের বেশি মানুষ, আর multiple parallel workstream হলেই ভাঙন শুরু হয়।
এটা হয় না কারণ কেউ আলসে হয়েছে। না কারণ process খারাপ ছিল। হয় কারণ টুলগুলোর মধ্যে connection-এর volume এমন জায়গায় যায় যেটা একজন মানুষের পক্ষে manually track করা অসম্ভব হয়ে পড়ে। সাপ্তাহিক sweep ৩০ মিনিটের বদলে ৯০ মিনিট লাগে, আর PM skim করা শুরু করে। Decision log পুরনো হয়ে যায় কারণ যে maintain করত সে ছুটিতে গেছে আর কেউ তুলে নেয়নি। Linking discipline Linear আর GitHub-এ থাকে, কিন্তু Slack আর Figma-তে ভেঙে পড়ে কারণ ওই টুলগুলোর structured reference একই রকম না।
এটা (আর আমি পরিষ্কারভাবে বলতে চাই) discipline problem না – এটা scaling problem। আমি সত্যিই চমৎকার PM আর engineering lead-দের এতে হিমশিম খেতে দেখেছি, এমন মানুষ যারা টাইট শিপ চালায় আর কিছু ফসকে যাক সেটা একদম চায় না। একটা স্কেলের পর সমস্যা সমাধানকে ছাড়িয়ে যায়। এটা ব্যক্তির ব্যর্থতা না – এটা tooling ecosystem-এর ব্যর্থতা, যেটা নিজের মধ্যে connection দিতে পারে না।
"তোমার tooling যত sophisticated, ফসকে যাওয়া কাজের failure surface তত জটিল। ব্যাপারটা আমার কাছে গভীরভাবে ironic।" – Ellis Keane
আর যে অংশটা আমার কাছে সত্যিই unfair মনে হয়: তোমার টিম টুল যত ভালো ব্যবহার করে, cross-tool gap-এর surface area তত বাড়ে। যে টিম Linear কঠোরভাবে মেনে চলে, Notion spec আপডেট রাখে, active Figma review করে, আর সুন্দরভাবে সংগঠিত Slack channel-এ communicate করে – তাদের handoff point সেই টিমের চেয়ে বেশি যারা শুধু email আর spreadsheet ব্যবহার করে।
তোমার টুলগুলো কেন সাহায্য করতে পারে না
এই পুরো সমস্যায় যেটা আমার কাছে সত্যিই interesting, আর যেটা নিয়ে যথেষ্ট কথা হয় না: তোমার টুলগুলো ঠিক যেটার জন্য বানানো হয়েছে সেটাই করছে। Linear, Linear issue track করতে চমৎকার। GitHub, code change track করতে চমৎকার। Notion, document organise করতে চমৎকার। Slack... Slack হতে চমৎকার (ভালো-মন্দ যাই হোক)।
কিন্তু এদের কোনোটাই একে অপরের মধ্যে connection track করার জন্য বানানো হয়নি। আর কাজ, আসল কাজ, এক টুলের ভেতরে হয় না – সব টুলে flow করে। টুলের মাঝে handoff point-গুলোতেই জিনিস হারিয়ে যায়, আর কোনো একটা individual tool যতই ভালো করো, সমস্যা সমাধান হয় না। তুমি Linear-কে issue tracking-এ আরো ভালো করতে পারো, কিন্তু তাতে লাভ নেই যখন issue-টাই প্রথমে তৈরি হওয়ার কথা ছিল এমন একটা Slack কথোপকথন থেকে যেটা engineering lead monitor করে না।
আসলে কী এটা ঠিক করবে
এই পোস্টে আমি product নিয়ে ইচ্ছে করেই অস্পষ্ট ছিলাম – আমি চেয়েছিলাম এটা কাজে লাগুক, তুমি আমাদের বানানো কিছু ব্যবহার করো বা না করো। কিন্তু যখন এতদূর এসেছো (আর এটা আমি appreciate করি), তখন সৎভাবে বলি আমার মতে আসল fix কেমন দেখতে।
এটা better task tracker না। Better process না। Standup bot, weekly review, বা shared spreadsheet-ও না। এগুলো সবই সাহায্য করে, আর ছোট স্কেলে যথেষ্টও, কিন্তু এগুলো সবই symptom treat করে।
আসল fix হলো এমন কিছু যেটা তোমার টুলগুলোর মধ্যে connection watch করে আর কোথাও হিসাব না মিললে flag করে। Slack-এ সিদ্ধান্ত হলো কিন্তু ticket হলো না। GitHub PR issue close করল কিন্তু unresolved comment আছে। Notion spec এমন requirement reference করছে যেটা spec-এর লেখক দেখেনি এমন কথোপকথনে deprioritise হয়ে গেছে।
Concrete করে বলি। ধরো তোমার system Slack আর Linear দুটোই watch করছে। এটা #engineering-এ দেখল কেউ বলছে "user এখনও email verify না করলে সেই case-টাও handle করা উচিত" – এটা নতুন requirement। এই requirement ৪৮ ঘণ্টার মধ্যে Linear ticket হিসেবে না আসলে, system flag করে। চেঁচামেচি notification দিয়ে না (কারও সেটা দরকার নেই) – বরং "decisions not yet tracked" view-তে একটা entry হিসেবে, যেটা PM শুক্রবারের sweep-এ দেখতে পারে। একই idea GitHub PR-এর জন্য যেগুলো Linear ticket close করে কিন্তু review comment এখনও open, বা Notion spec যেগুলো এমন feature reference করে যেগুলো spec লেখার পর deprioritise হয়ে গেছে।
তুমি এটা internally build করবে কিনা (কিছু টিম webhook, message queue, আর সামান্য glue code দিয়ে করে), off the shelf কিছু নেবে, বা ফসকে যাওয়া কাজকে ব্যবসার cost হিসেবে মেনে নেবে – সিদ্ধান্ত তোমার। আমরা এই উত্তরের একটা version বানাচ্ছি, কিন্তু এটা একমাত্র version না, আর অনেক টিমের জন্য এখনো সঠিক version-ও না।
তোমার জন্য কখন সঠিক হতে পারে, তার আমার সৎ heuristic দিই: সাপ্তাহিক sweep ৩০ মিনিটের বেশি লাগে আর তারপরও জিনিস ফসকে যাচ্ছে, তাহলে তুমি manual approach ছাড়িয়ে গেছো। For the broader picture of why tasks fall through the cracks and how to prevent it, we've written a full guide. And if you've already had a miss and need a recovery framework, how to recover from a dropped ball walks through the forensic steps. You can also go deeper on what tasks fall through the cracks and why for the structural analysis.
---
সাপ্তাহিক sweep ৩০ মিনিটের বেশি লাগছে আর তারপরও জিনিস ফসকে যাচ্ছে, তাহলে তুমি manual approach ছাড়িয়ে গেছো। Sugarbug gap-গুলো automatically দেখে।
Q: প্রজেক্ট ম্যানেজমেন্টে Sugarbug কীভাবে ফসকে যাওয়া কাজ আটকায়? A: Sugarbug তোমার টুলগুলো জুড়ে একটা নলেজ গ্রাফ বানায় – Linear, GitHub, Slack, Figma, Notion – আর টাস্ক, কথোপকথন, আর সিদ্ধান্ত এক টুল থেকে আরেক টুলে যাওয়ার সময় ট্র্যাক করে। কোথাও কিছু থেমে গেলে বা original request-এর সাথে সংযোগ হারালে, gap-এ পড়ার আগেই Sugarbug সেটা সামনে তুলে আনে। এটা শুধু reminder system না – এটা টুলজুড়ে item-এর সম্পর্ক বোঝে, আর সেই সম্পর্ক ভাঙলে flag করে।
Q: Slack-এ আলোচনা হয়েছে কিন্তু কখনও লগ করা হয়নি, এমন টাস্ক কি Sugarbug ধরতে পারে? A: হ্যাঁ। Sugarbug Slack-এর কথোপকথন monitor করে আর শনাক্ত করে কখন কোনো সিদ্ধান্ত বা action item আলোচনা হয়েছে কিন্তু Linear-এ task বা GitHub-এ ticket হিসেবে কখনো আসেনি। এটা gap flag করে যেন কেউ act করতে পারে। কত aggressively flag করা উচিত সেটা আমরা এখনো refine করছি (notification fatigue কেউ চায় না), কিন্তু core detection কাজ করছে।
Q: ফসকে যাওয়া কাজ ঠিক করতে কি টুল লাগবেই, নাকি এটা process-এর সমস্যা? A: সত্যি বলতে, এটা স্কেলের ওপর নির্ভর করে। দুই বা তিনটা টুল নিয়ে ছোট টিম সাধারণত ভালো অভ্যাস দিয়ে সামলে নিতে পারে – সাপ্তাহিক review, shared doc, linking discipline। কিন্তু চার বা পাঁচটার বেশি টুল আর দশের বেশি মানুষ হলে manual approach আর scale করে না, তখন এমন কিছু লাগে যেটা connection automatically track করে। Threshold টিমভেদে আলাদা, কিন্তু কখন hit করেছো সেটা তুমি বুঝতে পারবে।
Q: প্রজেক্ট ম্যানেজমেন্টে task tracker আর সিগন্যাল ইন্টেলিজেন্স সিস্টেমের পার্থক্য কী? A: Task tracker তুমি যা বলো সেটাই record করে। সিগন্যাল ইন্টেলিজেন্স সিস্টেম তোমার টুলগুলো জুড়ে আসলে কী হচ্ছে সেটা দেখে আর কোথাও হিসাব না মিললে flag করে – done mark করা task-এ unresolved comment পড়ে আছে, বা Slack-এ সিদ্ধান্ত হয়েছে কিন্তু spec-এ তার প্রতিফলন নেই। এটা সেই জিনিসগুলো ধরে যেগুলো মানুষ log করতে ভুলে যায় – আর আমাদের অভিজ্ঞতায়, বেশিরভাগ gap আসলে সেখান থেকেই শুরু হয়।