TimoDesk

আমি TheSoftKing-এ TimoDesk-এর ডেভেলপমেন্টের নেতৃত্ব দিয়েছি। এই প্রোডাক্টের Engineering-এ Backend, Web Dashboard, Desktop Agent এবং Native System Integration-এর জন্য Laravel, React, Electron, Node.js, Swift এবং C# ব্যবহার করা হয়েছে।

তবে এই প্রোডাক্ট তৈরি করতে গিয়ে যে বিষয়টিতে আমার সবচেয়ে বেশি সময় দিতে হয়েছে, সেটি শুধুমাত্র Engineering বা Feature Development ছিল না; বরং এর পেছনের একটি গভীর প্রশ্ন ছিল—যখন একটি Software কোনো টিমের কাজ পর্যবেক্ষণ করতে শুরু করে, তখন সেই টিমের উপর এর প্রভাব কী হয়?

আসল প্রোডাক্ট ড্যাশবোর্ড নয়, এজেন্ট

এই ধরনের Software-এর প্রতিটি Demo সাধারণত Dashboard দিয়ে শুরু হয়, কারণ একজন Customer যা দেখতে চায়, সেটিই Dashboard। কিন্তু কোনো কোম্পানি শুধু Dashboard দেখে দীর্ঘদিন Customer থাকে না। ষষ্ঠ মাসেও তারা Subscription চালিয়ে যাবে কি না, তার মূল নির্ভরতা থাকে সেই ছোট Application-এর উপর, যা এমন একটি Laptop-এ Background-এ চলছে, যেটি আমাদের নিয়ন্ত্রণে নেই এবং যেখানে আমাদের কোনো Direct Access নেই।

বড় করে দেখুন

প্রকৃত কঠিন Engineering Challenges ছিল Client-side-এ

Server-side Architecture ছিল পরিচিত ধরনের একটি Multi-tenant Laravel API, MySQL এবং Storage বা Email সম্পর্কিত কাজগুলো পরিচালনার জন্য Queue System। এরকম Architecture আমি আগেও তৈরি করেছি।

Desktop Agent-এর আচরণ নিয়ন্ত্রণ করা কঠিন, কারণ এটি আমাদের নিয়ন্ত্রিত পরিবেশে নয়, বাস্তব ব্যবহারকারীর ডিভাইসে চলে। Laptop কাজের মাঝখানে Sleep Mode-এ চলে যেতে পারে এবং পুনরায় চালু হওয়ার পর অন্য Timezone-এ অবস্থান করতে পারে। ট্রেনে চলার সময় Wi-Fi সংযোগ বিচ্ছিন্ন হতে পারে। কেউ শুক্রবার সন্ধ্যায় Laptop বন্ধ করে সোমবার আবার চালু করলে, এর মধ্যে দুই দিনের Unsent Data জমে থাকতে পারে। Corporate VPN সংযোগে বাধা দিতে পারে। এমনকি Antivirus-ও আমাদের Binary-কে Quarantine করতে পারে, কারণ এটি Screenshot সংগ্রহ করে যা, সত্যি বলতে, Malware-ও করে থাকে।

এই কারণেই Agent-টিকে Day One থেকেই Offline-first হিসেবে তৈরি করা হয়েছিল, পরে কোনো Patch হিসেবে যোগ করা হয়নি। Activity প্রথমে Local-ভাবে সংরক্ষিত হয় এবং Device আবার Connected হলে স্বয়ংক্রিয়ভাবে Sync হয়। কিন্তু এই সিদ্ধান্ত নেওয়ার সঙ্গে সঙ্গেই তিনটি গুরুত্বপূর্ণ Constraint তৈরি হয়, যেগুলোর কোনোটিই পরে cheap way তে পরিবর্তন করা সম্ভব ছিল না।

প্রথমত, Server থেকে Acknowledgement না পাওয়া পর্যন্ত Local Store-ই Data-এর Source of Truth হিসেবে কাজ করে। তাই Sync Endpoint-কে Idempotent হতে হয়। Timeout-এর পর কোনো Retry হলে সেটি যেন একই এক ঘণ্টার কাজকে দুইবার Count না করে। দ্বিতীয়ত, Client Clock-এর উপর নির্ভর করা যায় না, কারণ যে কেউ তার Machine-এর সময় পরিবর্তন করতে পারে। Server সিদ্ধান্ত নেয় একটি Interval-এর মূল্য কত হবে; Client শুধু সে কী Observe করেছে তা Report করে। এরপর দুই পক্ষের Data Merge না করে Reconcile করা হয়। তৃতীয়ত, Upload Process-কে Resumable এবং Cost-efficient হতে হয়, কারণ সোমবার সকালে এক হাজার Agent থেকে জমে থাকা Data একসঙ্গে আসা একটি "Thundering Herd" তৈরি করতে পারে, যা নিয়মিত সময়েই Server-এর উপর চাপ তৈরি করে।

The unit of truth is an interval

TimoDesk-এর যে Design Decision নিয়ে আমি এখনও সবচেয়ে বেশি সন্তুষ্ট, সেটি হলো—TimoDesk আসলে Event Record করে না; এটি Interval Record করে। Work Data-কে ১০ মিনিটের Window-এ ভাগ করা হয়, এবং প্রতিটি Window-এর সঙ্গে সংরক্ষিত থাকে সেই সময়ের মধ্যে প্রকৃত কতক্ষণ কাজ করা হয়েছে, Activity Percentage এবং সেই সময়ে Captured হওয়া Screenshot।

বড় করে দেখুন

Interval শুনতে খুব সাধারণ মনে হয়, আর এটাই এর মূল উদ্দেশ্য। এটি প্রতি User প্রতি দিনের Write Volume-কে এমন একটি সীমার মধ্যে রাখে, যার ভিত্তিতে Capacity Planning করা যায়। এটি একটি Partial Hour-কে ব্যাখ্যাযোগ্য করে তোলে: আপনি দেখতে পারেন ১টা থেকে ২টার মধ্যে মোট ৩৬ মিনিট কাজ হয়েছে এবং সেই সময়গুলো ঠিক কোন কোন Window-এর মধ্যে পড়েছে।

A dollar a month is an engineering constraint

একটি Plan, প্রতি User মাসে $1, এবং সব Feature অন্তর্ভুক্ত। Pricing Page-এর দিক থেকে এটি বেশ সুবিধাজনক, ব্যাখ্যা করার মতো কোনো Tier নেই, তৈরি করার মতো Feature Gate নেই, এমনকি Design করার মতো Upgrade Prompt-ও নেই। কিন্তু Engineering-এর দৃষ্টিকোণ থেকে এটি একটি কঠোর Discipline, কারণ এখন প্রতিটি Feature-কেই খরচের হিসাবের পরীক্ষায় টিকে থাকতে হয়।

What leading it actually involved

বাস্তবে Lead হিসেবে আমার কাজটি মূলত তিনটি বিষয়ে এসে দাঁড়িয়েছিল। প্রথমত, Code Review-কে Gatekeeping হিসেবে নয়, শেখানোর একটি প্রক্রিয়া হিসেবে দেখা। এতে কিছুটা বেশি সময় লাগে, কিন্তু এর ফল তখনই পাওয়া যায়, যখন Team-এর কেউ আমার উপস্থিতি ছাড়াই এমন একটি Bug ধরতে পারে, যেটি আগে হয়তো আমাকেই ধরতে হতো।

বড় করে দেখুন

দ্বিতীয়ত, গুরুত্বপূর্ণ Decisionগুলো লিখে রাখা, বিশেষ করে যে Optionগুলো আমরা বিবেচনা করে Reject করেছি সেগুলোও। কারণ কোনো সিদ্ধান্তের পেছনের কারণ Document করা না থাকলে, কয়েক মাস পর Team-এ নতুন কেউ এসে একই বিষয় নিয়ে আবার আলোচনা শুরু করবে।

তৃতীয়ত, প্রয়োজনে স্পষ্টভাবে “না” বলা এবং কেন না বলা হচ্ছে তার কারণ ব্যাখ্যা করা। প্রতি User মাসে মাত্র $1-এর একটি Product-এ সব Feature তৈরি করে দেওয়া সম্ভব নয়। আর একজন Lead যদি কোনো Feature Request কখন বন্ধ করতে হবে সেই সিদ্ধান্ত নিতে না পারেন, তাহলে তিনি আসলে সমস্যাটি সমাধান করছেন না, শুধু Deadline পর্যন্ত হতাশাটাকে পিছিয়ে দিচ্ছেন।

কী রাখব, কী বদলাব

যে সিদ্ধান্তগুলো আমি একই রাখতাম: প্রথম Commit থেকেই Offline-first Architecture, Time-এর ক্ষেত্রে Server-কে একমাত্র Authority হিসেবে রাখা, Event-এর পরিবর্তে Interval ব্যবহার, একটি মাত্র Flat Plan, এবং Agent-কে এতটাই Lightweight রাখা যেন এর Resource Usage নিয়ে User-এর অভিযোগ করার কোনো কারণ না থাকে।

যে বিষয়গুলো আমি পরিবর্তন করতাম: Manager-facing View-এর আগে Employee-facing View তৈরি করতাম। Data একই থাকত, শুধু তৈরির ক্রমটা উল্টো হতো। এতে পরবর্তী অংশগুলোর Default আরও ভালোভাবে নির্ধারণ করা যেত। User সংখ্যা Scale করার আগেই Agent-এর জন্য Proper Telemetry এবং Instrumentation তৈরি করতাম, পরে নয়। কারণ যে Client থেকে কোনো Telemetry পাওয়া যায় না, সেটির সমস্যা দূর থেকে Debug করা প্রায় অসম্ভব। এছাড়া Data Retention এবং Deletion-কে শুরু থেকেই Launch Feature হিসেবে বিবেচনা করতাম এবং এগুলোর জন্য একটি বাস্তব User Interface তৈরি করতাম। কেউ প্রশ্ন করার পর Policy লিখে সমাধান করার বিষয় হিসেবে এগুলোকে রেখে দিতাম না।