Playbook Keberhasilan Sistem Engineering GitHub

• Untuk mencapai keberhasilan engineering, penting menjaga keseimbangan di tiga area: kualitas (Quality), kecepatan (Velocity), dan kepuasan developer (Happiness)
• ESSP (Engineering System Success Playbook) menyediakan kerangka kerja 3 langkah untuk memaksimalkan hasil bisnis dengan meningkatkan ketiganya secara terpadu
• Melalui 12 metrik inti yang dirancang berdasarkan berbagai framework seperti SPACE, DevEx, DX Core 4, DORA, organisasi dapat memahami kondisi saat ini, menetapkan prioritas sesuai sasaran perbaikan, lalu secara bertahap menerapkan dan menyesuaikan perubahan
  • Kedua belas metrik ini disusun agar setiap area dapat dilacak secara kuantitatif, dan dapat disesuaikan menurut kondisi masing-masing organisasi
• Semua perbaikan didasarkan pada keberlanjutan di tingkat tim dan pemikiran sistemik, dengan menekankan pendekatan seimbang yang mempertimbangkan indikator leading dan lagging sekaligus
• Berfokus pada perubahan jangka panjang yang berkelanjutan, bukan perbaikan cepat
• ESSP dapat mulai diterapkan tanpa alat pengukuran khusus, dan diagnosis awal melalui metode kualitatif seperti survei juga tetap berguna
• GitHub menekankan lewat contoh internalnya bahwa perbaikan yang berpusat pada kualitas pada akhirnya juga berdampak positif pada kecepatan dan kepuasan developer

Metrik keberhasilan engineering GitHub

• Quality
  • Change failure rate: tingkat kegagalan perubahan
    → Persentase perubahan yang menimbulkan insiden atau masalah
    • Cara menghitung: (jumlah deployment gagal / total deployment) × 100
    • Tips: sepakati dengan jelas di dalam tim apa yang dianggap sebagai kegagalan (misalnya rollback, peringatan monitoring, dll.)
  • Failed deployment recovery time: waktu pemulihan deployment gagal
    → Waktu yang dibutuhkan untuk membatalkan deployment yang gagal atau memulihkannya ke kondisi normal
    • Cara menghitung: median dari waktu selesai pemulihan − waktu terjadinya kegagalan untuk setiap deployment gagal
    • Tips: disarankan mengekstraknya otomatis dari sistem notifikasi atau log. Gunakan median, bukan rata-rata, untuk menghindari dampak outlier
  • Code security and maintainability: keamanan dan maintainability kode
    • Cara menghitung: evaluasi gabungan atas jumlah kerentanan, kompleksitas, coverage, dan sebagainya melalui alat analisis statis, GitHub Advanced Security, CodeQL, dll.
    • Tips: atur pemindaian otomatis secara berkala. Berguna untuk mengukur dampak refactoring atau perubahan kebijakan keamanan
• Velocity
  • Lead time: lead time
    → Waktu dari perubahan kode hingga diterapkan ke production
    • Cara menghitung: waktu sejak PR dibuat sampai dideploy setelah merge
    • Tips: menggunakan median alih-alih rata-rata akan mengurangi distorsi. Jika lead time panjang, ukur juga secara terpisah waktu tunggu PR atau keterlambatan review
  • Deployment frequency: frekuensi deployment
    → Seberapa sering deployment ke production dilakukan
    • Cara menghitung: jumlah deployment dalam periode tertentu (harian/mingguan)
    • Tips: perlu dijelaskan apakah deployment otomatis juga dihitung, dan untuk tim kecil acuan mingguan mungkin lebih sesuai
  • PRs merged per developer: jumlah PR yang di-merge per developer
    • Cara menghitung: total PR yang di-merge / jumlah developer yang berkontribusi
    • Tips: gunakan untuk mengukur efisiensi workflow tim, bukan sebagai alat perbandingan. Perlu dibaca bersama ukuran atau kompleksitas PR
• Developer Happiness
  • Flow state experience: pengalaman flow state
    • Cara menghitung: menilai “frekuensi/durasi pengalaman flow baru-baru ini” lewat survei developer
    • Tips: disarankan survei rutin setidaknya sekali sebulan. Jika menyertakan jawaban uraian bebas, insight kualitatif bisa diperoleh
  • Engineering tooling satisfaction: kepuasan terhadap tooling engineering
    • Cara menghitung: mengumpulkan tingkat kepuasan penggunaan alat serta hal yang ingin diperbaiki melalui survei developer
    • Tips: jika dibagi per alat secara detail (IDE, CI, issue tracking, dll.), akan lebih mudah menemukan titik perbaikan yang nyata
  • Copilot satisfaction: kepuasan penggunaan Copilot
    • Cara menghitung: survei kepuasan kepada pemegang lisensi Copilot (NPS atau skor)
    • Tips: disarankan membandingkan pada beberapa titik waktu seperti tepat setelah adopsi dan 3 bulan kemudian. Feedback dapat dipakai untuk meningkatkan pelatihan dan contoh pemanfaatan
• Business Outcomes
  • AI leverage: tingkat pemanfaatan AI
    • Cara menghitung: porsi commit dari Copilot, tingkat adopsi rekomendasi kode AI, waktu penggunaan, dll.
    • Tips: dapat memanfaatkan Copilot Telemetry API milik GitHub atau instrumentasi internal. Lebih efektif jika dianalisis bersama feedback kualitatif
  • Engineering expenses to revenue: rasio biaya engineering terhadap pendapatan
    • Cara menghitung: pengeluaran terkait engineering / total pendapatan
    • Tips: perlu pembenahan standar akuntansi internal. Disarankan analisis tren bulanan atau kuartalan untuk perbandingan
  • Feature engineering expenses to total engineering expenses: proporsi biaya pengembangan fitur terhadap total biaya engineering
    • Cara menghitung: (pengeluaran terkait pengembangan fitur / total pengeluaran engineering)
    • Tips: agar pengukuran akurat, kriteria klasifikasi biaya non-fitur seperti maintenance, infrastruktur, dan testing harus diperjelas terlebih dahulu

[3 langkah menuju keberhasilan engineering]

Langkah 1: Identifikasi hambatan keberhasilan saat ini

• Mengidentifikasi masalah dalam proses pengembangan saat ini dan hambatan yang menghalangi keberhasilan engineering adalah hal yang utama
• Ini berfungsi sebagai baseline untuk menetapkan arah perbaikan dan prioritas ke depan
• Pendekatan
  • Analisis seluruh alur SDLC (Software Development Life Cycle) untuk menemukan titik bottleneck
  • Di GitHub, analisis dilakukan berdasarkan 12 metrik standar, tetapi organisasi dapat memakai hanya sebagian sesuai karakteristiknya
• Partisipasi tim
  • Bukan satu pemimpin saja, tetapi seluruh anggota tim harus bersama-sama mendefinisikan proses perbaikan
  • Memulai percakapan yang bermakna hanya dengan sejumlah kecil metrik pun sudah cukup
• Metodologi

  • 1. Memahami alur dasar

    • Seluruh alur engineering dibagi dan ditinjau sebagai berikut:
      • Perencanaan (Plan) → Pengembangan (Develop) → Review (Review) → Build (Build) → Pengujian (Test) → Rilis (Release) → Operasi (Operate)

  • 2. Mengumpulkan sinyal kuantitatif

    • Data kuantitatif berikut dianalisis:
      • Siklus deployment: seberapa sering deployment dilakukan
      • Lead time: waktu yang dibutuhkan dari saat kode ditulis hingga deployment
      • Change failure rate: tingkat terjadinya error setelah deployment
      • MTTR (Mean Time To Recovery): waktu yang dibutuhkan untuk pulih setelah masalah terjadi

  • 3. Mengumpulkan sinyal kualitatif

    • Mengumpulkan feedback berbasis pengalaman dari developer dan tim:
      • Kapan anggota tim merasakan ketidakefisienan
      • Alat atau prosedur apa yang berulang kali menimbulkan masalah
      • Aktivitas apa yang memberikan beban psikologis terbesar
    • Metode:
      • Menggunakan survei, retrospektif, wawancara 1:1, dan sebagainya
      • Daftar pertanyaan ESSP yang telah ditentukan sebelumnya juga dapat digunakan

  • 4. Mendefinisikan masalah inti

    • Mendefinisikan hambatan (Barrier) melalui data yang telah dikumpulkan
    • Contoh:
      • "Lead time yang panjang menunda pengembangan fitur baru"
      • "Build sering gagal sehingga keandalan deployment rendah"
      • "Developer sering mengalami context switching"
    • Masalah harus dinyatakan dalam bentuk yang spesifik dan dapat diamati

  • 5. Menentukan prioritas metrik

    • Alih-alih memperbaiki semua metrik sekaligus, fokus pada satu atau dua metrik yang memiliki dampak terbesar
    • Prioritas ini akan menjadi dasar percobaan perbaikan dan pengukuran hasil pada Step 2 dan Step 3 berikutnya
• Tips untuk menjalankan Step 1 dengan sukses
  • 1. Fokus pada akar penyebab, bukan penampilan luar
    • Jangan menilai hanya dari gejala permukaan; akar masalah harus digali lebih dalam
      • Contoh: alasan lambat mungkin tampak karena 'pengujian manual', tetapi penyebab sebenarnya bisa jadi kurangnya kepercayaan terhadap pengujian otomatis
    • Untuk itu, berguna untuk merujuk pada antipattern yang umum muncul dalam software engineering
  • 2. Rujuk antipattern
    • Antipattern berarti pendekatan yang sering digunakan, tetapi tidak benar-benar menyelesaikan masalah, dan justru bisa menimbulkan efek samping
    • GitHub menyediakan contoh antipattern yang mungkin ada di dalam tim sebagai resource terpisah, sehingga bisa dimanfaatkan sebagai alat review internal
  • 3. Libatkan orang yang tepat
    • Dalam Task 1 pada Step 1, penting untuk menerima masukan dari anggota dengan berbagai peran
      • Contoh: developer, tester, operasional, keamanan, product manager, dan lain-lain
    • Dengan demikian, workflow secara keseluruhan dapat dipahami secara lebih menyeluruh dan sudut pandang tertentu tidak terlewat
  • 4. Gunakan data kuantitatif dan kualitatif secara seimbang
    • Metrik saja tidak cukup untuk memahami keseluruhan konteks
    • Selain analisis kuantitatif, perlu juga mengumpulkan feedback kualitatif tentang masalah psikologis, budaya, dan kolaborasi dalam tim
    • Contoh: turunnya moral tim, kurangnya komunikasi, atau keluhan saat retrospektif tidak terlihat dalam angka
  • 5. Jangan memilih terlalu banyak hambatan
    • Jangan mencoba menyelesaikan semua masalah sekaligus; fokuslah pada hambatan yang paling berdampak dan paling mendesak
    • Jika terlalu banyak tugas perbaikan diambil di awal, ada risiko kehilangan daya eksekusi dan momentum
  • 6. Pastikan adanya psychological safety
    • Perlu diciptakan lingkungan tempat anggota tim dapat menyampaikan pendapat secara jujur tanpa takut dirugikan atau dibalas
    • Ini adalah syarat kunci untuk mengungkap masalah yang sebenarnya, sekaligus meningkatkan keandalan dan efektivitas aktivitas perbaikan
  • 7. Perbandingan dilakukan untuk pembelajaran, bukan evaluasi
    • Perbandingan metrik antar tim atau perbedaan workflow harus digunakan untuk memperoleh insight, bukan untuk evaluasi kinerja kuantitatif
    • Karena setiap tim memiliki situasi, tujuan, tech stack, dan batasan yang berbeda, perbandingan sederhana bisa menimbulkan salah paham
    • Sebagai gantinya, budaya belajar yang mendorong berbagi apa yang bekerja dengan baik dan menarik pelajaran darinya harus didukung

Langkah 2: Evaluasi apa yang perlu dilakukan untuk mencapai tujuan target Anda

• Tujuan
  • Tahap untuk menganalisis perubahan apa yang perlu dijalankan guna menyelesaikan masalah inti (Barrier) yang didefinisikan pada Step 1
  • Melampaui sekadar pengenalan fitur atau pergantian alat, dengan mengidentifikasi akar penyebab dan solusi pada level organisasi, teknis, dan budaya

• 1. Analisis akar penyebab kondisi saat ini

  • Bukan sekadar berhenti pada hasil seperti "kecepatan lambat" atau "kepuasan rendah", tetapi harus membedakan:
    • mengapa lambat,
    • alasan struktural atau organisasional apa yang ada,
    • serta apa yang bisa dan tidak bisa diubah
  • Alat yang dapat digunakan:
    • teknik 5 Whys
    • diagram fishbone (sebab-akibat)
    • analisis umpan balik kualitatif dari retrospektif tim

• 2. Menurunkan solusi yang memungkinkan

  • Brainstorming solusi teknis, budaya, dan proses untuk masalah tersebut
  • Contoh:
    • Teknis: meningkatkan kecepatan pengujian, memperbaiki pipeline CI/CD
    • Budaya: membenahi praktik code review, meningkatkan onboarding
    • Proses: membatasi ukuran PR, mengubah kriteria merge
  • Teknik yang direkomendasikan GitHub:
    • menghasilkan solusi dengan memadukan solusi berbasis observasi dan perbaikan yang berpusat pada manusia

• 3. Evaluasi dampak dan risiko

  • Untuk setiap solusi, evaluasi elemen berikut:
    • Dampak yang diharapkan: metrik perbaikan apa yang dapat dipengaruhi
    • Kelayakan implementasi: sumber daya tim dan kemampuan eksekusi yang realistis
    • Penerimaan organisasi: tingkat resistensi terhadap perubahan
    • Pemisahan dampak jangka pendek/jangka panjang: apakah hasil muncul cepat atau merupakan perubahan berkelanjutan
  • Untuk itu, Pilot (uji coba) direkomendasikan
    • uji pada unit tim kecil, kumpulkan umpan balik, lalu tentukan apakah akan diperluas

• 4. Menentukan prioritas dan komunikasi

  • Dari berbagai solusi, lakukan prioritisasi berdasarkan kriteria berikut:
    • yang dapat memberi dampak terbesar
    • yang paling mudah dilaksanakan
    • yang menyelesaikan pain point paling mendesak
  • Keputusan ini harus dibagikan bersama anggota tim dan mendapatkan persetujuan,
    • dan sebaiknya dinyatakan dengan jelas dalam bentuk OKR atau target perbaikan
• Tips untuk menjalankan Step 2 dengan sukses
  • 1. Pastikan mempertimbangkan keberlanjutan jangka panjang
    • Jika hanya fokus pada hasil jangka pendek, justru bisa memicu masalah jangka panjang
      • Contoh: pengenalan alat baru dapat segera meningkatkan kecepatan, tetapi tanpa pelatihan, dukungan, dan manajemen perubahan, justru bisa memicu kesalahan dan kebingungan
    • Karena itu, setiap upaya perbaikan harus berupa strategi yang juga mempertimbangkan pemeliharaan dan kemungkinan skalasi
  • 2. Pertimbangkan trade-off antar area (zone)
    • Perhatikan agar perubahan yang memperbaiki satu area (misalnya kecepatan) tidak mengorbankan area lain (misalnya kepuasan developer atau kualitas)
      • Contoh: pelonggaran standar review bisa meningkatkan kecepatan, tetapi dapat memperburuk kualitas kode atau kelelahan developer
    • Selalu perlu pendekatan yang seimbang dengan mempertimbangkan bahwa cakupan dampak melintasi beberapa area
  • 3. Libatkan tim sejak awal
    • Semakin besar keterlibatan langsung tim dan semakin bersama-sama perubahan itu dibuat, semakin tinggi peluang keberhasilannya
    • Himpun pendapat anggota agar perubahan dapat terjadi secara bottom-up
    • Perubahan yang bersifat instruksional sepihak (top-down) dapat memicu resistensi dan sikap tidak peduli
  • 4. Definisikan metrik keberhasilan dengan jelas
    • Sebelum perubahan diterapkan, harus ada kesepakatan tentang apa yang dimaksud dengan sukses
    • Contoh: jika targetnya adalah “memperpendek waktu deployment”,
      • metrik lagging: penurunan waktu deployment aktual
      • metrik leading: penurunan waktu tunggu PR, peningkatan respons dalam survei developer yang merasa 'kecepatan PR membaik'
    • Idealnya, Leading Indicator dan Lagging Indicator didefinisikan bersama
  • 5. Utamakan eksperimen cepat daripada rencana sempurna
    • Pendekatan iteratif yang mencoba perubahan kecil dengan cepat lalu memperbaikinya berdasarkan umpan balik itu efektif
      • Pada tahap awal, meski masih belum sempurna, lakukan pengujian dalam skala kecil terlebih dahulu, lalu perluas jika efektivitasnya terbukti
    • Ini menguntungkan untuk menurunkan kemungkinan kegagalan dan memperkuat kelincahan serta kemampuan adaptasi tim terhadap perubahan
  • 6. Mulailah dari perubahan yang memberi dampak besar dengan usaha kecil
    • Saat item perubahan banyak dan kompleks, pilih dulu usulan perbaikan di area “dampak tinggi-biaya rendah”
    • Contoh: memperkenalkan panduan review sederhana atau menghapus notifikasi yang tidak perlu dapat diterapkan dengan cepat sekaligus memberi dampak besar pada kepuasan
    • Pengalaman sukses awal memberi kepercayaan diri kepada tim dan menyediakan momentum untuk maju ke masalah yang lebih sulit

Langkah 3: Terapkan perubahan Anda, pantau hasilnya, dan sesuaikan

• Menjalankan upaya perbaikan (Intervention) yang dihasilkan pada Step 2 di dalam organisasi secara nyata,
  mengukur hasilnya, lalu bila perlu menyesuaikan atau mengulang perbaikan untuk mengejar keberhasilan engineering yang berkelanjutan

• 1. Eksekusi (Implement the change)

  • Sebelum eksekusi, hal-hal berikut harus diperjelas:
    • Perubahan apa yang akan dilakukan?
    • Siapa yang akan bertanggung jawab?
    • Metrik apa yang akan dijadikan dasar evaluasi?
    • Pengukuran akan dilakukan dari kapan sampai kapan?
  • Hal yang perlu dipertimbangkan saat eksekusi:
    • Menetapkan penanggung jawab: memperjelas ownership
    • Onboarding dan pelatihan tim: semua anggota tim harus memahami mengapa perubahan ini diperlukan dan apa yang akan berubah
    • Mendokumentasikan perubahan: menyisakan catatan agar bisa dijadikan referensi untuk retrospektif dan pengulangan di masa depan
  • Contoh penerapan:
    • Mengubah strategi build cache untuk meningkatkan kecepatan CI/CD
    • Mengubah kebijakan code review (misalnya, menerapkan aturan respons dalam 1 hari)

• 2. Monitoring (Monitor the change)

  • Setelah rencana perbaikan dijalankan, melacak dan mengamati efektivitasnya dengan metrik yang telah ditetapkan sebelumnya
    • Apakah lead time berkurang
    • Apakah tingkat kegagalan menurun
    • Apakah kepuasan developer meningkat, dan sebagainya
  • Alat:
    • GitHub Insights, Copilot Telemetry, sistem BI internal
    • Dashboard laporan mingguan/bulanan
    • Survei developer atau feedback retrospektif
  • Poin penting:
    • Harus bisa dibandingkan dengan baseline
    • Penting untuk melihat tren, bukan hanya satu angka

• 3. Mengumpulkan feedback (Collect feedback)

  • Selain metrik kuantitatif, perlu mengumpulkan feedback tentang apakah perubahan tersebut benar-benar membantu dari sudut pandang developer
    • Manfaatkan retrospektif, survei anonim, meeting 1:1, dan sebagainya
    • Pastikan tingkat “terasa manfaatnya” dari perbaikan cukup tinggi, dan bukan malah perubahan yang menimbulkan kelelahan
  • Perubahan yang dijalankan terburu-buru tanpa kesepakatan organisasi dapat memicu resistensi dan penolakan

• 4. Menyesuaikan atau mengulang (Adjust as needed)

  • Jika hasil upaya perbaikan tidak memenuhi harapan atau menimbulkan efek samping, tanggapi dengan cara berikut:
    • Membatalkan atau melengkapi perubahan
    • Hanya mempertahankan sebagian elemen dan memperkecil cakupan
    • Memperluas penerapan ke cakupan yang lebih besar
  • Terlepas dari berhasil atau gagalnya perubahan, hal-hal berikut harus selalu dipelajari:
    • Elemen apa yang efektif?
    • Faktor apa yang menjadi penghambat?
    • Apa yang harus diubah pada percobaan berikutnya?
• Tips untuk menjalankan Step 3 dengan sukses
  • 1.Jangan mengharapkan kesempurnaan instan
    • Tidak semua perubahan langsung menghasilkan perbaikan yang terlihat jelas
      • Butuh waktu sampai efeknya muncul
      • Tim juga membutuhkan proses beradaptasi dengan perubahan, sehingga kesabaran dan pengamatan berkelanjutan sangat penting
    • Pada tahap awal, efektif untuk menggunakan alat feedback kualitatif seperti survei guna memahami bagaimana perubahan dirasakan
  • 2.Terus ulangi dan perbaiki perubahan
    • Sekalipun pernah berhasil, bukan berarti harus dipertahankan begitu saja; perubahan juga harus terus berevolusi dan disesuaikan
    • Seiring munculnya masalah baru atau perubahan lingkungan eksternal, rencana perbaikan yang ada pun perlu ditinjau ulang
    • Tim perlu didorong agar menganggap ini sebagai aktivitas rutin dan mempertahankan siklus perbaikan
  • 3.Waspadai efek samping yang tidak diinginkan
    • Beberapa perubahan dapat menimbulkan gesekan tak terduga di area lain
      • Contoh: meningkatkan kecepatan deployment adalah perubahan yang baik, tetapi jika validasi kualitas lemah, hal itu bisa berujung pada peningkatan bug
    • Selain metrik, perlu juga melihat perubahan alur workflow secara keseluruhan, dan jika ada tanda-tanda anomali, tindakan segera diperlukan
  • 4.Terus periksa kondisi psychological safety
    • Bahkan setelah perubahan, tim harus tetap berada dalam lingkungan yang memungkinkan mereka mengangkat masalah dengan bebas
    • Agar “masalah yang tidak diungkapkan” tidak menumpuk, perlu dibangun suasana yang memungkinkan anggota tim memberi feedback jujur
    • Seperti ketidakpuasan terhadap proses yang berubah, peningkatan beban kerja yang berlebihan, atau stres tak terduga
  • 5.Terus evaluasi efek jangka panjang
    • Kuncinya bukan hasil jangka pendek, melainkan kinerja yang berkelanjutan dan peningkatan moral tim
    • Seiring waktu, terus periksa:
      • Apakah perubahan sudah benar-benar tertanam
      • Apakah muncul efek samping atau masalah baru
      • Apakah ada kinerja yang bertahan atau menurun
  • 6.Manfaatkan feedback sebagai peluang belajar
    • Bahkan perubahan yang gagal pun merupakan aset pembelajaran yang berharga
    • Analisis apa yang salah berdasarkan data dan feedback, lalu terapkan pada percobaan berikutnya
    • Yang juga penting adalah budaya yang mendorong tim untuk melihat kegagalan sebagai peluang belajar

Beyond the steps: Make the playbook work for you

• Penyesuaian

  • Pilih metrik dan metode pengukuran (telemetri vs survei) sesuai karakteristik organisasi
  • Jangan menjadikan pengukuran sebagai tujuan itu sendiri; gunakan sebagai alat untuk perbaikan yang nyata

• Manajemen perubahan

  • Penting untuk membantu organisasi beradaptasi dengan baik terhadap perubahan dengan memanfaatkan framework manajemen perubahan seperti model ADKAR dan Kotter

• Growth mindset

  • Anggap semua upaya sebagai peluang belajar, dan sikap yang menerima kegagalan adalah kunci perbaikan berkelanjutan

• Gamification

  • Desain reward berbasis motivasi dapat menghasilkan efek positif, tetapi jika dirancang dengan buruk justru bisa menurunkan kualitas atau memicu ketidakseimbangan

Alternatives to the GitHub Engineering System Success Playbook

• Bergantung pada situasi, selain ESSP juga dimungkinkan analisis sederhana yang berfokus pada penggunaan fitur atau strategi perbaikan berbasis tool individual
• Yang penting adalah pendekatan yang realistis sesuai tim dan organisasi, serta upaya perbaikan yang berkelanjutan