Workflow Dunia Tech : From WhatsApp to Deploy

Kadang kerjaan saya dimulai dari WhatsApp chat jam 10 malam, dan berakhir jadi pull request dua minggu kemudian.

Aneh? Banget.

Tapi ini realita produk teknologi sekarang — apalagi di dunia AI, apalagi kalau kamu kerja di tengah-tengah semua itu.

Bagian dari seri “Syntax Error (in Communication)” penjelasan ringan untuk orang-orang yang nyasar (atau diseret) masuk ke dunia teknologi.

STEP 1: Requirement gathering and analysis

Apa yang Klien mau (atau nggak) dan butuhkan (atau nggak)

Semua dimulai dari:
“Kami pengen dashboard yang AI banget, pakai Machine Learning juga boleh. Bisa bikin Predictive Model juga. Pakai Blockchain, Web3, metaverse-compatible, zero-trust, quantum-edge dashboard buat reputasi digital.” – tapi yang mudah, simple, murah. Dan bisa selesai dalam 2 minggu.

Kedengeran keren. Tapi maksudnya apa?
Apakah dia minta LLM? Model klasifikasi? Analisis sentimen? Crawler? Alert system? Visualisasi? → Nggak ada yang dijelasin.

Client Brief Reality:

  • Voice note sepanjang 3 menit.
  • PDF presentasi lawas.
  • Forward-an whatsapp “brief” dari tim marketing.

Ya terus gimana? AI to the Rescue. Buka OpenAI, Claude dan sebangsanya. Buat konteks dahulu.

  • Siapa user-nya?
  • Apa tugas mereka?
  • Apa yang mereka harap lihat?
  • Workflow idealnya kayak apa?
  • Output akhirnya gimana bentuknya?

Tips: bikin versi awal draft BRD pakai AI (tapi inget, kadang dokumen nggak pernah benar-benar dibaca → kasih visualisasi kasar pakai v0.dev atau Lovable → konfirmasi pemahaman.

Biasanya kalau mereka bilang,

“Iya, iya, kayak gitu tuh,”
itu artinya kita udah deket.

STEP 2: Design

Translate dari Bahasa Klien → Bahasa Teknologi

Setelah pemahaman awal dapet, mulai susun dokumen:
Bisa berupa BRD (Business Requirement Document), Prioritas fitur, Asumsi teknis awal (data dari mana, flow-nya gimana), atau kadang tanpa dokumen brief sama sekali

Jangan lupa juga untuk menjembatani request:

  • Klien maunya “semua bisa otomatis”,
  • Tapi API-nya nggak ada.
  • Data-nya belum dikumpulin.
  • Aksesnya terbatas.

Jadi kita harus:

  • Cari alternatif logika
  • Simulasikan lewat AI: misalnya generate JSON data palsu, atau buat mock-up dashboard
  • Kadang bikin front-end awal pakai tool no-code atau AI builder, buat bantu tim dev ngerti maksud client

Intinya: Dev team jangan disuruh nebak. Tapi juga nggak semua dari klien bisa langsung diambil mentah-mentah. Harus diproses dulu — kayak kopi. Jangsan sampai Dev bingung, tapi klien juga tidak perlu dijejali istilah teknis.

Selesai? Belum.
Kita juga perlu bantuan AI untuk bantu bikin estimasi biaya produksi yang diperlukan, API yang mungkin dibutuhkan, dan akhirnya buat semua itu jadi sebuah proposal, deck dan pricing yang bisa di nego-nego.

STEP 3: Implementasi

Development Fase (a.k.a. Controlled Chaos)

Development dimulai. Tapi bukan berarti pekerjaan saya selesai.

Saya harus:

  • Cek staging setiap hari.
  • Validasi apakah fitur sesuai.
  • Buat QA checklist dan edge case yang nggak sempat dibahas di awal.

Dev kadang bingung:
“Ini datanya kok nggak muncul?”
“Alert-nya trigger kalau gimana, ya?”
“Kenapa request-nya berubah dari minggu lalu?”

Sementara klien bisa bilang:
“Bisa nggak diganti warna tombolnya jadi biru?”
“Kok grafiknya ‘nggak kelihatan AI banget’, ya?”
“Ini bisa baca sentimen dari komentar Facebook nggak?”

Di sinilah saya harus jadi interpreter real-time:

  • Translate permintaan absurd jadi tugas logis.
  • Filter mana yang doable sekarang, mana yang bisa jadi backlog.
  • Ngasih ke tim dengan brief yang bisa dipahami tanpa marah-marah.

Dan kadang, harus ngingetin klien:

“Kalau mau fitur A, kita perlu akses ke B, dan itu perlu izin tambahan dari C (dan tambahan cost XXX). Masih mau jalan?”

STEP 4: Launch ≠ Selesai

Produk udah jadi. Tapi itu baru 50% dari pekerjaan.
Selanjutnya kita perlu memperkenalkan makhluk ajaib ini ke klien dan teman-temanya sebagai user. Caranya?

  • Buat presentasi demo
  • Bikin video tutorial, manual, dan SOP
  • Jalani onboarding call ke semua stakeholder
  • Siap jadi “customer support” dadakan

Masalahnya, user biasanya:

  • Nggak baca manual
  • Lupa login
  • Bingung lihat UI yang sebenarnya simpel

Dan feedback-nya bisa absurd:

“Kok nggak bisa langsung masuk ke bagian alert ya?”
“Ini AI-nya bisa ngerti tone suara juga?”
“Udah live? Saya nggak lihat perbedaannya.”

Solusinya?

Kirim screenshot produk mereka sendiri
Ajarin pakai “mode kasir Indomaret” → satu tombol, langsung keluar hasil
Siap-siap jawaban cepat:


“Pak, coba clear cache dan Ctrl + Shift + R ya.”


Client: “Ooh ya udah muncul. Bisa ganti warna header gak?”

STEP 5: Iterasi & Perbaikan — Karena Produk Nggak Pernah Final

Habis deploy, ada feedback baru:

  • Ada fitur yang ternyata nggak dipakai
  • Ada bug yang baru muncul kalau datanya banyak
  • Ada user baru dengan permintaan aneh

Kita masukin ke backlog, sprint, dan kadang harus nyusun ulang alur kerja produk.
Kadang revisi kecil. Kadang rombak besar.


Dunia teknologi kelihatannya canggih — tapi kenyataannya sering berantakan, ambigu, dan absurd.
Tapi justru di situlah serunya: kita bukan cuma bikin produk, tapi juga bikin jembatan pemahaman.
Antara yang membayangkan dashboard AI futuristik… dan yang harus ngebangun dari nol dengan resource terbatas.
Antara klien yang pengen semuanya simpel… dan developer yang butuh input detail buat bisa mulai kerja.

Saya bukan engineer.
Tapi saya ngerti betapa pentingnya role di tengah:
Ngerti bahasa klien, bisa translate ke logika dev, dan tetap tenang waktu revisi dateng jam 11 malam.

Karena pada akhirnya, produk teknologi bukan soal seberapa “AI banget” dia kelihatannya.
Tapi apakah dia nyampe ke orang yang butuh, dan bisa dipakai dengan masuk akal.

Next post, kita ngobrol soal:
Bagaimana AI bantu saya tetap relevan (dan bahkan unggul) di dunia yang makin teknikal — meski saya nggak nulis satu baris kode pun.