Kenapa Tim Engineering Anda Semakin Lambat (Meskipun Terus Menambah Karyawan)

Beberapa tahun lalu, sebuah tim produk tempat saya bekerja memiliki lima belas engineer. Mereka bisa merilis fitur setiap dua minggu. Manajemen memutuskan untuk menggandakan ukuran tim agar bisa merilis lebih cepat. Enam bulan kemudian, dengan tiga puluh engineer, mereka malah merilis setiap tiga minggu. Semua orang bingung. Para engineer tidak malas. Mereka juga tidak kurang terampil. Ada sesuatu yang tidak terlihat yang memperlambat mereka.

Sesuatu yang tidak terlihat itu sekarang kita sebut sebagai beban kognitif. Dan inilah alasan utama mengapa platform engineering ada.

Pekerjaan Tersembunyi Sebelum Menulis Kode

Bayangkan Anda adalah seorang developer yang ditugaskan untuk membuat fitur baru. Sebelum Anda menulis satu baris logika bisnis pun, Anda perlu:

• Membuat repositori baru dengan aturan proteksi branch yang tepat
• Membuat pipeline build dan pipeline test
• Mengonfigurasi environment development yang terhubung ke database development
• Mencari tahu cara deploy ke staging
• Mempelajari proses deployment production di perusahaan
• Memahami cara rollback jika terjadi kesalahan
• Menyiapkan monitoring dan logging untuk service Anda

Setiap tugas ini membutuhkan context switching. Anda harus mengingat alat CI apa yang digunakan tim, penyedia cloud mana yang menjadi host environment staging, versi database mana yang kompatibel, dan siapa yang harus dimintai akses ke production.

Bagi seorang developer yang ingin fokus membangun fitur yang benar-benar dilihat pengguna, ini sangat melelahkan. Dan ini bukan masalah keterampilan. Bahkan engineer senior pun melambat ketika mereka harus mengelola pengetahuan infrastruktur di samping logika fitur.

Biaya Sebenarnya: Beban Kognitif

Beban kognitif adalah jumlah usaha mental yang diperlukan untuk menyelesaikan suatu tugas. Saat Anda menulis fitur, otak Anda memproses logika bisnis, aliran data, dan edge cases. Itu sudah cukup berat. Sekarang tambahkan perintah deployment, variabel environment, konfigurasi pipeline, dan prosedur rollback. Otak Anda sekarang membagi kapasitasnya antara dua domain yang sangat berbeda.

Hasilnya bisa ditebak: fitur memakan waktu lebih lama, kesalahan lebih sering terjadi, dan para engineer merasa terkuras di penghujung hari. Bukan karena mereka tidak kompeten, tetapi karena mereka dipaksa untuk menyimpan terlalu banyak hal di kepala mereka sekaligus.

Masalah ini semakin parah seiring pertumbuhan perusahaan. Tim yang terdiri dari tiga hingga lima orang bisa berbagi pengetahuan secara informal. Semua orang tahu bagaimana rekan mereka melakukan deployment. Tapi ketika Anda memiliki sepuluh tim produk, masing-masing dengan preferensi sendiri, kekacauan pun berlipat ganda. Satu tim menggunakan Jenkins. Tim lain menggunakan GitLab CI. Tim ketiga menggunakan GitHub Actions. Satu tim melakukan deploy langsung ke production. Tim lain membutuhkan tiga tingkat persetujuan manual. Satu tim menjalankan Kubernetes. Tim lain menggunakan virtual machine biasa.

Kini tim platform atau DevOps menjadi kewalahan karena setiap tim butuh bantuan dengan pengaturan yang berbeda. Dan tim produk masih lambat karena mereka menghabiskan separuh waktu mereka untuk urusan infrastruktur.

Platform Engineering Bukanlah Alat Lain

Di sinilah platform engineering masuk. Tapi penting untuk memahami apa itu dan apa yang bukan.

Platform engineering bukanlah membangun dashboard yang cantik atau membeli alat baru. Ini adalah perubahan pola pikir: infrastruktur dan pipeline tidak lagi menjadi proyek sampingan yang ditangani tim saat ada waktu luang. Mereka menjadi produk internal yang harus dirancang, dibangun, dan dipelihara dengan ketelitian yang sama seperti produk yang digunakan pelanggan Anda.

Ide utamanya sederhana: alih-alih setiap tim membangun pipeline mereka sendiri dari awal, tim platform menyediakan jalur yang siap pakai. Alih-alih setiap tim belajar cara deploy ke production, platform menyediakan mekanisme deployment yang teruji dan aman. Tim produk fokus pada kode dan fitur. Platform menangani overhead infrastruktur dan pipeline.

Ini secara drastis mengurangi beban kognitif. Developer tidak perlu lagi mengingat cara menyiapkan environment, cara mengonfigurasi monitoring, atau cara menangani rollback. Platform yang melakukannya. Mereka tinggal menulis kode dan menjalankan pipeline yang sudah ada.

Jebakan Pendekatan Satu-Untuk-Semua

Tapi di sinilah banyak upaya platform gagal. Mereka mencoba memaksa setiap tim ke dalam alur kerja yang persis sama. Itu tidak berhasil karena setiap tim memiliki kebutuhan yang berbeda. Beberapa butuh siklus deployment yang cepat. Beberapa butuh gerbang persetujuan yang ketat. Beberapa menggunakan database atau bahasa pemrograman tertentu yang membutuhkan penanganan khusus.

Jika platform terlalu kaku, tim akan menghindarinya. Mereka akan membuat jalan pintas sendiri, dan Anda kembali ke masalah awal: infrastruktur yang terfragmentasi dan beban kognitif yang tinggi.

Platform yang baik mengakomodasi perbedaan tanpa mendorong tim kembali ke pengelolaan semuanya sendiri. Platform menyediakan jalur standar yang mencakup kasus-kasus umum, tetapi memungkinkan tim untuk membuat pilihan di tempat yang penting. Di sinilah konsep golden path berperan, yang akan kita bahas lebih detail nanti.

Artinya Bagi Tim Anda

Jika tim engineering Anda bertambah tetapi kecepatan pengiriman tidak, lihatlah pekerjaan yang tidak terlihat. Tanyakan pada developer Anda: apa yang perlu Anda ketahui atau lakukan sebelum Anda bisa mulai menulis fitur? Jawabannya akan memberi tahu Anda di mana beban kognitif paling tinggi.

Tujuan platform engineering bukanlah untuk mengendalikan tim. Tujuannya adalah untuk menghilangkan gesekan yang memperlambat mereka. Jika dilakukan dengan baik, ini memungkinkan developer tetap dalam flow state mereka, membangun fitur yang penting, sementara platform menangani sisanya.

Daftar Periksa Praktis

Sebelum Anda mulai membangun platform, ajukan pertanyaan-pertanyaan ini:

• Tugas apa yang diulangi oleh developer di setiap fitur atau service?
• Tugas infrastruktur mana yang paling memakan waktu untuk dipelajari atau dipecahkan masalahnya?
• Di mana tim membuat jalan pintas sendiri karena proses yang ada tidak sesuai?
• Apa yang perlu diketahui seorang developer untuk melakukan deploy service baru dari awal hari ini?
• Bagian pipeline mana yang paling menyebabkan kecemasan atau penundaan selama rilis?

Kesimpulan

Tim Anda tidak melambat karena mereka tidak kompeten. Mereka melambat karena mereka membawa beban yang tidak terlihat. Platform engineering adalah tentang menghilangkan beban itu, bukan menambahkan lebih banyak alat. Mulailah dengan memahami apa yang sebenarnya menyulitkan developer Anda, lalu bangun jalur yang membuat kesulitan itu hilang.