Baca dalam bahasa Inggris

Bagikan melalui


Buat rencana dan prioritas

Pelajari cara mengidentifikasi tujuan untuk upaya rekayasa platform Anda berdasarkan Model Kemampuan Teknik Platform, menelusuri skenario umum, dan mencari cara untuk mengukur keberhasilan. Ukur keberhasilan dengan mencakup tujuan Anda ke tujuan bisnis.

Mengidentifikasi tujuan dan skenario utama

Untuk memulai, pertama-tama nilai di mana organisasi Anda hari ini dengan Model Kemampuan Rekayasa Platform. Gunakan model untuk membuat bagan di mana organisasi Anda berada di enam kemampuan rekayasa platform inti - investasi, adopsi, tata kelola, provisi dan mangement, antarmuka, serta pengukuran dan umpan balik. Semua organisasi lebih maju dalam beberapa kemampuan daripada yang lain. Setelah Anda tahu di mana organisasi Anda berdiri hari ini, Anda dapat memilih kemampuan mana yang ingin Anda kembangkan. Untuk mempelajari lebih lanjut, lihat cara menggunakan model.

Anda dapat terus merencanakan dan memperbarui tujuan rekayasa platform Anda dari waktu ke waktu. Menjadi jelas tentang apa yang ingin Anda peroleh dari berinvestasi dalam perjalanan teknik platform Anda dapat berjalan jauh dalam membantu membangun dukungan organisasi.

Sebagai pemimpin rekayasa platform, "Saya tidak melakukan sesuatu untuk rekayasa platform sampai saya memiliki sesuatu yang dapat saya peroleh darinya." - Peter, pemimpin teknik platform, Perusahaan Teknologi Multinasial

Saat Anda memikirkan tujuan Anda, cakupannya ke tujuan bisnis yang terkait dengan upaya rekayasa platform Anda, daripada spesifik tim pengembangan tertentu. Tujuan rekayasa platform tingkat tinggi umum meliputi:

  • Tingkatkan kualitas aplikasi, kurangi bug, dan masalah selama rilis.
  • Tingkatkan keamanan, kurangi jumlah insiden keamanan, atau deteksi Kerentanan dan Paparan Umum (CVE) sekali dalam produksi.
  • Mengurangi risiko melalui kepatuhan yang lebih baik di area seperti lisensi, aksesibilitas, privasi, atau peraturan pemerintah.
  • Mempercepat nilai waktu ke bisnis dengan mengurangi kompleksitas, overhead, dan mempromosikan berbagi kode melalui praktik sumber dalam.
  • Kurangi biaya pengembangan atau operasi, minimalkan duplikasi, dan tingkatkan otomatisasi.

Memilih tujuan utama Anda sangat penting karena tujuan Anda mendorong bagaimana Anda berpikir tentang prioritas Anda.

Lebih baik lagi, menyetujui tujuan dan hasil utama (OKR) dengan kepemimpinan dan mitra internal Anda mengarah pada pembentukan tujuan terukur untuk fase investasi Anda saat ini. (Pendekatan perencanaan lainnya memiliki konsep serupa jika organisasi Anda menggunakan sesuatu yang lain.) OKR terbaik adalah yang dapat Anda tetapkan berdasarkan ukuran konkret karena menghilangkan subjektivitas.

Skenario dan pekerjaan yang akan dilakukan

Setelah mengidentifikasi tujuan Anda, pilih skenario utama untuk mengusir backlog dan peta strategi Anda. Misalnya, lihat skenario ini dan pekerjaan terkait yang akan dilakukan.

Skenario: Mulai membangun aplikasi baru

  • Memahami dan menerapkan praktik dan kebijakan terbaik organisasi
  • Buat repositori baru
  • Alat provisi
  • Menyediakan infrastruktur umum
  • Memberikan akses kepada anggota tim
  • Membuat alur CI/CD
  • Penyediaan infrastruktur pengembangan
  • Penyebaran awal untuk menguji "pipa"

Skenario: Menambahkan atau menghapus anggota baru ke tim yang sudah ada

  • Memperbarui akses ke alat, layanan
  • Menyiapkan mesin pengembang
  • Meningkatkan anggota tim pada aplikasi
  • Membuat lingkungan kotak pasir aplikasi
  • Membuat dan meninjau PR pertama

Skenario: Menambahkan atau memperbarui infrastruktur untuk aplikasi yang sudah ada

  • Memahami praktik terbaik organisasi, opsi yang tersedia
  • Memperbarui / menambahkan infrastruktur sebagai artefak kode
  • Membuat lingkungan kotak pasir aplikasi
  • Memverifikasi pembaruan
  • Meluncurkan perubahan pada lingkungan lain

Skenario: Menambahkan atau memperbarui alat untuk tim yang sudah ada

  • Memahami praktik terbaik organisasi, opsi yang tersedia
  • Meminta penggunaan alat baru
  • Memperbarui akses anggota tim ke alat
  • (Jika berlaku) Mengintegrasikan alat ke dalam klien atau alur CI/CD

Skenario: Menemukan atau menggunakan kembali API, SDK, atau layanan yang ada

  • Menemukan API, SDK, layanan yang tersedia
  • Menilai apakah memenuhi kebutuhan
  • Terhubung dengan tim pemilik untuk pertanyaan apa pun
  • Adopsi untuk aplikasi

Skenario: Menanggapi insiden operasi

  • Pemberitahuan masalah
  • Menilai apakah kode aplikasi atau terkait infra (atau keduanya)
  • Membuat lingkungan kotak pasir yang mencerminkan prod (jika berbeda)
  • Membuat perubahan, pengujian, rilis di luar band

Skenario: Memulihkan insiden keamanan dengan cepat

  • Pemberitahuan masalah
  • Menilai luasnya masalah (sistem mana)
  • Pahami apakah pelanggan terkena dampak langsung
  • Membuat lingkungan kotak pasir yang mencerminkan prod (jika berbeda)
  • Membuat perubahan, pengujian, rilis di luar band
  • Berkomunikasi dengan siapa pun yang terpengaruh

Skenario: Alat penghentian

  • Memahami penggunaan alat
  • Memberi tahu pengguna tentang penghentian
  • (Opsional) Migrasi koordinasi pengguna ke alat baru

Skenario: Peluncuran model arsitektur aplikasi baru

  • Arsitektur yang diusulkan pilot
  • Menyesuaikan berdasarkan hasil pilot
  • Memperbarui dokumentasi praktik terbaik
  • Membuat templat, memperbarui otomatisasi, kebijakan, tata kelola

Mengaudit kepatuhan aplikasi (GDPR, aksesibilitas, standar infrastruktur)

  • Memahami aturan kepatuhan saat ini
  • Memverifikasi aplikasi memenuhi aturan
  • Menetapkan tenggat waktu perbaikan untuk penyimpangan
  • Membuat perubahan, menguji, merilis

Banyak skenario berlaku untuk lebih dari satu peran. Pikirkan tentang metrik tentang bagaimana Anda akan mengukur peningkatan.

Dari masalah hingga konsep

Selanjutnya, cari untuk memahami masalah terbesar yang dihadapi pengembang Anda dan peran lain dengan skenario dan pekerjaan yang Anda identifikasi. Mungkin menggoda untuk mulai menyelidiki produk baru untuk mengisi celah yang dirasakan, tetapi jika produk-produk ini tidak menyelesaikan titik sakit utama, mereka tidak mungkin diadopsi atau dihargai.

Ada beberapa pendekatan yang dapat membantu Anda melakukan penyelidikan semacam ini. Salah satunya adalah Kerangka Kerja Kemajuan Hipotesis. Bahkan jika Anda tidak menggunakan proses formal seperti Kerangka Kerja Kemajuan Hipotesis, Anda harus mewawancarai pengembang tentang pekerjaan yang harus dilakukan untuk mencakup diskusi, dan kemudian mengidentifikasi masalah terbesar mereka dalam menyelesaikan pekerjaan mereka. Setelah Anda memiliki rasa yang baik tentang apa masalah ini, lanjutkan untuk datang dengan rencana untuk menyelesaikannya. Ini membantu memastikan bahwa Anda membangun fitur yang ingin digunakan pengembang.

Agar dapat dengan cepat mengulangi proses ini, identifikasi seseorang yang dapat mewakili suara pelanggan langsung di tim platform pengembang internal Anda. Peran ini biasanya disebut manajer produk (bahkan jika mereka memiliki jabatan yang berbeda), dan ketika pengetahuan mereka tumbuh, mereka dapat secara akurat memprediksi hasil untuk keputusan yang lebih kecil dan menentukan kapan Anda perlu melakukan lebih banyak wawancara. Ini menjaga kelincahan Anda tetap terjaga sambil tetap memastikan Anda berfokus pada pengiriman nilai kepada pelanggan internal Anda.

Buat kasus untuk investasi awal Anda

Setelah Anda memiliki serangkaian masalah dan konsep yang divalidasi, Anda berada dalam posisi yang baik untuk memutuskan di mana harus berinvestasi. Namun, pertimbangkan investasi di muka dan pemeliharaan jangka panjang yang diperlukan saat mengevaluasi solusi. Solusi upaya terendah yang dapat menyelesaikan masalah cenderung menjadi yang tepat untuk memulai, tetapi seringkali itu adalah pekerjaan pemeliharaan yang pada akhirnya memutuskan apakah investasi Anda berhasil.

Dengan cara lain, jangan membuat solusi yang menargetkan tahap selanjutnya dari perjalanan Anda kecuali Anda benar-benar perlu.

Setelah mengidentifikasi platform layak (TVP) tertipis ( MVP untuk platform Anda), uji coba dengan sekumpulan tim pengembangan yang bersedia memberikan umpan balik. Jika solusi pilot Anda memecahkan masalah yang dihadapi tim ini, Anda seharusnya tidak kesulitan menemukan seseorang yang tertarik untuk terlibat.

Anda harus mengambil beberapa metrik utama saat Anda menguji coba kemampuan atau perubahan baru sehingga Anda dapat mengukur apakah konsep berhasil sebelum Anda meluncurkannya.

Mengukur nilai keberhasilan dan pembuktian

Mengukur seberapa sukses Anda adalah bagian penting dari pola pikir produk. Bahkan keberhasilan kecil dengan investasi sederhana dapat meletakkan dasar untuk investasi yang lebih besar untuk dibangun.

Misalnya, mungkin sulit untuk mengamankan pendanaan atau pembelian untuk upaya kepatuhan karena dapat dianggap sebagai pajak operasi kepada tim pengembangan yang memberikan nilai bisnis. Pola pikir produk dapat mengubah persepsi tersebut. Dengan pola pikir produk, Anda mencoba memastikan pelanggan untuk platform pengembang internal Anda senang, dan bahwa tujuan bisnis pemangku kepentingan terpenuhi. Metrik menempatkan Anda dalam posisi untuk menggunakan fakta untuk membuktikan bahwa Anda memberikan nilai bisnis. Pengaturan OKR dapat membantu, terutama jika Anda memiliki metrik yang dapat Anda gunakan untuk membantu menghapus bias subjektif. Bahkan jika Anda tidak mengukur apa pun yang berlaku hari ini, Anda dapat mengatur OKR pembelajaran untuk mengatur garis besar yang kemudian akan Anda persiapkan setelah garis besar ini diketahui.

Berikut ini adalah contoh metrik terkenal yang dapat Anda ukur untuk menentukan apakah tim yang bekerja dengan Anda mendapatkan nilai dari apa yang Anda bangun. Nol pada mereka yang membantu Anda mengukur apakah Anda, dan pelanggan tim pengembangan Anda, mencapai tujuan Anda. Misalnya, berikut ini adalah sekumpulan metrik yang membantu Anda mengevaluasi apakah platform Anda berkontribusi pada organisasi teknik yang efektif:

  • Kecepatan / waktu untuk nilai bisnis: Hari median untuk menyelesaikan permintaan pull pertama (onboarding), menit median untuk proses build dan pengujian (misalnya: CI), waktu median untuk menggabungkan permintaan pull.
  • Kualitas perangkat lunak: Insiden (masalah) yang dibuat per bulan per dev(hitungan yang dinormalisasi ke jumlah dev), waktu rata-rata untuk memulihkan (MTTR), waktu rata-rata untuk menyelidiki dan memulihkan masalah keamanan.
  • Kemudahan penggunaan platform: Kepuasan pengguna bersih (NSAT)
  • Ekosistem yang berkembang: Skor rata-rata untuk setiap pertanyaan yang disurvei berikut: "Saya didayakan untuk melakukan pekerjaan terbaik saya," "sebagian besar hari saya diberi energi oleh pekerjaan yang saya lakukan," "pekerjaan yang saya lakukan bermakna bagi saya."

Anda kemudian dapat memecah metrik ini berdasarkan organisasi, tim, atau proyek. Untuk memulai, Anda perlu mengukur beberapa garis besar, tetapi Anda kemudian dapat melihat metrik ini berubah saat Anda meningkatkan platform Anda.

Metrik lain yang mungkin Menarik bagi Anda atau sponsor Anda meliputi:

Luas Contoh metrik
Performa pengiriman perangkat lunak DevOps Research and Assessment (DORA): Mengubah waktu tunggu, frekuensi penyebaran, mengubah tingkat kegagalan, waktu untuk memulihkan layanan (MTTR)
Operasional DORA (MTTR), rata-rata waktu antara kegagalan (MTBF), waktu rata-rata untuk mengakui, ketersediaan pelanggan akhir, latensi, metrik throughput, biaya per tim, biaya per penyebaran
Metrik adopsi kemampuan platform Jumlah tim atau pengembang yang menggunakan alat atau fitur dari waktu ke waktu, persentase repositori menggunakan platform, templat paling populer, alur, dll.

Mengumpulkan metrik memerlukan waktu dan upaya sehingga penting untuk fokus pada metrik penting untuk tujuan inti yang Anda identifikasi - terutama yang mendukung OKR Anda. Produk berbasis OpenTelemetry seperti Application Insights dapat membantu. Terlepas dari itu, pastikan untuk mengukur kemudahan penggunaan dan survei platform bahwa Anda memiliki ekosistem yang berkembang secara teratur. Metrik ini sering terlewatkan untuk sistem internal dan merupakan indikator utama apakah Anda memenuhi tujuan bisnis Anda yang lebih luas karena partisipasi yang terlibat sangat penting untuk keberhasilan. Ini juga membantu Anda mengetahui apakah sudah waktunya untuk melakukan pengembangan pelanggan lebih lanjut untuk memahami ke mana harus pergi berikutnya.

Tips lainnya

Terlepas dari bagaimana Anda memulai, perlu diingat bahwa Anda harus merencanakan perubahan, memulai dengan aplikasi baru untuk pilot, fokus pada peningkatan pengalaman pengguna yang ada, mengadopsi prinsip hak istimewa paling sedikit, merencanakan eksperimen terkontrol, dan meminimalkan penyesuaian.

Rencana perubahan

Platform aplikasi target Anda akan berkembang dari waktu ke waktu, dan Anda mungkin tidak dapat memigrasikan semua investasi yang ada sekaligus. Pikirkan bagaimana Anda dapat mendukung lebih dari satu variasi dari waktu ke waktu dan merencanakan perubahan.

Memvalidasi ide dengan aplikasi yang lebih baru

Mulailah dengan aplikasi baru dengan ukuran yang wajar saat Anda menguji coba kemampuan platform atau platform baru Anda. Ini juga akan memberi Anda pengalaman mengelola platform Anda sebagai produk. Malu-malu dari mereplatformasi proyek untuk memulai karena Anda belajar saat Anda pergi, dan aplikasi besar yang ada sering memiliki kebutuhan unik yang hanya terungkap selama upaya platforming ulang itu sendiri. Karena itu, mengkoplorasi keberhasilan Anda terhadap jenis upaya ini dapat mengakibatkan ketidakcocokan harapan atau masalah yang terlambat melanggar. Dimulai dengan sesuatu yang lebih baru dapat memberi Anda keyakinan pada arah nilai yang disediakannya. Itu mengurangi risiko mengatasi upaya yang lebih besar ini. Dengan cara lain, jika Anda yakin orang dapat memulai dengan benar dan tetap benar, maka menjadi lebih mudah untuk mendorong kampanye yang tepat dengan apa yang Anda pelajari dari pengalaman. Jika pendekatan ini tidak memungkinkan, Anda harus melakukan analisis yang cermat, menetapkan harapan, dan secara bertahap masuk daripada mencoba mengubah semuanya sekaligus.

Fokus pada pusat gravitasi yang ada untuk pengalaman pengguna sebelum membuat yang baru

Pengembang lebih cenderung mengadopsi dan tetap dengan kemampuan baru ketika muncul dalam sesuatu yang sudah mereka sukai dan gunakan. Saat Anda mengevaluasi konsep untuk memberikan kemampuan baru, pastikan untuk menyelidiki opsi yang mengambil "pusat gravitasi" yang ada. Misalnya, editor/IDEs (Visual Studio, VS Code), DevOps suites (GitHub, Azure DevOps), CLIs yang ada, atau portal internal yang ada dapat lebih efektif daripada portal yang sama sekali baru atau UX lainnya. Lihat pengalaman pengguna untuk mempelajari selengkapnya.

Asumsikan prinsip hak istimewa paling sedikit

Asumsikan pengembang memiliki akses terbatas ke sistem hilir untuk hal-hal seperti penyediaan infrastruktur. Anda akan memerlukan cara terkontrol untuk mengaktifkan akses ini untuk pengalaman layanan mandiri.

Merencanakan eksperimen terkontrol

Eksperimen sebelum meluncurkan perubahan besar atau berisiko. Tidak semuanya harus sepenuhnya otomatis untuk memulai. Alur kerja manual yang dipicu secara otomatis dapat menjadi cara yang bagus untuk menguji ide.

Meminimalkan kustomisasi Platform Aplikasi

Hindari kemampuan platform aplikasi bangunan kustom yang dapat dilepaskan oleh kemampuan rilis vendor perangkat lunak dari waktu ke waktu. Misalnya, hosting runtime, jala layanan, sistem identitas, dan sebagainya. Jika Anda menemukan kebutuhan mendesak di area yang Anda duga mungkin seperti ini, rencanakan beberapa opsi implementasi mengingat pemeliharaan jangka panjang kemungkinan akan menyebabkan Anda beralih dari waktu ke waktu.