AI অ্যাপের ব্যবসায়িক নিয়ম সহজ ভাষায় দলিল করুন

অস্পষ্ট নিয়ম কেন নির্ভরযোগ্য অ্যাপ তৈরিতে ব্যর্থতা দেয়

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

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

"বড় ব্যয়গুলোর ক্ষেত্রে ম্যানেজারের অনুমোদন দরকার"—এমন একটি নিয়ম মানুষকে মনে হতে পারে পরিষ্কার। কনস্ট্রাক্টর বা বিল্ডার তা মনে নাও করতে পারে। কী ধরা হবে বড়: $500, $5,000, নাকি টিম বাজেট ছাড়ালে? কোন ম্যানেজার: সরাসরি ম্যানেজার, বিভাগের প্রধান, না ফাইনান্স? যদি কেউ দুই দিনের মধ্যে সাড়া না দেয়, অনুরোধ কি অপেক্ষা করবে, মেয়াদোত্তীর্ণ হবে, নাকি কাউকে ফরেয়ার্ড হবে?

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

সবচেয়ে বড় সমস্যা সাধারণত কয়েকটি ক্ষেত্রে দেখা যায়:

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

একটি সাদামাটা উদাহরণ সমস্যাটা দেখায়। একজন প্রতিষ্ঠাতা Koder.ai-তে একটি অভ্যন্তরীণ ব্যয় অ্যাপ বানান এবং লেখেন, "Reimburse travel costs unless they seem unusual." এটি যুক্তিযুক্ত শোনালেও, অ্যাপের কাছে অনিয়মিত কি তা বিচার করার নির্ভরযোগ্য উপায় নেই। একজন কর্মীর ট্যাক্সি অনুমোদিত হয়, অনুরূপ আরেকটি চিহ্নিত হয়, এবং কেউ জানে না কেন।

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

স্পষ্ট ব্যবসায়িক নিয়ম কেমন হওয়া উচিত

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

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

অধিকাংশ স্পষ্ট নিয়ম চারটি মৌলিক প্রশ্নের উত্তর দেয়:

• কে সিদ্ধান্ত নেয় বা পদক্ষেপ নেয়?
• কখন নিয়মটি প্রযোজ্য?
• অ্যাপে কী পরিবর্তন ঘটে?
• এরপর কী হয়?

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

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

ফারাকটা সহজেই দেখা যায়:

"Premium customers get priority handling" অস্পষ্ট।

"If the customer has a premium plan, the support request is marked High Priority when the ticket is created" স্পষ্ট।

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

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

সহজ ভাষায় গণনা লেখা

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

একটি ভালো নিয়ম শুনতে এমন লাগে: "The reimbursement amount equals approved miles multiplied by the mileage rate." এটা অনেক বেশি পরিষ্কার "calculate travel pay" বা "apply standard reimbursement"-এর থেকে।

এরপর, প্রতিটি ইনপুট কী হবে তা সংজ্ঞায়িত করুন। বিল্ডার যাতে অনুমান না করে সেজন্য যথেষ্ট নির্দিষ্ট হন।

প্রতিটি গণনার জন্য কী নির্ধারণ করবেন

প্রতিটি গণনার জন্য স্পষ্টভাবে লিখে রাখুন:

• ইনপুটগুলো, সহজ নাম ও ইউনিটসহ
• প্রতিটি মান কোথা থেকে আসে
• রাউন্ডিং নিয়ম
• যেকোনও ন্যূনতম বা সর্বোচ্চ মান
• কোনো মান অনুপস্থিত হলে কী হবে

ক্ষুদ্র বিস্তারিতগুলোই গুরুত্বপূর্ণ। "শেষ পরিমাণ 2 দশমিক স্থানে রাউন্ড করুন" প্রতিটি লাইনের আইটেম আগে রাউন্ড করলে যে ফল হবে তার থেকে ভিন্ন ফল দেয়। যদি ক্যাপ থাকে, বলুন অ্যাপ কি ক্যাপে পৌঁছে থামবে নাকি একটি ওয়ার্নিং দেখাবে।

একটি সহজভাবে লেখা নিয়ম হতে পারে: "The travel reimbursement equals approved miles x $0.67. Round the final amount to 2 decimal places. The maximum reimbursement is $300 per trip. If approved miles is blank, do not calculate the amount. Mark the request as incomplete and ask the user to enter miles."

তারপর একটি বা দুটি কাজ করা উদাহরণ দিন বাস্তব সংখ্যাসহ। উদাহরণগুলি বিমূর্ত সূত্রের চেয়ে দ্রুত ফাঁক দেখায়।

উদাহরণ 1: "If approved miles is 120, reimbursement is 120 x $0.67 = $80.40. Because this is below the $300 cap, the final amount is $80.40."

উদাহরণ 2: "If approved miles is 500, reimbursement is 500 x $0.67 = $335.00. Because the maximum is $300, the final amount is $300.00."

এই ধাঁচ মানুষদের জন্য রিভিউ করা সহজ এবং বিল্ডারকে অ্যাপ আচরণে রূপান্তর করতে সহজ।

বিভ্রাটগুলো টিজে নেওয়া (exceptions) বাগ ছাড়া ধরা

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

ব্যতিক্রম লেখার সহজ উপায় হল ছোট if-then নিয়ম ব্যবহার করা। প্রতিটি নিয়মকে একটি শর্ত ও একটি ফলাফলের উপর রাখুন।

• If the expense is under $100, then auto-approve.
• If the expense is under $100 but submitted after 30 days, then send it for manual review.
• If the employee is in the executive team, then skip the $100 limit and route to finance.
• If a finance admin marks the claim as urgent, then manual override applies and the claim moves to the top of the queue.

এই ফরম্যাটটি লুকোনো লজিককে দৃশ্যমান করে তোলে। এটি ওভারল্যাপ খুঁজে পেতে সাহায্য করে আগে যে গুলি বাগে পরিণত হয়।

একইভাবে গুরুত্বপূর্ণ, বলুন দুটি নিয়ম সংঘর্ষ করলে কোনটি জয়ী হবে। একজন গ্রাহক ডিসকাউন্টের যোগ্য হতে পারে, কিন্তু অর্ডারটি ছুটির ব্ল্যাকআউট সময়ে পড়তে পারে। সাধারণ ভাষায় অগ্রাধিকার লিখুন: "If a holiday blackout rule conflicts with a customer discount rule, the blackout rule wins."

সীমাগুলোতে সুনির্দিষ্ট হন। তারিখ, ব্যবহারকারী টাইপ, অবস্থান, অ্যাকাউন্ট স্ট্যাটাস এবং ম্যানুয়াল ওভাররাইড প্রায়ই ফলাফল পরিবর্তন করে। "late submissions need approval" লেখার বদলে লিখুন, "If a request is submitted more than 14 calendar days after the event, then manager approval is required."

এছাড়া প্রতিটি ব্যতিক্রমে অ্যাপ ব্যবহারকারীকে কী দেখাবে তাও বলুন। একটি ভালো নিয়ম সিদ্ধান্তে থামে না; এটি মেসেজও নির্ধারণ করে, যেমন "Submitted after 14 days. Manager approval required" বা "Manual override applied by finance admin."

এইভাবে ব্যতিক্রম লেখা হলে অস্বাভাবিক কেসগুলো অস্বাভাবিক মনে হওয়া বন্ধ করে। তারা স্বাভাবিক, টেস্টযোগ্য আচরণে পরিণত হয়।

ধাপে ধাপে অনুমোদন লজিক বর্ণনা করা

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

শুরু করুন নির্দিষ্ট করে ভূমিকাটি নাম দিয়ে, শুধুমাত্র টিম না বলেই। "finance reviews large requests" লেখার বদলে লিখুন, "the Finance Manager can approve, reject, or send back any request over $5,000." এতে অনুমান নেই এবং আচরণ নির্মাণ সহজ হয়।

তারপর প্রতিটি ধাপের ট্রিগার সংজ্ঞায়িত করুন। একটি ট্রিগার হলো শর্ত যা অনুরোধকে পরবর্তী ব্যক্তির কাছে পাঠায়। এটি পরিমাণ, depart­ment, রিস্ক স্কোর, অনুরোধের ধরন বা এগুলোর মিশ্রণ হতে পারে।

উদাহরণস্বরূপ:

• If the request is under $500, the team lead reviews it.
• If the request is $500 to $5,000, the department manager reviews it after the team lead approves.
• If the request is above $5,000, finance reviews it after the department manager approves.
• If the request is marked high risk, compliance must review it before final approval.

থ্রেশহোল্ডগুলোতে সঠিক সীমানা রাখুন। "large" বা "sensitive" বলবেন না। বলুন "above $5,000," "from the Sales department," বা "risk score 8 or higher." যদি একই সময়ে দুটি থ্রেশহোল্ড প্রযোজ্য হয়, বলুন কোনটি জয়ী। উদাহরণ: "High risk always goes to compliance, even if the amount is low."

আপনাকে একটি টাইমআউট নিয়মও দরকার। যদি কেউ সাড়া না দেয়, অ্যাপ কালে অনন্তকাল অপেক্ষা করা উচিৎ নয়। নির্দিষ্ট সময়ের পরে কী হবে বলুন, যেমন 48 ঘন্টা বা 3 ব্যবসায়িক দিন। অনুরোধকে অনুমোদকের ম্যানেজারের কাছে এসক্যালেট করা যেতে পারে, ব্যাকআপ অনুমোদকের কাছে পুনরায় বরাদ্দ করা যেতে পারে, বা স্বয়ংক্রিয়ভাবে বাতিল করা হতে পারে।

শেষে, প্রতিটি সিদ্ধান্তের পর স্ট্যাটাস নির্ধারণ করুন। সংক্ষিপ্ত ও ধারাবাহিক লেবেল ব্যবহার করুন:

• Approved: অনুরোধ এগিয়ে চলে বা সম্পন্ন হয়।
• Rejected: অনুরোধ বন্ধ হয়ে যায় এবং আর কোনো পদক্ষেপ নেই।
• Sent back: রিকোয়েস্টকারী সম্পাদনা করে পুনরায় জমা দেবে।
• Escalated: অনুরোধ ব্যাকআপ বা উচ্চতর অনুমোদকের কাছে যায়।

যখন অনুমোদন লজিক এইভাবে লেখা হয়, বিল্ডারের অনুমানের সম্ভবনা কমে যায় এবং ওয়ার্কফ্লো বেশি নির্ভরযোগ্য হয়।

আপনি পুনরায় ব্যবহার করতে পারবেন এমন একটি সহজ নিয়ম টেমপ্লেট

নিয়মগুলোর ধারাবাহিক আচরণ চাইলে প্রতিটি নিয়মকে একই আকার দিন। মিশ্র লেখা শৈলী প্রায়শই মিশ্র ফল নিয়ে আসে।

একটি সহজ ফর্ম্যাট বেশিরভাগ ক্ষেত্রে ভাল কাজ করে: trigger, conditions, action, result। এটি দ্রুত লিখার জন্য যথেষ্ট ছোট এবং পরে অন্য কেউ রিভিউ করতেও স্পষ্ট।

এক নিয়ম, এক ইউনিট ব্যবহার করুন

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

একটি ব্যবহারিক টেমপ্লেট এরকম দেখতে পারে:

Trigger: When [event happens]
Conditions: If [facts must be true]
Action: Then [the app does this]
Result: So [expected outcome]
Assumption: [anything not yet confirmed]
Example: [short sample input and output]

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

উদাহরণস্বরূপ:

Trigger: When an employee submits an expense claim
Conditions: If the total is over $500 and no receipt is attached
Action: Then send the claim back for correction
Result: So incomplete claims are not forwarded to a manager
Assumption: Receipt is required for all claims above $500
Example: A $620 taxi claim without a receipt is returned to the employee

দ্রষ্টব্য: উদাহরণটি নিয়মের নিচে আছে, নিয়মের ভিতরে নয়। এতে নিয়মটি পরিষ্কার থাকে। উদাহরণটি কেবল প্রমাণ করে নিয়মটি কীভাবে আচরণ করবে।

ধারণাগুলো স্পষ্টভাবে চিহ্নিত করুন—"Assumption" বা "Needs confirmation"—তাই খোলা প্রশ্নগুলো বিল্ডিংয়ের আগে সহজে দেখা যায়।

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

একটি দ্রুত টেস্ট ভালো কাজ করে: কেউ কি এই নিয়ম পরীক্ষা করতে পারবে, এবং কেউ কি এটিকে ভুল বুঝতে পারবে? যদি প্রথমটির উত্তর না হয় বা দ্বিতীয়টির উত্তর হ্যাঁ হয়, শব্দগুলো আরও টাইট করুন।

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

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

নমুনা নীতি

মিল রুলটি এইভাবে লিখুন: কর্মচারীরা সাধারণ কর্মদিবসে প্রতিদিন সর্বোচ্চ $40 পর্যন্ত খাবারের দাবি করতে পারবেন। অ্যাপকে একই তারিখের সবmeal receipt যোগ করে দিনের মোটের সাথে সীমা তুলনা করতে হবে, প্রতিটি রসিদ আলাদাভাবে নয়।

যদি কর্মচারী মঙ্গলবার সকালবেলায় $12 এবং দুপুরে $22 খরচ করে, মোট $34—তাই দাবি পাশ করে। যদি একই দিনে $15 ডিনার যোগ করা হয়, মোট $49 হয়ে যায় এবং অ্যাপকে দাবিটিকে সীমা ছাড়িয়ে চিহ্নিত করতে হবে।

এখন একটি ব্যতিক্রম যোগ করুন। যদি খাবার অনুমোদিত ব্যবসায়িক সফরের সময় বা ক্লায়েন্ট মিটিং-এ ঘটে, দৈনিক খাবারের সীমা $75 পর্যন্ত বাড়ে। সেই ব্যতিক্রম তখনি প্রযোজ্য যখন কর্মচারী Travel day = Yes অথবা Client meeting = Yes নির্বাচন করে এবং ক্লায়েন্টের নাম বা ট্রিপের উদ্দেশ্য নিয়ে একটি সংক্ষিপ্ত নোট যোগ করে।

এটি অস্পষ্ট "special cases may be allowed"-এর চেয়ে বেশি নির্ভরযোগ্য কারণ ব্যতিক্রমটি স্পষ্ট শর্তের সঙ্গে বাঁধা।

অনুমোদন ধাপ

অনুমোদন লজিকটাও একই সরলতায় রাখা যায়:

• $100-এর নিচের দাবিগুলো কর্মচারীর ম্যানেজার অনুমোদন করবেন।
• $100 থেকে $500 পর্যন্ত দাবিগুলো ম্যানেজার অনুমোদনের পরে ফাইন্যান্স অনুমোদন চায়।
• $500-এর উপরের দাবিগুলো ম্যানেজার, ফাইন্যান্স এবং তারপর বিভাগীয় প্রধানের অনুমোদন চায়।
• যে কোনো দাবিতে "travel" মার্ক করা থাকলেও তা পরিমাণ যতই হোক না কেন ফাইন্যান্স রিভিউতেই যাবে।

কিছু সহজ কেস দিয়ে নিয়ম পরীক্ষা করুন। একটি $36 মিল দাবী সাধারণ কর্মদিবসে রিসিট সংযুক্ত থাকলে অনুমোদিত হওয়া উচিৎ। একটি $60 মিল দাবি ট্রাভেল দিনে সঠিক নোট থাকলে পাশ করা উচিত। একটি $60 মিল দাবি সাধারণ দিনে হলে ফিরিয়ে দিয়ে সংশোধনের জন্য বলা উচিত। একটি $650 হোটেল দাবী সব তিন ধাপ অতিক্রম করবে।

লক্ষ্যটাই এমন: নিয়মটি প্রতিবারই একই ফল দেয় যখন কেউ বাস্তব কেস দিয়ে টেস্ট করে।

খারাপ ফল দেয় এমন সাধারণ ভুলগুলো

একটি নিয়ম মানুষকে স্পষ্ট মনে হতে পারে কিন্তু বিল্ডারকে বিভ্রান্ত করতে পারে। সাধারণত এটাই হয় যখন ডকুমেন্টটি অস্পষ্ট, একাধিক ধারণা দিয়ে ভরা, বা লাইনের পর লাইনে inconsistent।

একটি সাধারণ ভুল হল এক বড় প্যারায় একাধিক নিয়ম চাপাটানো। উদাহরণ: "Managers approve travel unless the total is high, finance checks receipts, and urgent requests can skip review." এটি কার্যকর মনে হতে পারে, কিন্তু এতে অনেক আলাদা সিদ্ধান্ত লুকানো আছে। পৃথক নিয়মে বিভক্ত করুন যাতে প্রতিটি অ্যাকশনের নিজস্ব ট্রিগার ও আউটকাম থাকে।

আরেকটি সমস্যা ঝাপসা ভাষা। normal, large, urgent, বা recent এর মত শব্দগুলো তখনই কাজ করে যখন তাদের ব্যাখ্যা থাকে। যদি "large expense" মানে $2,000-এর বেশি হয়, সেটা লিখে দিন। যদি "urgent" মানে 24 ঘন্টার মধ্যে প্রয়োজন, সেই শর্ত লিখুন।

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

সর্বাধিক ঝামেলা যে ভুলগুলো করে তারা:

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

চূড়ান্ত কর্তৃত্ব অনেক দলের চেয়ে বেশি গুরুত্বপূর্ণ। যদি ম্যানেজার ও ফাইন্যান্স রিভিউয়ার দ্বন্দ্ব করে, শেষ সিদ্ধান্ত কার? যদি কেউ চূড়ান্ত ধাপটি না রাখে, অ্যাপ আটকে যাবে বা কাজ ঘুরে বেড়াবে।

শব্দ পরিবর্তন নীরবে ত্রুটি সৃষ্টি করে। যদি আপনি শুরুতে "request" বলেন এবং পরে এটিকে "submission" বা "ticket" বলেন, পাঠকরা ধরে নেবে এরা আলাদা আইটেম। একটি শব্দ বেছে নিন এবং পুরো ডকুমেন্টে সেটাই ব্যবহার করুন।

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

বিল্ডের আগে দ্রুত চেকলিস্ট

স্ক্রিন, ফ্লো বা প্রম্পটে রূপান্তর করার আগে একটি শেষ রিভিউ করুন। একটু চেক এখনই ভবিষ্যতে অদ্ভুত আচরণ ঠিক করতে ঘণ্টা বাঁচাতে পারে।

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

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

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

সম্পূর্ণ অনুমোদন পথ ম্যাপ করুন। প্রতিটি থ্রেশহোল্ডের জন্য বলুন কে অনুমোদন করে এবং পরবর্তী কী হয়। এজগুলোতেও সুনির্দিষ্ট হন: বলুন নীতি $500-এ শুরু হয় না কি $500-এর উপরে থেকে শুরু হয়—এই জিনিসগুলো স্পষ্ট করুন।

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

একটি ছোট উদাহরণ কেন এটা গুরুত্বপূর্ণ তা দেখায়। "Manager approves large expenses" অদ্ভুত মনে হলেও কেউ জিজ্ঞাসা করলে $500 বড় কি না বোঝা যায় না। "Manager approves expenses above $500. Director approves expenses above $2,000. Expenses of $500 or less are auto-approved" অনেক কম ভুলের সুযোগ দেয়।

নিয়মকে কার্যকর অ্যাপে রূপান্তর করা

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

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

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

এই ধাপটি ফাঁকগুলো আগে ধরে ফেলে। একটি নিয়ম কাগজে স্পষ্ট মনে হলেও বাস্তব অনুরোধ যখন প্রত্যাশিত প্যাটার্নে না পড়ে তখন ভাঙ্গতে পারে।

যখন সেসব দৃঢ় হয়, সেগুলোকে আপনার বিল্ডারে নিন। আপনি যদি Koder.ai-র মত চ্যাট-ভিত্তিক প্ল্যাটফর্ম ব্যবহার করছেন, একটি স্পষ্ট নিয়ম সেট বিল্ডটি অনেক দ্রুত করে—কারণ আপনি নির্ধারিত প্রক্রিয়াটিকে স্ক্রিন, অ্যাকশন এবং অনুমোদনে রূপান্তর করছেন না; বরং অন-ফ্লাই সিদ্ধান্ত নেওয়ার দরকার কমে যাচ্ছে।

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

একটি ছোট অভ্যাস সাহায্য করে: প্রক্রিয়া বদলালে নিয়মগুলো রিভিউ করুন, কেবল তখনই নয় যখন অ্যাপ ভেঙে যায়। ছোট আপডেট আগেই করলে বড় বিভ্রাট ঠিক করার চেয়ে অনেক সহজ।

যদি ডকুমেন্ট আপ-টু-ডেট থাকে, অ্যাপ সময়ের সাথে পরীক্ষা, সংস্কার এবং বিশ্বাসযোগ্য হয়ে ওঠে।