Railway , platform infrastruktur cloud yang melayani 1,7 juta pengguna, telah membagikan perjalanan mereka menjauh dari metode perencanaan tradisional setelah berjuang dengan proses yang sarat formalitas yang menciptakan lebih banyak kebingungan daripada kejelasan. Evolusi perusahaan selama 18 bulan dari OKRs ke pendekatan Problem Driven Development mereka saat ini menawarkan wawasan mengapa banyak perusahaan teknologi merasa perencanaan kuartalan membuat frustrasi dan tidak efektif.
Struktur Organisasi Railway:
- Tim Produk: Engineering untuk fitur UI dan Terminal
- Tim Platform: Pengembangan infrastruktur dan API
- Tim Logistik: Fungsi dukungan, pemasaran, dan penjualan
- Total Ukuran Tim: 27 orang
- Basis Pengguna: 1,7+ juta pelanggan
Eksperimen OKR yang Berbalik Arah
Seperti banyak startup yang berkembang, Railway awalnya beralih ke Objectives and Key Results (OKRs) ketika mereka perlu menyelaraskan tim yang berkembang. Perusahaan dengan tekun membaca buku-buku yang direkomendasikan dan menerapkan kerangka kerja tersebut, tetapi dengan cepat menemukan bahwa OKRs bekerja lebih baik di lingkungan pabrik daripada lingkungan pengembangan perangkat lunak. Kerangka kerja tersebut unggul dalam tujuan konkret dan biner tetapi kesulitan dengan pekerjaan rekayasa kreatif dan tujuan tak terbatas seperti meningkatkan tingkat konversi.
Tim menemukan diri mereka menghabiskan lebih banyak waktu memperdebatkan apa yang merupakan OKR yang valid daripada benar-benar memutuskan apa yang akan dibangun. Perencanaan performatif ini menghabiskan siklus rekayasa yang berharga sambil menciptakan ketidakfleksibelan yang membuat koreksi di tengah jalan hampir tidak mungkin. Diskusi komunitas mengungkapkan ini tidak unik untuk Railway - banyak organisasi berjuang dengan masalah serupa ketika menerapkan proses yang dirancang untuk pabrik pada pekerjaan pengetahuan kreatif.
Dari Proyek ke Masalah
Solusi Railway membalik perencanaan tradisional. Alih-alih meminta tim untuk mengusulkan solusi, mereka sekarang fokus secara eksklusif pada artikulasi masalah. Pergeseran ini menghilangkan keterikatan emosional yang sering dirasakan pengembang terhadap solusi yang mereka usulkan dan mencegah komitmen prematur pada pendekatan spesifik sebelum memahami apa yang perlu dipecahkan.
Fokus pada masalah, bukan solusi adalah praktik standar yang cukup umum. Sepertinya penulis memilih-milih beberapa konsep abstrak dari perusahaan besar dan perencanaan yang didorong proses mereka.
Proses kuartalan empat hari mereka terbagi menjadi fase-fase yang berbeda: pengumpulan masalah, prioritas tim independen, resolusi dependensi, dan komitmen publik. Hanya setelah berkomitmen untuk memecahkan masalah spesifik mereka mulai menulis spesifikasi teknis dan menentukan pendekatan implementasi.
Proses Perencanaan Empat Hari Railway:
- Hari 1: Tim secara independen memasukkan masalah (tanpa solusi)
- Hari 2: Sesi tim tertutup untuk peringkat prioritas (P0/P1/P2)
- Hari 3: Resolusi ketergantungan lintas tim dan konfirmasi kapasitas
- Hari 4: Komitmen publik dan penugasan DRI (Directly Responsible Individual)
Pemeriksaan Realitas Kapasitas
Satu elemen penting yang membedakan pendekatan Railway adalah penekanan mereka pada perencanaan kapasitas yang jujur. Sebelum menyelesaikan komitmen, mereka menilai beban kerja saat ini, rotasi siaga, dan peristiwa kehidupan yang akan datang seperti cuti orang tua. Jika mereka mengidentifikasi delapan masalah prioritas tetapi hanya memiliki kapasitas untuk lima, mereka membuat keputusan eksplisit tentang apa yang turun prioritasnya atau peran apa yang perlu mereka rekrut.
Pendekatan berbasis realitas ini menangani kritik umum di komunitas tentang berkomitmen pada pekerjaan sebelum memahami kompleksitas implementasi. Sementara beberapa berpendapat ini menciptakan masalah gambar sisa burung hantu, budaya rekayasa otonom Railway memungkinkan penyesuaian di tengah kuartal ketika masalah terbukti lebih kompleks daripada yang diperkirakan awalnya.
Tingkat Prioritas yang Digunakan:
- P0: Risiko eksistensial perusahaan - harus diselesaikan
- P1: Harus diselesaikan kuartal ini
- P2: Bagus untuk dimiliki
Skeptisisme Komunitas dan Pertanyaan yang Lebih Luas
Komunitas pengembang tetap terbagi pada pendekatan Railway . Beberapa mempertanyakan apakah perencanaan kuartalan itu sendiri adalah masalah fundamental, terutama untuk perusahaan yang masih mencari kesesuaian produk-pasar di mana rencana tiga bulan dapat menjadi usang dalam hitungan minggu. Yang lain mengakui pendekatan tersebut sebagai variasi dari praktik manajemen produk yang sudah mapan seperti pohon solusi peluang, menunjukkan Railway mungkin telah menemukan kembali metodologi yang sudah ada daripada menciptakan sesuatu yang benar-benar baru.
Diskusi ini menyoroti ketegangan yang lebih dalam dalam pengembangan perangkat lunak antara kebutuhan koordinasi dalam skala dan sifat pekerjaan teknis kreatif yang secara inheren tidak dapat diprediksi. Seperti yang dicatat oleh satu anggota komunitas, tantangan sebenarnya seringkali bukan proses perencanaan itu sendiri, tetapi faktor organisasi seperti insentif yang tidak selaras dan kurangnya pemahaman lintas fungsi.
Pengalaman Railway menunjukkan bahwa perencanaan yang efektif bukan tentang menemukan kerangka kerja yang sempurna, tetapi tentang membangun proses yang sesuai dengan psikologi dan gaya kerja tim Anda. Penekanan mereka pada masalah daripada solusi, prioritas independen sebelum negosiasi, dan penilaian kapasitas yang jujur menawarkan alternatif praktis untuk tim yang berjuang dengan pendekatan perencanaan tradisional. Apakah metode ini dapat diskalakan melampaui tim 27 orang mereka saat ini masih harus dilihat, tetapi kesediaan mereka untuk beriterasi dan berbagi pelajaran yang dipelajari berkontribusi data berharga untuk percakapan yang sedang berlangsung tentang perencanaan pengembangan perangkat lunak yang efektif.
Referensi: Why most product planning is bad and what to do about it