চ্যাট-নির্মিত অ্যাপের এজেন্ট ভূমিকা: Planner থেকে Reviewer ওয়ার্কফ্লো

কেন চ্যাট দিয়ে অ্যাপ বানালে নির্ভরযোগ্যতা ভেঙে যায়

চ্যাট আপনাকে দ্রুত এগিয়ে নিয়ে যায়, কিন্তু এটা পুরো প্রোডাক্টকে মাথায় রেখে চলতে ভালো নয়। বেশিরভাগ ব্যর্থতা “খারাপ কোড” না হয়ে থাকে। এগুলো আসলে আপনার ইচ্ছে, সহকারী যা অনুমান করেছিল এবং প্রকৃতপক্ষে যা লঞ্চ হয়েছে—এই তিনটির মাঝে ফাঁক থেকেই হয়।

প্রথম ফাঁকটি হলো অনুপস্থিত রিকোয়ারমেন্ট। আপনি বলেন “একটি সাধারণ সাইনআপ ফ্লো করতে” তবে কেউ এজ কেসগুলো লিখে না—যেমন পাসওয়ার্ড রিসেট, ইমেল ইতিমধ্যে ব্যবহার হয়েছে কি না, অথবা ইউজার মাঝখানে ট্যাব বন্ধ করলে কী হবে। সহকারী ফাঁকগুলো পূরন করে দেয়, এবং সেই অনুমানগুলোই আপনার প্রোডাক্ট হয়ে যায়।

দ্বিতীয় ফাঁকটি হলো অসংগত সিদ্ধান্ত। একবার মেসেজে ডেটা মডেল নির্ধারিত হয়, পরের মেসেজে শর্টকাট যোগ হয়, আর তৃতীয় মেসেজে নামকরণ বা ভ্যালিডেশন বদলে যায়। প্রতিটি সিদ্ধান্ত নিজে-একা যৌক্তিক হতে পারে; একসাথে তারা একটি ভঙ্গুর অ্যাপ তৈরি করে যা পরবর্তীতে ফিচার যোগ করলে ভেঙে পড়ে।

তৃতীয় ফাঁকটি হলো প্রমাণের অভাব। বেসিক টেস্ট না থাকলে এবং স্পষ্ট অ্যাক্সেপ্ট্যান্স চেক না থাকলে আপনি কেবল ক্লিক করে দেখলেই সমস্যা খুঁজে পান। তখনই “আমার স্ক্রিনে কাজ করছে” রাতশেষে হটফিক্স ও র‌্যাগ্রেশন-এ পরিণত হয়।

একটি সহজ সমাধান হলো পুনরায় ব্যবহারযোগ্য পারসোনা ব্যবহার করা: Planner যে কাজটিকে স্পষ্ট করে, Architect যা আকার নির্ধারণ করে, Implementer ছোট ধাপে নির্মাণ করে, Tester ভাঙার চেষ্টা করে, এবং Reviewer শেষের 10% ধরে ধরে যা 90% ব্যথার কারণ হয় তা ধরেছে। এটা কোনো বড় প্রক্রিয়া নয়। এটা সিদ্ধান্তগুলিকে ধারাবাহিক রাখার একটি পুনরাবৃত্তি যোগ্য উপায়।

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

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

মূল ধারণা: দায়িত্ব আলাদা করুন, তারপর পরিষ্কার হ্যান্ডঅফ করুন

নির্ভরযোগ্যতা হারায় যখন একাই চ্যাট সবকিছু করতে চায়: কী বানাবেন সিদ্ধান্ত নেওয়া, ডিজাইন করা, কোড লেখা, টেস্ট করা এবং বিচার করা। ঐ কাজগুলো মিশ্রিত করলে এজ কেস মিস হয়ে যায়, বিল্ডের মাঝেই রিকোয়ারমেন্ট বদলে যায়, বা বাগ “ফিক্স” করার নাম করে আরও ঝামেলা এসে যায়।

প্রতিরোধের সহজ উপায় হলো ভূমিকা গুলো সঙ্কীর্ণ ও ধারাবাহিক রাখা। প্রতিটি ভূমিকা এক কাজের দায়িত্ব নেবে, এবং ঐ কাজের বাইরে “সহায়তা” করা যাবে না। এতে সিদ্ধান্ত ট্রেসযোগ্য হয় এবং ভুল ধরা সহজ হয়।

প্রায় যেকোন ফিচারের জন্য এই সিকোয়েন্স ব্যবহার করুন:

• Planner: লক্ষ্য, ইউজার, অ্যাক্সেপ্ট্যান্স চেক এবং আউট অফ স্কোপ নির্ধারণ করে
• Architect: সেই লক্ষ্য সমর্থন করার জন্য সবচেয়ে সরল ডিজাইন প্রস্তাব করে
• Implementer: ঠিক যা পরিকল্পনা করা হয়েছে সেটাই ছোট ধাপে নির্মাণ করে
• Tester: ভাঙতে চেষ্টা করে এবং ব্যর্থতা স্পষ্টভাবে রিপোর্ট করে
• Reviewer: শেষ মাইলের ডিটেইলগুলো চেক করে (নামকরণ, সিকিউরিটি বেসিক, UX শূন্যতা, ঝুঁকিপূর্ণ শর্টকাট)

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

উদ্দেশ্য নিয়ে লুপ ব্যাক করুন, দুর্ঘটনায় নয়। টেস্ট ফেল করলে Implementer-এ একটি মিনি বাগ রিপোর্ট নিয়ে ফিরে যান। ডিজাইন যদি নতুন রিকোয়ারমেন্ট সামলাতে না পারে, Architect-এ ফিরে যান। রিকোয়ারমেন্ট যদি অস্পষ্ট বা বারবার পরিবর্তিত হয়, Planner-এ ফিরে ধমকে বসুন।

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

Persona 1: Planner (কেউ বিল্ড করার আগে কাজ স্পষ্ট করুন)

Planner-এর কাজ বিস্তৃত আইডিয়াকে এমন কিছুতে পরিণত করা যেটা আপনি নির্মাণ ও যাচাই করতে পারেন। এটা “ডক লেখা” নয়। এটা প্রথম স্ক্রিন বা API এন্ডপয়েন্ট তৈরির আগে “ডান” কী তা সম্মত হওয়া।

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

Planner প্রম্পট টেমপ্লেট (ছোট, অগ্রাধিকারকৃত পরিকল্পনা)

Use this when you have a feature idea and want a tight plan the rest of the roles can follow.

You are the Planner. Turn the feature idea below into a buildable plan.

Feature idea:
<PASTE IDEA>

Context:
- App type:
- Target users:
- Current behavior (if any):
- Constraints (time, data, compliance, devices):

Output (keep it short):
1) Problem statement (1-2 sentences)
2) Assumptions (3-6 bullets)
3) Questions to confirm (max 6, prioritized)
4) User stories (2-5)
5) Acceptance criteria (5-10, testable, specific)
6) Edge cases & failure modes (3-8)
7) Out of scope (3-6 bullets)
8) Small milestone plan (2-4 steps, highest value first)

Planner to Architect handoff (structured and short)

Send this message as-is (filled in) to reduce back-and-forth.

PLANNER HANDOFF
Feature: <name>
Problem: <1-2 sentences>
Users: <who>
Must-haves (AC): <5-10 acceptance criteria>
Key edge cases: <3-6>
Out of scope: <3-6>
Open questions (need Architect input): <1-4>
Constraints: <tech, data, privacy, deadlines>
Success signal: <how we’ll know it worked>

Planner-এর কাজ করার ক্ষেত্রে একটাই গুরুত্বপূর্ণ কথা: অ্যাক্সেপ্ট্যান্স ক্রাইটেরিয়াগুলো মেপে নেওয়া যায় এমন হওয়া চাই। উদাহরণ: “User can reset password and receives an email within 60 seconds” এই ধরনের মাপযোগ্য বিবরণ “Password reset works.”-এর তুলনায় অনেক ভালো।

Persona 2: Architect (অ্যাপের এমন একটি আকার বেছে নিন যা বাস্তবে টেকসই)

Architect একটি ভালো প্ল্যানকে একটি নির্মাণযোগ্য আকারে রূপান্তর করে। কাজটি ফ্যান্সি প্যাটার্ন খোঁজা নয়; বরং সবচেয়ে সরল স্ট্রাকচার বেছে নেওয়া যাতে বাস্তবে ইউজার ক্লিক করলে, ডেটা বাড়লে এবং এরর ঘটলে এটি টিকে থাকে।

এখানেই নির্ভরযোগ্যতা বাস্তবে অনুভূত হয়: স্পষ্ট বর্ডার, স্পষ্ট ডেটা, এবং স্পষ্ট ফেলিওর পাথ।

প্রায়োগিক Architect আউটপুট সাধারণত কভার করে:

• Screens (React or Flutter) বা API endpoints (Go)
• একটি ছোট ডেটা মডেল (PostgreSQL টেবিল ও কী ফিল্ড)
• ১-২টি কোর ফ্লো (হ্যাপি পাথ + কী ভুল হতে পারে)
• নন-ফাংশনাল বেসিক যা এখনই গুরুত্বপূর্ণ (auth, privacy, performance, logging)
• ট্রেডঅফ (এগুলো এখনই বানানো হচ্ছে না)

কংক্রিট রাখুন। “notifications system” বলার বদলে বলুন “POST /api/alerts, table alerts(user_id, type, status), show unread count in header।” “secure” বললে বলুন “JWT session, role checks on admin endpoints, protect PII fields.”

Prompt template: Architect handoff (forces tradeoffs)

Use this when the Planner hands work to the Architect, or when you want to reset a feature that feels messy.

You are the Architect.
Goal: design the simplest buildable structure for this feature.
Context:
- App type: [web/mobile/both]
- Stack: React UI, Go API, PostgreSQL DB (Flutter screens if mobile)
- Existing constraints: [auth method, existing tables, deadlines]

Input (from Planner):
- User story:
- Acceptance criteria:
- Out of scope:

Deliverables (keep it short and specific):
1) UI map: list screens/components with 1-line purpose each.
2) API map: list endpoints with method, path, request/response fields.
3) Data model: tables + key columns + relationships.
4) Key flows: happy path + 2 failure cases and how UI should respond.
5) Non-functional needs: security, performance, audit/logging (only what matters now).
6) Tradeoffs: 3 decisions you made (and what you avoided) to prevent over-design.

Rules:
- Prefer the smallest option that meets acceptance criteria.
- If something is unclear, ask up to 3 questions, otherwise make a reasonable assumption and write it down.

Koder.ai-এ কাজ করলে এই ধরনের হ্যান্ডঅফ Implementation-কে দ্রুত করে তোলে কারণ Implementer কে আর অনুমান করতে হয় না—তিনি একটি পরিষ্কার মানচিত্র পাবেন।

Persona 3: Implementer (ছোট ধাপে নির্মাণ করুন, স্কোপ টাইট রাখুন)

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

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

একজন ভালো Implementer একটি সংক্ষিপ্ত এভিডেন্স ট্রেল রেখে যায়: বিল্ড অর্ডার, কী পরিবর্তন হয়েছে, কী পরিবর্তন হয়নি (গোপন স্কোপ ক্রিপ এড়াতে), এবং কীভাবে যাচাই করবেন।

নিচে Implementer-কে হ্যান্ডঅফ দেওয়ার জন্য একটি প্রম্পট টেমপ্লেট দেওয়া হলো:

You are the Implementer.

Context:
- Feature: <name>
- Current behavior: <what happens today>
- Desired behavior: <what should happen>
- Acceptance criteria: <bullets>
- Constraints: <tech choices, performance, security, no schema change, etc.>

Before writing code:
1) Ask up to 5 questions if anything is unclear.
2) Propose a step-by-step build plan (max 6 steps). Each step must be reversible.
3) For each step, list the exact files/modules you expect to touch.

Then implement:
- Execute steps one by one.
- After each step, summarize what changed and how to verify.
- Do not add extras. If you notice a better idea, stop and ask first.

উদাহরণ: Planner যদি বলে “Add a password reset email flow,” Implementer-কে একই সময়ে লগইন স্ক্রিন রিডিজাইন করা শুরু করা উচিত না। প্রথমে ইমেল রিকোয়েস্ট এন্ডপয়েন্ট, তারপর টোকেন হ্যান্ডলিং, তারপর UI—প্রতিটি ধাপের পরে সংক্ষিপ্ত ভেরিফিকেশন নোট দিন। যদি টুল স্ন্যাপশট ও রোলব্যাক সাপোর্ট করে (Koder.ai করে), ছোট ধাপগুলো অনেকই নিরাপদ হয়।

Persona 4: Tester (কাজটাকে ভগ্নপ্রায় করে দেখান এবং কীভাবে ব্যর্থ হয় তা দেখান)

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

একজন ভালো Tester আউটপুট অন্য কেউ ব্যবহার করতে পারে: অ্যাক্সেপ্ট্যান্স ক্রাইটেরিয়া-র সাথে টেস্ট ম্যাট্রিক্স, একটি সংক্ষিপ্ত ম্যানুয়াল স্ক্রিপ্ট, এবং এক্স্যাক্ট স্টেপস সহ বাগ রিপোর্ট (একজন অন্য ব্যক্তিও রেপ্রোডিউস করতে পারবে)।

কী পরীক্ষা করবেন (UI, API, এবং ডেটা)

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

• UI: খালি স্টেট, এরর মেসেজ, লোডিং স্টেট, ডিসেবলড বাটন, কীবোর্ড-ওনলি ফ্লো
• API: মিসিং ফিল্ড, ভুল টাইপ, auth ব্যর্থতা, রেট/টাইমআউট আচরণ
• ডেটা ভ্যালিডেশন: ডুপ্লিকেট, ম্যাক্স লেন, অবৈধ ফরম্যাট, সার্ভার-সাইড চেক (শুধু UI নয়)
• পারমিশন: সাধারণ ইউজার বনাম অ্যাডমিন কী করতে পারে
• রিগ্রেশন: ১-২টা “আমরা কি এক্সিস্টিং আচরণ ভেঙে ফেলেছি?” চেক

উদাহরণ: যদি আপনি “Create invoice” যোগ করেন, নেগেটিভ অ্যামাউন্ট, 10,000 অক্ষরের নোট, মিসিং কাস্টমার, এবং ডাবল-সাবমিট ক্লিক পরীক্ষা করুন।

Prompt template: অ্যাক্সেপ্ট্যান্স ক্রাইটেরিয়ার থেকে টেস্ট ম্যাট্রিক্স জেনারেট করুন

Use this when handing off from Implementer to Tester. Paste the acceptance criteria and any relevant UI/API notes.

ROLE: Tester
GOAL: Produce a test matrix tied to acceptance criteria, including negative tests.
CONTEXT:
- Feature: <name>
- Acceptance criteria:
  1) <AC1>
  2) <AC2>
- Surfaces: UI screens: <list>; API endpoints: <list>; DB changes: <notes>
OUTPUT FORMAT:
1) Test matrix table with columns: AC, Test case, Steps, Expected result, Notes
2) Negative tests (at least 5) that try to break validation and permissions
3) Manual test script (10 minutes max) for a non-technical person
4) Bug ticket template entries for any failures you predict (Title, Steps, Expected, Actual, Severity)
CONSTRAINTS:
- Keep steps precise and reproducible.
- Include at least one test for loading/error states.

Persona 5: Reviewer (শেষের 10% ধরুন যা 90% সমস্যা সৃষ্টি করে)

Reviewer চূড়ান্ত কোয়ালিটি পাস। সবকিছু আবার লিখার জন্য নয়, বরং ছোট কিন্তু পরে বড় সমস্যা হওয়ার জিনিসগুলো খুঁজে বের করা: বিভ্রান্তিকর নামকরণ, অনুপস্থিত এজ কেস, দুর্বল এরর মেসেজ, এবং এমন শর্টকাট যা পরবর্তী পরিবর্তনকে কঠিন করে দেবে।

একজন ভালো Reviewer স্পষ্ট আউটপুট দেয়: কী চেক করা হয়েছে, কী পরিবর্তন অনিবার্য, কোনগুলো ঝুঁকিপূর্ণ কিন্তু গ্রহণযোগ্য, এবং কী সিদ্ধান্ত নেওয়া হয়েছে (তাই পরের সপ্তাহে পুনরায় বিতর্ক না হয়)।

Reviewer কী খোঁজে

এই পাসটি সংক্ষিপ্ত ও পুনরাবৃত্তিযোগ্য রাখুন। এমন জিনিসগুলোতে ফোকাস করুন যা সাধারণত নির্ভরযোগ্যতা ভাঙে:

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

স্ট্রাকচার্ড রিভিউ প্রম্পট (approve or changes requested)

Use this handoff when the Implementer says the feature is done:

You are the Reviewer. Do a final review for correctness, clarity, and maintainability.

Context
- Feature goal:
- User flows:
- Key files changed:
- Data model/migrations:

Review checklist
1) Correctness: does it meet the goal and handle edge cases?
2) Security basics: auth, validation, safe logging.
3) Errors: clear messages, consistent status codes.
4) Consistency: naming, patterns, UI text.
5) Maintainability: complexity, duplication, TODOs.

Output format
- Findings (bulleted): include file/function references and severity (high/medium/low)
- Requested changes (must-fix before merge)
- Risk notes (acceptable with reason)
- Decision log updates (what we decided and why)

Finish with exactly one:
APPROVE
CHANGES REQUESTED

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

হ্যান্ডঅফ টেমপ্লেট যা রিওয়ার্ক প্রতিরোধ করে

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

প্রতিবারই একটি কমন শিরোনাম ব্যবহার করুন, ছোট কাজের ক্ষেত্রেও:

• Context + Goal: এক প্যারায় আপনি কী ও কেন তৈরী করছেন।
• Inputs: স্ক্রিন, API নোট, ডেটা ফিল্ড, স্যাম্পল রেকর্ড, সম্পর্কিত কোড এলাকা।
• Constraints: টেক পছন্দ, ডেডলাইন, পারফরম্যান্স, সিকিউরিটি, রাখতে হবে এমন আচরণ।
• Definition of Done: মাপযোগ্য চেক (কী পাশ করতে হবে, কী থাকতে হবে)।
• Assumptions / Open questions / Decisions made: আপনি কী অনুমান করেছেন, কী অজানা এবং কী স্থির করেছেন।

নিচে Architect থেকে Implementer-এ একটি সিঙ্গেল হ্যান্ডঅফ উদাহরণ:

ROLE HANDOFF: Architect -> Implementer
Context: Add “Invite team member” to the admin area.
Goal: Admin can send an invite email; invited user can accept and set a password.
Inputs: Existing Users table; auth uses JWT; email provider already configured.
Constraints: Go backend + PostgreSQL; React UI; audit log required; no breaking auth changes.
Definition of Done:
- UI: invite modal + success state
- API: POST /invites, POST /invites/accept
- DB: invites table with expiry; audit event on create/accept
- Tests: happy path + expired invite + reused token
Assumptions: Email templates can reuse “reset password” styling.
Open questions: Should invites be single-use per email?
Decisions made: 72h expiry; tokens stored hashed.

ইচ্ছে করলে আপনার টেমপ্লেটগুলো যেখানে সবাই কপি করতে পারে সেখানে রাখুন। Koder.ai-এ যদি আপনি Planning Mode ব্যবহার করেন, তাহলে প্ল্যান লক করুন এবং ইমপ্লিমেন্টেশনের আগে স্ন্যাপশট নিন—রোলব্যাক সহজ হবে যদি স্কোপ বদলে যায়।

প্রতিটি ফিচারের জন্য অনুসরণযোগ্য স্টেপ-বাই-স্টেপ ওয়ার্কফ্লো

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

স্টোরি সমর্থন করার জন্য শুধুমাত্র ন্যূনতম আকার ডিজাইন করুন। লক্ষ্য পারফেক্ট সিস্টেম নয়—এটি একটি সরল প্ল্যান যাতে পরবর্তী ফিচার যোগ করলে ধ্বসে না পড়ে।

একটি ব্যবহারিক ফ্লো দেখায়:

1. Planner: ইউজার স্টোরি, এজ কেস, এবং অ্যাক্সেপ্ট্যান্স ক্রাইটেরিয়া নিশ্চিত করা (সাফল্য, ব্যর্থতা, এবং “ইউজার X করলে কী হবে”)।
2. Architect: সবচেয়ে ছোট ডেটা মডেল ও API সারফেস প্রস্তাব (টেবিল/ফিল্ড, এন্ডপয়েন্ট, auth রুল), সাথে কি না বানানো হচ্ছে সে সম্পর্কে একটি নোট।
3. Implementer: একটি পাতলা স্লাইস end-to-end (UI থেকে API পর্যন্ত DB) বানান যা অ্যাক্সেপ্ট্যান্স ক্রাইটেরিয়া পূরণ করে, এমনকি UI সাদামাটা হলেও।
4. Tester: একটি পুনরাবৃত্তি যোগ্য টেস্ট স্ক্রিপ্ট চালান, ব্যর্থতা ধাপে ধাপে লগ করুন, এবং অস্পষ্ট আচরণ নোট করুন।
5. Reviewer: সিকিউরিটি বেসিক ও প্রোডাক্ট পলিশের জন্য চুড়ান্ত পাস দিন, তারপর সিদ্ধান্তগুলো রেকর্ড করুন।

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

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

বাস্তবসম্মত উদাহরণ: একটি ফিচার আইডিয়া থেকে রিভিউড রিলিজ পর্যন্ত

ফিচার: একটি সাধারণ CRM স্ক্রিন যেখানে ইউজাররা কন্ট্যাক্ট যোগ করতে পারবে, ট্যাগ (যেমন “Lead” বা “Vendor”) লাগাতে পারবে, এবং নাম বা ট্যাগ দিয়ে সার্চ করতে পারবে। সীমাবদ্ধতা: 90 মিনিট সময়, এবং বিদ্যমান contacts টেবিল ব্যবহার করতে হবে (ব্রেকিং মাইগ্রেশন নয়)। মোবাইলের জন্য একটি এক-পেজ “Add Contact” স্ক্রীন লাগবে।

নিচে পারসোনা চেইন ব্যবহার করে হ্যান্ডঅফ কেমন দেখায়—প্রতিটি ভূমিকা একটি ছোট আর্টিফ্যাক্ট দেয় যা পরবর্তী ব্যক্তি বিশ্বাস করে ব্যবহার করতে পারে।

Planner output (definition + acceptance)
- Goal: Add contacts with tags and fast search.
- Must: Create, edit, list contacts; add/remove tags.
- Search: matches name OR any tag; results update in under 300ms.
- Constraint: keep existing contacts table; tags can be new table.
- Done when: 5 test cases pass; mobile screen has no scroll on common devices.

Architect output (shape + data)
- Tables: contacts (existing), tags (id, name), contact_tags (contact_id, tag_id).
- API: POST /contacts, PATCH /contacts/:id, GET /contacts?query=.
- Search: SQL ILIKE on contact name + join on tags.
- UI: Contact list with search bar; contact form with tag picker.
- Risk: duplicate tags (“lead” vs “Lead”) - enforce lowercase unique.

Implementer output (small steps)
- Step 1: Add tags + join table migrations.
- Step 2: Update backend handlers and query.
- Step 3: Build React UI list + form; wire to API.
- Step 4: Add basic validation (name required, tag length).
- Step 5: Add loading/error states; keep UI responsive.

Tester output (proof + failure)
- Case: search “lea” returns contacts tagged “lead”. FAIL: returns none.
- Case: adding tag “Lead” then “lead” should not create two tags. PASS.
- Case: empty name rejected. PASS.
- Bug note: backend search only checks contact name, not tags.

Loop-back (Planner update)
- Update acceptance: search must match tags via join; include a test for it.
- Add edge case: searching by tag should return even if name doesn’t match.

Reviewer output (last 10%)
- Check: query uses indexes; add index on tags.name and contact_tags.tag_id.
- Check: error messages are clear; avoid raw SQL errors.
- Check: mobile form spacing and tap targets.
- Confirm: snapshots/rollback point created before release.

সেই একটিকেই ফেল করা টেস্ট একটি পরিষ্কার লুপ-ব্যাক তৈরি করে: প্ল্যান তীক্ষ্ণ হয়ে যায়, Implementer একটি কোয়েরি বদলে দেয়, এবং Reviewer পারফরম্যান্স ও পলিশ ভেরিফাই করে রিলিজের আগে।

সাধারণ ফাঁদ (এবং সহজ সমাধান)

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

• Persona মিলেমিশে যায় (রিকোয়ারমেন্ট স্থির না থাকা অবস্থায় বিল্ডিং শুরু)। সমাধান: Planner আউটপুট লক করুন কোড লেখা শুরু করার আগে। টেমপ্লেট টুইক: “Implementer: Planner-এর Scope, Assumptions, এবং Acceptance Criteria না থাকলে কোড লিখবেন না। যদি মিসিং হয়, ম্যাক্স 3টি প্রশ্ন জিজ্ঞাসা করুন।”
• Definition of Done নেই, তাই কাজ কখনই শেষ হয় না। সমাধান: প্রতিটি হ্যান্ডঅফে একটি Done লাইন বাধ্যতামূলক করুন। উদাহরণ: “Done means: acceptance criteria met, no new TODOs, and changes documented in 5 bullets.”
• Tester শুধু হ্যাপি পথ চেক করে। সমাধান: প্রতিবার একটি invalid-input এবং একটি এজ কেস দরকারি করুন। টেমপ্লেট টুইক: “Tester: provide (1) happy path, (2) one invalid input case, (3) one edge case. If you can’t run it, describe exact steps and expected output.”
• Reviewer স্টাইল নিয়ে তর্ক করে বদলে প্রোডাক্ট রিস্ক ফোকাস করে না। সমাধান: Reviewer-কে প্রথমে রিস্কে ফোকাস করাবেন। টেমপ্লেট টুইক: “Reviewer: list the top 3 risks (security, data loss, broken UX, performance). Mention style only if it blocks readability or causes bugs.”
• হ্যান্ডঅফে কনটেক্সট মিসিং, তাই পরের ভূমিকাটি অনুমান করে শুরু করে। সমাধান: প্রতিবার ছোট Handoff Block বাধ্যতামূলক করুন: “Goal, What changed, How to verify, Known gaps.” 8 লাইন এর মধ্যে রাখুন।

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

দ্রুত চেকলিস্ট নির্ভরযোগ্য চ্যাট-বিল্ট রিলিজের জন্য

বিল্ড করার আগে, মার্জ করার আগে এবং শিপ করার পরে এই চেকলিস্ট চালান।

Pre-build (কেউ কোড লিখার আগে)

• একটি বাক্যে লক্ষ্য লিখুন এবং 2-3টি অ্যাক্সেপ্ট্যান্স চেক তালিকাভুক্ত করুন (কীভাবে “ডান” দেখবে)।
• কী আউট অফ স্কোপ সেট করুন (তাতে Implementer অনুমান করবে না)।
• সঠিক ডেটা ফিল্ড ও নিয়ম তালিকা করুন (টাইপ, required/optional, ডিফল্ট)।
• প্রধান এরর কেসগুলো নোট করুন (খারাপ ইনপুট, মিসিং পারমিশন, খালি স্টেট, টাইমআউট)।
• দ্রুত যাচাই করার উপায় ঠিক করুন (একটি স্ক্রিন, API রেসপন্স, বা একটি লগ লাইন)।

একটি ছোট উদাহরণ: “Add invite-by-email.” ফিল্ডগুলো (email, role), ইমেল অবৈধ হলে কী হয়, এবং পুনরায় আমন্ত্রণ দেওয়া যাবে কি না—এসব স্পষ্ট রাখুন।

Pre-merge এবং Post-release (পরিবর্তনের ভয় কমান)

• Pre-merge: নিশ্চিত করুন টেস্ট চালানো হয়েছে (অথবা একটি ছোট ম্যানুয়াল স্ক্রিপ্ট) এবং কী চেক করা হয়েছে তা রেকর্ড করুন।
• Pre-merge: স্পষ্টভাবে 2-3 টা এজ কেস কভার করুন, “should work” নয়।
• Pre-merge: একটি রোলব্যাক প্ল্যান ও কী পরিবর্তন হলে রোলব্যাক ট্রিগার হবে তা নোট করুন।
• Post-release: প্রথমে 1-2 সিগনাল (এরর, স্লো পেজ, ব্যর্থ জব) পর্যবেক্ষণ করুন প্রথম এক ঘন্টা/এক দিন।
• Post-release: ইউজার ফিডব্যাক সংগ্রহ করুন এবং জানা সীমাবদ্ধতাগুলো লিখে রাখুন যাতে সাপোর্ট গাইডলাইন পেয়ে যায়।

আপনার প্ল্যাটফর্ম যদি সাপোর্ট করে (Koder.ai করে), ঝুঁকিপূর্ণ এডিটের আগে স্ন্যাপশট নিন। জানলে রোলব্যাক করা সহজ হলে ছোট, নিরাপদ পরিবর্তন শিপ করা সহজ হয়।

পরবর্তী পদক্ষেপ: এটিকে আপনার ডিফল্ট ওয়ার্কফ্লো বানান

একটি ছোট ফিচার তুলে নিন এবং পুরো পারসোনা চেইন একবার চালান। কিছু বাস্তব কিন্তু সংহত বাছুন—যেমন “add password reset,” “create an admin-only page,” অথবা “export invoices to CSV.” উদ্দেশ্য হলো Planner থেকে Reviewer পর্যন্ত পরিষ্কার হ্যান্ডঅফ চাপলে কী পরিবর্তন হয় তা দেখা।

আপনি Koder.ai ব্যবহার করলে (koder.ai), Planning Mode হলো স্কোপ ও অ্যাক্সেপ্ট্যান্স চেক লক করার বাস্তব জায়গা। তারপর স্ন্যাপশট ও রোলব্যাক আপনাকে নিরাপদ পালস দেয় যখন কোনো সিদ্ধান্ত ভুল প্রমাণিত হয়—বাকি প্রজেক্টকে বিতর্কে না ফেলে।

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