ডিসকভারি কল থেকে বিল্ড-প্রস্তুত প্রম্পট তৈরি করা

কেন ডিসকভারি কলগুলো হ্যান্ডফঅফে ব্যর্থ হয়\n\nভাঙনটা সাধারণত মিটিংয়ের পরে ঘটে, মিটিংয়ের সময় নয়। সবাই ডিসকভরি কল থেকে একমত বলে বের হয়, কিন্তু নোটগুলো থেকে কাজ করার জন্য পর্যাপ্ত তথ্য থাকে না। টিমগুলো "needs approvals," "admin view," বা "customer portal" মতো বাক্য লিখে ধরে নেয় যে তা যথেষ্ট। সাধারণত তা যথেষ্ট নয়।\n\nযা হারিয়ে যায় তা হলো ব্যবসার দৈনন্দিন বাস্তবতা। কলটিতে ফিচারগুলো আলোচিত হতে পারে, কিন্তু কে কাজটি করে, কাজগুলি কোন ক্রমে ঘটে, কোন নিয়ম ভাঙা যাবে না, এবং একটি স্বাভাবিক সপ্তাহে সফলতা কেমন দেখায়—এসব মিস হতে পারে। যখন সেই প্রসঙ্গ চলে যায়, প্রথম ভার্সন অনুমানের ওপর তৈরি হয়।\n\nএই অনুমানগুলো দুর্বল প্রথম ভার্সনগুলোর দিকে নিয়ে যায়। একটি স্ক্রিন দৃষ্টিনন্দন দেখাতেও সমস্যা সমাধান না করে থাকতে পারে কারণ এটি ভুল সমস্যার সমাধান করে। "Users submit requests" শুনতে ভাল লাগলে, সেটি জানায় না ব্যবহারকারী গ্রাহক, মাঠ কর্মী, নাকি ম্যানেজার, কিংবা সাবমিশনের পরে কী হওয়া উচিত।\n\nসেজন্য একটি ভালো প্রম্পটে কেবল ফিচার তালিকা নয় ব্যবসায়িক প্রসঙ্গ থাকা দরকার। শক্তিশালী হ্যান্ডঅফটি এরকম হওয়া উচিৎ: "Field staff মোবাইল থেকে সার্ভিস অনুরোধ জমা দেয়, সুপারভাইজাররা সেগুলো একই দিন রিভিউ করেন, জরুরি কাজগুলো সাধারণ কিউ এলে স্কিপ হবে, এবং প্রতিটি পরিবর্তন লগ করা হবে।" এইভাবে বিল্ডারদের জন্য বাস্তব কিছু থাকে।\n\nএটি আরও গুরুত্বপূর্ণ যখন একটি টিম দ্রুত প্রম্পট থেকে কাজ করা প্রোডাক্টে যেতে পারে। Koder.ai-এর মতো প্ল্যাটফর্মে গতি সত্যিই সুবিধা, কিন্তু শুধুমাত্র তখনই যদি প্রম্পটে ব্যবসায়িক লজিকও থাকে।\n\nলক্ষ্যটি সোজা: কল শেষে এমন একটি ব্যক্তি থাকা উচিৎ যিনি প্রম্পট পড়ে সরাসরি বিল্ড শুরু করতে পারেন। তাকে ট্রান্সক্রিপ্ট ডিকোড করতে হবে না বা অনুপস্থিত বিবরণ অনুসরণ করতে হবে না।\n\n## ব্যবহারকারী এবং তাদের বাস্তব কাজ দিয়ে শুরু করুন\n\nভালো হ্যান্ডঅফ মানুষ দিয়ে শুরু হয়, ফিচার দিয়ে নয়। সেই ধাপটি বাদ দিলে প্রথম বিল্ড প্রায়ই এমন স্ক্রিনগুলোর ভিড় হয়ে যায় যাদের কোনো স্পষ্ট মালিক নেই। ডিসকভারি নোটগুলোকে কার্যকর করতে দ্রুততম উপায়টি হল: কে এই প্রোডাক্ট খুলবে, এবং তারা কী করতে চায়?\n\nপ্রতিটি ধরনের ব্যবহারকারীকে নাম দিন, এমনকি গ্রুপগুলো স্পষ্ট মনে হলেও। একজন প্রতিষ্ঠাতা, সেলস রিপ, ম্যানেজার, ফাইনান্স লিড, এবং সাপোর্ট এজেন্ট একই সিস্টেমে পুরোপুরি ভিন্ন কারণে টাচ করতে পারে। যখন এই রোলগুলো মিশে যায়, প্রম্পট অস্পষ্ট হয় এবং প্রথম ভার্সন সবাইকে একই সাথে সার্ভ করার চেষ্টা করে।\n\nপ্রত্যেক অভিনেতাকে বাস্তব কাজের সাথে যুক্ত রাখুন। একটি সেলস রিপ ডিল স্টেজ আপডেট, কল নোট লগ, এবং পরবর্তী অ্যাকশন চেক করতে পারে। একজন ম্যানেজার পাইপলাইন নম্বর রিভিউ, ডিসকাউন্ট অনুমোদন, এবং সাপ্তাহিক রিপোর্ট এক্সপোর্ট করতে পারেন। এই পার্থক্যগুলো নির্ধারণ করে কে কী প্রথম দেখতে পাবে এবং কী পরিবর্তন করতে পারবে।\n\nএকটি সহজ বিভাজন সাহায্য করে:\n\n- দৈনন্দিন ব্যবহারকারী: একই মূল কাজগুলো বারবার করে।\n- ম্যানেজার: রিভিউ, অনুমোদন, এবং সংশোধন করে।\n- অ্যাডমিন: সেটিংস, পারমিশন এবং সিস্টেম নিয়ম পরিচালনা করে।\n- ভিউ-ওনলি ব্যবহারকারী: স্ট্যাটাস দেখে, সম্পাদনা করে না।\n- ফাইনান্স বা অপারেশনস ব্যবহারকারী: প্রায়ই এক্সপোর্ট এবং রিপোর্টিং দরকার।\n\nএটি সাধারণ ভুল এড়ায়: প্রত্যেক ব্যবহারকারীকে অ্যাডমিনের মতো তৈরি করা। বেশিরভাগ লোককে পূর্ণ কন্ট্রোল দরকার নেই। তাদের সাধারণ কাজের জন্য সবচেয়ে দ্রুত পথ দরকার।\n\nএই বিশদ প্রথম প্রম্পটের গুণগতমান বদলে দেয়। "Build a CRM" অস্পষ্ট। "Sales reps leads আপডেট করে, ম্যানেজার কোট পরিবর্তন অনুমোদন করে, সাপোর্ট অ্যাকাউন্ট ইতিহাস দেখতে পারে, এবং ফাইনান্স ক্লোজড ডিল এক্সপোর্ট করে" পণ্যের বাস্তব আকৃতি দেয়।\n\n## কথোপকথনকে স্পষ্ট কাজগুলোতে পরিণত করুন\n\nএকটি দরকারী প্রম্পট কাজগুলোকে এমন এক্টিভিটিতে ভাঙে যা মানুষ আদৌ নেয়। এই পর্যায়েই ডিসকভারি নোটগুলো বিল্ডযোগ্য হয়ে ওঠে।\n\nকেউ বললে, "We need a better way to manage orders," চালিয়ে যান যতক্ষণ না ধাপগুলো পরিষ্কার না হয়। "Manage orders" কোনো কাজ নয়। "Create an order, review payment status, approve shipment, and send a confirmation" হলো কাজ।\n\nকিছু সংক্ষিপ্ত ক্রিয়াপদ নোটগুলো পরিষ্কার করতে সাহায্য করে:\n\n- Create\n- Review\n- Approve\n- Send\n- Update\n\nএই ক্রিয়াপদগুলো ব্যবহার করে বিস্তৃত বিবৃতিগুলোকে টাস্ক লাইনে পুনঃলিখুন। একটি ক্লিনিক মালিক বলতে পারেন, "I want staff to handle bookings faster." বিল্ড-রেডি ভার্সনটি স্পষ্ট হবে: "Receptionist একটি অ্যাপয়েন্টমেন্ট তৈরি করে, ডাক্তারের উপলব্ধতা রিভিউ করে, স্লট নিশ্চিত করে, এবং রোগীকে রিমাইন্ডার পাঠায়।"\n\nপ্রতিটি টাস্কের আগের ও পরের অবস্থা থাকা দরকার। কী ট্রিগার করে? পরে কী হওয়া উচিত? যদি একজন ম্যানেজার রিফান্ড অনুমোদন করেন, তখন কি আগে থাকতে হবে এবং অনুমোদনের পরে কী পরিবর্তিত হবে? ছোট-বড় এসব বিশদ স্ক্রিন, বোতাম, স্ট্যাটাস লেবেল, এবং নোটিফিকেশন নির্ধারণ করে।\n\nএকটি সহজ চেইন ভাল কাজ করে: ট্রিগার, ক্রিয়া, ফলাফল। উদাহরণ: "When a new lead comes in, the sales rep reviews the details, updates the priority, and sends a first reply." এটি প্রথম বিল্ডে রূপান্তর করা অনেক সহজ।\n\nএছাড়া কোন টাস্কগুলো প্রথম দিন গুরুত্বপূর্ণ তা চিহ্নিত করা সহায়ক। যদি তিনটি অ্যাকশন প্রতিদিন ঘটে এবং দুটি এক মাসে একবার ঘটে, দৈনন্দিনগুলো প্রথমে বানান। এটা প্রথম রিলিজকে ফোকাসড ও ব্যবহারিক রাখে।\n\n## সীমাবদ্ধতাগুলো ধরুন, যাতে সেগুলো পরে আঁচড় না করে\n\nভালো প্রম্পট কেবল ফিচারের তালিকা নয়; এতে সেই সীমাগুলোও থাকা দরকার যেগুলো টিমকে মেনে চলতে হবে। কলের সময় যদি ওই সীমাগুলো অস্পষ্ট থাকে, প্রথম ভার্সন সঠিক দেখালেও কার্যপ্রণালীতে ব্যর্থ হতে পারে।\n\nব্যবসায়িক নিয়মগুলো সাধারণ ভাষায় লিখে শুরু করুন। টিম আগে থেকে যদি টেকনিক্যাল বা আইনি ভাষা ব্যবহার করে, তখনও সোজা ভাষা রাখতে পারেন। "role-based approval matrix" বলার বদলে বলুন, "সেলস রিপরা ডিসকাউন্ট ড্রাফট করতে পারে, কিন্তু কেবল ম্যানেজারই তা অনুমোদন করতে পারবেন।"\n\nকিছু সীমাবদ্ধতা পুরো বিল্ডকে আকার দেয় এবং এগুলো প্রথমে ক্যাপচার করা দরকার। এর মধ্যে রয়েছে প্রাইভেসি নিয়ম, ডেটা অবস্থান চাহিদা, এবং ইন্ডাস্ট্রি নির্দিষ্ট অনুশাসন। যদি কাস্টমার ডেটা কোনো নির্দিষ্ট দেশ বা অঞ্চলে থাকতে হবে, তা স্পষ্টভাবে লিখুন।\n\nএছাড়া কি কিছুকে বদলানো যাবে না তা রেকর্ড করা সুবিধাজনক। অনেক টিম নতুন অ্যাপ চায়, কিন্তু কিছু বিদ্যমান টুল বা ম্যানুয়াল ধাপ তারা রেখে দিতে বাধ্য থাকে। ফাইনান্স একই অ্যাকাউন্টিং সিস্টেম রাখতেই পারে। সাপোর্ট চাইতে পারে টিকিটগুলো বর্তমান হেল্পডেস্কে থেকেই যাবে। ঐ সীমাগুলোও নতুন ফিচারগুলোর মতোই গুরুত্বপূর্ণ।\n\nপ্রায়োগিক সীমাবদ্ধতা সংক্ষিপ্তভাবে রাখুন, যেমন:\n\n- নির্দিষ্ট লঞ্চ তারিখ\n- বাজেট ক্যাপ বা ব্যয় পরিসর\n- টিম সাইজ এবং উপলব্ধ রিভিউয়াররা\n- কাজে থাকতে হবে এমন টুলগুলো\n- আইনি, প্রাইভেসি, বা লোকেশন চাহিদা\n\nএই বিবরণগুলো প্রথম বিল্ডকে ভুল অনুমান থেকে রক্ষা করে। এগুলো বিল্ডারকে ভাল ট্রেড-অফ করতে সাহায্য করে।\n\n## প্রম্পটকে বাস্তব করা উদাহরণ দিয়ে দৃঢ় করুন\n\nউদাহরণ জেনেরিক নোটগুলোকে এমন কিছুতে পরিণত করে যা টিম আসলে তৈরি করতে পারে। "manage orders" বা "review leads" মতো বিস্তৃত বাক্যগুলো ইনপুট, প্রত্যাশিত আউটপুট, বা মানদণ্ড দেখায় না।\n\nএকটি সাম্প্রতিক কাজ থেকে একটি সাধারণ উদাহরণ দিয়ে শুরু করুন। এমন কিছু বাছুন যা সাধারণভাবে ঘটে, বিরল অ্যাজুকেস না। যদি টিম বলে তারা লিড কুয়ালিফাই করতে চায়, তাদেরকে একটি আসল লিড রেকর্ড দেখান, কী তথ্য এসেছিল, এবং রিভিউয়ের পরে ফলাফল কেমন হওয়া উচিত তা দেখান।\n\nএকটি দরকারী উদাহরণ সাধারণত চারটি জিনিস অন্তর্ভুক্ত করে:\n\n- নমুনা ইনপুট\n- অ্যাপকে করতে বলা ধাপ বা সিদ্ধান্ত\n- প্রত্যাশিত আউটপুট\n- কী বিষয়গুলো সেই আউটপুটকে পর্যাপ্ত করে তোলে\n\nতারপর একটি ঝামেলাযুক্ত কেস চান যা প্রায়ই ঘটে। সেখানে লুকানো নিয়ম বেরিয়ে আসে। হয়তো ফর্মে ফোন নম্বর নেই, হয়তো একই কাস্টমার দুইবার আছে, বা অনুরোধটি অস্পষ্ট। এখনই যদি আপনি সেটি ক্যাপচার করেন, প্রথম প্রম্পট বলবে অ্যাপটিকে তা ফ্ল্যাগ করতে হবে, স্কিপ করতে হবে, নাকি আরও তথ্য চাওয়া হবে।\n\nগুণমান সম্পর্কে নির্দিষ্ট থাকুন। "It should work" কোনো কার্যকর লক্ষ্য নয়। "It should group duplicates, keep the newest contact details, and mark low-confidence matches for review" হল এমন কিছু যা বিল্ডার কাজে লাগাতে পারেন।\n\nপ্রায়োগিকভাবে, দুইটি পেস্ট করা উদাহরণ প্রায়ই একটি লম্বা বিমূর্ত বর্ণনার চেয়ে বেশি সাহায্য করে। একটি পরিষ্কার কেস এবং একটি ঝামেলাযুক্ত কেস বিল্ডারের জন্য প্যাটার্ন দেয়।\n\n## প্রথম বিল্ডকে রক্ষা করতে না-করার লক্ষ্য নির্ধারণ করুন\n\nএকটি শক্তিশালী প্রথম প্রম্পটে স্পষ্ট সীমা থাকা দরকার। এগুলো না থাকলে ভার্সন ওয়ান অতিরিক্ত আইডিয়া দিয়ে ভরিয়ে উঠতে পারে এবং ফলটি এলোমেলো, ধীর, বা লক্ষ্যহীন হয়ে পড়ে।\n\nউন্নয়নের প্রাথমিক পর্যায়ে প্রোডাক্টটি কী করবে না তা লিখে রাখুন। এটি মূল ওয়ার্কফ্লো রক্ষা করে যা আপনি প্রমাণ করতে চান।\n\nনাইস-টু-হ্যাভ আইডিয়াগুলো সাধারণত সহজে চিনহিত করা যায়। এগুলো কার্যকর মনে হলেও প্রথমে প্রয়োজনীয় নয়। কাস্টম ড্যাশবোর্ড, উন্নত রোল, গভীর রিপোর্টিং, বা পরিপাটি নোটিফিকেশনগুলো পরে দরকার হতে পারে। এগুলোকে ভার্সন ওয়ানের মেইন ফ্লোয়ের সাথে প্রতিযোগিতা করতে দেবেন না।\n\nকিছু প্রশ্ন সাহায্য করে:\n\n- প্রথম 1–2 সপ্তাহে ব্যবহারকারীরা কী ছাড়া থাকতে পারবে?\n- শুরুতে টিম কোনগুলো ম্যানুয়ালি হ্যান্ডেল করতে পারে?\n- কি ব্যবহারকারী কানে ভদ্রলোক মনে হলেও প্রধান আউটকামের সাথে জড়িত নয়?\n- কোন ইন্টিগ্রেশনগুলো কোর ফ্লো স্থিতিশীল না হওয়া পর্যন্ত অপেক্ষা করতে পারে?\n\nম্যানুয়াল কাজ প্রায়ই সঠিক অস্থায়ী পছন্দ। যদি লিডগুলো দিনে একবার ম্যানুয়ালি রিভিউ করা যায়, তখন অটো-রাউটিং এখনই লাগবে না। যদি ইনভয়েস এক্সপোর্ট করে হাতে পাঠানো যায়, পুরো বিলিং অটোমেশন পরে করা যেতে পারে। এটা ব্যর্থতা নয়—এটি ফোকাস।\n\nএকই কথার প্রয়োগ ইন্টিগ্রেশনগুলোর ক্ষেত্রে। টিমগুলো প্রায়ই পেমেন্ট টুল, ইমেল প্ল্যাটফর্ম, ক্যালেন্ডার সিঙ্ক, এবং CRM কানেকশনের জন্য অনুরোধ করে। যদি প্রথম বিল্ড একটি ওয়ার্কফ্লো ভ্যালিডেট করার উদ্দেশ্য রাখে, সংস্করণ ওয়ানে কোন সিস্টেমগুলো বাইরে থাকবে তা নোট করুন।\n\nউদাহরণস্বরূপ, একটি অভ্যন্তরীণ CRM কন্ট্যাক্ট ক্যাপচার, স্ট্যাটাস আপডেট, এবং একটি সাধারণ টাস্ক লিস্ট দিয়ে শুরু করতে পারে। নন-গোলস হতে পারে: মাল্টি-টিম পারমিশন, উন্নত অ্যানালিটিক্স, মোবাইল পুশ এলার্ট, এবং বাইরের টুলগুলোর লাইভ সিঙ্ক।\n\n"Version one-এ অন্তর্ভুক্ত নয়" বলা প্রায়ই যথেষ্ট। স্পষ্ট সীমা প্রথম বিল্ডটিকে দ্রুত শিপ ও টেস্ট করা সহজ করে।\n\n## একটি সহজ ধাপে-ধাপে প্রম্পট টেমপ্লেট\n\nএকটি দরকারী প্রম্পট ছোট একটি ব্রিফের মতো পড়া উচিৎ, নকল নোটগুলোর গাদা মতো নয়। প্রতিবার একই স্ট্রাকচার ব্যবহার করলে হ্যান্ডঅফ অনেক সহজ হবে।\n\n1. এক লাইনের প্রোডাক্ট সারসংক্ষেপ দিয়ে শুরু করুন। এটা কি, কার জন্য এবং প্রধান ফলাফল কী হবে তা বলুন।\n2. অভিনেতাদের নাম দিন। যারা এটি ব্যবহার করবেন তাদের তালিকাভুক্ত করুন।\n3. মূল টাস্কগুলি বর্ণনা করুন। ভার্সন ওয়ানে সবচেয়ে গুরুত্বপূর্ণ কিধরকার কাজগুলোর ওপর গুরুত্ব দিন।\n4. সীমাবদ্ধতা ও উদাহরণ যোগ করুন। নিয়ম, সীমা, ডেটা চাহিদা, এবং এক বা দুইটি বাস্তব কেস অন্তর্ভুক্ত করুন।\n5. সফলতার মানদণ্ড দিয়ে শেষ করুন। প্রথম ভার্সনটি কি পর্যাপ্তভাবে করতে হবে যেন তা ব্যবহারযোগ্য?\n\nভাষাটা সাধারণ ও নির্দিষ্ট রাখুন। "manage projects better" লিখবেন না যদি আসলে বোঝাতে চান "টিম লিডরা একটি প্রজেক্ট তৈরি করতে পারেন, টাস্ক অ্যাসাইন করতে পারেন, এবং কাজ সম্পন্ন হিসেবে চিহ্নিত করতে পারেন।"\n\nসরল বাক্যই সবচেয়ে কার্যকর। উদাহরণ: "একটি ছোট সেলস টিমের জন্য একটি ছোট CRM বানান। অভিনেতারা: সেলস রিপস ও একটি ম্যানেজার। টাস্ক: লিড যোগ, ডিল স্টেজ আপডেট, এবং ফলো-আপ দেখা। সীমাবদ্ধতা: মোবাইল-ফ্রেন্ডলি, সহজ ড্যাশবোর্ড, CSV এক্সপোর্ট। উদাহরণ: একজন রিপ ৩০ সেকেন্ডের মধ্যে একটি কল লগ করতে পারবে। সফলতা: টিম স্প্রেডশিট ছাড়া সক্রিয় ডিল ট্র্যাক করতে পারে।"\n\nএটুকুই একজন বিল্ডারকে একটি স্পষ্ট শুরু দেবে পুরো প্রোডাক্ট বর্ণনা দেওয়ার চেষ্টা না করে।\n\n## উদাহরণ: একটি কলকে এক ব্যবহারযোগ্য প্রম্পটে পরিণত করা\n\nভাবুন একটি ছোট সার্ভিস ব্যবসা, যেমন একটি লোকাল ক্লিনিং কোম্পানি। কলটিতে মালিক বলেন, "Customers need to book online, pay easily, and my staff need a simple way to manage appointments." এটি কার্যকর, তবে এখনও প্রথম বিল্ডের জন্য খুবই আলোরহীন।\n\nএকটি বিল্ড-রেডি ভার্সন সেই কথোপকথনটিকে এমন কিছুতে রূপান্তর করে যা সরাসরি ব্যবহার করা যাবে:\n\n\n\nএটি কাজ করে কারণ এটি অভিনেতাদের স্পষ্টভাবে নাম করে এবং অস্পষ্ট অনুরোধগুলোকে বাস্তব টাস্কে পরিণত করে। সীমাবদ্ধতাগুলোও ততটাই গুরুত্বপূর্ণ। সীমিত সময়ের কারণে সিস্টেম অসম্ভব সময় স্লট দেখানো থেকে বিরত থাকে। রিফান্ড নিয়মগুলো পরে বিভ্রান্তি রোধ করে। মোবাইল ব্যবহারের গুরুত্ব শুরু থেকেই লেআউট নির্ধারণ করে।\n\nনন-গোলগুলো বিল্ডকে রক্ষা করে। এগুলো না থাকলে একটি সহজ বুকিং অ্যাপ দ্রুত অনেক বড় প্রকল্পে পরিণত হতে পারে।\n\n## সাধারণ ভুলসমূহ যা প্রথম ভার্সনকে দুর্বল করে\n\nএকটি দুর্বল প্রথম ভার্সন প্রায়ই ব্যর্থ হয় কারণ টিম সেটি তৈরি করতে পারে না—বরং কারণ প্রম্পটটা খুবই ঝাপসা ছিল।\n\nএকটি সাধারণ ভুল হলো ফিচার আইডিয়াগুলোকে ব্যবসায়িক নিয়মের সাথে মিশিয়ে দেওয়া। একজন প্রতিষ্ঠাতা বলতে পারেন, "We need a dashboard, filters, and alerts," কিন্তু আসল নিয়ম হতে পারে "Only managers can approve refunds above a set amount." যদি সেই নিয়মটি ইচ্ছে-মালার ভেতরে পুতে থাকলে, প্রথম বিল্ড যত সুন্দরই হোক ভুল হতে পারে।\n\nআরেকটি সমস্যা হলো কেবল প্রতিষ্ঠাতার দৃষ্টিকোণ থেকে লেখা। প্রতিষ্ঠাতা প্রায়ই যা দেখতে চান তা বর্ণনা করেন, সব ব্যবহারকারীর দরকারি কাজ নয়। সেলস রিপ, অপারেশনস ম্যানেজার, এবং সাপোর্ট এজেন্ট প্রত্যেকে আলাদা ভাবে অ্যাপ ব্যবহার করে। যদি প্রম্পট শুধু লিডারদের লক্ষ্য প্রতিফলিত করে, দৈনন্দিন কাজগুলো চ্যুত হয়ে যায়।\n\nসবচেয়ে সাধারণ ভুলগুলো হল:\n\n- আইডিয়া, নিয়ম, এবং অনুমানগুলোকে একই জিনিস মনে করা\n- অ্যাপকে এক ব্যক্তির জন্য বর্ণনা করা পরিবর্তে সব গুরুত্বপূর্ণ ইউজার সারিবদ্ধ করা ছাড়া\n- আড়চোখের কেসগুলো (পার্শিয়াল পেমেন্ট, দেরি অনুমোদন, বা ডুপ্লিকেট রেকর্ড) এড়িয়ে যাওয়া\n- অনুমোদন ধাপগুলো অস্পষ্ট রাখা: কোনো ট্রিগার আছে, কোন মালিক আছে, বা ডেডলাইন কি না\n- পুরো রোডম্যাপকে ভার্সন ওয়ানে ঢুকিয়ে ফেলার চেষ্টা করা\n\n"Order approval" নিন উদাহরণ হিসাবে। শুনতে পরিষ্কার লাগলেও তা নয়। কে অনুমোদন করবে? অনুমোদনকারী অনুপস্থিত হলে কী হবে? কি প্রতিটি অর্ডারই অনুমোদন দরকার, নাকি নির্দিষ্ট থ্রেশহোল্ডের উপরে? এই বিশদগুলো বিল্ড বদলায়।\n\nযখন টিমগুলো দ্রুত অ্যাপ-নির্মাণ টুল ব্যবহার করে, এই ফাঁকগুলো দ্রুত দেখা যায়। পরিষ্কৃত প্রম্পট আপনাকে এমন একটি প্রথম ভার্সন দেয় যা মানুষ পরীক্ষা করতে পারে, কেবল প্রতিক্রিয়া জানাতে নয়।\n\n## দ্রুত চেকলিস্ট বিল্ড শুরু করার আগে\n\nপ্রম্পটটি বিল্ডারে পাঠানোর আগে একটি দ্রুত রিভিউ করুন। এখানে দুর্বল নোটগুলো স্পষ্ট নির্দেশে পরিণত হয়।\n\n### প্রথমে কি নিশ্চিত করবেন\n\n- আপনি দ্রুত প্রতিটি ইউজারের টাইপ তালিকাভুক্ত করতে সক্ষম হওয়া উচিৎ।\n- প্রতিটি অভিনেতার ২–৫টি স্পষ্ট অ্যাকশন থাকা উচিৎ।\n- অনুমোদন ধাপ, প্রাইভেসি চাহিদা, মোবাইল ব্যবহার, বা প্রয়োজনীয় টুলগুলো লিক করুন।\n- একটি সাধারণ কেস এবং একটি এজ কেস যোগ করুন।\n- কি ভার্সন ওয়ান করবে না তা স্পষ্ট করুন।\n\nএকটি ছোট উদাহরণই পার্থক্য দেখায়। "Staff creates bookings" পাতলা। শক্তিশালী প্রম্পট বলে: স্টাফরা বুকিং তৈরি, সম্পাদনা, এবং বাতিল করতে পারবে; ম্যানেজার ব্যতিক্রম অনুমোদন করবে; ডাবল-বুকিং ব্লক করা থাকবে; এবং ভার্সন ওয়ানে ইনভয়সিং নেই।\n\nযদি এই অংশগুলো মিসিং থাকে, থামুন এবং ঠিক করুন। একটি সংক্ষিপ্ত, পূর্ণাঙ্গ প্রম্পট প্রায়ই অনেক দীর্ঘ কিন্তু ফাঁকা প্রম্পটকে হারায়।\n\n## স্মুথার প্রথম বিল্ডের জন্য পরবর্তী ধাপগুলো\n\nকল সম্পন্ন হলে নোটগুলো চ্যাট, ডকস, এবং মেমরিতে ছড়িয়ে রাখতে হবে না। সেগুলোকে একটি একক শেয়ার করা বিল্ড ব্রিফে রূপান্তর করুন যা কেউ কয়েক মিনিটে পড়তে পারে। সেই ব্রিফটি ব্যবহারকারী, মূল টাস্ক, নিয়ম, উদাহরণ, এবং নন-গোলগুলো সাধারণ ভাষায় ধারণ করবে।\n\nতারপর প্রথম ভার্সনের স্কোপে সাইন-অফ নিন। পুরো প্রোডাক্টের অনুমোদন নয়—শুধু কি ভার্সন ওয়ান করবে এবং কি করবে না সে নিয়ে সম্মতি। এটি ছোট পদক্ষেপ সাধারণ ভুলটিকে রোধ করে যেখানে একজন কলের জন্য ডেমো আশা করে এবং অন্যজন প্রায় শেষ পণ্যের আশা করে।\n\nএকটি ভাল প্রথম-ভার্সন স্কোপ চারটি প্রশ্নের উত্তর দেওয়া উচিৎ:\n\n- এইটি এখন কার জন্য?\n- ৩–৫টি কার্য যে প্রথমে কাজ করতে হবে কি কি?\n- কোন সীমাবদ্ধতা ভাঙা যাবে না?\n- এই রাউন্ডে কি জোর করে বাইরে রাখা হয়েছে?\n\nকিছু জেনারেট করার আগে প্ল্যানিং পাস চালান। কাঁচা নোটগুলোকে একটি ব্যবহারযোগ্য বিল্ড প্রম্পটে পরিণত করুন, অনুপস্থিত বিবরণ খুঁজে বের করুন, এবং "simple," "fast," বা "user-friendly" মতো অস্পষ্ট শব্দগুলো সরিয়ে দিন। এই শব্দগুলো শোনতে ভাল লাগে, কিন্তু প্রকৃতপক্ষে বিল্ডারকে কী বানাতে হবে তা বলে না।\n\nউদাহরণস্বরূপ, "make client onboarding easy" লেখার বদলে লিখুন: "A new client can submit their business name, contact details, project type, and budget in one form, then receive a confirmation screen."\n\nআপনি যদি Koder.ai ব্যবহার করেন, সেই প্ল্যানিং ধাপটি planning mode-এ ভালভাবে ফিট করে। এটি টিমগুলোকে জেনারেশন শুরু করার আগে অ্যাপকে আকার দেওয়ার সাহায্য করে, এবং স্ন্যাপশটগুলো প্রম্পট পরিবর্তন টেস্ট করার সময় কাজ করা ভার্সন হারানো ছাড়াই তুলনা সহজ করে।\n\nলক্ষ্য প্রথম দিনেই নিখুঁত প্রম্পট নয়—এটি একটি শেয়ার করা, অনুমোদিত প্রম্পট যা প্রথম বিল্ডকে সঠিক দিশা দেয়। যখন ব্রিফটি স্পষ্ট হয়, প্রথম ভার্সন রিভিউ করা সহজ, উন্নত করা সহজ, এবং প্রকৃত ব্যবসায়িক চাহিদা মিস হওয়ার সম্ভাবনা অনেক কম থাকে।