সফটওয়্যারে নতুন ফিচার যোগ করার সময় সাধারণত খুব বেশি আপত্তি ওঠে না। সমস্যা শুরু হয় কয়েক বছর পর। তখন দেখা যায়, কিছু ফিচার আছে যেগুলো খুব কম মানুষ ব্যবহার করছেন, অথচ সেগুলো চালু রাখতে নিয়মিত কাজ করতে হচ্ছে। নতুন সংস্করণ বের হলে পরীক্ষা করতে হচ্ছে, পুরোনো কোড ঠিক রাখতে হচ্ছে, নিরাপত্তার সমস্যা দেখা দিলে সমাধান করতে হচ্ছে। কখনো আবার একটি পুরোনো ফিচারের কারণে নতুন কোনো পরিবর্তন করাও কঠিন হয়ে পড়ে।
এই অবস্থায় ফিচারটি সরিয়ে দেওয়ার কথা ওঠা অস্বাভাবিক নয়। কিন্তু এখানেই তাড়াহুড়ো করলে ভুল হতে পারে। ব্যবহার কম—এই তথ্যটি গুরুত্বপূর্ণ, কিন্তু সিদ্ধান্ত নেওয়ার জন্য একা যথেষ্ট নয়।
Product Sunset মূলত এমন একটি পরিকল্পিত প্রক্রিয়া, যেখানে কোনো ফিচার, API, সেবা বা কখনো পুরো পণ্য ধীরে ধীরে বন্ধ করা হয়। এখানে “বন্ধ করা” অংশটির চেয়ে “কীভাবে বন্ধ করা হচ্ছে” অংশটি বেশি গুরুত্বপূর্ণ। কারণ একটি ফিচার সরিয়ে দিলে শুধু সফটওয়্যারের পর্দা থেকে একটি অপশন কমে না; কারও কাজের পদ্ধতি, পুরোনো তথ্য কিংবা অন্য কোনো সফটওয়্যারের সংযোগও প্রভাবিত হতে পারে।
কম ব্যবহার দেখেই ফিচার বাদ দেওয়া কেন ঠিক নয়
প্রোডাক্ট টিমের ড্যাশবোর্ডে একটি ফিচারের ব্যবহার খুব কম দেখা গেল। প্রথম প্রতিক্রিয়া হতে পারে, এটি রেখে লাভ কী?
সংখ্যাটি একটু অন্যভাবে দেখলে উত্তর বদলে যেতে পারে।
ধরা যাক, কোনো ব্যবসায়িক সফটওয়্যারের একটি তথ্য রপ্তানির সুবিধা মাত্র 2% ব্যবহারকারী ব্যবহার করেন। সংখ্যাটি নিঃসন্দেহে ছোট। কিন্তু সেই ব্যবহারকারীরা যদি প্রতিষ্ঠানের প্রশাসক হন এবং মাস শেষে হিসাবের তথ্য অন্য ব্যবস্থায় পাঠাতে ওই ফিচারটি ব্যবহার করেন, তাহলে সেটি তাদের জন্য ছোট কোনো সুবিধা নয়।
আবার কিছু ফিচার নিয়মিত ব্যবহারের জন্য তৈরিই নয়। বছরের শেষে প্রতিবেদন নামানো, পুরোনো তথ্য রপ্তানি করা বা বিশেষ কোনো প্রশাসনিক কাজের সুবিধা মাসের পর মাস ব্যবহার না হলেও প্রয়োজনের সময় খুব গুরুত্বপূর্ণ হয়ে উঠতে পারে।
তাই শুধু “গত 30 দিনে কতজন ব্যবহার করেছেন” দেখে স্থায়ী সিদ্ধান্ত নেওয়া বিপজ্জনক হতে পারে।
আরেকটি প্রশ্নও করা দরকার। ফিচারটি মানুষ ব্যবহার করছেন না কেন?
হতে পারে সেটির প্রয়োজন নেই। আবার এমনও হতে পারে, ব্যবহারকারী সেটি সহজে খুঁজে পাচ্ছেন না। নামটি অস্পষ্ট, ব্যবহারের ধাপ বেশি, অথবা ফিচারটির অবস্থান এমন জায়গায় যেখানে সাধারণ ব্যবহারকারী পৌঁছানই না।
এই দুই পরিস্থিতির সমাধান এক নয়। প্রথম ক্ষেত্রে ফিচার বন্ধ করার যুক্তি থাকতে পারে। দ্বিতীয় ক্ষেত্রে সমস্যা আসলে নকশা বা ব্যবহারযোগ্যতায়।
পুরোনো ফিচার রেখে দেওয়ারও মূল্য দিতে হয়
কম ব্যবহৃত ফিচার রাখার পক্ষে একটি পরিচিত যুক্তি হলো—“থাকলে ক্ষতি কী?”
ক্ষতি সব সময় সরাসরি দেখা যায় না।
একটি পুরোনো ফিচারের জন্য আলাদা করে সার্ভার খরচ খুব সামান্য হতে পারে, কিন্তু সেটির কোড নতুন পরিবর্তনের সঙ্গে মানিয়ে রাখতে হয়। সফটওয়্যারের অন্য অংশ বদলালে ওই ফিচারটি ভেঙে যাচ্ছে কি না পরীক্ষা করতে হয়। নিরাপত্তার দুর্বলতা পাওয়া গেলে সেটিকেও ঠিক করতে হয়। গ্রাহক সহায়তা দলকে পুরোনো সুবিধাটি বুঝতে হয়, কারণ একজন ব্যবহারকারী হলেও সমস্যা নিয়ে যোগাযোগ করতে পারেন।
এর সঙ্গে আছে প্রযুক্তিগত জটিলতা। পুরোনো কোনো অংশের ওপর অনেক কিছু দাঁড়িয়ে থাকলে নতুন ব্যবস্থা চালু করা কঠিন হয়ে যেতে পারে। তখন একটি কম ব্যবহৃত ফিচার সরিয়ে দেওয়া শুধু পর্দা পরিষ্কার করার সিদ্ধান্ত থাকে না; এটি ভবিষ্যৎ উন্নয়নের পথও সহজ করতে পারে।
তবে এখানেও ভারসাম্য দরকার। যে ফিচারটির রক্ষণাবেক্ষণ প্রায় কোনো চাপই তৈরি করছে না, সেটি শুধু কম ব্যবহার হচ্ছে বলে সরিয়ে দেওয়ার তেমন প্রয়োজন নাও থাকতে পারে।
Product Sunset আর Deprecation এক জিনিস নয়
সফটওয়্যার নিয়ে কাজ করতে গেলে কয়েকটি শব্দ বারবার আসে—Deprecation, Sunset এবং End of Support। এগুলো কাছাকাছি হলেও একই অর্থে ব্যবহার করা ঠিক নয়।
কোনো ফিচার বা API-কে deprecated বলা হলে সাধারণত বোঝানো হয়, সেটি আর ভবিষ্যতের জন্য সুপারিশ করা হচ্ছে না। পুরোনো ব্যবস্থা তখনও কিছুদিন চলতে পারে। ব্যবহারকারী বা ডেভেলপারকে মূলত বলা হচ্ছে, নতুন ব্যবস্থায় যাওয়ার প্রস্তুতি নিন।
Sunset আরও এক ধাপ এগিয়ে। এখানে শেষ পর্যন্ত পুরোনো ফিচার বা সংস্করণ বন্ধ করার পরিকল্পনা থাকে।
আর End of Support মানে নির্মাতার নির্ধারিত সহায়তার সময় শেষ হওয়া। কোনো সফটওয়্যার তখনও চালু থাকতে পারে, কিন্তু আপডেট, সমস্যা সমাধান বা নিরাপত্তা সহায়তা আগের মতো নাও থাকতে পারে।
বাস্তবে প্রতিষ্ঠানভেদে এই শব্দগুলোর প্রয়োগে কিছু পার্থক্য থাকতে পারে। তাই শুধু একটি শব্দ দেখে নয়, সংশ্লিষ্ট নীতিতে কী বলা হয়েছে সেটি বোঝা জরুরি।
সিদ্ধান্তটা আসলে কার ওপর প্রভাব পড়বে, তা দিয়ে শুরু করা উচিত
ফিচারটি কতজন ব্যবহার করছেন, সেই সংখ্যার পাশেই আরেকটি তালিকা থাকা দরকার—কারা ব্যবহার করছেন।
একজন সাধারণ ব্যবহারকারী মাসে একবার কোনো অপশন খুলেছেন আর একটি বড় গ্রাহকের হিসাব ব্যবস্থা প্রতিদিন একটি API ব্যবহার করছে—দুটিকে একই ধরনের “ব্যবহার” হিসেবে দেখা যায় না।
কোনো ফিচার বন্ধ করার আগে তাই কয়েকটি জিনিস পরিষ্কার হওয়া দরকার।
এর ওপর অন্য কোনো ফিচার নির্ভর করছে কি না। কোনো স্বয়ংক্রিয় কাজ চলছে কি না। তৃতীয় পক্ষের সফটওয়্যার এর সঙ্গে যুক্ত কি না। বড় কোনো গ্রাহক নিয়মিত এটি ব্যবহার করছেন কি না। কোনো চুক্তি বা নির্দিষ্ট প্যাকেজে ফিচারটির উল্লেখ আছে কি না।
এই তথ্যগুলো না দেখে শুধু ব্যবহারসংখ্যার গ্রাফ দেখে সিদ্ধান্ত নিলে পরে এমন নির্ভরতা সামনে আসতে পারে, যা আগে ধরা পড়েনি।
API-এর ক্ষেত্রে ঝুঁকিটি আরও বেশি। সাধারণ ব্যবহারকারী হয়তো সরাসরি কোনো API দেখেনই না। কিন্তু সেটি বন্ধ হলে তার ব্যবহৃত অন্য কোনো ব্যবস্থা হঠাৎ কাজ করা বন্ধ করে দিতে পারে।
সবচেয়ে দুর্বল সানসেট ঘোষণা কেমন
“এই ফিচারটি আগামী মাস থেকে বন্ধ হয়ে যাবে।”
এই একটি বাক্যে কোম্পানির কাজ শেষ হতে পারে, ব্যবহারকারীর নয়।
যিনি ফিচারটি ব্যবহার করছেন, তাঁর পরের প্রশ্ন হবে—এখন কী করব?
সানসেটের আসল পরীক্ষা এখানেই। পুরোনো ব্যবস্থার বদলে নতুন কোনো ফিচার আছে কি? তথ্য বের করে নেওয়ার সুযোগ আছে কি? API বদলালে নতুন সংস্করণে কীভাবে যেতে হবে? ব্যবহারকারীকে নিজের কাজের পদ্ধতি পাল্টাতে হবে কি?
ফিচার বন্ধ করার সিদ্ধান্তের সঙ্গে এই উত্তরগুলোও তৈরি থাকা উচিত।
সব ক্ষেত্রে নতুন ফিচার বানিয়ে দিতে হবে এমন নয়। কোনো সুবিধা হয়তো সত্যিই অপ্রয়োজনীয় হয়ে গেছে। কিন্তু ফিচারটির সঙ্গে যদি ব্যবহারকারীর তথ্য বা গুরুত্বপূর্ণ কাজ যুক্ত থাকে, তাহলে বিকল্প না দিয়ে হঠাৎ বন্ধ করা সমস্যার কারণ হতে পারে।
কতদিন আগে জানানো উচিত?
এর কোনো একক উত্তর নেই।
অনেক সময় ছোট একটি পরিবর্তনের জন্য কয়েক সপ্তাহই যথেষ্ট। আবার একটি বড় API বা প্রতিষ্ঠানের দৈনন্দিন কাজে ব্যবহৃত ব্যবস্থা বদলাতে কয়েক মাস লাগতে পারে।
এই জায়গায় অন্য কোম্পানির নীতি কপি করা খুব একটা কাজে আসে না। কোনো প্রতিষ্ঠান 6 মাস সময় দিয়েছে বলে আপনার পণ্যের জন্যও 6 মাস যথেষ্ট হবে, এমন নয়।
ব্যবহারকারীকে কী করতে হবে, সেটিই সময় নির্ধারণের ভালো ভিত্তি।
যদি শুধু নতুন একটি অপশন বেছে নিলেই কাজ শেষ হয়, প্রস্তুতি কম লাগবে। কিন্তু ব্যবহারকারীকে তথ্য স্থানান্তর করতে হলে, নিজের সফটওয়্যারের কোড বদলাতে হলে বা কর্মীদের নতুন পদ্ধতি শেখাতে হলে সময়ও বেশি প্রয়োজন হবে।
নিরাপত্তার ক্ষেত্রে অবশ্য পরিস্থিতি ভিন্ন হতে পারে। গুরুতর দুর্বলতা থাকলে পুরোনো ফিচার দীর্ঘদিন চালু রাখা উল্টো ঝুঁকি বাড়াতে পারে। তখন স্বাভাবিক সানসেট সময়সীমা ছোট করার প্রয়োজন হতে পারে।
একটি ব্লগ পোস্ট দিয়ে সবাইকে জানানো যায় না
প্রোডাক্ট টিম সিদ্ধান্ত জানিয়ে একটি পোস্ট প্রকাশ করল। ওয়েবসাইটে খবরটি থাকল। কিন্তু যে ব্যবহারকারী প্রতিদিন সরাসরি সফটওয়্যারে ঢোকেন, তিনি হয়তো সেই পোস্ট কোনোদিনই দেখবেন না।
তাই পরিবর্তন যত গুরুত্বপূর্ণ, যোগাযোগের পথও তত সরাসরি হওয়া দরকার।
অ্যাপের ভেতরে বার্তা, ইমেইল, ডকুমেন্টেশন, ডেভেলপারদের জন্য আলাদা নোটিশ—পরিস্থিতি অনুযায়ী একাধিক পথ ব্যবহার করা যেতে পারে। বড় গ্রাহকের গুরুত্বপূর্ণ কাজ প্রভাবিত হলে সরাসরি যোগাযোগও লাগতে পারে।
বার্তাটি খুব দীর্ঘ হওয়ার দরকার নেই। কিন্তু কয়েকটি প্রশ্নের উত্তর সেখানে থাকা উচিত: কী বন্ধ হচ্ছে, কবে হচ্ছে, ব্যবহারকারীকে কিছু করতে হবে কি না এবং পুরোনো ব্যবস্থার বিকল্প কী।
তথ্য হারানোর সম্ভাবনা থাকলে সেই বিষয়টি লুকিয়ে বা অস্পষ্টভাবে বলা উচিত নয়।
একবারে বন্ধ করা সব সময় ভালো সিদ্ধান্ত নয়
জটিল ফিচারের ক্ষেত্রে ধাপে ধাপে এগোনো সুবিধাজনক।
প্রথমে নতুন ব্যবহারকারীকে পুরোনো ফিচার দেওয়া বন্ধ করা যেতে পারে। বিদ্যমান ব্যবহারকারীদের কিছু সময় আগের মতো ব্যবহার করতে দেওয়া যায়। এর মধ্যে বিকল্প ব্যবস্থায় যাওয়ার কাজ চলবে। পরে নির্ধারিত দিনে পুরো ফিচার বন্ধ হবে।
এতে একটি বাড়তি সুবিধা পাওয়া যায়—অজানা নির্ভরতা ধরা পড়ে।
অনেক সময় কোনো পুরোনো ফিচার বছরের পর বছর চুপচাপ একটি ছোট দলের কাজে ব্যবহৃত হচ্ছে। সাধারণ ড্যাশবোর্ডে সেটি বিশেষ চোখে পড়ে না। সানসেটের ঘোষণা হওয়ার পরই দলটি জানায়, তাদের গুরুত্বপূর্ণ একটি কাজ এর ওপর নির্ভর করছে।
এ ধরনের তথ্য আগেই পাওয়া গেলে সিদ্ধান্ত বদলানো বা সময় বাড়ানো সম্ভব।
কখন সিদ্ধান্ত থামিয়ে আবার দেখা দরকার
কোনো ফিচার বন্ধ করার পরিকল্পনা শুরু হয়ে গেছে মানেই সেটি শেষ পর্যন্ত করতেই হবে—এমন নয়।
নতুন তথ্য পাওয়া গেলে সানসেট পিছিয়ে দেওয়াও ভালো প্রোডাক্ট সিদ্ধান্ত হতে পারে।
বিশেষ করে যদি দেখা যায় গুরুত্বপূর্ণ গ্রাহক এখনও ফিচারটির ওপর নির্ভর করছেন, কার্যকর বিকল্প প্রস্তুত হয়নি, ব্যবহারকারী নিজের তথ্য বের করতে পারছেন না কিংবা অন্য কোনো সফটওয়্যারের নির্ভরতা আগে ধরা পড়েনি।
একইভাবে, ব্যবহার কম হওয়ার আসল কারণ যদি অস্পষ্ট থাকে, আগে সেটি বোঝা ভালো। হয়তো ফিচারটি বন্ধ করার দরকার নেই; ব্যবহারপদ্ধতি সহজ করলেই সমস্যার সমাধান হবে।
লিখিত নীতি কেন কাজে লাগে
ছোট প্রোডাক্ট টিমেও Product Sunset নিয়ে কয়েকটি লিখিত নিয়ম থাকা উপকারী।
এটি বড় কোনো নীতিমালা হতে হবে না।
একটি ফিচার বন্ধ করার প্রস্তাব উঠলে কোন তথ্য দেখা হবে, কে ব্যবহারকারীর প্রভাব যাচাই করবেন, গুরুত্বপূর্ণ গ্রাহকদের মতামত প্রয়োজন কি না, বিকল্প প্রস্তুত হয়েছে কি না এবং ঘোষণার দায়িত্ব কার—এগুলো আগে ঠিক থাকলে সিদ্ধান্ত নেওয়া সহজ হয়।
সবচেয়ে কাজে লাগতে পারে একটি সাধারণ নিয়ম: “কম ব্যবহার” নিজে থেকে কোনো ফিচার বন্ধ করার যথেষ্ট কারণ নয়।
এতে ডেভেলপমেন্ট দলের সাময়িক চাপ কিংবা ব্যক্তিগত পছন্দের কারণে তাড়াহুড়ো করে সিদ্ধান্ত নেওয়ার ঝুঁকি কমে।
Product Sunset-এর ভালো সিদ্ধান্ত সাধারণত একটি প্রশ্ন দিয়ে শুরু হয় না, কয়েকটি প্রশ্ন একসঙ্গে দেখতে হয়। ফিচারটি রাখার খরচ কত, সরালে কার সমস্যা হবে এবং সেই মানুষগুলোর জন্য বাস্তব বিকল্প আছে কি না।
এই তিনটির মধ্যে শেষের দুটি উপেক্ষা করলে পরিষ্কার প্রোডাক্ট পাওয়ার বদলে অসন্তুষ্ট ব্যবহারকারী পাওয়া সহজ।
তাই কম ব্যবহারের সংখ্যা দেখলে প্রথম কাজ “Delete” পরিকল্পনা করা নয়। আগে বোঝা দরকার, ওই সংখ্যার পেছনে কারা আছেন এবং ফিচারটি তাদের জন্য আসলে কী কাজ করছে। সেখান থেকেই ভালো Product Sunset সিদ্ধান্ত শুরু হয়।
