Program Studi Bisnis Digital • FEB UNDIP

Laboratorium Financial Technology

Pertemuan 13 — Pengembangan Proyek Fintech Dasar: Penyusunan dan Perancangan

Dari ide dan masalah nyata menuju rancangan proyek fintech tim yang layak dikerjakan — model bisnis, produk, arsitektur, dan dokumen perencanaan.

RPS MINGGU 14 • 2 × 50 MENIT

Selamat datang di pertemuan ketiga belas mata kuliah Laboratorium Financial Technology. Sepanjang semester ini Anda sudah menempuh perjalanan panjang: dari sejarah disrupsi layanan keuangan, teknologi pendukung seperti cloud dan AI, blockchain, pembayaran digital, lending, wealthtech, insurtech, sampai regulasi, keamanan siber, dan tren masa depan seperti open banking dan Web3. Hari ini kita masuk fase yang paling ditunggu, yaitu mengubah seluruh pengetahuan itu menjadi rancangan proyek fintech nyata yang akan dikerjakan tim Anda dan dipresentasikan pada pertemuan berikutnya. Bayangkan Anda adalah founder muda yang ingin membuat aplikasi seperti GoPay untuk kantin kampus, atau platform urun dana seperti Amartha untuk pedagang pasar — hari ini kita akan belajar cara berpikir sistematis dari ide mentah sampai dokumen perancangan yang siap dieksekusi. Siapkan laptop dan catatan kelompok Anda, karena banyak keputusan tim harus mulai diambil hari ini.

Bagian 1 dari 3

Dari Ide ke Model Bisnis Fintech

Menentukan masalah, vertikal, dan cara proyek Anda menghasilkan nilai — sebelum satu baris kode pun ditulis.

Peta Perjalanan Menuju Proyek Anda

Setiap materi yang sudah Anda pelajari adalah bahan baku untuk proyek hari ini. Tujuan pertemuan ini: tim Anda pulang dengan rancangan proyek fintech yang siap dieksekusi dan dipresentasikan.

Yang Sudah Dipelajari

1 Ekosistem, teknologi & regulasi fintech
2 Cybersecurity & manajemen risiko
3 Analisis data & pemodelan kuantitatif
4 Studi kasus global & lokal, tren masa depan

Hasil Akhir Pertemuan Ini

Masalah & vertikal fintech yang dipilih tim
Model bisnis & angka kelayakan dasar
Rancangan produk (MVP) & arsitektur teknologi
Dokumen Project Charter siap dikerjakan

Menemukan Masalah yang Layak Diselesaikan

Proyek fintech yang baik dimulai dari masalah nyata, bukan dari fitur yang terlihat keren. Contoh alur berpikir tim: UMKM pedagang pasar sulit mengakses modal usaha.

Tahap 1 — Amati & Validasi

Siapa yang mengalami masalah? — pedagang pasar tradisional tanpa rekam kredit bank
Seberapa sering & seberapa mahal masalah ini? — ditolak bank, terjebak rentenir harian
Apakah ada bukti orang lain sudah mencoba membayar solusi serupa? — Amartha, Investree

Tahap 2 — Rumuskan Solusi Awal

Solusi spesifik: skoring kredit alternatif berbasis data transaksi harian
Vertikal fintech yang relevan: Fintech Lending (P2P/microlending)
Uji akal sehat: mampu dibangun tim dalam kerangka waktu proyek?

Mari kita latih cara berpikir ini dengan sebuah contoh yang dekat dengan keseharian Anda di Semarang, yaitu pedagang pasar tradisional yang kesulitan mendapat modal karena tidak punya agunan atau rekam jejak kredit di bank. Pada tahap pertama, tim harus mengamati dan memvalidasi apakah masalah ini nyata, seberapa menyakitkan, dan apakah orang sudah pernah mencoba membayar untuk solusinya, misalnya lewat rentenir harian yang bunganya sangat tinggi. Pada tahap kedua, barulah tim merumuskan solusi awal, dalam contoh ini skoring kredit alternatif dari data transaksi harian, yang jelas masuk ke vertikal Fintech Lending seperti Amartha atau Investree. Perhatikan urutannya, masalah dulu baru solusi, bukan sebaliknya. Ini adalah kesalahan paling umum yang membuat proyek fintech mahasiswa terasa dipaksakan.

Pilih Vertikal Fintech Proyek Anda

Setiap tim memilih satu vertikal sebagai fokus utama proyek — boleh menggabungkan elemen vertikal lain sebagai fitur pendukung.

Payment

Dompet digital, QRIS, transfer — contoh: GoPay, DANA

Lending

P2P lending, microlending, BNPL — contoh: Amartha, Kredivo

WealthTech

Robo-advisor, reksa dana digital — contoh: Bibit, Pluang

InsurTech

Asuransi mikro, klaim digital — contoh: Qoala, PasarPolis

RegTech

Kepatuhan & KYC otomatis — contoh: Privy, VIDA

Business Model Canvas untuk Proyek Fintech

Sembilan blok BMC dipetakan ke bahasa fintech — isi setiap blok sebelum merancang produk.

Blok BMC	Pertanyaan Kunci Fintech	Contoh Isi
Value Proposition	Masalah apa yang diselesaikan?	Skoring kredit alternatif untuk UMKM
Customer Segment	Siapa penggunanya?	Pedagang pasar tanpa rekam kredit bank
Channels	Bagaimana menjangkau pengguna?	Kemitraan koperasi pasar, WhatsApp
Revenue Streams	Dari mana uang masuk?	Origination fee & biaya layanan bulanan
Key Resources	Aset penting apa yang dibutuhkan?	Data transaksi, izin/kemitraan, tim tekno
Key Partners	Siapa mitra strategis?	Bank penyalur dana, penyedia payment gateway

Business Model Canvas atau BMC adalah alat pemetaan model bisnis yang sudah Anda kenal dari mata kuliah kewirausahaan, dan hari ini kita adaptasi khusus untuk konteks fintech. Value proposition menjawab masalah apa yang diselesaikan, misalnya skoring kredit alternatif tadi. Customer segment menentukan siapa pengguna utamanya, dalam contoh ini pedagang pasar tanpa rekam kredit bank. Channels menjelaskan cara menjangkau mereka, misalnya lewat kemitraan koperasi pasar. Revenue streams, yang akan kita hitung detail di slide berikutnya, menjelaskan dari mana uang masuk. Key resources dan key partners menjelaskan apa dan siapa yang dibutuhkan agar proyek berjalan, misalnya kemitraan dengan bank penyalur dana. Tim Anda wajib mengisi keenam blok ini sebagai bagian dari dokumen perancangan sebelum masuk ke tahap desain produk.

Coba Sendiri: Susun Business Model Canvas Tim Anda

Isi tiap blok BMC secara interaktif untuk ide proyek fintech tim Anda, lalu lihat bagaimana blok-blok itu saling terhubung.

Hitung dari Nol: Model Pendapatan P2P Lending

Platform menyalurkan pinjaman Rp 50.000.000 ke UMKM, tenor 12 bulan, saldo pinjaman menurun linear.

Langkah	Perhitungan	Nilai
1. Pokok pinjaman disalurkan	—	Rp 50.000.000
2. Origination fee (di awal)	3% × Rp 50.000.000	Rp 1.500.000
3. Rata-rata saldo berjalan	(Rp 50.000.000 + Rp 0) ÷ 2	Rp 25.000.000
4. Biaya layanan per bulan	1% × Rp 25.000.000	Rp 250.000
5. Total biaya layanan 12 bulan	Rp 250.000 × 12	Rp 3.000.000
6. Total pendapatan platform	Rp 1.500.000 + Rp 3.000.000	Rp 4.500.000

Take Rate Efektif

Rp 4.500.000 ÷ Rp 50.000.000

Sekarang kita masuk ke perhitungan konkret yang wajib bisa dikerjakan setiap anggota tim, bukan hanya dihafal. Platform menyalurkan pinjaman lima puluh juta rupiah dengan tenor dua belas bulan dan saldo menurun linear seperti kredit UMKM pada umumnya. Langkah pertama, pokok pinjaman lima puluh juta disalurkan penuh di awal. Langkah kedua, origination fee tiga persen dipotong di muka sebesar satu juta lima ratus ribu rupiah, mirip biaya admin yang dipotong Amartha atau Investree saat pencairan. Langkah ketiga sampai lima, kita hitung biaya layanan bulanan satu persen dari rata-rata saldo berjalan, yang totalnya tiga juta rupiah selama dua belas bulan. Langkah keenam, kita jumlahkan menjadi total pendapatan platform empat juta lima ratus ribu rupiah, atau take rate efektif sembilan persen dari pokok pinjaman. Angka sembilan persen inilah yang nanti dibandingkan dengan biaya operasional platform untuk menilai kelayakan model bisnis.

Hitung dari Nol: Ekonomi Unit (CAC vs LTV)

Tim menghabiskan Rp 15.000.000 biaya pemasaran bulanan untuk mengakuisisi 500 pengguna baru.

Langkah	Perhitungan	Nilai
1. Biaya akuisisi (CAC)	Rp 15.000.000 ÷ 500 pengguna	Rp 30.000
2. Margin kontribusi/pengguna/bulan	Rp 25.000 ARPU × 60%	Rp 15.000
3. Estimasi umur pengguna aktif	1 ÷ churn 5% per bulan	20 bulan
4. Nilai seumur hidup (LTV)	Rp 15.000 × 20 bulan	Rp 300.000
5. Rasio LTV terhadap CAC	Rp 300.000 ÷ Rp 30.000	10×

Patokan investor: rasio LTV:CAC sehat umumnya ≥ 3× — hasil 10× di atas layak dipertahankan sebagai asumsi proyek, dengan catatan wajib divalidasi ulang saat presentasi akhir.

Setelah tahu berapa pendapatan per pinjaman, sekarang kita cek apakah biaya menarik pengguna baru masuk akal, memakai dua metrik favorit investor fintech yaitu CAC atau customer acquisition cost dan LTV atau lifetime value. Langkah pertama, CAC dihitung dari total biaya pemasaran dibagi jumlah pengguna baru, hasilnya tiga puluh ribu rupiah per pengguna. Langkah kedua, kita hitung margin kontribusi per pengguna per bulan dari pendapatan rata-rata dikali persentase margin. Langkah ketiga, kita estimasi berapa lama pengguna bertahan memakai aplikasi, dari asumsi churn lima persen per bulan, hasilnya dua puluh bulan. Langkah keempat dan kelima, kita kalikan menjadi LTV tiga ratus ribu rupiah, dan rasio LTV terhadap CAC sepuluh kali. Investor fintech biasanya menganggap rasio tiga kali sudah sehat, jadi hasil tim ini terlihat sangat baik, tetapi ingatkan mahasiswa bahwa asumsi churn dan margin ini harus divalidasi ulang dengan data yang lebih realistis saat presentasi akhir.

Coba Sendiri: Kalkulator CAC vs LTV Startup

Ubah biaya pemasaran, ARPU, margin, dan churn — amati bagaimana rasio LTV terhadap CAC berubah dan apakah masih di atas patokan sehat 3x.

Cek Kelayakan Regulasi Sejak Awal

Rancangan produk yang bagus bisa gagal total kalau melanggar aturan OJK/BI — cek dua tahap ini sebelum lanjut ke desain produk.

Tahap 1 — Klasifikasi & Izin

Apakah aktivitas ini termasuk kategori berizin (payment, lending) atau masih boleh terdaftar sandbox OJK/BI?
Apakah proyek menyentuh dana pihak ketiga secara langsung? — risiko tinggi
Simpulan: untuk proyek kelas, posisikan sebagai prototipe/simulasi, bukan operasional nyata

Tahap 2 — Kewajiban Turunan

Perlindungan data pribadi sesuai UU PDP — data KYC wajib dienkripsi
Prosedur KYC/AML minimal (verifikasi identitas dasar)
Transparansi biaya & bunga ke pengguna (anti jebakan biaya tersembunyi)

Sebelum tim Anda jatuh cinta pada desain aplikasi, kita perlu berhenti sejenak dan mengecek kelayakan regulasinya, karena ini adalah tahap yang paling sering dilewatkan mahasiswa. Tahap pertama, tim harus mengklasifikasikan apakah aktivitas proyek termasuk kategori yang wajib berizin resmi dari OJK atau Bank Indonesia, seperti penyaluran dana pihak ketiga, atau masih bisa diposisikan sebagai prototipe yang aman untuk tujuan akademik, mirip status regulatory sandbox yang pernah kita bahas. Untuk proyek kelas, kesimpulannya selalu sama, posisikan sebagai simulasi atau prototipe, bukan layanan yang benar-benar mengelola uang nasabah. Tahap kedua, meskipun hanya prototipe, tim tetap wajib merancang kewajiban turunan seperti perlindungan data pribadi sesuai UU PDP, prosedur KYC dasar, dan transparansi biaya. Kebiasaan merancang sesuai regulasi sejak awal ini yang membedakan proyek fintech mahasiswa yang matang dari yang sekadar mainan aplikasi.

Bagian 2 dari 3

Perancangan Produk & Arsitektur

Menerjemahkan model bisnis menjadi rancangan produk minimum yang bisa dibangun dan diuji.

Menyaring Fitur: MVP vs Nice-to-Have

Studi kasus: tim merancang e-wallet kampus untuk transaksi kantin dan UKT. Ikuti dua tahap penyaringan fitur berikut.

Tahap 1 — Daftar Semua Ide Fitur

Top up saldo, bayar kantin via QR
Cek riwayat & saldo transaksi
Split bill antar-mahasiswa
Program loyalitas & badge gamifikasi

Tahap 2 — Saring: Inti atau Tunda?

MVP: top up, bayar QR, cek saldo — menjawab masalah inti
MVP: notifikasi transaksi dasar — kepercayaan pengguna
Nice-to-have: split bill, gamifikasi — ditunda ke iterasi berikutnya

Mari kita praktikkan penyaringan fitur dengan studi kasus e-wallet kampus untuk transaksi kantin dan pembayaran UKT, mirip semangat GoPay tetapi skala kampus. Tahap pertama, tim mendaftar semua ide fitur tanpa disaring dulu, mulai dari top up saldo, bayar kantin lewat QR, cek riwayat transaksi, sampai fitur split bill dan gamifikasi berupa badge. Tahap kedua, barulah kita saring mana yang benar-benar inti atau MVP dan mana yang nice-to-have alias bisa ditunda. Fitur top up, bayar QR, cek saldo, dan notifikasi transaksi masuk MVP karena langsung menjawab masalah inti dan membangun kepercayaan pengguna. Fitur split bill dan gamifikasi memang menarik, tetapi tidak esensial di rilis pertama, jadi ditunda. Prinsip ini berlaku untuk vertikal fintech mana pun yang dipilih tim Anda, bukan hanya payment.

Arsitektur Teknologi Dasar Aplikasi Fintech

Empat lapis yang wajib ada di rancangan proyek, sekalipun hanya level konsep/prototipe.

Tim tidak wajib membangun sistem penuh — cukup gambarkan lapisan ini pada dokumen rancangan agar arsitektur logis dan bisa dijelaskan ke penilai.

Diagram ini menunjukkan empat lapis arsitektur teknologi dasar yang idealnya ada dalam rancangan proyek fintech, meskipun tim Anda tidak diwajibkan membangun sistem sungguhan. Lapis pertama adalah aplikasi yang dilihat pengguna, bisa mobile atau web. Lapis kedua adalah API gateway yang mengatur otentikasi dan lalu lintas permintaan, semacam pos penjagaan sebelum masuk ke sistem inti. Lapis ketiga adalah layanan inti seperti mesin pembayaran atau mesin penilaian kredit, tergantung vertikal yang dipilih tim. Lapis keempat adalah integrasi ke pihak luar seperti bank atau payment gateway resmi, mirip cara GoPay terhubung ke jaringan perbankan. Di bagian bawah ada lapis keamanan dan data yang memotong semua lapis di atasnya, mencakup enkripsi, proses KYC, dan log audit. Tim Anda cukup menggambarkan diagram serupa ini di dokumen rancangan untuk menunjukkan bahwa arsitektur produk sudah dipikirkan secara logis.

Alur Pengguna (User Journey) Sederhana

Petakan langkah pengguna dari awal sampai transaksi selesai — ini menjadi dasar rancangan wireframe tim.

Setiap titik pada alur ini adalah calon layar/wireframe — titik dengan risiko drop-off tertinggi biasanya Verifikasi KYC, rancang sesederhana mungkin.

Setelah arsitektur teknologi, langkah berikutnya adalah memetakan alur pengguna dari ujung ke ujung, yang nanti menjadi dasar membuat wireframe atau sketsa layar aplikasi. Alurnya dimulai dari registrasi, lalu verifikasi KYC seperti unggah foto KTP dan swafoto, kemudian aktivasi akun, dilanjutkan transaksi utama sesuai vertikal yang dipilih tim, dan diakhiri notifikasi serta laporan ke pengguna. Perhatikan bahwa titik verifikasi KYC biasanya menjadi titik dengan risiko pengguna berhenti di tengah jalan atau drop-off paling tinggi, karena prosesnya sering dianggap merepotkan, seperti yang mungkin pernah Anda alami saat mendaftar DANA atau OVO. Karena itu tim harus merancang langkah verifikasi ini sesederhana mungkin tanpa mengorbankan kepatuhan terhadap aturan KYC yang sudah kita bahas di slide sebelumnya.

Keamanan & Manajemen Risiko Sejak Desain

Terapkan kembali materi cybersecurity minggu-minggu sebelumnya ke rancangan proyek Anda — bukan tempelan di akhir.

Data

Enkripsi data sensitif (nomor rekening, NIK) saat disimpan & dikirim

Identitas

Otentikasi berlapis (PIN/OTP) untuk transaksi bernilai besar

Operasional

Batas transaksi harian & deteksi anomali sederhana

Checklist minimum dokumen rancangan: data apa yang disimpan, siapa yang bisa mengakses, apa yang terjadi jika data bocor — tiga pertanyaan ini wajib terjawab di Project Charter.

Kita sudah membahas cybersecurity secara mendalam beberapa minggu lalu, dan sekarang saatnya menerapkannya langsung ke proyek Anda, bukan sekadar teori terpisah. Pada sisi data, tim wajib memikirkan enkripsi untuk data sensitif seperti nomor rekening atau NIK, baik saat disimpan maupun saat dikirim antar-sistem. Pada sisi identitas, tim perlu merancang otentikasi berlapis seperti PIN atau OTP, terutama untuk transaksi bernilai besar, mirip yang Anda alami saat transfer di aplikasi mobile banking BCA atau Bank Jago. Pada sisi operasional, tim bisa merancang batas transaksi harian sederhana dan mekanisme deteksi anomali dasar. Tiga pertanyaan di kotak catatan itu wajib bisa dijawab tim Anda di dokumen Project Charter, karena penilai akan mengecek apakah keamanan benar-benar dipikirkan sejak awal, bukan ditambahkan belakangan setelah desain selesai.

Bagian 3 dari 3

Dokumen Perancangan & Rencana Tim

Menuangkan seluruh keputusan tim ke dalam satu dokumen kerja yang jelas dan bisa dieksekusi.

Struktur Dokumen Project Charter

Satu dokumen ringkas berisi seluruh keputusan tim hari ini — menjadi acuan kerja sampai presentasi akhir.

Komponen	Isi
Latar Belakang & Masalah	Masalah nyata, bukti, dan siapa yang terdampak
Vertikal & Solusi	Vertikal fintech dipilih + gambaran solusi
Model Bisnis	Ringkasan BMC + revenue model + unit economics
Ruang Lingkup MVP	Daftar fitur inti vs ditunda
Arsitektur & Keamanan	Diagram lapis teknologi + checklist keamanan
Kelayakan Regulasi	Status izin/sandbox + kewajiban kepatuhan

Pembagian Peran Tim & Rencana Kerja

Empat peran minimum dalam tim proyek — boleh dirangkap bila anggota tim terbatas.

Peran Minimum Tim

Product Lead — menjaga fokus masalah & MVP
Business/Finance Lead — model bisnis & angka kelayakan
Design/Tech Lead — wireframe & arsitektur
Compliance Lead — regulasi & keamanan

Rencana Kerja Menuju Presentasi

Minggu ini — Project Charter final dikumpulkan
Minggu berikut — wireframe/prototipe visual selesai
Menjelang presentasi — latihan pitch & simulasi tanya-jawab

Rancangan sebagus apa pun tidak akan jalan tanpa pembagian peran yang jelas, jadi mari kita sepakati empat peran minimum dalam tim, dan boleh dirangkap kalau jumlah anggota terbatas. Product lead menjaga agar tim tetap fokus pada masalah dan MVP, tidak melebar ke fitur yang tidak perlu. Business atau finance lead bertanggung jawab pada model bisnis dan angka kelayakan seperti yang kita hitung tadi. Design atau tech lead menangani wireframe dan arsitektur. Compliance lead memastikan regulasi dan keamanan tidak terlewat. Untuk rencana kerja, minggu ini tim wajib menyelesaikan dan mengumpulkan Project Charter, minggu berikutnya menyelesaikan wireframe atau prototipe visual, dan menjelang hari presentasi tim berlatih pitch serta simulasi tanya jawab, karena presentasi akhir akan dinilai layaknya sesi pitching ke investor sungguhan.

Kriteria Penilaian & Struktur Presentasi Akhir

Presentasi akhir pertemuan berikutnya dinilai dari empat dimensi — siapkan struktur pitch sejak sekarang.

Kejelasan Masalah

Masalah nyata & tervalidasi, bukan asumsi semata

Kelayakan Bisnis

Angka revenue model & unit economics masuk akal

Kematangan Rancangan

MVP, arsitektur, keamanan tergambar jelas

Kepatuhan & Risiko

Isu regulasi & keamanan sudah diantisipasi

Agar tim tidak menebak-nebak, berikut empat dimensi yang akan dinilai pada presentasi akhir pertemuan berikutnya, jadi mulailah menyiapkan struktur pitch sejak sekarang. Dimensi pertama, kejelasan masalah, apakah tim benar-benar membuktikan masalah ini nyata, bukan sekadar asumsi. Dimensi kedua, kelayakan bisnis, apakah angka revenue model dan unit economics yang disajikan masuk akal dan bisa dipertanggungjawabkan. Dimensi ketiga, kematangan rancangan, apakah MVP, arsitektur, dan alur pengguna tergambar jelas, bukan hanya deskripsi umum. Dimensi keempat, kepatuhan dan risiko, apakah tim sudah mengantisipasi isu regulasi dan keamanan. Struktur pitch yang disarankan mengikuti urutan yang sama seperti pitch deck startup sungguhan, mulai dari masalah, solusi, model bisnis, sampai rencana ke depan.

Kesalahan Umum yang Harus Dihindari

Belajar dari kesalahan tim-tim sebelumnya agar proyek Anda lebih tajam sejak awal.

Sering Terjadi

Fitur terlalu banyak, tidak ada fokus MVP
Model pendapatan tidak dihitung, hanya diasumsikan "pasti untung"
Regulasi diabaikan sampai akhir

Cara Menghindarinya

Kunci 3–4 fitur MVP di dokumen sejak hari ini
Wajib ada tabel perhitungan revenue & unit economics
Isi checklist regulasi & keamanan sebelum desain final

Latihan Tim: Susun Project Charter Anda

Kerjakan bersama kelompok selama sisa waktu kelas — lanjutkan di luar kelas, kumpulkan sebelum pertemuan berikutnya.

Instruksi Tugas

Tentukan masalah, vertikal, dan segmen pengguna tim Anda (Bagian 1)
Isi Business Model Canvas ringkas + hitung revenue model & unit economics dengan angka nyata (bukan asumsi kosong)
Susun daftar fitur MVP (maksimal 4) + sketsa alur pengguna & arsitektur sederhana
Isi checklist regulasi & keamanan minimum
Tuliskan seluruhnya dalam format Project Charter, sertakan pembagian peran & jadwal kerja

Batas kumpul: sebelum pertemuan berikutnya (presentasi akhir proyek). Dokumen ini menjadi dasar penilaian proses & acuan kerja tim sampai hari presentasi.

Sekarang giliran tim Anda bekerja. Gunakan sisa waktu kelas untuk mulai menyusun Project Charter bersama kelompok, lalu lanjutkan di luar kelas sampai batas waktu pengumpulan sebelum pertemuan berikutnya, yaitu presentasi akhir proyek. Ikuti urutan instruksi di layar, mulai dari menentukan masalah dan vertikal, mengisi Business Model Canvas dan menghitung angka kelayakan seperti latihan tadi, menyusun daftar fitur MVP dan sketsa arsitektur, sampai melengkapi checklist regulasi dan keamanan. Ingat, dokumen ini bukan sekadar tugas administratif, melainkan alat kerja nyata yang akan memandu tim Anda sampai hari presentasi, persis seperti dokumen perencanaan yang dipakai tim founder fintech sungguhan sebelum bertemu investor. Saya akan berkeliling membantu setiap kelompok selama sisa waktu kelas ini, jangan ragu bertanya bila ada bagian yang membingungkan.