বাগ ফিক্স ও নিউ ফিচারের মধ্যে রিসোর্স ভাগ করবেন কীভাবে

সোমবারের স্প্রিন্ট প্ল্যানিং। বিক্রয় দল এমন একটি নিউ ফিচার (New Feature) চাইছে, যেটি পরের বড় গ্রাহকের ডেমোতে দেখানো জরুরি। প্রোডাক্ট ম্যানেজার বলছেন, ফিচারটি প্রোডাক্ট রোডম্যাপে আগেই পিছিয়ে গেছে। অন্যদিকে ইঞ্জিনিয়ারিং লিড এমন একটি বাগ ফিক্স (Bug Fix) সামনে এনেছেন, যেটি কয়েক সপ্তাহ ধরে ব্যাকলগে পড়ে আছে এবং নিয়মিত গ্রাহক সহায়তা দলের কাছে অভিযোগ তৈরি করছে।

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

এখন রিসোর্স ভাগ হবে কীভাবে? বাগ ফিক্স ও নিউ ফিচার (Bug Fix vs New Feature)?

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

এই দ্বন্দ্ব কোনো দুর্বল দলের লক্ষণ নয়। প্রোডাক্ট ম্যানেজমেন্টে এটি স্থায়ী বাস্তবতা। কারণ বাগ ফিক্স এবং নিউ ফিচার—দুটোই গুরুত্বপূর্ণ, কিন্তু দুটোই একই সীমিত ইঞ্জিনিয়ারিং সক্ষমতার জন্য প্রতিযোগিতা করে।

বাগ ফিক্স ও নিউ ফিচারের মধ্যে রিসোর্স ভাগ কেন স্থায়ী সমস্যা

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

নিউ ফিচার ব্যবহারকারীর নতুন সমস্যা সমাধান করতে পারে, বাজারে পণ্যকে প্রতিযোগিতায় টিকিয়ে রাখতে পারে, বিক্রির সুযোগ তৈরি করতে পারে বা আয়ের নতুন পথ খুলতে পারে। অন্যদিকে বাগ ফিক্স বিদ্যমান ব্যবহারকারীর অভিজ্ঞতা, আস্থা এবং পণ্যের নির্ভরযোগ্যতা রক্ষা করে।

কঠিন বিষয় হলো—দুটোর জন্যই একই দলের সময় লাগে।

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

তাই প্রশ্নটি “কোন কাজ গুরুত্বপূর্ণ?” নয়। বরং “এই মুহূর্তে কোন কাজ কতটা গুরুত্বপূর্ণ?”

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

বাগ কি শুধু রক্ষণাবেক্ষণের কাজ?

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

বাস্তবে সেই “বেঁচে যাওয়া সময়” অনেক স্প্রিন্টেই আসে না।

ফিচারের কাজ অনুমানের তুলনায় বেশি সময় নিতে পারে। প্রয়োজনীয়তা বদলাতে পারে। অন্য দলের ওপর নির্ভরতা তৈরি হতে পারে। পরীক্ষার সময় নতুন সমস্যা ধরা পড়তে পারে। ফলে যে বাগগুলো “সময় থাকলে” ঠিক করার কথা ছিল, সেগুলো আবার পরের স্প্রিন্টে চলে যায়।

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

আরেকটি সমস্যা হলো পুনরাবৃত্ত খরচ। একই ত্রুটির জন্য গ্রাহক সহায়তা দলকে বারবার ব্যাখ্যা দিতে হচ্ছে, ব্যবহারকারীকে বিকল্প পথ দেখাতে হচ্ছে, পরীক্ষণ দলকে প্রতি প্রকাশের আগে একই জায়গায় আলাদা সতর্কতা নিতে হচ্ছে—এগুলোও তো সময়ের খরচ।

বাগ যত পুরোনো হয়, সবসময় যে তত বড় বিপদে পরিণত হবে তা নয়। তবে দীর্ঘদিন অবহেলিত বাগ ব্যাকলগ দলের জন্য অনিশ্চয়তা তৈরি করে। কোনটি সামান্য দৃশ্যগত সমস্যা, কোনটি ভবিষ্যতের বড় ভাঙনের ইঙ্গিত—ব্যাকলগ খুব বড় হলে সেটি বোঝাও কঠিন হয়ে যায়।

নিউ ফিচারও “সময় থাকলে করা যাবে” ধরনের কাজ নয়

বাগের গুরুত্ব বোঝাতে গিয়ে বিপরীত ভুলটাও করা সহজ। কেউ কেউ ধরে নেন, আগে সব ত্রুটি শেষ করতে হবে, তারপর নতুন ফিচার।

অনেক পণ্যের ক্ষেত্রে এটি বাস্তবসম্মত নয়।

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

শুরুর পর্যায়ের পণ্যে নতুন ফিচারের গুরুত্ব আরও বেশি হতে পারে। তখন দল এখনও বুঝতে চেষ্টা করছে ব্যবহারকারীরা আসলে কী চায়, কোন সুবিধার জন্য টাকা দিতে রাজি, কোন কাজের ধারা তাদের কাছে অপরিহার্য।

এ অবস্থায় নতুন ফিচার ধীর করে দিলে শেখার গতিও কমে যায়।

তাই “আগে সব বাগ শেষ, তারপর ফিচার”—এমন নীতি সাধারণত কার্যকর নয়। বাগ ব্যাকলগ পুরোপুরি শূন্য হওয়ার অপেক্ষা করলে পণ্য উন্নয়নই থেমে যেতে পারে।

লক্ষ্য হওয়া উচিত বাগ শূন্য করা নয়। লক্ষ্য হচ্ছে, ত্রুটির ঝুঁকি যেন নিয়ন্ত্রণে থাকে এবং নিউ ফিচারও অর্থপূর্ণ গতিতে এগোয়।

একটি স্প্রিন্টে কতটা সময় বাগ ফিক্সের জন্য রাখা উচিত?

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

পদ্ধতিটি কার্যকর হতে পারে, কারণ তখন বাগ আর “ফাঁকে করলে হবে” ধরনের কাজ থাকে না। পরিকল্পনার শুরুতেই তার জন্য জায়গা থাকে।

তবে কোনো একটি নির্দিষ্ট শতকরা হারকে সবার জন্য সঠিক নিয়ম ধরে নেওয়া উচিত নয়। একটি দলের জন্য যে ভাগ কাজ করছে, অন্য দলের জন্য সেটি অযৌক্তিক হতে পারে। এমনকি একই দলের ক্ষেত্রেও তিন মাস পর ভিন্ন ভাগ দরকার হতে পারে।

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

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

স্থির অনুপাতের চেয়ে পরিবর্তনযোগ্য একটি প্রাথমিক ভাগ বেশি কার্যকর।

রিসোর্স ভাগ করার সাধারণ পদ্ধতি

সব দল একইভাবে কাজ করে না। দলের আকার, পণ্যের প্রযুক্তিগত কাঠামো, গ্রাহক সহায়তার চাপ এবং প্রকাশ প্রক্রিয়া অনুযায়ী আলাদা পদ্ধতি দরকার হতে পারে।

গুরুত্বভিত্তিক ট্রায়াজ ছাড়া কোনো ভাগই টিকবে না

ধরা যাক, স্প্রিন্ট শুরুতে কাজের সক্ষমতা ভাগ করা হয়েছে। মাঝপথে দেখা গেল, গ্রাহক টাকা পরিশোধ করতে পারছেন না। এখন কি বলা হবে, “বাগের জন্য রাখা সময় শেষ, পরের স্প্রিন্টে দেখব”?

না।

গুরুতর ত্রুটি সব সময় পরিকল্পিত ভাগকে ছাড়িয়ে যেতে পারে। ব্যবহারকারীকে পুরোপুরি আটকে দেয়, তথ্য হারানোর ঝুঁকি তৈরি করে, নিরাপত্তা বিঘ্নিত করে বা ব্যবসার গুরুত্বপূর্ণ কাজ বন্ধ করে দেয়—এমন বাগের জন্য আলাদা জরুরি ব্যবস্থা থাকা দরকার।

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

বাগের গুরুত্ব নির্ধারণে কয়েকটি প্রশ্ন খুব কাজে আসে। কতজন ব্যবহারকারী প্রভাবিত হচ্ছেন? বিকল্প কোনো উপায় আছে কি? মূল কাজ বন্ধ হচ্ছে কি? তথ্য বা অর্থ লেনদেনের ঝুঁকি আছে কি? সমস্যা কত ঘনঘন ঘটছে?

একটি বোতামের রঙ সামান্য ভুল হওয়া আর পেমেন্ট ব্যর্থ হওয়া একই অগ্রাধিকার পেতে পারে না।

পালাক্রমে বাগ সামলানোর ব্যবস্থা কখন কাজে দেয়

কিছু দলে সবাইকে দিনের মধ্যে বারবার নিউ ফিচার এবং হঠাৎ আসা বাগের মধ্যে মনোযোগ বদলাতে হয়। এতে দুই ধরনের কাজই ধীর হয়ে যায়।

একটি বিকল্প হলো পালাক্রমে বাগের দায়িত্ব দেওয়া। একটি কাজের চক্রে একজন প্রকৌশলী বা ছোট একটি দল নতুন উৎপাদন-পরিবেশের ত্রুটি, গ্রাহক সহায়তা দলের জরুরি অনুরোধ এবং ছোটখাটো বাগ ফিক্স সামলাবে। অন্যরা তুলনামূলকভাবে বাধাহীনভাবে ফিচারের কাজে মন দিতে পারবে।

পরের চক্রে এই দায়িত্ব বদলে যাবে।

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

বাগ ব্যাশেরও সীমা আছে

মাঝে মাঝে পুরো দল মিলে বাগ খোঁজা ও ঠিক করা উপকারী। বিশেষ করে বড় প্রকাশের আগে পণ্যের বিভিন্ন অংশ ব্যবহার করে ছোটখাটো সমস্যা ধরার সুযোগ থাকে।

তবে বাগ ব্যাশ যেন নিয়মিত বাগ ব্যবস্থাপনার বিকল্প না হয়ে যায়।

যদি কয়েক মাস পরপর এমন অবস্থা হয় যে, “সব ফিচার বন্ধ করে এবার এক সপ্তাহ শুধু বাগ ঠিক করতে হবে”, তাহলে মূল সমস্যা সম্ভবত আগের পরিকল্পনায়।

হয়তো বাগের আগমন ঠিকভাবে নথিভুক্ত হচ্ছে না। গুরুত্ব নির্ধারণ দুর্বল। হয়তো কোনো সক্ষমতাই আগে থেকে বরাদ্দ নেই। অথবা একই ধরনের ত্রুটি বারবার তৈরি হওয়ার মূল কারণ ধরা হচ্ছে না।

কোন বিষয়গুলো রিসোর্স ভাগ নির্ধারণে প্রভাব ফেলে?

শুরুর পর্যায়ের একটি স্টার্টআপ এবং বহু বছর ধরে হাজারো গ্রাহক ব্যবহার করছেন—এমন একটি প্রতিষ্ঠিত পণ্যের জন্য একই ভাগ যৌক্তিক নয়।

পণ্যের পরিপক্বতা অনেক কিছু বদলে দেয়

নতুন পণ্যের শুরুতে দল হয়তো এখনও বুঝছে ব্যবহারকারী আসলে কী চায়। সেখানে নতুন ফিচার পরীক্ষা ও পরিবর্তনের গতি খুব কমিয়ে দিলে শেখার গতিও কমে যেতে পারে।

কিন্তু কয়েক বছর পর একই পণ্যে যদি বড় ব্যবহারকারীভিত্তি তৈরি হয়, গুরুত্বপূর্ণ ব্যবসায়িক কাজ তার ওপর নির্ভর করে এবং নিয়মিত অর্থপ্রদানকারী গ্রাহক থাকে, তাহলে একটি ত্রুটির প্রভাবও অনেক বড় হয়।

একটি ছোট ভাঙন তখন হাজারো মানুষের কাজে প্রভাব ফেলতে পারে।

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

বাগ ব্যাকলগের সংখ্যা নয়, প্রবণতা দেখুন

“আমাদের ব্যাকলগে ১৮৭টি বাগ আছে”—এই সংখ্যাটি একা খুব বেশি কিছু বলে না।

প্রথম প্রশ্ন হওয়া উচিত, সংখ্যাটি বাড়ছে, কমছে, নাকি মোটামুটি স্থির?

যদি প্রতি কাজের চক্রে নতুন বাগ আসছে সমাধান হওয়া বাগের চেয়ে দ্রুত, তাহলে ব্যাকলগ সুস্থ অবস্থায় নেই। আজ হয়তো বড় সমস্যা হচ্ছে না, কিন্তু কয়েকটি চক্র পরে অগ্রাধিকার নির্ধারণ আরও কঠিন হয়ে যাবে।

আবার ব্যাকলগে অনেক পুরোনো কম-গুরুত্বের ত্রুটি থাকতে পারে, কিন্তু নতুন গুরুতর সমস্যা কম আসছে এবং গুরুত্বপূর্ণ বাগ দ্রুত সমাধান হচ্ছে। সেটি সম্পূর্ণ ভিন্ন পরিস্থিতি।

ব্যাকলগ ব্যবস্থাপনায় এক দিনের মোট সংখ্যার চেয়ে সময়ের সঙ্গে তার গতিপথ বেশি গুরুত্বপূর্ণ।

অংশীজনদের কাছে এই সমঝোতাটি দৃশ্যমান করবেন কীভাবে

অনেক ইঞ্জিনিয়ারিং দলের সমস্যা কেবল জনবল কম হওয়া নয়; বড় সমস্যা হলো তাদের সময় কোথায় যাচ্ছে সেটি প্রতিষ্ঠানের অন্যরা দেখতে পাচ্ছেন না।

নেতৃত্ব রোডম্যাপে পাঁচটি ফিচার দেখছে। স্প্রিন্ট শেষে তিনটি এসেছে। বাইরে থেকে মনে হতে পারে ইঞ্জিনিয়ারিং দল ধীর।

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

তাই সক্ষমতা কীভাবে ভাগ হচ্ছে, সেটি স্পষ্টভাবে জানানো দরকার।

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

এটি অজুহাত নয়। এটি পরিকল্পনার তথ্য।

বাগ ফিক্সে সময় দেওয়া যদি ব্যবসার জন্য প্রয়োজনীয় হয়, তাহলে সেই কাজও ব্যবসায়িক আলোচনায় দৃশ্যমান হওয়া উচিত।

একই প্রতিবেদনে ফিচারের অগ্রগতি ও বাগের অবস্থা দেখান

শুধু “কয়টি ফিচার প্রকাশ হয়েছে” দেখালে পণ্যের স্বাস্থ্যের অর্ধেক গল্পই দেখা যায়।

নিয়মিতভাবে কয়েকটি বিষয় দেখা যেতে পারে:

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

লক্ষ্য অকারণ পরিমাপ তৈরি করা নয়। লক্ষ্য হলো অনুমানের বদলে তথ্যের ভিত্তিতে আলোচনা করা।

কেউ যদি প্রশ্ন করেন, “বাগে এত সময় কেন যাচ্ছে?”, দল তখন বলতে পারবে—গত কয়েকটি চক্র ধরে নতুন বাগ সমাধানের চেয়ে দ্রুত আসছে, তাই এবার স্থিতিশীলতার জন্য বেশি সক্ষমতা রাখা হয়েছে।

এ ধরনের ব্যাখ্যা অনেক বেশি কার্যকর।

বাগ ব্যাকলগ ও ফিচার ব্যাকলগ আলাদা রাখা উচিত?

অনেক ক্ষেত্রে আলাদা রাখা সুবিধাজনক। তবে একেবারে বিচ্ছিন্ন করা উচিত নয়।

ফিচার ব্যাকলগে সাধারণত ব্যবহারকারীর মূল্য, ব্যবসার সুযোগ, কৌশলগত গুরুত্ব এবং কাজের পরিমাণ বিবেচনা করা হয়। বাগ ব্যাকলগে গুরুত্ব, কত ঘনঘন হচ্ছে, কতজন ব্যবহারকারী ক্ষতিগ্রস্ত, বিকল্প পথ আছে কি না এবং পুনরাবৃত্তির ঝুঁকি—এসব বেশি গুরুত্বপূর্ণ।

একই তালিকায় সবকিছু ঢুকিয়ে দিলে ছোট আকারের কিন্তু গুরুত্বপূর্ণ বাগ বড় ফিচারের নিচে চাপা পড়ে যেতে পারে।

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

ভালো পদ্ধতি হলো, তালিকা আলাদা হতে পারে; কিন্তু পরিকল্পনার সিদ্ধান্ত এক জায়গায় নিতে হবে।

একটি দল কীভাবে বাস্তবে রিসোর্স ভাগ ঠিক করতে পারে?

এই সিদ্ধান্ত নিয়ে মাসের পর মাস তাত্ত্বিক বিতর্ক করার দরকার নেই। বরং একটি সহজ ও নিয়মিত প্রক্রিয়া থাকাই বেশি কার্যকর।

১. আগে বাগ ব্যাকলগ পরিষ্কার করুন

একই সমস্যার একাধিক নথি আছে কি না, কোনো বাগ ইতিমধ্যে সমাধান হয়েছে কি না, সমস্যা পুনরায় তৈরি করা যায় কি না—এসব আগে দেখুন।

বছরের পর বছর পুরোনো এবং আর প্রাসঙ্গিক নয় এমন ত্রুটি ব্যাকলগে রেখে দিলে সংখ্যা বাড়ে, কিন্তু সিদ্ধান্তের মান বাড়ে না।

২. ফিচার ব্যাকলগের সঙ্গে বাগ ব্যাকলগও একই পরিকল্পনায় আনুন

স্প্রিন্ট প্ল্যানিংয়ের আগে শুধু নিউ ফিচারের তালিকা দেখলে হবে না। ইঞ্জিনিয়ারিং লিড বা দায়িত্বপ্রাপ্ত ব্যক্তিকে বাগের বর্তমান অবস্থাও তুলে ধরতে হবে।

কোনো গুরুতর সমস্যা আছে কি? কোন বাগ বারবার গ্রাহকের অভিযোগ তৈরি করছে? কোনো প্রযুক্তিগত ত্রুটি কি নতুন কাজের গতি কমাচ্ছে?

ফিচারের অগ্রাধিকারের পাশাপাশি এগুলোও দেখা দরকার।

৩. একটি প্রাথমিক ভাগ ঠিক করুন

দল সাময়িকভাবে সক্ষমতার একটি ভাগ ঠিক করতে পারে। সেটি শতকরা হারে হতে পারে, স্টোরি পয়েন্টে হতে পারে, প্রকৌশলী-দিনের হিসাবে হতে পারে—যেটি দলের জন্য সহজ।

মূল কথা হলো, এটি একটি প্রাথমিক ব্যবস্থা; স্থায়ী আইন নয়।

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

এই পরিবর্তন করার ক্ষমতাটিই বেশি গুরুত্বপূর্ণ।

৪. গুরুতর বাগকে পরিকল্পনার ওপর অগ্রাধিকার দিন

প্রাথমিক ভাগ পরিকল্পনার জন্য। জরুরি ঘটনার জন্য নয়।

যে ত্রুটি মূল সুবিধা বন্ধ করছে, তথ্য হারানোর ঝুঁকি তৈরি করছে বা গুরুত্বপূর্ণ গ্রাহকের কাজ থামিয়ে দিচ্ছে, সেটির জন্য আলাদা দ্রুত সিদ্ধান্তের ব্যবস্থা থাকা উচিত।

তাহলে জরুরি মুহূর্তে “এটা কি এই স্প্রিন্টে নেওয়া হবে?”—এই বিতর্ক নতুন করে করতে হয় না।

৫. নির্দিষ্ট বিরতিতে ভাগ পুনরায় দেখুন

প্রতি স্প্রিন্টে ভাগ বদলানোর দরকার নেই। আবার ছয় মাস আগে নেওয়া সিদ্ধান্তও অন্ধভাবে চালিয়ে যাওয়া উচিত নয়।

দল মাসিক, কয়েকটি স্প্রিন্ট পরপর বা ত্রৈমাসিক পরিকল্পনার সময় ভাগ পুনরায় পর্যালোচনা করতে পারে।

প্রশ্নগুলো খুব সহজ:

বাগ ব্যাকলগ কোন দিকে যাচ্ছে? গুরুতর ত্রুটি বাড়ছে কি? ফিচারের কাজ অস্বাভাবিকভাবে আটকে আছে কি? গ্রাহক সহায়তা দলের চাপ বেড়েছে কি? সামনে বড় প্রকাশ আছে কি? প্রকৌশলীরা কি প্রায় সব সময় আগুন নেভানোর মতো জরুরি কাজে ব্যস্ত?

এই উত্তরগুলোই পরের ভাগ ঠিক করতে সাহায্য করবে।

কখন নিউ ফিচার বন্ধ রেখে শুধু বাগ ফিক্স করা উচিত?

এটি স্বাভাবিক অবস্থা হওয়া উচিত নয়। তবে কিছু পরিস্থিতিতে সাময়িকভাবে নতুন ফিচারের কাজ থামানো যুক্তিযুক্ত হতে পারে।

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

এ অবস্থায় সীমিত সময়ের জন্য স্থিতিশীলতা-কেন্দ্রিক একটি কাজের চক্র নেওয়া যেতে পারে।

তবে শেষ কোথায়, সেটি আগে থেকেই পরিষ্কার থাকা দরকার।

“সব বাগ শেষ না হওয়া পর্যন্ত ফিচার বন্ধ”—এটি ভালো লক্ষ্য নয়। কারণ সব বাগ শেষ হওয়ার কোনো নিশ্চিত সীমা নেই।

বরং লক্ষ্য হতে পারে—উচ্চ-গুরুত্বের বাগ একটি গ্রহণযোগ্য পর্যায়ে নামবে, পুনরাবৃত্ত সমস্যার মূল কারণ ঠিক হবে এবং গুরুত্বপূর্ণ কাজের ধারার স্থিতিশীলতা ফিরে আসবে। তারপর স্বাভাবিক ফিচার উন্নয়ন আবার শুরু হবে।

ব্যবসায়িক বাস্তবতাকে বাদ দিলে পরিকল্পনা বাস্তব থাকে না

শুধু প্রকৌশলগত স্বাস্থ্য দেখে রিসোর্স ভাগ করলে কখনও কখনও গুরুত্বপূর্ণ ব্যবসায়িক সময় হারিয়ে যেতে পারে।

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

এই সময় সাময়িকভাবে নিউ ফিচারে বেশি সক্ষমতা দেওয়া অযৌক্তিক নয়।

কিন্তু এর মূল্য কী, সেটিও পরিষ্কার থাকতে হবে।

যেমন, দল বলতে পারে—পরের দুই স্প্রিন্টে ফিচারের কাজ বেশি হবে, ফলে কম-গুরুত্বের বাগ ব্যাকলগ কিছুটা বাড়তে পারে।

এটি সচেতন সিদ্ধান্ত।

সমস্যা হয় যখন একই ঘটনা নীরবে ঘটে। নেতৃত্ব নতুন ফিচার চাপ দেয়, বাগ জমতে থাকে, তারপর কয়েক মাস পর প্রশ্ন ওঠে—পণ্য এত অস্থিতিশীল কেন?

রিসোর্স ভাগ যদি ব্যবসায়িক সিদ্ধান্ত হয়, তার ঝুঁকিটিও ব্যবসায়িক সিদ্ধান্তের অংশ হওয়া উচিত।

টেক ডেট আর বাগ ফিক্স কি একই জিনিস?

পুরোপুরি নয়, যদিও দুটির মধ্যে সম্পর্ক আছে।

বাগ সাধারণত দৃশ্যমান ভুল আচরণ—পণ্য যেভাবে কাজ করার কথা, সেভাবে কাজ করছে না।

টেক ডেট হলো প্রযুক্তিগত কাঠামোর এমন আপস বা দুর্বলতা, যেটি এখনই দৃশ্যমান বাগ তৈরি না করলেও নতুন কাজ ধীর করতে পারে, পরিবর্তন কঠিন করতে পারে বা ভবিষ্যতে ত্রুটির ঝুঁকি বাড়াতে পারে।

ধরা যাক, পুরোনো একটি মডিউলে বারবার ত্রুটি হচ্ছে। প্রতি বার আলাদা করে বাগ ঠিক করা যায়। কিন্তু যদি মূল কোডই ভঙ্গুর হয়, তাহলে কোনো এক পর্যায়ে সেই মূল কাঠামো ঠিক করা বেশি কার্যকর।

এখানেই রিসোর্স ভাগের আরেকটি স্তর আসে।

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

তাই একই ধরনের বাগ বারবার ফিরছে কি না, সেটিও দেখতে হবে।

সাধারণ ভুল ও সমাধান

“সময় পেলে বাগ ফিক্স করব”

এটি সম্ভবত সবচেয়ে পরিচিত ব্যর্থতা।

স্প্রিন্ট সাধারণত নিজের থেকে ফাঁকা হয়ে যায় না। প্রোডাক্ট দলের কাছে নতুন অনুরোধ থাকে, ইঞ্জিনিয়ারিং দলের কাছে উন্নতির কাজ থাকে, নেতৃত্বের কাছে সময়সীমা থাকে।

যে কাজের জন্য পরিকল্পনায় জায়গা নেই, সেটি বাস্তব কাজেও প্রায়ই জায়গা পায় না।

সব বাগকে সর্বোচ্চ অগ্রাধিকার দেওয়া

অগ্রাধিকারের ব্যবস্থা তখনই কাজ করে, যখন কম গুরুত্বপূর্ণ সমস্যাকে অপেক্ষা করানো যায়।

একটি বানান ভুল, খুব বিরল কোনো পরিস্থিতিতে দেখা দেওয়া সমস্যা এবং পেমেন্ট ব্যর্থতা যদি একই জরুরি তালিকায় যায়, তাহলে সত্যিকারের জরুরি সমস্যা সামনে এলে আলাদা করে বোঝা কঠিন হবে।

ট্রায়াজের অর্থই হলো—কিছু বাগ অপেক্ষা করবে।

আগুন নেভানোর কাজকেই স্থায়ী অভ্যাস বানানো

একটি অস্থিতিশীল প্রকাশের পর কয়েকটি স্প্রিন্ট বাগে বেশি মনোযোগ দেওয়া যৌক্তিক। কিন্তু দল যদি মাসের পর মাস শুধু নতুন আসা ত্রুটি সামলায়, তাহলে প্রশ্ন করা দরকার—এত ত্রুটি তৈরি হচ্ছে কেন?

পরীক্ষায় ঘাটতি আছে? প্রযুক্তিগত কাঠামো দুর্বল? প্রকাশ প্রক্রিয়ায় সমস্যা? প্রয়োজনীয়তা অস্পষ্ট? পর্যবেক্ষণ ব্যবস্থা দুর্বল?

শুধু বাগ বন্ধ করে গেলে মূল সমস্যাটি থেকেই যেতে পারে।

স্প্রিন্ট প্ল্যানিংয়ে আলোচনাটি কেমন হওয়া উচিত

স্বাস্থ্যকর পরিকল্পনার আলোচনা সাধারণত “ফিচার নাকি বাগ?” দিয়ে শুরু না করে “এখন আমাদের সবচেয়ে বড় ঝুঁকি কোথায়?”—এই প্রশ্ন দিয়ে শুরু হয়।

প্রোডাক্ট ম্যানেজার দেখবেন ব্যবসার সুযোগ ও রোডম্যাপের চাপ। ইঞ্জিনিয়ারিং লিড দেখবেন প্রযুক্তিগত স্বাস্থ্য, গুরুতর ত্রুটির ঝুঁকি এবং কাজের জটিলতা। গ্রাহক সহায়তা বা বিক্রয় দল দেখবে ব্যবহারকারীর বাস্তব সমস্যা।

একটি বাস্তবসম্মত আলোচনা এমন হতে পারে:

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

এখানে সিদ্ধান্ত পরিষ্কার। সবাই জানে কোন সমঝোতা হয়েছে এবং কোন পরিস্থিতিতে পরিকল্পনা বদলাবে।

রিসোর্স ভাগের আসল কাজও এটিই—কোনো জাদুকরী শতকরা হার বের করা নয়, বরং সীমিত সক্ষমতা নিয়ে সচেতন সিদ্ধান্ত নেওয়া।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

সব বাগ কি সমান গুরুত্বপূর্ণ?

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

একটি স্প্রিন্টে বাগ ফিক্সের জন্য নির্দিষ্ট শতকরা সময় রাখা কি দরকার?

নির্দিষ্ট সক্ষমতা রাখা অনেক দলের জন্য কার্যকর হতে পারে, তবে সবার জন্য একই শতকরা হার নেই। পণ্যের পরিপক্বতা, বাগ ব্যাকলগ, দলের আকার এবং বর্তমান ব্যবসায়িক পরিস্থিতি দেখে একটি প্রাথমিক ভাগ ঠিক করাই ভালো।

কখন নিউ ফিচার বন্ধ রেখে শুধু বাগ ফিক্স করা উচিত?

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

বাগ ব্যাকলগ কত বড় হলে চিন্তার বিষয়?

শুধু মোট সংখ্যা দেখে সিদ্ধান্ত নেওয়া উচিত নয়। নতুন বাগ কত দ্রুত আসছে, কত দ্রুত সমাধান হচ্ছে, উচ্চ-গুরুত্বের সমস্যা বাড়ছে কি না এবং পুরোনো অমীমাংসিত বাগ জমছে কি না—এই প্রবণতাই বেশি গুরুত্বপূর্ণ।

শেষ পর্যন্ত লক্ষ্য নির্দিষ্ট অনুপাত নয়, নিয়ন্ত্রণ

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

সমস্যা শুরু হয় তখনই, যখন একটিকে “আসল কাজ” আর অন্যটিকে “পরে করা যাবে” বলে ধরে নেওয়া হয়।

ভালো রিসোর্স ভাগ মানে প্রতি স্প্রিন্টে একই শতকরা হার মেনে চলা নয়। বরং দল জানবে কোন কাজে কত সময় যাচ্ছে, গুরুতর বাগ কখন পরিকল্পনা বদলাবে, বাগ ব্যাকলগ কোন দিকে যাচ্ছে এবং কখন বরাদ্দ পুনর্বিন্যাস করতে হবে।

পরের স্প্রিন্ট প্ল্যানিংয়ে একটি কাজ করুন—শুধু ফিচার ব্যাকলগ নয়, বাগ ব্যাকলগও একই আলোচনায় খুলুন। তারপর বর্তমান পরিস্থিতির জন্য একটি প্রাথমিক রিসোর্স ভাগ ঠিক করুন।

স্থায়ী নিয়ম হিসেবে নয়।

বাস্তব পরিস্থিতি বদলালে সেই ভাগও বদলাবে—এটাই স্বাভাবিক।

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