Bagaimana Ketidaknyamanan Pelanggan Menjadi Produk - Proses Pengembangan Tim API Airbridge

Artikel pengantar tentang proses yang digunakan tim API untuk membangun Airbridge, alat pemasaran B2B

• Mengumpulkan permintaan dan ide dari pelanggan
• Menentukan masalah yang harus diselesaikan berdasarkan prioritas
• Melakukan kick-off
  • Memahami pekerjaan seperti apa yang akan dilakukan dan merinci skenario pengguna
  • Developer juga ikut serta sejak tahap ini dan secara aktif menyampaikan pendapat teknis
• Menulis tech spec
  • Menuliskan ringkasan, latar belakang, tujuan, hal-hal yang bukan tujuan, rencana kerja, perkiraan Q&A, hal-hal yang perlu dipertimbangkan, dan milestone
  • Mencoba menulis terlebih dahulu sekitar 30% dari kode yang akan dikerjakan untuk membuat rencana yang realistis
  • Mereview bersama counterpart
• Pengerjaan kode
  • Semua kode wajib memiliki test code yang sesuai
• QA & Code Review
  • Melalui feature branch, endpoint QA dibuat secara otomatis
  • Untuk membantu Code Review, otomatisasi eksekusi tes dan alat analisis statis juga dijalankan secara otomatis
• Release
  • Merayakan bersama rekan kerja karena produk telah menjadi lebih baik

Melalui proses ini, siklus umpan balik dipersingkat, tahap pengembangan dibuat transparan sehingga jadwal menjadi lebih mudah diprediksi, dan kemungkinan terjadinya bug pada fitur dapat dikurangi

• Error akibat deployment fitur baru turun 18% dibanding periode yang sama, dan tiket berukuran kecil tetap bisa dirilis hanya dalam 5 hari meski mengikuti proses ini

[yunyun0505]

Ada satu hal yang pasti dipelajari saat mengambil mata kuliah rekayasa perangkat lunak di kampus. “Melakukan revisi pada tahap perencanaan membutuhkan biaya paling kecil, dan melakukan revisi setelah pengembangan selesai membutuhkan biaya paling besar.” Ini adalah prinsip yang sulit dijalankan meski kita memahaminya. Terlebih lagi di startup yang bergerak cepat.
Tim pengembang Airbridge berusaha tetap melangkah ke arah yang mereka yakini benar, meskipun sulit.