স্প্রিন্টের দ্বিতীয় সপ্তাহ চলছে। প্রকৌশল দল প্রায় পুরো ফিচারটি তৈরি করে ফেলেছে। ডিজাইন পর্যালোচনার সময় হঠাৎ একজন অংশীজন বললেন, “আমি তো ভেবেছিলাম, লগইন না করেও ব্যবহারকারী এই সুবিধাটি ব্যবহার করতে পারবে।”
ডেভেলপার বললেন, “চাহিদায় তো সেটা লেখা ছিল না।”
প্রোডাক্ট ম্যানেজারের উত্তর, “আমি ধরে নিয়েছিলাম, বিষয়টি সবার কাছেই পরিষ্কার।”
সমস্যাটা ঠিক এখানেই।
সফটওয়্যার তৈরির কাজে সব ভুল প্রযুক্তিগত জটিলতা থেকে আসে না। অনেক সময় দুই সপ্তাহের কাজ আবার করতে হয় শুধু এ কারণে যে একই ফিচার নিয়ে কথা বললেও প্রত্যেকের মাথায় তার আলাদা ছবি ছিল।
একটি ভালো PRD বা Product Requirement Document এই অস্পষ্টতা কমায়। এতে পরিষ্কার থাকে—কোন সমস্যার সমাধান করা হচ্ছে, কার জন্য করা হচ্ছে, কী তৈরি করতে হবে, কোন বিষয় এখনকার কাজের সীমার বাইরে থাকবে এবং কী ফল পাওয়া গেলে কাজটিকে সফল বলা যাবে।
তবে PRD মানেই বিশাল কোনো নথি নয়। ছোট পরিবর্তনের জন্য এক পাতার PRD-ও যথেষ্ট হতে পারে। আসল প্রশ্ন নথিটি কত বড়, তা নয়। সেটি পড়ে প্রোডাক্ট, ডিজাইন, প্রকৌশল দল ও সংশ্লিষ্ট অংশীজন একই বিষয় বুঝছেন কি না—সেটাই গুরুত্বপূর্ণ।
PRD আসলে কী?
Product Requirement Document বা PRD হলো কোনো পণ্য, ফিচার বা বড় পরিবর্তনের প্রয়োজন, উদ্দেশ্য, কাজের সীমা এবং প্রত্যাশিত ফলাফল লিখিতভাবে পরিষ্কার করার নথি।
সহজ ভাষায়, একটি PRD কয়েকটি গুরুত্বপূর্ণ প্রশ্নের উত্তর দেয়:
- কোন সমস্যার সমাধান করছি?
- কার জন্য করছি?
- কী তৈরি করতে হবে?
- কী এখন তৈরি করা হবে না?
- কী হলে বুঝব কাজটি সফল হয়েছে?
এখানে একটি পার্থক্য মনে রাখা জরুরি। PRD মূলত বলে কী দরকার এবং কেন দরকার। কিন্তু ঠিক কোন প্রযুক্তি, কোন প্রোগ্রামিং লাইব্রেরি বা কী ধরনের ডেটাবেজ কাঠামো দিয়ে সেটি তৈরি করা হবে, তা সাধারণত প্রকৌশল দলের সিদ্ধান্তের ক্ষেত্র।
PRD কী নয়?
নতুন প্রোডাক্ট ম্যানেজারদের একটি পরিচিত ভুল হলো PRD-কে সব ধরনের নথির বিকল্প মনে করা।
PRD সাধারণত—
- প্রকৌশল নকশার নথি নয়;
- বিপণন পরিকল্পনা নয়;
- শুধু wireframe বা নকশার ফাইল নয়;
- backlog বা কাজের তালিকার হুবহু অনুলিপি নয়;
- প্রকল্পের পূর্ণ সময়সূচি নয়;
- অংশীজন যা বলেছেন, তার হুবহু লিখিত রূপও নয়।
ধরা যাক, একটি চাহিদা হলো:
ব্যবহারকারী তার অ্যাকাউন্টে দুই ধাপের পরিচয় যাচাই চালু করতে পারবেন।
এখানে প্রোডাক্ট ম্যানেজারের কাজ হলো কেন এটি দরকার, কার জন্য দরকার, ব্যবহারকারী কী করতে পারবেন, কোন পরিস্থিতিতে কাজটি ব্যর্থ হতে পারে এবং কী হলে ফিচারটি সম্পূর্ণ বলা যাবে—এসব পরিষ্কার করা।
কিন্তু পরিচয় যাচাইয়ের কোড কীভাবে লেখা হবে, তথ্য কোন স্তরে রাখা হবে বা কোন সেবা ব্যবহার করা হবে—এসব বিষয়ে প্রকৌশল দলের কাজের স্বাধীনতা থাকা উচিত, যদি না কোনো নির্দিষ্ট ব্যবসায়িক, নিরাপত্তা বা আইনগত সীমাবদ্ধতা থাকে।
PRD কেন গুরুত্বপূর্ণ?
PRD-এর আসল মূল্য নথি তৈরিতে নয়। এর বড় কাজ হলো সব পক্ষকে একই বোঝাপড়ায় আনা।
একটি ফিচার নিয়ে প্রোডাক্ট, ডিজাইন, প্রকৌশল দল এবং ব্যবসায়িক অংশীজনের চিন্তার জায়গা স্বাভাবিকভাবেই আলাদা।
প্রোডাক্ট ম্যানেজার ভাবছেন ব্যবহারকারীর সমস্যা ও পণ্যের লক্ষ্য নিয়ে। ডিজাইনার ভাবছেন ব্যবহারপ্রবাহ ও ব্যবহারযোগ্যতা নিয়ে। প্রকৌশলী দেখছেন বাস্তবায়ন কতটা সম্ভব, কোথায় ঝুঁকি আছে এবং কোন ব্যতিক্রমী পরিস্থিতি সামলাতে হবে। ব্যবসায়িক অংশীজন হয়তো আয়, সময়সীমা বা বাজারের চাহিদা নিয়ে বেশি ভাবছেন।
PRD এই আলাদা দৃষ্টিভঙ্গিগুলোকে একই আলোচনার জায়গায় নিয়ে আসে।
ভুল জিনিস বানানোর ঝুঁকি কমে
ধরা যাক, চাহিদায় লেখা হলো:
“Checkout সহজ করতে হবে।”
শুনতে ঠিক মনে হলেও বাক্যটি খুব অস্পষ্ট।
“সহজ” বলতে কী বোঝানো হচ্ছে?
অতিথি হিসেবে কেনাকাটা করার সুযোগ? কম ঘর পূরণ? সংরক্ষিত ঠিকানা? কম ধাপ? নাকি দ্রুত পৃষ্ঠা খোলা?
এসব প্রশ্ন শুরুতেই পরিষ্কার না করলে দল প্রযুক্তিগতভাবে ভালো একটি সমাধান বানিয়েও ভুল সমস্যার সমাধান করতে পারে।
কাজের সীমা নিয়ে বিরোধ কমে
প্রোডাক্ট তৈরির কাজে এটি খুব পরিচিত ঘটনা। ছোট একটি ফিচার দিয়ে কাজ শুরু হয়, তারপর পর্যালোচনা সভায় একের পর এক নতুন চাহিদা যোগ হতে থাকে।
তাই ভালো PRD-তে শুধু কী থাকবে লিখলে হবে না। কী থাকবে না, সেটিও পরিষ্কারভাবে লিখতে হবে।
বিশেষ করে MVP তৈরির সময় এই অংশটি খুব গুরুত্বপূর্ণ।
একটি নির্ভরযোগ্য তথ্যসূত্র তৈরি হয়
একটি সিদ্ধান্ত সভায় হয়েছে, আরেকটি বার্তায়, আরেকটি কাজের টিকিটে—এভাবে তথ্য ছড়িয়ে থাকলে বিভ্রান্তি তৈরি হবেই।
হালনাগাদ PRD দলকে একটি নির্ভরযোগ্য মূল নথি দেয়। কোনো সিদ্ধান্ত বদলালে PRD-তেও সেটি বদলানো হয়। ফলে পরে কেউ পুরোনো বার্তা দেখে ভুল সিদ্ধান্ত নিয়ে কাজ শুরু করার ঝুঁকি কমে।
PRD সাধারণত কে লেখে?
বেশির ভাগ পণ্যদলে PRD-এর মূল দায়িত্ব থাকে প্রোডাক্ট ম্যানেজার বা Product Owner-এর ওপর।
তবে এর অর্থ এই নয় যে প্রোডাক্ট ম্যানেজার একা বসে নথি লিখবেন, তারপর বাকিরা শুধু সেটি মেনে কাজ করবেন।
ভালো PRD সাধারণত যৌথভাবে তৈরি হয়।
প্রোডাক্ট ম্যানেজার ব্যবহারকারীর সমস্যা, ব্যবসায়িক উদ্দেশ্য ও পণ্যের লক্ষ্য পরিষ্কার করেন। ডিজাইনার ব্যবহারপ্রবাহ ও ব্যবহারযোগ্যতা নিয়ে প্রশ্ন তোলেন। প্রকৌশল দল বাস্তবায়নের জটিলতা, নির্ভরতা ও প্রযুক্তিগত সীমাবদ্ধতা সামনে আনে। প্রয়োজন হলে তথ্য বিশ্লেষণ, নিরাপত্তা, আইন, বিক্রয় বা পরিচালন দলের মতামতও নেওয়া হয়।
অর্থাৎ, নথিটির প্রধান দায়িত্ব প্রোডাক্ট ম্যানেজারের হতে পারে; কিন্তু ভালো PRD একা ঘরে বসে লেখা নথি নয়।
পণ্য তৈরির কোন পর্যায়ে PRD লেখা হয়?
সাধারণভাবে ব্যবহারকারীর সমস্যা বোঝা ও প্রাথমিক যাচাইয়ের পর PRD লেখা শুরু হয়।
একটি সাধারণ ধারা এমন হতে পারে:
সমস্যা শনাক্ত → ব্যবহারকারী ও ব্যবসায়িক প্রয়োজন যাচাই → সম্ভাব্য সমাধানের দিক নির্ধারণ → PRD → ডিজাইন → প্রকৌশল পরিকল্পনা → নির্মাণ → পরীক্ষা → প্রকাশ
বাস্তবে অবশ্য সব দল এত সরল ধারায় কাজ করে না।
Agile পদ্ধতিতে সমস্যা যাচাই, ডিজাইন এবং চাহিদা পরিমার্জন অনেক সময় পাশাপাশি চলে। গুরুত্বপূর্ণ হলো—সমস্যা না বুঝেই PRD লেখা শুরু না করা।
কোনো অংশীজন যদি বলেন, “আমাদের একটি AI chatbot দরকার”, তাহলে সঙ্গে সঙ্গে chatbot তৈরির PRD লেখা ঠিক হবে না।
প্রথম প্রশ্ন হওয়া উচিত: ব্যবহারকারীর কোন সমস্যার সমাধান করতে chatbot দরকার?
PRD-তে কী কী থাকা জরুরি?
সব প্রতিষ্ঠানের জন্য এক ধরনের PRD কাঠামো নেই। পণ্যের ধরন, দলের আকার, ঝুঁকি ও কাজের পদ্ধতি অনুযায়ী কাঠামো বদলাতে পারে।
তারপরও ভালো PRD-তে কয়েকটি বিষয় প্রায় সব সময়ই কাজে আসে।
১. সমস্যার বিবরণ ও প্রেক্ষাপট
PRD ফিচার দিয়ে নয়, সমস্যা দিয়ে শুরু করলে ভালো হয়।
দুর্বল উদাহরণ:
“অ্যাপে Dark Mode যোগ করতে হবে।”
আরও ভালোভাবে লেখা যায়:
“রাতে অ্যাপ ব্যবহার করেন এমন কিছু ব্যবহারকারী বর্তমান উজ্জ্বল পর্দা নিয়ে অসুবিধার কথা জানিয়েছেন। বর্তমানে অ্যাপটি ফোনের থিম অনুসরণ করে না এবং ব্যবহারকারীও আলাদাভাবে গাঢ় থিম বেছে নিতে পারেন না।”
দ্বিতীয় উদাহরণে বোঝা যাচ্ছে কেন ফিচারটি দরকার।
২. লক্ষ্য ও সাফল্যের মাপকাঠি
ফিচার প্রকাশ করাই লক্ষ্য নয়।
প্রশ্ন করতে হবে—ফিচারটি সফল হলে ব্যবহারকারী বা ব্যবসায়িক ফলাফলে কী পরিবর্তন দেখা যাবে?
ফিচারের ধরন অনুযায়ী মাপকাঠি হতে পারে:
- কাজ সম্পন্ন করার হার;
- বিক্রয় রূপান্তরের হার;
- ব্যবহারকারী ধরে রাখার হার;
- ত্রুটির হার;
- সহায়তা চাওয়ার সংখ্যা;
- ফিচার ব্যবহারের হার;
- পৃষ্ঠা বা সেবার সাড়া দেওয়ার সময়।
সব ক্ষেত্রেই আয়কে মাপকাঠি বানানোর প্রয়োজন নেই। কোনো ফিচারের উদ্দেশ্য যদি ব্যবহারকারীর ভুল কমানো হয়, তাহলে ভুলের হারই বেশি অর্থবহ মাপকাঠি হতে পারে।
৩. লক্ষ্য ব্যবহারকারী
“সব ব্যবহারকারীর জন্য”—এই কথাটি খুব সাবধানে ব্যবহার করুন।
ফিচারটি কি নতুন ব্যবহারকারীর জন্য? নিয়মিত ব্যবহারকারীর জন্য? প্রশাসকের জন্য? বিক্রেতার জন্য? অর্থপ্রদানকারী গ্রাহকের জন্য? নাকি প্রতিষ্ঠানের ভেতরের কোনো দলের জন্য?
লক্ষ্য ব্যবহারকারী যত পরিষ্কার হবে, চাহিদা ও ডিজাইন নিয়ে সিদ্ধান্ত নেওয়া তত সহজ হবে।
৪. কাজের সীমা
এই অংশে সাধারণত দুটি বিষয় রাখা ভালো:
যা থাকবে: বর্তমান সংস্করণে কী তৈরি হবে।
যা থাকবে না: কোন বিষয়গুলো সচেতনভাবে এখন করা হবে না।
MVP তৈরির সময় এই অংশটি বিশেষভাবে দরকারি। কারণ MVP-তে সবচেয়ে বড় প্রশ্ন সাধারণত “আর কী যোগ করা যায়” নয়; বরং “এখন কী না করলেও চলে”।
৫. কার্যগত চাহিদা
পণ্য বা ব্যবস্থাটি কী করতে পারবে, সেটি এখানে লেখা হয়।
যেমন Dark Mode-এর ক্ষেত্রে:
- ব্যবহারকারী সেটিংস থেকে গাঢ় থিম চালু করতে পারবেন।
- চাইলে ফোনের থিম অনুসরণ করার বিকল্প বেছে নিতে পারবেন।
- নির্বাচিত থিম সংরক্ষিত থাকবে।
- অ্যাপ বন্ধ করে আবার চালু করলেও আগের পছন্দ বজায় থাকবে।
এগুলো এমন আচরণ, যা ডিজাইনার, ডেভেলপার ও পরীক্ষক সবাই বুঝতে পারবেন।
৬. গুণগত বা অ-কার্যগত চাহিদা
নামটি একটু প্রযুক্তিগত শোনালেও ধারণাটি সহজ।
কার্যগত চাহিদা বলে পণ্য কী করবে।
গুণগত চাহিদা বলে কাজটি কতটা দ্রুত, নিরাপদ, নির্ভরযোগ্য বা ব্যবহারযোগ্যভাবে করতে হবে।
এখানে আসতে পারে:
- কর্মক্ষমতা;
- নিরাপত্তা;
- নির্ভরযোগ্যতা;
- গোপনীয়তা;
- প্রবেশগম্যতা;
- সমর্থিত যন্ত্র বা পরিবেশ।
যেমন Dark Mode-এ লেখা ও পটভূমির বৈপরীত্য এমন হতে হবে, যাতে লেখা স্পষ্টভাবে পড়া যায়।
৭. ধরে নেওয়া বিষয় ও সীমাবদ্ধতা
কিছু বিষয় আমরা আপাতত সত্য ধরে কাজ শুরু করি। এগুলো হচ্ছে অনুমান।
আবার কিছু বাস্তব সীমা আছে, যার বাইরে যাওয়া যাবে না। এগুলো সীমাবদ্ধতা।
উদাহরণ:
ধরে নেওয়া হচ্ছে: অধিকাংশ লক্ষ্য ব্যবহারকারী অ্যাপের সাম্প্রতিক সংস্করণ ব্যবহার করছেন।
সীমাবদ্ধতা: বর্তমান প্রকাশে পুরো নকশা ব্যবস্থা নতুন করে তৈরি করা যাবে না।
৮. নির্ভরতা
ফিচারটি কি অন্য দল, API, তৃতীয় পক্ষের সেবা, প্ল্যাটফর্মের অনুমোদন বা অবকাঠামোগত পরিবর্তনের ওপর নির্ভর করছে?
এই নির্ভরতাগুলো আগে না লিখলে সময় পরিকল্পনা বাস্তবতার তুলনায় অনেক বেশি আশাবাদী হয়ে যেতে পারে।
৯. সময়সীমা ও প্রধান ধাপ
PRD পুরো প্রকল্পের সময়সূচি নয়। তবু নির্দিষ্ট প্রকাশের সময়, ব্যবসায়িক সময়সীমা বা গুরুত্বপূর্ণ ধাপ থাকলে তা উল্লেখ করা দরকার।
বিশেষ করে বিপণন প্রচার, অংশীদার সংযোগ, চুক্তিভিত্তিক প্রতিশ্রুতি বা আইনগত সময়সীমা থাকলে।
১০. অমীমাংসিত প্রশ্ন
সব উত্তর শুরুতেই জানা থাকবে—এমন আশা করা বাস্তবসম্মত নয়।
বরং যেসব প্রশ্নের উত্তর এখনো মেলেনি, সেগুলো স্পষ্টভাবে লিখুন।
যেমন:
- লগইন না করা ব্যবহারকারীর থিম পছন্দ কোথায় রাখা হবে?
- বর্তমান ব্যবহারকারীদের জন্য কোন থিম স্বয়ংক্রিয়ভাবে চালু থাকবে?
- ওয়েব সংস্করণ কি একই প্রকাশের অংশ?
অমীমাংসিত প্রশ্ন দৃশ্যমান থাকলে সিদ্ধান্ত নেওয়া যায়। আড়ালে থাকলে সেগুলো সাধারণত কাজের মাঝপথে সমস্যা হয়ে ফিরে আসে।
১১. অংশীজন ও অনুমোদন প্রক্রিয়া
কারা নথিটি পর্যালোচনা করবেন? কার মতামত বাধ্যতামূলক? শেষ সিদ্ধান্ত কে দেবেন?
সব প্রতিষ্ঠানে আনুষ্ঠানিক sign-off বা চূড়ান্ত অনুমোদন প্রয়োজন হয় না। কিন্তু শেষ সিদ্ধান্তের দায়িত্ব কার, সেটি পরিষ্কার থাকা দরকার।
PRD-এর মূল উপাদান
| উপাদানের নাম | কী থাকে | কেন গুরুত্বপূর্ণ |
| সমস্যার বিবরণ | ব্যবহারকারী বা ব্যবসায়িক সমস্যা ও প্রেক্ষাপট | সমাধানের আগে সমস্যা বুঝতে সাহায্য করে |
| লক্ষ্য | কোন ফল অর্জন করতে হবে | ফিচারটি কেন তৈরি হচ্ছে তা পরিষ্কার করে |
| সাফল্যের মাপকাঠি | ফল মাপার উপায় | প্রকাশ করা আর সফল হওয়ার পার্থক্য বোঝায় |
| লক্ষ্য ব্যবহারকারী | কোন ব্যবহারকারী দলের জন্য | চাহিদা ও ডিজাইন সিদ্ধান্ত নির্দিষ্ট করে |
| কাজের সীমা | কী থাকবে এবং কী থাকবে না | কাজ অযথা বড় হওয়া ঠেকায় |
| কার্যগত চাহিদা | পণ্য কী করতে পারবে | প্রত্যাশিত আচরণ পরিষ্কার করে |
| গুণগত চাহিদা | গতি, নিরাপত্তা, নির্ভরযোগ্যতা, প্রবেশগম্যতা | কাজের মান ও গ্রহণযোগ্যতার সীমা ঠিক করে |
| অনুমান ও সীমাবদ্ধতা | ধরে নেওয়া বিষয় ও বাস্তব সীমা | ঝুঁকি ও সিদ্ধান্তের প্রেক্ষাপট বোঝায় |
| নির্ভরতা | অন্য দল, ব্যবস্থা, API বা সেবার ওপর নির্ভরতা | বাস্তবায়নের ঝুঁকি বুঝতে সাহায্য করে |
| সময়সীমা | প্রধান তারিখ ও ধাপ | পরিকল্পনা বাস্তবসম্মত করতে সাহায্য করে |
| অমীমাংসিত প্রশ্ন | এখনো সিদ্ধান্ত না হওয়া বিষয় | গুরুত্বপূর্ণ অজানা বিষয় লুকিয়ে থাকতে দেয় না |
| অংশীজন ও অনুমোদন | পর্যালোচক ও সিদ্ধান্তদাতা | মতামত ও চূড়ান্ত অনুমোদনের প্রক্রিয়া পরিষ্কার করে |
PRD কীভাবে লিখবেন? ধাপে ধাপে পদ্ধতি
PRD লেখার কাজ কোনো template খুলে ঘর পূরণ করা দিয়ে শুরু হয় না। ভালো PRD-এর আসল কাজ শুরু হয় তারও আগে।
ধাপ ১: চাওয়া ফিচার নয়, আসল সমস্যা বুঝুন
অংশীজনের সঙ্গে প্রথম আলোচনায় শুধু ফিচারের তালিকা লিখবেন না।
জানার চেষ্টা করুন:
“এই সমস্যা এখন কেন গুরুত্বপূর্ণ?”
“কারা সবচেয়ে বেশি সমস্যায় পড়ছেন?”
“বর্তমানে তারা কাজটি কীভাবে করছেন?”
“এটি না বানালে কী সমস্যা হবে?”
“এই সমস্যার পক্ষে আমাদের কী প্রমাণ আছে?”
এই প্রশ্নগুলো অনেক অপ্রয়োজনীয় ফিচার তৈরি হওয়া ঠেকাতে পারে।
ধাপ ২: ব্যবহারকারীর তথ্য ও বিদ্যমান উপাত্ত দেখুন
ব্যবহারকারীর সাক্ষাৎকার, সহায়তা চাওয়ার বার্তা, ব্যবহারসংক্রান্ত উপাত্ত, বিক্রয় দলের মতামত, ব্যবহারযোগ্যতা পরীক্ষা বা আগের পরীক্ষার ফল—যা আছে, দেখুন।
প্রতিটি ছোট ফিচারের জন্য বড় গবেষণা দরকার নেই। কিন্তু চাহিদাটি যেন অন্তত বাস্তব কোনো সমস্যার সঙ্গে যুক্ত থাকে।
ধাপ ৩: সমস্যার বিবরণ লিখুন
দুই বা তিনটি বাক্যে সমস্যাটি বোঝানোর চেষ্টা করুন।
এমনভাবে লিখবেন না, যাতে পাঠককে মূল সমস্যা খুঁজতে পাঁচ অনুচ্ছেদ পড়তে হয়।
নিজেকে প্রশ্ন করুন: প্রকৌশল দলের প্রধান শুধু এই অংশ পড়েই কি বুঝতে পারবেন, কেন ফিচারটি দরকার?
ধাপ ৪: লক্ষ্য ও যা এখন লক্ষ্য নয়—দুটিই লিখুন
শুধু লক্ষ্য লিখবেন না। এই পর্যায়ে কোন কাজটি করা হবে না, সেটিও লিখুন।
ধরা যাক, অনুসন্ধান সুবিধা উন্নত করা হচ্ছে।
লক্ষ্য: ব্যবহারকারী যেন দ্রুত প্রাসঙ্গিক ফল খুঁজে পান।
এখনকার লক্ষ্য নয়: এই সংস্করণে পুরো সুপারিশ ব্যবস্থা নতুন করে তৈরি করা হবে না।
এই একটি অংশ ভবিষ্যতের অনেক ভুল প্রত্যাশা কমাতে পারে।
ধাপ ৫: User story ও চাহিদা লিখুন
অস্পষ্ট বিশেষণ কম ব্যবহার করুন।
“দ্রুত”, “সহজ”, “আধুনিক”, “সুন্দর”, “স্বজ্ঞাত”—এসব শব্দ একা কোনো চাহিদা নয়।
পরিবর্তে এমন আচরণ লিখুন, যা দেখা এবং পরীক্ষা করা যায়।
ধরা যাক:
একজন নিবন্ধিত ব্যবহারকারী হিসেবে আমি আমার সংরক্ষিত অর্থপ্রদানের মাধ্যম দেখতে চাই, যাতে কেনাকাটার সময় আমাকে বারবার কার্ডের তথ্য দিতে না হয়।
তারপর গ্রহণযোগ্যতার শর্ত বা acceptance criteria দিয়ে সীমা পরিষ্কার করা যায়।
ধাপ ৬: ব্যতিক্রমী পরিস্থিতি নিয়ে ডিজাইন ও প্রকৌশল দলের সঙ্গে বসুন
শুধু স্বাভাবিক ব্যবহারপথ লিখে PRD শেষ করবেন না।
অর্থপ্রদানের প্রবাহ হলে ভাবুন:
- অর্থপ্রদান ব্যর্থ হলে কী হবে?
- ব্যবহারকারী মাঝপথে ফিরে গেলে কী হবে?
- ইন্টারনেট সংযোগ চলে গেলে কী হবে?
- একই অনুরোধ দুবার গেলে কী হবে?
- কার্ডের মেয়াদ শেষ হলে কী হবে?
প্রোডাক্ট ম্যানেজারকে সব প্রযুক্তিগত উত্তর জানতেই হবে না। তবে সঠিক প্রশ্নগুলো সামনে আনার দায়িত্ব তাঁর আছে।
ধাপ ৭: খসড়া পর্যালোচনা করুন
প্রথম খসড়াই চূড়ান্ত PRD নয়।
ডিজাইন, প্রকৌশল দল এবং প্রয়োজনীয় অংশীজনদের নিয়ে পর্যালোচনা করুন।
আলোচনায় বিশেষভাবে দেখুন:
- সমস্যা সবাই একইভাবে বুঝেছেন কি না;
- কাজের সীমা বাস্তবসম্মত কি না;
- কোনো গুরুত্বপূর্ণ চাহিদা বাদ পড়েছে কি না;
- লুকানো কোনো নির্ভরতা আছে কি না;
- কোন সিদ্ধান্ত এখনো বাকি।
ধাপ ৮: সংশোধন করে চূড়ান্ত অনুমোদন নিন
মতামতের ভিত্তিতে নথি সংশোধন করুন।
কোনো সিদ্ধান্ত বদলালে সেটি শুধু চ্যাট বা সভার নোটে রেখে দেবেন না। PRD-তেও পরিবর্তনটি লিখুন।
বড় প্রতিষ্ঠানে আনুষ্ঠানিক sign-off লাগতে পারে। ছোট দলে প্রোডাক্ট, ডিজাইন ও প্রকৌশল নেতৃত্বের পরিষ্কার সম্মতিই যথেষ্ট হতে পারে।
ধাপ ৯: কাজ চলাকালেও PRD হালনাগাদ রাখুন
চূড়ান্ত অনুমোদন পাওয়ার পর PRD-কে বন্ধ নথি বানিয়ে রাখবেন না।
কাজ চলাকালে নতুন ব্যতিক্রমী পরিস্থিতি, সীমাবদ্ধতা বা কাজের সীমা-সংক্রান্ত সিদ্ধান্ত আসতে পারে।
গুরুত্বপূর্ণ পরিবর্তন হলে PRD-তে লিখে রাখুন। প্রয়োজন হলে ছোট পরিবর্তন-তালিকা যোগ করুন—কী বদলেছে, কেন বদলেছে এবং কবে সিদ্ধান্ত হয়েছে।
PRD লেখার ধাপ
| ধাপ | কী করতে হবে | কার সঙ্গে কাজ করতে হবে |
| ১. প্রেক্ষাপট বোঝা | সমস্যা, ব্যবসায়িক প্রয়োজন ও অনুরোধের কারণ বুঝুন | অংশীজন, গ্রাহকসেবা, বিক্রয় দল |
| ২. প্রমাণ দেখা | ব্যবহারকারীর মতামত, উপাত্ত ও আগের ফল যাচাই করুন | গবেষণা, তথ্য বিশ্লেষণ, সহায়তা দল |
| ৩. সমস্যা লিখুন | সংক্ষিপ্ত ও পরিষ্কার সমস্যার বিবরণ তৈরি করুন | প্রোডাক্ট ও ডিজাইন |
| ৪. লক্ষ্য ও কাজের সীমা ঠিক করুন | লক্ষ্য, সাফল্যের মাপকাঠি, কী থাকবে ও কী থাকবে না নির্ধারণ করুন | অংশীজন, প্রোডাক্ট নেতৃত্ব |
| ৫. চাহিদা লিখুন | User story, কার্যগত চাহিদা ও গ্রহণযোগ্যতার শর্ত তৈরি করুন | ডিজাইন ও প্রকৌশল দল |
| ৬. সীমাবদ্ধতা যাচাই | ব্যতিক্রমী পরিস্থিতি, নিরাপত্তা, কর্মক্ষমতা ও নির্ভরতা দেখুন | প্রকৌশল, QA, নিরাপত্তা দল |
| ৭. পর্যালোচনা করুন | খসড়া নিয়ে কাঠামোবদ্ধ মতামত নিন | ডিজাইন, প্রকৌশল ও অংশীজন |
| ৮. অনুমোদন নিন | সিদ্ধান্ত ও অমীমাংসিত প্রশ্ন পরিষ্কার করুন | সংশ্লিষ্ট সিদ্ধান্তদাতা |
| ৯. হালনাগাদ রাখুন | কাজ চলার সময় অনুমোদিত পরিবর্তন নথিবদ্ধ করুন | পুরো বাস্তবায়ন দল |
চাহিদা কীভাবে লিখলে প্রকৌশল দল সহজে বুঝবে?
চাহিদা যতটা সম্ভব পরীক্ষা করা যায় এমন হওয়া ভালো।
ধরা যাক, লেখা হলো:
“ব্যবহারকারী সহজে পাসওয়ার্ড পরিবর্তন করতে পারবেন।”
এখানে সমস্যা হলো, “সহজে” কীভাবে মাপবেন?
এর বদলে লেখা যায়:
“লগইন পর্দা থেকে ব্যবহারকারী ‘পাসওয়ার্ড ভুলে গেছেন’ বিকল্প বেছে নিয়ে নিবন্ধিত ই-মেইলে পাসওয়ার্ড পুনর্নির্ধারণের লিংক চাইতে পারবেন।”
তারপর গ্রহণযোগ্যতার শর্ত হতে পারে:
- বৈধ অ্যাকাউন্ট হলে পুনর্নির্ধারণের ই-মেইল পাঠানো হবে।
- অজানা ই-মেইল দিলে ওই ঠিকানায় অ্যাকাউন্ট আছে কি না, তা প্রকাশ করা হবে না।
- মেয়াদ শেষ হওয়া লিংক ব্যবহার করা যাবে না।
- নতুন পাসওয়ার্ড নির্ধারিত নীতি পূরণ না করলে উপযুক্ত বার্তা দেখানো হবে।
এখন প্রোডাক্ট, প্রকৌশল ও QA—সবাই একই আচরণ বুঝতে পারছে।
এটাই কার্যকর PRD-এর অন্যতম বড় সুবিধা।
ছোট PRD নাকি বিস্তারিত PRD—কখন কোনটি দরকার?
প্রতিটি ফিচারের জন্য একই ধরনের নথি বানানো ভালো প্রক্রিয়ার লক্ষণ নয়।
একটি বোতামের লেখা বদলানোর জন্য ১২ পাতার PRD তৈরি করা অপ্রয়োজনীয়। আবার নতুন অর্থপ্রদান ব্যবস্থা তৈরির জন্য পাঁচ লাইনের কাজের টিকিট দিয়েই নির্মাণ শুরু করাও ঝুঁকিপূর্ণ।
কখন এক পাতার PRD যথেষ্ট?
ছোট ও কম ঝুঁকির পরিবর্তনের ক্ষেত্রে এক পৃষ্ঠা বা সংক্ষিপ্ত PRD যথেষ্ট হতে পারে।
যেমন:
- পুরোনো ফিচারের ছোট ব্যবহারযোগ্যতা উন্নয়ন;
- সীমিত ব্যবহারপ্রবাহ পরিবর্তন;
- ছোট পরীক্ষা;
- সীমিত ব্যবহারকারী দলের জন্য ফিচার;
- এমন কাজ, যার প্রেক্ষাপট ডিজাইন ও প্রকৌশল দল আগে থেকেই ভালোভাবে জানে।
এক্ষেত্রে সমস্যা, লক্ষ্য, কাজের সীমা, মূল চাহিদা, সাফল্যের মাপকাঠি এবং গুরুত্বপূর্ণ অমীমাংসিত প্রশ্ন থাকলেই অনেক সময় যথেষ্ট।
কখন বিস্তারিত PRD দরকার?
জটিলতা ও ঝুঁকি যত বাড়ে, নথিতে প্রয়োজনীয় বিস্তারিতও তত বাড়তে পারে।
যেমন:
- নতুন পণ্যসারি;
- নতুন checkout বা অর্থপ্রদানের প্রবাহ;
- সংবেদনশীল তথ্য ব্যবস্থাপনা;
- একাধিক দলের ওপর নির্ভরতা;
- বড় প্ল্যাটফর্ম পরিবর্তন;
- বড় প্রতিষ্ঠানের জন্য বিশেষ ফিচার;
- আইন বা নিরাপত্তাসংক্রান্ত চাহিদা;
- বড় MVP, যেখানে অনেক অংশীজন জড়িত।
মূল নীতি হলো—নথির দৈর্ঘ্য নয়, সিদ্ধান্তের জটিলতা অনুযায়ী বিস্তারিত নির্ধারণ করুন।
PRD, BRD ও FRD-এর মধ্যে পার্থক্য কী?
এই তিনটি নাম নিয়ে অযথা কঠোর বিভাজন তৈরি করার দরকার নেই।
এক প্রতিষ্ঠানে যে নথিকে PRD বলা হয়, অন্য প্রতিষ্ঠানে তার কিছু অংশ BRD বা FRD-তে থাকতে পারে। কোথাও তিনটি আলাদা নথি আছে, কোথাও একটিই আছে।
তাই এগুলোকে চূড়ান্ত নিয়ম না ধরে সাধারণ ব্যবহার হিসেবে বোঝা ভালো।
BRD: ব্যবসা কেন কাজটি করছে?
Business Requirement Document বা BRD সাধারণত ব্যবসায়িক সমস্যা, উদ্দেশ্য, প্রত্যাশিত মূল্য, উচ্চপর্যায়ের কাজের সীমা এবং অংশীজনের প্রয়োজনের দিকে বেশি নজর দেয়।
PRD: পণ্য কী দেবে?
PRD ব্যবসায়িক প্রেক্ষাপটকে ব্যবহারকারীর সমস্যা ও পণ্যের সক্ষমতার সঙ্গে যুক্ত করে।
এতে থাকে ব্যবহারকারীর প্রয়োজন, ফিচারের আচরণ, কাজের সীমা, সাফল্যের মাপকাঠি এবং প্রকাশের প্রয়োজনীয় শর্ত।
FRD: ব্যবস্থা কীভাবে আচরণ করবে?
Functional Requirement Document বা FRD সাধারণত ব্যবস্থার কার্যগত আচরণ আরও বিস্তারিতভাবে বোঝায়।
যেমন:
- কোন তথ্য নেওয়া হবে;
- কোন শর্তে কী ফল হবে;
- কোন ক্রমে কাজ হবে;
- ভুল হলে কী হবে;
- নির্দিষ্ট ব্যবহারের ক্ষেত্রে ব্যবস্থা কীভাবে সাড়া দেবে।
PRD, BRD ও FRD-এর তুলনা
| নথি | মূল ফোকাস | সাধারণত কে লেখে | কখন ব্যবহৃত হয় |
| BRD — Business Requirement Document | ব্যবসায়িক সমস্যা, উদ্দেশ্য, মূল্য ও উচ্চপর্যায়ের চাহিদা | ব্যবসায় বিশ্লেষক, প্রকল্পপ্রধান বা ব্যবসায়িক অংশীজন | কোনো উদ্যোগের ব্যবসায়িক প্রয়োজন পরিষ্কার করার সময় |
| PRD — Product Requirement Document | ব্যবহারকারীর সমস্যা, কাজের সীমা, পণ্যের আচরণ ও সাফল্যের মাপকাঠি | প্রোডাক্ট ম্যানেজার বা Product Owner, অন্য দলের মতামতসহ | পণ্য বা ফিচারের নকশা ও নির্মাণের আগে এবং চলাকালে |
| FRD — Functional Requirement Document | ব্যবস্থার বিস্তারিত কার্যগত আচরণ | ব্যবসায় বিশ্লেষক, সিস্টেম বিশ্লেষক বা সংশ্লিষ্ট পণ্য ও প্রকৌশল দল | বিস্তারিত কার্যপদ্ধতি নির্ধারণ বা নির্মাণ পরিকল্পনার সময় |
আপনার দলে BRD ও PRD-এর বিষয়বস্তু যদি এক নথিতেই থাকে এবং সবাই সেটি বুঝে কাজ করতে পারেন, তাহলে শুধু নাম আলাদা রাখার জন্য নতুন নথি তৈরির প্রয়োজন নেই।
PRD লেখার সময় প্রোডাক্ট ম্যানেজাররা যে ভুলগুলো বেশি করেন
চাহিদা খুব অস্পষ্ট রাখা
“Dashboard আরও কাজের হতে হবে।”
এটি আসলে পরিষ্কার চাহিদা নয়।
“কাজের” বলতে ব্যবহারকারী কী নতুন কাজ করতে পারবেন, সেটি লিখতে হবে।
অতিরিক্তভাবে সমাধান নির্ধারণ করে দেওয়া
উল্টো সমস্যাও হয়।
কিছু PRD পড়লে মনে হয় সেটি প্রোডাক্ট ম্যানেজারের লেখা প্রকৌশল নকশার নথি।
কোন ডেটাবেজ ব্যবহার হবে, কোন লাইব্রেরি লাগবে, কোন সেবা কোথায় থাকবে—এসব বিষয় যদি পণ্যের বাধ্যতামূলক সীমাবদ্ধতা না হয়, তাহলে প্রকৌশল দলের সিদ্ধান্তের জায়গা থাকা উচিত।
প্রোডাক্ট ম্যানেজারের মূল দায়িত্ব কী দরকার এবং কেন দরকার পরিষ্কার করা।
সাফল্যের মাপকাঠি না রাখা
“ফিচার প্রকাশ হয়েছে”—এটি সাফল্যের মাপকাঠি নয়।
এটি শুধু কাজ শেষ হওয়ার একটি ঘটনা।
সাফল্য তখনই বোঝা যাবে, যখন দেখা যাবে ফিচারটি ব্যবহারকারীর আচরণ বা ব্যবসায়িক ফলাফলে কাঙ্ক্ষিত পরিবর্তন এনেছে কি না।
প্রকৌশল দলের মতামত ছাড়াই PRD চূড়ান্ত করা
প্রকৌশল দলের পর্যালোচনায় অনেক লুকানো জটিলতা সামনে আসে।
প্রোডাক্ট ম্যানেজার হয়তো ভাবলেন, “একটি ছোট ছাঁকনি যোগ করতে হবে।”
প্রকৌশলী জানালেন, বর্তমান API-তেই প্রয়োজনীয় তথ্য নেই।
এই তথ্য স্প্রিন্ট শুরুর আগে জানা আর মাঝপথে জানা—দুটোর প্রভাব এক নয়।
কী থাকবে না, সেটি না লেখা
শুধু কী থাকবে লিখলে অনেকেই ধরে নেন কাছাকাছি অন্য সুবিধাগুলোও বর্তমান কাজের অংশ।
তাই পরিষ্কারভাবে লিখুন:
“এই সংস্করণে একসঙ্গে অনেক তথ্য রপ্তানির সুবিধা থাকবে না।”
একটি ছোট বাক্য অনেক দীর্ঘ আলোচনা বাঁচাতে পারে।
প্রথম খসড়ার পর PRD আর না বদলানো
চাহিদা বদলেছে, কিন্তু PRD বদলায়নি—এমন হলে সেটি আর বর্তমান সত্যের নথি নয়।
PRD-কে জীবন্ত নথি বলার অর্থ প্রতিদিন কিছু না কিছু বদলানো নয়। গুরুত্বপূর্ণ সিদ্ধান্ত বদলালে নথিটিও বদলানো।
ডিজাইন ও প্রকৌশল দলের সঙ্গে PRD নিয়ে কীভাবে কাজ করবেন?
PRD পর্যালোচনাকে শুধু অনুমোদনের আনুষ্ঠানিকতা বানালে লাভ কম।
বরং পর্যালোচনার উদ্দেশ্য হওয়া উচিত চাহিদার দুর্বলতা বের করা।
প্রকৌশল দলকে জিজ্ঞেস করুন:
“কোন চাহিদা বাস্তবায়নে বড় ঝুঁকি আছে?”
ডিজাইনারকে জিজ্ঞেস করুন:
“কোন ব্যবহারপ্রবাহ এখনো অস্পষ্ট?”
QA-কে জিজ্ঞেস করুন:
“কোন গ্রহণযোগ্যতার শর্ত পরীক্ষা করা কঠিন?”
ব্যবসায়িক অংশীজনকে জিজ্ঞেস করুন:
“এখন যা করা হবে না, তার মধ্যে এমন কিছু আছে কি যা ব্যবসার জন্য অবশ্যই দরকার?”
“কোনো মতামত আছে?”—এই সাধারণ প্রশ্নের চেয়ে এমন নির্দিষ্ট প্রশ্ন বেশি কার্যকর।
পর্যালোচনা সংক্ষিপ্ত রাখুন
ছোট ফিচারের ক্ষেত্রে নথিতে মন্তব্য করেই অনেক সময় কাজ হয়ে যায়।
জটিল ফিচারের জন্য আলাদা পর্যালোচনা সভা দরকার হতে পারে। তবে সভায় পুরো নথি পড়ে শোনানোর প্রয়োজন নেই।
সবার আগে পড়ার সুযোগ থাকা ভালো। সভার সময় ব্যবহার করুন মতবিরোধ, ঝুঁকি এবং অমীমাংসিত প্রশ্ন নিয়ে আলোচনা করতে।
পরিবর্তনের ইতিহাস রাখুন
Google Docs, Notion, Confluence বা অন্য কোনো সহযোগী নথি ব্যবস্থাপনা পদ্ধতি ব্যবহার করলে গুরুত্বপূর্ণ পরিবর্তনের ইতিহাস রাখুন।
যেমন:
পরিবর্তন: Guest checkout MVP থেকে বাদ দেওয়া হয়েছে।
কারণ: অর্থপ্রদান সেবাদাতার ওপর নির্ভরতার কারণে প্রকাশের সময়সীমায় ঝুঁকি তৈরি হচ্ছে।
সিদ্ধান্তের তারিখ: [তারিখ]
পরে “এটি কে বাদ দিয়েছিল?” বা “কেন সিদ্ধান্ত বদলেছিল?”—এই ধরনের বিভ্রান্তি কমে।
PRD ও backlog-এর সম্পর্ক পরিষ্কার রাখুন
PRD পুরো সমস্যার প্রেক্ষাপট দেয়।
Backlog বা কাজের তালিকা সেই সমস্যার সমাধানকে ছোট ছোট বাস্তবায়নযোগ্য কাজে ভেঙে দেয়।
PRD থেকে epic, user story ও আলাদা কাজ তৈরি হতে পারে। কিন্তু কাজের তালিকার ছোট ছোট টিকিটের মধ্যে যদি মূল ব্যবহারকারী সমস্যা হারিয়ে যায়, তাহলে দল শুধু টিকিট শেষ করবে; পণ্যের ফল অর্জন করবে না।
তাই কাজের তালিকার সংশ্লিষ্ট অংশ থেকে PRD-র সংযোগ রাখা ভালো অভ্যাস।
সারণি ৪: একটি সংক্ষিপ্ত নমুনা PRD
নিচের উদাহরণটি সম্পূর্ণ কাল্পনিক এবং বোঝানোর জন্য তৈরি। এটি কোনো বাস্তব প্রতিষ্ঠানের অভ্যন্তরীণ PRD নয়।
ধরা যাক, একটি মোবাইল অ্যাপে Dark Mode যোগ করা হবে।
| PRD-এর অংশ | উদাহরণস্বরূপ বিষয়বস্তু |
| সমস্যার বিবরণ | রাতে অ্যাপ ব্যবহার করা কিছু ব্যবহারকারী বর্তমান উজ্জ্বল পর্দা নিয়ে অস্বস্তির কথা জানিয়েছেন। অ্যাপ বর্তমানে ফোনের থিম অনুসরণ করে না। |
| লক্ষ্য | ব্যবহারকারীকে হালকা, গাঢ় অথবা ফোনের নিজস্ব থিম অনুসরণ করার সুযোগ দেওয়া। |
| লক্ষ্য ব্যবহারকারী | মোবাইল অ্যাপের লগইন করা ব্যবহারকারী। |
| সাফল্যের মাপকাঠি | নতুন থিম ব্যবহারের হার এবং থিম-সংক্রান্ত সহায়তা বার্তা পর্যবেক্ষণ করা হবে। |
| যা থাকবে | তিন ধরনের থিম নির্বাচন, সেটিংসে বিকল্প, পছন্দ সংরক্ষণ এবং সমর্থিত পর্দায় থিম প্রয়োগ। |
| যা থাকবে না | নিজস্ব রঙের থিম, ওয়েব অ্যাপের পুনর্নকশা, ব্যবহারকারীর তৈরি থিম। |
| User story | একজন অ্যাপ ব্যবহারকারী হিসেবে আমি গাঢ় থিম বেছে নিতে চাই, যাতে কম আলোতে অ্যাপ ব্যবহার করতে স্বাচ্ছন্দ্য বোধ করি। |
| কার্যগত চাহিদা | সেটিংস থেকে থিম নির্বাচন করা যাবে এবং অ্যাপ পুনরায় চালু করলেও পছন্দটি থাকবে। |
| গুণগত চাহিদা | লেখা ও নিয়ন্ত্রণগুলো গাঢ় পটভূমিতে স্পষ্ট থাকতে হবে এবং থিম বদলালে অ্যাপের স্থিতিশীলতা নষ্ট হওয়া যাবে না। |
| ব্যতিক্রমী পরিস্থিতি | লগআউট করা ব্যবহারকারীর পছন্দ যন্ত্রে রাখা হবে কি না—সিদ্ধান্ত প্রয়োজন। |
| নির্ভরতা | বর্তমান নকশা ব্যবস্থা এবং মোবাইল অ্যাপের থিম কাঠামো। |
| অমীমাংসিত প্রশ্ন | বর্তমান ব্যবহারকারীদের প্রাথমিক থিম কী হবে—হালকা, নাকি ফোনের নিজস্ব থিম? |
| সংশ্লিষ্ট পক্ষ | প্রোডাক্ট, মোবাইল প্রকৌশল, ডিজাইন ও QA দল। |
| সময়সীমা | প্রকৌশল দলের হিসাব ও নির্ভরতা যাচাইয়ের পরে নির্ধারণ করা হবে। |
খেয়াল করুন, এই কাল্পনিক PRD-তে ডেভেলপারকে বলা হয়নি Dark Mode কীভাবে কোড করতে হবে।
কিন্তু “কাজ শেষ” বলতে কী বোঝানো হচ্ছে, তার সীমা পরিষ্কার।
এটাই ভালো PRD-এর আসল উদ্দেশ্য।
PRD ভালো হয়েছে কি না বুঝবেন কীভাবে?
নথি লেখা শেষ হলে একবার লেখকের চোখ দিয়ে নয়, পাঠকের চোখ দিয়ে পড়ুন।
একজন প্রকৌশলী কি নথিটি পড়ে বলতে পারবেন—
- আমরা কোন সমস্যার সমাধান করছি?
- কার জন্য করছি?
- এই প্রকাশে কী থাকবে?
- কী থাকবে না?
- প্রত্যাশিত আচরণ কী?
- কোন সিদ্ধান্ত এখনো বাকি?
- কী হলে কাজটি গ্রহণযোগ্য বলা যাবে?
ডিজাইনার কি ব্যবহারপ্রবাহের মূল সীমা বুঝতে পারছেন?
ব্যবসায়িক অংশীজন কি বুঝতে পারছেন কাজটির উদ্দেশ্য কী?
QA দল কি গ্রহণযোগ্যতার শর্ত থেকে পরীক্ষার পরিস্থিতি তৈরি করতে পারছে?
যদি এসব প্রশ্নের উত্তর বারবার “না” হয়, তাহলে PRD আরও বড় করার দরকার নেই।
আরও পরিষ্কার করার দরকার আছে।
PRD নিয়ে সাধারণ প্রশ্ন
PRD আর BRD-এর মধ্যে পার্থক্য কী?
BRD সাধারণত ব্যবসায়িক সমস্যা, উদ্দেশ্য ও উচ্চপর্যায়ের চাহিদার দিকে বেশি নজর দেয়।
PRD সেই ব্যবসায়িক প্রেক্ষাপট থেকে ব্যবহারকারীর জন্য পণ্য কী দেবে, কোন কাজের সীমার মধ্যে দেবে এবং সাফল্য কীভাবে মাপা হবে—এসব পরিষ্কার করে।
তবে প্রতিষ্ঠানভেদে এই দুই নথির সীমা আলাদা হতে পারে।
ছোট দলের জন্যও কি PRD দরকার?
হ্যাঁ, তবে বড় আনুষ্ঠানিক নথি সব সময় দরকার হয় না।
ছোট startup বা নতুন প্রতিষ্ঠানের দলের জন্য সমস্যা, লক্ষ্য, কাজের সীমা, মূল চাহিদা, গুরুত্বপূর্ণ ব্যতিক্রমী পরিস্থিতি এবং সাফল্যের মাপকাঠি নিয়ে এক পাতার PRD যথেষ্ট হতে পারে।
নথির আকার দলের সদস্যসংখ্যা দিয়ে নয়, কাজের জটিলতা ও অস্পষ্টতা দিয়ে ঠিক করা ভালো।
নির্মাণকাজ শুরু হওয়ার আগে কি PRD পুরোপুরি চূড়ান্ত করতে হবে?
মূল কাজের সীমা ও চাহিদা নিয়ে যথেষ্ট বোঝাপড়া নির্মাণ শুরু হওয়ার আগে থাকা উচিত।
তবে PRD-কে অপরিবর্তনীয় নথি ভাবা ঠিক নয়।
নতুন তথ্য পাওয়া, প্রযুক্তিগত সীমাবদ্ধতা ধরা পড়া বা সিদ্ধান্ত বদলানোর কারণে PRD হালনাগাদ হতে পারে। গুরুত্বপূর্ণ বিষয় হলো, সেই পরিবর্তন যেন পুরো দলের কাছে দৃশ্যমান থাকে।
PRD-তে user story ও acceptance criteria রাখা কি বাধ্যতামূলক?
না। PRD-এর জন্য একটিমাত্র বাধ্যতামূলক কাঠামো নেই।
তবে user story ব্যবহারকারীর উদ্দেশ্য বোঝাতে এবং acceptance criteria বা গ্রহণযোগ্যতার শর্ত “কাজ শেষ” বলতে কী বোঝায়, তা পরিষ্কার করতে বেশ কার্যকর।
ছোট ফিচারে কয়েকটি পরিষ্কার চাহিদাই যথেষ্ট হতে পারে। জটিল ব্যবহারপ্রবাহে user story ও গ্রহণযোগ্যতার শর্ত বেশি কাজে আসে।
ভালো PRD-এর শেষ পরীক্ষা: “কাজ শেষ” বলতে সবাই কি একই জিনিস বোঝে?
শুরুর সেই স্প্রিন্টের ঘটনায় ফিরে আসি।
ডেভেলপার ফিচারটি বানিয়েছেন লগইন করা ব্যবহারকারীর জন্য। ব্যবসায়িক অংশীজন ভেবেছেন, লগইন না করা ব্যবহারকারীও এটি ব্যবহার করতে পারবেন। প্রোডাক্ট ম্যানেজার ধরে নিয়েছেন, বিষয়টি সবার কাছেই পরিষ্কার।
এই ভুল আটকাতে কোনো জটিল কাঠামোর দরকার ছিল না।
PRD-এর কাজের সীমায় একটি বাক্যই যথেষ্ট হতে পারত:
এখনকার কাজের বাইরে: MVP প্রকাশে লগইন না করা ব্যবহারকারী এই ফিচার ব্যবহার করতে পারবেন না।
অথবা লগইন না করা ব্যবহারকারীও ফিচারটি ব্যবহার করতে পারলে গ্রহণযোগ্যতার শর্তে লেখা যেত:
লগইন করা ও লগইন না করা—দুই ধরনের ব্যবহারকারীই পুরো প্রক্রিয়া সম্পন্ন করতে পারবেন।
একটি ভালো Product Requirement Document বা PRD-এর শক্তি এখানেই।
এটি শুধু নথি লেখার কাজ নয়। এটি এমন সব অস্পষ্টতা আগে বের করে আনার পদ্ধতি, যেগুলো পরে স্প্রিন্ট থামিয়ে দিতে পারে বা তৈরি হয়ে যাওয়া কাজ আবার করতে বাধ্য করতে পারে।
তাই পরেরবার PRD লেখার সময় নিখুঁত template খোঁজার আগে একটি পরিষ্কার সমস্যার বিবরণ লিখুন। এরপর লক্ষ্য, কাজের সীমা, প্রত্যাশিত আচরণ এবং “কাজ শেষ” বলতে কী বোঝাচ্ছেন, তা এমনভাবে লিখুন যেন প্রোডাক্ট, ডিজাইন, প্রকৌশল দল ও ব্যবসায়িক অংশীজন সবাই একই জিনিস কল্পনা করেন।
PRD তখনই সত্যিকারের কাজে দিচ্ছে, যখন কঠিন প্রশ্নগুলো স্প্রিন্ট শুরুর আগেই উঠে আসছে—দ্বিতীয় সপ্তাহে নয়।
