Apa yang anda lakukan apabila anda diminta untuk bergerak lebih pantas tetapi tidak diberi lebih ramai orang?

Question

Accepted Answer

Menambah orang jarang menjadikan pasukan lebih pantas dalam jangka pendek pun, jadi soalan sebenar ialah: ke mana *masa pasukan sebenarnya pergi*, dan apa yang boleh saya ubah tentang itu? Saya menganggap "bergerak lebih pantas" sebagai dorongan untuk mencari leverage, bukan sebagai tuntutan untuk bekerja lebih lama.

## Di mana saya mencari kelajuan

- **Potong skop, bukan jalan pintas.** Cara paling pantas untuk menghantar lebih pantas ialah membina lebih sedikit. Saya bekerja dengan PM untuk mengutamakan secara kejam dan mencari versi terkecil yang menyampaikan nilai. Kebanyakan ciri ialah 80% nilai dalam 20% kerja.
- **Hapuskan friksi dan masa menunggu.** Selalunya bottleneck bukan kelajuan coding — ia ialah CI yang perlahan, ujian flaky, deploy yang menyakitkan, review yang perlahan, atau menunggu kelulusan. Membetulkan build 30 minit atau penantian review dua hari membeli velociti sebenar secara percuma.
- **Kurangkan work-in-progress.** Pasukan yang menjuggle sepuluh perkara tidak menyelesaikan apa-apa. Memfokus pada lebih sedikit item secara selari menghantar perkara lebih cepat.
- **Automasikan yang berulang.** Ujian manual, keluaran manual, persediaan persekitaran manual — melabur sekali, jimat selamanya.
- **Bayar balik debt yang secara aktif melambatkan anda.** Bukan semuanya; cuma bahagian yang pasukan tersandung setiap hari.
- **Lindungi masa fokus.** Lebih sedikit mesyuarat dan gangguan boleh menjadi kemenangan lebih besar daripada mana-mana alat.

## Bagaimana saya membalas permintaan itu

Saya tidak sekadar berkata "mustahil" atau menerimanya secara senyap. Saya membalas dengan satu **trade-off**: "Kita boleh capai tarikh itu jika kita potong ciri A dan B, atau menerima risiko lebih tinggi pada ujian. Ini yang saya syorkan." Ini menjadikan kelajuan satu keputusan yang dikongsi dan sedar, bukan pertaruhan kualiti yang senyap.

## Perangkap yang perlu dielakkan

- **Mewajibkan kerja lebih masa.** Ia membeli satu sprint pendek dan membayarnya balik dengan burnout, pepijat, dan keciciran.
- **Melangkau ujian dan review secara senyap.** Kelajuan hari ini, satu outage bulan depan.
- **Berkata ya kepada tarikh tanpa mengubah apa-apa** — itu cuma berharap, dan harapan terlepas deadline.

## Mengapa ia penting

Kelajuan yang lestari datang daripada menghapuskan pembaziran, bukan daripada memerah orang. Seorang Tech Lead yang membalas tekanan dengan trade-off yang jelas dan penambahbaikan proses membina pasukan yang benar-benar pantas dan tahan lama — bukan pasukan yang berlari pecut, terhempas, dan kehilangan jurutera terbaiknya.