পুনরায় কাজ এড়াতে অ্যাপ স্পেসে বাধ্যবাধকতা ও না-লক্ষ্য

কেন স্পেকগুলো যখন কনস্ট্রেইন্ট বাদ দেয় তখন রিওয়ার্ক হয়

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

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

ক্যান্সেল করা কনস্ট্রেইন্টগুলো পরে আচমকাই সিদ্ধান্ত তৈরি করে। যখন একটা স্পেকে লেখা থাকে "একটি CRM তৈরি করুন," সেটা ডজনখানেক প্রশ্ন খোলা রেখে দেয়: কে এটি ব্যবহার করবে, কোন প্ল্যাটফর্মগুলো গুরুত্বপূর্ণ, কোন সিকিউরিটি নিয়ম প্রযোজ্য, কি কি স্কোপ থেকে রাখা হবে, বাস্তব বাজেট ও সময়সীমা কী। যদি উত্তরগুলো কোড তৈরি হওয়ার পরে আসে, প্রজেক্ট দ্বিগুণ খরচ ওঠে: একবার বানাতে, আরেকবার উল্টে ফেলতে।

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

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

এটি দীর্ঘ ডকুমেন্ট লেখার ব্যাপার নয়। একটি হালকা স্পেকও যেখানে প্রয়োজন সেখানে কঠোর হতে পারে। শুরুতেই এটা উত্তর দেওয়া উচিত:

• কি জিনিস ফিক্স (ডেডলাইন, বাজেট, টিম, রিভিউ কেডেন্স)?
• কি টেকনিক্যালভাবে ফিক্স (স্ট্যাক, হোস্টিং, ডেটা অবস্থান)?
• অ্যাপ কী করব না (নন-গোলস)?
• কি পরিবর্তন হতে পারে আবার পুরো পরিকল্পনা খুলতে না?

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

কনস্ট্রেইন্ট বনাম নন-গোল: এক মিনিটের মধ্যে পার্থক্য

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

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

একটি দ্রুত নিয়ম: কনস্ট্রেইন্টগুলো কিভাবে বানাবেন তা সীমাবদ্ধ করে; নন-গোলস কি বানাবেন না তা সীমাবদ্ধ করে।

কী গুলো কনস্ট্রেইন্ট হিসেবে গোনা হবে

কনস্ট্রেইন্ট হলো এমন একটি অবশ্য যা প্রকৃত সিদ্ধান্ত (এবং ট্রেড-অফ) ছাড়া বদলায় না।

উদাহরণ:

• “আমাদের ৬ সপ্তাহে লঞ্চ করতে হবে।”
• “বাজেট $15k-এ সীমাবদ্ধ।”
• “ডেটা রেসিডেন্সির জন্য EU-তেই চালাতে হবে।”
• “Frontend হবে React, backend হবে Go, ডাটাবেস হবে PostgreSQL।”

যখন একটি কনস্ট্রেইন্ট বাস্তব, এটাকে এমন এক বাক্য হিসেবে লিখুন যাকে নিয়ে বিতর্ক করা যায় না। যদি কেউ বলে “হয়ত,” তাহলে এটা এখনও কনস্ট্রেইন্ট নয়।

কী গুলো নন-গোলস হিসেবে গোনা হবে

নন-গোল হলো স্পষ্ট “আমরা এটা করছি না,” এমনকি যদি এটি কার্যকর মনে হয়। এটি প্রথম রিলিজকে রক্ষা করে।

উদাহরণ:

• “v1-এ মোবাইল অ্যাপ বানানো হবে না; এটা ওয়েব-অনলি।”
• “লঞ্চে মাল্টি-ল্যাঙ্গুয়েজ সাপোর্ট নেই।”
• “রিয়েল-টাইম চ্যাট নেই; ইমেল নোটিফিকেশন যথেষ্ট।”

নন-গোলস নেগেটিভিটি নয়। এগুলো ব্যয়বহুল ভ্রমণগুলোর থেকে রক্ষা করে। উদাহরণস্বরূপ, “v1-এ কাস্টম রোল নেই” লাইনে ডাটাবেস ও UI পুনর্গঠনের সপ্তাহগুলো বাঁচাতে পারে।

একটি ওয়ান-লাইনার ও ছোট সাফল্য সংজ্ঞা দিয়ে শুরু করুন

বিস্তারিত পাতার আগে একটি বাক্য লিখুন যা প্রজেক্টকে ফিক্স করে রাখে। এটি ট্রেড-অফের সময় সবার এলাইনমেন্ট রাখে।

একটি ভালো ওয়ান-লাইনার উত্তর দেয়: এটা কার জন্য, এবং মূল কাজ কী?

উদাহরণ ওয়ান-লাইনার:

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

এরপর একটি ছোট সাফল্য সংজ্ঞা যোগ করুন: ৩ থেকে ৫টি আউটকাম যা একটি বাস্তব ব্যবহারকারী প্রকল্প শেষ হলে অর্জন করতে পারবে। এগুলো ফিচারের বদলে ব্যবহারকারীর ফলাফল হিসেবে লিখুন।

টিউটর বুকিং উদাহরণের জন্য:

• একজন টিউটর কয়েক মিনিটে সাপ্তাহিক সময় সেট করতে পারে।
• একজন ছাত্র কল বা ইমেল না করেই সেশন বুক করতে পারে।
• উভয় পক্ষই একটি কনফার্মেশন ও একটি রিমাইন্ডার পায়।
• টিউটর ফোন ও ল্যাপটপে স্পষ্ট দৈনিক সূচি দেখতে পায়।

যদি আপনার কাছে এখনও মেট্রিক্স না থাকে, শব্দে সাফল্য বর্ণনা করুন। “দ্রুত” অস্পষ্ট, কিন্তু “ফোনে দ্রুত মনে হবে” উপকারী। “সহজ” অস্পষ্ট, কিন্তু “কোনো সেটআপ কল লাগবে না” স্পষ্ট। পরে আপনি সংখ্যা যোগ করতে পারেন।

এই অংশ ছোট রাখুন। এটি পরবর্তী সব কিছুর প্রেক্ষাপট হবে: কি অবশ্যই সত্য হতে হবে, কি করা যাবে না, এবং কি পরিবর্তন হতে পারে।

স্থির প্রজেক্ট কনস্ট্রেইন্ট লিখুন (সময়, বাজেট, মানুষ)

রিওয়ার্ক প্রায়ই তখন শুরু হয় যখন সময়সূচি ও সিদ্ধান্ত প্রক্রিয়া কেবল কারও মাথায় থাকে। স্পেকের শিরোনামে প্রজেক্ট কনস্ট্রেইন্টগুলো রাখুন, তারপর স্ক্রীন ও ফিচারের বর্ননা দিন।

তারা প্লেইন, টেস্ট করা যায় এমন বর্ণনায় লিখুন:

• ডেডলাইন ও মাইলস্টোন: লঞ্চ তারিখ ও ২–৩টি চেকপয়েন্ট (স্পেক সাইন-অফ, প্রোটোটাইপ অ্যাপ্রুভাল, প্রথম রিলিজ রেডি)। প্রথম রিলিজে কি অন্তর্ভুক্ত তা উল্লেখ করুন।
• বাজেট: এটা হার্ড কেপ নাকি টার্গেট রেঞ্জ। কি অন্তর্ভুক্ত (বিল্ড সময়, ডিজাইন, টেস্টিং, হোস্টিং, সাপোর্ট) তা বলুন যাতে পরে তা নিয়ে বিতর্ক না হয়।
• মানুষ ও সময় উপলব্ধ: কে রিভিউ করে এবং তারা কত দ্রুত সাড়া দেয়। ধীর ফিডব্যাকই একটি প্রকৃত কনস্ট্রেইন্ট।
• সিদ্ধান্ত মালিক: ট্রেড-অফ উঠলে কে হ্যাঁ বা না বলতে পারে।

একটি সহজ উদাহরণ:

“প্রথম রিলিজ ৩০ মে-র মধ্যে শিপ করতে হবে। এতে লগইন, একটি বেসিক কাস্টমার লিস্ট, এবং এক মাসিক রিপোর্ট অন্তর্ভুক্ত। v1-এ কোনো ইন্টিগ্রেশন নেই। বাজেট $8,000 কেপ, প্রথম মাসের হোস্টিং সহ। রিভিউ সপ্তাহের কার্যদিবসে ২৪ ঘণ্টার মধ্যে হবে। প্রডাক্ট ওনার সম — Sam — যিনি স্কোপ পরিবর্তন অনুমোদন করেন।”

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

বাস্তবতার সাথে মিলে এমন রিভিউ কেডেন্স বেছে নিন: একই দিন ফিডব্যাক, কার্যদিবসে ২৪–৪৮ ঘণ্টা, সাপ্তাহিক রিভিউ মিটিং, বা (দুর্লভভাবে) “কোনো ফিডব্যাক প্রয়োজন নেই।”

স্থির টেকনিক্যাল কনস্ট্রেইন্ট লিখুন (স্ট্যাক ও হোস্টিং)

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

শুরুতে কি লক করা হয়েছে এবং কি কেবল পছন্দ সেটা বলুন। “React পছন্দ” আর “React হওয়া আবশ্যক কারণ ইন-হাউস কম্পোনেন্ট লাইব্রেরি নির্ভর” এক নয়। এক সিদ্ধান্তের প্রতিটি আলাদা লাইন যথেষ্ট।

স্ট্যাক লক করুন (শুধুমাত্র যা সত্যিই বদলানো যাবে না)

ওয়েব, ব্যাকএন্ড, ডাটাবেস এবং মোবাইল জুড়ে স্পষ্ট হোন। যদি কোনো অংশ নমনীয় হয়, তা বলুন এবং একটি সীমা যোগ করুন (উদাহরণ: “v1-এ মোবাইল ওয়েব-অনলি”)।

লিখবার সহজ উপায়:

• Web/UI: X ব্যবহার করতে হবে (কারণ), বা X/Y ব্যবহার করা যেতে পারে (উপসংহারকারী)
• Backend: X হতে হবে (কারণ) এবং নির্দিষ্ট স্টাইল API এক্সপোজ করবে (REST বা GraphQL)
• Database: X হতে হবে, এবং মাল্টি-টেন্যান্সি এখন প্রয়োজন কি না
• Mobile: নেটিভ/Flutter হতে হবে, অথবা “v1-এ নেই”
• Dev ও ডেলিভারি: সোর্স কোড এক্সপোর্ট দরকার কি না, এবং দরকারি এনভায়রনমেন্ট (dev/stage/prod)

তারপর আপনি যে ইন্টিগ্রেশনগুলো এড়ানো যাবে না সেগুলো তালিকাভুক্ত করুন। সিস্টেমগুলোর নাম দিন (পেমেন্ট, ইমেল, অ্যানালিটিক্স, CRM) ও কঠোর সীমা উল্লেখ করুন। উদাহরণ: “বিলিংয়ের জন্য Stripe ব্যবহার করতে হবে,” “ইমেল পাঠাতে আমাদের বিদ্যমান প্রোভাইডার ব্যবহার করতে হবে,” “অ্যানালিটিক্স পার্সোনাল ডেটা ট্র্যাক করবে না।” যদি অথেনটিকেশন ঠিক থাকে (SSO, Google লগইন, পাসওয়ার্ডলেস), তা উল্লেখ করুন।

হোস্টিং, রিজিয়ন, ও ডেটা নিয়ম (সাদামাঠা ভাষায়)

হোস্টিং পছন্দ আর্কিটেকচার বদলে দেয়। বলুন অ্যাপ কোথায় চালাতে হবে এবং কেন: “জার্মানিতে চালাতে হবে,” “ডেটা EU-তেই থাকতে হবে,” অথবা “গ্লোবালি চলতে পারবে।”

যদি কমপ্লায়েন্স প্রয়োজন থাকে, সেগুলো konkreৎ রাখুন: রিটেনশন পিরিয়ড, ডিলিশন রুল, এবং অডিটের চাহিদা।

উদাহরণ: “রেকর্ড ৭ বছর সংরক্ষণ, যাচাইকৃত অনুরোধ পেলে ৩০ দিনের মধ্যে মুছে ফেলতে হবে, কোন রেকর্ড কে দেখেছে তার অডিট লগ রাখতে হবে, এবং যেখানে রোগী থাকে সেই দেশে ডিপ্লয় করা হবে।” এই লাইনগুলো লঞ্চের সময় আচমকা সারপ্রাইজ ঠেকায়।

স্কোপ রক্ষা করতে নন-গোলস যোগ করুন

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

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

প্রথম রিলিজে আপনি কী বানাবেন না

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

• v1-এ কোনো অ্যাডমিন পোর্টাল নেই (কেবল বেসিক স্টাফ টুল)
• লঞ্চে মাল্টি-ল্যাঙ্গুয়েজ বা লোকালাইজেশন নেই
• অফলাইন মোড বা সিঙ্ক নেই
• জটিল ড্যাশবোর্ড নয় (শুধু একটি সহজ সাপ্তাহিক সারসংক্ষেপ)
• v1-এ কোনো ইন্টিগ্রেশন নেই (পেমেন্ট, ক্যালেন্ডার, ইমেল টুল)

এগুলো খারাপ ফিচার নয়—এগুলো ব্যয়বহুল। এগুলো লিখে রাখলে প্রথম রিলিজ ফোকাসড থাকে।

এছাড়াও ধারাবিবরণি আইটেমগুলো বলুন যা বড় নক-অন কাজ করে: রোল, পারমিশন, এবং এজ-কেস ফ্লো। “কাস্টম রোল নেই; শুধু দুই রোল: Owner ও Member।” এই এক লাইনে সপ্তাহগুলো সেভ হবে।

আপনি কী অপ্টিমাইজ করবেন না বা সাপোর্ট করবেন না

টিমগুলো প্রায়ই নন-গোল ভুলে যায় যা ফিচার না হলেও পরে ব্যথার কারণ হয়। এগুলো পরে রিওয়ার্কে পরিণত হতে পারে।

নির্ধারণ করুন আপনি কী না অপ্টিমাইজ করবেন। উদাহরণ: “1M ব্যবহারকারীর জন্য টিউন করব না। v1-এ আমরা সর্বোচ্চ 500 সাপ্তাহিক অ্যাকটিভ ইউজার ধরে নেব।”

এছাড়া কি সাপোর্ট করা হবে না তা উল্লেখ করুন যাতে টেস্টিং বাস্তবসম্মত থাকে: “No Internet Explorer,” “No tablet-specific layouts,” অথবা “লগইন কেবল ইমেল ও পাসওয়ার্ড (না SSO, না ম্যাজিক লিঙ্ক)।”

কি পরিবর্তন হতে পারে আবার সব খুলে না দেয়ার শর্ত নির্ধারণ করুন

একটি স্পেক তখনই নিরাপদ মনে হয় যখন এটা ছোট সিদ্ধান্তগুলো ঢুকতে দেয়। যদি আপনি কেবল ফিক্সড জিনিসগুলো লিখেন, প্রতিটি নতুন আইডিয়া আবার বিতর্কে পরিণত হয়। একটি সংক্ষিপ্ত “পরিবর্তন হতে পারে” তালিকা লোকদের কাজ উন্নত করার সুযোগ দেয় ছাড়া পুরো পরিকল্পনা নতুন করে খোলার।

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

এরপর নির্ধারণ করুন কিভাবে পরিবর্তনগুলো গৃহীত হবে। একটি সহজ অনুমোদন নিয়ম না থাকলে “দ্রুত টুইক” গোপনে স্কোপ ক্রিপে পরিণত হয়ে যায়।

একটি সাধারণ ওয়ার্কফ্লো যা বেশিরভাগ ছোট টিমের জন্য কাজ করে:

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

মূল নিয়ম: নমনীয় পরিবর্তনগুলো ফিক্সড কনস্ট্রেইন্ট ভাঙতে পারবে না। যদি আপনার স্ট্যাক React + Go + PostgreSQL হয়, একটি “পরিবর্তন করা যাবে” অনুরোধ ব্যাকেন্ড বদলে দেওয়ার অনুরোধে পরিণত হতে পারবে না। যদি ডেডলাইন ফিক্সড হয়, “পরিবর্তন” মানে দুই সপ্তাহ লাগে এমন নতুন মডিউল যোগ করা নয়।

একটি ট্রেড-অফ নোট যোগ করুন সবাই একমত হবে এমন। উদাহরণ: “যদি আমরা একটি নতুন ইউজার রোল কাস্টম পারমিশনসহ যোগ করি, আমরা অ্যাডভান্সড রিপোর্টিং ফেজ ২-এ সরাব।”

আপনার স্পেক-এ কপি করে বসানোর ধাপে ধাপে ফরম্যাট

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

কপি/পেস্ট ফরম্যাট (খালি অংশ পূরণ করুন)

ডকের হেডারে এটা ব্যবহার করুন:

SPEC v0.1 (date)
Owner:
Reviewers:

1) One-liner
- Build: [what it is]
- For: [who]
- So they can: [main benefit]

2) Success definition (3 outcomes)
- Outcome 1: [measurable result]
- Outcome 2: [measurable result]
- Outcome 3: [measurable result]

3) Fixed constraints (cannot change without re-approval)
- Deadline: [date]
- Budget: [$ or hours]
- People: [who is available]
- Tech stack: [fixed choices]
- Hosting/region: [where it must run]

4) Non-goals (must NOT happen)
- [explicit “no”]
- [explicit “not in v1”]
- [explicit “we won’t support”]

5) Open questions
- Q: [question]
  Owner: [name]
  Due: [date]

6) Lock rule
- After review: changes require: [what approval looks like]

(উপরের কোড-ব্লক অনুবাদ করা হয়নি — এটি যেভাবে আছে সেভাবেই রেখে দেবেন।)

দ্রুত ৫-ধাপ ওয়ার্কফ্লো যাতে দ্রুত শেষ হয়

1. প্রথমে ওয়ান-লাইনার ও তিনটি আউটকাম লিখুন। যদি এইগুলো শেষ করতে না পারেন, আপনি ফিচার নিয়ে সিদ্ধান্ত নেবার জন্য প্রস্তুত নন।
2. পরের ধাপে স্থির কনস্ট্রেইন্ট ভরাট করুন: ডেডলাইন, বাজেট, টিম, স্ট্যাক, ও হোস্টিং রিজিয়ন।
3. গার্ডরেইল হিসেবে নন-গোলস যোগ করুন। “না” তালিকা লিখুন।
4. প্রতিটি ওপেন প্রশ্ন এক মালিকসহ তালিকাভুক্ত করুন।
5. ১৫ মিনিট রিভিউ করুন, তারপর ভার্সন লক করুন। তার পর থেকে পরিবর্তনগুলোকে নতুন অনুরোধ হিসেবে বিবেচনা করুন, সহজ সম্পাদনা নয়।

সাধারণ ফাঁকগুলো যা পরে সারপ্রাইজ দেয়

অধিকাংশ সারপ্রাইজ ভাগ্য নয়; সেটা ঘটে কারণ স্পেক বিভিন্ন ব্যাখ্যা করার জায়গা রাখে।

একটি সাধারণ ফাঁক হলো লক্ষ্য ও সমাধান মিশিয়ে ফেলা। টিমগুলো স্ক্রীন ও ওয়ার্কফ্লো থেকে সরাসরি শুরু করে দেয় যখন তারা ফিক্সড জিনিসগুলো (ডেডলাইন, বাজেট, টেক স্ট্যাক) আগে লিখে না। ফলাফল হলো একটি সুন্দর UI পরিকল্পনা যা কনস্ট্রেইন্টে ফিট করে না।

আরেকটি ফাঁক হলো অস্পষ্ট নন-গোলস। “কোনও অতিরিক্ত ফিচার নয়” কঠোর শোনালেও, যখন কেউ বলে “আরও একটি রিপোর্ট” বা “একটি দ্রুত অ্যাডমিন প্যানেল,” তখন তা রোধ করে না। ভালো নন-গোল স্পষ্ট ও টেস্টেবল হয়।

লুকানো বাজেট বা “সফট” ডেডলাইনও স্কোপ বোমা। যদি বাস্তব বাজেট $5k এবং স্পেকটি $50k পণ্য যেন দেখায়, টিম ভুল জিনিস বানাবে। অস্বস্তিকর সংখ্যাগুলো পৃষ্ঠায় রাখুন।

ইন্টিগ্রেশন ও ডেটা মালিকানাও নীরবে সারপ্রাইজ দেয়। আপনি যদি বলুন “Stripe-এ কানেক্ট করুন” কিন্তু কোন ইভেন্ট, কোন ফিল্ড, और কে ডেটার মালিক তা নির্ধারণ না করেন, আপনি একই সিদ্ধান্ত বারবার পুনরায় বিবেচনা করবেন।

শেষ ফাঁক হলো বিল্ডের মাঝপথে কনস্ট্রেইন্ট বদলানো কিন্তু ট্রেড-অফ না বলা। “ওয়েব-অনলি” থেকে “ওয়েব + মোবাইল” বা “Postgres ব্যবহার” থেকে “যেটা সস্তা” তে পরিবর্তন করলে পরিকল্পনা বদলে যায়। আপনি পরিবর্তন করতে পারবেন, কিন্তু স্কোপ, টাইমলাইন, বা গুণমান প্রত্যাশা আপডেট করা জরুরি।

এইসব ফাঁক এড়ানোর দ্রুত উপায়

স্পেক এ একটি সংক্ষিপ্ত নোট যোগ করুন যা পাঁচ পয়েন্টের উত্তর দেয়:

• কি ফিক্স (ডেডলাইন, বাজেট রেঞ্জ, এবং কে এটি বানাচ্ছে)
• কি টেকনিক্যালি ফিক্স (স্ট্যাক, হোস্টিং, অপরিহার্য সিকিউরিটি নিয়ম)
• কি স্পষ্টভাবে অন্তর্ভুক্ত নয় (৩–৫টি স্পষ্ট নন-গোল)
• প্রথম রিলিজের “ডান” মানে কী (একটি পরিমাপযোগ্য আউটকাম)
• কি পরিবর্তন অনুমোদনযোগ্য স্টার্টিংকেন্দ্র ছাড়া

কোড জেনারেট করার আগে দ্রুত চেকলিস্ট ও পরবর্তী ধাপ

কারো কিছু বানানোর আগে, আপনাকে “কি ফিক্স?” প্রশ্নগুলো সহজে উত্তর দিতে সক্ষম হতে হবে, দীর্ঘ ডক খুঁটিয়ে না পড়ে।

দ্রুত চেক:

• আপনি কি ডেডলাইন, বাজেট রেঞ্জ, এবং কে কাজ করবে (বা করবে না) খুঁজে পেতে পারছেন?
• টেকনিক্যাল পছন্দগুলো কি ফিক্সড হিসেবে লেখা আছে, সঙ্গে যা আপনি ব্যবহার করতে অস্বীকার করবেন?
• হোস্টিং স্পষ্ট কি, অঞ্চল ও সাধারণ ডেটা নিয়মসহ (কোথায় ডেটা থাকতে হবে, কি সীমা আছে)?
• কি একটি সংক্ষিপ্ত নন-গোল তালিকা আছে যা স্কোপ ক্রিপ ব্লক করে?
• কি স্পষ্ট যে কি পরিবর্তন হতে পারে এবং কে পরিবর্তন অনুমোদন করে যাতে পুরো স্পেক আবার খোলার দরকার না পড়ে?

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

মোমেন্টাম বজায় রেখে কিন্তু খারাপ সিদ্ধান্তে আটকে না পড়ার পরবর্তী ধাপগুলো:

1. স্পেকের শীর্ষে কনস্ট্রেইন্ট ও নন-গোল রাখুন, ফিচারের আগে।
2. যারা পরিবর্তন অনুমোদন করবে তাদের নিয়ে একটি সংক্ষিপ্ত পরিকল্পনা পাস করুন। নন-গোলগুলো মুখে উচ্চারণ করে নিশ্চিত করুন, কারণ নীরবতা প্রায়ই অসম্মতি মানে।
3. প্রথম ভার্সন ছোট ইটারেশনে বানান, তারপর শেখার সঙ্গে স্পেক টাইট করুন।

আপনি যদি Koder.ai (koder.ai) ব্যবহার করেন, “Planning Mode” এবং স্পষ্ট কনস্ট্রেইন্ট ও নন-গোল সেকশন প্ল্যাটফর্মকে আপনার স্ট্যাক, হোস্টিং রিজিয়ন, এবং স্কোপ অনুযায়ী প্রথম খসড়া জেনারেট করতে সাহায্য করবে। এবং যদি অগ্রাধিকার বদলে যায়, স্ন্যাপশট ও রোলব্যাক আপনাকে একটি স্থিতিশীল বেসলাইন হারানো ছাড়া পরিবর্তন পরীক্ষা করতে দেবে।

যখন এই নিয়মগুলো আগে লেখা থাকে, ফিচার আলোচনা সহজ হয় কারণ সবাই জানে কি থাকতে হবে ফিক্সড এবং কি সরানোর অনুমতি আছে।