Jira ছাড়া ইঞ্জিনিয়ারিং মেট্রিক্স
কী গুরুত্বপূর্ণ সেটা মাপতে তোমার Jira লাগবে না। Git, CI, আর তোমার টিম আগে থেকেই যে টুলগুলো ব্যবহার করে, সেখান থেকেই ইঞ্জিনিয়ারিং হেলথ ট্র্যাক করার উপায় এখানে।
By Chris Calo · 2026-03-23
যে ছোট টিমগুলো ইঞ্জিনিয়ারিং visibility-তে সবচেয়ে ভালো করে, তাদের একটা common ব্যাপার আছে: Jira যেসব metrics track করতে বলে, সেগুলোর পেছনে ছোটা তারা বন্ধ করেছে।
শুনতে মনে হতে পারে আমি শুধু উল্টো কথা বলার জন্য বলছি, আর সত্যি বলতে একটু-আধটু সেটা আছেও – কিন্তু প্রায় তিন বছরের বড় একটা অংশ আমি খুব নিষ্ঠার সাথে sprint board maintain করেছি, backlog groom করেছি, আর এমন ticket-এ estimate আপডেট করেছি যেগুলোর কাজ ওই সকালে Jira খোলার আগেই অর্ধেক শেষ ছিল। প্রতি দুই সপ্তাহে আমরা একটা রুমে বসতাম (আচ্ছা, Zoom-এ – সময়টা ২০২৩ ছিল) আর velocity chart-এর দিকে তাকিয়ে থাকতাম যেটা আমাদের এমন কিছুই বলত না যা কথা বলে আগে থেকে জানতাম না। Jira ছাড়া engineering metrics আমি খুঁজতে বের হইনি। Velocity chart কাজে লাগছে, এই ভান করা বন্ধ করার পরেই এটা নিজে থেকে ঘটেছে।
তোমার টিম যদি এক টেবিলে বসে কাজ করতে পারার মতো ছোট হয়, তাহলে কেমন চলছে সেটা বুঝতে Jira দরকার নাও হতে পারে। দরকার তোমরা আগে থেকে যে টুলগুলো ব্যবহার করছো, সেখান থেকে ভালো সিগন্যাল।
এটা "Jira খারাপ" টাইপ লেখা না। যে সব organisation-এ Jira-স্টাইল tracking সত্যিই দরকার, তাদের জন্য Jira ভালো টুল (আর একটা নির্দিষ্ট scale-এ সত্যিই লাগে)। কিন্তু তুমি যদি ১০ থেকে ৪০ জনের startup-এ engineering manager হও আর শুধু velocity chart বানানোর জন্য Jira-র টাকা দাও, সেটা অনেকটা লাঞ্চ গরম করতে industrial oven কেনার মতো।
"শুধু velocity chart বানানোর জন্য Jira-র টাকা দেওয়া অনেকটা লাঞ্চ গরম করতে industrial oven কেনার মতো।" – Chris Calo
Jira metrics আসলে কী মাপে
সোজা কথা বলি: বেশিরভাগ Jira metrics মাপে Jira usage, engineering output না। Story points মাপে টিম story points estimate করতে কতটা পারদর্শী। Velocity মাপে টিম sprint-গুলো মোটামুটি একই capacity-তে কত ধারাবাহিকভাবে ভরতে পারে। Burndown chart মাপে বৃহস্পতিবার বিকেলে কেউ ticket board-এ drag করতে মনে রেখেছিল কি না।
এগুলো পুরোপুরি অকাজের, তা ঠিক না। কিন্তু এগুলো আসলে process metrics, যেগুলোকে developer productivity metrics সেজে দেখানো হয়, আর এই দুইয়ের ফাঁকেই engineering manager-রা আসল ছবি হারিয়ে ফেলে।
আমি নিজেই সেই EM ছিলাম যে stakeholder meeting-এর আগে প্রায় এক ঘণ্টা Jira data ঘষেমেজে slide deck বানাত যাতে দেখায় "we're on track।" Stakeholder মাথা নাড়ত, গত মঙ্গলবারের login bug নিয়ে একটাই প্রশ্ন করত, তারপর meeting শেষ। ঘণ্টাটা slide deck-এর জন্য গেছে। আসল উত্তরটা ছিল "engineer-কে জিজ্ঞেস করো।"
যে metrics maintain করতে যত কাজ লাগে সেটা যদি measured কাজের চেয়ে বেশি হয়, তাহলে সমস্যা metrics-এই।
Ticket board না, Git থেকে cycle time
ছোট product team-এর জন্য cycle time সাধারণত সবচেয়ে high-signal metric। এটা first commit থেকে production deploy পর্যন্ত সময় মাপে, আর পুরোটাই তুমি Git history আর CI pipeline থেকে বের করতে পারো – ticket board ছাড়াই।
Component গুলো:
- Branch বা PR-এর first commit timestamp
- PR merge timestamp
- Deploy timestamp (তোমার CI/CD থেকে – GitHub Actions, CircleCI, যা-ই চালাও)
১ আর ৩-এর পার্থক্যই তোমার cycle time। এটাকে segment করো – coding time (১ থেকে PR open), review time (PR open থেকে merge), আর deploy queue (merge থেকে production) – তাহলে একটা diagnostic পাবে যেটা বলে দেবে কাজ আসলে কোথায় আটকে যাচ্ছে।
আমাদের টিমে আমি প্রথমবার এটা করার পর সংখ্যাগুলো সত্যিই চমকে দিয়েছিল। আমি ধরে নিয়েছিলাম bottleneck review time-এ (সবাই তো সবসময় review time-কেই bottleneck ভাবে, তাই না?)। দেখা গেল coding-to-PR phase ঠিক ছিল, review ঠিক ছিল, কিন্তু merge আর deploy-এর মাঝখানে গড়ে প্রায় দুই দিন হারাচ্ছিলাম কারণ staging environment flaky ছিল আর কেউ সেটা fix করতে priority দেয়নি। Velocity chart এটা কোনোদিন দেখাত না।
কীভাবে মাপবে
তুমি GitHub-এ থাকলে CLI দিয়ে টেনে আনতে পারো:
```bash
গত ৩০ দিনের merged PR বের করো
gh pr list --state merged --limit 50 --json number,createdAt,mergedAt,headRefName ```
Deploy timestamp-এর জন্য বেশিরভাগ CI system API বা webhook দিয়ে expose করে। PR merge SHA-কে deploy event-এর সাথে map করো, তাহলে phase অনুযায়ী segmented cycle time পেয়ে যাবে।
Tip: তোমার CI যদি deploy timestamp পরিষ্কারভাবে expose না করে, খুব সহজ একটা উপায় হলো এমন Slack bot বানানো যেটা #deploys channel-এ commit SHA সহ post করে। Timestamp পাবে, মানুষ পড়তে পারে এমন log পাবে, আর bonus হিসেবে – এমন একটা channel যেটা বলে দেয় কত ঘন ঘন তোমরা ship করছো।
Code review throughput
Review throughput – প্রতি engineer সপ্তাহে কতটা PR review করছে, আর PR open থেকে first review পর্যন্ত median সময় – টিম health সম্পর্কে যেকোনো sprint metric-এর চেয়ে বেশি বলে। এটা underrated।
কেন? কারণ review behaviour leading indicator। Review time বাড়তে শুরু করলে সাধারণত বোঝায় engineer-রা overloaded, অতিরিক্ত কনটেক্সট সুইচিং করছে, বা (আর এটা অস্বস্তিকর কিন্তু সত্যি) একে অন্যের code এড়িয়ে যাচ্ছে। এগুলোর যেকোনোটা দুই সপ্তাহ পরে missed deadline হয়ে সামনে আসার আগেই জানা দরকার।
GitHub API থেকে এই data পাওয়া যায়। মূল field হলো PR-এর createdAt আর first review event-এর submittedAt।
আমি যে সংখ্যাটা দেখি সেটা হলো first review পেতে median hours। কয়েকটা ছোট টিমে আমাদের অভিজ্ঞতায়, healthy review cadence সাধারণত ৮ ঘণ্টার নিচে থাকে। এটা নিয়মিত এক দিনের ওপরে গেলে বোঝা যায় structural কিছু বদলেছে – আর সেটা যাই হোক, Jira-তে অদৃশ্যই থেকে যায়।
Meetings-to-decisions ratio
এটা traditional engineering metric না, আর শুরুতেই বলি: এটা rough heuristic, KPI না। কিন্তু ছোট টিমে আমি এটাকে অবাক করার মতো তথ্যবহুল পেয়েছি।
এই সপ্তাহে তোমার টিম কতগুলো meeting করেছে গুনো। সেখান থেকে কতগুলো concrete decision বের হয়েছে গুনো ("X দেখা উচিত" টাইপ না – owner আর next step সহ আসল decision)। দ্বিতীয় সংখ্যাকে প্রথমটা দিয়ে ভাগ করো।
অর্ধেকের কম meeting থেকে decision বের হলে জিজ্ঞেস করা উচিত meeting-গুলো সময়ের মূল্য পাচ্ছে কি না। কিছু meeting risk কমাতে বা context share করতে হয়, সেটা বৈধ – সব কিছুর শেষে resolution লাগবে এমন না। কিন্তু তুমি যখন এটা informal-ভাবেও track করা শুরু করো (আমি আক্ষরিক অর্থেই notebook-এ tally রাখতাম), তখন বুঝতে শিখবে কোন meeting সত্যিকারের কাজ এগোয় আর কোনটা শুধু ritual।
আমি প্রায় এক মাস এটা track করেছিলাম, আর এটা আমার meeting schedule বদলে দিয়েছে যেকোনো productivity article-এর চেয়ে বেশি। যখন স্পষ্ট দেখো সোমবারের standup টানা তিন সপ্তাহে শূন্য decision দিয়েছে, সেটা cancel করাটা আর radical মনে হয় না।
Jira ছাড়া engineering metrics বানানো: একটা lightweight dashboard
এর জন্য BI tool লাগবে না। Notion page, Google Sheet, বা weekly Slack post-এ চারটা সংখ্যা দিলেই যথেষ্ট:
- Median cycle time (Git/CI থেকে) – আমরা দ্রুত ship করছি নাকি ধীরে?
- Median time to first review (GitHub থেকে) – টিম কি দ্রুত review করছে?
- Deploy frequency (CI বা #deploys channel থেকে) – কত ঘন ঘন ship করছি?
- Meetings-to-decisions ratio (manual tally) – আমাদের meeting-গুলো কি সময়ের মূল্য দিচ্ছে?
চারটা সংখ্যা, সবই তোমার হাতে থাকা টুল থেকে বের করা যায়, কোনোটার জন্যই Jira board maintain করতে হয় না। সপ্তাহে একবার আপডেট করো। কোনো সংখ্যা টানা দুই সপ্তাহ ভুল দিকে গেলে investigate করো। স্থির থাকলে ছেড়ে দাও।
লক্ষ্য surveillance system বানানো না (please সেটা কোরো না – তোমার engineer-রা বিরক্ত হবে, আর তাদের বিরক্তি যথার্থ হবে)। Engineering team visibility কাজ থেকেই আসা উচিত, কাজের রিপোর্ট দিতে মানুষকে বলে না। That’s the principle behind a single view of what the team is doing: the signals already exist in your tools, and how managers see team progress without asking for status reports is really about connecting those signals, as is task visibility across Linear, GitHub, Slack, and Notion.
সেরা engineering metrics সংগ্রহ করা সস্তা, game করা কঠিন, আর action নেওয়ার মতো কিছু বলে। Story points তিনটাতেই fail করে।
কখন আসলেই ticket board দরকার
বলেছিলাম এটা "Jira খারাপ" লেখা না, আর সেটাই সত্যি। কিছু বৈধ পরিস্থিতি আছে যেখানে project management tool ছাড়া metrics track করা সত্যিই দায়িত্বজ্ঞানহীন:
- Compliance-heavy industry যেখানে task status-এর audit trail আইনগতভাবে বাধ্যতামূলক
- বড় engineering org যেখানে cross-team dependency-র কারণে informal coordination টেকসই না
- যে organisation-এ dedicated project management function আছে আর team জুড়ে canonical source of truth দরকার
তোমার পরিস্থিতি এটা হলে, Jira (বা Linear, বা Shortcut) সঠিক সিদ্ধান্ত। আমি যেটা বলছি, ছোট টিমে শুধু metrics-এর জন্য heavyweight tool চালিয়ে যাওয়া খারাপ trade-off। শেষ পর্যন্ত টিমের আসল কাজের বদলে tool-এর model অনুযায়ী optimise করতে থাকো।
আর সত্যি বলতে? Jira ব্যবহার করা টিমও ওপরের Git-derived metrics যোগ করলে লাভ পাবে। Jira বলে মানুষ কী করছে বলে জানাচ্ছে। Git বলে আসলে কী করছে। দুটোই useful, কিন্তু status-update theatre থেকে immune একটাই।
তোমার startup-এ যদি metrics নিয়ে বারবার প্রশ্ন আসে, এক মাসের জন্য এই চার-সংখ্যার dashboard চালিয়ে দেখো। Jira ছাড়া engineering metrics শুনতে safety net ছাড়া হাঁটার মতো লাগতে পারে – কিন্তু Git history আর CI pipeline-এ কত সিগন্যাল লুকিয়ে আছে একবার দেখলে, ticket board আসলে কী যোগ করছিল সেটাই প্রশ্ন হবে।
Cycle time, stalled PR, আর review bottleneck স্বয়ংক্রিয়ভাবে surface করো – custom script বা Jira board ছাড়াই।
Q: প্রজেক্ট ম্যানেজমেন্ট টুল ছাড়া কি অর্থবহ engineering metrics পাওয়া যায়? A: হ্যাঁ। Cycle time (first commit থেকে deploy), review throughput, আর deploy frequency সবই তোমার Git history আর CI pipeline-এ থাকে। প্রায় ৪০ জনের কম engineer-এর টিমে এগুলো সাধারণত ticket board-এর যেকোনো কিছুর চেয়ে বেশি ধারালো আর game করা কঠিন – আর accurate রাখতে কাউকে board-এ card drag করতে হয় না।
Q: Sugarbug কি স্বয়ংক্রিয়ভাবে engineering metrics দেখায়? A: Sugarbug GitHub, Linear, Slack, আর calendar-এর সাথে কানেক্ট করে তোমার টিমের activity-র একটি নলেজ গ্রাফ তৈরি করে। এটা stalled PR, review bottleneck, আর unresolved decision-এর মতো pattern flag করে – ফলে GitHub API-র ওপর custom script লিখে maintain না করেও এখানে বলা অনেক সিগন্যাল তুমি পেয়ে যাও।
Q: Metrics-এর জন্য Jira বাদ দিতে buy-in কীভাবে পাবো? A: এটাকে বিদ্রোহ না, experiment হিসেবে frame করো। চার সপ্তাহ Git-derived metrics তোমার বিদ্যমান Jira dashboard-এর পাশে চালাও, তারপর দেখো কোন সংখ্যাগুলো আসলে পরিবর্তন এনেছে। Git metrics যদি বেশি actionable প্রমাণিত হয় (আর আমাদের অভিজ্ঞতায় সাধারণত হয়), তাহলে যুক্তি নিজে থেকেই দাঁড়িয়ে যায়।
Q: Process metrics আর performance metrics-এর পার্থক্য কী? A: Process metrics (story points, velocity, burndown) মাপে টিম কত ধারাবাহিকভাবে একটি ওয়ার্কফ্লো follow করছে। Performance metrics (cycle time, deploy frequency, review throughput) মাপে টিম আসলে কী ship করছে আর কত দ্রুত। ছোট টিম প্রায় সবসময় দ্বিতীয়টা থেকে বেশি সিগন্যাল পায়, কারণ performance metrics কাজ থেকেই আসে, manual status update থেকে না।