Program Studi Bisnis Digital • FEB UNDIP
Lab Pemrograman
Pertemuan 1 — Identifikasi Masalah Bisnis Digital dan Perumusan Ide Proyek Aplikasi Titik berangkat proyek aplikasi satu semester: belajar menemukan masalah bisnis digital yang nyata, lalu merumuskannya menjadi ide proyek yang layak dikembangkan.
RPS MINGGU 1 • 2 × 50 MENIT
Selamat datang di mata kuliah Lab Pemrograman. Anda mungkin membayangkan mata kuliah ini akan langsung mengetik kode di depan komputer, tapi hari ini kita justru belum menyentuh satu baris kode pun. Bayangkan Anda ingin membangun aplikasi seperti Gojek atau Tokopedia versi kecil untuk kampus Anda — sebelum menulis kode, pendiri aslinya menghabiskan waktu lama hanya untuk memastikan masalah yang mereka pecahkan benar-benar nyata dan dirasakan banyak orang. Sepanjang pertemuan ini kita akan berlatih menemukan masalah bisnis digital yang layak dipecahkan, lalu merumuskannya menjadi ide proyek aplikasi yang akan Anda kembangkan sepanjang satu semester ke depan. Silakan siapkan catatan Anda, karena kerangka berpikir hari ini menjadi fondasi seluruh proyek akhir mata kuliah ini. Tujuan Pembelajaran Hari Ini Setelah pertemuan ini, Anda diharapkan mampu menemukan dan merumuskan masalah bisnis digital sebagai titik berangkat proyek aplikasi. Secara rinci:
CAPAIAN 1 — KONSEP
APA ITU MASALAH BISNIS DIGITAL
Menjelaskan pengertian masalah bisnis digital dan mengapa ia menjadi titik awal setiap proyek aplikasi.
CAPAIAN 2 — TEKNIK
MENGGALI MASALAH NYATA
Menerapkan teknik observasi & wawancara sederhana untuk menemukan masalah yang benar-benar dirasakan pengguna.
CAPAIAN 3 — SELEKSI
MENILAI KELAYAKAN IDE
Menyaring beberapa kandidat masalah menjadi satu ide proyek terkuat memakai skor kelayakan sederhana.
CAPAIAN 4 — RUMUSAN
MENYUSUN PROBLEM STATEMENT
Menuliskan rumusan masalah & ide proyek aplikasi secara ringkas, siap dikembangkan pada pertemuan berikutnya.
Ada empat capaian yang ingin kita tuntaskan hari ini. Pertama, kita bangun pemahaman tentang apa yang dimaksud masalah bisnis digital, karena istilah ini akan terus kita pakai sepanjang semester. Kedua, kita berlatih teknik sederhana menggali masalah dari calon pengguna, bukan sekadar menebak-nebak dari asumsi pribadi Anda. Ketiga, karena biasanya muncul banyak kandidat ide sekaligus, kita akan belajar menyaringnya dengan skor kelayakan yang objektif, mirip cara tim produk di Tokopedia memilih fitur mana yang dikerjakan lebih dulu. Keempat, kita tutup dengan menuliskan rumusan masalah yang rapi, karena inilah dokumen pertama proyek aplikasi Anda yang akan terus disempurnakan sampai pertemuan terakhir. Mengapa Tidak Langsung Membuat Aplikasi Saja? Banyak proyek aplikasi mahasiswa gagal bukan karena kodenya jelek, tapi karena aplikasinya memecahkan masalah yang tidak ada . Bandingkan dua pendekatan berikut.
LANGSUNG BUAT APLIKASI
BERISIKO GAGAL DIPAKAI
"Saya mau buat aplikasi seperti Instagram tapi untuk kucing" — fitur bagus, tapi tidak jelas masalah nyata apa yang diselesaikan bagi siapa.
MULAI DARI MASALAH
TERARAH & TERUKUR
"Mahasiswa kos sulit menemukan warung makan halal murah di dekat kampus" — masalah jelas, pengguna jelas, arah solusi jelas.
Inilah alasan Pertemuan 1 fokus pada masalah, bukan fitur : aplikasi hebat lahir dari masalah nyata, bukan sebaliknya.
Contoh dua pendekatan ini sengaja saya buat kontras supaya perbedaannya terasa tajam. Pendekatan pertama sering dilakukan pemula: terinspirasi aplikasi populer lalu langsung meniru fiturnya tanpa bertanya siapa yang benar-benar membutuhkannya. Pendekatan kedua justru dimulai dari observasi keluhan nyata, misalnya keluhan mahasiswa kos di sekitar kampus Undip Tembalang yang kesulitan mencari warung makan halal dengan harga terjangkau saat jam kuliah padat. Startup besar seperti Gojek pun lahir dari pengamatan masalah kemacetan dan sulitnya mencari ojek di Jakarta, bukan dari keinginan membuat aplikasi terlebih dahulu. Sepanjang semester ini, proyek aplikasi Anda akan dinilai bukan hanya dari kerumitan kodenya, tetapi dari seberapa jelas masalah yang dipecahkannya. Bagian 1 dari 3
Mengenal Masalah Bisnis Digital
Apa itu masalah bisnis digital, dari mana sumbernya, dan bagaimana cara menggalinya secara sistematis?
Definisi
Sumber Masalah
Teknik Menggali
Di bagian pertama ini kita membangun fondasi konsep. Kita akan mulai dari pertanyaan paling dasar: apa sebenarnya yang dimaksud masalah bisnis digital, lalu dari mana saja masalah semacam itu bisa ditemukan di sekitar kita. Setelah itu kita pelajari satu studi kasus nyata dan teknik sederhana untuk menggali masalah langsung dari calon pengguna, supaya Anda punya bekal praktis, bukan hanya teori di atas kertas. Apa itu Masalah Bisnis Digital? Kesenjangan antara kondisi yang diinginkan pengguna/bisnis dengan kondisi nyata saat ini, yang berpotensi diselesaikan atau diringankan lewat solusi berbasis teknologi digital (aplikasi, website, platform).
Nyata: benar-benar dialami orang, bukan hasil imajinasi atau asumsi Anda sendiri.Berulang: terjadi berkali-kali, bukan kejadian sekali seumur hidup.Bernilai jika diselesaikan: orang bersedia meluangkan waktu/uang untuk solusinya.INTI SASARAN
GAP, BUKAN GAGASAN FITUR
Masalah bisnis digital dirumuskan sebagai kesenjangan yang dirasakan seseorang — bukan sebagai daftar fitur aplikasi yang ingin dibangun.
Contoh: bukan "saya mau bikin aplikasi presensi", melainkan "dosen kesulitan merekap kehadiran manual dari 200 mahasiswa di banyak kelas".
Perhatikan definisi ini baik-baik karena akan menjadi acuan sepanjang semester. Kata kunci pertama adalah "kesenjangan" — ada jarak antara apa yang diinginkan orang dan apa yang sedang mereka alami sekarang. Kata kunci kedua, tiga syarat kelayakan: masalahnya harus nyata dialami, misalnya keluhan langsung dari teman kos Anda, bukan sekadar dugaan; harus berulang, seperti kesulitan mencari tempat parkir kampus yang terjadi setiap hari, bukan cuma sekali; dan harus bernilai, artinya orang mau membayar waktu atau uang untuk solusinya. Contoh yang saya tampilkan sengaja membandingkan cara berpikir "fitur dulu" dengan cara berpikir "masalah dulu" — dosen yang kesulitan merekap kehadiran manual dari ratusan mahasiswa adalah masalah nyata, dan dari situlah ide aplikasi presensi digital baru masuk akal untuk dibangun. Dari Mana Sumber Masalah Bisnis Digital? Masalah tidak muncul dari imajinasi kosong — ia digali dari tiga sumber utama di sekitar Anda.
IDE PROYEK Aplikasi Digital PENGAMATAN LANGSUNG Kebiasaan & keluhan sehari-hari WAWANCARA CALON PENGGUNA Tanya langsung, bukan menebak DATA & TREN PASAR DIGITAL Laporan industri, media, media sosial Diagram ini menunjukkan tiga jalur utama yang bermuara pada satu ide proyek aplikasi. Jalur pertama, pengamatan langsung terhadap kebiasaan dan keluhan di sekitar Anda, misalnya mengamati antrean panjang di kantin kampus setiap jam makan siang. Jalur kedua, wawancara langsung dengan calon pengguna — bertanya kepada teman kos, penjual UMKM di sekitar kampus, atau pedagang kaki lima tentang kesulitan sehari-hari mereka, bukan menebak dari sudut pandang Anda sendiri. Jalur ketiga, membaca data dan tren pasar digital, misalnya laporan asosiasi e-commerce Indonesia atau berita tentang bagaimana UMKM masih kesulitan berjualan daring. Ketiga jalur ini sebaiknya dipakai bersamaan, bukan hanya satu, supaya masalah yang Anda temukan benar-benar teruji dari beberapa sisi. Studi Kasus: Masalah di Balik Aplikasi Populer Aplikasi besar yang Anda kenal hari ini semuanya lahir dari satu masalah bisnis digital yang spesifik.
GOJEK
TUKANG OJEK SULIT DIHUBUNGI
Calon penumpang di Jakarta kesulitan mencari & memesan ojek pangkalan secara cepat & transparan soal tarif.
TOKOPEDIA
UMKM SULIT BERJUALAN LUAS
Pedagang kecil tidak punya toko daring terjangkau untuk menjangkau pembeli di luar kota asalnya.
BANK DIGITAL
SULIT BUKA REKENING
Warga di daerah tanpa cabang bank fisik kesulitan mengakses layanan perbankan dasar.
Pola yang sama: masalah spesifik + pengguna spesifik , baru kemudian aplikasi dirancang sebagai jawabannya — bukan sebaliknya.
Tiga contoh ini sengaja saya pilih karena hampir semua dari Anda pernah memakainya. Gojek lahir dari pengamatan bahwa mencari ojek pangkalan di Jakarta itu lambat dan tarifnya tidak transparan, sehingga solusinya adalah memesan lewat aplikasi dengan estimasi tarif jelas di muka. Tokopedia lahir dari masalah pedagang kecil yang tidak punya cara murah untuk berjualan ke luar kota, sehingga solusinya adalah marketplace yang bisa diakses siapa saja. Bank digital, seperti yang belakangan tumbuh pesat di Indonesia, menjawab masalah warga di daerah yang jauh dari cabang bank konvensional milik BCA maupun BRI. Perhatikan polanya: ketiganya dimulai dari masalah yang sangat spesifik milik kelompok pengguna tertentu, bukan dari ide "aplikasi keren" yang umum. Inilah pola yang ingin kita tiru dalam proyek Anda. Teknik Sederhana Menggali Masalah Anda tidak perlu riset pasar rumit — tiga teknik dasar berikut sudah cukup untuk memulai.
Amati: catat kebiasaan & keluhan berulang orang di sekitar Anda selama beberapa hari.Tanyakan "mengapa": gali akar masalah, jangan berhenti di keluhan permukaan.Wawancara 5 orang: tanyakan pengalaman nyata mereka, bukan pendapat soal ide Anda.JEBAKAN UMUM
MENANYAKAN IDE, BUKAN MASALAH
Bertanya "kalau ada aplikasi X, mau pakai tidak?" sering menghasilkan jawaban sopan yang menyesatkan — lebih baik tanyakan masalah nyata yang mereka alami minggu ini.
Tiga langkah ini bisa Anda praktikkan mulai minggu ini juga, tanpa alat khusus. Mengamati berarti Anda benar-benar meluangkan waktu memperhatikan, misalnya berapa lama antre di kasir minimarket dekat kos Anda pada jam sibuk. Menanyakan "mengapa" berulang kali membantu Anda menembus keluhan permukaan sampai ke akar masalah — misalnya keluhan "susah cari parkir" ternyata akar masalahnya adalah tidak ada informasi slot parkir kosong secara real time. Wawancara lima orang cukup untuk melihat pola awal, asalkan Anda benar-benar bertanya tentang pengalaman nyata mereka. Jebakan yang paling sering dilakukan pemula adalah langsung menawarkan ide aplikasi dan bertanya "mau pakai tidak", padahal orang cenderung menjawab sopan "iya mungkin" meski sebenarnya tidak akan memakainya — jawaban semacam ini menyesatkan dan sering membuat proyek aplikasi salah arah sejak awal. Bagian 2 dari 3
Dari Masalah ke Ide Proyek
Bagaimana merumuskan masalah menjadi pernyataan yang jelas, lalu menyaring kandidat ide dengan skor kelayakan.
Problem Statement
Skor Kelayakan
Hitung Sendiri
Bagian kedua ini akan lebih terasa aplikatif. Kita akan menelusuri langkah demi langkah bagaimana masalah yang tadi kita gali dirumuskan menjadi kalimat problem statement yang jelas. Setelah itu kita berlatih menghitung sendiri skor kelayakan sebuah ide, karena biasanya Anda akan punya lebih dari satu kandidat masalah dan perlu cara objektif untuk memilih satu yang paling layak dikembangkan menjadi proyek aplikasi. Merumuskan Problem Statement, Langkah demi Langkah Gunakan template ini untuk mengubah keluhan mentah menjadi pernyataan masalah yang tajam & siap digarap.
Langkah Pertanyaan Panduan Contoh Isian 1. Siapa penggunanya Kelompok spesifik mana yang mengalami masalah ini? Mahasiswa baru kos di sekitar kampus Undip Tembalang 2. Apa masalahnya Kesenjangan apa yang mereka rasakan? Sulit menemukan warung makan halal murah & masih buka larut malam 3. Kapan/di mana terjadi Dalam situasi seperti apa masalah ini muncul? Terutama malam hari saat belajar/tugas larut & warung sudah tutup 4. Mengapa penting diselesaikan Apa dampaknya jika masalah ini dibiarkan? Mahasiswa melewatkan makan atau membeli makanan mahal/kurang sehat
Rumusan akhir: "Mahasiswa kos di sekitar kampus kesulitan menemukan warung makan halal murah yang masih buka larut malam."
Mari kita ikuti template ini satu per satu karena inilah alat bantu utama Anda minggu ini. Langkah pertama, tentukan siapa penggunanya secara spesifik — bukan "mahasiswa" secara umum, melainkan kelompok yang lebih sempit seperti mahasiswa baru yang kos di sekitar kampus. Langkah kedua, rumuskan kesenjangan yang mereka rasakan secara jelas, dalam contoh ini kesulitan menemukan warung makan halal murah yang masih buka larut malam. Langkah ketiga, perjelas konteks kapan dan di mana masalah itu muncul, karena konteks ini nanti memengaruhi desain solusi Anda. Langkah keempat, jelaskan mengapa masalah ini penting untuk diselesaikan — kalau dampaknya kecil, mungkin bukan masalah yang layak digarap satu semester penuh. Setelah keempat langkah ini terisi, Anda tinggal menggabungkannya menjadi satu kalimat rumusan masalah yang padat seperti contoh di layar. Hitung dari Nol: Skor Kelayakan Ide Proyek Sebuah kelompok menilai ide "Aplikasi Antar Makanan Warung Malam Kampus" dengan tiga kriteria berbobot, skala 1–5.
Langkah Perhitungan Nilai Ukuran pasar (skor 4, bobot 40%) 4 × 40% 1,6 + Urgensi masalah (skor 5, bobot 35%) 1,6 + (5 × 35%) 3,35 + Kelayakan teknis (skor 3, bobot 25%) 3,35 + (3 × 25%) 4,1 Skor kelayakan akhir dari skala maksimum 5 4,1 / 5
HASIL AKHIR
4,1
skor kelayakan dari skala 5
Mari kita hitung bersama, langkah demi langkah, jangan sampai ada yang terlewat. Kita mulai dari kriteria ukuran pasar dengan skor 4 dari 5 dan bobot 40%, sehingga kontribusinya adalah 4 dikali 40% sama dengan 1,6. Selanjutnya kita tambahkan kriteria urgensi masalah dengan skor 5 dan bobot 35%, kontribusinya 5 dikali 35% sama dengan 1,75, sehingga subtotal menjadi 3,35. Terakhir kita tambahkan kelayakan teknis dengan skor 3 dan bobot 25%, kontribusinya 3 dikali 25% sama dengan 0,75, sehingga total skor kelayakan akhir mencapai 4,1 dari skala maksimum 5. Skor setinggi ini menandakan ide tersebut cukup layak untuk dilanjutkan menjadi proyek aplikasi — bandingkan dengan kandidat ide lain di kelompok Anda dan pilih skor tertinggi. Coba Sendiri: Uji Kelayakan Ide Proyek Anda Geser skor tiap kriteria dan ubah bobotnya, lalu amati bagaimana skor kelayakan akhir berubah secara langsung.
Silakan satu perwakilan kelompok maju dan coba masukkan skor ide proyek kelompok Anda sendiri ke kalkulator ini. Coba geser bobot urgensi masalah lebih tinggi dan perhatikan bagaimana skor akhir bergeser meski skor mentahnya tidak berubah. Perhatikan juga bahwa ide dengan skor teknis rendah tetap bisa lolos kalau urgensinya sangat tinggi — itu sebabnya bobot penting dibicarakan di awal, bukan setelah skoring selesai. Dari sini kita lanjut ke bagaimana menerjemahkan ide yang layak menjadi janji nilai yang jelas bagi pengguna. Dari Masalah ke Solusi: Value Proposition Setelah masalah terkonfirmasi, rumuskan value proposition — janji nilai aplikasi Anda dalam satu kalimat sederhana.
Untuk [kelompok pengguna target]yang mengalami [masalah spesifik]aplikasi kami membantu [manfaat utama]tidak seperti [alternatif yang ada saat ini]CONTOH ISIAN
"WARMAL" APP
Untuk mahasiswa kos yang kesulitan makan malam larut, WarMal menampilkan warung halal terdekat yang masih buka — tidak seperti aplikasi antar makanan umum yang datanya sering tidak akurat malam hari.
Value proposition ini adalah jembatan antara masalah yang sudah Anda rumuskan dan solusi aplikasi yang akan dibangun. Template empat baris ini sengaja dibuat sederhana supaya mudah diingat: siapa penggunanya, masalah apa yang mereka alami, apa manfaat utama aplikasi Anda, dan mengapa berbeda dari alternatif yang sudah ada, misalnya aplikasi antar makanan besar yang datanya kurang akurat soal warung mana yang masih buka larut malam. Latihan menyusun value proposition ini penting karena akan menjadi bahan presentasi singkat Anda di akhir pertemuan hari ini, sekaligus menjadi cikal bakal deskripsi proyek yang akan Anda kembangkan di pertemuan-pertemuan berikutnya. Hitung dari Nol: Prioritas Fitur dengan Skor RICE Fitur "Notifikasi Warung Buka Malam" dinilai memakai skor RICE = (Reach × Impact × Confidence) ÷ Effort.
Langkah Perhitungan Nilai Reach (pengguna terdampak per bulan) Diketahui 500 × Impact (skala dampak per pengguna: 2) 500 × 2 1.000 × Confidence (keyakinan estimasi 80%) 1.000 × 0,8 800 ÷ Effort (2 orang-bulan pengerjaan) 800 ÷ 2 Skor RICE = 400
HASIL AKHIR
400
skor prioritas fitur (RICE)
Skor RICE ini biasa dipakai tim produk profesional, misalnya di tim produk Tokopedia atau Traveloka, untuk memilih fitur mana yang dikerjakan lebih dulu ketika sumber daya terbatas. Mari kita hitung bersama: Reach adalah jumlah pengguna yang terdampak fitur ini setiap bulan, kita asumsikan 500 mahasiswa. Impact adalah skala dampak fitur bagi tiap pengguna, kita beri skor 2, sehingga 500 dikali 2 sama dengan 1.000. Confidence adalah tingkat keyakinan tim terhadap estimasi ini, kita asumsikan 80 persen atau 0,8, sehingga 1.000 dikali 0,8 sama dengan 800. Terakhir kita bagi dengan Effort, yaitu perkiraan usaha pengerjaan 2 orang-bulan, sehingga skor RICE akhirnya adalah 800 dibagi 2 sama dengan 400. Semakin tinggi skor RICE sebuah fitur dibandingkan fitur lain, semakin layak fitur itu dikerjakan lebih dulu dalam proyek aplikasi Anda. Coba Sendiri: Bandingkan Prioritas Dua Fitur Ubah Reach, Impact, Confidence, dan Effort dua fitur berbeda, lalu amati skor RICE mana yang menang.
Ajak satu mahasiswa maju dan minta dia memasukkan dua fitur berbeda yang ada di ide proyek kelompoknya, misalnya fitur notifikasi versus fitur pembayaran digital. Perhatikan bersama bagaimana fitur dengan effort besar bisa kalah walau reach-nya tinggi, dan sebaliknya fitur kecil dengan confidence tinggi bisa naik peringkat. Diskusikan sejenak kenapa Effort ada di penyebut, bukan pembilang — supaya jelas kenapa fitur mahal harus benar-benar sepadan dampaknya. Setelah ini kita masuk ke bagian menyusun proposal ide proyek Anda sendiri. Bagian 3 dari 3
Menyusun Proposal Ide Proyek
Merangkai elevator pitch singkat, menentukan cakupan MVP, lalu menyepakati kontrak kuliah satu semester.
Elevator Pitch
Cakupan MVP
Kontrak Kuliah
Di bagian terakhir ini kita bergerak dari analisis menuju dokumen nyata yang akan Anda kumpulkan. Kita akan berlatih menyusun elevator pitch, yaitu ringkasan ide proyek yang bisa disampaikan dalam waktu singkat, lalu menentukan cakupan minimum aplikasi yang realistis untuk satu semester. Kita tutup pertemuan hari ini dengan menyepakati kontrak kuliah: bagaimana nilai Anda dihitung, aturan kerja kelompok, dan peta lengkap empat belas pertemuan proyek aplikasi ke depan. Menyusun Elevator Pitch Proyek Elevator pitch adalah ringkasan ide proyek yang bisa disampaikan dalam 30–60 detik — latihan wajib sebelum presentasi ke dosen & tim.
Masalah: satu kalimat problem statement.Solusi: satu kalimat gagasan aplikasi.Diferensiasi: satu kalimat kenapa berbeda dari yang ada.Ajakan: satu kalimat penutup yang mengundang tanggapan.CONTOH PITCH SINGKAT
"WARMAL MEMBANTU MAHASISWA KOS MENEMUKAN WARUNG HALAL BUKA MALAM DALAM 10 DETIK."
Padat, spesifik, dan langsung menonjolkan manfaat utama bagi penggunanya.
Elevator pitch namanya diambil dari bayangan Anda bertemu investor di dalam lift dan hanya punya waktu sesingkat perjalanan lift itu untuk menjelaskan ide Anda. Empat bagian ini — masalah, solusi, diferensiasi, dan ajakan — harus muat dalam waktu sangat singkat, sehingga memaksa Anda memilih kata-kata paling penting saja. Latihan ini juga bermanfaat melatih Anda menjelaskan proyek ke dosen pembimbing atau calon anggota tim dengan cepat dan meyakinkan, mirip cara founder startup menjelaskan idenya ke calon investor di ajang seperti Startup Weekend. Silakan coba tuliskan versi pitch Anda sendiri berdasarkan rumusan masalah yang sudah dibuat tadi, lalu latih mengucapkannya keras-keras sebelum sesi presentasi kelompok. Menentukan Cakupan MVP (Minimum Viable Product) MVP = versi aplikasi paling sederhana yang tetap bisa menyelesaikan masalah inti — bukan aplikasi lengkap sekaligus.
HARUS ADA
FITUR INTI
Langsung menjawab problem statement — contoh: daftar warung & status buka/tutup real time.
MENYUSUL
FITUR PENDUKUNG
Meningkatkan pengalaman tapi bukan inti — contoh: rating warung, riwayat pencarian.
DITUNDA
FITUR IMPIAN
Menarik tapi terlalu kompleks untuk semester ini — contoh: pembayaran digital terintegrasi.
Kesalahan umum mahasiswa: mencoba membangun ketiga kategori sekaligus di semester pertama — fokuslah pada fitur inti dulu.
Konsep MVP ini sangat penting untuk proyek satu semester karena waktu dan kemampuan Anda terbatas, sama seperti startup pemula yang tidak langsung membangun aplikasi selengkap Gojek versi sekarang. Fitur inti adalah yang langsung menjawab masalah utama, dalam contoh WarMal berarti daftar warung dan status buka-tutupnya secara real time — tanpa ini, aplikasi tidak ada gunanya. Fitur pendukung seperti rating warung atau riwayat pencarian boleh ditambahkan belakangan setelah fitur inti berjalan baik. Fitur impian seperti pembayaran digital terintegrasi memang menarik, tapi kompleksitasnya terlalu besar untuk proyek Lab Pemrograman satu semester, sehingga sebaiknya ditunda dulu. Kesalahan paling sering saya lihat adalah kelompok mahasiswa yang terlalu ambisius mencoba semuanya sekaligus, akibatnya di akhir semester tidak ada satu fitur pun yang benar-benar selesai dengan baik. Latihan Hari Ini: Rumuskan Ide Proyek Kelompok Anda Kerjakan berkelompok (3–4 orang) selama sisa waktu kelas, kumpulkan lewat e-learning sebelum pertemuan berikutnya.
1. Diskusikan minimal 3 kandidat masalah bisnis digital di sekitar kampus/kos.2. Tuliskan problem statement untuk tiap kandidat memakai template Slide 10.3. Hitung skor kelayakan (seperti Slide 11) untuk ketiganya, pilih skor tertinggi.4. Susun elevator pitch (30 detik) untuk ide terpilih & siapkan cakupan MVP awal.Dokumen ini menjadi proposal awal proyek aplikasi Anda — akan disempurnakan bertahap sampai Pertemuan 13.
Sekarang giliran Anda mempraktikkan langsung apa yang sudah kita bahas hari ini. Silakan berkumpul dalam kelompok tiga sampai empat orang, lalu diskusikan minimal tiga kandidat masalah yang benar-benar Anda amati atau alami sendiri di sekitar kampus maupun tempat kos. Gunakan template problem statement dari slide sebelumnya untuk merumuskan masing-masing kandidat, lalu hitung skor kelayakannya seperti contoh perhitungan yang baru saja kita kerjakan bersama. Setelah kelompok Anda memilih satu ide dengan skor tertinggi, susun elevator pitch singkat dan cakupan MVP awalnya. Dokumen hasil latihan ini bukan tugas sekali jadi — ia akan menjadi proposal awal proyek aplikasi Anda yang terus disempurnakan sampai evaluasi akhir di Pertemuan 13, jadi kerjakan dengan sungguh-sungguh sejak sekarang. Kontrak Kuliah: Komponen Penilaian Nilai akhir Anda ditentukan dari lima komponen berikut, mengikuti perjalanan proyek aplikasi sepanjang semester.
Komponen Bobot Bentuk Tugas mingguan & progres proyek 25% Latihan & checkpoint proyek per pertemuan Diskusi & keaktifan kelas 10% Partisipasi tanya-jawab & presentasi kelompok Evaluasi Tengah Semester 25% Setelah Pertemuan 7 — prototipe UI/UX & komponen dasar Presentasi & Laporan Akhir Proyek 35% Setelah Pertemuan 14 — aplikasi terintegrasi & laporan Kehadiran 5% Minimal 75% kehadiran untuk syarat evaluasi akhir
Total bobot 100% . Karena ini mata kuliah proyek, nilai kelompok & individu dipisah — rubrik detail dibagikan lewat e-learning.
Mari kita sepakati komponen penilaian ini bersama-sama sebagai kontrak kuliah. Tugas mingguan dan progres proyek berbobot 25% karena mata kuliah ini berbasis proyek berkelanjutan, bukan hafalan sesaat — setiap minggu ada checkpoint yang harus Anda selesaikan. Diskusi dan keaktifan kelas 10% mendorong Anda aktif bertanya dan berbagi kesulitan teknis dengan kelompok lain. Evaluasi Tengah Semester berbobot 25% berupa prototipe UI/UX dan komponen dasar aplikasi, sedangkan presentasi dan laporan akhir proyek berbobot paling besar, 35%, menilai aplikasi yang sudah terintegrasi penuh di akhir semester. Kehadiran tetap berbobot 5% dengan syarat minimal 75% untuk boleh mengikuti evaluasi akhir. Karena proyek dikerjakan berkelompok, saya akan menilai kontribusi individu secara terpisah lewat log kerja mingguan, jadi pastikan semua anggota kelompok berkontribusi merata. Peta Jalan 14 Pertemuan Proyek Aplikasi Dari perumusan ide hari ini, proyek Anda akan bergerak menuju aplikasi mobile/web yang terintegrasi penuh.
P1 – P7 (SEBELUM UTS)
IDE, DESAIN & KOMPONEN DASAR
Ide proyek, UI/UX, HTML/CSS/JS & React Native, integrasi Python, state & props, login.
P8 – P11
NAVIGASI, API & DATABASE
Routing antarhalaman, REST API, struktur database, simulasi dummy API.
P12 – P14 (SEBELUM UAS)
INTEGRASI & LAPORAN AKHIR
Integrasi GUI-CRUD, penggabungan front-end & back-end, debugging, presentasi akhir.
Ide proyek yang Anda rumuskan hari ini akan terus dipakai sebagai konteks di setiap pertemuan berikutnya — pilih dengan sungguh-sungguh.
Peta jalan ini penting supaya Anda memahami mengapa pertemuan hari ini menjadi fondasi seluruh semester. Tujuh pertemuan pertama sebelum UTS akan membawa ide proyek Anda dari rumusan masalah menuju desain antarmuka dan komponen dasar aplikasi memakai HTML, CSS, JavaScript, dan React Native, termasuk integrasi Python dasar. Empat pertemuan berikutnya masuk ke navigasi antarhalaman, perancangan REST API, dan struktur database yang menopang aplikasi Anda. Tiga pertemuan terakhir sebelum UAS mengarah pada integrasi penuh antara komponen GUI, operasi CRUD, front-end, dan back-end, ditutup dengan debugging serta presentasi laporan proyek akhir. Karena setiap pertemuan akan terus memakai ide proyek yang sama sebagai konteks latihan, pastikan ide yang Anda pilih hari ini benar-benar solid dan Anda yakini. Ringkasan Pertemuan 1 Masalah bisnis digital = kesenjangan nyata, berulang, bernilai untuk diselesaikan. Tiga sumber masalah: pengamatan, wawancara, data/tren pasar digital. Rumuskan lewat problem statement, lalu saring dengan skor kelayakan berbobot. Ide terpilih dirangkum jadi elevator pitch & cakupan MVP awal. SIAP UNTUK PERTEMUAN 2
DESAIN UI/UX APLIKASI
Minggu depan kita mulai merancang antarmuka & pengalaman pengguna dari ide proyek yang sudah Anda rumuskan hari ini.
Pastikan proposal ide proyek kelompok Anda sudah dikumpulkan sebelum pertemuan berikutnya — ini fondasi seluruh proyek satu semester.
Mari kita rangkum apa yang sudah kita capai hari ini. Kita telah mendefinisikan masalah bisnis digital sebagai kesenjangan nyata, berulang, dan bernilai untuk diselesaikan, lalu mempelajari tiga sumber utama untuk menggalinya: pengamatan langsung, wawancara calon pengguna, dan data tren pasar digital. Kita juga sudah berlatih langsung merumuskan problem statement dan menghitung skor kelayakan ide memakai bobot kriteria, sampai menyusun elevator pitch dan cakupan MVP awal. Terakhir, kita menyepakati kontrak kuliah dan peta jalan empat belas pertemuan proyek aplikasi Anda. Minggu depan kita melangkah ke desain antarmuka dan pengalaman pengguna dari ide proyek yang sudah Anda rumuskan hari ini, jadi pastikan proposal kelompok Anda benar-benar solid sebelum pertemuan berikutnya. Sampai jumpa di pertemuan kedua!