ওপেন সোর্স পদ্ধতিতে করুন - AI যুগে InnerSource এর ভূমিকা ও সম্ভাবনা
আধুনিক সংস্থাগুলিকে তাড়া করা প্রশ্ন #
যখন অগণিত ডেভেলপার প্রম্পট ইঞ্জিনিয়ারিং এবং কনটেক্সট ইঞ্জিনিয়ারিং এর গুণাবলী নিয়ে বিতর্ক করে, যখন প্রভাবশালীরা তাদের সর্বশেষ AI কোডিং কৌশল প্রদর্শন করে, এবং যখন স্টার্টআপগুলি AI-প্রথম উন্নয়নের দিকে ঝুঁকে পড়ে, আলোচনায় একটি স্পষ্ট ফাঁক অব্যাহত থাকে। আমরা ব্যক্তিগত উৎপাদনশীলতা এবং ছোট দলের কৌশল নিয়ে আলোচনায় ডুবে আছি, তবুও আমরা বড়, প্রতিষ্ঠিত সংস্থাগুলি কীভাবে AI রূপান্তর নেভিগেট করবে সে বিষয়ে নির্দেশনার জন্য ক্ষুধার্ত।
এটি শুধু একটি বড় এন্টারপ্রাইজ সমস্যা নয়। শক্তিশালী ১০-ব্যক্তির AI দল সহ ছোট স্টার্টআপগুলিও শেষ পর্যন্ত বৃহৎ কোডবেস পরিচালনা করবে এবং রাতারাতি বড় সিস্টেমে স্কেল করবে। মৌলিক প্রশ্ন হয়ে ওঠে: সংস্থাগুলি কীভাবে তাদের সোর্স কোড এবং সহযোগিতার অনুশীলনগুলি প্রস্তুত করে যাতে তারা ভেঙে না পড়ে AI এর সাথে গতিতে নির্বিঘ্নে কাজ করে?
এটি আরও ভাল প্রম্পট লেখা বা আপনার কোপাইলট অভিজ্ঞতা অনুকূল করার বিষয়ে আরেকটি নিবন্ধ নয়। এটি সেই সাংগঠনিক DNA সম্পর্কে যা নির্ধারণ করবে আপনার কোম্পানি AI যুগে উন্নতি করবে নাকি কেবল টিকে থাকবে।
TL;DR: পাঁচটি গুরুত্বপূর্ণ সাংগঠনিক চ্যালেঞ্জ #
AI-চালিত উন্নয়ন পাঁচটি গুরুত্বপূর্ণ সাংগঠনিক চ্যালেঞ্জের মুখোমুখি যা ওপেন সোর্স পদ্ধতি সমাধান করতে পারে:
মানকীকরণ দ্বিধা: সংস্থাগুলি চায় AI তাদের মালিকানাধীন পদ্ধতিগুলি বুঝুক, কিন্তু AI মালিকানাধীনের চেয়ে উন্মুক্ত মানদণ্ডে পারদর্শী। মূল বিষয় হল স্বীকার করা যে AI উন্মুক্ত, মানসম্মত অনুশীলন থেকে ব্যাপকভাবে শিখেছে।
মান নিশ্চয়তা বাধা: AI প্রচুর পরিমাণে ডুপ্লিকেট কোড উৎপন্ন করে, এবং মানুষ সব পর্যালোচনা করতে পারে না। AI কে বারবার চাকা আবিষ্কার করতে দেওয়ার পরিবর্তে, সংস্থাগুলিকে অভ্যন্তরীণভাবে মান-নিশ্চিত কোড ভাগাভাগি করে এবং অন্তহীন পর্যালোচনা চক্র এড়িয়ে দ্বিগুণকরণ প্রতিরোধ করতে হবে।
তথ্য সাইলো সমস্যা: AI আরও স্বায়ত্তশাসিত হওয়ার সাথে সাথে, সংস্থাগুলি চায় এটি ব্যাপক সাংগঠনিক জ্ঞানে অ্যাক্সেস করুক, কিন্তু সাইলোড তথ্য বহু-স্তরের অ্যাক্সেস সমস্যা তৈরি করে। স্বচ্ছ, অ-সাইলোড সংস্থাগুলি AI কে আমলাতান্ত্রিক বাধা ছাড়াই প্রয়োজনীয় তথ্যে অ্যাক্সেস করতে সক্ষম করে।
ডকুমেন্ট ফরম্যাট বিশৃঙ্খলা: AI PowerPoint, Excel এবং মালিকানাধীন ফরম্যাটের সাথে লড়াই করে। ওপেন সোর্স সহযোগিতা স্বাভাবিকভাবেই Markdown-ভিত্তিক ডকুমেন্টেশন এবং ইস্যু-ভিত্তিক সহযোগিতার দিকে আকর্ষিত হয়—এমন ফরম্যাট যা AI সহজেই পার্স এবং বুঝতে পারে।
অনুপস্থিত প্রসঙ্গ সংকট: লোকেরা AI কে স্ন্যাপশট তথ্য দেয় সিদ্ধান্তগুলি “কেন” নেওয়া হয়েছিল সেই গুরুত্বপূর্ণ প্রসঙ্গ ছাড়াই। ওপেন সোর্স সংস্কৃতি স্বাভাবিকভাবেই সিদ্ধান্ত গ্রহণের প্রক্রিয়াগুলি ডকুমেন্ট করে, AI এর উপযুক্ত পরামর্শ দেওয়ার জন্য প্রয়োজনীয় প্রাসঙ্গিক বোধগম্যতা তৈরি করে।
AI কে একজন প্রসঙ্গ-মুক্ত প্রতিভাবান ইঞ্জিনিয়ার হিসেবে ভাবুন যে হঠাৎ আপনার সংস্থায় যোগ দিয়েছে—একজন ওপেন সোর্স অবদানকারীর মতো যে আপনার সিস্টেম, প্রক্রিয়া বা ইতিহাসের কোনো পটভূমি জ্ঞান ছাড়াই এসেছে। আমাদের AI কে সাংগঠনিক পরামর্শদান প্রদান করতে হবে, কিন্তু এটি ব্যক্তিগত প্রচেষ্টা হতে পারে না—এর জন্য প্রয়োজন পদ্ধতিগত, সংস্থা-ব্যাপী সহায়তা যা AI কে শুধু আমরা কী করি তা নয়, কীভাবে এবং কেন করি তা বুঝতে সাহায্য করে।
সংস্থার মধ্যে এই ওপেন সোর্স পদ্ধতি বাস্তবায়নকেই আমরা InnerSource বলি। ওপেন সোর্স অনুশীলনগুলি স্বচ্ছ সহযোগিতা, ভাগাভাগি মানদণ্ড এবং সম্প্রদায়-চালিত উন্নতিকে উৎসাহিত করে। ওপেন সোর্স পদ্ধতি দলগুলিকে স্বাভাবিকভাবে এমন অনুশীলনগুলির দিকে আকর্ষিত করতে সাহায্য করে যা AI বোঝে যখন সেই প্রাতিষ্ঠানিক জ্ঞানকে সংরক্ষণ করে যা আপনার সংস্থাকে অনন্য করে তোলে। ওপেন সোর্স পদ্ধতিগুলি ধীরে ধীরে সংস্থাগুলিকে “AI-জানা মানক পদ্ধতিগুলির” সাথে সারিবদ্ধ করার জন্য কৌশল বিকশিত করে যখন এই রূপান্তরের জন্য প্রয়োজনীয় সাংগঠনিক সম্পদ এবং ব্যক্তিগত সক্ষমতা তৈরি করে। এটি পরিবর্তন জোর করার বিষয়ে নয়—এটি এমন শর্ত তৈরি করার বিষয়ে যেখানে পরিবর্তন স্বাভাবিক এবং উপকারী মনে হয়।
1. “আমাদের পদ্ধতি” বনাম “মানক পদ্ধতি” #
এটি কল্পনা করুন: আপনার সংস্থা তার কোড পর্যালোচনা প্রক্রিয়া, ডকুমেন্টেশন মানদণ্ড এবং পরীক্ষার পদ্ধতি নিখুঁত করতে বছরের পর বছর কাটিয়েছে। এগুলি শুধু অনুশীলন নয়—এগুলি আপনার সাংগঠনিক পরিচয়ের অংশ। তারপর AI আসে, এবং হঠাৎ এটি আপনার সযত্নে তৈরি করা নিয়মাবলী বোঝে না। এটি PEP8-ইশ স্টাইলের কোড উৎপন্ন করে, আপনার কাস্টম Python স্টাইল গাইড নয়। এটি Jest প্যাটার্নে পরীক্ষা লেখে, আপনার মালিকানাধীন পরীক্ষা ফ্রেমওয়ার্কে নয়।
অবশ্যই, আপনি AI কে আপনার নির্দিষ্ট উপায় শেখাতে পারেন, কিন্তু এটি ইতিমধ্যে যে শূন্য-শট জ্ঞানের অধিকারী তার সুবিধা নেওয়া স্পষ্টতই সহজ। এজন্যই বেশিরভাগ মানুষ Bootstrap, Tailwind এবং অন্যান্য সুপ্রতিষ্ঠিত প্যাটার্নের দিকে আকর্ষিত হয়—কারণ এটি সহজভাবে আরও দক্ষ।
অস্বস্তিকর সত্য #
AI আপনার মালিকানাধীন তথ্য জানে না। এটি আপনার অভ্যন্তরীণ কোডিং মানদণ্ড, আপনার কাস্টম ফ্রেমওয়ার্ক বা আপনার অনন্য স্থাপত্য সিদ্ধান্তগুলিতে প্রশিক্ষিত হয়নি। এটি ওপেন সোর্সের ভাষা বলে—বিশ্বব্যাপী ডেভেলপারদের সাধারণ ভাষা যা ব্যাপকভাবে ডকুমেন্ট করা এবং ভাগাভাগি করা হয়েছে।
এটি তাৎক্ষণিক ঘর্ষণ বিন্দু তৈরি করে। সংস্থাগুলি তাদের “বিশেষ পদ্ধতিতে” ব্যাপক বিনিয়োগ করেছে, প্রায়শই ভাল কারণে। হয়তো আপনার কোডিং মানদণ্ড বেদনাদায়ক ডিবাগিং সেশন থেকে উদ্ভূত। সম্ভবত আপনার ডকুমেন্টেশন ফরম্যাট নির্দিষ্ট সম্মতির প্রয়োজনীয়তা পূরণ করতে বিকশিত হয়েছে। এগুলি নির্বিচার পছন্দ নয়—এগুলি প্রক্রিয়ায় স্ফটিকীভূত প্রাতিষ্ঠানিক জ্ঞান।
স্বল্পমেয়াদী সমাধান: মানদণ্ড গ্রহণ করুন #
ব্যবহারিক উত্তর, অন্তত এখনকার জন্য, মানকীকরণ। Python এর জন্য PEP8 গ্রহণ করুন। প্রচলিত কমিট বার্তা ব্যবহার করুন। প্রতিষ্ঠিত পরীক্ষা প্যাটার্ন অনুসরণ করুন। আপনার ডকুমেন্টেশনকে এমন ফরম্যাটে কাঠামোবদ্ধ করুন যা AI পার্স এবং বুঝতে পারে।
এটি আত্মসমর্পণ নয়—এটি বাস্তববাদ। যখন AI এমন কোড উৎপন্ন করে যা আপনার মানদণ্ডের সাথে সংগতিপূর্ণ, ঘর্ষণ অদৃশ্য হয়ে যায়। যেহেতু প্রসঙ্গ উইন্ডোগুলি নাটকীয়ভাবে সম্প্রসারিত হয়, আপনি অবশেষে আপনার সমস্ত সোর্স কোড এবং মালিকানাধীন তথ্য যেভাবেই হোক প্রসঙ্গে ডাম্প করতে পারবেন। কোড পর্যালোচনা মসৃণ হয়ে যায়। একীকরণ নির্বিঘ্ন হয়ে ওঠে। আপনার ডেভেলপাররা AI-উৎপন্ন কোডের সাথে লড়াই করতে কম সময় এবং এর সক্ষমতাগুলি কাজে লাগাতে আরও সময় ব্যয় করে।
দীর্ঘমেয়াদী বাস্তবতা: AI আপনার পদ্ধতি শিখবে #
কিন্তু এখানে যে সূক্ষ্মতা বেশিরভাগ আলোচনা মিস করে: এটি সম্ভবত একটি অস্থায়ী সমস্যা। AI সিস্টেমগুলি প্রসঙ্গ এবং মালিকানাধীন তথ্য বোঝায় দ্রুত উন্নতি করছে। ফাইন-টিউনিং, উন্নত ইন-কনটেক্সট লার্নিং এবং দীর্ঘ প্রসঙ্গ উইন্ডো অবশেষে AI কে আপনার সাংগঠনিক বিশেষত্বগুলি শোষণ করার অনুমতি দেবে।
প্রশ্ন হয়ে ওঠে: এমন একটি সমস্যা সমাধানের জন্য সাংগঠনিক উথালপাথাল কি মূল্যবান যা নিজেই সমাধান হতে পারে?
InnerSource একটি সেতু হিসেবে #
এখানেই InnerSource অমূল্য হয়ে ওঠে। InnerSource দাবি করে না যে আপনি রাতারাতি আপনার সাংগঠনিক পরিচয় পরিত্যাগ করুন। পরিবর্তে, এটি ক্রমিক রূপান্তরের জন্য একটি কাঠামো প্রদান করে—আপনার রেড রাইডিং হুডকে এমন একটি পথ খুঁজে পেতে সাহায্য করে যা নিরাপদ এবং দক্ষ উভয়ই।
InnerSource নিজের জন্য কোড লেখার বিষয়ে নয়—এটি আপনার দলের জন্য, ব্যাপক সংস্থার জন্য, প্রতিবেশী দলগুলির জন্য এবং এক বা দুই হপ দূরে থাকা দলগুলির জন্য লেখার বিষয়ে। এর অর্থ এমন কোড লেখা যা প্রত্যেকে সহজেই পড়তে পারে, তারা নতুন জুনিয়র ইঞ্জিনিয়ার হোক বা অভিজ্ঞ, দক্ষ পেশাদার। এই দর্শন কেবল কোড থেকে বিস্তৃত হয়ে ইন-কোড ডকুমেন্টেশন এবং স্থাপত্য সিদ্ধান্তগুলিতে।
InnerSource আপনার সংস্থার মধ্যে ওপেন সোর্স অনুশীলন গ্রহণকে উৎসাহিত করে: স্বচ্ছ সহযোগিতা, ভাগাভাগি মানদণ্ড এবং সম্প্রদায়-চালিত উন্নতি। এটি দলগুলিকে স্বাভাবিকভাবে এমন অনুশীলনগুলির দিকে আকর্ষিত করতে সাহায্য করে যা AI বোঝে যখন সেই প্রাতিষ্ঠানিক জ্ঞানকে সংরক্ষণ করে যা আপনার সংস্থাকে অনন্য করে তোলে।
পদ্ধতিটি ধীরে ধীরে সংস্থাগুলিকে “AI-জ্ঞাত মানক পদ্ধতিগুলির” সাথে সারিবদ্ধ করার জন্য কৌশল বিকশিত করে যখন এই রূপান্তরের জন্য প্রয়োজনীয় সাংগঠনিক সম্পদ এবং ব্যক্তিগত সক্ষমতা তৈরি করে। এটি পরিবর্তন জোর করার বিষয়ে নয়—এটি এমন শর্ত তৈরি করার বিষয়ে যেখানে পরিবর্তন স্বাভাবিক এবং উপকারী মনে হয়।
2. মান নিশ্চয়তা বাধা: যখন AI মানব পর্যালোচনাকে ছাড়িয়ে যায় #
এটি সত্যিই কোনো গোপনীয়তা নয়—সবাই এই অস্বস্তিকর সত্যের সাথে লড়াই করছে। AI সক্ষমতা দ্রুতগামীভাবে বৃদ্ধি পেতে থাকে, কিন্তু মানুষের জ্ঞানীয় ক্ষমতা তুলনামূলকভাবে স্থিতিশীল থাকে। যদিও AI নিশ্চিতভাবে কোড বোধগম্যতায় সহায়তা করতে পারে এবং পর্যালোচনাগুলিকে আরও দক্ষ করে তুলতে পারে, মানব প্রক্রিয়াকরণ ক্ষমতার মৌলিক সীমা রয়েছে যা আমরা ইঞ্জিনিয়ার করে দূর করতে পারি না।
AI সেকেন্ডে হাজার লাইন কোড উৎপন্ন করতে পারে। একজন দক্ষ ডেভেলপার এক ঘন্টায় কয়েকশ লাইন পর্যালোচনা করতে পারে। গণিত কাজ করে না, এবং AI সক্ষমতা উন্নতির সাথে এটি আরও খারাপ হচ্ছে।
পর্যালোচনা সমস্যা স্কেল করা কঠিন #
পরীক্ষা লেখা নিশ্চিতভাবে এই পরিস্থিতিতে উল্লেখযোগ্য উন্নতি আনতে পারে, এবং অনেক সংস্থার কাছ থেকে সম্মতি হল যে পরীক্ষাগুলি আগের চেয়ে আরও গুরুত্বপূর্ণ হয়ে উঠেছে—তারা AI-সহায়তা প্রাপ্ত উন্নয়ন জগতে অপরিহার্য গার্ডরেল হিসেবে কাজ করে। এমনকি যদি AI বাস্তবায়ন কোডের সাথে পরীক্ষা কোড উৎপন্ন করে, কাউকে এখনও সেই পরীক্ষাগুলি পর্যালোচনা করতে হবে। এমনকি যদি AI তার যুক্তি ব্যাখ্যা করে, কাউকে সেই যুক্তি যাচাই করতে হবে। মৌলিক সীমাবদ্ধতা থেকে যায়: মানব জ্ঞানীয় ব্যান্ডউইথ।
ঐতিহ্যগত মান নিশ্চয়তা দুর্লভতা অনুমান করে—যে কোড লেখা ব্যয়বহুল এবং তাই যত্নসহকারে পর্যালোচনার যোগ্য। কিন্তু যখন কোড উৎপন্ন করা সস্তা হয়ে যায়, আমাদের মানের মডেলগুলি সম্পূর্ণভাবে ভেঙে পড়ে।
সমাধান: মান-নিশ্চিত কোড ভাগাভাগি #
মূল অন্তর্দৃষ্টি হল AI কে বারবার চাকা আবিষ্কার করা থেকে প্রতিরোধ করা। প্রতিটি AI কে একই সমস্যা সমাধান করতে এবং অনুরূপ কোড উৎপন্ন করতে দেওয়ার পরিবর্তে, পর্যালোচিত, পরীক্ষিত এবং অনুমোদিত কোড উপাদানের ভাণ্ডার তৈরি করুন যা দলগুলি পুনরায় ব্যবহার করতে পারে।
যখন আপনার কাছে ওপেন সোর্স এবং InnerSource পরিবেশের মতো অনেক ভাগাভাগিযোগ্য অংশ থাকে, তখন কিছু আকর্ষণীয় ঘটে: বিভিন্ন লোক সেই সরঞ্জাম এবং কোড উপাদানগুলি ব্যবহার করতে শেষ করে। মান সামষ্টিক ব্যবহারের মাধ্যমে নিশ্চিত হয়—অনেক চোখ সেই কোড পরীক্ষা করে, সমস্যা খুঁজে পায় এবং সময়ের সাথে এটি উন্নত করে।
এই পদ্ধতির জন্য মানসিকতায় মৌলিক পরিবর্তন প্রয়োজন। কোড ব্যক্তিগত মালিকানার চেয়ে সামষ্টিক সম্পদ ব্যবস্থাপনার বিষয়ে কম হয়ে ওঠে। তবে, এর অর্থ সামষ্টিক কোড মালিকানার পরিবর্তে দুর্বল কোড মালিকানা বাস্তবায়ন—কারণ যখন সবাই কিছুর মালিক, তখন কেউই সত্যিকারে এর মালিক নয়। এর অর্থ আমাদের সোর্স কোড যথাযথভাবে রক্ষণাবেক্ষণের সংস্কৃতিরও প্রয়োজন।
কিন্তু এখানে ভাল খবর: AI এখন সোর্স কোড রক্ষণাবেক্ষণের অধিকাংশ পরিচালনা করতে পারে। আসল প্রশ্ন হল সংস্থাগুলি কীভাবে এই ধরনের ভাগাভাগি কোড ভাণ্ডারের মালিকানা এবং তত্ত্বাবধান করবে।
দলগুলিকে তাদের তাৎক্ষণিক প্রয়োজনের বাইরে চিন্তা করতে হবে এবং বিবেচনা করতে হবে কীভাবে তাদের সমাধান সংস্থা জুড়ে অন্যদের উপকার করতে পারে।
InnerSource পদ্ধতিগত ভাগাভাগি সক্ষম করে #
InnerSource এই রূপান্তরের জন্য সাংস্কৃতিক ভিত্তি প্রদান করে। এটি ডেভেলপারদের ওপেন সোর্স রক্ষণাবেক্ষণকারীদের মতো চিন্তা করতে উৎসাহিত করে—শুধু তাদের তাৎক্ষণিক প্রয়োজনের জন্য কোড লেখা নয়, বরং এমন সমাধান তৈরি করা যা অন্যরা বুঝতে, সংশোধন করতে এবং উন্নত করতে পারে।
এটি শুধু কোড লাইব্রেরির বিষয়ে নয়। এটি কোন কোড মান নিশ্চয়তা বিনিয়োগের যোগ্য তা চিহ্নিত করার জন্য কাঠামো তৈরি করা, ভাগাভাগি ভাণ্ডার রক্ষণাবেক্ষণের প্রক্রিয়া এবং অবদান ও পুনর্ব্যবহারকে উৎসাহিত করে এমন সাংস্কৃতিক অনুশীলনের বিষয়ে।
পদ্ধতিটি স্বয়ংক্রিয়তা এবং মানব তত্ত্বাবধানের মধ্যে ভারসাম্য মোকাবেলা করে, সংস্থাগুলিকে মান মানদণ্ড বজায় রাখার সময় AI-উৎপন্ন কোড একীকরণের জন্য টেকসই অনুশীলন বিকশিত করতে সাহায্য করে।
3. তথ্য সাইলো সমস্যা: AI এর জ্ঞান ক্ষুধা #
সংস্থাগুলি এমন AI এর স্বপ্ন দেখে যা সব কিছু জানে—সমস্ত বিভাগীয় জ্ঞানে অ্যাক্সেস সহ একটি কৃত্রিম কর্মচারী, ব্যতিক্রমী ক্রস-ফাংশনাল কাজ করতে সক্ষম। কিন্তু এই স্বপ্ন তথ্য সাইলোর বাস্তবতার বিরুদ্ধে ভেঙে পড়ে।
বহু-স্তরের অ্যাক্সেস চ্যালেঞ্জ #
আপনার সংস্থাকে একটি ভেন ডায়াগ্রাম হিসেবে বিবেচনা করুন। বিভাগ X এর নির্দিষ্ট তথ্যে অ্যাক্সেস আছে, বিভাগ Y এর ভিন্ন তথ্যে, বিভাগ Z এর আবার অন্য সেটে। ছেদ—সব বিভাগের জন্য অ্যাক্সেসযোগ্য তথ্য—প্রায়শই আশ্চর্যজনকভাবে ছোট।
যখন আপনি “সাংগঠনিক AI” তৈরি করার চেষ্টা করেন, আপনি তৎক্ষণাৎ এই সীমাবদ্ধতার সাথে সংঘর্ষে পড়েন। বর্তমান RAG বাস্তবায়নগুলি প্রতি বিভাগ তথ্য অনুকূল করে, কিন্তু তারা অনুসন্ধান নির্ভুলতা এবং ক্রস-বিভাগীয় প্রসঙ্গ নিয়ে লড়াই করে। প্রতিটি বিভাগ তার নিজস্ব AI সহায়ক পায়, কিন্তু তাদের কেউই সত্যিকারে সংস্থাকে সামগ্রিকভাবে বুঝতে পারে না।
আপনি হয়তো মনে করেন এটি কোনো বড় ব্যাপার নয় কারণ আপনি AI কে যেসব প্রকল্প উল্লেখ করতে চান সেগুলি একটি ভেন ডায়াগ্রামের একটি বৃত্তের মধ্যে মাপসই হতে পারে। কিন্তু এটি শুধু সোর্স কোড অ্যাক্সেসের বিষয়ে নয়—এটি একটি বহু-স্তরের, বহু-পর্যায়ের সমস্যা যা অনেক গভীরে যায়।
আপনার সংস্থা কিছু প্রকল্পের জন্য Notion ব্যবহার করতে পারে, অন্যদের জন্য Office 365। কিছু দল GitHub ব্যবহার করে, অন্যরা GitLab। লাইসেন্সধারী এবং যারা নেই তাদের মধ্যে পার্থক্য রয়েছে। যখন এই বিভিন্ন সিস্টেমগুলির সহযোগিতার প্রয়োজন হয়, সমস্যাগুলি বহুগুণ হয়। এমনকি যখন কর্মচারীরা একই প্রকল্পে কাজ করে, তাদের ভূমিকা, সিনিয়রিটি বা বিভাগের উপর ভিত্তি করে তথ্যে তাদের অ্যাক্সেসের স্তর নাটকীয়ভাবে ভিন্ন হতে পারে।
স্বল্পমেয়াদে, AI সম্ভবত ব্যক্তিগত থাকবে—ব্যক্তিরা তাদের নিজস্ব AI মিথস্ক্রিয়া পরিচালনা করবে। এমন ক্ষেত্রে, সাংগঠনিক তথ্যে অ্যাক্সেসের অভাব, বা সাংগঠনিক তথ্যে অ্যাক্সেস পেতে প্রয়োজনীয় লিড টাইম, একটি গুরুত্বপূর্ণ বাধা হয়ে ওঠে যা AI কার্যকারিতা সীমিত করে।
তথ্য ওভারল্যাপের শক্তি #
সমাধান AI কে আরও তথ্যে অ্যাক্সেস দেওয়া নয়—এটি ভেন ডায়াগ্রামে ওভারল্যাপ বৃদ্ধি করা। বিভাগগুলির মধ্যে ভাগাভাগি তথ্যের ছেদ যত বড়, আপনার সাংগঠনিক AI তত শক্তিশালী হবে।
এর জন্য সাংস্কৃতিক রূপান্তর প্রয়োজন। সাংগঠনিক সদস্যরা তাদের ব্যক্তিগত Google ড্রাইভ বা স্থানীয় স্টোরেজে অনেক তথ্য রাখতে পারে। যথাযথ নিয়ম এবং সাংস্কৃতিক পরিবর্তন ছাড়া, কর্মচারী, ইঞ্জিনিয়ার এবং পণ্য মালিকরা স্বাভাবিকভাবেই তথ্য সাংগঠনিকভাবে অ্যাক্সেসযোগ্য করার পরিবর্তে তাদের ব্যক্তিগত দখলে রাখার ডিফল্ট পছন্দ করবে।
কর্মচারীদের তথ্য সংরক্ষণ থেকে ভাগাভাগিতে পরিবর্তন করতে হবে। বিভাগগুলিকে তাদের জ্ঞান রক্ষা করা থেকে সাংগঠনিক বুদ্ধিমত্তায় অবদানের দিকে এগিয়ে যেতে হবে।
নিরাপত্তা এবং অ্যাক্সেস বিবেচনা #
এর অর্থ সমস্ত অ্যাক্সেস নিয়ন্ত্রণ অপসারণ বা নিরাপত্তা দুর্বলতা সৃষ্টি করা নয়। এর অর্থ সংবেদনশীল ডেটার জন্য যথাযথ সীমানা বজায় রেখে নিরাপদে ভাগাভাগি করা যেতে পারে এমন তথ্যের অ্যাক্সেস চিন্তাভাবনার সাথে সম্প্রসারণ করা।
চ্যালেঞ্জটি প্রযুক্তিগত যতটা সাংস্কৃতিক। AI শুধুমাত্র আনুষ্ঠানিক তথ্য পরিচালনা করতে পারে—এটি নিরব জ্ঞান বা ব্যক্তিরা যে তথ্য সংরক্ষণ করে তা অ্যাক্সেস করতে পারে না। তাই, উন্মুক্ত, স্বচ্ছ সহযোগিতা সক্ষম করা অত্যন্ত গুরুত্বপূর্ণ হয়ে ওঠে।
তবে, আপনার চিন্তাভাবনা, সম্পদ, অসমাপ্ত কাজ এবং আপনি যে নথিগুলি সম্পর্কে আত্মবিশ্বাসী নন সেগুলি অনেক লোকের কাছে দেখানো মনস্তাত্ত্বিক সহ উল্লেখযোগ্য বাধা তৈরি করে। এজন্য এই ধরনের অনুশীলনগুলিকে স্বাভাবিক এবং নিরাপদ অনুভব করানো প্রশিক্ষণ অপরিহার্য।
তথ্য ভাগাভাগির জন্য আস্থা প্রয়োজন, এবং আস্থা গড়তে সময় লাগে। সংস্থাগুলির নিরাপত্তা এবং গোপনীয়তার প্রয়োজনীয়তা বজায় রেখে ক্রমান্বয়ে তথ্য অ্যাক্সেস সম্প্রসারণের জন্য কাঠামোর প্রয়োজন।
InnerSource বাধাগুলি ভেঙে দেয় #
InnerSource তথ্য সাইলো ভাঙতে উৎকৃষ্ট কারণ এটি মূলত সংস্থার মধ্যে উন্মুক্ত, সহযোগিতামূলক পরিবেশ তৈরি করার বিষয়ে। এটি জ্ঞান ভাগাভাগি, অবদান ব্যবস্thাপনা এবং সম্প্রদায় গঠনের জন্য প্রমাণিত অনুশীলন প্রদান করে।
পদ্ধতিটি সংস্থাগুলিকে ব্যাপক তথ্য অ্যাক্সেসের জন্য আস্থা এবং নিরাপত্তা মডেল বিকশিত করতে সাহায্য করে যখন সাংস্কৃতিক রূপান্তর কর্মসূচি তৈরি করে যা উন্মুক্ত তথ্য ভাগাভাগিকে উৎসাহিত করে। এটি এই বাস্তবতাকে মোকাবেলা করে যে তথ্য অ্যাক্সেস পরিবর্তনগুলি রাতারাতি বাস্তবায়িত হতে পারে না এবং টেকসই সাংস্কৃতিক গ্রহণ প্রয়োজন।
4. নথি ফরম্যাট বিশৃঙ্খলা: Markdown বিপ্লব #
আপনার সংস্থার PowerPoint উপস্থাপনা, Excel স্প্রেডশিট, জটিল Word নথি, JIRA টিকিট, Confluence পৃষ্ঠা এবং Notion ডেটাবেসে আবদ্ধ দশকের প্রাতিষ্ঠানিক জ্ঞান রয়েছে। আপনি এই সবকিছু AI কে খাওয়াতে চান, কিন্তু এখানে সমস্যা: ফরম্যাট বৈচিত্র নির্ভুলতা দুঃস্বপ্ন তৈরি করে।
AI অ্যাক্সেসিবিলিটি চ্যালেঞ্জ #
AI এর কাছে, একটি PowerPoint ফাইল শুধু XML এবং ইমেজ ফাইল। আপনার যত্নসহকারে তৈরি স্লাইডগুলির শব্দার্থিক বোধগম্যতার অভাব রয়েছে। Excel স্প্রেডশিটগুলি প্রসঙ্গ ছাড়া ডেটা স্যুপ হয়ে যায়। জটিল নথিগুলি বর্তমান AI সিস্টেম দ্বারা প্রক্রিয়াকরণের সময় তাদের কাঠামো এবং অর্থ হারায়।
ইমেজ প্রক্রিয়াকরণ নির্ভুলতায় এখনও উল্লেখযোগ্য উন্নতির অবকাশ রয়েছে, এবং প্ল্যাটফর্ম দেয়াল অতিরিক্ত বাধা তৈরি করে। আপনার জ্ঞান বিভিন্ন API, অনুসন্ধান ক্ষমতা এবং অ্যাক্সেস নিয়ন্ত্রণ সহ একাধিক সিস্টেম জুড়ে ছড়িয়ে আছে।
র্যাডিক্যাল সমাধান: Markdown এবং GitHub কেন্দ্রীকরণ #
উত্তরটি প্রায় হাস্যকরভাবে সহজ শোনায়: সবকিছু Markdown এ লিখুন এবং সবকিছু GitHub (বা অনুরূপ সংস্করণ-নিয়ন্ত্রিত প্ল্যাটফর্ম) এ কেন্দ্রীভূত করুন।
এই সুপারিশ তাৎক্ষণিক প্রতিরোধ ট্রিগার করতে পারে। রিচ ফরম্যাটিং সম্পর্কে কি? জটিল ভিজুয়ালাইজেশন সম্পর্কে কি? আমাদের বিদ্যমান ওয়ার্কফ্লো সম্পর্কে কি?
কিন্তু সুবিধাগুলি বিবেচনা করুন: AI এর অ্যাক্সেসের জন্য কম অবস্থান, শব্দার্থিক কাঠামো যা AI বুঝতে পারে, অন্তর্নির্মিত সংস্করণ নিয়ন্ত্রণ এবং সহযোগিতার বৈশিষ্ট্য, লিঙ্কযোগ্য এবং অনুসন্ধানযোগ্য সামগ্রী, এবং সময়ের সাথে রক্ষণাবেক্ষণযোগ্য ডকুমেন্টেশন।
মাইগ্রেশন চ্যালেঞ্জ এবং ক্রমিক পদ্ধতি #
রিচ নথি থেকে Markdown এ যাওয়া একটি উল্লেখযোগ্য মাইগ্রেশন প্রচেষ্টা এবং সাংস্কৃতিক পরিবর্তনের প্রতিনিধিত্ব করে যা মূলত সংস্থাগুলিকে সহজ ডকুমেন্টেশন ফরম্যাটের পক্ষে প্রক্রিয়া এবং দীর্ঘ-চাষকৃত তথ্য ভাণ্ডার আপডেট করতে বলে। এই চ্যালেঞ্জটি ঐতিহ্যগত প্রকল্প ব্যবস্থাপনা পদ্ধতি (PowerPoint-ভিত্তিক পরিকল্পনা, Excel ট্র্যাকিং) থেকে ইস্যু-ভিত্তিক এবং ডিজাইন ডকুমেন্ট-চালিত উন্নয়ন ওয়ার্কফ্লোতে রূপান্তরিত করার চেষ্টার সময় সংস্থাগুলি যে কঠিনতার মুখোমুখি হয় তার সমান।
তবে, এটি একটি সব বা কিছুই না প্রস্তাব নয়। “সব PowerPoint এবং Excel” বনাম “সব Markdown” এর মধ্যে বেছে নেওয়ার পরিবর্তে, সংস্থাগুলির AI-পাঠযোগ্য তথ্য ফরম্যাট ক্রমান্বয়ে বৃদ্ধির উপর ফোকাস করা উচিত। ব্যবস্thাপনা সিস্টেমের বৈশিষ্ট্যগুলিও গুরুত্বপূর্ণ—যে সিস্টেমগুলি তথ্য তুলনামূলকভাবে সমতল রাখতে পারে সেগুলি জটিল হায়ারার্কিক্যাল অনুমতির প্রয়োজন হয় এমন সিস্টেমের চেয়ে আরও আদর্শ।
যদিও এন্টারপ্রাইজ গভর্নেন্সের জন্য বহু-স্তরের অনুমতি সমর্থনকারী প্ল্যাটফর্মগুলি নিশ্চিতভাবে গুরুত্বপূর্ণ, সংস্থার মধ্যে উচ্চ স্বচ্ছতার সাথে পরিচালিত হতে পারে এমন তথ্যের অংশ বৃদ্ধি সবার উপকার করে। এটি সঠিক ভারসাম্য খোঁজা এবং বিভিন্ন উদ্দেশ্যে উপযুক্ত সরঞ্জাম ব্যবহার করার বিষয়ে, বাইনারি পছন্দ করার বিষয়ে নয়।
দলগুলিকে নতুন সরঞ্জাম এবং ওয়ার্কফ্লো শিখতে হবে। জটিল নথিগুলি পুনর্গঠন করতে হবে। অনুমতি সিস্টেমগুলি পুনর্ডিজাইন করতে হবে। তবুও যে সংস্থাগুলি এই রূপান্তর করে তারা AI একীকরণের বাইরে আশ্চর্যজনক সুবিধার রিপোর্ট করে: উন্নত সহযোগিতা, ভাল সংস্করণ নিয়ন্ত্রণ, আরও অ্যাক্সেসযোগ্য ডকুমেন্টেশন এবং কম সরঞ্জাম জটিলতা।
InnerSource কাঠামো প্রদান করে #
InnerSource এই ধরনের সাংগঠনিক রূপান্তরের জন্য প্রমাণিত কৌশল প্রদান করে। এটি AI অ্যাক্সেসিবিলিটি উন্নত করার সময় নথির বিশ্বস্ততা বজায় রাখার মাইগ্রেশন কৌশল, একীভূত তথ্য স্থাপত্য নীতি এবং ওপেন-সোর্স-অনুপ্রাণিত ডকুমেন্টেশন অনুশীলন প্রদান করে।
পদ্ধতিটি রিচ নথি এবং AI অ্যাক্সেসিবিলিটির মধ্যে ট্রেড-অফ স্বীকার করে যখন ব্যাঘাত কমিয়ে ক্রমিক রূপান্তরের জন্য পথ প্রদান করে।
5. অনুপস্থিত প্রসঙ্গ সংকট: “কেন” বোঝা #
AI “কি” জানে কিন্তু “কেন” জানে না। এটি সম্পূর্ণ কাজের স্ন্যাপশট দেখে কিন্তু কীভাবে এবং কেন সিদ্ধান্ত নেওয়া হয়েছিল তার প্রসঙ্গ নেই। এই সীমাবদ্ধতা AI-সহায়তা প্রাপ্ত উন্নয়নের জন্য উল্লেখযোগ্য সমস্যা তৈরি করে।
স্ন্যাপশট সমস্যা #
অনেক লোক AI কে স্ন্যাপশট তথ্য দেয় এবং এটি সম্পূর্ণ প্রসঙ্গ বুঝবে বলে আশা করে, কিন্তু এই পদ্ধতি ব্যর্থ হয় কারণ এতে সিদ্ধান্তের পিছনের গুরুত্বপূর্ণ “কেন” এর অভাব রয়েছে। যখন সংস্থাগুলির সমস্যা সমাধানের প্রয়োজন হয়, সাধারণত বিপুল পরিমাণ তথ্য এবং অসংখ্য সম্ভাব্য সমাধান উপলব্ধ থাকে। বিকল্প সমাধান বিদ্যমান থাকলেও, সাধারণত ব্যাপক কারণ রয়েছে কেন সেই সমাধানগুলি আগে বেছে নেওয়া হয়নি—কিন্তু এই যুক্তি খুব কমই ব্যাপকভাবে ডকুমেন্ট করা হয়।
বর্তমান AI সিস্টেমগুলি সমাপ্ত কোড দেখে কিন্তু উন্নয়ন প্রক্রিয়া নয়। তারা জানে যে একটি ফাংশন বিদ্যমান কিন্তু জানে না কেন এটি একটি নির্দিষ্ট উপায়ে লেখা হয়েছিল। তারা “অদক্ষ” কোড চিহ্নিত করতে পারে কিন্তু সত্যিকারের সমস্যাগ্রস্ত কোড এবং নির্দিষ্ট কারণে ইচ্ছাকৃতভাবে কাঠামোগত কোডের মধ্যে পার্থক্য করতে পারে না।
এটি বিপজ্জনক দৃশ্য তৈরি করে যেখানে AI “উন্নতি” সুপারিশ করে যা যত্নসহকারে নির্মিত সমাধান ভেঙে দেয় বা “অপ্রয়োজনীয়” কোড সরিয়ে দেয় যা গুরুত্বপূর্ণ কিন্তু অ-সুস্পষ্ট উদ্দেশ্য পরিবেশন করে।
অনানুষ্ঠানিক জ্ঞান ফাঁক #
অনেক মূল্যবান প্রসঙ্গ অনানুষ্ঠানিক যোগাযোগে বিদ্যমান: GitHub ইস্যু আলোচনা, Slack কথোপকথন, Microsoft Teams থ্রেড, হলওয়ে কথোপকথন এবং মিটিংয়ে নেওয়া ডিজাইন সিদ্ধান্ত। এই প্রাতিষ্ঠানিক জ্ঞান প্রায়শই AI সিস্টেমের জন্য দুর্গম বা সময়ের সাথে হারিয়ে যায়, তবুও এটি কোড তার বর্তমান আকারে কেন বিদ্যমান তা বোঝার জন্য গুরুত্বপূর্ণ।
নতুন দলের সদস্যরা প্রায়শই বুঝতে পারে না কেন নির্দিষ্ট বাস্তবায়ন এড়ানো উচিত, এবং AI একই সীমাবদ্ধতার মুখোমুখি হয়। এই ঐতিহাসিক প্রসঙ্গ—কেবল কী সিদ্ধান্ত নেওয়া হয়েছিল তা নয় বরং কেন বিকল্পগুলি প্রত্যাখ্যান করা হয়েছিল তা ডকুমেন্ট করা—মানব অবদানকারী এবং AI সিস্টেম উভয়ের জন্য মূল্যবান।
AI-অ্যাক্সেসযোগ্য সিদ্ধান্ত ট্রেইল তৈরি করা #
সমাধানের জন্য সিদ্ধান্ত গ্রহণের প্রক্রিয়াগুলি ক্যাপচার এবং AI এর জন্য অ্যাক্সেসযোগ্য করার জন্য সিস্টেম তৈরি করা প্রয়োজন। এর অর্থ প্রতিটি কথোপকথন রেকর্ড করা নয়, কিন্তু এর অর্থ গুরুত্বপূর্ণ সিদ্ধান্ত এবং তাদের যুক্তি আনুষ্ঠানিক করা।
ওপেন সোর্স প্রকল্পগুলিতে, যখন সিদ্ধান্তগুলি সম্পূর্ণ ভিন্ন প্রসঙ্গ বা প্ল্যাটফর্মে নেওয়া হয়, তখন নতুন অবদানকারীদের বুঝতে অত্যন্ত কঠিন হয়ে পড়ে কীভাবে বাস্তবায়ন উপলব্ধি করা হয়েছিল বা বর্তমান সিদ্ধান্তগুলি কীভাবে নেওয়া হয়েছিল। এই ধরনের বাধাগুলি শেষ পর্যন্ত অবদানকারী অংশগ্রহণে বাধা দেয় এবং অবদানকে আরও কঠিন করে তোলে। AI একই চ্যালেঞ্জের মুখোমুখি।
এতে প্রযুক্তিগত চ্যালেঞ্জ (যোগাযোগ সিস্টেমের সাথে একীকরণ) এবং সাংস্কৃতিক চ্যালেঞ্জ (সিদ্ধান্ত গ্রহণের প্রক্রিয়াগুলির ডকুমেন্টেশনকে উৎসাহিত করা) উভয়ই জড়িত।
InnerSource সংস্কৃতি স্বাভাবিকভাবে সিদ্ধান্তগুলি ডকুমেন্ট করে #
ওপেন সোর্স প্রকল্পগুলি সিদ্ধান্তগুলি ডকুমেন্ট করতে দক্ষ কারণ স্বচ্ছতা তাদের সাফল্যের জন্য মৌলিক। অবদানকারীদের কেবল কোড কী করে তা নয়, কেন এটি বিদ্যমান এবং এটি কী সমস্যা সমাধান করে তা বুঝতে হবে।
InnerSource এই সংস্কৃতিকে সংস্থার মধ্যে নিয়ে আসে। এটি দলগুলিকে তাদের যুক্তি ডকুমেন্ট করতে, সিদ্ধান্তগুলি খোলাখুলিভাবে আলোচনা করতে এবং অডিট ট্রেইল তৈরি করতে উৎসাহিত করে যা প্রাতিষ্ঠানিক জ্ঞান সংরক্ষণ করে।
পদ্ধতিটি সিদ্ধান্ত ডকুমেন্টেশন কাঠামো, অনানুষ্ঠানিক যোগাযোগ আনুষ্ঠানিক করার প্রক্রিয়া এবং কোড পরিবর্তনগুলিকে ব্যবসায়িক সিদ্ধান্তের সাথে লিঙ্ক করার অনুশীলন প্রদান করে।
সাংগঠনিক সীমাবদ্ধতার বাস্তবতা #
এই চ্যালেঞ্জগুলির অনেকগুলি সম্ভবত স্বল্প থেকে মধ্যম মেয়াদে প্রযুক্তি দ্বারা সমাধান হবে। উন্নত AI ক্ষমতা, ভাল একীকরণ সরঞ্জাম এবং উন্নত প্রসঙ্গ বোধগম্যতা এই কিছু সমস্যা স্বয়ংক্রিয়ভাবে সমাধান করবে।
কিন্তু সংস্থাগুলি নিখুঁত সমাধানের জন্য অপেক্ষা করতে পারে না। তারা বাস্তব সীমাবদ্ধতা পরিচালনা করার সময় AI ক্ষমতাগুলি কাজে লাগানোর জন্য তাৎক্ষণিক চাপের মুখোমুখি: বাজেট সীমাবদ্ধতা, ঝুঁকি বিমুখতা, নিয়ন্ত্রক প্রয়োজনীয়তা এবং এই সহজ বাস্তবতা যে বড় সংস্থাগুলি পরিবর্তন করতে সময় নেয়।
কার্যকারিতার সমস্যা #
যখন এই আলোচনাগুলি উঠে আসে, কখনও কখনও কঠোর সুপারিশ প্রস্তাবিত হয়। আমার মনে আছে যখন আমি Microsoft এ ছিলাম, আমাদের একটি গ্রাহক ছিল যে ইন-হাউস উন্নয়ন ক্ষমতা এগিয়ে নিয়ে যাওয়ার সাথে লড়াই করছিল। যখন আমরা গ্রাহকের সাথে দেখা করার জন্য একজন Microsoft নির্বাহী নিয়ে এসেছিলাম, তার পরামর্শ সোজা ছিল: “যেহেতু আপনি একটি বড় কোম্পানি, আপনি কেন অনেক অত্যাবশ্যক ইঞ্জিনিয়ার আছে এমন কোম্পানিগুলি অধিগ্রহণ করেন না?”
সেই সুপারিশ সম্ভবত সঠিক ছিল, কিন্তু…
নাটকীয় সুপারিশ করা সহজ: “উদ্ভাবনী কোম্পানি কিনুন,” “আপনার সিস্টেমগুলি পুনর্নির্মাণ করুন,” “প্রতিরোধী কর্মচারীদের প্রতিস্থাপন করুন,” “AI বিশেষজ্ঞ নিয়োগ করুন।” কিন্তু বেশিরভাগ সংস্থা এই ধরনের পরামর্শ সহজে বাস্তবায়ন করতে পারে না।
এই ধরনের মতামত সম্ভবত সোশ্যাল মিডিয়ায় সঠিক বলে বিবেচিত হয়, এবং বাস্তবে, দূরদর্শী CEO দের জন্য এই ধরনের রূপান্তর দ্রুত সম্পাদন করা সম্ভবত আদর্শ হবে। তাই সেই তর্ক নিশ্চিতভাবে সঠিক।
কিন্তু বাস্তব এন্টারপ্রাইজ নেতারা এবং বাস্তব কোম্পানির মধ্যম ব্যবস্থাপকরা ইতিমধ্যে এটি জানেন। তারা জানেন, তারা জানেন। তবুও ব্যাপক কারণ রয়েছে কেন তারা এই সমাধানগুলি সম্পাদন করতে পারেন না। তারা শেয়ারহোল্ডারদের কাছে বড় অধিগ্রহণের ন্যায্যতা প্রমাণ করতে পারেন না। সফল পোস্ট-মার্জার একীকরণের জন্য তাদের প্রতিভা নেই। তাদের বড় সিস্টেম ওভারহলের জন্য ব্যয়বহুল পরামর্শদাতার প্রয়োজন। তারা বিদ্যমান চুক্তি, সম্মতি প্রয়োজনীয়তা এবং পরিচালনগত নির্ভরতা দ্বারা সীমাবদ্ধ।
যে কোম্পানিগুলি নাটকীয় পরামর্শ অনুসরণ করতে পারে না তারা অগত্যা ভুল নয়—তারা বাস্তব সীমাবদ্ধতার মধ্যে কাজ করছে যা “উপদেষ্টারা” প্রায়শই উপেক্ষা করেন।
ক্রমিক রূপান্তর অপরিহার্যতা #
এজন্যই পদ্ধতিগুলি গুরুত্বপূর্ণ। সংস্থাগুলির ক্রমিক রূপান্তরের জন্য কাঠামোর প্রয়োজন, যা উত্সাহী নেতা, উৎসাহী অবদানকারী এবং টেকসই সাংস্কৃতিক বিকাশ দ্বারা সমর্থিত।
নিজেকে পরিবর্তন করা তুলনামূলকভাবে সহজ। পরিবেশ, অন্য মানুষ এবং পুরো বিভাগ পরিবর্তন করা সত্যিই কঠিন। তবুও সংস্থাগুলিকে এই সীমাবদ্ধতা সত্ত্বেও এগিয়ে যেতে হবে।
জন সমস্যা #
আপনি, এটি পড়ছেন, সম্ভবত একটি বৃদ্ধির মানসিকতা রাখেন এবং সক্রিয়ভাবে নতুন AI বিষয় অনুসন্ধান করছেন। আপনি যদি একজন উচ্চ বেতনভোগী ইঞ্জিনিয়ার হন যিনি এই ধরনের উন্নয়নকে স্বাভাবিক বিবেচনা করেন, তাহলে আপনি নিশ্চিতভাবে কর্মক্ষমতায় ক্রমাগত উন্নতির জন্য সেই বৃদ্ধির মানসিকতার সুবিধা নিতে যাচ্ছেন। আপনি সম্ভবত মনে করেন যে নেতিবাচক মানুষরা সংস্থায় থাকার উপযুক্ত নয়।
কিন্তু প্রতিবেশী দলের জন সম্পর্কে চিন্তা করুন। বৃদ্ধি উদ্যোগে তার স্বেচ্ছায় সহযোগিতা সন্দেহজনক। তিনি অক্ষম নন—তিনি যুক্তিসঙ্গতভাবে সক্ষম কিন্তু অনুপ্রাণিত করার জন্য আরও প্রচেষ্টার প্রয়োজন, বা তিনি অন্যত্র দুর্দান্ত কিন্তু আপনার এলাকায় প্রেরণাহীন মনে হয় কারণ এটি তাকে সরাসরি উপকৃত করে না।
এটি অগত্যা ব্যক্তিগত কর্মক্ষমতার বিষয়ে নয়—এটি একটি সাংগঠনিক সমস্যা। আপনি কীভাবে এমন পরিস্থিতি তৈরি করেন যেখানে জন AI রূপান্তরে অংশগ্রহণ করতে চান? আপনি কীভাবে প্রণোদনাগুলি সারিবদ্ধ করেন যাতে সহযোগিতা জোরপূর্বকের পরিবর্তে স্বাভাবিক মনে হয়?
“ইঞ্জিনিয়ার” এর সম্প্রসারিত সংজ্ঞা #
InnerSource মূলত একটি ইঞ্জিনিয়ারিং পদ্ধতি হিসাবে ডিজাইন করা হয়েছিল সোর্স কোড, তথ্য এবং সহযোগিতা পরিচালনার জন্য যখন নতুন অবদানকারীদের উন্নয়ন ইকোসিস্টেমে অংশগ্রহণ করতে উৎসাহিত করে। কিন্তু “ইঞ্জিনিয়ার” এর সংজ্ঞা স্পষ্টভাবে সম্প্রসারিত হচ্ছে।
যখন Ruby on Rails বিকশিত হয়েছিল, “ফ্রেমওয়ার্ক ব্যবহারকারীরা” ইঞ্জিনিয়ারিং সম্প্রদায়ের অংশ হয়ে উঠেছিল। Rails তাদের সফটওয়্যার উন্নয়নে তাদের প্রবেশ বিন্দু প্রদান করেছিল। এখন, “Vibe Coding” এবং AI-সহায়তা প্রাপ্ত উন্নয়ন ইঞ্জিনিয়ারদের জন্য নতুন প্রবেশ বিন্দু প্রতিনিধিত্ব করে।
যেহেতু আরও মানুষ “ইঞ্জিনিয়ারিং” এ জড়িত হয়, ঐতিহ্যগত সীমানা ঝাপসা হয়ে যায়। আগে “অ-ইঞ্জিনিয়ার” বিবেচিত মানুষরা এখন কোড তৈরি, সিস্টেম ডিজাইন এবং প্রযুক্তিগত সিদ্ধান্ত গ্রহণে অংশগ্রহণ করে।
আপনি এখনও মনে করতে পারেন যে অ-ইঞ্জিনিয়ার এবং ইঞ্জিনিয়ারদের মধ্যে একটি স্পষ্ট সীমানা রয়েছে। যদিও আমি এই সন্দেহ বুঝি যে অ-ইঞ্জিনিয়াররা হঠাৎ যথেষ্ট শেখা ছাড়া ইঞ্জিনিয়ার-সমতুল্য ক্ষমতা অর্জন করতে পারে, অনস্বীকার্য সত্য হল যে প্রবেশের বাধাগুলি ক্রমাগত হ্রাস পাচ্ছে, এবং অংশগ্রহণের বাধা কম হচ্ছে।
সফটওয়্যার সৃষ্টির গণতন্ত্রীকরণ #
এই সম্প্রসারণ আগের প্রযুক্তিগত পরিবর্তনগুলি প্রতিফলিত করে। যেমন Ruby on Rails শক্তিশালী বিমূর্ততা প্রদান করে ওয়েব উন্নয়নের গণতন্ত্রীকরণ করেছিল, AI কোড জেনারেশনের প্রযুক্তিগত বাধা কমিয়ে সফটওয়্যার সৃষ্টির গণতন্ত্রীকরণ করছে।
এই গণতন্ত্রীকরণ নতুন চ্যালেঞ্জ তৈরি করে। যখন আরও মানুষ সফটওয়্যার তৈরি করতে পারে তখন আপনি কীভাবে মান বজায় রাখেন? যখন সিস্টেম পরিবর্তনের বাধা কম তখন আপনি কীভাবে নিরাপত্তা নিশ্চিত করেন? যখন প্রযুক্তিগত কর্মীবাহিনী আরও বৈচিত্র্যময় তখন আপনি কীভাবে প্রাতিষ্ঠানিক জ্ঞান সংরক্ষণ করেন?
InnerSource সাংগঠনিক কাঠামো হিসাবে #
InnerSource এই চ্যালেঞ্জগুলির উত্তর প্রদান করে কারণ এটি মূলত বিভিন্ন দক্ষতার স্তর এবং প্রেরণা সহ অবদানকারীদের বৈচিত্র্যময় সম্প্রদায় পরিচালনার বিষয়ে। এটি নতুন অবদানকারীদের অন্তর্ভুক্ত করা, মান মানদণ্ড বজায় রাখা এবং প্রাতিষ্ঠানিক জ্ঞান সংরক্ষণের জন্য প্রমাণিত অনুশীলন প্রদান করে।
“ইঞ্জিনিয়ারিং” AI-সহায়তা প্রাপ্ত ডেভেলপারদের অন্তর্ভুক্ত করার জন্য সম্প্রসারিত হওয়ার সাথে সাথে পদ্ধতিটি ক্রমশ গুরুত্বপূর্ণ হয়ে ওঠে। এটি এই নতুন বাস্তবতা পরিচালনার জন্য সাংস্কৃতিক এবং পদ্ধতিগত কাঠামো প্রদান করে।
উপসংহার: AI কৌশল হিসাবে ওপেন সোর্স পদ্ধতি #
ভবিষ্যৎ সেই সংস্থাগুলির যারা তাদের অনন্য জ্ঞান এবং প্রক্রিয়াগুলিকে AI ক্ষমতার সাথে সফলভাবে মিশ্রিত করতে পারে। এটি মানব দক্ষতা এবং কৃত্রিম বুদ্ধিমত্তার মধ্যে বেছে নেওয়ার বিষয়ে নয়—এটি সমন্বয়সাধক সম্পর্ক তৈরি করার বিষয়ে যা উভয়কে বিস্তৃত করে।
ওপেন সোর্স পদ্ধতি সফল AI সহযোগিতার চাবিকাঠি। যে সংস্থাগুলি স্বচ্ছতা গ্রহণ করে, অবদানকে উৎসাহিত করে, সিদ্ধান্তগুলি ডকুমেন্ট করে, জ্ঞান ভাগাভাগি করে এবং সম্প্রদায় তৈরি করে তারা AI যুগে উন্নতি লাভ করবে।
InnerSource, ওপেন সোর্স নীতিগুলির সাংগঠনিক মূর্তি, এই রূপান্তরের জন্য কাঠামো প্রদান করে। এটি তথ্য ভাগাভাগি, মান নিশ্চয়তা, অ্যাক্সেসিবিলিটি এবং প্রসঙ্গ সংরক্ষণের মৌলিক চ্যালেঞ্জগুলি সমাধান করে যা সংস্থাগুলি AI কে তাদের উন্নয়ন প্রক্রিয়ায় একীভূত করার সময় মুখোমুখি হয়।
এগিয়ে যাওয়ার পথ #
এটি রাতারাতি InnerSource বাস্তবায়ন বা নাটকীয় সাংগঠনিক পরিবর্তন জোর করার বিষয়ে নয়। এটি ধীরে ধীরে এমন অনুশীলন গ্রহণের বিষয়ে যা আপনার সংস্থাকে আরও AI-বান্ধব করে তোলে যখন সেই জ্ঞান এবং সংস্কৃতি সংরক্ষণ করে যা আপনাকে অনন্য করে তোলে।
ছোট থেকে শুরু করুন। একটি দল বা একটি প্রকল্প বেছে নিন। কোড আরও খোলাখুলিভাবে ভাগাভাগি করা শুরু করুন। সিদ্ধান্তগুলি আরও পুঙ্খানুপুঙ্খভাবে ডকুমেন্ট করুন। যেখানে অর্থবহ সেখানে মানক করুন। স্বচ্ছতার মাধ্যমে আস্থা তৈরি করুন।
যে সংস্থাগুলি এই ভারসাম্যে দক্ষতা অর্জন করে—খোলামেলা এবং নিরাপত্তার মধ্যে, মানদণ্ড এবং অনন্যতার মধ্যে, AI ক্ষমতা এবং মানব বিচারের মধ্যে—তারা সফটওয়্যার উন্নয়নের পরবর্তী যুগ নির্ধারণ করবে।
প্রশ্ন এটি নয় যে AI কীভাবে আমরা সফটওয়্যার তৈরি করার পদ্ধতি পরিবর্তন করবে। প্রশ্ন হল আপনার সংস্থা সেই রূপান্তর দ্বারা আকৃতি প্রাপ্ত হবে নাকি এটি আকার দিতে সাহায্য করবে।
পছন্দ, সর্বদা হিসাবে, আপনার। কিন্তু ওপেন সোর্স পদ্ধতি এগিয়ে যাওয়ার একটি প্রমাণিত পথ প্রদান করে।
