Sesi 2 — Pelatihan Elnusa

02

Hari 1 · Sesi 2

Dokumen platform — scope, arsitektur, stack, design

Satu aplikasi per meja. Empat dokumen platform — business requirement, arsitektur, tech stack, design — sebelum PRD modul.

180 menit

Tim inspeksi fasilitas Elnusa Petrofin — **Inspeksi & kepatuhan lapangan** Serah terima kerja = dokumen yang bisa dibaca mesin dan manusia.

Agenda · Sesi 2

Pondasi platform, aplikasi, lalu lab dua putaran

Putaran 1 dari bahan meja · putaran 2 selaras template · satu chat satu dokumen.

Goals

Create dokumen Business Requirement

Create dokumen Architecture

Create dokumen Tech Stack

Create dokumen Design dan HTML preview

0–12 Kontrak

1 · Penjelasan pondasi platform

What/why → how system → how coding → how UI/UX. Metode dua putaran.

12–52 Meja & alat

2 · Menentukan aplikasi dan pengenalan Cursor

Formulir meja dan modul A/B/C, lalu kenali Cursor untuk lab; bahan ke inbox.

52–128 Lab P1 → P2

3 · Latih: business requirement dan arsitektur

Mempersiapkan what/why aplikasi yang dikembangkan → how system yang dikembangkan.

128–180 Lab & tutup

4 · Latih: tech stack dan design

Stack lalu design platform dan guideline. Kritik meja dan bekal Sesi 3.

15 · Prepare · Sebelum Development PRD

Prepare pipeline: requirement → arsitektur → stack → design

Pahami platform apa dan kenapa, bagaimana sistem dan teknologi dikembangkan, dan bagaimana antarmuka dan tampilannya.

Tahap 1

01

Business Requirement

what / why

Tahap 2

02

Arsitektur

how sistem

Tahap 3

03

Stack BE / FE

how coding

Tahap 4

04

Design Guideline

how UI

Empat pondasi platformRequirement · arsitektur · stack · antarmuka

Tahap 1 · Business Requirement

Masalah bisnis & persona — siapa pemakai, pain point, outcome yang diharapkan
Capability user-facing — apa yang bisa dilakukan user, bukan sekadar daftar layar
In scope & out of scope tegas per modul latihan
Peta app/modul · route antarmuka · sentuhan backend · model data utama
Reuse fitur/modul yang sudah ada vs yang benar-benar baru
Permission, tenant, dan dependensi antar modul (Calendar, Task, Approval, …)

Tahap 2 · Arsitektur

Repository & boundary — web · api · devops/admin · shared libs & pola
Stack platform — FE/BE · database · storage · infrastruktur & DevOps
Deployment — local · dev · prod; di mana artefak & konfigurasi mendarat
CI/CD — strategi branch (mis. trunk-based) · workflow per repo · target deploy
Keamanan arsitektur — auth, boundary layanan, permukaan yang sensitif
Model data & konvensi — skema/ORM · penamaan · standard engineering & rilis

Tahap 3 · Stack BE / FE

Profil aplikasi — monolith/modular · multi-repo vs mono-repo sesuai lab
Framework inti — runtime, router, ORM/query, bundler/build FE & BE
Validasi & keamanan — schema input, authz hook, secret & env handling
Database & storage — driver, migrasi, file/object store yang dipakai
Modul & pola internal — layer service, DTO, error, logging yang konsisten
Testing · skeleton folder · variable env — struktur repo siap dikerjakan agent

Tahap 4 · Design Guideline

Design token — warna, tipografi, spacing, radius, shadow (EPN / brand meja)
Hierarki halaman — header, body, footer, density; satu ide utama per layar
Komponen reuse — button, field, table, card; kapan pakai variant apa
Pola form & tabel — validasi, loading, empty state, error & pesan bisnis
Responsif & aksesibilitas — kontras, fokus keyboard, label yang jelas
Anti-pattern — yang dilarang agar UI tidak pecah antar modul/agent

What/why di scope · how sistem & teknologi · how UI — empat tahap itu harus jelas sebelum satu baris PRD modul.

12–32 · Meja, lalu alat

Menentukan Aplikasi dan Pengenalan Cursor

Kunci satu aplikasi per meja, lalu kenali Cursor sebagai tempat lab dokumen platform.

Menentukan aplikasi

Tim operasi Elnusa berkoordinasi — **Formulir meja · modul A / B / C** Satu aplikasi per meja — isi plano, bacakan, baru laptop.

Pengenalan Cursor

Referensi meja · lintas departemen

17 ide aplikasi — pilih satu untuk latihan

Gulir dokumen · standalone · tiap ide: tujuan, masalah, modul A/B/C (selesai jika…).

Memuat dokumen ide aplikasi…

Prepare platform · dokumen 1

Business requirement | What / Why — develop aplikasi?

Deskripsikan platform kamu: untuk apa, kenapa, siapa, bagaimana, kenapa.

KENAPA

Mengunci what/why produk sebelum spesifikasi teknis dan PRD per modul
Menjelaskan masalah operasional yang diselesaikan dan siapa pemakainya
Menetapkan outcome bisnis terukur — bukan daftar layar tanpa konteks nilai
Memisahkan yang dibangun, yang ditunda, dan yang sengaja di luar scope produk
Peta capability / modul jadi acuan urutan delivery dan folder PRD
Tanpa scope, arsitektur, stack, dan PRD cenderung mengisi kekosongan dengan asumsi

GOALS

Menjadi satu acuan bisnis — ringkasan produk, pemakai, dan nilai yang dikejar
Menjelaskan masalah & alasan membangun platform (what/why), bukan daftar fitur kosong
Memetakan capability & modul plus prioritas gelombang delivery
Mencatat skala, domain, integrasi, dan yang sengaja di luar scope
Menyiapkan handoff ke arsitektur dengan open questions & changelog yang terlacak

Template BUSINESS_SCOPE.md.tmpl

templates/platform/BUSINESS_SCOPE.md.tmpl

# Business Requirement — {{product_name}}

Status: draft | review | approved
Terakhir diperbarui: {{date}}
Owner bisnis: {{business_owner}}


## 1. Ringkasan produk
## 2. Katalog feature
## 3–4. Skala & horizon 6 bln
## 5. Domain bisnis ·
## 6. Saluran & persona
## 7. Ukuran sukses ·
## 8. Peta modul
## 9. Dependensi ·
## 10. Integrasi eksternal
## 11. Di luar scope ·
## 12. Open questions
## 13. Handoff ke delivery
## 14. Changelog

Business requirement · what / why

Isi setiap bagian dokumen

1 Ringkasan produk

Jawaban singkat: platform ini untuk apa, siapa pemakainya, dan nilai utama yang dikejar.

Biasanya 2–3 paragraf narasi — bukan daftar fitur, bukan solusi teknis.

2 Katalog feature

Tabel modul/capability: key konsisten, folder PRD, gelombang MVP atau fase berikutnya.

Satu baris = satu unit delivery yang bisa dijadwalkan; bukan FR, API, atau layar.

3–4 Skala & horizon 6 bln

Baseline operasional (pengguna, transaksi, tenant) dan kondisi hari ini.

Target 6 bulan, asumsi, milestone — greenfield isi 0/N/A, jangan dikosongkan.

5 Domain bisnis

Narasi domain bisnis dan aturan yang berlaku lintas banyak modul.

Edge case shared dicatat di sini; bukan alur layar per modul atau skema database.

6 Saluran & persona

Saluran UI level produk: admin web, mobile, API publik, atau worker tanpa UI.

Persona ringkas per saluran; detail persona modul di BRD_*.md folder modul.

7 Ukuran sukses

Outcome bisnis terukur: bukti bahwa investasi platform berhasil.

Bukan salin ulang angka mentah dari bagian skala; modul boleh selaras, payung tetap di sini.

8 Peta modul

Tabel folder NNNN, nama modul, feature key, status BRD/PRD.

Acuan urutan kerja: modul A/B/C mendarat di folder docs mana sebelum PRD ditulis.

9 Dependensi

Prasyarat antar feature — contoh: platform/auth sebelum modul domain.

Menjelaskan urutan yang aman; mencegah tim paralel tanpa fondasi yang sama.

10 Integrasi eksternal

Inventaris bisnis: payment, notifikasi, ERP, data pihak ketiga — jenis dan arah data.

Tandai wajib MVP atau tidak plus dampak bisnis; detail adapter teknis di dokumen arsitektur.

11 Di luar scope

Daftar eksplisit yang sengaja tidak dibangun di produk ini.

Modul C, nice-to-have, atau proses manual — agar PRD tidak melebar tanpa keputusan meja.

Prepare platform · dokumen 2

Arsitektur | How system

Dengan batas sistem, aktor, trust, dan integrasi terdokumentasi maka stack dan pengembangan modul tidak menebak how system.

KENAPA

Mengunci batas sistem sebelum schema, framework, dan detail implementasi
Menjelaskan aktor, alur, dan trust — siapa berinteraksi dengan siapa, data masuk/keluar ke mana
Menetapkan tanggung jawab tiap komponen — web, API, penyimpanan, integrasi; bukan asumsi “semua saling panggil”
Memisahkan yang termasuk produk dan yang sengaja di luar sistem — legacy, manual, pihak ketiga
Diagram & kontrak bersama jadi acuan estimasi, keamanan, integrasi, dan perubahan skala

GOALS

Menjadi satu peta sistem — konteks, diagram, dan batas produk vs eksternal
Menjelaskan trust & aliran data antar komponen — tanpa secret atau daftar versi paket
Memetakan modul domain selaras katalog feature di business requirement
Mencatat cara delivery — workspace, branch, CI/CD, QA — sebelum dokumen stack
Menyiapkan handoff ke tech stack dengan open questions dan ADR ringkas

Template ARCHITECTURE.md.tmpl

templates/platform/ARCHITECTURE.md.tmpl

# Architecture — {{product_name}}

Status: draft | review | approved
Sebelum: BUSINESS_SCOPE.md


## 1. Konteks sistem       diagram · aktor · trust
## 2. Batas sistem & container
### 2.1 Unit
### 2.2 Integrasi
### 2.4 Modul domain
## 3. Stack (ringkas)        → TECH_STACK
## 4. Workspace
## 5. Repository
## 6. Branch Management
## 7. Security baseline ·
## 8. Observability
## 9. CI/CD · local, stg, prod
## 10. Mekanisme QA
## 11. ADR ·
## 12. Open questions

Arsitektur · how system

Isi setiap bagian dokumen

1 Konteks sistem

Diagram konteks plus narasi aktor utama dan trust boundary produk.

Menjawab gambaran besar sebelum detail container; tanpa secret atau versi paket.

2 Batas sistem & container

Peta batas logical/physical: apa di dalam produk, apa di luar sistem.

Landasan sebelum unit deployable dan integrasi dipecah lebih rinci.

2.1 Unit

Web, API, worker, database — unit deployable dan perannya singkat.

Bukan daftar framework; pilihan teknologi detail ada di tech stack.

2.2 Integrasi

Pola hubungan antar unit dan ke sistem eksternal (HTTP, queue, webhook).

Selaras inventaris integrasi bisnis di business requirement.

2.4 Modul domain

Pembagian modul/domain selaras katalog feature requirement.

Boundary data dan use case antar modul — cegah “semua saling panggil”.

3 Stack (ringkas)

Pointer ke dokumen TECH_STACK; tidak menduplikasi versi paket.

Cukup lapisan yang sudah diputus (UI, API, DB) plus alasan singkat.

4 Workspace

Di mana tim bekerja: monorepo, multi-repo, folder platform dan modul.

Satu peta path supaya docs, kode, dan agent tidak tercampur.

5 Repository

Daftar repo, ownership, dan hubungan antar repo jika layered.

Struktur organisasi kode — bukan isi implementasi per file.

6 Branch Management

Definisi branch, alur merge, dan kaitannya ke lingkungan dev/stg/prod.

Definisi “selesai” selaras review manusia sebelum rilis.

7 Security baseline

Authn/authz, data sensitif, dan baseline keamanan tanpa menulis secret.

Acuan review keamanan sebelum coding modul dan integrasi.

8 Observability

Log, metric, dan jejak insiden — apa yang harus terlihat saat produksi.

Bukan spesifikasi vendor APM kecuali sudah keputusan organisasi.

9 CI/CD

Alur dari commit ke local, staging, dan produksi; artefak apa ke mana.

Perubahan kode memicu pipeline — bukan hanya “jalan di laptop”.

10 Mekanisme QA

Unit, integration, smoke, gate rilis — kait ke PRD modul nanti.

QA terencana di arsitektur, bukan ad hoc setelah fitur selesai.

Prepare platform · dokumen 3

Tech stack | How coding

Dengan lapisan teknologi, repo, dan cara jalan lokal terdokumentasi maka pengembangan modul dan agent tidak menebak how coding.

KENAPA

Menetapkan how coding setelah batas sistem — satu acuan untuk tim & agent
Menghubungkan pilihan arsitektur (web, API, DB) ke versi terbaca atau target eksplisit
Perintah test & jalankan lokal — supaya PRD nanti tidak asumsi repo kosong
Membaca ARCHITECTURE — tidak menduplikasi diagram container
Tanpa stack, design platform dan PRD modul mengisi framework sendiri

GOALS

Menjadi satu acuan how coding — UI, API, DB, auth plus alasan tiap lapisan
Menjelaskan versi terbaca atau target dari lockfile/manifest — bukan angka karangan
Memetakan repo & perintah lokal — test, run, port — supaya PRD tidak asumsi repo kosong
Mencatat infra lokal, CI/CD, dan testing selaras arsitektur tanpa duplikasi diagram
Menyiapkan handoff ke design platform dan PRD modul — termasuk cara memperbarui stack

Template TECH_STACK.md.tmpl

templates/platform/TECH_STACK.md.tmpl

# Tech Stack — {{product_name}}

Sebelum: ARCHITECTURE.md

## 1. Peta stack
## 2. Ringkasan eksekutif  UI · API · DB · auth + alasan
## 3. Repositori
## 4–5. Frontend · Backend
## 6. Database & storage
## 7. Pola lintas service
## 8. Infra & port lokal
## 9. CI/CD · ## 10. Kualitas & testing
## 11. Cara memperbarui

Tech stack · how coding

Goals setiap tahap dokumen

1 Peta stack

Menentukan seberapa detail dokumentasi stack — satu gugus atau per lapisan — sesuai ukuran repo.

Supaya tim dan agent tahu di mana mencari jawaban tanpa duplikasi atau kekosongan.

2 Ringkasan eksekutif

Memberi satu jawaban cepat: lapisan apa dipakai untuk UI, API, data, auth, dan deploy.

Supaya pilihan teknologi terbukti dan konsisten — bukan asumsi atau salinan produk lain.

3 Repositori

Menjelaskan rumah kode dan peran tiap repo/folder — siapa kerja di mana.

Supaya struktur kerja selaras gambaran sistem, tanpa menebak lokasi proyek.

4 Frontend

Menetapkan standar bangun UI — alat, gaya, dan quality gate sebelum merge.

Supaya setiap layar dan agent FE mengikuti pola yang sama, bukan stack baru per fitur.

5 Backend

Menetapkan standar layanan — cara jalan, akses data, job latar, dan uji lokal.

Supaya modul domain implementasinya seragam dan dapat di-review.

6 Database & storage

Mendefinisikan tempat data hidup — persisten, cache, unggah file — plus aturan evolusi schema.

Supaya perubahan data terkendali dan aman untuk produksi.

7 Pola lintas service

Menyelaraskan cara layanan saling bicara — login, routing, tenant, hak akses.

Supaya fitur baru tidak menginventasi jalur sendiri di luar keputusan platform.

8 Infra & port lokal

Menyamakan lingkungan laptop — layanan apa jalan, port berapa, urutan nyalakan.

Supaya onboarding cepat: semua orang menjalankan stack yang sama.

9 CI/CD

Mendefinisikan alur otomatis dari commit ke test, staging, dan rilis.

Supaya deploy repeatable — bukan ritual manual yang berbeda tiap orang.

10 Kualitas & testing

Menetapkan definition of done teknis: cukup aman merge vs cukup aman rilis.

Supaya QA modul nanti plug-in ke gate yang sudah disepakati platform.

11 Cara memperbarui

Menjaga dokumen stack tetap sumber kebenaran saat dependency atau vendor berubah.

Supaya agent dan tim tidak drift tanpa keputusan meja yang tercatat.

Prepare platform · dokumen 4

Design platform : Guideline Design → Prototype

Dokumen prototype — guideline, komponen, dan contoh halaman.

KENAPA

Menetapkan satu acuan untuk design
Brand guideline konsisten
Menetapkan prinsip-prinsip UI/UX sesuai dengan BUSINESS_SCOPE
Mengurangi halusinasi ketika pengembangan

GOALS

Menjadi satu acuan how UI — token, shell, komponen, lalu prototype HTML sebelum PRD modul
Menetapkan color, typography, spacing, komponen, menu, header, footer — plus sample beberapa halaman — terdokumentasi
Menerjemahkan persona & saluran dari business scope ke prinsip layout, density, dan pola form/tabel
Mencatat komponen inti, anti-pattern, a11y — agent mengikuti DESIGN.md, bukan tebak gaya sendiri

Dokumen Prototype (Guideline, Komponen dan Contoh Halaman)

DESIGN.md · komponen · HTML sample halaman

# Prototype — {{product_name}}

Sebelum: TECH_STACK.md · BUSINESS_SCOPE §6

Guideline · DESIGN.md — token & prinsip UI
## 1. Filosofi · ## 2. Color tokens
## 3. Typography · ## 4. Surface / komponen

Komponen · menu · header · footer · button · table · form

Contoh halaman · HTML preview — 2–3 layar representatif