নতুন একজন সদস্য দলে যোগ দিয়ে একদিন খুব সাধারণ একটি প্রশ্ন করলেন, “আমরা এই ফিচারটা বাদ দিয়েছিলাম কেন?”
যারা কয়েক মাস আগে সেই আলোচনায় ছিলেন, তাঁদের একজন বললেন, “সম্ভবত কাজটা অনেক বড় হয়ে যাচ্ছিল।” আরেকজনের মনে হলো, কোনো stakeholder তখন আপত্তি করেছিলেন। তৃতীয়জন বললেন, “না, আমার যত দূর মনে পড়ে, ব্যবহারকারীদের সত্যিই এটা দরকার কি না, সেই সন্দেহটাই বড় ছিল।”
সমস্যা হলো, তিনটি কথাই হয়তো কিছুটা সত্য। কিন্তু আসল কারণটি আর কারও স্পষ্ট মনে নেই।
ফলে যে সিদ্ধান্ত নিয়ে আগেই ঘণ্টার পর ঘণ্টা আলোচনা হয়েছিল, সেটাই আবার নতুন করে শুরু হলো। পুরোনো যুক্তি নেই, আগের বিকল্পগুলো নেই, কোন ছাড় মেনে সিদ্ধান্তটি নেওয়া হয়েছিল সেটাও নেই।
একটি ভালো Product Decision Log ঠিক এই জায়গাতেই কাজে আসে। এটি সভার প্রতিটি কথা লিখে রাখার খাতা নয়। বরং গুরুত্বপূর্ণ product decision-এর পেছনের কারণ, পরিস্থিতি ও বিবেচনাগুলো এমনভাবে ধরে রাখা, যাতে কয়েক মাস পরেও দল বুঝতে পারে—তখন সিদ্ধান্তটি কেন যৌক্তিক মনে হয়েছিল।
Product Decision Log আসলে কী?
Product Decision Log হলো গুরুত্বপূর্ণ প্রোডাক্ট সিদ্ধান্তগুলোর ধারাবাহিক ও সংক্ষিপ্ত নথি।
এখানে সাধারণত লেখা থাকে—কী সিদ্ধান্ত নেওয়া হয়েছে, কেন নেওয়া হয়েছে, কোন বিকল্পগুলো বিবেচনায় ছিল, কারা আলোচনায় ছিলেন, কখন সিদ্ধান্তটি হয়েছে এবং কী ফল আশা করা হয়েছিল।
এটি বড় কোনো প্রতিবেদন নয়। বেশির ভাগ ক্ষেত্রেই কয়েকটি অনুচ্ছেদ যথেষ্ট।
ভালো Decision Log মূলত সিদ্ধান্তের স্মৃতি ধরে রাখে। বিশেষ করে সেই অংশটি, যা কাজের তালিকা, প্রোডাক্ট রোডম্যাপ বা সভার নোটে প্রায়ই হারিয়ে যায়—কেন এই সিদ্ধান্ত নেওয়া হয়েছিল।
Decision Log কেন Team-এর জন্য এত গুরুত্বপূর্ণ?
প্রোডাক্ট টিমে গুরুত্বপূর্ণ সিদ্ধান্ত সাধারণত একটি মাত্র কারণে নেওয়া হয় না।
ব্যবহারকারীর প্রয়োজন আছে। ব্যবসার লক্ষ্য আছে। সময়ের সীমা আছে। প্রযুক্তিগত জটিলতা আছে। কখনো বাজেটের সীমাবদ্ধতা থাকে, কখনো আবার কোনো stakeholder দ্রুত কিছু চাইছেন। এসবকিছুর মধ্যে ভারসাম্য করেই একটি সিদ্ধান্ত আসে।
কিন্তু কিছুদিন পর সেই পুরো আলোচনাটি প্রায়ই একটি বাক্যে এসে ঠেকে।
“মোবাইল অ্যাপ এখন করছি না।”
“ফ্রি প্ল্যানে এক্সপোর্ট থাকবে না।”
“এই পর্যায়ে রিপোর্টিং ফিচারটি বাদ।”
বাক্যগুলো বলে কী সিদ্ধান্ত হয়েছিল। কিন্তু বলে না কেন হয়েছিল।
ধরা যাক, একটি টিম প্রথম সংস্করণে একসঙ্গে অনেক তথ্য আমদানির সুবিধা দেবে না বলে ঠিক করেছিল। কারণ তখনকার পর্যবেক্ষণে দেখা গিয়েছিল, মূল ব্যবহারকারীরা তুলনামূলক ছোট তথ্যসেট নিয়ে কাজ করছেন। আবার এই সুবিধাটি যোগ করতে গেলে বাজারে পণ্য ছাড়তে দেরি হতে পারত।
চার মাস পরে বড় একটি সম্ভাব্য গ্রাহক একই সুবিধা চাইলেন।
পুরোনো সিদ্ধান্তে যদি শুধু লেখা থাকে—“প্রথম সংস্করণে এটি থাকবে না”—তাহলে নতুন আলোচনায় মনে হতে পারে, টিম কোনো শক্ত কারণ ছাড়াই ফিচারটি বাদ দিয়েছিল।
কিন্তু Decision Log-এ যদি লেখা থাকে—“বর্তমান লক্ষ্য ব্যবহারকারীদের জন্য জরুরিতা কম; তৈরি করতে সময় বেশি লাগবে; পণ্য প্রকাশ পিছিয়ে না দিতে আপাতত বাদ”—তাহলে আলোচনা অন্য জায়গা থেকে শুরু হবে।
তখন আর প্রশ্ন হবে না, “আমরা এটা করিনি কেন?”
বরং প্রশ্ন হবে, “আগের যে ধারণাগুলোর ওপর সিদ্ধান্তটি দাঁড়িয়েছিল, সেগুলো কি এখনও ঠিক আছে?”
এই পার্থক্যটাই গুরুত্বপূর্ণ।
সিদ্ধান্তের ফল নয়, কারণটাও ধরে রাখা দরকার
রোডম্যাপ দেখে বোঝা যায় কী করা হচ্ছে।
কাজের তালিকায় বোঝা যায় কী বাকি।
ব্যবহারসংক্রান্ত তথ্য দেখে বোঝা যায় মানুষ কী করছেন।
কিন্তু “আমরা কেন এই পথটি বেছে নিয়েছিলাম?”—এই প্রশ্নের উত্তর এসব জায়গায় সব সময় পাওয়া যায় না।
তাই ভালো ডকুমেন্টেশন শুধু চূড়ান্ত সিদ্ধান্ত ধরে রাখে না। সিদ্ধান্তের সময়কার পরিস্থিতিটাও ধরে রাখে।
ধরা যাক, দুটি নকশা নিয়ে আলোচনা হচ্ছিল।
প্রথমটি ব্যবহারকারীর জন্য সহজ, কিন্তু তৈরি করতে তিন সপ্তাহ বেশি সময় লাগবে। দ্বিতীয়টি কিছুটা সীমিত, কিন্তু নির্দিষ্ট সময়ের মধ্যে পণ্য প্রকাশ করা সম্ভব।
টিম দ্বিতীয়টি নিল।
এক বছর পরে কেউ ওই পর্দাটি দেখে বলতে পারেন, “এত সীমিত করে বানানো হয়েছিল কেন?”
Decision Log থাকলে বোঝা যাবে, এটি কোনো ভুল বা অসাবধানতার ফল ছিল না। নির্দিষ্ট পরিস্থিতিতে সময়ের চাপ মেনে সচেতনভাবে একটি ছাড় দেওয়া হয়েছিল।
আবার এটাও হতে পারে, এখন আর সেই ছাড়ের দরকার নেই।
Decision Log পুরোনো সিদ্ধান্তকে অপরিবর্তনীয় বানায় না। বরং পুরোনো সিদ্ধান্তটি নতুন করে বিচার করার জন্য প্রয়োজনীয় প্রেক্ষাপট দেয়।
মানুষের স্মৃতির ওপর প্রোডাক্টের ইতিহাস রেখে দেওয়া ঠিক নয়
প্রায় সব টিমেই এমন দুই-একজন মানুষ থাকেন, যাঁদের কাছে সবাই পুরোনো সিদ্ধান্তের ব্যাখ্যা জানতে যান।
“এই ফিচারটা এমন কেন?” — তিনি জানেন।
“মূল্য নির্ধারণের নিয়ম কেন বদলেছিল?” — তিনিই জানেন।
“এই সংযোগটি কেন বন্ধ হয়েছিল?” — পুরোনো প্রকৌশলপ্রধান হয়তো জানেন।
যত দিন সবাই একই দায়িত্বে আছেন, তত দিন ব্যবস্থা কোনোভাবে চলে।
সমস্যা শুরু হয় যখন কেউ অন্য দলে চলে যান, চাকরি বদলান, দীর্ঘ ছুটিতে যান অথবা কয়েক মাস আগের আলোচনার সূক্ষ্ম বিষয়গুলো ভুলে যান।
মানুষ ভুলে যায়। এটিই স্বাভাবিক।
তাই গুরুত্বপূর্ণ সিদ্ধান্ত যদি শুধু কয়েকজনের মাথায় থাকে, সেটিকে দলের জ্ঞান বলা কঠিন। বরং সেটি কয়েকজন ব্যক্তির স্মৃতির ওপর নির্ভরশীল জ্ঞান।
Decision Log সেই জ্ঞানকে মানুষের মাথা থেকে দলের নথিতে নিয়ে আসে।
এর মানে এই নয় যে প্রতিটি ছোট আলোচনা লিখে রাখতে হবে। লিখতে হবে সেই সিদ্ধান্তগুলো, যেগুলো পরে আবার প্রশ্ন হয়ে ফিরে আসতে পারে।
নতুন সদস্যের অনবোর্ডিং অনেক সহজ হয়
নতুন কোনো প্রোডাক্ট ম্যানেজার, ডিজাইনার বা প্রকৌশলী দলে যোগ দিলে তাঁকে অল্প সময়ের মধ্যে অনেক কিছু বুঝতে হয়।
বর্তমান রোডম্যাপ কী?
কোন ব্যবহারকারীদের জন্য পণ্যটি?
কোন সমস্যা এখন সবচেয়ে গুরুত্বপূর্ণ?
কোন কাজ কেন আটকে আছে?
কিন্তু একটি পণ্য আজ যেখানে দাঁড়িয়ে আছে, সেখানে শুধু বর্তমান ফিচার দেখে পৌঁছানো যায় না। এর পেছনে অনেক পুরোনো সিদ্ধান্ত থাকে।
কেন একটি নির্দিষ্ট গ্রাহকগোষ্ঠীকে বেশি গুরুত্ব দেওয়া হয়েছে?
কেন প্রতিদ্বন্দ্বী প্রতিষ্ঠানের জনপ্রিয় একটি ফিচার নকল করা হয়নি?
কেন নতুন ব্যবহারকারীর জন্য একটি নির্দিষ্ট ধাপ রাখা হয়েছে?
কেন কোনো পুরোনো প্ল্যান এখনও চালু আছে?
নতুন সদস্য যদি প্রতিটি প্রশ্নের উত্তর পেতে আলাদা আলাদা মানুষের কাছে যান, তাহলে অনবোর্ডিং ধীর হয়ে যায়। একই সঙ্গে তিনি এমন ব্যাখ্যা পান, যা ব্যক্তিভেদে বদলে যেতে পারে।
Decision Log এখানে ছোট কিন্তু খুব কার্যকর একটি ইতিহাসের মতো কাজ করে।
বড় কোনো নির্দেশিকা নয়। বরং গুরুত্বপূর্ণ মোড়গুলো কেন এসেছিল, তার সংক্ষিপ্ত ব্যাখ্যা।
এতে নতুন সদস্য আগের সব সিদ্ধান্তের সঙ্গে একমত হবেন—এমন নয়। বরং তিনি দ্রুত বুঝতে পারবেন, বর্তমান প্রোডাক্ট স্ট্র্যাটেজি কোন ধারণা ও সীমাবদ্ধতার ওপর দাঁড়িয়ে আছে।
তারপর তিনি ভালো প্রশ্ন করতে পারবেন।
একই সিদ্ধান্ত বারবার নতুন করে তোলার প্রবণতা কমে
এটি Decision Log-এর সবচেয়ে চোখে পড়ার মতো সুবিধাগুলোর একটি।
ধরা যাক, একটি টিম তিন মাস আগে মূল্য নির্ধারণ নিয়ে দীর্ঘ আলোচনা করেছে। বিভিন্ন পক্ষ মত দিয়েছে। শেষ পর্যন্ত সিদ্ধান্তও হয়েছে।
কিন্তু সিদ্ধান্তটির কারণ কোথাও পরিষ্কারভাবে লেখা হয়নি।
কিছুদিন পর নতুন stakeholder একই প্রশ্ন তুললেন। আগের সভায় থাকা কেউ বললেন, “এটা নিয়ে আমরা আগেই আলোচনা করেছি।”
কিন্তু তারপরই প্রশ্ন আসে—“কেন এই সিদ্ধান্ত হয়েছিল?”
সঠিক উত্তর কারও মনে নেই।
আলোচনা আবার শুরু।
এখানে stakeholder প্রশ্ন করেছেন, সেটি সমস্যা নয়। নতুন তথ্য এলে পুরোনো সিদ্ধান্ত অবশ্যই বদলানো যেতে পারে।
সমস্যা হচ্ছে, নতুন তথ্য ছাড়া শুধু পুরোনো যুক্তি হারিয়ে যাওয়ার কারণে একই বিতর্ক শূন্য থেকে শুরু হচ্ছে।
ভালো Decision Log আলোচনা বন্ধ করে না। বরং আলোচনার শুরুটা ঠিক করে দেয়।
“আগেরবার আমরা এই তিনটি কারণে দ্বিতীয় বিকল্পটি নিয়েছিলাম। এখন এর মধ্যে কোন কারণটি বদলেছে?”
এই প্রশ্নের উত্তর পাওয়া গেলে আলোচনাও অনেক বেশি ফলপ্রসূ হয়।
Retrospective তখন দোষ খোঁজার জায়গা না হয়ে শেখার জায়গা হয়
কোনো সিদ্ধান্ত প্রত্যাশামতো ফল না দিলে পরে সবাই খুব সহজে বলতে পারেন, “এটা তো আগেই বোঝা উচিত ছিল।”
ফল জেনে যাওয়ার পর পুরোনো সিদ্ধান্তকে বিচার করা সহজ।
কিন্তু সিদ্ধান্তটি যখন নেওয়া হয়েছিল, তখন টিম কী জানত?
কী জানত না?
কোন ফল আশা করেছিল?
কোন ঝুঁকিগুলো জেনেও মেনে নিয়েছিল?
Decision Log এগুলো ধরে রাখে।
ধরা যাক, টিম একটি সহজ checkout প্রক্রিয়া চালু করেছিল এবং ধারণা করেছিল এতে মাঝপথে ব্যবহারকারী হারিয়ে যাওয়া কমবে। পরে দেখা গেল, প্রত্যাশিত পরিবর্তন এলো না।
শুধু ফলাফল দেখে “সিদ্ধান্ত ভুল ছিল” বলা সহজ।
কিন্তু Decision Log দেখে বোঝা যায়—তখনকার অনুমানটি কি যুক্তিসংগত ছিল? প্রয়োজনীয় তথ্য কি কম ছিল? নাকি সিদ্ধান্ত ঠিক ছিল, কিন্তু বাস্তবায়নে সমস্যা হয়েছিল?
Retrospective-এ এই পার্থক্য খুব দরকারি।
কারণ শেখার উদ্দেশ্য যদি থাকে, তাহলে শুধু “কী ভুল হলো” জানা যথেষ্ট নয়। “তখন আমরা কী ভেবেছিলাম” সেটাও জানতে হয়।
Stakeholder-এর সঙ্গে স্বচ্ছতা বাড়ে
প্রোডাক্ট টিমে সবাই একই জিনিস চান না।
বিক্রয় দল হয়তো বড় গ্রাহকের জন্য নতুন ফিচার চায়। বিপণন দল দ্রুত বাজারে কিছু আনতে চায়। প্রকৌশল দল পুরোনো প্রযুক্তিগত সমস্যা কমাতে চায়। নেতৃত্ব আয় বা প্রবৃদ্ধির দিকে তাকিয়ে থাকে।
এ অবস্থায় প্রোডাক্ট ম্যানেজার যদি শুধু বলেন, “এই ফিচার এখন করছি না,” তাহলে সিদ্ধান্তটি অনেকের কাছে খামখেয়ালি মনে হতে পারে।
কিন্তু যদি কারণটিও দৃশ্যমান থাকে, কথাটা অন্যরকম শোনায়।
যেমন—
“ফিচারটি বিবেচনা করা হয়েছে। তবে এই পর্যায়ে নতুন ব্যবহারকারীর সক্রিয়তা বাড়ানোকে অগ্রাধিকার দেওয়া হচ্ছে, কারণ সেটি বর্তমান ব্যবসায়িক লক্ষ্যের সঙ্গে বেশি সরাসরি যুক্ত।”
সবাই সিদ্ধান্তটি পছন্দ করবেন, এমন নিশ্চয়তা নেই।
কিন্তু অন্তত বোঝা যাবে যে সিদ্ধান্তটি কোনো ব্যক্তিগত পছন্দ বা মুহূর্তের আবেগ থেকে আসেনি।
এই জায়গায় টিম কমিউনিকেশন, স্বচ্ছতা এবং জবাবদিহির সম্পর্ক তৈরি হয়।
Decision Log কাউকে দায়ী করার খাতা নয়।
“এই ভুলটি অমুক করেছিলেন”—এমন ব্যবহারে মানুষ খুব দ্রুত সৎভাবে সিদ্ধান্তের কারণ লিখতে আগ্রহ হারাবে।
এর উদ্দেশ্য হওয়া উচিত—কে আলোচনায় ছিলেন, তখন কী তথ্য ছিল, কোন বিকল্প বিবেচনায় ছিল এবং কেন একটি পথ বেছে নেওয়া হয়েছিল তা দৃশ্যমান রাখা।
Decision Log রাখার মূল সুবিধা
| সুবিধা | সংক্ষিপ্ত ব্যাখ্যা |
| সিদ্ধান্তের কারণ সংরক্ষণ | শুধু কী সিদ্ধান্ত হয়েছিল নয়, কেন হয়েছিল সেটিও বোঝা যায় |
| একই বিতর্ক কমানো | আগের যুক্তি সামনে থাকায় আলোচনা শূন্য থেকে শুরু করতে হয় না |
| নতুন সদস্যকে দ্রুত বোঝানো | পুরোনো গুরুত্বপূর্ণ সিদ্ধান্তের ইতিহাস সহজে জানা যায় |
| Retrospective ভালো করা | তখনকার ধারণা, প্রত্যাশা ও ঝুঁকি নতুন করে দেখা যায় |
| Stakeholder-এর কাছে স্বচ্ছতা | অগ্রাধিকার ও ছাড়ের কারণ পরিষ্কার থাকে |
| ব্যক্তিনির্ভর স্মৃতি কমানো | গুরুত্বপূর্ণ তথ্য কয়েকজনের মাথায় আটকে থাকে না |
| প্রোডাক্ট স্ট্র্যাটেজির ধারাবাহিকতা | পুরোনো ও নতুন সিদ্ধান্তের সম্পর্ক বোঝা সহজ হয় |
সবচেয়ে বড় লাভ সম্ভবত টেবিলের কোনো একক সারিতে নেই।
লাভটি হলো—টিম নিজের সিদ্ধান্তের ইতিহাস হারায় না।
একটি প্রোডাক্ট যত পুরোনো হয়, এই ইতিহাস তত মূল্যবান হয়ে ওঠে। কারণ বর্তমান পণ্যটি শুধু আজকের রোডম্যাপের ফল নয়; বহু আগের অসংখ্য সিদ্ধান্ত ও ছাড়ের ফল।
Decision Log-এ কী কী তথ্য রাখা উচিত?
ভালো একটি Decision Log entry এমন হওয়া উচিত, যা পড়ে সেই মানুষও সিদ্ধান্তটি বুঝতে পারবেন, যিনি সভায় ছিলেন না।
এর জন্য বড় ছক দরকার নেই।
বরং ছক যত সহজ রাখা যায়, নিয়মিত লেখার সম্ভাবনা তত বেশি।
| উপাদান | কেন প্রয়োজন |
| তারিখ | কোন সময়ের পরিস্থিতিতে সিদ্ধান্তটি হয়েছিল তা বোঝার জন্য |
| সমস্যা বা প্রেক্ষাপট | কোন প্রশ্ন বা সমস্যার উত্তর হিসেবে সিদ্ধান্তটি এসেছে তা জানায় |
| বিবেচিত বিকল্প | অন্য কী কী পথ সামনে ছিল তা বোঝায় |
| চূড়ান্ত সিদ্ধান্ত | শেষ পর্যন্ত কী করা হবে সেটি পরিষ্কার করে |
| সিদ্ধান্তের কারণ | কেন এই পথটি নেওয়া হয়েছে তার ব্যাখ্যা দেয় |
| কারা যুক্ত ছিলেন | কোন কোন ভূমিকার মানুষ আলোচনায় ছিলেন তা বোঝায় |
| প্রত্যাশিত ফল | সিদ্ধান্তটি থেকে কী পরিবর্তন আশা করা হয়েছিল তা ধরে রাখে |
| পরে কী হয়েছে | সিদ্ধান্তটি বদলানো, বাতিল বা পুনর্বিবেচিত হলে তা জানায় |
এখানে বিকল্পগুলো লিখে রাখা বিশেষভাবে উপকারী।
শুধু “প্রথম বিকল্পটি নেওয়া হয়েছে” লিখলে ভবিষ্যতের পাঠক জানবেন না, দ্বিতীয় বিকল্পটি কখনো আলোচনায় এসেছিল কি না।
কিন্তু যদি লেখা থাকে—“প্রথম বিকল্পটি নেওয়া হয়েছে; দ্বিতীয়টি বাস্তবায়নের সময় ও তথ্য স্থানান্তরের ঝুঁকির কারণে আপাতত বাদ”—তাহলে পুরো বিষয়টি অনেক পরিষ্কার হয়।
প্রত্যাশিত ফলটিও লিখে রাখা ভালো।
কারণ পরে যখন সিদ্ধান্তটি ফিরে দেখা হবে, তখন টিম তুলনা করতে পারবে—আমরা কী আশা করেছিলাম, আর বাস্তবে কী হয়েছে?
জানেন কি? Architecture Decision Records থেকেও ধারণা নেওয়া যায়
সফটওয়্যার প্রকৌশলে আর্কিটেকচার ডিসিশন রেকর্ডস (Architecture Decision Records বা ADR) নামে একটি পরিচিত হালকা নথিবদ্ধকরণ পদ্ধতি আছে। গুরুত্বপূর্ণ স্থাপত্যগত সিদ্ধান্তের প্রেক্ষাপট, সিদ্ধান্ত ও তার সম্ভাব্য ফল ছোট নথিতে ধরে রাখাই এর মূল ধারণা।
এই পদ্ধতিটি সাধারণভাবে মাইকেল নাইগার্ডের নামের সঙ্গে যুক্ত বলে পরিচিত।
Product Decision Log এবং ADR একই জিনিস নয়। তবে একটি ধারণা দুই ক্ষেত্রেই কাজে লাগে—লম্বা প্রতিবেদন না লিখে গুরুত্বপূর্ণ সিদ্ধান্তের পেছনের যুক্তিটুকু এমনভাবে রাখা, যাতে পরে সেটি বোঝা যায়।
Product Decision Log কীভাবে এমনভাবে রাখবেন, যাতে ছয় মাস পরও Team ব্যবহার করে?
Decision Log শুরু করা খুব কঠিন নয়।
চালু রাখা কঠিন।
প্রথম সপ্তাহে টিম হয়তো খুব আগ্রহ নিয়ে একটি সুন্দর নথি বানাল। আলাদা ঘর আছে, বিভাগ আছে, মালিকের নাম আছে, অবস্থা আছে।
দুই সপ্তাহ সবাই লিখল।
তারপর ধীরে ধীরে নতুন entry আসা বন্ধ হয়ে গেল।
এমনটা প্রায়ই হয়, কারণ নথি রাখার পদ্ধতি আসল কাজের চেয়ে বেশি ভারী হয়ে যায়।
এন্ট্রি ছোট রাখুন
একটি সিদ্ধান্ত লিখে রাখতে যদি আধা ঘণ্টা লাগে, মানুষ সভা শেষে বলবে, “পরে লিখব।”
আর “পরে লিখব” অনেক সময় “আর লেখা হবে না”-তে গিয়ে শেষ হয়।
একটি সাধারণ Decision Log entry এমন হতে পারে:
প্রেক্ষাপট: বিনা মূল্যের পরীক্ষামূলক সময় শুরু করতে কার্ডের তথ্য চাওয়া ব্যবহারকারীর জন্য বাধা তৈরি করছে কি না, তা নিয়ে আলোচনা।
সিদ্ধান্ত: আপাতত নতুন ব্যবহারকারীর পরীক্ষামূলক ব্যবহার শুরু করতে কার্ডের তথ্য বাধ্যতামূলক রাখা হবে না।
কারণ: এখন মূল লক্ষ্য বেশি মানুষকে পণ্যটি ব্যবহার শুরু করানো। অর্থপ্রদানের তথ্য আগেই নেওয়ার সুবিধার তুলনায় শুরু করার বাধা কমানোকে বেশি গুরুত্বপূর্ণ ধরা হয়েছে।
অন্য বিকল্প: কার্ডের তথ্য বাধ্যতামূলক রাখা অথবা শুধু নির্দিষ্ট ব্যবহারকারী গোষ্ঠীর জন্য নিয়ম শিথিল করা।
প্রত্যাশিত ফল: আরও বেশি উপযুক্ত ব্যবহারকারী পরীক্ষামূলক ব্যবহার শুরু করবেন। অপব্যবহারের ঝুঁকি আলাদাভাবে পর্যবেক্ষণ করা হবে।
এটি কোনো প্রবন্ধ নয়।
কিন্তু ছয় মাস পরে “আমরা কার্ডের তথ্য নেওয়া বন্ধ করেছিলাম কেন?”—এই প্রশ্নের উত্তর দেওয়ার মতো তথ্য এখানে আছে।
আলাদা কাজ না বানিয়ে পরিচিত কাজের সঙ্গে জুড়ে দিন
“প্রতি শুক্রবার সবাই Decision Log হালনাগাদ করবে”—কাগজে ভালো শোনায়।
বাস্তবে শুক্রবার আরও অনেক কাজ থাকে। নথি লেখা পিছিয়ে যায়।
তার চেয়ে গুরুত্বপূর্ণ সিদ্ধান্ত হওয়ার পরপরই লিখে রাখার অভ্যাস বেশি কার্যকর।
যেমন, গুরুত্বপূর্ণ সভা শেষ হওয়ার পর কাজের তালিকা লেখার সময় Decision Log entry তৈরি হলো।
রোডম্যাপে অগ্রাধিকার বদলানোর সময় তার কারণটিও লেখা হলো।
ফিচার বাদ দেওয়ার সিদ্ধান্তের সঙ্গে সঙ্গে সংশ্লিষ্ট নথির লিংক যোগ হলো।
অর্থাৎ Decision Log-কে আলাদা প্রশাসনিক কাজ না বানিয়ে প্রোডাক্ট ডিসিশন মেকিং-এর শেষ ধাপ বানান।
সিদ্ধান্ত হলো।
তারপর লেখা হলো।
বিষয়টি এতটাই সহজ রাখা ভালো।
একজন দায়িত্বশীল মানুষ থাকা দরকার
“সবাই লিখবে” ধরনের নিয়মের সমস্যা হলো, শেষ পর্যন্ত কেউ নিশ্চিতভাবে লেখে না।
তাই অন্তত একজন মানুষকে দায়িত্ব নিতে হবে—সিদ্ধান্তটি নথিভুক্ত হয়েছে কি না সেটি দেখার জন্য।
তিনি প্রোডাক্ট ম্যানেজার হতে পারেন। সভা পরিচালনাকারী হতে পারেন। আবার সিদ্ধান্তের ধরন অনুযায়ী অন্য কেউও হতে পারেন।
এর মানে এই নয় যে তিনিই একা সিদ্ধান্তের কারণ লিখবেন বা নিজের মতো করে ব্যাখ্যা করবেন।
তাঁর কাজ হলো, গুরুত্বপূর্ণ সিদ্ধান্তটি যেন হারিয়ে না যায়।
বিশেষ করে stakeholder-সংবেদনশীল কোনো সিদ্ধান্ত হলে সংশ্লিষ্ট মানুষদের দিয়ে দ্রুত দেখে নেওয়া যেতে পারে—কারও মত ভুলভাবে লেখা হয়েছে কি না।
সব সিদ্ধান্ত Decision Log-এ ঢোকাবেন না
এই জায়গাটিতেই অনেক ভালো উদ্যোগ নষ্ট হয়।
একদিন বোতামের লেখা “Continue” হবে না “Next”—সেটাও লেখা হলো।
পরের দিন কে কোন ছোট কাজ করবেন—সেটাও লেখা হলো।
তারপর একসময় Decision Log এত বড় হয়ে গেল যে গুরুত্বপূর্ণ সিদ্ধান্ত খুঁজে বের করাই কঠিন।
Decision Log হলো গুরুত্বপূর্ণ সিদ্ধান্তের ইতিহাস।
দলের প্রতিটি ছোট ঘটনার রেকর্ড নয়।
একটি সিদ্ধান্ত সত্যিই লিখে রাখা দরকার কি না বুঝতে কয়েকটি প্রশ্ন নিজেকে করা যায়।
সিদ্ধান্তটি পরে বদলানো কঠিন হবে কি?
একাধিক বাস্তব বিকল্প ছিল কি?
কয়েক মাস পরে কেউ “কেন?” প্রশ্নটি করার সম্ভাবনা আছে কি?
এতে প্রোডাক্ট স্ট্র্যাটেজি, মূল্য নির্ধারণ, ব্যবহারকারীর অভিজ্ঞতা, লক্ষ্য গ্রাহক বা বড় কোনো অগ্রাধিকার বদলাচ্ছে কি?
একাধিক stakeholder-এর মধ্যে মতভেদ ছিল কি?
এসবের কোনো একটির উত্তর “হ্যাঁ” হলে সিদ্ধান্তটি লিখে রাখা যুক্তিযুক্ত।
কোন সিদ্ধান্ত Log করা উচিত বনাম কোনটা দরকার নেই
| সিদ্ধান্তের ধরন | উদাহরণ | Log করা উচিত কিনা |
| বড় প্রোডাক্ট কৌশল বদল | ছোট ব্যবসার বদলে বড় প্রতিষ্ঠানের গ্রাহকদের অগ্রাধিকার দেওয়া | হ্যাঁ |
| গুরুত্বপূর্ণ ফিচার বাদ বা পিছিয়ে দেওয়া | মোবাইল অ্যাপ পরের পর্যায়ে নেওয়া | হ্যাঁ |
| মূল্য বা প্যাকেজে পরিবর্তন | ফ্রি প্ল্যানের ব্যবহারসীমা বদলানো | হ্যাঁ |
| বড় ধরনের ছাড় মেনে সিদ্ধান্ত | দ্রুত প্রকাশের জন্য কিছু সুবিধা সীমিত রাখা | হ্যাঁ |
| দীর্ঘমেয়াদি প্রযুক্তিগত সীমাবদ্ধতা | পুরোনো ইন্টিগ্রেশন সমর্থন বন্ধ করা | সাধারণত হ্যাঁ |
| বারবার প্রশ্ন ওঠে এমন সিদ্ধান্ত | কেন একটি নির্দিষ্ট কাজের ধাপ রাখা হয়েছে | হ্যাঁ |
| ছোট ও সহজে বদলানো নকশা | একটি আইকনের অবস্থান সামান্য বদলানো | সাধারণত না |
| দৈনন্দিন কাজ ভাগ | কে কোন টিকিট নেবেন | না |
| অস্থায়ী সভার পরিবর্তন | পরের সপ্তাহের সভা এক দিন পিছোনো | না |
| ছোট লেখার পরিবর্তন | সহায়ক বাক্যের শব্দ বদলানো | সাধারণত না |
তবে এটিকে কঠোর নিয়ম ভাবার দরকার নেই।
একটি ছোট নকশার সিদ্ধান্তও গুরুত্বপূর্ণ হতে পারে, যদি সেটি আইনগত বাধ্যবাধকতা, প্রবেশগম্যতা বা বড় কোনো ব্যবসায়িক অনুমানের সঙ্গে যুক্ত থাকে।
তাই সিদ্ধান্তটি দেখতে কত ছোট, সেটি নয়—তার প্রভাব কতটা, সেটি দেখুন।
পুরোনো সিদ্ধান্ত মুছে ফেলবেন না
Decision Log-এর আরেকটি গুরুত্বপূর্ণ দিক হলো—পুরোনো সিদ্ধান্ত বদলালে তার ইতিহাসটিও রেখে দেওয়া।
ধরা যাক, আট মাস আগে টিম ঠিক করেছিল আলাদা মোবাইল অ্যাপ বানাবে না। কারণ তখন বেশির ভাগ ব্যবহারকারী ওয়েব থেকেই কাজ করছিলেন।
পরে পরিস্থিতি বদলাল।
মোবাইল ব্যবহার বাড়ল। গ্রাহকের অনুরোধ জমতে থাকল। ব্যবসার অগ্রাধিকারও পাল্টে গেল।
এখন টিম সিদ্ধান্ত নিল মোবাইল অ্যাপ বানাবে।
পুরোনো entry মুছে দেওয়ার দরকার নেই।
বরং সেখানে লিখে রাখা যায়—পুনর্বিবেচিত, পরিবর্তিত বা নতুন সিদ্ধান্তে প্রতিস্থাপিত।
তার সঙ্গে নতুন সিদ্ধান্তের লিংক দেওয়া যায়।
তাহলে পরে কেউ দেখলে বুঝবে, টিম নিজের কথার সঙ্গে নিজেই বিরোধ করছিল না। পরিস্থিতি বদলেছে, তাই সিদ্ধান্তও বদলেছে।
প্রোডাক্ট ম্যানেজমেন্টে এটি খুবই স্বাভাবিক।
Decision Log রাখতে গিয়ে যে ভুলগুলো বেশি হয়
সবচেয়ে পরিচিত ভুল হলো, নথির ছক এত বড় বানানো যে কেউ সেটি পূরণ করতে চায় না।
সিদ্ধান্তের বিভাগ, প্রভাবের মান, আস্থার মাত্রা, ঝুঁকি, নির্ভরতা, stakeholder তালিকা—সবই রাখা যায়।
কিন্তু একটি entry লিখতে যদি অনেক সময় লাগে, পুরো ব্যবস্থাটিই ধীরে ধীরে বন্ধ হয়ে যাবে।
আরেকটি সমস্যা হলো—Decision Log কোথায় আছে সেটিই কেউ জানে না।
প্রোডাক্টের নথি এক জায়গায়, সভার নোট আরেক জায়গায়, রোডম্যাপ তৃতীয় জায়গায়, আর Decision Log কোনো পুরোনো ফোল্ডারের ভেতরে পড়ে আছে।
তাহলে নথি technically আছে, কিন্তু কাজে নেই।
সিদ্ধান্তের নথি এমন জায়গায় রাখুন, যেখানে প্রোডাক্ট টিম স্বাভাবিকভাবেই খুঁজবে।
খোঁজা সহজ হতে হবে।
প্রয়োজনে রোডম্যাপ, ফিচারের বিবরণ বা সংশ্লিষ্ট প্রকল্পের নথি থেকে Decision Log-এর লিংক দেওয়া যায়।
| ভুল | প্রভাব | সমাধান |
| অতিরিক্ত বড় ছক | মানুষ লেখা পিছিয়ে দেয় | শুধু প্রয়োজনীয় তথ্য রাখুন |
| সব ছোট সিদ্ধান্ত লেখা | গুরুত্বপূর্ণ সিদ্ধান্ত ভিড়ের মধ্যে হারায় | শুধু প্রভাবশালী সিদ্ধান্ত রাখুন |
| Log খুঁজে পাওয়া কঠিন | নথি থেকেও বাস্তবে লাভ হয় না | পরিচিত ও সহজে খোঁজা যায় এমন জায়গায় রাখুন |
| শুরুতে বানিয়ে পরে ভুলে যাওয়া | কয়েক সপ্তাহ পর নথি পুরোনো হয়ে যায় | সিদ্ধান্ত নেওয়ার অভ্যাসের সঙ্গে নথি রাখা যুক্ত করুন |
| পুরোনো সিদ্ধান্ত আর দেখা না | পুরোনো সিদ্ধান্ত বর্তমান সত্য বলে মনে হতে পারে | অবস্থা বদলালে entry হালনাগাদ করুন |
| দায় ধরার খাতা বানানো | মানুষ সৎভাবে কারণ লিখতে ভয় পায় | শেখা ও প্রেক্ষাপট ধরে রাখাকে মূল উদ্দেশ্য করুন |
আরও একটি বিষয় খুব গুরুত্বপূর্ণ।
Decision Log যদি মানুষকে নজরদারি বা পরে দায়ী করার অস্ত্র হয়ে যায়, তাহলে এটি টিকবে না।
মানুষ যদি মনে করেন, আজকের প্রতিটি সিদ্ধান্ত ভবিষ্যতে তাঁদের বিরুদ্ধে প্রমাণ হিসেবে ব্যবহার হবে, তাহলে তাঁরা খুব নিরাপদ, অস্পষ্ট ভাষায় লিখবেন।
যেমন—
“বিভিন্ন বিষয় বিবেচনা করে সিদ্ধান্ত নেওয়া হয়েছে।”
এমন বাক্য ভবিষ্যতে কাউকে কোনো সাহায্য করে না।
তার চেয়ে লিখুন—কী জানা ছিল, কী জানা ছিল না, কোন অনুমান করা হয়েছিল এবং কোন ঝুঁকি জেনেও নেওয়া হয়েছিল।
প্রোডাক্ট ম্যানেজমেন্টে সব তথ্য হাতে নিয়ে সিদ্ধান্ত নেওয়ার সুযোগ খুব কমই আসে।
অসম্পূর্ণ তথ্যের মধ্যেই সিদ্ধান্ত নিতে হয়।
Decision Log-এর কাজ সেই অনিশ্চয়তা লুকানো নয়। বরং সেটিকেও সৎভাবে ধরে রাখা।
ছোট Team-এর জন্যও কি Decision Log দরকার?
হ্যাঁ, যদি ছোট দলটিও এমন সিদ্ধান্ত নেয়, যার কারণ কয়েক মাস পরে গুরুত্বপূর্ণ হয়ে উঠতে পারে।
বরং ছোট দলে অনেক সিদ্ধান্ত অনানুষ্ঠানিক কথাবার্তায় হয়ে যায়। ফলে কারণ হারিয়ে যাওয়ার ঝুঁকি কখনো কখনো আরও বেশি থাকে।
তবে ছোট Team-এর জন্য বড় কোনো ব্যবস্থা দরকার নেই। একটি ভাগাভাগি করা নথি বা সহজ তালিকাই যথেষ্ট হতে পারে।
Decision Log আর Meeting Notes-এর মধ্যে পার্থক্য কী?
Meeting Notes সাধারণত সভায় কী আলোচনা হয়েছে, কার কী কাজ, কোন বিষয় উঠেছে—এসব ধরে রাখে।
Decision Log অনেক বেশি বাছাই করা নথি।
এখানে মূলত গুরুত্বপূর্ণ সিদ্ধান্ত, তার প্রেক্ষাপট, বিকল্প এবং সিদ্ধান্তের কারণ থাকে।
একটি সভায় দশটি বিষয় নিয়ে আলোচনা হতে পারে। কিন্তু সেখান থেকে Decision Log-এ হয়তো একটি সিদ্ধান্তই যাবে।
Product Decision Log কত ঘন ঘন হালনাগাদ করা উচিত?
এর জন্য নির্দিষ্ট সাপ্তাহিক বা মাসিক নিয়ম থাকা জরুরি নয়।
সবচেয়ে ভালো সময় হলো—গুরুত্বপূর্ণ সিদ্ধান্ত হওয়ার পর যত দ্রুত সম্ভব।
তখন প্রেক্ষাপট সবার মনে পরিষ্কার থাকে।
পুরোনো সিদ্ধান্ত বদলালে বা আবার আলোচনায় এলে সংশ্লিষ্ট entry-টিও হালনাগাদ করা উচিত।
Decision Log কে দেখভাল করবে?
একজন পরিষ্কার দায়িত্বশীল মানুষ থাকলে অভ্যাসটি ধরে রাখা সহজ হয়।
প্রোডাক্ট ম্যানেজার এই দায়িত্ব নিতে পারেন, তবে সেটিই একমাত্র উপায় নয়।
মূল কথা হলো—সিদ্ধান্ত হওয়ার পরে কে নিশ্চিত করবেন যে সেটি নথিতে এসেছে, এ বিষয়ে দলের মধ্যে যেন দ্বিধা না থাকে।
ছয় মাস পরে যেন আবার একই প্রশ্ন থেকে শুরু করতে না হয়
শুরুর সেই দৃশ্যটায় আবার ফিরি।
নতুন সদস্য জিজ্ঞেস করলেন, “আমরা এই ফিচারটা বাদ দিয়েছিলাম কেন?”
উত্তর খুঁজতে যদি পাঁচজনকে বার্তা পাঠাতে হয়, পুরোনো সভার নোট ঘাঁটতে হয়, তারপরও সবাই নিজের স্মৃতির ওপর নির্ভর করেন—তাহলে সমস্যাটি মানুষের স্মৃতিশক্তিতে নয়।
সমস্যা হলো, সিদ্ধান্তের ইতিহাস রাখার নির্ভরযোগ্য জায়গা নেই।
একটি ভালো Product Decision Log সেই জায়গাটি তৈরি করে।
এটি ভুল সিদ্ধান্ত আটকাবে—এমন নিশ্চয়তা নেই। পুরোনো সিদ্ধান্ত কখনো বদলানো যাবে না—এমন কথাও বলে না।
বরং এটি Team-কে বুঝতে সাহায্য করে—তখন কী জানা ছিল, কী কী পথ সামনে ছিল, কেন একটি পথ নেওয়া হয়েছিল এবং আজ সেই কারণগুলো এখনও প্রযোজ্য কি না।
শুরু করতে বড় কোনো ব্যবস্থা দরকার নেই।
পরের গুরুত্বপূর্ণ সিদ্ধান্তের পর পাঁচটি বিষয় লিখুন—প্রেক্ষাপট, বিকল্প, চূড়ান্ত সিদ্ধান্ত, কারণ এবং প্রত্যাশিত ফল।
তারপর সেটি এমন জায়গায় রাখুন, যেখানে ছয় মাস পরে সত্যিই খুঁজে পাওয়া যাবে।
সেখান থেকেই একটি কার্যকর Decision Log তৈরি হতে শুরু করে।
