এখনকার ভাবনা · ছয় পর্বে
6টির মধ্যে পর্ব 2 AI-কে নিয়ে ডেভেলপমেন্টের গোটা ব্যবস্থা গড়া
কাজের চাহিদাগুলোই AI ডেলিভারির নিয়ন্ত্রণের জায়গা
AI-কে নিয়ে কাজ ঠিক পথে থাকে যখন কী আচরণ চাই, কী বাধা আছে, কোথায় ব্যতিক্রম আর কোন প্রমাণে কাজ মেনে নেব—এসব লিখে রাখা ইঞ্জিনিয়ারিংয়ের ইনপুট হয়।
চাহিদাটা যদি শুধু কথাবার্তায় থাকে, অটোমেশনের হাতে নিয়ন্ত্রণের কোনও ভিত্তি নেই। আছে শোনা কথা।
টিকিটের নামটা গোটা চুক্তি নয়
টিকিটের নামে সাধারণত ইচ্ছেটা লেখা থাকে: একসঙ্গে approve করার ব্যবস্থা করো, alert panel বদলাও, মোবাইলে চালাও, পেজ migrate করো। ইমপ্লিমেন্টেশনের পরেও ঠিক কী কী আচরণ থাকতে হবে, সেটা পুরো বলা থাকে না। প্রোডাক্টের ভুলগুলো বেশির ভাগ ওই বাদ পড়া জায়গাতেই থাকে: অনুমতি, অর্ধেক ডেটা, পুরনো state, আবার চেষ্টা, navigation, timezone, accessibility, বা কাজের অর্ধেক সফল হলে কী হবে।
AI-কে নিয়ে কাজের নিয়ন্ত্রণের ভিত্তি হিসেবে functional requirement দেখি। কে কাজ করছে, আগে কী সত্যি হতে হবে, কী অবস্থা দেখা যাবে, কী action করা যায়, ব্যতিক্রম কী, কোন শর্ত নড়বে না আর গ্রহণের প্রমাণ কী—এসব বলা থাকবে। শুধু প্রম্পটের চেয়ে টেকসই কিছু মেনে ইমপ্লিমেন্টেশন এগোতে পারবে।
প্রতিটা কাজকে আইনি কাগজ বানানোর কথা বলছি না। যতটা আচরণ বলা দরকার যাতে ঠিক কাজ আর শুধু ঠিক মনে হওয়া কাজ আলাদা করা যায়, ততটাই। এ তফাত না থাকলে AI দারুণ আউটপুট বানালেও দল চুপচাপ প্রোডাক্টের মূল শর্ত হারিয়ে ফেলতে পারে।
সোজা পথের ধার ঘেঁষে একটা ভুল
পরিচয় বাদ দেওয়া একটি bulk-action উদাহরণ ধরা যাক। সামনে থেকে চাহিদা সহজ: ব্যবহারকারী কয়েকটা record বেছে একসঙ্গে approve করবেন। তৈরি ইমপ্লিমেন্টেশন selection দেখাল, API ডাকল, success message দেখাল। নির্দিষ্ট পরীক্ষায় সব বাছা আর সব সফল হওয়ার পথ দেখা হল।
আসল কাজের মধ্যে কিন্তু মেশানো permission আর আংশিক ব্যর্থতাও ছিল। কিছু record approve করা যায়, কিছু শুধু পড়া যায়। backend অনুরোধের কিছুটা মানতে, বাকিটা ফেরাতে পারে। প্রথম ইমপ্লিমেন্টেশন request ফিরলেই পুরো selection মুছে success বলেছিল। দেখতে শেষ, কিন্তু যে record-গুলোর দিকে এখনও নজর দরকার, সেগুলোই আড়াল হল।
এ ধরনের ভুল আটকাতে কাজের চাহিদার চুক্তির সঙ্গে trace matrix রাখি। প্রতিটা চাহিদার স্থির পরিচয়, কে কাজ করবে, আগের শর্ত, প্রত্যাশিত আচরণ, ব্যতিক্রম, না বদলানো শর্ত আর দরকারি প্রমাণ থাকে। তার সঙ্গে কোন ইমপ্লিমেন্টেশন, পরীক্ষা, ব্রাউজারের পরিস্থিতি আর রিলিজের প্রমাণ জুড়ছে, সেটা দেখা যায়। জিনিসটা ইচ্ছে করেই সাদামাটা। ব্যবহারকারী ধরার আগেই বাদ পড়া আচরণ চোখে পড়াই তার দাম।
যা অটোমেট করি
ছড়ানো ইনপুট থেকে দেখে মেনে নেওয়ার মতো চাহিদার তালিকা তৈরি করা অটোমেট করি। প্রোডাক্টের নোট, ডিজাইন, পুরনো পরীক্ষা, support-এর প্রমাণ আর রিপোজিটরির নিয়ম থেকে আচরণ তোলা যায়। একই কথা এক করা, বিরোধ দেখানো, অনির্দিষ্ট state চেনা আর মেনে নেওয়া চাহিদা দিয়ে কাজের প্যাকেট বানানো যায়।
যখন বানানোর মতো যথেষ্ট স্থির চাহিদা আছে, অটোমেশন পরীক্ষার উদাহরণ, ব্রাউজারের পথ আর ঝুঁকির জায়গা সাজেস্ট করতে পারে। বদলে কোন চাহিদা ছোঁয়া হল, কোনটার পক্ষে প্রমাণ আছে, আর কোনটা এখনও অনুমান—ধরে রাখতে পারে। চাহিদা বদলালে কার কার ওপর প্রভাব পড়বে খুঁজে দেখা যায়; কারও সব consumer মনে থাকার দরকার পড়ে না।
মিথ্যে নিশ্চয়তাও যেন ব্যবস্থা না দেয়, সেটাও চাই। দুটো উৎসে permission-এর নিয়ম আলাদা হলে, বা খালি state কেমন হবে বলা না থাকলে, সেটা স্পষ্ট প্রশ্ন হবে। শেষ যে নথি পড়েছে সেটাই ভরসা করে নিশ্চিত ইমপ্লিমেন্টেশনের চেয়ে অনুমানের তালিকা বেশি কাজে লাগে।
যে সিদ্ধান্ত মানুষেরই থাকবে
উৎসে বিরোধ হলে কোন চাহিদা মানতে হবে, মানুষ ঠিক করবেন। পুরনো আচরণটা না নড়ার শর্ত, শুধু ইতিহাসে জমে থাকা কিছু, না ইচ্ছে করে বদলাতে চাওয়া প্রোডাক্ট—সেটাও। কোন ব্যতিক্রম না মিটলে রিলিজ থামবে আর কোনটা পরের ধাপে করা যাবে, সেই সিদ্ধান্তও মানুষের।
মানুষের ওপর বা কাজের ব্যবস্থায় প্রভাব পড়ে এমন চাহিদায় বিচারটা আরও জরুরি। মুছে ফেলার action, permission-এর সীমানা, অনিশ্চিত পরামর্শ বা আংশিক ব্যর্থতার ঠিক আচরণ দেখতে মিল আছে কি না দিয়ে বার করা যায় না। ব্যবহারকারী আর ব্যবসার পরিণতিটা কাউকে বুঝতে হবে।
মেনে নেওয়ার ভিত্তি স্মৃতি নয়, প্রমাণ হোক। রিভিউয়ার যেন দেখতে পান কী বদলেছে, কোন চাহিদা চালিয়ে দেখা হয়েছে, যাচাইয়ে কী ফেল করেছে আর কী এখনও প্রমাণিত নয়। সিদ্ধান্ত মানুষেরই, কিন্তু তথ্য জোড়া লাগানোর কাজটা হাতে করে করতে হবে কেন?
স্পষ্ট হওয়া মানে ভবিষ্যৎ আটকে দেওয়া নয়
এখানে একটা ছাড় দেওয়ার দিক আছে। স্পষ্ট চাহিদা বানাতে পরিশ্রম লাগে, আর সেই স্পষ্টতাই ভুল নিশ্চয়তার ভাব দিতে পারে। প্রোডাক্ট বদলায়। মতামত থেকে বাদ পড়া state জানা যায়। API বদলায়। প্রতিটা বাক্যকে চিরস্থায়ী আইন ধরলে, বা দরকারি বদলকে নথির নিয়ম ভাঙা মনে হলে, সেই চাহিদার ব্যবস্থাই ক্ষতি করে।
যে শর্ত বদলাবে না, এখনকার সিদ্ধান্ত, আর এখনও পরীক্ষা করার অনুমান—এই তিনটে আলাদা রাখি। অনুমতি নেই এমন মানুষ কোনও action করতে পারবেন না, এটা স্থির শর্ত হতে পারে। action কোথায় দেখাব, সেটা এখনকার সিদ্ধান্ত। কয়েকটা action একসঙ্গে রাখলে খাটনি কমবে, সেটা অনুমান। তিনটে কথার ক্ষমতা আর আয়ু সমান হওয়া উচিত নয়।
চাহিদা বাঁচিয়ে রাখা মানে প্রোডাক্ট জমিয়ে রাখা নয়। বুঝেশুনে, বলে বদলানো। চাহিদা নড়লে কোথায় প্রভাব পড়ে, কোন প্রমাণ আবার লাগবে, আর কোন শর্ত অক্ষুণ্ণ থাকবে—ব্যবস্থা সেটা দেখাক। তবেই বদলের সঙ্গে মানিয়ে নেওয়া দিশা হারানো হয়ে যায় না।