অ্যাপ তৈরি করার সময়ে বাস্তব জীবনের ব্যতিক্রমগুলো সামলানো

কেন পরিপাটি অ্যাপ ফ্লো বাস্তবে ব্যর্থ হয়

পরিপাটি ফ্লোচার্ট সুন্দর দেখায় কারণ তা ধরে নেয় মানুষগুলো সঠিক ক্রমে, সঠিক তথ্য দিয়ে, সঠিক সময়ে কাজ করবে। বাস্তব কাজ তেমন কমই হয়। কেউ ফর্ম দেরিতে জমা দেয়, ম্যানেজার অসুস্থ হয়ে থাকে, গ্রাহক একটি গুরুত্বপূর্ণ বিবরণ ছেড়ে যায়, অথবা কোনো পেমেন্ট এমন বিশেষ অনুমোদন চায় যা শুরুতে বলা ছিল না।

এতেই বোঝা যায় প্রথম সংস্করণটি ডেমোতে সম্পূর্ণ মনে হতে পারে কিন্তু ভেতরে মানুষ কাজে নেমে পড়লেই ভেঙে পড়তে পারে। "হ্যাপি পাথ" কাজ করে; দৈনন্দিন কাজ বেশিক্ষণ সেই পথেই থাকে না।

সবচেয়ে নিরাপদ ধারণা হলো পরিপাটি সংস্করণ অসম্পূর্ণ বলে ধরে নেওয়া। ছোট একটি অসঙ্গতি পুরো অনুরোধটিকে দ্রুত বদলে দিতে পারে। একটি অনুপস্থিত ফিল্ড, এক অস্বাভাবিক ক্লায়েন্ট, বা এক বিলম্বিত অনুমোদন পুরো প্রক্রিয়াকে আটকে দিতে পারে এবং মানুষগুলোকে ভাবতে ছেড়ে দেয় পরবর্তী কী করা উচিত।

সাধারণ ব্যর্থতাগুলো সাধারণত সাদামাটা:

• একটি অনুরোধ এগোয়, তারপর আটকে যায় কারণ অনুমোদক উপলব্ধ নেই।
• একটি রেকর্ড সেভ হয় না কারণ একটি বাধ্যতামূলক বিবরণ এখনও জানা নেই।
• একটি বিশেষ কেস সাধারণ কেসের মতো আচরণ করা হয় এবং পরে হাতে ঠিক করতে হয়।

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

একটি ভাল লক্ষ্য সহজ: নিয়ম লেখার আগে ব্যতিক্রমগুলো সংগ্ৰহ করুন। ডেটা অনুপস্থিত হলে কী হয়, টাইমিং ভুল হলে কী হয়, এবং অনুরোধটি স্ট্যান্ডার্ড পথ মানায় না তখন কী হয়—এগুলো জিজ্ঞাসা করুন। এই ঝামেলাগুলো ছোট-বিষয় নয়; এগুলোই নির্ধারণ করে আপনার অ্যাপ বাস্তবে কাজ করবে কিনা।

কোন ব্যতিক্রমগুলো আগে খুঁজবেন

প্রথম সমস্যাগুলো বিরল এজ-কেস নয়। এগুলো সেই বিশৃঙ্খল ঘটনা যা প্রতি সপ্তাহে ঘটে এবং পরিপাটি ওয়ারফ্লোকে চুপচাপ ভেঙে দেয়। শক্ত প্রথম সংস্করণ চাইলে দেখুন কোথায় কাজ বিলম্বিত হচ্ছে, ব্লক হচ্ছে, বা সিস্টেম সিদ্ধান্ত নিতে না পেরে মানুষকে হাতে সঁপে দিচ্ছে।

বিলম্বিত অনুমোদনগুলো সাধারণত তালিকার উপরে থাকে। একজন ম্যানেজার ডেডলাইনের পরে, পে-রোল ক্লোজ হওয়ার পরে, অথবা স্টক পুনরায় অর্ডার হওয়ার পরে অনুমোদন করে। অ্যাপটি সেই মুহূর্তের জন্য একটি নিয়ম রাখতে হবে। এটি কি অনুরোধ পুনরায় খুলবে, একটি নতুন অনুরোধ তৈরি করবে, ফাইন্যান্সকে জানাবে, নাকি রিভিউ-তে পাঠাবে—পরের ধাপ কী হবে? অ্যাপ সেগুলো জেনে কাজ করা উচিত।

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

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

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

মানব রিভিউ একটি ব্যর্থতা নয়। যখন সিস্টেম কনফ্লিকটিং ডেটা দেখছে, নীতির ব্যতিক্রম হচ্ছে, বা উচ্চ-খরচের কাজ চলছে, তখন মানব রিভিউ প্রায়শই সবচেয়ে নিরাপদ। একটি পজ করা রিভিউ কিউ সাধারণত মিসটেক করে যাওয়ার থেকে ভাল।

যদি আপনি এগুলো আগে থেকেই খুঁজে পান, প্রথম সংস্করণটি অনেক বেশি বাস্তবমুখী এবং কম ভঙ্গুর হবে।

বাস্তব উদাহরণ কোথায় সংগ্রহ করবেন

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

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

পুরনো কাজও একটি ভালো উৎস। আগের ইমেইল, সাপোর্ট টিকিট, চ্যাট মেসেজ, এবং হ্যান্ডঅফ নোটগুলো প্রায়ই দেখায় ঠিক যে মুহূর্তে পরিপাটি ফ্লো ভেঙেছিল। এই রেকর্ডগুলো দরকারি কারণ এগুলো মানুষ যখন কিছু ভুল হয় তখন যেই ভাষা ব্যবহার করে তা ক্যাপচার করে—প্রসেস ডকুমেন্টের পরিশোধিত ভাষা নয়।

পাশের টুলগুলোও দেখুন। কেউ যদি স্প্রেডশিট, স্টিকি-নোট লিস্ট, বা ব্যক্তিগত ডকুমেন্টে ব্যতিক্রম ট্র্যাক করে, সেটি একটি শক্তিশালী সংকেত। ওয়ার্কারাউন্ডগুলোর কারণ আছে এবং সেগুলো প্রায়ই সেই নিয়মগুলো প্রকাশ করে যা আপনার অ্যাপ প্রথম দিন থেকেই লাগবে।

প্রথমে যে সোর্সগুলো রিভিউ করবেন তারা সাধারণত শ্যাডো সিস্টেমের মতো: স্প্রেডশিট এবং ব্যক্তিগত চেকলিস্ট, ইমেইল থ্রেড যেখানে মানুষ অনুপস্থিত তথ্য বা ম্যানুয়াল অনুমোদন চায়, জরুরি ফিক্স নিয়ে চ্যাট কথোপকথন, বিলম্ব বা বাতিল এন্ট্রি উল্লেখ করা সাপোর্ট টিকিট, এবং সাম্প্রতিক ভাঙা কেসগুলোর পূর্ণ টাইমলাইন।

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

যদি আপনি চ্যাট-ভিত্তিক বিল্ডারে প্রথম খসড়া স্কেচ করছেন, লজিক জেনারেট করার আগে এসব উদাহরণগুলো সংগ্রহ করুন। বাহিরে গন্ধ ছাড়া ঝুঁকি কমে—চেনে গেলে messy কেসগুলো দৃশ্যমান থাকলে নিরাপদ ফ্লো বানানো সহজ।

কিভাবে গল্পগুলোকে অ্যাপ লজিকে রূপান্তর করবেন

একটি তত্ত্ব নয়, একটি বাস্তব কেস দিয়ে শুরু করুন। একটি মানুষ যে ভাবে নিজের টীমমেটকে বলবে সেভাবে লিখুন: ওরা কী করার চেষ্টা করছিল, কী ভুল হল, কে হস্তক্ষেপ করেছিল, এবং কিভাবে শেষ হয়েছে।

"অনুরোধটি আটকে গিয়েছিল কারণ ম্যানেজার ছুটিতে ছিল, পরে ফাইন্যান্স এক ফিল্ড না থাকা সত্ত্বেও পরে অনুমোদন করেছে"—এরকম এক বিশৃঙ্খল গল্প পরিপাটি ফ্লোচার্টের চেয়ে বেশি কাজের। এটি দেখায় কোথায় অ্যাপ সাধারণত ভাঙে।

গল্প থেকে নিয়ম

প্রতিটি কেস থেকে চারটি কথা টানুন: কী ঘটল, কে সিদ্ধান্ত নিল, কেন তারা তা করল, এবং অ্যাপ পরবর্তী কি করবে।

এটি আচরণের উপর ফোকাস রাখে—শুধু স্ক্রিন নয়। লক্ষ্য প্রতিটি অদ্ভুত কেস কভার করা নয়, বরং পুনরাবৃত্তি করে এমন প্যাটার্ন চিহ্নিত করা।

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

তারপর প্রতিটি বালতিকে সবচেয়ে লঘু নিয়মে পরিণত করুন যা কাজ করে। সেই নিয়ম সার্বক্ষণিক অটোমেশন হওয়া দরকার না। মাঝে মাঝে একটি সতর্কবার্তা, একটি পজ, বা একটি ম্যানুয়াল রিভিউই সেরা সিদ্ধান্ত।

উদাহরণস্বরূপ, যদি অনুমোদন দেরিতে আসে কারণ অনুমোদক অনুপস্থিত, অ্যাপ ২৪ ঘণ্টার পরে রিমাইন্ডার পাঠাতে পারে, ৪৮ ঘণ্টার পরে পুনরায় অ্যাসাইন করতে পারে, বা ব্যাকআপ অনুমোদককে রিভিউ করতে পাঠাতে পারে। যদি একটি গুরুত্বপূর্ণ ফিল্ড অনুপস্থিত থাকে, সম্পূর্ণ ঠোকাঠোকি বন্ধ করে দেওয়ার বদলে সেভ-এন্ড-রিটার্ন ড্রাফট বেস্ট অপশন হতে পারে। এতে প্রসেস চলতে থাকে এবং সমস্যা লুকোয় না।

আপনি যদি Koder.ai মতো চ্যাট-ভিত্তিক টুলে তৈরি করছেন, সোজা ভাষার কেসগুলো অনেক সাহায্য করে। সেগুলো সিস্টেমকে কনক্রিট কিছু দেয় যাতে প্রথম ওয়ার্কফ্লো বাস্তব সিদ্ধান্তের উপর ভিত্তি করে তৈরি হয়, একটি পরিপাটি কিন্তু বাস্তবে অপ্রাসঙ্গিক অনুমানের উপর নয়।

বাস্তব কেস দিয়ে টেস্ট করুন

লজিক লক করার আগে দুই বা তিনটি বাস্তব গল্প ওতে চালান। কয়েকটি সহজ প্রশ্ন জিজ্ঞাসা করুন। ফ্লো কি বাস্তব কেসের মত একই আউটকাম পায়? তথ্য অনুপস্থিত হলে কি এটি নিরাপদভাবে ব্যর্থ করে? কি এটা কখন মানবকে ডেকে?

যদি না হয়, একেবারে জটিলতা যোগ করবেন না। আগে নিয়মটাকে সহজ ভাষায় পুনর্লিখুন। পরিষ্কার নিয়ম সাধারণত এমন বুদ্ধিমান নিয়মের চেয়ে ভাল যা কেউ বোঝে না।

একটি সহজ উদাহরণ: ব্যয় অনুমোদন

পরিপাটি সংস্করণ দিয়ে শুরু করুন। একজন কর্মী একজন ক্লায়েন্টের জন্য $42 ট্যাক্সি খরচ জমা করেন। তারা তারিখ, পরিমাণ, প্রজেক্ট নাম ও রসিদ যোগ করেন। তাদের ম্যানেজার পে-রোল কাটঅফের আগে অনুমোদন করেন, এবং ফাইন্যান্স পরবর্তী রিমবার্সমেন্ট রান-এ এটিকে যুক্ত করে।

সেই পথ মডেল করা সহজ, কিন্তু পুরো কাজ নয়।

প্রথম ব্যতিক্রম যোগ করুন। কর্মী অনুরোধ সময়মতো জমা দেয়, কিন্তু ম্যানেজার পে-রোল ক্লোজ হওয়ার এক দিন পরে অনুমোদন করে। অ্যাপ ইচ্ছে করলে সেটি নীরবে ঠেলতে ব্যবহার করা উচিত না, এবং সেটি খারাপও প্রত্যাখ্যান করা উচিত না।

একটি ভাল প্রতিক্রিয়া হলো অনুরোধটিকে একটি পরিষ্কার স্ট্যাটাসে নিয়ে আনা, যেমন "কাটঅফের পরে অনুমোদিত"। সেখান থেকে অ্যাপ পরবর্তী পে-রোল সাইকেলে পেমেন্ট ধরে রাখতে পারে, কর্মীকে নতুন পে-আউট তারিখ জানাতে পারে, এবং কেবল তখনই ফাইন্যান্সকে রুট করবে যদি কোম্পানির পলিসি ম্যানুয়াল অফ-সাইকেল পেমেন্ট অনুমোদন করে।

এর মানে অ্যাপকে একাধিক তারিখ রাখতে হবে—কবে সাবমিট করা হয়েছিল, কবে অনুমোদিত হয়েছিল, এবং কোন কাটঅফ মিস করা হয়েছে।

দ্বিতীয় ব্যতিক্রম যোগ করুন। কর্মী রসিদ ভুলে গেছেন, তাই ম্যানেজার কেবল ব্যাখ্যার ভিত্তিতেই অনুমোদন দেন। দুই দিন পরে রসিদ আসে।

ভালভাবে নির্মিত হলে কেসটি অদৃশ্য হয়ে যাবে বা শূন্য থেকে শুরু হবে না। এটি একটি "রসিদের জন্য অপেক্ষা" হোল্ডে যাবে, রিমাইন্ডার পাঠাবে এবং খোলা থাকবে। যখন রসিদ পরে আপলোড হবে, অ্যাপ কেসটি পুনরায় খুলবে এবং কেবল সেই ধাপে পাঠাবে যেটি এখনও অ্যাকশন চায়।

এমন একটি ফ্লো কয়েকটি সহজ স্টেটে যেতে পারে: submitted, waiting for manager approval, approved after cutoff, on hold for missing receipt, এবং reopened for finance review.

এটাই বাস্তব ব্যতিক্রম হ্যান্ডলিংয়ের অনুশীলন। অ্যাপ কেবল হ্যাঁ/না সিদ্ধান্ত নিচ্ছে না; এটি সিদ্ধান্ত নিচ্ছে ধরে রাখবে, রুট করবে, বা কেসটি পুনরায় খুলবে—বিনা কনটেক্সট, তারিখ বা দায়িত্ব হারানো ছাড়া।

কিভাবে অনুপস্থিত তথ্যকে ফ্লো ভাঙা ছাড়া হ্যান্ডেল করবেন

অনুপস্থিত তথ্য স্বাভাবিক—বিরল এজ-কেস নয়। যদি আপনার অ্যাপ ধরে নেয় প্রতিটি ফর্ম প্রথমবারেই পূর্ণ হবে, ব্যবহারকারীরা ফাঁক হাতে পেলেই ফ্লো আটকে যাবে। একটি ভাল নিয়ম সরল: পরবর্তী ধাপের জন্য শুধু যা দরকার সেটাই রিকোয়ার করুন।

ধাপ ধরে পরিকল্পনা করুন। এখনই অ্যাপকে কী জানতে হবে, আর কী পরে অপেক্ষা করতে পারে—এটা জিজ্ঞাসা করুন। একটি ব্যয় অনুরোধ জমা দেওয়ার জন্য পরিমাণ ও কর্মীর নাম প্রয়োজন হতে পারে, কিন্তু চূড়ান্ত রসিদ কেবল পেমেন্টের আগে দরকার হতে পারে। এতে কাজ চলতে থাকে কিন্তু কন্ট্রোলও কমে না।

অসম্পূর্ণ কাজ দৃশ্যমান করুন

ব্যবহারকারীকে অগ্রগতি সেভ করার সুযোগ দিন এমনকি কিছু বিবরণ অনুপস্থিত থাকলেও। একটি ড্রাফট যা পুনরায় খোলা যায় তা আবার শুরু করার মতো একটি ফর্মের চেয়ে অনেক ভাল। এটি তখনই বেশি জরুরি যখন অনুপস্থিত তথ্য অন্য किसी—যেমন ম্যানেজার, ভেন্ডর, বা ফাইন্যান্স টিম—এর উপর নির্ভর করে।

পরিষ্কার স্ট্যাটাস সবাইকে কী হচ্ছে তা বুঝতে সাহায্য করে। সংক্ষিপ্ত ও স্ক্যানযোগ্য রাখুন: waiting for info, blocked by missing document, needs review, ready for approval, sent back for update।

এই লেবেলগুলো একই সময়ে দুই কাজ করে। এগুলো বর্তমান অবস্থা দেখায় এবং ব্যবহারকারীকে বলে কোন ধরনের সমস্যা ঠিক করা দরকার।

প্রতিটি অনুপস্থিত আইটেমের একটি মালিকও থাকা দরকার। যদি ট্যাক্স আইডি অনুপস্থিত থাকে, কে তা যোগ করবে? রসিদ অস্পষ্ট হলে কে তা প্রতিস্থাপন করবে? অনুমোদন নোট না থাকলে কে তা দিতে পারবে? যখন কেউ ঠিক করার মালিক থাকে না, রেকর্ডগুলো লিম্বোতে পড়ে থাকে।

একটি সরল উদাহরণ থেকে এটা স্পষ্ট হবে। ধরুন একজন কর্মী হোটেল থেকে রসিদ না পেয়ে ভ্রমণ ব্যয় জমা দেয়। অ্যাপটিকে তাদের সেভ এবং সাবমিট করার অনুমতি দেওয়া উচিত একটি "রসিদের জন্য অপেক্ষা" স্ট্যাটাস দিয়ে। ফাইন্যান্স বাকি অংশ রিভিউ করতে পারে, কর্মী জানবে কী অনুপস্থিত, এবং অনুরোধটি নিঃশব্দ ত্রুটিতে অদৃশ্য হবে না।

কখন অটোমেট করবেন এবং কখন একজনকে জিজ্ঞাসা করবেন

যখন একই ইনপুট প্রায়ই একই ফলাফল দেয়—তখন অটোমেশন সবচেয়ে ভাল কাজ করে। যদি একটি অনুরোধ স্পষ্ট প্যাটার্ন ফলো করে, তাকে একটি নিয়ম দিন। যদি উত্তর অনুপস্থিত কনটেক্সট, অস্বাভাবিক টাইমিং, বা বিচার নির্ভর করে, একজন মানুষকে পাঠান।

এই বিভাজন গুরুত্বপূর্ণ। একটি ভালো অ্যাপ সাধারন কেসগুলোতে দ্রুত চলবে এবং অস্পষ্ট কেসে ধীর হবে। একটি ভুল স্বয়ংক্রিয় সিদ্ধান্ত স্বল্প মানের ম্যানুয়াল রিভিউয়ের চেয়েও বেশি কাজ তৈরি করতে পারে।

একটি সহজ পরীক্ষা সাহায্য করে: একই ডেটা পেলে দুজন আলাদা টিম মেম্বার কি একই সিদ্ধান্ত নিতো? হ্যাঁ হলে অটোমেট করুন। না হলে মানুষকে রেখো।

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

কিছু পরিস্থিতি মোটেও অনুমান করা উচিত নয়: মূল বিবরণ অনুপস্থিত, অনুরোধ নর্মাল প্যাটার্ন ভাঙে, দুটি নিয়ম সংঘর্ষে আছে, খরচ বা ঝুঁকি বেশি, বা কাউকে ব্যাখ্যা করা দরকার।

ধরা যাক একটি ভ্রমণ অনুরোধে গন্তব্য নেই, জরুরি তারিখ আছে, এবং খরচ সাধারণ সীমার উপরে। অ্যাপটি চালাক হবে না—এটি কেস ফ্ল্যাগ করবে, ফ্লো থামাবে, এবং সঠিক ব্যক্তির কাছে পাঠাবে।

অতএব, প্রতিটি ব্যতিক্রমের কারণ দৃশ্যমান রাখাও সমান জরুরি। দেখান কেন অ্যাপ থামালো, কোন নিয়ম ট্রিগার হলো, এবং কোন তথ্য অনুপস্থিত। এতে রিভিউ দ্রুত হয় এবং টিম পরে ওয়ার্কফ্লো উন্নত করতে পারে।

এড়ানোর মতো সাধারণ ভুলগুলো

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

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

আরেক ভুল হলো বিভিন্ন পরিস্থিতিকে একে অপরের ভেতর লুকিয়ে দেওয়া একটি অস্পষ্ট নিয়মে। "কিছু ভুল মনে হলে অ্যাডমিনকে পাঠাও"—এমন নিয়ম নমনীয় শোনালেও নতুন সমস্যা তৈরি করে। অ্যাডমিন কে? কীকে ভুল বলে গণ্য করা হবে? কেউ দুদিনে সাড়া না দিলে কী হবে?

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

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

অডিট ইতিহাস সাধারণ কারণেই জরুরি। মানুষ জানতে চায় কে কোন ভ্যালু বদলে দিয়েছে, কাউকে ব্যতিক্রম অনুমোদন করেছে, এবং কখন স্ট্যাটাস ঘুরেছে।

লজিক জেনারেট করার আগে একটি দ্রুত চেক

কোনও ওয়ার্কফ্লোকে নিয়মে পরিণত করার আগে বিরতি দিন এবং দেখুন আপনার ইনপুটগুলো বাস্তব কাজের সাথে মেলে কি না। পরিপাটি ডায়াগ্রামগুলো প্রায়ই ওই অদ্ভুত কেসগুলো মিস করে যেগুলো পরে বিলম্ব, বিভ্রান্তি, বা ম্যানুয়াল ফিক্স সৃষ্টি করে।

একটি দ্রুত রিভিউ সাহায্য করে:

• অনুমান না করে বাস্তব উদাহরণ থেকে শুরু করুন।
• প্রতিটি ব্যতিক্রম এক সংক্ষিপ্ত বাক্যে নামান।
• ব্লক হওয়া কেসগুলোর মালিক কে তা নির্ধারণ করুন।
• ব্যবহারকারীরা অনুপস্থিত তথ্য থেকে কীভাবে ফিরে আসে তা পরীক্ষা করুন।
• শুরু থেকে শেষ পর্যন্ত একটি বাস্তব পরিস্থিতি টেস্ট করুন।

একটি সরল টেস্ট কেস প্রায়ই দুর্বল লজিক উন্মোচন করে। ধরুন একটি ক্রয় অনুরোধ সাপ্লায়ার নাম ছাড়া সাবমিট হয়, তারপর ডিপার্টমেন্ট লিড দেরিতে অনুমোদন করে। রিকোয়েস্টকারী কি অনুপস্থিত ফিল্ড ঠিক করতে পারবে? অ্যাপ জানে কি তা পুনরায় খুলবে, চালিয়ে নেবে, বা ফাইন্যান্সকে রিভিউ করতে পাঠাবে?

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

নিরাপদ প্রথম সংস্করণের পরবর্তী ধাপসমূহ

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

প্রথম সংস্করণটি সেই সংকীর্ণ ওয়ার্কফ্লো এবং ঐ পাঁচটি কেসের চারপাশে তৈরি করুন। নিয়মগুলো পড়তে সহজ রাখুন। যদি একটি অনুরোধ অসম্পূর্ণ, কি অনুপস্থিত তা দেখান। যদি অনুমোদন দেরি হয়, কখন রিমাইন্ডার পাঠানো হবে, কখন এস্কেলেট করা হবে, এবং কখন পজ করা হবে তা ঠিক করুন। যদি একটি কেস সাধারণ পথ মেনে না চলে, স্পষ্টভাবে বলুন কে পর্যালোচনা করবে।

তারপর যাদের কাজের সাথে সম্পর্ক আছে তাদের নিয়ে এটিকে টেস্ট করুন: রিকোয়েস্ট সাবমিট করা মানুষ, প্রথম অনুমোদক, ব্যতিক্রম ঠিক করা ব্যক্তি, এস্কেলেশনের জন্য যে ম্যানেজার, এবং যিনি চূড়ান্ত ফলাফল দেখেন।

এরা কোথায় আটকে যায়, অনুমান করে, বা সাহায্য চায় সেটাও লক্ষ্য করুন। এই মুহূর্তগুলোই মসৃণ কাজের চেয়েও বেশি গুরুত্বপূর্ণ। যদি তিনজনই একই ধাপে আটকে যায়, নিয়ম বা স্ক্রিন পরিবর্তন করতে হবে।

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

তারপর ছোট রাউন্ডে নিয়মগুলো ঠিক করুন। বিভ্রান্তি সৃষ্টিকারী ধাপগুলো বাদ দিন। শুধুমাত্র সেই ফিল্ডগুলো যোগ করুন যেগুলো পুনরাবৃত্ত সমস্যা আটকায়। রিমাইন্ডারের টাইমিং পরিবর্তন করুন যদি প্রয়োজন পড়ে। বাস্তব টেস্টিংয়ের পরে ছোট পরিবর্তনগুলো সাধারণত আগে থেকে জটিল বিশেষ-কেস লজিক যোগ করার চেয়ে ভালো।

দ্রুত প্রোটোটাইপ করতে চাইলে Koder.ai-এর মতো চ্যাট-ভিত্তিক বিল্ডার সাহায্য করতে পারে বাস্তব উদাহরণগুলোকে ধাপে ধাপে কাজ করা অ্যাপে পরিণত করতে। মূল কথা একই: প্রথমে ঝামেলাজনক গল্পগুলো ধরুন, তারপর তাদের চারপাশে নিয়ম বানান।