Selama bertahun-tahun, cara perusahaan membuat software kurang lebih mengikuti pola yang sama.
Tim bisnis menyampaikan kebutuhan. Product manager menerjemahkannya menjadi requirement. Designer membuat rancangan. Engineer kemudian mengubah semuanya menjadi kode.
.png "Forward Deployed Engineer: Kenapa Engineer Harus Turun Langsung ke Lapangan?") |
| Forward Deployed Engineer: Kenapa Engineer Harus Turun Langsung ke Lapangan? |
Kelihatannya sederhana.
Tapi ada satu masalah besar: requirement belum tentu sama dengan masalah sebenarnya.
Pengguna bisa mengatakan mereka membutuhkan dashboard, padahal masalahnya bukan kekurangan dashboard. Mereka mungkin meminta chatbot, padahal yang sebenarnya membuat pekerjaan lambat adalah proses mencari data dari berbagai sistem.
Di sinilah konsep Forward Deployed Engineer (FDE) menjadi menarik.
Alih-alih hanya menerima requirement dari jauh, engineer ditempatkan sedekat mungkin dengan pengguna. Mereka ikut melihat bagaimana pekerjaan dilakukan, memahami masalah yang terjadi, membuat prototype, menguji solusi, dan membantu memastikan teknologi yang dibuat benar-benar memberikan hasil.
Konsep ini semakin relevan sekarang karena AI membuat proses membangun software menjadi jauh lebih cepat.
Ketika membuat software semakin mudah, pertanyaan yang menjadi semakin penting bukan lagi sekadar "seberapa cepat kita bisa membuatnya?", tetapi "apakah kita sedang membuat sesuatu yang benar?"
Apa Itu Forward Deployed Engineer?
Forward Deployed Engineer adalah engineer yang bekerja langsung dengan customer atau pengguna untuk memahami masalah mereka dan membangun solusi yang sesuai dengan kondisi nyata.
Seorang FDE bukan hanya bertugas menerima tiket lalu mengerjakannya.
Mereka bisa terlibat dalam berbagai aktivitas seperti:
Bertemu langsung dengan customer
Mengamati workflow pengguna
Memahami sistem yang sudah digunakan
Menganalisis masalah teknis dan bisnis
Membuat prototype
Menguji solusi bersama pengguna
Melakukan iterasi berdasarkan feedback
Mengimplementasikan solusi
Mengukur apakah solusi tersebut benar-benar memberikan hasil
Karena itu, posisi FDE sering berada di antara software engineer, product engineer, solutions engineer, product manager, dan customer-facing engineer.
Namun yang paling penting bukanlah nama jabatannya.
Yang penting adalah kedekatan dengan masalah dan tanggung jawab terhadap outcome.
Kenapa Engineer Perlu Bertemu Langsung dengan Pengguna?
Engineer biasanya sangat memahami teknologi.
Kita tahu bagaimana API bekerja, bagaimana database dirancang, bagaimana sistem di-deploy, bagaimana CI/CD dibuat, dan bagaimana aplikasi dioptimalkan.
Tetapi ada sesuatu yang sulit ditemukan di dokumentasi teknis:
konteks pengguna.
Misalnya sebuah perusahaan meminta:
"Kami membutuhkan fitur approval."
Secara teknis, requirement tersebut terlihat cukup jelas.
Engineer mungkin langsung membuat workflow approval dengan beberapa status:
Pending → Approved → Rejected
Tetapi ketika engineer benar-benar melihat proses pengguna, mungkin ditemukan hal lain.
Ternyata approval dilakukan oleh beberapa orang secara berurutan. Sebagian approver tidak mendapatkan notifikasi. Data yang dibutuhkan untuk mengambil keputusan berada di sistem lain. Bahkan beberapa orang masih menggunakan WhatsApp untuk memastikan bahwa approval mereka sudah diproses.
Requirement awal ternyata hanya permukaan.
Masalah sebenarnya jauh lebih kompleks.
Dengan berada langsung bersama pengguna, engineer dapat melihat hal-hal yang biasanya hilang ketika kebutuhan sudah berubah menjadi ticket Jira.
FDE Bukan Software House
Sekilas, pendekatan ini mungkin terdengar seperti pekerjaan konsultan atau software house.
Namun ada perbedaan penting.
Dalam model custom software development, customer biasanya mengatakan apa yang ingin dibuat.
Contohnya:
"Buatkan aplikasi seperti ini."
Vendor kemudian membuat aplikasi sesuai spesifikasi yang telah disepakati.
Model tersebut bisa bekerja dengan baik jika kebutuhan memang sudah jelas.
Tetapi bagaimana jika customer sendiri belum mengetahui solusi terbaik?
FDE menggunakan pendekatan berbeda.
Daripada hanya bertanya:
"Fitur apa yang Anda inginkan?"
mereka mencoba memahami:
"Masalah apa yang sebenarnya ingin Anda selesaikan?"
Kemudian pertanyaan berikutnya:
"Seperti apa kondisi jika masalah tersebut berhasil diselesaikan?"
Ini membuat fokus bergeser dari feature delivery menuju outcome delivery.
Dari Feature ke Outcome
Perbedaan ini sangat penting dalam pengembangan produk.
Bayangkan sebuah perusahaan memiliki tim customer support yang membutuhkan waktu rata-rata 15 menit untuk menyelesaikan satu tiket.
Manajemen kemudian meminta:
"Buatkan chatbot AI."
Jika engineer hanya mengikuti requirement, hasil akhirnya mungkin memang sebuah chatbot.
Namun setelah mengamati workflow tim support, FDE menemukan bahwa sebagian besar waktu sebenarnya habis untuk mencari informasi dari beberapa sistem internal.
Dalam kondisi seperti itu, chatbot mungkin bukan solusi terbaik.
Solusi yang lebih berguna bisa berupa AI assistant internal yang otomatis mengambil data dari berbagai sistem dan menyajikannya kepada customer support.
Hasil akhirnya bukan:
"Kita berhasil membuat chatbot."
Tetapi:
"Waktu penyelesaian tiket turun dari 15 menit menjadi 5 menit."
Itulah perbedaan antara menyelesaikan fitur dan menyelesaikan masalah.
Kenapa FDE Semakin Penting di Era AI?
AI mengubah biaya dan kecepatan dalam membuat software.
Dengan AI coding assistant dan AI coding agent, developer sekarang dapat membuat prototype dalam waktu yang jauh lebih singkat.
Kode yang sebelumnya membutuhkan berjam-jam bisa dibuat jauh lebih cepat.
Namun ada konsekuensi yang menarik.
Ketika kemampuan membuat software meningkat, kemampuan menentukan software apa yang seharusnya dibuat menjadi semakin penting.
Kita bisa membuat aplikasi lebih cepat.
Kita bisa membuat prototype lebih cepat.
Kita bahkan bisa membuat beberapa alternatif solusi dalam waktu singkat.
Tetapi semua itu tidak berarti produk yang dibuat otomatis menjadi berguna.
Hal ini berkaitan dengan fenomena yang sebelumnya dibahas dalam artikel The AI Productivity Paradox: Mengapa AI Belum Tentu Membuat Developer Lebih Produktif.
AI bisa meningkatkan jumlah kode yang dihasilkan seorang developer, tetapi peningkatan output kode tidak selalu berarti peningkatan nilai bagi pengguna.
Kalau kita membangun produk yang salah dengan sangat cepat, hasilnya tetap produk yang salah.
Bedanya, sekarang kita mendapatkannya lebih cepat.
FDE dan AI Coding Agent
Bayangkan seorang engineer mendapat tugas:
"Buat AI agent untuk membantu tim finance."
Ada dua cara mengerjakannya.
Cara pertama adalah langsung masuk ke sisi teknis.
Engineer memilih framework, menentukan model AI, membuat API, menyiapkan database, menghubungkan tools, lalu mulai membangun agent.
Cara kedua adalah menggunakan pendekatan FDE.
Engineer terlebih dahulu duduk bersama tim finance.
Mereka melihat pekerjaan yang dilakukan setiap hari.
Ternyata setiap pagi tim finance harus:
Mengambil data dari beberapa sistem.
Membersihkan data.
Membandingkan transaksi.
Mencari transaksi yang mencurigakan.
Membuat laporan.
Mengirim laporan kepada stakeholder.
Setelah memahami workflow tersebut, engineer membuat prototype sederhana.
Prototype kemudian digunakan oleh tim finance.
Ditemukan bahwa AI agent sering memberikan jawaban yang terlihat benar tetapi tidak mencantumkan sumber datanya.
Engineer memperbaikinya.
Prototype diuji lagi.
Kemudian muncul masalah lain.
Iterasi terus dilakukan sampai solusi tersebut benar-benar membantu pekerjaan pengguna.
Inilah yang membuat FDE sangat dekat dengan product discovery.
AI Bisa Membuat Prototype, Tapi Tidak Bisa Menggantikan Pemahaman Masalah
AI coding tools membuat proses eksperimen menjadi semakin murah.
Developer tidak perlu selalu menghabiskan waktu berhari-hari untuk membuktikan sebuah ide.
Prototype sederhana bisa dibuat lebih cepat.
Namun prototype yang cepat tetap membutuhkan pertanyaan yang benar.
Misalnya:
"Bisakah kita membuat AI agent untuk proses ini?"
Pertanyaan yang lebih baik adalah:
"Apakah proses ini memang membutuhkan AI agent?"
Dan bahkan setelah itu:
"Bagian mana yang seharusnya diotomatisasi?"
"Bagian mana yang harus tetap dilakukan manusia?"
"Apa konsekuensinya jika AI salah?"
Pertanyaan tersebut tidak bisa dijawab hanya dengan menulis kode.
Kita perlu memahami lingkungan tempat software tersebut digunakan.
Hubungannya dengan AI Agent
AI agent membuat konsep FDE semakin relevan.
AI agent bukan sekadar chatbot.
Agent dapat membaca informasi, menggunakan tools, memanggil API, menjalankan workflow, dan dalam beberapa kasus mengambil tindakan berdasarkan kondisi tertentu.
Semakin besar kemampuan agent, semakin besar pula kebutuhan untuk memahami konteks pengguna.
Misalnya sebuah agent digunakan untuk membantu operasional perusahaan.
Engineer perlu mengetahui:
Data apa yang boleh diakses?
Data apa yang dianggap valid?
Keputusan apa yang boleh dilakukan otomatis?
Kapan manusia harus melakukan approval?
Apa yang terjadi jika agent memberikan keputusan yang salah?
Bagaimana aktivitas agent diaudit?
Bagaimana pengguna mengetahui alasan sebuah keputusan?
Hal-hal seperti ini jauh lebih mudah dipahami ketika engineer benar-benar berinteraksi dengan pengguna.
Karena itu, membangun AI agent bukan hanya masalah memilih LLM, membuat prompt, atau menggunakan framework agentic AI.
Masalah utamanya tetap sama:
Apa masalah yang ingin diselesaikan?
Pembahasan mengenai risiko ketika AI coding agent semakin mandiri juga bisa dibaca di artikel Ketika AI Coding Agent Menjadi Terlalu Mandiri.
Jangan Sampai FDE Berubah Menjadi Tim Software Custom
Ada jebakan dalam pendekatan FDE.
Jika engineer terlalu fokus pada satu customer, perusahaan bisa berakhir dengan banyak solusi yang sangat spesifik.
Misalnya:
Customer A mendapatkan solusi A.
Customer B mendapatkan solusi B.
Customer C mendapatkan solusi C.
Setiap solusi memiliki database, workflow, dan kode yang berbeda.
Dalam jangka panjang, perusahaan akan memiliki banyak software custom yang mahal untuk dirawat.
Karena itu, FDE yang baik tidak hanya mencari solusi untuk satu customer.
Mereka juga mencari pola yang dapat digunakan kembali.
Misalnya tiga perusahaan memiliki workflow yang berbeda, tetapi semuanya membutuhkan kemampuan untuk melakukan monitoring terhadap transaksi.
Implementasinya mungkin berbeda.
Tetapi dari sana perusahaan bisa membangun sebuah platform monitoring yang dapat digunakan oleh banyak customer.
Di sinilah product engineering dan platform engineering menjadi penting.
Dari Customer Discovery ke Product Discovery
Customer bukan hanya sumber revenue.
Customer juga bisa menjadi sumber pembelajaran.
Ketika engineer bekerja langsung dengan beberapa customer, mereka dapat melihat pola:
masalah yang sering berulang,
pekerjaan manual yang tidak efisien,
kebutuhan integrasi,
workaround yang dibuat pengguna,
fitur yang terus diminta,
dan masalah yang bahkan tidak pernah masuk ke requirement resmi.
Jika pola tersebut muncul berulang kali, mungkin ada peluang untuk membangun sebuah produk.
Alurnya kemudian berubah menjadi:
Customer → Problem → Discovery → Prototype → Experiment → Outcome → Product
Bukan hanya:
Customer → Requirement → Code
Perubahan ini sangat besar.
Prototype Menjadi Senjata Penting
FDE tidak harus menunggu berbulan-bulan untuk menunjukkan hasil kepada customer.
Prototype dapat digunakan untuk menguji asumsi.
Misalnya perusahaan memiliki hipotesis:
"AI dapat mengurangi pekerjaan manual tim operasional."
Daripada langsung membangun sistem produksi lengkap, engineer dapat membuat prototype kecil.
Prototype tersebut kemudian diberikan kepada pengguna.
Pengguna mencoba.
Mereka menemukan masalah.
Engineer memperbaiki.
Pengguna mencoba lagi.
Siklus tersebut terus berulang.
Dengan cara ini, perusahaan belajar sebelum menginvestasikan terlalu banyak waktu dan uang.
AI membuat siklus tersebut semakin cepat karena biaya membuat prototype menjadi lebih rendah.
FDE Tidak Harus Engineer
Walaupun namanya Forward Deployed Engineer, prinsipnya tidak hanya berlaku untuk engineer.
Product manager bisa melakukan hal yang sama.
Designer bisa melakukan hal yang sama.
Founder startup bahkan sering kali secara alami menjadi FDE pada tahap awal.
Founder bertemu customer.
Mendengar masalah.
Membuat prototype.
Menguji solusi.
Mengubah produk.
Kemudian kembali bertemu customer.
Siklus tersebut dilakukan berulang kali.
Karena itu, kemampuan untuk memahami pengguna secara langsung sebenarnya merupakan skill penting bagi hampir semua product creator.
Bagaimana Developer Bisa Mulai Menerapkan Konsep FDE?
Tidak perlu menunggu perusahaan mengubah struktur organisasi.
Developer bisa mulai dari hal sederhana.
1. Jangan Hanya Membaca Ticket
Ticket biasanya merupakan hasil akhir dari proses komunikasi.
Kalau memungkinkan, cari tahu siapa yang membuat request dan alasan di balik request tersebut.
2. Bicara dengan Pengguna
Jika ada kesempatan, ikut meeting dengan customer atau end user.
Tanyakan bagaimana mereka menggunakan sistem saat ini.
Lebih penting lagi, perhatikan apa yang mereka lakukan.
Kadang apa yang dilakukan pengguna berbeda dengan apa yang mereka katakan.
3. Lihat Workflow yang Sebenarnya
Dokumentasi mungkin mengatakan sebuah proses hanya memiliki tiga langkah.
Dalam praktiknya pengguna bisa melakukan sepuluh langkah tambahan karena adanya pekerjaan manual.
Temukan perbedaannya.
4. Buat Prototype
Tidak semua ide harus langsung dibuat production-ready.
Gunakan prototype untuk mendapatkan pembelajaran.
5. Ukur Outcome
Jangan hanya mengukur:
"Apakah fitur sudah selesai?"
Coba ukur:
"Apakah masalahnya benar-benar berkurang?"
Misalnya:
waktu pengerjaan berkurang,
error berkurang,
conversion meningkat,
pekerjaan manual berkurang,
atau pengguna mengambil keputusan lebih cepat.
6. Cari Pola
Jika masalah yang sama muncul pada banyak pengguna, jangan selalu membuat solusi custom.
Mungkin ada capability yang bisa dibuat lebih general.
Dari sinilah solusi untuk satu customer dapat berkembang menjadi produk.
FDE dan Perkembangan AI di Dunia Nyata
Perkembangan AI juga menunjukkan bahwa model AI semakin banyak digunakan untuk menyelesaikan persoalan di dunia nyata.
Salah satu contohnya adalah GeoPT, AI dari MIT yang membantu model memahami dan mensimulasikan dunia fisik.
Perkembangan seperti ini menunjukkan bahwa AI tidak lagi hanya digunakan untuk menghasilkan teks atau gambar.
AI semakin diarahkan untuk memahami lingkungan, melakukan reasoning, membuat prediksi, dan membantu menyelesaikan pekerjaan yang lebih kompleks.
Ketika AI masuk ke domain seperti finance, healthcare, manufacturing, logistics, engineering, dan operasi perusahaan, konteks menjadi semakin penting.
Model AI mungkin memiliki kemampuan general.
Tetapi masalah yang dihadapi setiap organisasi bisa sangat spesifik.
Di sinilah manusia yang memahami lingkungan pengguna tetap memiliki peran penting.
Apakah Semua Perusahaan Membutuhkan FDE?
Tidak.
Produk consumer sederhana dengan jutaan pengguna tentu tidak selalu membutuhkan engineer yang secara khusus ditempatkan bersama setiap customer.
Namun FDE sangat menarik untuk produk yang:
kompleks,
membutuhkan integrasi dengan sistem lain,
memiliki workflow khusus,
digunakan oleh perusahaan besar,
bergantung pada data internal,
atau menggunakan AI agent untuk melakukan pekerjaan nyata.
Terutama ketika customer sendiri belum dapat menjelaskan solusi yang mereka butuhkan secara detail.
Skill Engineer Akan Berubah
Ada satu pelajaran penting dari perkembangan ini.
Selama ini kemampuan engineer sering diukur dari kemampuan teknis.
Bisa membuat API.
Bisa merancang database.
Bisa membuat aplikasi.
Bisa memahami cloud.
Bisa melakukan debugging.
Semua itu tetap penting.
Tetapi ketika AI semakin mampu membantu pekerjaan coding, kemampuan memahami mengapa sesuatu harus dibangun menjadi semakin berharga.
Engineer yang hanya menerima requirement lalu menerjemahkannya menjadi kode akan semakin mudah dibantu oleh AI.
Sebaliknya, engineer yang mampu:
memahami masalah,
berbicara dengan pengguna,
memahami konteks bisnis,
membuat prototype,
melakukan eksperimen,
memahami trade-off,
dan mengukur outcome,
akan memiliki kemampuan yang jauh lebih sulit digantikan.
Mereka bukan sekadar programmer.
Mereka adalah product creator.
FDE + AI Bisa Menjadi Kombinasi yang Sangat Kuat
Kita sedang melihat perubahan besar dalam software engineering.
Dulu salah satu bottleneck terbesar adalah:
"Seberapa cepat kita bisa menulis kode?"
Sekarang AI secara perlahan mengurangi bottleneck tersebut.
Developer dapat membuat prototype lebih cepat.
Eksperimen menjadi lebih murah.
Code generation semakin mudah.
AI agent bahkan dapat membantu menjalankan sebagian workflow engineering.
Namun muncul bottleneck baru:
"Apakah kita sedang membangun sesuatu yang benar?"
Di sinilah FDE menjadi semakin relevan.
AI dapat membantu mempercepat proses membangun solusi.
FDE membantu memastikan solusi tersebut berasal dari pemahaman terhadap masalah nyata.
Kombinasi keduanya sangat kuat:
Manusia memahami masalah → AI membantu mengeksplorasi solusi → pengguna memberikan feedback → engineer melakukan iterasi → produk berkembang.
Kesimpulan
Forward Deployed Engineer bukan sekadar jabatan baru.
Pada dasarnya, konsep ini mengingatkan kita pada prinsip yang sangat sederhana dalam product development:
Bangun sesuatu berdasarkan pemahaman terhadap masalah nyata, bukan hanya berdasarkan dokumen requirement.
AI membuat software semakin mudah dan cepat dibuat.
Tetapi semakin mudah software dibuat, semakin penting kemampuan menentukan apa yang seharusnya dibuat.
Karena itu, waktu yang dihemat dari coding seharusnya tidak hanya digunakan untuk menghasilkan lebih banyak kode.
Sebagian dari waktu tersebut sebaiknya digunakan untuk berbicara dengan pengguna, memahami workflow, menguji asumsi, membuat prototype, dan mencari outcome yang benar-benar bernilai.
Pada akhirnya, software terbaik bukan software yang memiliki kode paling banyak.
Software terbaik adalah software yang berhasil menyelesaikan masalah penting bagi orang yang menggunakannya.
Dan mungkin di era AI, engineer yang paling berharga bukanlah engineer yang paling cepat menulis kode.
Melainkan engineer yang tahu apa yang harus dibangun, untuk siapa, dan mengapa hal tersebut penting.
.png&description=Forward Deployed Engineer: Kenapa Engineer Harus Turun Langsung ke Lapangan?){kind=link}
0 Comments