ব্যতিক্রম পথ ডিজাইন: অনুমোদনের আগে প্রত্যাখ্যান পরিকল্পনা করুন

কেন হ্যাপি পাথ যথেষ্ট নয়\n\nবেশিরভাগ টিম একটি পরিষ্কার সংস্করণ থেকেই শুরু করে। একটি অনুরোধ আসে, কেউ এটি পর্যালোচনা করে, এবং এটি অনুমোদিত হয়। এটি দক্ষ মনে হয়, কিন্তু এখানেই আসল কাজ গোপন থাকে।\n\nহ্যাপি পাথ সাধারণত সবচেয়ে কম পথ। ফর্ম সম্পূর্ণ, সংযুক্তি আছে, এবং রিভিউয়ার ঠিক কি করতে হবে জানে। বাস্তব অপারেশনে, সেটা খুব কমইইইইইইইইইইইইই— দেরি ঘটায়।\n\nদেরি শুরু হয় যখন কিছু অনুপস্থিত, অস্পষ্ট, দেরিতে আসে, অথবা কেবল আংশিকভাবে গ্রহণযোগ্য হয়। একজন ব্যবস্থাপক বাজেট অনুমোদন করতে পারেন কিন্তু একটি লাইন আইটেম প্রত্যাখ্যান করেন। ফাইন্যান্স এমন একটি ট্যাক্স ডকুমেন্ট চাইতে পারে যা কখনো আপলোড হয়নি। একটি সাপোর্ট লিড_REASON_FIELD_TOO_VAGUE_ অনুরোধটা ফিরে পাঠাতে পারেন কারণ কারণ ফিল্ডটি খুব অস্পষ্ট। এধরনের প্রতিটি সময় অতিরিক্ত ধাপ, অতিরিক্ত বার্তা এবং অতিরিক্ত অপেক্ষা তৈরি করে।\n\nযদি এগুলো আগে থেকেই পরিকল্পনা না করা হয়, মানুষ ঝটপট সিদ্ধান্ত নেয়। একজন রিভিউয়ার ইমেইল পাঠায়। আরেকজন টুলে মন্তব্য রেখে দেয়। তৃতীয়জন কোন ব্যাখ্যা ছাড়াই অনুরোধ প্রত্যাখ্যান করে। অনুরোধকারী আন্দাজ করতে থাকে: কি ঠিক করা উচিত, কি আবার শুরু করা উচিত, না কি কাউকে সাহায্য চাওয়া উচিত?\n\nএই বিভ্রান্তির একটি মূল্য আছে। এটি অনুরোধ দাখিলকারীকে, রিভিউয়ারকে এবং যে কেউ ব্যাখ্যা করতে টানা হয়েছে তাদের সেয। একটি ওয়ার্কফ্লো যা হোয়াইটবোর্ডে সহজ দেখায় তা পরে ফলোআপ চ্যাট, ডুপ্লিকেট সাবমিশন এবং ম্যানুয়াল হ্যান্ডঅফে পরিণত হয়।\n\nএকটি মৌলিক অনুমোদন ফ্লো আঁকাটা সহজ:\n\n- অনুরোধ জমা দিন\n- অনুরোধ পর্যালোচনা করুন\n- অনুরোধ অনুমোদন করুন\n\nবাস্তব সংস্করণ কঠিন। যদি কোনো ডকুমেন্ট অনুপস্থিত থাকে? যদি কেবল অংশ অনুমোদিত হয়? যদি রিভিউয়ার তা প্রত্যাখ্যান করে কিন্তু ব্যবহারকারী সেটি ঠিক করতে পারে? এগুলো অস্বাভাবিক নয়। অনেক টিমের জন্য, এগুলোই স্বাভাবিক কেস।\n\nএই কারণেই ব্যতিক্রম পথ ডিজাইন স্ক্রিন আঁকার এবং স্টেটস নামকরণের আগে গুরুত্ব পেতে হয়। ব্যতিক্রম পথ নির্ধারণ করে বাস্তবতা পরিকল্পনায় বিঘ্ন ঘটালে কী হয়, আর বাস্তবতা প্রায়ই বাধা দেয়।\n\nআপনি যদি একটি অভ্যন্তরীণ অনুমোদন অ্যাপ তৈরি করছেন, এমনকি একটি নো-কোড প্ল্যাটফর্মে AppMaster-এ, প্রত্যাখ্যান এবং অসম্পূর্ণ কেসগুলো অনুমোদিত কেসের মতো যত্ন দাবি করে। তারা মানুষের দেখা বার্তা, তারা যে পদক্ষেপগুলো নিতে পারে, এবং ওয়ার্কফ্লো মানুষকে কিভাবে উদ্ধার করে বা আটকে রাখে তা নির্ধারণ করে।\n\nএকটি হ্যাপি পাথ উদ্দেশ্য দেখায়। ব্যতিক্রম পথ দেখায় প্রক্রিয়াটি বাস্তবে টিকে থাকতে পারে কিনা।\n\n## ব্যতিক্রম পথ কিরূপ\n\nএকটি ব্যতিক্রম পথ হল যখন একটি অনুরোধ স্বাভাবিকভাবে সামনে যেতে পারে না তখন যা ঘটে। এটি কোনো বিরল এজ কেস নয়। এটি সেই অংশ যা বাস্তব জগতের বিশৃঙ্খলা সামলায়: একটি অনুরোধ প্রত্যাখ্যান করা হয়েছে, একটি ফর্ম অসম্পূর্ণ, একটি অংশ অনুমোদিত কিন্তু অন্যটি নয়, অথবা কাজ আটকে গেছে।\n\nএকটি স্পষ্ট ব্যতিক্রম পথ সাধারণ ভাষা ব্যবহার করে। অস্পষ্ট স্ট্যাটাস যেমন "Failed" বলার বদলে বলুন কী হয়েছে: "বাজেট সীমার বাইরে হওয়ায় প্রত্যাখ্যান" বা "ID ডকুমেন্টের জন্য অপেক্ষা চলছে"। মানুষকে জানতে হবে কি ভুল হয়েছে, কে কাজ করবে, এবং পরবর্তী কী হবে।\n\nবেশিরভাগ ওয়ার্কফ্লো কয়েকটি পূর্বানুমেয় উপায়ে ভেঙে পড়ে:\n\n- অনুরোধটি একটি নির্দিষ্ট কারণে প্রত্যাখ্যাত\n- একটি প্রয়োজনীয় ডকুমেন্ট বা ফিল্ড অনুপস্থিত\n- কেবল অনুরোধের অংশই অনুমোদিত\n- অনুরোধের কোনো মালিক নেই বা পরবর্তী ধাপ নির্ধারিত নয়\n\nঅনুপস্থিত তথ্য সবচেয়ে সাধারণ সমস্যাগুলোর মধ্যে একটি। ধরুন একটি সরবরাহকারী অনবোর্ডিং ফর্ম যা একটি ট্যাক্স ডকুমেন্ট এবং একটি ব্যাংক অ্যাকাউন্ট নম্বর প্রয়োজন। যদি কোনটা অনুপস্থিত থাকে, সিস্টেম কেবল থেমে যাবে না। এটি অনুরোধকে অসম্পূর্ণ হিসেবে মার্ক করা উচিত, ঠিক কোনটা অনুপস্থিত তা দেখানো উচিত, এবং এটি সঠিক ব্যক্তির কাছে ফিরিয়ে দেওয়া উচিত।\n\nআংশিক অনুমোদনও সমানভাবে গুরুত্বপূর্ণ। একটি ট্রাভেল অনুরোধ বিবেচনা করুন যেটিতে ফ্লাইট, হোটেল এবং খাদ্য বাজেট আছে। ব্যবস্থাপক ফ্লাইট এবং হোটেল অনুমোদন করেন কিন্তু খাদ্য বাজেট কেটে দেন। এ অবস্থায় নিয়ম দরকার। কর্মচারী কি পরিবর্তন গ্রহণ করবেন, অনুরোধ আপডেট করবেন, না কি যাত্রা বাতিল করবে?\n\nস্টলগুলোও গুরুত্বপূর্ণ। একটি অনুরোধ অপরিবর্তিত পড়ে থাকতে পারে কারণ নির্ধারিত রিভিউয়ার কোম্পানি ছেড়েছেন, টিম ব্যাকআপ অ্যাপ্রুভার সেট করেনি, বা প্রক্রিয়া কোনো এমন ধাপে পৌঁছেছে যেখানে পরবর্তী মালিক নেই। প্রযুক্তিগতভাবে কিছু ভাঙ্গেনি, কিন্তু অনুরোধ তখনও এগোতে পারে না।\n\nযদি আপনি এগুলো আগে ডিজাইন না করেন, মানুষ ইমেইল, চ্যাট বা স্প্রেডশিট নোটে এগুলো হ্যান্ডল করে। দ্রুতই কেউ জানে না কোন সংস্করণ চূড়ান্ত।\n\n## একটি সহজ অনুমোদন উদাহরণ\n\nএকজন সেলস ম্যানেজারের জন্য দুইদিনের কনফারেন্সে অংশগ্রহণের ট্রাভেল রিকোয়েস্ট নিন। কাগজে ফ্লো সহজ দেখায়: কর্মচারী ভ্রমণের তারিখ, আনুমানিক খরচ এবং ভ্রমণের কারণ লিখে। ব্যবস্থাপক এটি অনুমোদন করেন, ফাইন্যান্স বাজেট নিশ্চিত করে, এবং ট্রিপ বুকিংয়ের দিকে যায়।\n\nওই ফ্লো পরিষ্কার, কিন্তু অসম্পূর্ণ।\n\nএখন একই অনুরোধ ভেঙে ফেলুন। কর্মচারী ফ্লাইট অনুমান এবং কনফারেন্স টিকিট আপলোড করেন কিন্তু হোটেলের কোট ভুলে যান। যদি সিস্টেম কেবল "submitted" এবং "approved" জানে, মানুষ দ্রুত আটকে পড়ে। ফাইন্যান্স একটি অসম্পূর্ণ অনুরোধ দেখবে, ব্যবস্থাপক মনে করতে পারেন এটা প্রস্তুত, এবং কর্মচারী জানবে না কি অনুপস্থিত।\n\nএকটি ভাল ফ্লো সেই অনুরোধকে তার নিজস্ব স্টেট দেয়, যেমন "Waiting for document" বা "Needs update"। কর্মচারী একটি স্পষ্ট বার্তা দেখলে: "এটি ফাইন্যান্সে যাওয়ার আগে হোটেল কোট যোগ করুন"। ব্যবস্থককে পুরো ট্রিপ প্রত্যাখ্যান করে কেবল একটি ফাইল চাওয়ার জন্য যেতে হবে না।\n\nএখন আরেকটি সমস্যা যোগ করুন। ব্যবস্থাপক সম্মত যে কর্মচারী যাত্রা করবে, কিন্তু পুরো টাকার জন্য নয়। তারা ফ্লাইট এবং এক রাতের হোটেল অনুমোদন করেন, কিন্তু ওয়ার্কশপ ফি এবং দ্বিতীয় হোটেল রাত প্রত্যাখ্যান করেন।\n\nএখানেই অনেক টিম আবিষ্কার করে যে তাদের কাছে আংশিক অনুমোদনের প্রসেস নেই।\n\nযদি ওয়ার্কফ্লো কেবল অনুরোধের অংশই অনুমোদন করতে না পারে, মানুষ ওয়ার্কঅ্যারাউন্ড শুরু করে। তারা পুরো অনুরোধ প্রত্যাখ্যান করে কর্মচারীকে পুনরায় জমা দিতে বলতে পারে। অথবা ফাইন্যান্স ভুল করে পুরো টাকাই অনুমোদন করে দিতে পারে কারণ সিস্টেম শুধু একটি হ্যাঁ-বা-না সিদ্ধান্ত রাখে।\n\nএকটি পরিষ্কার মডেল প্রতিটি খরচ আইটেম ট্র্যাক করে, বা অন্তত অনুমোদিত মোট দেখায়। একটি অনুরোধ দেখাতে পারে:\n\n- Flight: approved\n- Hotel: approved for 1 night\n- Workshop add-on: not approved\n- Total requested: $1,450\n- Total approved: $980\n\nএই এক উদাহরণই দেখায় কেন অনুমোদন ওয়ার্কফ্লো ত্রুটিগুলো প্রায়ই অনিয়মিত নিয়মের অভাব থেকে আসে, লো-পারসনেল ত্রুটি থেকে নয়। স্ক্রিন ডিজাইন করার আগে সেই নিয়মগুলো নির্ধারণ করলে বাকি ওয়ার্কফ্লো অনেক বেশি বিশ্বাসযোগ্য হয়ে যায়।\n\n## স্ক্রিনের আগে ব্যতিক্রম ডিজাইন করুন\n\nওয়ার্কফ্লো উন্নত করার একটি ভাল উপায় হল ধরে নেওয়া যে অনুরোধটি পরিষ্কারভাবে যাবে না। একটিই পরিবর্তন দ্রুত ডিজাইনের গুণমান বদলে দেয়।\n\nগলমেলে কেসগুলো দিয়ে শুরু করুন: ফর্ম অসম্পূর্ণ, নীতি অস্পষ্ট, অনুমোদনকারী অনুপস্থিত, বা কেবল অংশই সামনে যাবে। বেশিরভাগ টিম এইগুলোকে তিনটি প্রধান প্যাটার্নে গ্রুপ করতে পারে:\n\n- প্রত্যাখ্যান\n- অনুপস্থিত তথ্য\n- আংশিক অনুমোদন\n\nএতে কাজটি পরিচালনাযোগ্য থাকে। প্রতিটি এজ কেসের জন্য নতুন উত্তর আবিষ্কার করার বদলে, আপনি একটি ছোট প্যাটার্ন সেট সংজ্ঞায়িত করে প্রতিটি অনুরোধের ধরনে তা প্রয়োগ করবেন।\n\nএই ক্রমেই কাজ করুন।\n\nপ্রথমে, প্রতিটি পয়েন্ট তালিকাভুক্ত করুন যেখানে অনুরোধ থেমে যেতে পারে। অনুপস্থিত ডকুমেন্ট, অবৈধ মান, নীতি লঙ্ঘন, মেয়াদ উত্তীর্ণ শেষ তারিখ, ডুপ্লিকেট সাবমিশন, এবং ম্যানুয়াল রিভিউ চিন্তা করুন। যদি অনুরোধ অপেক্ষা করতে পারে, ব্যর্থ হতে পারে, বা প্রেরকের কাছে ফিরে যেতে পারে, তা লিখে রাখুন।\n\nএরপর, প্রতিটি কেসে কি হবে তা নির্ধারণ করুন। প্রতিটি ব্যতিক্রমের জন্য চারটি সহজ প্রশ্নের উত্তর দিন:\n\n- কে অবগত করা হবে\n- অনুরোধ কোন স্ট্যাটাস দেখাবে\n- ব্যবহারকারী পরের কি করতে হবে\n- কখন অনুরোধ আবার অগ্রসর হবে\n\nউদাহরণস্বরূপ, একজন কর্মচারী $600-র একটি ভ্রমণ খরচ দাবি জমা করে। হোটেল রিসিট অনুপস্থিত এবং একটি খাবার নীতির পরিমাণের বেশি। যদি আপনি শুধু হ্যাপি পাথ ডিজাইন করেন, অনুরোধ আটকে যাবে বা সব একসঙ্গে প্রত্যাখ্যাত হবে। যদি আপনি ব্যতিক্রম আগে ডিজাইন করেন, সিস্টেম অনুরোধটিকে অনুপস্থিত রিসিটের জন্য বিরতি দিতে পারে, কর্মচারীকে একটি স্পষ্ট বার্তা পাঠাতে পারে, এবং অনুমোদিত আইটেমগুলোকে শর্তসাপেক্ষে চিহ্নিত করতে পারে।\n\nএখানেই আংশিক অনুমোদন নিয়মগুলোর গুরুত্ব। আপনাকে নির্ধারণ করতে হবে অনুমোদিত পরিমাণ কি এখন এগোতে পারবে, বাকিটা কি ধরে থাকবে, এবং অনুরোধকারী শুধু বিতর্কিত অংশই সম্পাদনা করতে পারবে নাকি পুরো দাবি পুনরায় জমা দিতে হবে।\n\nআপনি যদি AppMaster-এ প্রক্রিয়াটি তৈরি করছেন, এই সময়ে সেই শাখাগুলো বিজনেস লজিকে ম্যাপ করুন UI পালিশ করার আগে। যখন reject, return-for-edits, এবং approve-with-conditions আলাদা পাথ হিসেবে বিবেচিত হয়, তখনওয়ার্কফ্লোকে বিশ্বাস করা সহজ হয়।\n\nশেষে, শুরু থেকে শেষ পর্যন্ত একটি বাস্তব দৃশ্য টেস্ট করুন। বাস্তব সংখ্যা, একটি প্রকৃত ডকুমেন্ট গ্যাপ এবং একটি নীতি ব্যতিক্রম ব্যবহার করুন। যদি একজন মানুষ ফ্লো পড়ে এক মিনিটের মধ্যে বলা না পারে পরবর্তী কী হবে, ডিজাইন এখনও অস্পষ্ট।\n\n## ইন্টারফেসের আগে নিয়মগুলো নির্ধারণ করুন\n\nস্ক্রিনগুলো কংক্রিট মনে হয়, তাই টিমগুলো প্রায়ই সেগুলো দিয়েই শুরু করে। তারা বোতাম, ফর্ম এবং ড্যাশবোর্ড আঁকে আগে কাদের নিয়মে একমত হয়েছে তা নির্ধারণ করার আগে। পরে সমস্যাগুলো হয় কারণ ইন্টারফেস এমন সিদ্ধান্তগুলো লুকিয়ে রাখে যা কেউ সত্যিই করেনি।\n\nভাল ক্রমটি সহজ: স্টেট, হ্যান্ডঅফ, ডেডলাইন এবং এগিয়ে যেতে প্রমাণ কী লাগবে তা নির্ধারণ করুন। তারপর স্ক্রিনগুলো সেই নিয়মগুলোর উপর গড়ুন।\n\nযদি নিয়ম সেটটি ছোট ও স্পষ্ট হয়, ব্যতিক্রম ডিজাইন অনেক সহজ হয়। একটি অনুরোধ অনুমোদন, প্রত্যাখ্যান, ঠিক করার জন্য ফেরত দেওয়া বা আংশিকভাবে অনুমোদিত হতে পারে—এই স্টেটগুলোর পরিষ্কার নাম থাকা উচিত যা কেবল একটাই অর্থ বহন করে। "Returned," "reopened," এবং "needs changes"-এর মতো কাছাকাছি নামগুলো এড়ান যতক্ষণ না ওগুলো সত্যিই আলাদা আচরণ করে।\n\nএকটি ক্রয় অনুরোধ নিন। একজন ব্যবস্থাপক এটি খুলে দেখে কোট মিসিং। যদি টিম সিদ্ধান্ত না হয়েছে পরবর্তী কী হবে, মানুষ কৌশল তৈরি করে। একজন প্রত্যাখ্যান করে, আর একজন মুলতুবি রেখে দেয়, আরেকজন চ্যাটে বার্তা পাঠায় কিন্তু সিস্টেমে কিছুই পরিবর্তন করে না। দ্রুতই কেউ স্ট্যাটাসকে বিশ্বাস করে না।\n\nপ্রথমে নিয়ম লিখুন। যখন কোট অনুপস্থিত, অনুরোধটি "Needs documents"-এ যাবে। পরবর্তী ধাপের মালিক হবে অনুরোধকারী। অনুরোধটি সেখানে পাঁচ কার্যদিবস থাকবে। কিছু না এলে এটা "Expired" হয়ে যাবে এবং নতুন সাবমিশন প্রয়োজন হবে।\n\nএকটি নিয়ম পণ্যকে একটি মকআপের চেয়ে বেশি আকার দেয়। এখন আপনি জানেন ব্যবহারকারীকে কি দেখতে হবে, কি রিমাইন্ডার পাঠাতে হবে, এবং কি ইতিহাস রাখা হবে।\n\nএকটি ব্যবহারিক নিয়ম সেট চারটি প্রশ্নের উত্তর দেয়:\n\n- প্রতিদিন যে কয়টি স্ট্যাটাস নাম সবাই ব্যবহার করবে তা কী?\n- প্রতিটি স্ট্যাটাসে পরবর্তী কে কাজ করবে?\n- আইটেমটি কতক্ষণ সেখানে থাকতে পারে আগানোর আগে এস্ক্যালেট, এক্সপায়ার বা ক্লোজ হবে?\n\n- এগিয়ে যেতে কি ফিল্ড, ফাইল বা চেক দরকার?\n\nআংশিক অনুমোদনও একই যত্ন দাবি করে। যদি ট্রাভেল অনুমোদিত কিন্তু হোটেল কস্ট না হয়, অনুরোধকারী কি একই রেকর্ড সম্পাদনা করবে না কি নতুনটি তৈরি করবে? ফাইন্যান্স কি কেবল পরিবর্তিত অংশই পর্যালোচনা করবে নাকি আবার সবকিছু? আগে না ঠিক করলে স্ক্রিন সুন্দর দেখলেও প্রক্রিয়া পিছনে বিশৃঙ্খল থাকবে।\n\nযখন টিমগুলো প্রথমে নিয়ম নির্ধারণ করে, ইন্টারফেস সহজ হয়ে যায়। আরও গুরুত্বপূর্ণ, ব্যবহারকারীরা ঠিক জানে পরবর্তী কী করতে হবে, এমনকি উত্তর "এখনো অনুমোদিত নয়" হলেও।\n\n## এমন বার্তা লিখুন যা মানুষ কার্যকর করে\n\nএকটি খারাপ ব্যতিক্রম বার্তা সবকিছু ধীর করে দেয়। মানুষ শুধু জানলে হবে না যে কিছু ব্যর্থ হয়েছে—তাদের জানতে হবে কী ঘটেছে, কী প্রভাবিত হয়েছে, এবং পরবর্তী কী করা উচিত।\n\nএখানেই ডিজাইন ব্যবহারকারীর জন্য বাস্তবে আসে। আপনার অভ্যন্তরীণ নিয়ম যতই স্পষ্ট হোক না কেন, যদি স্ক্রিন কেবল বলে "Error" বা "Pending review", মানুষ আন্দাজ করবে, ভুল ফাইল পাঠাবে, বা সাপোর্টে জিজ্ঞেস করবে।\n\nএকটি ভেন্ডর অনুমোদন উদাহরণ নিন। একজন ব্যবহারকারী ট্যাক্স ডকুমেন্ট, ব্যাংক ডিটেইল এবং ইন্সিউরেন্স প্রুফ সহ ফর্ম জমা দেয়। ব্যাংক ডিটেইল ঠিক আছে, ট্যাক্স ডকুমেন্ট পুরনো, এবং ইন্সিউরেন্স প্রুফ অনুপস্থিত। যদি সিস্টেম কেবল বলে "Request not approved", ব্যবহারকারী স্পষ্ট পরবর্তী ধাপ পাবেন না।\n\nএকটি ভালো বার্তা এভাবে শোনায়: "আপনার ব্যাংক ডিটেইল অনুমোদিত হয়েছে। এখনও চূড়ান্ত অনুমোদনের জন্য একটি আপডেট ট্যাক্স ডকুমেন্ট এবং ইন্সিউরেন্স প্রুফ দরকার।" এক বাক্যই সময় বাঁচায় কারণ এটা কি সম্পন্ন হয়েছে এবং কি এখনও কাজ আছে আলাদা করে দেয়।\n\nভালো বার্তাগুলো সাধারণত চারটি ছোট প্রশ্নের উত্তর দেয়:\n\n- কোন অংশ প্রত্যাখ্যাত, অনুপস্থিত বা এখনো পর্যালোচনার মধ্যে?\n- কোন অংশ ইতিমধ্যেই গ্রহণ করা হয়েছে?\n- ব্যক্তি কি আপলোড, পরিবর্তন বা নিশ্চিত করতে হবে?\n- তারা পুনঃসাবমিট করলে কী হবে?\n\nশেষ অংশটি গুরুত্বপূর্ণ। যখন পরবর্তী ধাপটি স্পষ্ট থাকে, মানুষ কাজ করা সহজ মনে করে। "অনুপস্থিত ফাইল আপলোড করে পুনরায় জমা দিন" লেখা থাকা অনেক ভালো, "Action required" বলতে চেয়ে।\n\nঅস্পষ্ট লেবেলও উদ্বেগ তৈরি করে। "Pending review" মানে ব্যক্তি অপেক্ষা করছে, ডেটা অনুপস্থিত, বা কোনো অভ্যন্তরীণ চেক—যেটাই হোক না কেন। কারণ জানা থাকলে সেটি স্পষ্টভাবে বলুন। "Waiting for manager approval" এবং "Waiting for proof of address" একই নয়, এবং এগুলো একইভাবে দেখতে থাকা উচিত নয়।\n\nযদি প্রক্রিয়াটি আংশিক অনুমোদন অনুমোদন করে, স্ট্যাটাসেই তা স্পষ্টভাবে দেখান। সংক্ষিপ্ত ব্রেকডাউন এক লেবেলের চেয়ে কাজের।\n\n- Approved: identity document\n- Needs update: tax form\n- Missing: insurance certificate\n\nএখন ব্যবহারকারী কেবল যে অংশ ঠিক করতে হবে তা ঠিক করতে পারে। তাদের আবার শুরু করতে হবে না।\n\nএখানেই পুনরায় জমা দেওয়াও সহজে পাওয়া উচিত। বার্তার কাছে পরবর্তী অ্যাকশন রাখুন, অন্য স্ক্রিনে নয়। AppMaster-এ কাজ করলে ইউজার-ফেসিং স্ট্যাটাস টেক্সটকে বাস্তব বিজনেস প্রসেস স্টেটসের সাথে মিলিয়ে রাখাটা সাহায্য করে যাতে অ্যাপ ঠিকই বলে ওয়ার্কফ্লো কী করছে।\n\nভালো বার্তা সাপোর্ট টিকিট কমায়, অনুমোদন দ্রুত করে এবং প্রক্রিয়াটিকে ন্যায়সঙ্গত মনে করায়। মানুষ একটি প্রত্যাখ্যান গ্রহণ করবে যখন তারা সেটি বুঝবে।\n\n## ভুলসমূহ যা পুনরকাজ বাড়ায়\n\nবেশিরভাগ পুনরকাজের শুরু এক ভুল ধারণা: স্বাভাবিক পথই প্রধান বিষয়। টিমগুলো অনুরোধ জমা, অনুমোদন, সম্পন্ন মেপে নেয় এবং সেখানে থেমে যায়। তারপর বাস্তবতা আসে: একটি ফাইল অনুপস্থিত, একজন ব্যবস্থাপক পরিবর্তন চায়, বা কেবল অংশটি সামনে যাবে।\n\nএই ফাঁক দ্রুত অতিরিক্ত কাজ তৈরি করে। মানুষ ম্যানুয়াল ফিক্স আবিষ্কার করে, পাশের বার্তা পাঠায়, এবং স্ট্যাটাস অনায়াসে বদলে দেয়। কয়েক সপ্তাহ পরে কেউওয়ার্কফ্লোকে বিশ্বাস করে না কারণ প্রতিটি ব্যতিক্রম বিশেষ কেস মনে হয়।\n\nএকটি সাধারণ ভুল হলো আদর্শ পথটাকেই পণ্য হিসেবে দেখা এবং বাকি সবকিছু পরিষ্কার করে দেওয়া উচিত। ধরুন একটি ব্যয় অনুরোধ যা একটি রসিদ, ডিপার্টমেন্ট অনুমোদন এবং ফাইন্যান্স রিভিউ প্রয়োজন। যদি রসিদ অনুপস্থিত হয়, অনুরোধ কি বিরতি পাবে, কর্মচারীর কাছে ফিরবে, না কি প্রত্যাখ্যাত হবে? যদি শুরু থেকেই এই নিয়ম পরিষ্কার না থাকে, টিম পরে ইমেইল ও মন্তব্য দিয়ে প্যাচ করবে।\n\nবিভ্রান্তিকর স্ট্যাটাস নাম আরেকটি পুনরকাজ তৈরি করে। "In review 2" বা "Pending action"-এর মত লেবেলগুলো নিরীহ শোনালেও মানুষকে পরের ধাপটা আন্দাজ করতে বাধ্য করে। স্পষ্ট নামগুলো ভুল কমায় কারণ এগুলোই বা ভুলের কারণ, মালিক, পরিণতি বা পরবর্তী ধাপ নির্দেশ করে।\n\nওয়ার্কফ্লো ভাঙার আরেকটি জায়গা মালিকানা। একটি অনুরোধ কখনো এমন স্ট্যাটাসে বসে থাকা উচিত নয় যেটার কেউ মালিক নয়। যদি কোনো কেস অপেক্ষমান থাকে, কাউকে তা এগিয়ে নিতে, আরও তথ্য চাওয়া বা বন্ধ করতে দায়িত্ব নিতে হবে। অন্যথায় নীরব দেরি জমে এবং ব্যবহারকারীরা ধরে নেবে সিস্টেম তাদের অনুরোধ হারিয়েছে।\n\nআংশিক অনুমোদনও প্রায়ই খারাপভাবে হ্যান্ডল করা হয়। টিমগুলো এটিকে পুরো প্রত্যাখ্যানের মতো বিবেচনা করে কারণ সেটাই সহজ। কিন্তু ফলাফলগুলো আলাদা অর্থ বহন করে। যদি একটি ট্রাভেল অনুরোধে ফ্লাইট, হোটেল, এবং খাদ্য চাওয়া হয়, ফাইন্যান্স ফ্লাইট এবং হোটেল অনুমোদন করে কিন্তু খাদ্য প্রত্যাখ্যান করলে সেটির আলাদা পাথ, বার্তা এবং অন_follow-up_ থাকে।\n\nযখন আংশিক অনুমোদন প্রত্যাখ্যানের সাথে একত্রে লিপিবদ্ধ করা হয়, মানুষ পুরো অনুরোধ পুনরায় জমা দেয়, ডকুমেন্ট ডুপ্লিকেট করে, এবং আগেআই করা রিভিউ আবার শুরু করে। সেটাই বিশুদ্ধ পুনরকাজ।\n\nএকটি সহজ পরীক্ষা সাহায্য করে: প্রতিটি নন-হ্যাপি-পাথ স্ট্যাটাস পড়ুন এবং প্রশ্ন করুন, "এখানে মালিক কে, ব্যবহারকারী কি দেখে, এবং পরবর্তী কী হয়?" যদি উত্তর অস্পষ্ট হয়, প্রক্রিয়াটি সম্ভবত একই জায়গায় পরে ভেঙে পড়বে।\n\n## বিল্ড করার আগে দ্রুত চেকগুলো\n\nস্ক্রিন বা অটোমেট করার আগে একটি শেষ বার গলমেলে কেসগুলো দেখুন। ভালো ব্যতিক্রম পথ ডিজাইন প্রায়ই কয়েকটি পরিষ্কার সিদ্ধান্তের ফল যা আগে করা হয়, এর ফলে বিভ্রান্তি পুনরকাজে পরিণত হয় না।\n\nযদি একটি অনুরোধ প্রত্যাখ্যাত, বিরতি পায়, বা কেবল আংশিকভাবে অনুমোদিত হয়, তখন কাউকে সবসময় জানা উচিত পরবর্তী কী হবে, কে করবে, এবং কোন তথ্য এখনও অনুপস্থিত।\n\nপ্রতিটি প্রক্রিয়ার ব্যতিক্রমে এই দ্রুত চেক ব্যবহার করুন:\n\n- প্রতিটি ব্যতিক্রমের একটি মালিক আছে।\n- প্রতিটি স্ট্যাটাস একটি স্পষ্ট পরবর্তী ধাপে নিয়ে যায়।\n- অনুপস্থিত আইটেমগুলো সাধারণ ভাষায় নামকরণ করা হয়েছে।\n- আংশিক অনুমোদনের নিয়ম আছে, অনুমান নয়।\n- সময়সূচি স্পষ্ট।\n\nতারপর একটি সাধারণ টেস্ট চালান। ডিজাইন না করা ব্যক্তিকে প্রক্রিয়াটি দিন। তাদেরকে একটি প্রত্যাখ্যাত অনুরোধ এবং একটি অনুরোধ দিন যা একটি ডকুমেন্ট অনুপস্থিত। যদি তারা এক মিনিটের মধ্যেই কী করতে হবে না বলে পারে, প্রক্রিয়াটি এখনও বেশি অস্পষ্ট।\n\nএকটি ছোট উদাহরণ পয়েন্টটি করে দেখায়। ধরুন একজন ব্যবস্থাপক সফটওয়্যার অনুরোধ অনুমোদন করে কিন্তু হার্ডওয়্যার অংশ প্রত্যাখ্যান করে। যদি স্ট্যাটাস কেবল বলে "Partially approved", কর্মচারী ধরে নিতে পারে সবকিছু এগোয়। একটি ভাল স্ট্যাটাস ঠিক বলে কি অনুমোদিত, কি প্রত্যাখ্যাত, এবং কর্মচারী কি মিসিং অংশ পুনরায় সাবমিট করতে পারবেন কি না।\n\nআপনি যদি সেই নিয়মগুলোকে কাজ করা অভ্যন্তরীণ অ্যাপে রূপান্তর করতে চান, প্রথমে ব্যতিক্রম স্টেটগুলো ম্যাপ করুন এবং পরে হ্যাপি পাথটি তৈরি করুন। AppMaster-এ এটি মানে স্ট্যাটাস, বিজনেস নিয়ম, এবং প্রয়োজনীয় ফিল্ডগুলি ডিসাইন করার পরে স্ক্রিন নিয়ে চিন্তা করা। এটি নো-কোড অ্যাপ্লিকেশন তৈরি করার একটি বাস্তব পদ্ধতি যাতে বাস্তব কাজগুলো হ্যান্ডল করা যায়, কেবল আদর্শ সংস্করণ নয়।\n\nপরবর্তী ধাপ সহজ: আপনার শীর্ষ পাঁচটি ব্যতিক্রম তালিকাভুক্ত করুন, প্রতিটির জন্য একটি মালিক নিয়োগ করুন, এবং ব্যবহারকারীকে যে বার্তাটি দেখা উচিত তা লিখুন। যদি এই তিনটি অংশ স্পষ্ট হয়, বিল্ড করা সাধারণত অনেক সহজ হয়ে যায়।