10.14

View in English

10.14 পণ্য ব্যবস্থাপনা ও আবিষ্কার

পরিচিতি ও প্রেরণা

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

বড় দলের জন্য দুর্বল পণ্য ব্যবস্থাপনা নীরবে সবচেয়ে ব্যয়বহুল ব্যর্থতার ধরন। প্রকৌশল চমৎকার হতে পারে, ডেলিভারি দ্রুত হতে পারে, এবং পুরো যন্ত্র তবু এক বছর ভুল জিনিস অসাধারণ দক্ষতায় গড়তে ব্যয় করতে পারে। খরচ কখনো একটি প্রকৌশল ড্যাশবোর্ডে দেখা দেয় না। এটি সমতল রাজস্ব, চলে যাওয়া গ্রাহক, এবং এমন ফিচারের ব্যাকলগ হিসেবে দেখা দেয় যা কেউ ব্যবহার করে না কিন্তু সবাইকে এখন রক্ষণাবেক্ষণ করতে হয়। ভালো পণ্য ব্যবস্থাপনা লক্ষ্য স্পষ্ট, পরিমাপযোগ্য এবং একটি প্রকৃত গ্রাহক সমস্যার সঙ্গে বাঁধা থাকার ওপর জোর দিয়ে অর্থ অঙ্গীকারের আগেই সেই ঝুঁকি দৃশ্যমান করে।

এন্টারপ্রাইজ ও সরকারি প্রেক্ষাপট ঝুঁকি বাড়ায় এবং কাজের আকার বদলায়। এন্টারপ্রাইজ ক্রমশ প্রকল্প পরিচালনা মডেল (একটি প্রকল্পে অর্থায়ন, পাঠানো, দল ভেঙে দেওয়া) থেকে পণ্য পরিচালনা মডেলে (বছরের পর বছর ফলাফলের মালিক টেকসই দলে অর্থায়ন) সরছে, এবং অভ্যন্তরীণ প্ল্যাটফর্মকে প্রকৃত গ্রাহকসহ পণ্য গণ্য করছে। সরকার ব্যবহারকারী-কেন্দ্রিক নকশার পতাকার নিচে একই শিক্ষা নিচ্ছে: প্রকল্প নয়, সেবায় অর্থায়ন করুন, এবং মাপুন নাগরিকরা আসলে সেবা পাচ্ছেন কি না। এই অধ্যায় সেই মানসিকতা ও যান্ত্রিক পদ্ধতি নিয়ে যা সেই পরিবর্তনকে বাস্তব করে। এটি অধ্যায় 11.1 (আবিষ্কার পাইপলাইন)-এর সঙ্গে ঘনিষ্ঠভাবে জোড়া, যা পাইপলাইন যন্ত্র বিস্তারিত দেয়; এখানে আমরা ভূমিকা, কৌশল এবং আবিষ্কারের দৈনন্দিন অভ্যাসে মনোযোগ দিই।

মূল নীতিসমূহ

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

সুপারিশ

কী ও কেন-র মালিক হোন, এবং দলকে কীভাবে-র মালিক হতে দিন

পণ্য ব্যবস্থাপনা সুস্থ কি না তার সবচেয়ে স্পষ্ট পরীক্ষা হলো কোন প্রশ্নের মালিক কে। পণ্য ব্যবস্থাপক আমরা কোন সমস্যা সমাধান করছি এবং এখন কেন তা গুরুত্বপূর্ণ-র মালিক। নকশা ব্যবহারকারীর জন্য এটি কেমন অনুভূত হওয়া উচিত-এর মালিক। প্রকৌশল আমরা কীভাবে এটি গড়ি-র মালিক। একজন পণ্য ব্যবস্থাপক সমাধান, সময়সীমা ও বাস্তবায়ন নির্দেশ করতে শুরু করলে তিনি পণ্য শিরোনাম পরা একজন প্রকল্প ব্যবস্থাপক হয়ে গেছেন, এবং তিনি ঠিক সেই স্বায়ত্তশাসন কেড়ে নিয়েছেন যা একটি ক্ষমতায়িত দলকে কার্যকর করে (অধ্যায় 5.1 নকশা অংশীদারিত্ব ঢাকে, অধ্যায় 10.7 অ্যাজাইল ডেলিভারি মডেল ঢাকে)।

একটি ক্ষমতায়িত পণ্য দল, কখনো পণ্য ট্রায়ো বলা হয়, পণ্য, নকশা ও প্রকৌশল একসঙ্গে কাজ করে, গড়ার জন্য একটি ফিচারের বদলে সমাধানের জন্য একটি সমস্যা দেওয়া হয়। এটি “নতুন ব্যবহারকারীদের জন্য 30-দিনের ধারণ বাড়ান” এবং “মার্চের মধ্যে বিজ্ঞপ্তি কেন্দ্র গড়ুন”-এর পার্থক্য। প্রথমটি দলকে সেরা সমাধান খুঁজতে ক্ষমতায়ন করে এবং একটি ফলে ধরে রাখে। দ্বিতীয়টি তাদের একটি ডেলিভারি বাহুতে নামিয়ে আনে এবং ভুল হওয়ার ঝুঁকি নীরবে প্রয়োজনীয়তা যিনি লিখেছেন তাঁর ওপর স্থানান্তর করে। আপনি ফলাফলের জন্য জবাবদিহি চাইলে আপনাকে আউটপুটের নিয়ন্ত্রণ ছেড়ে দিতে হবে।

গ্রাহকে ভিত্তিযুক্ত একটি পণ্য দৃষ্টি ও কৌশল স্থির করুন

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

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

ফলাফলে পরিচালনা করুন এবং ফিচার কারখানা থেকে পালান

ফিচার কারখানা সেটাই যা পান যখন সাফল্য সংজ্ঞায়িত হয় “আমরা এটি পাঠিয়েছি” হিসেবে। দলগুলো বেগ মাপে, রিলিজ গোনে এবং লঞ্চ উদযাপন করে, যখন যে মেট্রিক বিল মেটায় তা সমতল পড়ে থাকে। প্রতিষেধক হলো সাফল্যকে একটি ফলাফল (গ্রাহক বা ব্যবসায়িক আচরণে পরিবর্তন) হিসেবে সংজ্ঞায়িত করা এবং গড়ার আগে তাতে একটি পরিমাপ জুড়ে দেওয়া। এখানেই পণ্য ব্যবস্থাপনা উদ্দেশ্য ও মূল ফলাফলের (অধ্যায় 11.4) সঙ্গে মেলে: উদ্দেশ্য আপনি যে পরিবর্তন চান তা বর্ণনা করে, মূল ফলাফল তা মাপে, এবং “ফিচার X লঞ্চ করুন” হিসেবে বলা একটি মূল ফলাফল ছদ্মবেশে একটি টাস্ক।

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

ডেলিভারির পাশাপাশি নিরন্তর আবিষ্কার চালান

নিরন্তর পণ্য আবিষ্কারের অর্থ প্রতি সপ্তাহে, ডেলিভারির সমান্তরালে, দল গ্রাহকদের কাছ থেকে শিখছে এবং যা গড়ার পরিকল্পনা করেছে তার পিছনের অনুমান পরীক্ষা করছে। মডেলটি দ্বৈত-ট্র্যাক: একটি আবিষ্কার ট্র্যাক ধারণা ঝুঁকিমুক্ত করে যখন একটি ডেলিভারি ট্র্যাক যাচাইকৃতগুলো গড়ে, এবং দুটি ক্রমিক পর্যায় হিসেবে নয়, নিরন্তর চলে (অধ্যায় 11.1 পাইপলাইন বিস্তারিত দেয়)। এর পিছনের ব্যবহারিক অঙ্গীকার ছোট ও নির্মম: প্রতি একক সপ্তাহে গ্রাহকদের সঙ্গে কথা বলুন, ব্যস্ত থাকলেও, বিশেষত ব্যস্ত থাকলে।

এর একটি দরকারি মেরুদণ্ড হলো সুযোগ-সমাধান গাছ: আপনি একটি কাঙ্ক্ষিত ফলাফল থেকে শুরু করেন, গ্রাহক সুযোগে (প্রয়োজন, ব্যথা বিন্দু, আকাঙ্ক্ষা) শাখা করেন যা তা নড়াতে পারে, প্রতিটি সুযোগের জন্য প্রার্থী সমাধানে আবার শাখা করেন, এবং তারপর অনুমান পরীক্ষায় যা বলবে একটি সমাধান কাজ করে কি না। গাছটি একটি নির্দিষ্ট ফিচার কেন টেবিলে তা নিয়ে দলকে সৎ রাখে এবং প্রথম সমাধানের প্রেমে পড়ার বদলে সুযোগগুলো তুলনা করতে বাধ্য করে। প্রকৌশল অঙ্গীকারের আগে আপনি সবচেয়ে সস্তা পরীক্ষায় সবচেয়ে ঝুঁকিপূর্ণ অনুমান পরীক্ষা করেন: একটি সাক্ষাৎকার, একটি প্রোটোটাইপ, একটি ফেক-ডোর পরীক্ষা, একটি A/B পরীক্ষা। আবিষ্কারের আউটপুট একটি ফিচার তালিকা নয়। এটি যাচাইকৃত, পরিমাপযোগ্য বাজির একটি ধারা যা ডেলিভারির জন্য প্রস্তুত।

অগ্রাধিকার কাঠামো বিচারের সহায়ক হিসেবে ব্যবহার করুন, দৈববাণী নয়

অগ্রাধিকার কাঠামো একটি এলোমেলো সিদ্ধান্তে দরকারি কাঠামো আনে, এবং প্রতিটি ভুল যদি আপনি তার সংখ্যাকে সত্য গণ্য করেন। RICE প্রতিটি ধারণাকে Reach (কত ব্যবহারকারী), Impact, Confidence এবং Effort দিয়ে স্কোর করে, তারপর (Reach x Impact x Confidence) / Effort দিয়ে র‍্যাঙ্ক করে। ওয়েটেড স্কোরিং কয়েকটি ওজনযুক্ত মানদণ্ডের বিপরীতে বিকল্প রেট করে। বিলম্বের খরচ জিজ্ঞাসা করে অপেক্ষার প্রতি সপ্তাহ আপনাকে কী খরচ করে, যা প্রায়ই ক্রম নির্ধারণের তীক্ষ্ণতম লেন্স। Kano মডেল ফিচারকে মৌলিক প্রত্যাশা, কর্মক্ষমতা প্রয়োজন ও আনন্দদায়কে সাজায়, মনে করিয়ে দেয় সব সন্তুষ্টি রৈখিক নয়।

এগুলো আপনার অনুমান উন্মুক্ত করতে এবং ট্রেড-অফ আলোচনাযোগ্য করতে ব্যবহার করুন, সিদ্ধান্ত ত্যাগ করতে নয়। RICE-এর Confidence পদ এবং ওয়েটেড স্কোরিংয়ের প্রাক্কলন গণিতের পোশাকে বিচারের সিদ্ধান্ত, এবং মিথ্যা নির্ভুলতা একটি খারাপ বাজিকে একটি র‍্যাঙ্ক করা তালিকায় ধুয়ে দিতে পারে যা বস্তুনিষ্ঠ দেখায়। সংখ্যা চালান, তারপর জিজ্ঞাসা করুন র‍্যাঙ্কিং আপনার কৌশল ও গ্রাহক জ্ঞানের সঙ্গে মেলে কি না। না মিললে বিচারে বিশ্বাস করুন এবং ইনপুট জেরা করুন। কাঠামো একটি চিন্তার সহায়ক; আপনাকেই এখনো সঠিক হতে হবে।

রোডম্যাপকে অভিপ্রায়ের বিবৃতি গণ্য করুন

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

অন্তর্নিহিত পদক্ষেপ হলো সমস্যা ও ফলাফলে দৃঢ়ভাবে এবং সমাধানে ঢিলেভাবে অঙ্গীকার করা। যে অংশীজনরা তারিখ-নিশ্চিত ফিচার প্রতিশ্রুতি দাবি করেন তাঁরা সাধারণত পূর্বাভাসযোগ্যতা চান, যা যুক্তিসঙ্গত; আপনি এখনো যাচাই করেননি এমন নির্দিষ্ট ফিচারের স্তরে নয়, ফলাফল ও সময়সীমার স্তরে (“আমরা এই অর্ধেক বছরে অনবোর্ডিং ড্রপ-অফ অর্থবহভাবে কমাব”) তা তাঁদের দিন। আপনাকে একটি কঠিন তারিখ দিতে হলে, অধ্যায় 10.6 প্রকল্প ডেলিভারির জন্য যেমন সুপারিশ করে, তা একটি মূল্যবান ফলাফলের সঙ্গে বাঁধুন এবং সমাধানের পরিসর নমনীয় হতে দিন।

কাঙ্ক্ষিততা, কার্যকারিতা, সম্ভাব্যতা ও ব্যবহারযোগ্যতা যাচাই করুন

প্রকৃত বিনিয়োগ অঙ্গীকারের আগে একটি পণ্য ধারণাকে চারটি ঝুঁকি পেরোতে হয়। কাঙ্ক্ষিততা: গ্রাহকরা কি আসলে এটি চায়? কার্যকারিতা: এটি কি ব্যবসার জন্য কাজ করে (আইনি, আর্থিক, ব্র্যান্ড, বিক্রয়)? সম্ভাব্যতা: প্রকৌশল কি উপলব্ধ সময় ও প্রযুক্তিতে এটি গড়তে পারে? ব্যবহারযোগ্যতা: মানুষ কি আসলে এটি ব্যবহার করতে পারে? ট্রায়ো এগুলো ঢাকার জন্য গড়া: পণ্য কার্যকারিতায় নেতৃত্ব দেয়, নকশা ব্যবহারযোগ্যতায়, প্রকৌশল সম্ভাব্যতায়, এবং কাঙ্ক্ষিততা সবার সমস্যা। একটি এড়িয়ে গেলে এটি একটি লঞ্চ হিসেবে ফিরে আসে যা গ্রাহকরা উপেক্ষা করে, আইনি আটকায়, প্রকৌশল পাঠাতে পারে না, বা ব্যবহারকারীরা বুঝতে পারে না।

এটি গড়া, কেনা বা অংশীদারিত্ব সিদ্ধান্তেরও কাঠামো। একটি সামর্থ্য আপনার পার্থক্যের মূল হলে তা গড়ুন। প্রয়োজনীয় কিন্তু অপৃথককারী হলে (বিলিং, প্রমাণীকরণ, ইমেইল ডেলিভারি), কেনা বা অংশীদারিত্ব দৃঢ়ভাবে পছন্দ করুন, কারণ আপনি যে প্রতিটি ফিচার গড়েন তা রক্ষণাবেক্ষণ, নিরাপত্তা পৃষ্ঠ ও জ্ঞানীয় ভারের চিরস্থায়ী লেজ বহন করে। একটি ন্যূনতম কার্যকর পণ্য (MVP) আপনার সবচেয়ে ঝুঁকিপূর্ণ অনুমান পরীক্ষা করা সবচেয়ে সস্তা জিনিস, আপনি পাঠিয়ে ভুলে যাওয়া একটি ছাঁটা সংস্করণ 1.0 নয়; কেবল কী লঞ্চ করবেন নয়, কী শিখবেন জিজ্ঞাসা করে একে সৎ রাখুন।

পণ্য-বাজার ফিট জানুন এবং পণ্য পরিচালনায় বিনিয়োগ করুন

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

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

ট্রেড-অফ: সুবিধা ও অসুবিধা

পদ্ধতিসুবিধাঅসুবিধা
ক্ষমতায়িত পণ্য দল (ফলাফল)ফলের মালিক; ভালো সমাধান খোঁজে; অনুপ্রাণিতসিনিয়র প্রতিভা ও প্রকৃত আস্থা লাগে; ওপর-থেকে-নিচে নির্দেশ কঠিনতর
ফিচার-দল / অর্ডার-নেওয়া মডেলপূর্বাভাসযোগ্য আউটপুট; পরিচালনা ও চুক্তি সহজভুল জিনিস দক্ষতায় পাঠায়; ফলাফলের কেউ মালিক নয়
নিরন্তর আবিষ্কারপ্রতি সপ্তাহে বাজি ঝুঁকিমুক্ত করে; দ্রুত শেখা; কম অপচয়গবেষণা সামর্থ্য ও শৃঙ্খলা লাগে; সময়সূচি কঠিনতর
ভারী আগাম প্রয়োজনীয়তাঅর্থদাতাদের স্বস্তি; স্পষ্ট পরিসরঅনুমান অপরীক্ষিত; দেরিতে ফিডব্যাক; বিগ-ব্যাং ঝুঁকি
এখন/পরে/পরবর্তী রোডম্যাপঅনিশ্চয়তা সম্পর্কে সৎ; শেখা রক্ষা করেতারিখযুক্ত ফিচার প্রতিশ্রুতি চাওয়া অংশীজনদের হতাশ করে
তারিখযুক্ত ফিচার রোডম্যাপপূর্বাভাসযোগ্য মনে হয়; জানানো সহজযা জানা যায় না তার প্রতিশ্রুতি দেয়; ফলাফলের ওপর আউটপুট পুরস্কৃত করে
কাঠামো স্কোরে অগ্রাধিকারকাঠামোবদ্ধ, আলোচনাযোগ্য, রাজনীতি কমায়মিথ্যা নির্ভুলতা; একটি খারাপ বাজিকে বস্তুনিষ্ঠ হিসেবে ধুয়ে দিতে পারে

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

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

  1. আপনার পণ্য ব্যবস্থাপক কি একটি ফলাফলের মালিক, নাকি একটি ব্যাকলগের? আপনার দল আসলে কীভাবে কাজ করে সে সম্পর্কে এটি একক সবচেয়ে প্রকাশক প্রশ্ন। পণ্য ব্যবস্থাপককে যদি রোডম্যাপ পাঠানো, অংশীজন অনুরোধ তাড়া করা এবং স্প্রিন্ট ভরা রাখায় মাপা হয়, আপনার একজন পণ্য শিরোনামের প্রকল্প সমন্বয়কারী আছে, এবং কাজ একটি মেট্রিক নড়ায় কি না তার জন্য আসলে কেউ জবাবদিহিযোগ্য নয়। প্রমাণ আনুন: আপনার পণ্য ব্যবস্থাপকের শেষ তিনটি ডেলিভারেবল দেখুন এবং জিজ্ঞাসা করুন প্রতিটি কোন গ্রাহক বা ব্যবসায়িক ফলাফল বদলানোর কথা ছিল, এবং কেউ তা পরীক্ষা করেছিল কি না। একটি বড় প্রতিষ্ঠানে ঝুঁকি চক্রবৃদ্ধি হয়, কারণ আউটপুটের দিকে নির্দেশিত একটি একক দল একাধিক ত্রৈমাসিক ব্যয় করতে পারে এমন ফিচার গড়তে যা ডেমোতে ভালো পরীক্ষিত হয় কিন্তু উৎপাদনে কিছুই বদলায় না। উত্তর আপনি পণ্য ব্যবস্থাপককে কীসে মাপেন এবং সমাধানে দলকে কতটা নিয়ন্ত্রণ দিতে ইচ্ছুক উভয়ই নতুন আকার দেওয়া উচিত। কেউ ফলাফলের মালিক না হলে, রোডম্যাপ নিয়ে তর্কের আগে তা ঠিক করুন।

  2. এই দলের কেউ শেষবার কখন একজন গ্রাহকের সঙ্গে কথা বলেছেন, এবং তা কি এই সপ্তাহে ছিল? নিরন্তর আবিষ্কার এই অভ্যাসের ওপর বাঁচে বা মরে, এবং ডেলিভারি চাপ বাড়লে এটি প্রথমে কাটা হয়, ঠিক যখন আপনার এটি সবচেয়ে বেশি দরকার। যে দলগুলো গ্রাহকদের সঙ্গে কথা বলা বন্ধ করে তারা লক্ষ করে না যে তারা অন্ধ হয়ে গেছে; তারা কেবল অভ্যন্তরীণ মতামত ও পুরনো গবেষণা থেকে যুক্তি দেওয়া শুরু করে, আরও আত্মবিশ্বাসী ও কম সঠিক হয়ে। প্রকৃত লগ আনুন: আপনার শেষ দশটি ফিচারের কয়টি গড়ার আগে একটি নথিবদ্ধ অনুমান ও একটি সস্তা পরীক্ষার মধ্য দিয়ে গিয়েছিল, বনাম একজন অংশীজনের মুখ থেকে সরাসরি ব্যাকলগে, গুনুন। যে এন্টারপ্রাইজ ও সরকারি দলে একটি অসারিবদ্ধ উদ্যোগ অনেক দল-ত্রৈমাসিক অপচয় করতে পারে এবং, সরকারি খাতে, প্রকৃত জনআস্থা, সাপ্তাহিক গ্রাহক যোগাযোগ জীবিত রাখার জন্য কে জবাবদিহিযোগ্য তার নাম দিন। সৎ উত্তর যদি “এই সপ্তাহে নয়” বা “নিশ্চিত নই” হয়, আপনি অনুমানে উড়ছেন এবং একে কৌশল বলছেন।

  3. একটি প্রকল্প পরিচালনা মডেল থেকে একটি পণ্য পরিচালনা মডেলে যেতে কী লাগবে, এবং আপনাকে কী আটকাচ্ছে? অনেক এন্টারপ্রাইজ এখনো অস্থায়ী প্রকল্পে অর্থায়ন করে, তাতে কর্মী দেয়, পাঠায় এবং দল ভেঙে দেয়, যা ভালো পণ্য কাজের নির্ভর করা টেকসই মালিকানা ও গ্রাহক জ্ঞান ধ্বংস করে। বছরের পর বছর ফলাফলের মালিক টেকসই দলে সরে যাওয়া, অভ্যন্তরীণ প্ল্যাটফর্মকে প্রকৃত গ্রাহকসহ পণ্য গণ্য করাসহ, অর্থায়ন, সংগঠন নকশা ও শাসনের পরিবর্তন, কেবল চাকরির শিরোনামের পরিবর্তন নয়। প্রমাণ আনুন: একটি বর্তমান উদ্যোগ কীভাবে অর্থায়িত ও কর্মী-দেওয়া তা ট্রেস করুন, এবং জিজ্ঞাসা করুন প্রকল্প শেষ হলে এবং দল ছড়িয়ে পড়লে জমা শেখার কী হয়। প্রতিদ্বন্দ্বী বিবেচনা প্রকৃত, কারণ বার্ষিক প্রকল্প বাজেটিং ও ক্রয় নিয়ম বৈধ জবাবদিহি কারণে আছে, এবং আপনাকে সেগুলো মানতে হবে, উপেক্ষা নয়। পুরো পোর্টফোলিও রূপান্তরের চেষ্টার আগে উত্তর সবচেয়ে ছোট সুনির্দিষ্ট পদক্ষেপ (একটি স্থিতিশীল বাজেটসহ একটি ফলাফলের মালিক একটি স্থায়ী দল) শনাক্ত করা উচিত যা মডেল প্রমাণ করে (অধ্যায় 10.1)।

  4. আমরা যখন একটি অগ্রাধিকার কাঠামো চালাই, তা কি সিদ্ধান্ত জানাচ্ছে নাকি ইতিমধ্যে নেওয়া একটি সিদ্ধান্ত অনুমোদন করছে? RICE, ওয়েটেড স্কোরিং ও বিলম্বের খরচ দরকারি ঠিক কারণ তারা অনুমানকে উন্মুক্ত করতে বাধ্য করে, এবং একটি সংখ্যা চিন্তা বন্ধ করার অজুহাত হলেই তারা ক্ষয়কারী হয়। প্রতিদ্বন্দ্বী বিবেচনা প্রকৃত: কাঠামো রাজনীতি কমায় এবং একটি রক্ষণযোগ্য কাগজের পথ দেয়, যা বড় প্রতিষ্ঠানের সত্যিই দরকার, তবু Confidence ও Impact পদ গণিতের পোশাকে বিচার এবং একটি খারাপ বাজিকে একটি বস্তুনিষ্ঠ-দেখতে র‍্যাঙ্কে ধুয়ে দিতে পারে। আপনার শেষ কয়েকটি অগ্রাধিকার সিদ্ধান্ত আনুন এবং দুটি জিনিস পরীক্ষা করুন: কৌশল বা গ্রাহক জ্ঞান দ্বিমত করলে কেউ কখনো স্কোর বাতিল করেছিল কি না, এবং সর্বোচ্চ-বেতনভোগী ব্যক্তির পছন্দ নীরবে র‍্যাঙ্কিং তৈরি করা ইনপুট ঠিক করেছিল কি না। যে এন্টারপ্রাইজ ও সরকারি পরিবেশে একটি স্কোর করা ব্যাকলগ প্রায়ই স্টিয়ারিং কমিটি ও নিরীক্ষকদের দেখানো নিদর্শন হয়, সংখ্যা বাতিল করার অনুমতি কার এবং কোন ভিত্তিতে তার নাম দিন, কারণ যে কাঠামো কেউ বাতিল করতে পারে না তা একটি চিন্তার সহায়ক থেকে একটি রাবার স্ট্যাম্প হয়ে গেছে।

  5. আমরা অংশীজনদের তারিখযুক্ত ফিচার হিসেবে কী প্রতিশ্রুতি দিয়েছি, এবং তাদের আস্থা না হারিয়ে সেই অঙ্গীকারগুলো ফলাফল হিসেবে পুনর্বিবৃত করতে পারতাম কি? তারিখযুক্ত ফিচার রোডম্যাপ পূর্বাভাসযোগ্যতার মতো লাগে এবং সাধারণত কল্পকাহিনী, কারণ তারা সেই সমাধান স্থির করে যার সম্পর্কে আবিষ্কারের শিখতে থাকার কথা, এবং একটি বড় প্রতিষ্ঠানে প্রতিটি এমন প্রতিশ্রুতি নির্ভরশীল দল, বিপণন পরিকল্পনা ও নির্বাহী প্রত্যাশায় ঢেউ তোলে। টানাপোড়েন বৈধ: অর্থদাতা ও অংশীজনরা বাজেট ও জবাবদিহি কারণে নিশ্চয়তা চান, তাই আপনি কেবল অঙ্গীকার প্রত্যাখ্যান করতে পারেন না; আপনাকে অযাচাইকৃত ফিচারের বদলে ফলাফল ও সময়সীমার স্তরে পূর্বাভাসযোগ্যতা দিতে হবে। বর্তমান রোডম্যাপ আনুন এবং প্রতিটি আইটেমকে হয় আপনি অঙ্গীকার করতে পারেন এমন একটি ফলাফল বা আপনি অনুমান করছেন এমন একটি নির্দিষ্ট সমাধান হিসেবে চিহ্নিত করুন, তারপর খসড়া করুন কীভাবে আপনি অনুমানগুলোকে এখন/পরে/পরবর্তী সমস্যা হিসেবে পুনর্বিবৃত করবেন। বার্ষিক বাজেট ও ক্রয় মাইলফলকে বাঁধা এন্টারপ্রাইজ ও সরকারি-খাত দলের জন্য কোন অঙ্গীকার প্রকৃতপক্ষে চুক্তিগত বনাম নিছক অভ্যাসগত তা শনাক্ত করুন, কারণ অভ্যাসগতগুলো সেই জায়গা যেখানে আপনি মিথ্যা নির্ভুলতাকে সৎ দিকের সঙ্গে বদলাতে পারেন, এবং চুক্তিগতগুলো সেই জায়গা যেখানে আপনাকে ফিচারের বদলে একটি ফলাফলের অঙ্গীকার আলোচনা করতে হবে।

  6. আমরা কোথায় এমন অপৃথককারী সামর্থ্য গড়ছি যা কেনা বা অংশীদারিত্ব করা যেত, এবং কে ঠিক করে? আপনার গড়া প্রতিটি ফিচার রক্ষণাবেক্ষণ, নিরাপত্তা পৃষ্ঠ ও সহায়তা ভারের চিরস্থায়ী লেজ বহন করে, তাই বিলিং, প্রমাণীকরণ বা ইমেইল ডেলিভারি হাতে তৈরি করা আপনার সবচেয়ে দুর্লভ সামর্থ্য এমন কাজে ব্যয় করে যা আপনাকে আলাদা করে না (অধ্যায় 10.4)। প্রতিদ্বন্দ্বী বিবেচনা হলো “কেনা” গতি ও নিম্নতর মালিকানা খরচের বিনিময়ে নিয়ন্ত্রণ ও মানানসই ছাড়ে, এবং কখনো আপনি যে সামর্থ্য পণ্যায়িত ধরেছিলেন তা আসলে আপনার সুবিধার মূল, তাই কাঙ্ক্ষিততা-কার্যকারিতা-সম্ভাব্যতা-ব্যবহারযোগ্যতা লেন্স একটি পছন্দের জন্য আড়াল হিসেবে নয়, সততার সঙ্গে প্রয়োগ করতে হবে। আপনার দল বর্তমানে অভ্যন্তরে কী গড়ছে তার একটি তালিকা আনুন, প্রতিটিকে মূল পৃথককারী বা অপৃথককারী নল-কাজ হিসেবে চিহ্নিত করুন, এবং একটি বিক্রেতা বিকল্পের বিপরীতে নল-কাজের চলমান মালিকানা খরচ প্রাক্কলন করুন। এন্টারপ্রাইজ ও সরকারি প্রেক্ষাপটে ক্রয় নিয়ম, ডেটা-আবাসন ও নিরাপত্তা প্রয়োজন, এবং বিক্রেতা লক-ইন ও প্রস্থান শর্ত যোগ করুন, কারণ সেখানে গড়া-কেনা-অংশীদারিত্ব সিদ্ধান্ত কেবল প্রকৌশল ট্রেড-অফ নয়, একটি সম্মতি ও জবাবদিহি সিদ্ধান্ত, এবং এর মালিক একজন নিরীক্ষকের কাছে পছন্দটি রক্ষা করতে সক্ষম হওয়া উচিত।

খাতভেদে দৃষ্টিভঙ্গি

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

ছোট ব্যবসা। আপনার কোনো নিবেদিত পণ্য ব্যবস্থাপক নেই, তাই পণ্য চিন্তা এমন অভ্যাস যা মালিক বা একজন লিড ইঞ্জিনিয়ার অন্যান্য দায়িত্বের পাশাপাশি বহন করেন। বেশিরভাগ গড়া-বনাম-কেনা সিদ্ধান্ত কেনার দিকে ফ্রেম করুন: বুকিং, পেমেন্ট বা ইমেইলের মতো অপৃথককারী সামর্থ্য একজন বিক্রেতার, এবং আপনার দুর্লভ মনোযোগ সেই এক বা দুটি জিনিসে যায় যা আসলে গ্রাহক জেতে। একটি আনুষ্ঠানিক রোডম্যাপের বদলে একটি হালকা এখন/পরে/পরবর্তী তালিকা রাখুন, এবং একটি পূর্ণ OKR যন্ত্রের বদলে আপনার ফলাফল হিসেবে একটি একক অগ্রণী মেট্রিক (পুনরাবৃত্ত কেনা, নো-শো) গণ্য করুন।

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

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

উদাহরণ

স্টার্টআপ। স্বাধীন ক্লিনিকের জন্য একটি সময়সূচি টুল গড়া ছয়জনের একটি স্টার্টআপ তিনজন জোরালো গ্রাহকের ক্রমাগত অনুরোধ করা বড় “অনলাইন বুকিং” ফিচার গড়ার প্রলোভন প্রতিরোধ করে। প্রতিষ্ঠাতা-পণ্য ব্যবস্থাপক বদলে এক সপ্তাহের আবিষ্কার চালান: পাঁচটি ক্লিনিক-মালিক সাক্ষাৎকার, বিপণন সাইটে একটি ফেক-ডোর বোতাম, এবং একটি অগ্রণী মেট্রিক (নো-শোতে শেষ হওয়া অ্যাপয়েন্টমেন্টের শতাংশ)। প্রমাণ বলে নো-শোই, বুকিং নয়, প্রকৃত ব্যথা, তাই দল একটি একক ফলাফল ফ্রেম করে (এই ত্রৈমাসিকে পাইলট ক্লিনিকে নো-শো 10%-এর নিচে কাটুন), সবচেয়ে ঝুঁকিপূর্ণ অনুমান পরীক্ষা করতে একটি ছোট ডিপোজিট-এবং-অনুস্মারক MVP পাঠায়, এবং এর একটি লাইন লেখার আগে বুকিং ফিচার বাতিল করে। রোডম্যাপ একটি তারিখযুক্ত পরিকল্পনা নয়, একটি এখন/পরে/পরবর্তী তালিকা, এবং পুরো দল স্মৃতি থেকে গত সপ্তাহের গ্রাহক কল বর্ণনা করতে পারে।

এন্টারপ্রাইজ। একটি খুচরা ব্যাংক তার পেমেন্ট গোষ্ঠীকে প্রকল্প মডেল থেকে পণ্য মডেলে নিয়ে যায়: একটি টেকসই ট্রায়ো (পণ্য, নকশা, প্রকৌশল) চার্টার করা প্রকল্পের ক্রমের বদলে একটি স্থিতিশীল বার্ষিক বাজেটসহ একটি স্থায়ী ফলাফল হিসেবে “প্রতিদিনের পেমেন্ট তাৎক্ষণিক অনুভূত হয়”-এর মালিক। দলটি সাপ্তাহিক গ্রাহক সাক্ষাৎকার চালায় এবং একটি সুযোগ-সমাধান গাছ বজায় রাখে, প্রার্থী সমাধানের ক্রম দিতে RICE ব্যবহার করে কিন্তু বিলম্বের খরচ বিশ্লেষণ একটি লেটেন্সি সমাধান বেশি গুরুত্বপূর্ণ দেখালে র‍্যাঙ্কিং বাতিল করে, এবং অংশীজনদের তারিখযুক্ত ফিচার প্রতিশ্রুতির বদলে একটি এখন/পরে/পরবর্তী রোডম্যাপ প্রকাশ করে। দুটি প্রস্তাবিত ফিচার অগ্রণী সূচক নড়াতে ব্যর্থ হয়ে আবিষ্কারে মারা যায়, আনুমানিক দুই ত্রৈমাসিকের নির্মাণ প্রচেষ্টা বাঁচিয়ে, এবং পণ্য পরিচালনা ব্যাংকের পনেরোটি পণ্য দল জুড়ে সাক্ষাৎকার ছন্দ ও বিশ্লেষণ বিশ্বাসযোগ্য রাখে।

সরকার। একটি সুবিধা আবেদন আধুনিকীকরণ করা একটি জাতীয় সংস্থা ডিজিটাল সেবা দলের সমর্থিত সরকারি-খাত পণ্য মানসিকতা গ্রহণ করে: এটি একটি স্থির-পরিসর প্রকল্পের বদলে একটি টেকসই সেবা দলে অর্থায়ন করে, এবং সাফল্য ডেলিভার করা মডিউলের বদলে একটি নাগরিক ফলাফল (গড় আবেদন সময় 40 থেকে 15 মিনিটে কমান এবং সফল স্ব-সেবা সমাপ্তি 55% থেকে 85%-এ বাড়ান) হিসেবে সংজ্ঞায়িত করে। ব্যবহারকারী-কেন্দ্রিক নকশা অনমনীয়: দল প্রতিটি রিলিজের আগে সহায়ক-প্রযুক্তি ব্যবহারকারীসহ প্রকৃত আবেদনকারীদের সঙ্গে পরিচালিত ব্যবহারযোগ্যতা পরীক্ষা চালায় এবং প্রবেশগম্যতা মানকে কঠিন প্রয়োজন গণ্য করে। কারণ রোডম্যাপ ফলাফল হিসেবে ফ্রেম করা এবং দল বছরের পর বছর সেবার মালিক, তদারকি সংস্থা একটি ব্যয় প্রতিবেদনের বদলে পরিমাপযোগ্য জনমূল্য দেখে, এবং সংস্থা একটি দূরের গো-লাইভে সবকিছু বাজি না রেখে আগে কার্যকর সামর্থ্য পাঠাতে পারে (অধ্যায় 11.1, 5.1)।

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

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

মালিকানার মোট খরচে প্রতিটি পাঠানো ফিচার একটি স্থায়ী দায়: রক্ষণাবেক্ষণ, টেস্টিং, নিরাপত্তা পৃষ্ঠ, সহায়তা ভার, এবং পণ্যে নেভিগেট করতে হয় এমন সবার ওপর জ্ঞানীয় ওজন (অধ্যায় 10.4)। পণ্য ব্যবস্থাপনা দুভাবে সেই খরচ কমায়। এটি আবিষ্কারে খারাপ ধারণা মারে, কেবল নির্মাণ নয়, মালিকানার পুরো লেজ এড়িয়ে। এবং এটি গড়া-কেনা-অংশীদারিত্ব সিদ্ধান্তকে অপৃথককারী সামর্থ্য কেনার দিকে চালনা করে, যাতে আপনার দলের সীমিত সামর্থ্য সেখানে যায় যা আসলে আপনাকে আলাদা করে। প্রকল্প পরিচালনা মডেল থেকে পণ্য পরিচালনা মডেলে পরিবর্তন একটি আরও সূক্ষ্ম প্রতিদান যোগ করে: টেকসই দল গ্রাহক জ্ঞান ও কোডবেস প্রেক্ষাপট ধরে রাখে যা প্রকল্প দল প্রতিবার ভেঙে পুনর্গঠিত হলে ফেলে দেয়।

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

অ্যান্টি-প্যাটার্ন ও ফাঁদ

  • ফিচার কারখানা: সাফল্য “আমরা এটি পাঠিয়েছি” হিসেবে সংজ্ঞায়িত, ব্যবসায়িক মেট্রিক সমতল থাকার সময় বেগ উদযাপিত।
  • প্রকল্প ব্যবস্থাপক হিসেবে পণ্য ব্যবস্থাপক: সমস্যা ও ফলাফলের বদলে সময়সূচি ও টিকিট সারির মালিক।
  • ফিচার সচিব হিসেবে পণ্য ব্যবস্থাপক: কোনো সমস্যা বা পরিমাপ জুড়ে না দিয়ে অংশীজন অনুরোধ ব্যাকলগে লিপিবদ্ধ করা।
  • তারিখযুক্ত ফিচার প্রতিশ্রুতি হিসেবে রোডম্যাপ: আপনি এখনো যাচাই করতে পারেন না এমন নির্দিষ্ট ত্রৈমাসিকে নির্দিষ্ট সমাধানের অঙ্গীকার।
  • একবারের পর্যায় হিসেবে আবিষ্কার: আগে একটি আবিষ্কার স্প্রিন্ট, তারপর আর কোনো গ্রাহক যোগাযোগ ছাড়া মাসের পর মাস গড়া।
  • HiPPO-চালিত অগ্রাধিকার: সর্বোচ্চ-বেতনভোগী ব্যক্তির মতামত প্রমাণ বাতিল করে, এবং কাঠামো তা অনুমোদন করার নাট্য হয়।
  • কাঠামো পূজা: একটি RICE বা ওয়েটেড স্কোরকে সত্য গণ্য করা, মিথ্যা নির্ভুলতাকে একটি খারাপ বাজি ধুয়ে দিতে দিয়ে।
  • অপৃথককারী অবকাঠামো গড়া: একজন বিক্রেতা ভালো ও সস্তায় দিত এমন বিলিং বা প্রমাণীকরণ হাতে তৈরি করা।
  • পণ্য-বাজার ফিটের আগে স্কেলিং: বাজার এখনো জোরালোভাবে চায় না এমন পণ্যে বৃদ্ধিতে অর্থ ঢালা।
  • পণ্য মালিকহীন অভ্যন্তরীণ প্ল্যাটফর্ম: একটি প্ল্যাটফর্ম দল তার অভ্যন্তরীণ গ্রাহকদের দরকারের বদলে যা আকর্ষণীয় মনে করে তা গড়ছে।

পরিপক্বতা মডেল

  • স্তর 1, সূচনা: পণ্য ব্যবস্থাপনা অর্ডার-নেওয়া ও প্রতিক্রিয়াশীল। একটি তারিখযুক্ত ফিচার রোডম্যাপ নিচে নামানো হয়; সাফল্য তা পাঠানো। কোনো বলা ফলাফল নেই, কোনো নিয়মিত গ্রাহক যোগাযোগ নেই, এবং কাজ একটি মেট্রিক নড়ায় কি না তার জন্য কেউ জবাবদিহিযোগ্য নয়।
  • স্তর 2, বিকাশ: মৌলিক পণ্য চর্চা দেখা দেয় কিন্তু দল জুড়ে অসামঞ্জস্যপূর্ণ। কিছু দলের জন্য ফলাফল ও OKR আছে, তবু লক্ষ্য প্রায়ই আউটপুট-আকৃতির এবং রোডম্যাপ এখনো ফিচার তালিকা। আবিষ্কার মাঝে মাঝে, সাধারণত আগাম পর্যায় হিসেবে ঘটে, এবং অগ্রাধিকার একটি কাঠামো ব্যবহার করে, কখনো সবচেয়ে জোরালো কণ্ঠের আড়াল হিসেবে।
  • স্তর 3, মানসম্মতকরণ: ক্ষমতায়িত ট্রায়ো ফলাফলের মালিক, এবং চর্চা নথিবদ্ধ ও প্রতিষ্ঠান-ব্যাপী প্রত্যাশিত। রোডম্যাপ এখন/পরে/পরবর্তী অভিপ্রায়ের বিবৃতি; নিরন্তর আবিষ্কার নথিবদ্ধ অনুমান পরীক্ষাসহ একটি কর্মী-দেওয়া সাপ্তাহিক অভ্যাস; অগ্রাধিকার কাঠামো বিচার প্রতিস্থাপন না করে জানায়; এবং পণ্য-বাজার ফিট বোঝা হয় ও একটি স্থানীয় অভ্যাসের বদলে একটি ভাগ করা মান হিসেবে অনুসরণ করা হয়।
  • স্তর 4, ব্যবস্থাপনা: চর্চা ভিত্তিরেখার বিপরীতে মাপা ও নিয়ন্ত্রিত। প্রতিটি দল একটি উল্লিখিত ভিত্তিরেখার বিপরীতে অগ্রণী ও পশ্চাৎ ফলাফল মেট্রিক অনুসরণ করে, এবং লঞ্চের পর প্রতিটি ফিচার একটি পূর্ব-নিবন্ধিত সাফল্য মেট্রিকের বিপরীতে পরীক্ষা করা হয় মতামতের বদলে প্রমাণে প্রয়োগ করা একটি বন্ধ করার সীমাসহ। আবিষ্কার স্বাস্থ্যও যন্ত্রায়িত (সাক্ষাৎকার ছন্দ পূরণ, গড়ার আগে অনুমান পরীক্ষিত, আবিষ্কারে মারা বনাম পাঠানো ধারণা), পণ্য-বাজার-ফিট সংকেত যেমন ধারণ বক্ররেখা ও হতাশ-হবে স্কোর পরিমাণযুক্ত, এবং RICE Confidence-এর মতো কাঠামো ইনপুট বাজি আসলে কেমন হয়েছিল তার বিপরীতে ক্যালিব্রেট করা।
  • স্তর 5, সমন্বয়: একটি পণ্য পরিচালনা মডেল পোর্টফোলিও জুড়ে চলে এবং নিরন্তর উন্নত ও অর্থায়ন ও কৌশলের সঙ্গে একীভূত। টেকসই দল বছরের পর বছর ফলাফলের মালিক এবং অভ্যন্তরীণ প্ল্যাটফর্ম পণ্য হিসেবে পরিচালিত; আবিষ্কার ও ডেলিভারি নিরন্তর লুপ করে; ফলাফল ডেটা বিনিয়োগ চালায় এবং খাপখাইয়ে পোর্টফোলিও পুনঃভারসাম্য করে; পণ্য পরিচালনা বড় পরিসরে চর্চা সুসংগত রাখে; এবং নেতৃত্ব ফলাফলের একটি পোর্টফোলিও পরিচালনা করে, প্রমাণ ও বাজার সরলে নিয়মিত বাজি অবসর, পুনঃপরিসর ও পুনঃঅগ্রাধিকার দেয়।

আলোচনার ভাবনা

  1. আপনার বর্তমান রোডম্যাপ দেখুন: কয়টি আইটেম শুধু একটি ফিচার ও একটি তারিখের বিপরীতে একটি পরিমাপযোগ্য ফলাফল বলে?
  2. আপনার দলে কে গ্রাহক সম্পর্কের এতটা মালিক যে স্মৃতি থেকে গত সপ্তাহের কথোপকথন বর্ণনা করতে পারেন?
  3. আপনার সাম্প্রতিক কোন ফিচারগুলো আপনি মেরে ফেলতেন যদি সবচেয়ে ঝুঁকিপূর্ণ অনুমানে আগে একটি সস্তা পরীক্ষা চালাতেন?
  4. আপনি কোথায় অপৃথককারী সামর্থ্য গড়ছেন যা কেনা বা অংশীদারিত্ব করা যেত, এবং তা আপনার কী খরচ করছে?
  5. আপনার কি পণ্য-বাজার ফিট আছে, এবং ধরে না নিয়ে আপনি আসলে তা কীভাবে জানবেন?
  6. একটি পণ্য পরিচালনা মডেলের দিকে আপনি সবচেয়ে ছোট কোন পদক্ষেপ নিতে পারেন, এবং কোন শাসন বাধা পথে দাঁড়িয়ে?

প্রধান শিক্ষা

  • পণ্য ব্যবস্থাপনা কী ও কেন-র মালিক, এবং ফলাফলের জন্য জবাবদিহিযোগ্য, টাস্ক সমন্বয় বা অনুরোধ লিপিবদ্ধ করার জন্য নয়।
  • গড়ার আগে গ্রাহক বা ব্যবসায়িক আচরণে পরিমাপকৃত পরিবর্তন হিসেবে সাফল্য সংজ্ঞায়িত করে ফিচার কারখানা থেকে পালান।
  • ডেলিভারির পাশাপাশি নিরন্তর আবিষ্কার চালান: প্রতি সপ্তাহে গ্রাহকদের সঙ্গে কথা বলুন এবং সবচেয়ে সস্তা পরীক্ষায় সবচেয়ে ঝুঁকিপূর্ণ অনুমান পরীক্ষা করুন (অধ্যায় 11.1)।
  • অগ্রাধিকার কাঠামো (RICE, ওয়েটেড স্কোরিং, বিলম্বের খরচ, Kano) বিচারের সহায়ক হিসেবে ব্যবহার করুন, কখনো দৈববাণী নয়।
  • রোডম্যাপকে অভিপ্রায়ের বিবৃতি গণ্য করুন (এখন/পরে/পরবর্তী): সমস্যা ও ফলাফলে দৃঢ়ভাবে, সমাধানে ঢিলেভাবে অঙ্গীকার করুন।
  • ট্রায়ো ক্ষমতায়ন করুন এবং বিনিয়োগের আগে কাঙ্ক্ষিততা, কার্যকারিতা, সম্ভাব্যতা ও ব্যবহারযোগ্যতা যাচাই করুন (অধ্যায় 5.1)।
  • এন্টারপ্রাইজ ও সরকারে প্রকল্প পরিচালনা মডেল থেকে পণ্য পরিচালনা মডেলে সরুন, প্রকল্প নয় সেবায় অর্থায়ন করুন, এবং পণ্য পরিচালনায় বিনিয়োগ করুন (অধ্যায় 10.1, 11.4)।

তথ্যসূত্র ও আরও পড়ার জন্য

  • Marty Cagan, Inspired and Empowered (empowered product teams, the product operating model).
  • Marty Cagan and Chris Jones, Transformed (moving to a product operating model).
  • Teresa Torres, Continuous Discovery Habits (opportunity-solution trees, weekly customer contact).
  • Melissa Perri, Escaping the Build Trap (outcomes over outputs, product operations).
  • Roman Pichler, Strategise (product vision, strategy, and roadmaps).
  • C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors, Product Roadmaps Relaunched (now/next/later roadmaps).
  • Dan Olsen, The Lean Product Playbook (product-market fit).
  • Eric Ries, The Lean Startup (minimum viable product, build-measure-learn).
  • Noriaki Kano et al., “Attractive Quality and Must-Be Quality” (Journal of the Japanese Society for Quality Control, 1984): origin of the Kano model.
  • Melissa Perri and Denise Tilles, Product Operations (scaling product practice).
  • U.S. Digital Service, Digital Services Playbook; UK Government Digital Service, Government Design Principles and Service Standard (public-sector, user-centred product delivery).