ওয়ার্কফ্লো স্ট্যাটাস লেবেল: আপনার টিম যে ৭টি স্পষ্ট স্ট্যাটাস শেয়ার করতে পারে

অসম্পষ্ট স্ট্যাটাস কেন কাজ ঢিলে দেয়

অস্পষ্ট ওয়ার্কারফ্লো স্ট্যাটাস লেবেলগুলো এমন বিভ্রান্তি তৈরি করে যা ব্যস্ততার ছদ্মবেশে ধরা দেয়। মানুষ আইটেমগুলো এগোয়, কিন্তু কেউ নিশ্চিত থাকে না আসলে কী পরিবর্তিত হয়েছে। “In Progress” লেখা টিকেটটি কারো কাছে “আমি ভাবা শুরু করেছি,” অন্য কারো কাছে “আমি আটকে আছি,” আর আরও একজনের কাছে “আমি শেষ করে রিভিউয়ের জন্য অপেক্ষা করছি” বোঝাতে পারে—সবে সরাসরি নির্ভর করে শেষ কোন কেউ সেটি আপডেট করেছে।

এই মেলামেশা তিনটি পূর্বানুমানযোগ্য সমস্যা তৈরি করে: পুনরায় কাজ, মিসড হ্যান্ডঅফ, এবং ঝ noise়়লাউড নোটিফিকেশন। যদি স্ট্যাটাসটি পরের ক ব্যক্তি কী করবে তা না বলে, কাজটা বারবার ফিরছে। যদি হ্যান্ডঅফ অস্পষ্ট লেবেলে লুকানো থাকে, তা তখনও বসে থাকে যতক্ষণ কেউ লক্ষ্য করে না। যদি সবাই কেবল সক্রিয়তা দেখানোর জন্য স্ট্যাটাস আপডেট করে, আপনার ফিডটা ঝড়ঝাপটা হয়ে যায় এবং আসল পরিবর্তনগুলো সহজে অদৃশ্য হয়ে পড়ে।

আরেকটি সাধারণ লক্ষণ হল একই লেবেল বিভিন্ন স্ক্রিনে ভিন্নভাবে ব্যবহৃত হওয়া। একজন সহকর্মী “Ready” বলতে “রিভিউয়ের জন্য প্রস্তুত” বোঝায়; আরেকজন বলছে “শুরু করার জন্য তৈরি।” বোর্ড চেক করা ম্যানেজার বুঝতে পারেন না দল কি অপেক্ষা করছে, কাজ করছে, না শেষ করেছে।

লক্ষ্য প্রতিটি প্রান্তিক কেস ব্যাখ্যা করা নয়। লক্ষ্য হলো কম স্ট্যাটাসে সাধারণ পথটি পরিষ্কার করা। যখন স্ট্যাটাসগুলো সব জায়গায় সঙ্গত থাকে, তখন হ্যান্ডঅফ দ্রুত হয় এবং “এটা কি সত্যিই শেষ?”—রকম প্রশ্ন কমে যায়।

যদি আপনার দল জানে না কোথা থেকে শুরু করবে, তাহলে 5–7টি স্ট্যাটাস লক্ষ্য করুন যা বেশিরভাগ কাজ কভার করে: একটা নতুন আইটেমের জন্য, একটা সক্রিয় কাজের জন্য, একটা অপেক্ষা বা ব্লক হওয়া কাজের জন্য, একটা রিভিউ/অনুমোদনের জন্য, আর একটা শেষ হওয়ার জন্য। মৌলিকগুলো স্থিতিশীল হলে তারপরই বিস্তারিত যোগ করুন।

একটি স্ট্যাটাস লেবেল কী বোঝানো উচিত (এবং কী নয়)

স্ট্যাটাস লেবেল হলো পরবর্তী কি হবে সে সম্পর্কে টিমের একটি ভাগ করা অঙ্গিকার। যখন কেউ স্ট্যাটাস পরিবর্তন করে, সবাইকে অতিরিক্ত প্রশ্ন ছাড়া পরবর্তী ধাপটি অনুমান করতে সক্ষম হওয়া উচিত।

ভাল ওয়ার্কফ্লো স্ট্যাটাস লেবেলগুলো কাজের বর্তমান বাস্তবতা বর্ণনা করে, কারো ব্যক্তিগত মতামত নয়। যদি লেবেলটি সত্য হয়, টিম বোঝতে পারবে আইটেমটি চলছে, অপেক্ষা করছে, না ব্লক করছে, এবং পরবর্তী যে জন এটি টাচ করবে তিনি কে।

স্ট্যাটাস Priority, assignee, category, বা progress notes-এর সমান নয়। সেই ক্ষেত্রগুলোও গুরুত্বপূর্ণ, কিন্তু স্ট্যাটাসে মিশিয়ে দিলে স্ট্যাটাস অবিশ্বাস্য হয়ে ওঠে।

এছাড়াও “state” এবং “stage” আলাদা রাখা সহায়ক। State হলো এখন কি সত্য (উদাহরণ: “blocked on customer reply”)। Stage হলো আপনার প্রক্রিয়ায় আইটেমটি কোথায় আছে (উদাহরণ: “review”)। আপনি এগুলো মিশাতে পারবেন, কিন্তু যখন একক স্ট্যাটাস উভয়কেই বোঝাতে গিয়ে অস্পষ্ট হয়ে যায়, তখন তা সমস্যা তৈরি করে।

একটি ব্যবহারযোগ্য স্ট্যাটাস নিম্নের তিনটোর মধ্যে একটি ট্রিগার করা উচিত:

• পরবর্তী মালিক (কে এটি নেবে)
• পরবর্তী কাজ (পরবর্তী কী হবে)
• অপেক্ষার শর্ত (আমরা কি জন্য অপেক্ষা করছি)

দ্রুত বাস্তবতা পরীক্ষা: কেউ কি ছোট তালিকা ভিউ-তে লেবেল পড়ে এখনও জানবে কী করা উচিত? যদি উত্তর “নির্ভর করে” হয়, তবে লেবেলটি সম্ভবত এমন কোনও সিদ্ধান্ত লুকিয়ে রাখছে যা অন্য জায়গায় করা উচিত (যেমন অগ্রাধিকার নিয়ম বা অ্যাসাইনমেন্ট)।

কতগুলো স্ট্যাটাস ব্যবহার করবেন এবং কেন 5–7 কাজ করে

স্ট্যাটাস সিস্টেমটি কাজকে এক নজরে পড়তে সহজ করা উচিত। খুব বেশি স্ট্যাটাস হলে মানুষ দেখাকে বিশ্বাস করা বন্ধ করে দেয়। খুব কম হলে আপনি হ্যান্ডঅফ ম্যানেজ করতে প্রয়োজনীয় বিশদ হারাবেন।

অধিকাংশ টিমের জন্য 5–7 স্ট্যাটাসই সেরা। এটা এক স্ক্রিনে ফিট করে, একটি Kanban বোর্ড বা সহজ তালিকা ভিউতে ভালো কাজ করে, এবং দৈনিক প্রশ্নগুলোর উত্তর দিতে যথেষ্ট সংকেত দেয়: কী ব্লক, কী চলছে, এবং কী রিভিউয়ের অপেক্ষায়।

সেট ছোট রাখার আরেকটি সুবিধা হলো “স্ট্যাটাস হান্টিং” কমে (12টির মধ্যে কোনটা সঠিক তা আন্দাজ করা), রিপোর্টিং সহজ হয়, এবং আপনি প্রাধান্য, মালিক, এবং টাইপ আলাদা ক্ষেত্র হিসেবে রাখার বাধ্যবাধকতা পাবেন।

নামগুলো ভিন্ন হতে পারে, এবং সেটাও ঠিক আছে। একজন টিম “In Progress” বলবে, অন্যজন “Doing” বলবে। যা পারবে না তা হলো অর্থের পরিবর্তন। যদি “In Review” মাঝে মাঝে “QA-র অপেক্ষায়” মানে এবং অন্য সময় “কাস্টমারের অপেক্ষায়” মানে, আপনার বোর্ডটি শব্দে পরিণত হবে।

অর্থগুলো সঙ্গত রাখতে এক সোর্স অফ ট্রুথ সেট করুন: একটি সংক্ষিপ্ত টিম ডক যেখানে প্রতিটি স্ট্যাটাস আছে, এর মানে কী, এবং কখন নম্বর্স প্রবেশ ও বাহির হয় সেই নিয়ম। এটাকে দুই মিনিটে পড়ার মতো ছোট রাখুন। তারপর সেই একই স্ট্যাটাস সেট সব জায়গায় ব্যবহার করুন।

শুরু করার জন্য সহজ 7-স্ট্যাটাস সেট

যদি আপনি এমন স্ট্যাটাস চান যা সময়ের সাথে পরিষ্কার থাকে, একটি ছোট সেট দিয়ে শুরু করুন যা তিনটি প্রশ্নের উত্তর দেয়: এখনকে কে মালিক, পরবর্তী কী হবে, এবং “সম্পন্ন” কী দেখতে লাগে।

নিচে একটি সহজ 7-স্ট্যাটাস সেট যা বেশিরভাগ টিমের জন্য কাজ করে:

গুরুত্বপূর্ণ নিয়ম: শুধু “Waiting” ব্যবহার করবেন না। যদি কিছু আটকে থাকে, Blocked বলুন এবং নোটে নির্ভরতার নাম দিন (উদাহরণ: “Blocked: customer reply” বা “Blocked: access granted”)।

প্রতিটি স্ট্যাটাসের সংজ্ঞা (এন্ট্রি ও এক্সিট নিয়মসহ)

স্পষ্ট ওয়ার্কফ্লো স্ট্যাটাস তখনই কার্যকর যখন প্রতিটি স্ট্যাটাস সহজ একটি প্রশ্নের উত্তর দেয়: এখন কী সত্য?

New

কি সত্য: আইটেমটি ধরা হয়েছে, কিন্তু কেউ এটি মূল্যায়ন করেনি।

কি সঠিক নয়: অগ্রাধিকার, স্কোপ, বা মালিক সম্মত নয়।

Entry: একটি অনুরোধ জমা পড়েছে।

Exit: কেউ এটি পড়ে Triaged-এ সরিয়ে দেয়।

Example: “একজন সাপোর্ট এজেন্ট স্ক্রিনশটসহ একটি বাগ রিপোর্ট লগ করে।”

Triaged

কি সত্য: দলটি অনুরোধটি পর্যাপ্তভাবে বুঝেছে যাতে এটি রুট করা যায় এবং বৈধতা নিশ্চিত করা যায়।

কি সঠিক নয়: এটি শুরু করার জন্য প্রস্তুত।

Entry: কেউ মৌলিক কন্টেক্সট যোগ করেছে (সারসংক্ষেপ, প্রভাব, প্রভাবিত এলাকা)।

Exit: এটি বা তো কাজের জন্য প্রস্তুত করা হয় (Ready) বা ইচ্ছাকৃতভাবে বাতিল করা হয় (workflow-এর বাইরে হ্যান্ডেল করা হয়)।

Example: “PM এটিকে বাস্তব বাগ হিসেবে চিহ্নিত করে এবং পুনরুত্পাদনের ধাপগুলো নোট করে।”

Ready

কি সত্য: এটি অনুপস্থিত কোনো তথ্য ছাড়াই শুরু করা যাবে।

কি সঠিক নয়: কাজ শুরু হয়েছে।

Entry: গ্রহণযোগ্যতা শর্তাবলী পরিষ্কার এবং নির্ভরতাগুলো স্থাপন করা হয়েছে।

Exit: কেউ কাজ শুরু করে এবং প্রথম অর্থপূর্ণ পরিবর্তন করে (In Progress)।

Example: “ফরম ফিল্ড ও ভ্যালিডেশন নিয়মগুলো চূড়ান্ত।”

In Progress

কি সত্য: সক্রিয় কাজ চলছে।

কি সঠিক নয়: এটি কোনো কিউ-তে অপেক্ষা করছে।

Entry: কেউ এটি নিয়ে কাজ শুরু করে।

Exit: এটি পর্যবেক্ষণ করার জন্য যথেষ্ট সম্পন্ন (In Review) অথবা কোন নির্ভরতা ধরা পরে (Blocked)।

Example: “একজন ডেভেলপার নতুন স্ট্যাটাস ড্রপডাউন তৈরি করে এবং লজিক সংরক্ষণ করে।”

In Review

কি সত্য: এটি যাচাই করা হচ্ছে (পিয়ার রিভিউ, QA, বা স্টেকহোল্ডার অনুমোদন)।

কি সঠিক নয়: নতুন বৈশিষ্ট্য যোগ করা হচ্ছে।

Entry: ডোয়ার এটি যাচাইয়ের জন্য জমা দেয়।

Exit: এটি অনুমোদিত হয় এবং টিমের ডিফাইনেশন অফ ডান পূরণ করে (Done), অথবা প্রতিক্রিয়া সহ ফেরত যায় (In Progress)।

Example: “QA নিশ্চিত করে এটি ওয়েব এবং মোবাইলে কাজ করে।”

Blocked

কি সত্য: একটি নির্দিষ্ট, নামকরণকৃত নির্ভরতার কারণে কাজ চালিয়ে যাওয়া যায় না।

কি সঠিক নয়: আইটেমটি কেবল নিম্ন অগ্রাধিকারযুক্ত।

Entry: assignee এমন একটি নির্ভরতার মুখোমুখি হয়েছে যেটি তিনি নিজে সমাধান করতে পারে না।

Exit: নির্ভরতা সরানো হয়েছে এবং কাজ পুনরায় শুরু হয়েছে (সাধারণত In Progress)।

Example: “Blocked: production লগে অ্যাক্সেসের অপেক্ষা।”

Done

কি সত্য: এটি চুক্তিভিত্তিক গ্রহণযোগ্যতা শর্তাবলি পূরণ করেছে এবং শিপ বা শিপযোগ্য।

কি সঠিক নয়: এটি এখনও রিভিউ, টেস্টিং, বা ফলো-আপ প্রয়োজন।

Entry: রিভিউ পাশ এবং রিলিজ ধাপগুলি সম্পন্ন (আপনার দলের ডিফিনিশন অনুযায়ী)।

Exit: নেই; পুনরায় খোলা হলে একটি নতুন সাইকেল স্পষ্ট কারণে শুরু হয়।

Example: “ফিক্সটি লাইভ এবং বাগ আর পুনরুত্পন্ন হয় না।”

ধাপে ধাপে: 60 মিনিটে আপনার স্ট্যাটাস সিস্টেম তৈরি করুন

একটি ফোকাসড মিটিংয়ে আপনি মেসি স্ট্যাটাসগুলো ঠিক করতে পারেন। লক্ষ্য নিখুঁত মডেল নয়—একটি ভাগ করা লেবেল সেট যা কাজ বাস্তবে কীভাবে চলে তা মিলিয়ে যায়, এবং নিয়মগুলো সবাই পুনরাবৃত্তি করতে পারে।

60-মিনিট ওয়ার্কিং সেশন (একটি আউটকামসহ)

যে সকল রোল কাজকে স্পর্শ করে তাদের মধ্যে একজন করে নিয়ে আসুন (requester, doer, reviewer, approver)। আপনার বর্তমান বোর্ড বা তালিকা স্ক্রিন শেয়ার করুন।

প্রথমে, বাস্তব ওয়ার্কফ্লো ম্যাপ করুন (আদর্শ নয়)। একটি টípিক আইটেম বেছে নিন এবং প্রকৃতপক্ষে কী হয় তা ট্রেস করুন, অপেক্ষার সময়সহ। ধাপগুলোকে সরল ক্রিয়াপদে লিখুন (“draft,” “review,” “approve”)। যদি কোনো ধাপ কখনো কখনো ঘটে, সেটাকে একটি শাখা হিসেবে নোট করুন।

পরবর্তীভাবে, ডুপ্লিকেটগুলো সরান এবং অস্পষ্ট লেবেলগুলো রিনেম করুন। একই মান বোঝানো লেবেলগুলো মার্জ করুন (“In Progress” বনাম “Doing”)। অস্পষ্টগুলো (“Pending”) এমন কিছুতে বদলান যাতে কাজ করা যায় (“Blocked: customer reply”)। যদি আপনি একটি লেবেল এক বাক্যে ব্যাখ্যা করতে না পারেন, তা প্রস্তুত নয়।

তারপর এন্ট্রি ও এক্সিট নিয়ম যোগ করুন। প্রতিটি স্ট্যাটাসের জন্য লিখুন কি সত্য হতে হবে এন্ট্রি করার জন্য এবং কি সত্য হলে এক্সিট হবে। সংক্ষিপ্ত রাখুন। উদাহরণ: “In Review তখন প্রবেশ করে যখন কাজ জমা দেওয়া হয়, এক্সিট হয় যখন প্রতিক্রিয়া ঠিক করা হয় এবং রিভিউয়ার অনুমোদন করে।”

এর পরে, প্রতিটি হ্যান্ডঅফের জন্য ডিফল্ট মালিক বেছে নিন (রোল ঠিক থাকলে চলবে) — এটি আইটেম আটকে যাওয়া প্রতিরোধ করে। উদাহরণ: “In Review-এ থাকা আইটেম রিভিউয়ারের মালিকানায় থাকবে, কাজটি করা ব্যক্তির নয়।”

অবশেষে, 10টি সাম্প্রতিক আইটেম নিয়ে টেস্ট করুন এবং সামঞ্জস্য করুন। গত কয়েক সপ্তাহের 10টি শেষ বা সক্রিয় আইটেম নিন এবং প্রতিটি পয়েন্টে একটি স্ট্যাটাস অ্যাসাইন করুন। যদি বারবার তর্ক হয়, আপনার লেবেলগুলো overlap বা অস্পষ্ট। যদি আপনি কোন আইটেম লোকেট করতে না পারেন, আপনি হয়ত স্ট্যাটাস মিস করছেন বা দুইটি ধারণা একটিতে মিশিয়ে ফেলেছেন।

মিটিংয়ের পরে সংজ্ঞাগুলো একটি স্থানে প্রকাশ করুন এবং যেখানেই মানুষ কাজ দেখেন সেখানেই লেবেলগুলো মেলান।

ওয়েব ও মোবাইল স্ক্রিন জুড়ে স্ট্যাটাস সঙ্গত রাখুন

যদি কোনো স্ট্যাটাস ওয়েবে এক অর্থ দেয় এবং মোবাইলে একটু ভিন্ন অর্থ, মানুষ এটি বিশ্বাস করা বন্ধ করে দেয়। তারা চ্যাটে জিজ্ঞাসা করা শুরু করে, বিস্তারিত আবার চেক করে, বা নিজেরাই একটি “বাস্তব স্ট্যাটাস” মন্তব্যে তৈরি করে। ওয়ার্কফ্লো স্ট্যাটাস লেবেলের লক্ষ্য হল ভাগ করা সত্য, ডেকোরেশন নয়।

স্ট্যাটাসকে একটি ভাগ করা ফিল্ড হিসেবে আচরণ করুন যার একটি সোর্স অফ ট্রুথ আছে। একই লেবেল একই বানানে, ক্যাপিটালাইজেশন, এবং অর্থে সব জায়গায় প্রদর্শিত হবে: তালিকা, ডিটেইল স্ক্রিন, নোটিফিকেশন, এক্সপোর্ট, এবং পুশ মেসেজ।

ছোট-স্ক্রিন নিয়ম যা বাস্তবে কাজ করে

মোবাইল স্ক্রিন দীর্ঘ নাম ও দুর্বল ভিজ্যুয়াল ডিজাইনকে শাস্তি দেয়। ডেক্সটপ টেবিলে যা ঠিক আছে, সেটি ফোনে একটি কাটা-বের হওয়া ব্যাজে পরিণত হতে পারে।

• নামগুলো ছোট রাখুন (সম্ভব হলে 1–2 শব্দ)।
• রঙ কনসিস্টেন্ট রাখুন, কিন্তু রংকেই একমাত্র নির্ভরযোগ্য সংকেত বানাবেন না।
• দীর্ঘতম লেবেলের জন্য ডিজাইন করুন যাতে কিছুই অপ্রচ্ছন্ন না হয়।
• প্ল্যাটফর্মগুলোর জুড়ে অর্ডার কনসিস্টেন্ট রাখুন।
• “In Progress” বনাম “Working” এর মতো প্রায় একই লেবেল এড়িয়ে চলুন—একটিই বাছুন।

পজিশনিংও গুরুত্বপূর্ণ। ডিটেইল ভিউতে টাইটেলের পাশে স্ট্যাটাস রাখুন যাতে পূর্ণ বিবরণ পড়ার আগে সেটি দেখা যায়। তালিকা ভিউতে প্রতিবার একই স্থানে দেখান।

অ্যাক্সেসিবিলিটি বেসিকস সবার জন্য সহায়ক। রঙ একটি ইঙ্গিত, পুরো বার্তা নয়। সবসময় টেক্সট লেবেল দেখান, এবং একটি সহজ আইকন ভাবুন (যেমন Done-এর জন্য একটি চেক) যাতে স্ক্রিন রিডার ব্যবহারকারীরাও বা রঙ-দৃষ্টি সমস্যা 있는রাও দ্রুত অর্থ বুঝতে পারে।

স্ট্যাটাসগুলো ড্রিফট হওয়ার সাধারণ ভুলগুলো

স্ট্যাটাসগুলো তখনই drift করে যখন তারা “কাজ কোথায় আছে” বলাটা বন্ধ করে এবং “মানুষ কাজ সম্পর্কে কেমন অনুভব করছে” বলা শুরু করে। একবার সেটা হলে, আপনার বোর্ড ব্যস্ত দেখায়, কিন্তু কেউ বিশ্বাস করে না।

একটি সাধারণ কারণ হল প্রতিটি ছোট ধাপের জন্য খুব বেশি লেবেল রাখা। যদি একটি টাস্ক ঘন্টার মধ্যে তিনবার সরতে পারে, মানুষ আপডেট করা বন্ধ করে দেয় বা “প্রায় ঠিক” স্ট্যাটাস বেছে নেয়। ছোট একটি সেটই শ্রেষ্ঠ যখন প্রতিটি সরে যাওয়া বাস্তবে প্রস্তুতি বা দায়িত্বে পরিবর্তন আনে।

আরেকটি drift-পয়েন্ট হলো এক ফিল্ডে বিভিন্ন মাত্রা মিশিয়ে দেওয়া। অগ্রাধিকার ও জরুরিতা গুরুত্বপূর্ণ, কিন্তু সেগুলো আলাদা ফিল্ডে থাকা উচিত, স্ট্যাটাসে নয়। যদি “Urgent” স্ট্যাটাস হয়, তা “In Review”-এর সঙ্গে প্রতিযোগিতা করবে এবং আপনার রিপোর্টিংয়ের মান থাকবে না।

নিচের প্যাটার্নগুলো দেখুন:

• পরিষ্কার পার্থক্য ছাড়া একাধিক “done-ish” লেবেল
• এককালীন ব্যক্তিগত লেবেল (“Waiting for Sam”)
• “In Progress” একটি পার্কিং লট হয়ে যাওয়া
• কোন লিখিত এন্ট্রি ও এক্সিট নিয়ম নেই
• নতুন স্ক্রিনগুলো বিভিন্ন স্ট্যাটাস নাম বা অর্ডার দেখাচ্ছে

ড্রিফট প্রতিরোধ করতে স্ট্যাটাস সেটের জন্য এক মালিক নির্ধারণ করুন এবং পরিবর্তনগুলো বিরল রাখুন। যখন কিছু পরিবর্তন করবেন, লিখে রাখুন কী বদলেছে, কেন, এবং কী প্রতিস্থাপন করছে।

উদাহরণ: একটি রিকোয়েস্ট শুরু থেকে শেষ পর্যন্ত

একজন কাস্টমার সাপোর্ট এ লেখে: “মোবাইলে অর্ডার হিস্ট্রি পেজটি একটা খালি অবস্থা দেখায় যদিও আমার অর্ডার আছে।” সাপোর্ট একটি আইটেম লগ করে যা পরে প্রোডাক্ট ফিক্স হয়ে রিলিজ হবে।

New: সাপোর্ট স্ক্রিনশট, ডিভাইস ডিটেইল, এবং কী ‘সঠিক’ তা কেমন হওয়া উচিত তা ক্যাপচার করে।

Triaged: প্রোডাক্ট ওনার নিশ্চিত করে এটি বাস্তব বাগ এবং কোথায় পড়ে তা নির্ধারণ করে (মোবাইল অ্যাপ, ব্যাকএন্ড নয়) এবং প্রভাব স্পষ্ট করে।

Ready: পুনরুত্পাদনের ধাপ নিশ্চিত ও গ্রহণযোগ্যতা শর্তাবলি পরিষ্কার।

In Progress: একজন ইঞ্জিনিয়ার ইস্যুটিকে পুনরুত্পাদন করে, দেখে যে API ডেটা ফিরিয়ে দিচ্ছে কিন্তু স্ক্রিন তা ভুলভাবে ফিল্টার করছে, এবং ফিক্স শুরু করে।

Blocked: ইঞ্জিনিয়ার আবিষ্কার করে UI একটি ফিল্ডের ওপর নির্ভর করে যা পুরনো অ্যাকাউন্টে নেই এবং ব্যাকএন্ড পরিবর্তন দরকার। আইটেমটি Blocked বলে চিহ্নিত করা হয় স্পষ্ট নোটসহ: “Blocked: backend needs legacy field mapping.”

In Review: নির্ভরতা সমাধান হলে QA iOS ও Android-এ পরীক্ষা করে নিশ্চিত করে যে খালি অবস্থা সত্যিকারের খালি থাকলে দেখায়।

Done: ফিক্সটি অনুমোদিত ও রিলিজ করা হয়েছে (বা আপনার টিমের জন্য পরবর্তী রিলিজ উইন্ডোতে শিডিউল করা হলে সেটাকেই Done ধরা হতে পারে)। সাপোর্ট নিশ্চিত করে লাইভ এবং কাস্টমারকে প্রতিউত্তর দেয়।

দ্রষ্টব্য যা বিভ্রান্তি রোধ করে: “Blocked”-এ একটি নির্দিষ্ট কারণ ও পরবর্তী কর্ম আছে, এবং মালিকানা বেড়েছে না। কেউ আইটেম খুললে বুঝবে কার হাতে আছে।

দ্রুত চেকলিস্ট টিমকে সচেতন রাখার জন্য

যদি আপনার বোর্ডটি দুর্ব্যবস্থায় মনে হয়, 10 মিনিটে সাধারণত কারণ আপনি দেখবেন।

10-মিনিট বোর্ড স্ক্যান

বোর্ডটি দেখে এই সংকেতগুলো খুঁজুন:

• প্রতিটি স্ট্যাটাস উত্তর দেয়: “এখন কী সত্য?”
• প্রতিটি স্ট্যাটাসে একটি ডিফল্ট মালিক (রোল মানেই চলবে) এবং পরবর্তী স্পষ্ট কর্ম আছে
• দুটি স্ট্যাটাস একই সময়ে একই আইটেম বর্ণনা করতে পারে না
• আইটেমগুলো সিদ্ধান্ত বিনা পার্ক করা নেই (যদি এটি কয়েক দিন থাকতে পারে, একটি এক্সিট নিয়ম যোগ করুন)
• একই কাজের টাইপগুলো একই মূল ধাপগুলো অতিক্রম করে, যদি না লিখিত ব্যতিক্রম থাকে

যদি মানুষ ঝগড়া করে কোন কার্ড কোথায় আছে তাতে, তাহলে সেই স্ট্যাটাসটি অন্যটির সঙ্গে ওভারল্যাপ করছে বা যথেষ্ট সংজ্ঞায়িত নয়।

ওয়েব + মোবাইল সঙ্গতি পরীক্ষা

একই ওয়ার্কফ্লো ফোনে খুলে দেখুন লেবেলগুলো ছোট জায়গায়ও কাজ করে কিনা:

• তালিকা ভিউতে লেবেলগুলো ছোট ও পাঠযোগ্য (কোন ট্রাঙ্কেশন নেই)
• রঙ ছাড়া টেক্সট স্পষ্ট
• স্ট্যাটাস পরিবর্তনগুলো এক মালিক (টিম লিড বা ops) দ্বারা অনুমোদিত, ব্যক্তিগত নয়
• পরিবর্তনগুলো সংক্ষিপ্ত নোটসহ আসে যাতে সংজ্ঞাগুলো drift না করে

পরবর্তী ধাপ: রক্ষণ, পরিমাপ, ও সময়ের সাথে উন্নতি

স্ট্যাটাস সিস্টেম তখনই কার্যকর থাকে যখন আপনি এটিকে নিয়মবিধি হিসেবে দেখেন: স্থিতিশীল, কিন্তু পর্যালোচনার সুযোগ রাখে। লক্ষ্য ধারাবাহিক ব্যবহার; নয় যে প্রতিনিয়ত বদলানো।

একটি হালকা কেডেন্স ঠিক করুন, যেমন মাসে একবার 30 মিনিটের পর্যালোচনা যেখানে প্রতিটি রোলের একজন থাকবে। 5–10টি সাম্প্রতিক আইটেম নিয়ে যান এবং যে ব্যতিক্রমগুলো আছে সেগুলো ঠিক করুন।

কয়েকটি সাধারণ সিগন্যাল ট্র্যাক করার মতো:

• Blocked-এ কাটানো সময় (এবং প্রধান কারণ)
• দুটি স্ট্যাটাসের মধ্যে বারবার বাউন্স করা আইটেম
• আপনার স্বাভাবিক চক্র সময়ের চাইতে বেশি সময় আটকে থাকা আইটেম

যদি কিছু অস্বাভাবিক মনে হয়, সাথে সাথেই নতুন স্ট্যাটাস যোগ করার প্রতিরোধ করুন। একটি নতুন স্ট্যাটাস যোগ করুন কেবল যখন নতুন অবস্থা সত্যিই আলাদা, এটি পরবর্তী কর্মকে বদলে দেয়, এবং প্রায়ই ঘটে। বেশিরভাগ সময় সমাধানটি সহজ: সংজ্ঞা টাইট করুন, একটি এন্ট্রি নিয়ম যোগ করুন, বা মালিক স্পষ্ট করুন।

যদি আপনি একটি অভ্যন্তরীণ টুলে ওয়ার্কফ্লো বানাচ্ছেন, স্ট্যাটাসকে স্ক্রিন-নির্দিষ্ট টেক্সট নয় বরং ভাগ করা ডেটা হিসেবে বিবেচনা করুন। উদাহরণস্বরূপ AppMaster (appmaster.io)-এ আপনি Data Designer-এ একবার স্ট্যাটাস ফিল্ড ডিফাইন করে তা ওয়েব ও নেটিভ মোবাইল অ্যাপে পুনরায় ব্যবহার করতে পারবেন, যা “আমার ফোনে অন্য অর্থ” ধরনের drift প্রতিরোধে সাহায্য করে।