ELM — Employee Lifecycle Management

সংক্ষেপ

ELM হলো একটি জাপানি এন্টারপ্রাইজ ক্লায়েন্টের প্রতিদিনের HR ও অপারেশনস প্ল্যাটফর্ম: ছুটি, হাজিরা, খরচ, ওয়ার্ক লগ, প্রতিষ্ঠানের ডিরেক্টরি, ঘোষণা আর অভ্যন্তরীণ অ্যাডমিনিস্ট্রেশন — ইংরেজি ও জাপানি দুই ভাষায়।

এই সিস্টেমে আমি দুইবার কাজ করেছি। প্রথমে আমরা এটা GeneXus + WorkWithPlus-এ তৈরি করি, যে লো-কোড স্ট্যাকে ক্লায়েন্টের ইকোসিস্টেম আগে থেকেই চলত। পরে সিস্টেমটা যখন সেই প্ল্যাটফর্মের সীমা ছাড়িয়ে গেল, তখন আমি এটাকে আধুনিক স্ট্যাকে রি-প্ল্যাটফর্ম করার নেতৃত্ব দিই — সামনে React ও TypeScript, পেছনে FastAPI ও PostgreSQL — আর পুরো সময় ক্লায়েন্ট সিস্টেমটা ব্যবহার করে গেছে।

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

ধাপ ১: GeneXus + WorkWithPlus-এ তৈরি

GeneXus দিয়ে ছোট একটা টিম দ্রুত বড় একটা সিস্টেম শিপ করতে পেরেছিল: ছুটির নীতি ও অনুমোদন, মাসিক হাজিরা পরিকল্পনা, খরচের আবেদন, কাজের রেজিস্ট্রেশন, রিপোর্ট আর ইমেইল টেমপ্লেট। যেখানে বিল্ট-ইন কম্পোনেন্ট যথেষ্ট ছিল না, সেখানে আমি JavaScript লাইব্রেরি দিয়ে কাস্টম GeneXus ইউজার কন্ট্রোল বানিয়েছি — Gantt চার্ট, Kanban বোর্ড আর রিচ-টেক্সট এডিটর — যার কয়েকটা এখন ওপেন সোর্স।

সিস্টেমটা কাজ করত, মানুষ এর ওপর নির্ভর করত। কিন্তু সময়ের সাথে সীমাবদ্ধতা চোখে পড়ল:

• অ্যাক্সেস কন্ট্রোল ছিল একটা মাত্র "user type" নম্বর। প্রতিটা নতুন অনুমতির নিয়ম মানে আরেকটা বিশেষ কেস।
• কোনো পরিবর্তনের ইতিহাস নেই। "কে এটা বদলেছে, আগে কী ছিল?" — কেউ বলতে পারত না।
• নোটিফিকেশন আলাদা মেইল আর পুশ টেবিলে ভাগ করা ছিল।
• ভাষা হার্ড-কোড করা, প্রতিটা ইউজারের জন্য আলাদা বাছাই করা যেত না।
• সেশন প্ল্যাটফর্মের বিল্ট-ইন অ্যাক্সেস ম্যানেজারের ওপর নির্ভর করত।

এগুলোর কোনোটাই বাগ ছিল না। এগুলো ছিল প্ল্যাটফর্মের সীমা।

ধাপ ২: ফরোয়ার্ড-ডিপ্লয়েড পদ্ধতিতে রি-প্ল্যাটফর্ম