জেনারেটেড অ্যাপের নামকরণ: প্রথম দিন থেকেই নিয়মাবলী

কেন নামকরণ দ্রুত ঘোলা হয়ে যায়\n\nনামকরণ সমস্যা সাধারণত বড় কোনো সিদ্ধান্ত থেকে শুরু করে না। ছোট ছোট শর্টকাট থেকেই শুরু হয়।\n\nএকটি স্ক্রিনে লেখা আছে "Open", এক বাটনে লেখা আছে "Start", আর পরের প্রম্পটে বলা হচ্ছে "Active" আইটেম। এই তিনটি একই স্টেটকে নির্দেশ করলেও অ্যাপ এগুলোকে ভিন্ন ধারণা হিসেবে ধরতে শুরু করে। প্রথমে যা ক্ষুদ্র মনে হয়েছিল তা পরে দলের এবং ব্যবহারকারীদের জন্য বিভ্রান্তিকর হয়ে ওঠে।\n\nএটি বিশেষ করে চ্যাট-ভিত্তিক প্রোডাক্টে ঘনঘন ঘটে কারণ মনে রাখতে হতে থাকে সময়ের সাথে একই জিনিস বিভিন্নভাবে বর্ণিত হয়েছে কি না। সোমবার একজন প্রতিষ্ঠাতা একটি রোলকে বলে "manager"। বুধবার একজন সহকর্মী অনুরোধ করে "admin" ভিউ। এক সপ্তাহ পর কেউ যোগ করে "team lead"। কেউ যদি থামেই এক লেবেল বেছে না নেয়, অ্যাপ এক ধারণাকে একাধিক ভার্সনে ভাগ করতে শুরু করে।\n\nক্ষতি একই সাথে দুই জায়গায় দেখা দেয়। প্রম্পট লেখা কঠিন হয় কারণ বিল্ডার সবসময় বুঝতে পারেনা দুটি শব্দ একই অর্থ রাখে কি না। স্ক্রিনগুলো ব্যবহার করা কঠিন হয়ে যায় কারণ ব্যবহারকারীরা একই ধরনের অ্যাকশন, স্ট্যাটাস, বা অনুমতির জন্য বিভিন্ন লেবেল দেখে বিভ্রান্ত হয়।\n\nছোট টিমগুলো প্রথমে এই সমস্যাটি অনুভব করে। একজন এখনো স্মরণ করতে পারে যে "approved", "published", এবং "live" একই জিনিস বোঝায়। নতুন সহকর্মী তা মনে রাখে না। তাদের অনুমান করতে হয় প্রতিটি শব্দের মানে কী, কোথায় সেটি প্রদর্শিত হয়, এবং একটি লেবেল বদলালে অন্যগুলোও বদলানো উচিত কিনা।\n\nপ্যাটার্নটি পরিচিত। একটি ফিচার দ্রুত নামকরণ করা হয় যাতে কাজ চালিয়ে যেতে পারে। পরে প্রম্পটে ভিন্ন শব্দ ব্যবহার করা হয় যা কাছে কাছেই শোনায়। স্ক্রিন, ফিল্টার, এবং নোটিফিকেশন দুভাবে দেখাতে থাকে। তারপর কেউ এক লেবেল আপডেট করে এবং বাকিগুলো মিস করে।\n\nএখন এমনকি সহজ সম্পাদনাও সময় বেশি নেয়। একটি বাটন রিনেম করার অনুরোধ বড় পরিবর্তনে পরিণত হয় কারণ সেই বাটন টেক্সট একটি স্ট্যাটাস, একটি ওয়ার্কফ্লো ধাপ, এবং একটি রিপোর্ট ফিল্টারের সাথে যুক্ত।\n\nKoder.ai-এর মতো প্ল্যাটফর্মে, যেখানে টিমগুলো ন্যাচারাল ল্যাঙ্গুয়েজ দিয়ে অ্যাপ গঠন করে, শব্দ ব্যবধানগুলো আরও বেশি বিষয়বস্তুর। পরিষ্কার লেবেলগুলো পরিবর্তন অনুরোধ করতে সহজ করে তোলে যাতে অনিচ্ছাকৃত ডুপ্লিকেট তৈরি না হয়ে যায়।\n\nঅ্যাপ নামকরণ নিয়মাবলী ঝকঝকে শব্দ বলার বিষয়ে নয়। এগুলো বিভ্রান্তি ছড়ানোর আগেই থামায়। যখন নামগুলো সঙ্গতিপূর্ণ থাকে, প্রম্পট লেখা সহজ হয়, স্ক্রিন আপডেট করা নিরাপদ হয়, এবং হ্যান্ডঅফগুলো স্মৃতির ওপর কম নির্ভরশীল হয়।\n\n## কোনগুলো আগে নাম দেওয়া উচিত\n\nপ্রথম যে নামগুলো আপনি বেছে নেবেন সেগুলোই আপনার অ্যাপে বারবার দেখাবে: স্ক্রিন, বাটন, ফিল্টার, নোটিফিকেশন, এবং ভবিষ্যৎ প্রম্পট। যদি ঐ শব্দগুলো জায়গা জায়গায় বদলে যায়, মানুষ ধীর হয়ে যায়, বেশি প্রশ্ন করে, এবং বেশি ভুল করে।\n\nযেসব টার্মগুলো ব্যবহারকারী প্রতিদিন দেখবে সেগুলো দিয়ে শুরু করুন।\n\n### ওয়ার্কফ্লো শব্দগুলো আগে রাখা উচিত\n\nস্ট্যাটাসগুলো দ্রুত নাম দিয়ে রাখা উচিত কারণ এগুলো লিস্ট, রিপোর্ট, এবং অটোমেশনে দেখা যায়। একটি ছোট পরিষ্কার লেবেল সেট বেছে নিন—উদাহরণ: Draft, Active, Closed—এবং প্রতিটির মানে সংজ্ঞায়িত করুন। কেউ যদি একটি জায়গায় Closed বলে, অন্য জায়গায় Completed বলে, আর তৃতীয়জনে Done বলে, অ্যাপ দ্রুত অসঙ্গত মনে হতে শুরু করবে।\n\nরোলগুলোও একই যত্ন চাই। Admin, Manager, এবং Viewer শুনতে সাধারণ মনে হতে পারে, কিন্তু টিমগুলো প্রায়ই একই শব্দে ভিন্ন পারমিশন সংযুক্ত করে। একটি অ্যাপে manager অনুরোধ অনুমোদন করতে পারে; অন্যটায় একই রোল শুধু রিভিউ করতে পারে। নামটি অবশ্যই দায়িত্বের সাথে মিলতে হবে।\n\nঅ্যাকশনগুলোর গুরুত্বও কম নয়। Create, Approve, Assign, Archive, এবং Delete নীতিগতভাবে বেছে নিন কারণ এগুলো ব্যবহারকারীর প্রত্যাশা গড়ে দেয় যে পরে কি হবে। উদাহরণস্বরূপ Archive এবং Delete কখনোই একই বোঝানো উচিত নয় যদি না আপনি চান ব্যবহারকারীরা ভুলবশত ডেটা হারিয়ে ফেলুক।\n\n### আপনার প্রধান বিজনেস অবজেক্টগুলোর নাম দিন\n\nআপনার কোর রেকর্ডগুলো শুরু থেকেই স্থিতিশীল নাম হওয়া উচিত। ঠিক করুন অ্যাপটি কি ট্র্যাক করবে—orders, leads, accounts, requests, projects, না কি অন্য কিছু। একই রেকর্ডের জন্য দুইটি শব্দ ব্যবহার করা এড়িয়ে চলুন, যেমন একটি মেনুতে Customer আর অন্য জায়গায় Account যদি না ওগুলো সত্যিই ভিন্ন অর্থ বহন করে।\n\nমেনু ও ফিল্টারে শেয়ার করা টার্মগুলো অনেক টিমের চেয়ে বেশি গুরুত্বপূর্ণ। যদি সাইডবারে লেখা থাকে Open, ফিল্টারে Active, এবং ড্যাশবোর্ডে Current, ব্যবহারকারীরা সময় নষ্ট করে অনুমান করবে এগুলো মেলে কি না।\n\nএকটি সহজ প্রাথমিক নামকরণ সেট সাধারণত পাঁচ জিনিস কভার করে: স্ট্যাটাস, রোল, অ্যাকশন, কোর রেকর্ড, এবং শেয়ার করা মেনু টার্ম। আপনি যদি Koder.ai-র মতো প্রম্পট-ভিত্তিক টুল দিয়ে তৈরি করে থাকেন, তাহলে এই লেবেলগুলো ভবিষ্যৎ প্রম্পটগুলোও পরিষ্কার করে। মডেলের কাছে পড়ার জন্য শব্দ সংখ্যা কমে যায়, তাই অ্যাপ বাড়ার সাথে সাথে বেশি সঙ্গতিশীল থাকে।\n\n## নামকরণ সিস্টেমের সহজ নিয়মগুলো\n\nএকটি নামকরণ সিস্টেম ফ্যান্সি হওয়ার প্রয়োজন নেই। কেবল পরিষ্কার হওয়াই যথেষ্ট।\n\nমূল নিয়মটি সহজ: একটি ধারণার জন্য একটা লেবেল। যদি একটি স্ক্রিনে বলা হয় "client", অন্যটায় বলা হয় "customer", এবং পরে একটি প্রম্পটে বলা হয় "account holder", মানুষ শব্দগুলোর বিশ্বাস করা বন্ধ করে দেবে।\n\nআপনার টিম যেভাবে সাধারণ কথোপকথনে শব্দ ব্যবহার করে, সেই শব্দগুলো বেছে নিন। সংক্ষিপ্ত, পরিচিত লেবেলগুলো মনে রাখা সহজ এবং পরে পুনরায় ব্যবহার করতেও সুবিধা হয়। "Approved" হল পুরোপুরি ভাল, যেখানে "administratively validated" ব্যবহার করার দরকার নেই। "Manager" এমনটিই রাখুন যেটা বুঝতে সহজ, জটিল টাইটেল না।\n\nঅ্যাকশন নামগুলো পরিষ্কার ক্রিয়া দিয়ে শুরু হওয়া উচিত। বাটন ও মেনু আইটেমগুলো এমন হওয়া উচিত যাতে ব্যবহারকারী ঠিক জানে কি ঘটবে: "Create invoice", "Send reminder", "Archive project"। জেনারেটেড অ্যাপ প্রম্পটে অস্পষ্ট লেবেল যেমন "Handle" বা "Process" পরে বিভ্রান্তিকর আপডেটে নিয়ে আসে।\n\nসংখ্যার স্টাইলেও সঙ্গতি রাখুন—একবার singular না plural ঠিক করে নিন, তারপর তা বজায় রাখুন। যদি মেনুতে "Orders" থাকে, কোথাও "Order list" বা "My order" ব্যবহার করবেন না যদি না বাস্তব কারণ থাকে।\n\nশেষ যে নিয়মটি টিমগুলো সবচেয়ে বেশি এড়িয়ে যায় তা হল: গুরুত্বপূর্ণ টার্মগুলো সরল ভাষায় সংজ্ঞায়িত করুন। প্রতিটি মূল শব্দের জন্য একটি সংক্ষিপ্ত লাইনের মতো লিখে রাখুন। কী গণ্য হবে একটি lead? কখন একটি আইটেম closed হয়? একজন রিভিউয়ার কি করতে পারে? একজন নতুন টিমমেট কয়েক সেকেন্ডে সংজ্ঞা পড়ে বোঝা উচিত।\n\nআপনি যদি Koder.ai বা যেকোন চ্যাট-ভিত্তিক টুলে তৈরি করেন, এই নিয়মগুলো প্রম্পটগুলোকে স্থিতিশীল করে। যখন লেবেলগুলো সঙ্গতিপূর্ণ থাকে, অ্যাপ বাড়ানো সহজ হয় এবং টিম কম সময় ব্যয়ে কী শব্দগুলো বোঝায় তা নিয়ে পরিষ্কার করে।\n\n## প্রথম দিন থেকেই কিভাবে নিয়ম নির্ধারণ করবেন\n\nস্ক্রিন, ওয়ার্কফ্লো, এবং প্রম্পট বাড়ার আগে নামকরণ ঠিক করা সহজ। প্রথম দিন একটি সাধারণ শেয়ার করা নোট খুলে ঠিক করুন অ্যাপটি তার কোর জিনিসগুলো কীভাবে ডাকবে। সেই প্রথম ঘণ্টা অনেক পরিশোধ কমিয়ে দিতে পারে।\n\nযেসব প্রধান আইটেম ব্যবহারকারী তৈরি, দেখা বা সম্পাদন করবে সেগুলো দিয়ে শুরু করুন। একটি সেলস অ্যাপে সেটা হতে পারে Lead, Account, Deal, Task, এবং Invoice। প্রতিটি আইটেমের জন্য একটি নাম বেছে নিন এবং সেটা প্রতিটি স্থানে ব্যবহার করুন—প্রম্পট, মেনু, এবং অভ্যন্তরীণ নোট সহ।\n\nতারপর প্রতিটি আইটেমের সম্ভাব্য স্টেটগুলো নাম দিন। একটি ডিল যে জায়গায় "Open" বলা হচ্ছে আরেক জায়গায় "Active" এবং প্রম্পটে "In progress" বলা হচ্ছে, যদি এগুলো একই মানে বোঝায় তাহলে একটি নাম বেছে নিয়ে তা ডকুমেন্ট করুন।\n\nরোলগুলোর ক্ষেত্রেও একই শৃঙ্খলা দরকার। সাধারণ শব্দ ব্যবহার করুন যেমন Admin, Manager, Agent, বা Customer। ফ্যান্সি টাইটেল আকর্ষণীয় মনে হতে পারে, কিন্তু হ্যান্ডঅফের সময় পারমিশন বোঝানো কঠিন করে তোলে।\n\nঅ্যাকশনগুলোর মধ্যে অসঙ্গতি সবচেয়ে দ্রুত ঢুকে পড়ে। আগেই ঠিক করে নিন ব্যবহারকারী কি "create" করবে না "add", "archive" না "close", "assign" না "send"। বাটন টেক্সট, মেনু লেবেল, এবং প্রম্পট একই ভের্ব ব্যবহার করা উচিত যাতে ব্যবহারকারী পরবর্তী কি হবে তা জানে।\n\nএকটি সহজ দিনের-এক সেটআপ যথেষ্ট:\n\n- অ্যাপের কোর আইটেমগুলো তালিকা করুন।\n- প্রতিটি আইটেমকে একটি স্ট্যান্ডার্ড নাম দিন।\n- প্রতিটি আইটেমের অনুমোদিত স্ট্যাটাসগুলো সংজ্ঞায়িত করুন।\n- রোল নামগুলো বেছে নিন এবং প্রতিটি রোল কি করতে পারে তা নোট করুন।\n- বাটন, মেনু, এবং অটোমেশনের জন্য অ্যাকশন শব্দগুলো নির্ধারণ করুন।\n\nএই নিয়মগুলো এমন জায়গায় রাখুন যাকে পুরো টিম দেখতে পায়। একটি পেইজই যথেষ্ট যদি তা আইটেম নাম, অনুমোদিত স্ট্যাটাস, রোল, এবং অ্যাকশন নামগুলো দেখায়। আপনি যদি Koder.ai-এ তৈরি করছেন, এটি পরিকল্পনা নোটে বড় পরিবর্তনের আগে রাখা যেতে পারে।\n\nএইভাবে পরবর্তী প্রম্পট লেখা সহজ হয়, নতুন টিমমেটের অনুমান কমে, এবং অ্যাপ কম নামকরণ সংঘর্ষ নিয়ে বাড়ে।\n\n## ছোট টিম অ্যাপ থেকে একটি বাস্তব উদাহরণ\n\nএকটি ছোট টিম শ্রম অনুরোধ ট্র্যাক করার জন্য একটি অভ্যন্তরীণ অ্যাপ তৈরি করে। সাপোর্ট লিড প্রতিটি আইটেমকে বলে ticket। অপারেশন ম্যানেজার একই জিনিসকে বলে request। চ্যাট প্রম্পট ব্যবহার করে একজন প্রতিষ্ঠাতা দুই শব্দই মিশিয়ে অ্যাপ তৈরি করেন। শীঘ্রই প্রোডাক্ট উভয় শব্দই বিভিন্ন স্ক্রিন, ফিল্টার, এবং নোটিফিকেশনে ব্যবহার করতে থাকে।\n\nপ্রথমে এটি ক্ষুদ্র মনে হয়। তারপর দলটি একটি সহজ প্রশ্নের উত্তর দেওয়ার চেষ্টা করে: "আমাদের কতটি open tickets আছে?" অন্য কেউ জিজ্ঞেস করে, "আপনি কি এমন requests বলতে চান যা রিভিউয়ের জন্য অপেক্ষা করছে, নাকি সব pending কাজ?" একটি লেবেল দুটি অর্থে ভাগ হয়ে যায়।\n\nএকই ঘটনা স্ট্যাটাসগুলোর সাথে হয়। একজন Pending ব্যবহার করে যা সমাপ্ত নয় বলে বোঝায়। অন্যজন In Review ব্যবহার করে সেই আইটেমগুলো বোঝাতে যেগুলো ম্যানেজারের অপেক্ষায় আছে। শীঘ্রই উভয় স্ট্যাটাসই একই ধাপের জন্য ব্যবহার করা শুরু হয়। মানুষ বোর্ডে বিশ্বাস রাখা বন্ধ করে দেয় কারণ তারা বুঝতে পারে না কাজ ব্লকড, অপেক্ষায়, না পরীক্ষা করা হচ্ছে।\n\nরোলও এলোমেলো হয়ে যায়। এক প্রম্পটে অ্যাপ রিভিউয়ার (Reviewer) ব্যবহার করে যে ব্যক্তি বিশদ দেখে। অন্য প্রম্পটে Approver বলা হয় যে ব্যক্তি চূড়ান্ত অনুমোদন দেয়। কিন্তু এই টিমে এক ম্যানেজার দুটোই করে। পরে একটি নতুন টিমমেট ধরে নিয়ে নেয় এগুলো আলাদা রোল এবং অপ্রয়োজনীয় অতিরিক্ত ধাপ যোগ করে।\n\nএকটি সংক্ষিপ্ত নামকরণ শীট দ্রুত এই সমস্যা মিটিয়ে দেয়। এটাকে পোলিশ করা লাগবে না; কেবল প্রধান শব্দগুলো একবার সরল ভাষায় সংজ্ঞায়িত করলেই হয়।\n\n### উদাহরণ নামকরণ শিট\n\n- Request: অ্যাপের প্রধান ওয়ার্ক আইটেম\n- Pending: জমা হয়েছে কিন্তু এখনও চেক করা হয়নি\n- In Review: বর্তমানে ম্যানেজার দ্বারা চেক করা হচ্ছে\n- Reviewer: সঠিকতা এবং সম্পূর্ণতা পরীক্ষা করে\n- Approver: চূড়ান্ত হ্যাঁ বা না দেয়\n\nএই নামগুলো একবার নির্ধারণ হলে ভবিষ্যৎ প্রম্পটগুলো অনেক পরিষ্কার হয়। উদাহরণস্বরূপ, "Approve" স্টেজ যোগ করার পরিবর্তে দলটি বলতে পারে, "Approver কনফার্ম করলে একটি request In Review থেকে Approved-এ সরানো হবে।" এতে অনুমান কমে।\n\nপরের হ্যান্ডঅফটাও সহজ হয়ে যায়। নতুন ব্যক্তি পাঁচ লাইন পড়েই বুঝে যাবে অ্যাপটি কিভাবে কাজ করে।\n\n## ভাল নামগুলো ভবিষ্যৎ প্রম্পটকে কিভাবে উন্নত করে\n\nভালো নামগুলো পরবর্তী প্রম্পটগুলোকে ছোট ও স্পষ্ট করে দেয়। যখন আপনার অ্যাপে স্ট্যাটাস, রোল, এবং অ্যাকশনগুলোর নির্দিষ্ট লেবেল থাকে, আপনি একই কথা বারবার ব্যাখ্যা করতে হবে না।\n\nদইটাই হলো নামকরণ নিয়মাবলীর রিটার্ন। একটি প্রম্পট যেমন "manager-only actions show for Approved requests" কাজ করবে কারণ প্রতিটি শব্দের একটি নির্দিষ্ট মানে আছে।\n\nওই শেয়ার করা শব্দভাণ্ডার না থাকলে প্রম্পট দ্রুত লম্বা হয়ে যায়। আপনি পরিমার্জন যোগ করতে থাকেন যেমন "manager মানে team lead, account owner নয়" বা "approved হল চূড়ান্ত স্টেট, reviewed নয়"। এ ধরনের ছোট সংশোধনগুলো কাজ ধীর করে এবং সিস্টেমের ভুল আন্দাজ করার সুযোগ বাড়ায়।\n\nপরিবর্তিত স্ক্রিন জেনারেট করার সময়ও পরিষ্কার নামগুলো সাহায্য করে। যদি অ্যাপ সব সময় Draft, In Review, এবং Published ব্যবহার করে, পরবর্তী ভার্সন সম্ভবত ঐ লেবেলগুলোই রাখবে। কিন্তু যদি একটি স্ক্রিনে Pending এবং অন্যটায় Waiting for approval থাকে, বিল্ডার সেগুলোকে ভিন্ন স্টেট মনে করে বিভ্রান্তি অনুযায়ী তৈরি করে ফেলতে পারে।\n\nনামকরণ সিস্টেম সংশোধনের রাউন্ডগুলোও কমিয়ে দেয়। আলাদা আলাদা পাসে "staff"—>"agent", "done"—>"resolved", এবং "submit"—>"send request" ঠিক করার বদলে আপনি যেগুলো আছে সেগুলো নিয়ে কাজ চালিয়ে যেতে পারবেন।\n\nকখন আরেকজন প্রজেক্ট নিতে যখন, একটি সহকর্মী, ফ্রিল্যান্সার, বা ক্লায়েন্ট লেবেলগুলো পড়ে দ্রুত অ্যাপ বুঝে ফেলবে। তাদের দীর্ঘ ব্যাখ্যা লাগবে না কারণ নামগুলোই কাজে লাগবে।\n\nউদাহরণস্বরূপ, একটি সাপোর্ট অ্যাপ যদি রোল হিসেবে Customer, Agent, এবং Admin এবং স্ট্যাটাস হিসেবে New, Assigned, Waiting on Customer, এবং Closed ব্যবহার করে, পরে ড্যাশবোর্ড, ফিল্টার, বা মোবাইল ভার্সনের অনুরোধগুলো বর্ণনা করা অনেক সহজ হয়। Koder.ai-র মতো চ্যাট-ভিত্তিক বিল্ডারে স্থিতিশীল ভাষা প্ল্যাটফর্মকে কম ভুল অনুমান করার সুযোগ দেয়।\n\n## সাধারণ ভুলগুলো যা এড়াতে হবে\n\nসবথেকে দ্রুত বিভ্রান্তি সৃষ্টি করে এমন পথ হল একই জিনিসকে একাধিক নাম দেওয়া। যদি আপনার অ্যাপে একই রেকর্ডের জন্য "client", "customer", এবং "account" ব্যবহার করা হয়, মানুষ অনুমান করতে থাকবে। ভবিষ্যৎ প্রম্পটগুলোও কম নির্ভরযোগ্য হবে কারণ টিম ও প্রোডাক্ট একই ভাষি ব্যবহার করছে না।\n\nএটি সাধারণত সেই সমার্থক শব্দগুলো দিয়ে শুরু হয় যা অদৃশ্য মনে হয়। এক সহকর্মী "approved" লিখে, অন্যজন "accepted", তৃতীয়জন "confirmed" ব্যবহার করে। প্রতিটি লেবেল আলাদাভাবে যুক্তিযুক্ত মনে হলেও একসাথে তারা ফিল্টার, রিপোর্ট, এবং হ্যান্ডঅফকে কঠিন করে তোলে।\n\nআরেকটি ভুল হল অভ্যন্তরীণ স্ল্যাং ব্যবহার করা। একটি সাপোর্ট টিম বলতে পারে "save it to ops" বা "send it to tier two", কিন্তু ব্যবহারকারীদের কাছে এগুলো অর্থহীন হতে পারে। অভ্যন্তরীণ শর্টহ্যান্ড ব্যক্তিগত নোটে ঠিক আছে—ইউজার-ফেসিং লেবেলগুলো সাধারণ ও স্পষ্ট হওয়া উচিত।\n\nটিমগুলো প্রায়ই সমস্যায় পড়ে যখন তারা অ্যাপে একটি লেবেল আপডেট করে কিন্তু পুরনো প্রম্পট, টেমপ্লেট, এবং ডকস ভুলে যায়। তখন স্ক্রিনে নতুন বাটন নাম দেখা যায় কিন্তু সেভ করা নির্দেশনায় পুরনো নাম থাকে। কেউ প্রম্পট অনুসরণ করে অ্যাকশন খুঁজে না পায় এবং ভুল ধরে অ্যাপ ভাঙা বলে ধরে নেয়।\n\nরোলগুলো বিশেষভাবে সহজে মিলিয়ে যায়। "Manager" হতে পারে প্রকৃত চাকরির টাইটেল, আর "Admin" হতে পারে অ্যাপ-স্তরের পারমিশন লেভেল। একজন মানুষকে বর্ণনা করে আর অন্যটাই বুঝায় তারা সিস্টেমে কি করতে পারে। যদি এই ধারণাগুলো মিশে যায়, অ্যাক্সেস নিয়ম বোঝানো ও রক্ষণাবেক্ষণ করা কঠিন হয়ে ওঠে।\n\nঅ্যাকশন নামগুলোতেও একই পরিষ্কার চাই। "Process" লেবেল প্রায় কিছুই বলে না। কি প্রসেস হবে, পরে কি ঘটবে? পরিষ্কার ক্রিয়াগুলো যেমন "Approve invoice", "Assign lead", বা "Archive project" সন্দেহ দূর করে।\n\nআপনি যদি জেনারেটেড অ্যাপ প্রম্পটে তৈরি করে থাকেন, প্রতিটি অস্পষ্ট বা অসঙ্গত নাম পরে আরও পরিষ্কারের কাজ বাড়ায়। আজকের ছোট নামের ভুল ভবিষ্যতে অদক্ষ স্ক্রিন, গোলমেলে প্রম্পট, এবং অপ্রয়োজনীয় টিম প্রশ্নে বদলে যেতে পারে।\n\n## একটি দ্রুত নামকরণ চেকলিস্ট\n\nভালো নামকরণ সিস্টেম এমন হওয়া উচিত যেন প্রায় বিরক্তিকর মনে হয়। একজন নতুন টিমমেট প্রোডাক্ট খুলে কয়েকটি স্ক্রিন পড়লেই যেন বুঝে যায় কোনো জিনিসের মানে কি, অনুবাদ ছাড়াই।\n\nলেবেলগুলো চূড়ান্ত করার আগে কয়েকটি সহজ প্রশ্ন করুন:\n\n- একজন নতুন ব্যক্তি কি প্রতিটি লেবেল বুঝতে পারবে?\n- স্ট্যাটাসগুলোর কি একটা পরিষ্কার ক্রম আছে?\n- প্রতিটি রোল কি একটিমাত্র সরল নাম পেয়েছে?\n- বাটনগুলো কি স্পষ্ট ক্রিয়া দিয়ে শুরু হয়েছে?\n- প্রম্পট ও স্ক্রিনে কি একই শব্দগুলো ব্যবহৃত হয়েছে?\n\nএকটি দ্রুত টেস্ট সাহায্য করে। আপনার লেবেলগুলোকে প্রকল্পের বাইরে কাউকে দিন পাঁচ মিনিটের জন্য এবং বলুন প্রতিটি স্ট্যাটাস, রোল, ও বাটন কী করে তা ব্যাখ্যা করতে। যদি তারা ভুল ধরে, নামটি কাজ করে না এবং পরিবর্তন করা দরকার।\n\nএই বিষয়টি দ্রুত তৈরি করার সময় আরও বেশি গুরুত্বপূর্ণ হয়। যখন প্রম্পট, UI লেবেল, এবং টিম নোট এক ভাষি ব্যবহার করে, ভবিষ্যৎ পরিবর্তন অনুরোধ করা, রিভিউ করা, এবং শিপ করা সহজ হয়।\n\nআপনার চেকলিস্ট যদি এমনকি একটি দুর্বল লেবেল খুঁজে পায়, সেটা দ্রুত ঠিক করুন। ছোট নামকরণ গ্যাপগুলি একবার বেশি স্ক্রিন, ওয়ার্কফ্লো, এবং টিমমেট জড়িত হলে দ্রুত ছড়িয়ে পড়ে।\n\n## আপনার টিমের পরবর্তী ধাপগুলো\n\nএকটি নামকরণ সিস্টেম তখনই কাজ করে যখন পুরো টিম সেটি সহজে ব্যবহার করতে পারে। সবচেয়ে সহজ পরবর্তী ধাপ একটি সংক্ষিপ্ত রেফারেন্স পেজ তৈরি করা এবং এটাকে একটি ভাগ করা রুলবুক হিসেবে ব্যবহার করা। এটিকে এত সরল রাখুন যাতে একজন প্রতিষ্ঠাতা, ডিজাইনর, ডেভেলপার, বা অপস টিমমেট দুই মিনিটে পড়ে বুঝতে পারে।\n\nওই পেজে বিশেষ করে সবচেয়ে ঘন ঘন ব্যবহৃত শব্দগুলো থাকা উচিত—স্ট্যাটাস, রোল, এবং অ্যাকশন। এই টার্মগুলো প্রতিদিন প্রম্পট, স্ক্রিন, টেবিল, এবং টিম চ্যাটে দেখা যায়। যদি এক ব্যক্তি "approved" লেখে এবং অন্যজন "accepted", বিভ্রান্তি ছোট থেকেই দ্রুত ছড়িয়ে পড়ে।\n\nএকটি ভাল স্টার্টার পেজ সাধারণত অনুমোদিত স্ট্যাটাস নাম, পারমিশন সম্পর্কে সংক্ষিপ্ত নোটসহ রোল লেবেল, স্ট্যান্ডার্ড অ্যাকশন ভের্ব, এবং কিছু স্টাইল নিয়ম যেমন singular বনাম plural বা টাইটেল কেস ব্যবহারের নিয়ম যোগ করে। একটি বা দুটি বাস্তব উদাহরণও সাহায্য করে, বিশেষ করে যদি তা স্ক্রিন বা প্রম্পটে টার্মগুলো কীভাবে ব্যবহার হচ্ছে তা দেখায়।\n\nএকবার পেজ তৈরি হলে নতুন ফিচার যোগ করার আগে সেটি রিভিউ করুন। নামকরণ সমস্যা সাধারণত দ্রুত আপডেটের সময় ঘটে, প্রথম নির্মাণের সময় নয়। একটি দ্রুত চেক আগে নতুন মডিউল, ফর্ম, বা ওয়ার্কফ্লো যোগ করার সময় ডুপ্লিকেট টার্ম প্রবেশ করা বন্ধ করতে পারে।\n\nসবাই প্রয়োজনীয় পরিবর্তন দাবি করলে পেজটি প্রতিবার রিরাইট করবেন না। শুধুমাত্র তখন আপডেট করুন যখন একটি টার্মের অর্থ সত্যিই বদলে যায় বা পুরনো নাম বাস্তবে বিভ্রান্তি তৈরি করে। স্থিতিশীল নামগুলো নির্ভুল নামের চেয়ে বেশি গুরুত্বপূর্ণ।\n\nআপনি যদি Koder.ai-এ তৈরি করেন, পরিকল্পনা মোডে এই নিয়মগুলো রাখলে ভবিষ্যৎ প্রম্পটগুলোকে একটি পরিষ্কার শব্দভাণ্ডার দেয়। এতে স্ক্রিন, রোল, এবং ফ্লোগুলিকে সঙ্গতিপূর্ণ রাখা সহজ হয় যখন প্রোডাক্ট বাড়ে।\n\nঅ্যাপ নামকরণ নিয়মাবলী ব্র্যান্ডিং অনুশীলন নয়। এগুলো একটা ব্যবহারিক অভ্যাস যা প্রম্পট পরিষ্কার করে, হ্যান্ডঅফ সহজ করে, এবং ভবিষ্যৎ পরিবর্তন অনেক কম কষ্টের করে তোলে।