Kemarin gw liat dashboard Jira tim dev kita penuh centang hijau. Dua puluh tiga tiket "Done" dalam sepekan. Dan client apparel e-commerce masih nanya kenapa fitur checkout masih delay seminggu.

That’s the exact moment gw realize: tracking jumlah task selesai itu cuma cara kita sendiri nyenengin ego. Kita di agensi atau startup scale-up pasti pernah jadi korban pola ini. Setiap minggu ada meeting review, dan yang dipamerin? Velocity chart. Jumlah ticket yang nyebrang kolom Done. Gw udah liat banyak PM senior jatuh cinta sama grafik yang naik terus, sampe lupa tanya: "Berapa lama beneran dari request masuk sampai user bisa klik?" Yang terjadi, orang buru-buru finish biar masuk hitungan. Bug numpuk, scope creep dibiarin, dan yang keluar ke production bukan kode yang rapi—cuma kode yang cepet dikunci statusnya. Beneran loh, ini vanity metric yang paling ngeselin karena bikin lo merasa produktif padahal lagi lari ke tempat yang salah.

Kenapa "Task Done/Bulan" Itu Nyangka Gue Sendiri

Kalau lo punya brief client yang udah 4x direvisi tapi PM lo tetep santuy "iya iya nanti diberesin" — itu red flag, bukan dedikasi. Tapi sayangnya, sistem metrik kita sering reward perilaku itu. Orang ngerasa aman karena angka close-ticket naik. Padahal di balik layar, PR-an menumpuk, test case gak dijalankan maksimal, dan yang akhirnya nyeselin ya tim support yang harus nontonin bug production.

Yang ngeselin lainnya, metrik ini gak bedain antara task kompleks dan task administratif. Bikin komponen UI ulang 3 kali bisa dihitung 1 unit selesai. Update dokumentasi API juga dihitung 1 unit. Hasilnya? Tim jadi gercep ngerjain hal-hal yang gampang dulu, supaya grafik keliatan sehat. Problem berat yang butuh riset mendalam malah ditunda karena takut ngerusak average velocity. Ini klasik, tapi jarang disadarin sampai deadline ketabrak.

Ganti ke Lead Time Proyek (dan WIP Limit)

Tiga bulan lalu, gw mutusin buat cabut metrik "task per minggu" dari dashboard utama. Ganti jadi satu angka doang: lead time proyek. Dari tiket masuk backlog/draft, sampai deliverable final di tangan client atau live di prod. Plus, gw pasang WIP limit keras di kolom In Progress. Maksimal 3 item per dev, 2 per designer. Bukan karena gw gak percaya kapabilitas tim, tapi karena experience gw bilang: makin banyak yang paralel, makin sering switch context, dan makin lama barangnya kelar.

Efeknya? Di minggu kedua, bottleneck langsung terlihat jelas. Ada dua ticket design yang macet di QA karena tim testing belum ready, sementara dev lain nganggur nunggu spec. Kalau pakai metrik task done, kita baru sadar akhir bulan pas deadline ketabrak. Sekarang? Week 2 aja gw sudah bisa geser resource atau adjust scope sebelum jadi fire drill. Data nyata: rata-rata lead time tim gw turun dari 14 hari jadi 5 hari dalam 90 hari. Bukan karena mereka kerja lebih gila, tapi karena mereka cuma pegang 2-3 hal sekaligus sampai mateng.

Kita juga mulai bedain lead time sama cycle time. Lead time itu dari request masuk sampai deliverable. Cycle time itu dari pengerjaan aktif sampai finish. Bedanya penting banget buat diagnosa. Kalau lead time panjang tapi cycle time pendek, berarti masalahnya ada di antrian atau handoff antar role. Kalau keduanya panjang, berarti teknikal debt atau kapasitas memang nggak match. Diagnosis segini gak mungkin kelar kalau kita cuma rajin ngitung centang hijau.

Evaluasi Performa Tim Startup yang Bukan Cuma Nge-rap Portofolio

Soal evaluasi performa tim startup, kebanyakan founder masih terjebak di kuantitas. "Bulan ini kamu selesai 45 tiket?" Nah, kalau lo evaluasi dengan cara itu, lo lagi reward speed over signal. Metrik kinerja tim agensi yang beneran harusnya ngukur konsistensi delivery, bukan volume. Gw pribadi gak setuju kalau kita pake jumlah close-ticket sebagai dasar kenaikan gaji atau bonus. Itu cuma mendorong behavior buruk: orang bakal ngerjain task kecil yang gampang dulu,回避 hard problem yang butuh riset mendalam, atau bahkan split big feature jadi 10 sub-task biar keliatan "busy".

Coba ganti fokusnya ke throughput waktu. Kalau seorang PM bisa handle 3 milestone klien dalam sebulan, masing-masing dengan lead time stabil di bawah 7 hari, itu jauh lebih berharga daripada dia ngerampok 20 micromanagement tickets sambil leave client menunggu approval 3 hari. Transparansi juga jadi kunci. Di SatuTim kita pakai fitur Discussions buat track decision logs dari client, jadi proses evaluasi ga cuma soal "udah berapa yang jalan", tapi "berapa lama response loop-nya" dan "berapa kali scope berubah tanpa impact assessment". Lo liat jejaknya, bukan cuma hasil akhir. Tanpa jejak, evaluasin cuma jadi sesi saling menyalahin.

Cara Gw Geser Fokus Tanpa Bikin Tim Panic

Perubahan metrik biasanya bikin tim defensif. "Gw mau dimonitor apa nih?", "Apakah ini pengurangan target?". Gw tackle ini dengan komunikasi transparan + gradual shift. Pertama, gw jelasin di team meeting bahwa tujuannya bukan nyuruh mereka lari lebih cepat, tapi ngasih ruang buat ngelanjutin pekerjaan yang udah mulai. Kedua, gw hapus laporan harian "status update" yang biasa diisi manual, ganti jadi auto-sync dari tool tracking plus diskusi async di chat buat blockage. Ketiga, tiap Jumat ada 30 menit retro khusus bahas lead time vs expected timeline, bukan bahas siapa yang ngaret.

Hasilnya? Stres turun, tapi kualitas output justru naek. Client kurang komplain soal delay, dan tim dev finally bisa ngalamin flow state tanpa constantly interrupted buat push tiket baru ke kolom Done. Yang ngeselin? Banyak temen founder yang masih teguh jaga "burndown chart" kayak itu warisan methodology tahun 2015. Padahal konteks kerja sekarang beda. Client gak bayar buat lihat tabel Jira yang rapi. Mereka bayar buat produk yang hidup tepat waktu, dengan bug minim.

Satu hal yang sering dilewatkan: WIP limit bukan hukuman. Itu pelindung. Saat semua orang cuma pegang 1-2 prioritas, code review jadi lebih teliti, QA bisa fokus, dan handoff antar departemen jadi lebih mulus. Gak ada lagi tugas gantung yang numpuk di inbox email orang. Kalau lo pengen coba, di SatuTim ada fitur Discussions buat async standup dan decision logging. Lo gak perlu rapat 20 menit buat nyari tau kenapa ticket A macet di kolom Review.

Apa yang Harus Lo Cek Minggu Ini

Jangan langsung ubah semua sistem sekali gus. Itu cuma bikin chaos. Mulai dari satu tim atau satu project pilot dulu. Pasang timer sejak ticket masuk draft, catat kapan status berubah jadi Done, dan plot jadi line graph bulanan. Bandingkan dengan rata-rata SLA client. Kalau grafiknya naik tiap bulan, artinya lo lagi maksa tim buat ngerampok capacity, bukan optimizing flow. Tarik WIP limit, potong paralel work, dan biarkan tim fokus ngejar ketepatan, bukan kecepatan sembarangan.

Kalau lead time tim lo sekarang rata-rata 12 hari, symptom utamanya biasanya dari mana—scope creep yang gak dikontrol, handoff antar role yang macet, atau terlalu banyak parallel work? Coba jabarkan di komentar, atau langsung praktikkan perubahan tracking ini dan lihat berapa jam fokus yang balik ke tim lo dalam sebulan berikutnya.