Pembelajaran & Pengembangan
Pendahuluan
Bagaimana Mentor memutuskan apakah artefak member sudah cukup? Rubrik universal 4 dimensi, rubrik track-spesifik, dan prosedur sign-off di dokumen ini menjawab pertanyaan tersebut. Alur review menggunakan dua lapisan: Divisi SDM melakukan review internal terlebih dahulu, baru diteruskan ke Mentor. Ini adalah operasionalisasi dari Prinsip 2 (Bukti Mendahului Klaim) dan Prinsip 6 (Progression melalui Demonstrasi) dari 🧭 Prinsip Pembelajaran YYZU.
Daftar Isi
- Pendahuluan
- Mengapa Dokumen Ini Ada
- Struktur Assessment di YYZU
- Rubrik Universal
- Rubrik Track-Spesifik
- Kompetensi Lintas Track - Cara Evaluasi
- Prosedur Sign-off
- Retry Mechanism
- Appeal Mechanism
- Mentor Calibration
- Dokumen Terkait
1. Mengapa Dokumen Ini Ada
Kurikulum Member YYZU mendefinisikan apa yang harus dikuasai (kompetensi) dan seperti apa buktinya (evidence). Tapi tidak mendefinisikan bagaimana Mentor memutuskan apakah bukti itu cukup. Gap ini berbahaya karena:
- Tanpa rubrik, dua Mentor yang berbeda bisa membuat keputusan berbeda terhadap artefak yang sama
- Member tidak tahu standar apa yang harus dipenuhi untuk mendapat sign-off
- Tidak ada mekanisme yang jelas jika member gagal sign-off atau tidak setuju dengan penilaian
2. Struktur Assessment di YYZU
Assessment di YYZU terdiri dari tiga lapisan:
- Lapisan 1: Kompetensi Statement
- Didefinisikan di Kurikulum Member YYZU
- Bersifat abstrak dan technology-agnostic
- Lapisan 2: Evidence Definition
- Didefinisikan di Kurikulum Member YYZU
- Output konkret yang dapat diamati
- Lapisan 3: Assessment Rubric
- Didefinisikan di dokumen ini
- Kriteria operasional yang membuat evidence “cukup” Dokumen ini tidak mendefinisikan ulang kompetensi atau evidence. Dokumen ini hanya mendefinisikan lapisan ke-3.
3. Rubrik Universal
Sebelum menggunakan rubrik track-spesifik, setiap artefak dievaluasi terhadap empat dimensi universal berikut:
Dimensi 1: Kegunaan (Usability)
Pertanyaan: Apakah artefak ini bisa digunakan oleh orang lain tanpa penjelasan lisan dari pembuatnya?
| Skor | Deskripsi |
|---|---|
| Tidak Memenuhi | Artefak tidak bisa dipahami atau digunakan tanpa klarifikasi verbal dari member |
| Memenuhi | Artefak dapat digunakan oleh orang lain dengan pemahaman yang cukup setelah membacanya |
| > CATATAN PENTING: Dimensi 1 adalah gating dimension. Jika Dimensi 1 tidak memenuhi, hasil akhir otomatis NOT YET tanpa perlu evaluasi dimensi lain. |
Dimensi 2: Kelengkapan (Completeness)
Pertanyaan: Apakah semua Exit Criteria yang relevan terpenuhi?
| Skor | Deskripsi |
|---|---|
| Tidak Memenuhi | Satu atau lebih Exit Criteria belum terpenuhi |
| Memenuhi | Semua Exit Criteria untuk level yang diklaim terpenuhi |
| Biner. Tidak ada "sebagian besar terpenuhi". |
Dimensi 3: Kejujuran Proses (Process Integrity)
Pertanyaan: Apakah artefak ini merepresentasikan pekerjaan yang benar-benar dilakukan member, bukan hasil copy-paste atau generasi AI tanpa pemahaman?
| Skor | Deskripsi |
|---|---|
| Tidak Memenuhi | Member tidak bisa menjelaskan keputusan di balik artefak yang disubmit |
| Memenuhi | Member dapat menjelaskan reasoning di balik setiap keputusan signifikan dalam artefak |
| Mekanisme: Mentor dapat mengajukan pertanyaan clarifying seperlunya selama sign-off review. Jika member tidak bisa menjawab, ini adalah sinyal untuk Dimensi 3. |
Dimensi 4: Tidak Ada Fundamental Error
Pertanyaan: Apakah artefak mengandung kesalahan mendasar yang menunjukkan miskonsepsi fundamental?
| Track | Contoh Fundamental Error |
|---|---|
| Web Development | Arsitektur atau implementasi menunjukkan miskonsepsi fundamental yang membuat sistem tidak memenuhi prinsip dasar keamanan, maintainability, atau correctness. (Contoh: logika autentikasi yang sistematis tidak aman, data dikirim ke client tanpa validasi, skema yang tidak dapat berkembang) |
| UI/UX Design | Desain yang tidak memiliki hierarki visual sama sekali; tidak ada evidence riset pengguna dalam proses; handoff yang tidak memungkinkan implementasi |
| Product Management | Problem statement yang merupakan solusi tersamar; PRD tanpa acceptance criteria yang bisa diverifikasi; keputusan tanpa reasoning yang dapat dievaluasi |
| Skor | Deskripsi |
| --- | --- |
| Tidak Memenuhi | Ada satu atau lebih fundamental error yang menunjukkan miskonsepsi pada level yang diklaim |
| Memenuhi | Tidak ada fundamental error. Minor error dan imperfection diperbolehkan - ini bukan tentang kesempurnaan |
4. Rubrik Track-Spesifik
Track: Web Development
Rubrik berikut mengukur keterampilan spesifik track Web Development di setiap level.
Level Beginner - Sign-off Checklist
| Kriteria | Cara Memverifikasi |
|---|---|
| Struktur dokumen semantik dan accessible | Review kode: apakah hierarki konten logis? Apakah ada pertimbangan accessibility (alt text, label, heading order)? |
| Layout responsif tanpa ketergantungan abstraksi yang tidak dipahami | Minta member jelaskan bagaimana layout bekerja. Jika tidak bisa - gagal Dimensi 3 |
| Interaksi dinamis terhadap input pengguna | Demo live: apakah UI bereaksi terhadap input dengan cara yang bermakna? |
| Komunikasi asynchronous dengan sumber data eksternal | Lihat kode: ada penanganan error state? Loading state? |
| Riwayat commit yang dapat dibaca | Review repository: apakah commit history bersifat inkremental dan menunjukkan proses iteratif? Apakah commit messages bermakna dan logically grouped - bukan semua perubahan di-squash ke satu commit? |
| Dokumentasi setup yang memungkinkan setup mandiri | Minta reviewer lain (atau Mentor) coba jalankan project hanya dari README. Berhasil = memenuhi |
Level Intermediate - Sign-off Checklist
| Kriteria | Cara Memverifikasi |
|---|---|
| State management terstruktur dan dapat diprediksi | Review arsitektur: apakah state flow jelas? Apakah state bisa di-debug tanpa author? |
| API contract terdokumentasi dan konsisten | Lihat dokumentasi API: apakah cukup untuk digunakan developer lain tanpa penjelasan? |
| Skema data dengan relasi yang logis | Review skema: apakah bisa berkembang tanpa rewrite? Ada foreign key yang benar? |
| Sistem autentikasi tanpa celah arsitektur fundamental | Review: apakah ada token yang expire? Authorization check di server? Password tidak disimpan plaintext? |
| Error handling bermakna | Test dengan invalid input and network failure: apakah user mendapat pesan yang useful? |
| Test yang membuktikan fungsi kritis | Lihat test: apakah happy path dan minimal satu error path tercakup? |
| Review konstruktif terhadap kode orang lain | Lihat PR comments yang ditulis member: apakah spesifik dan actionable? |
Level Advanced - Sign-off Checklist
| Kriteria | Cara Memverifikasi |
|---|---|
| Architecture Decision Record (ADR) | Apakah dokumen menjelaskan pilihan arsitektur dan alternatif yang ditolak beserta alasannya? |
| Bukti pengukuran performa | Ada data sebelum dan sesudah? Pengukuran menggunakan tool (profiler, load test)? |
| Security review yang mengidentifikasi dan menangani vulnerability | Apakah review mencakup kategori vulnerability yang relevan (bukan hanya satu kasus)? |
| Pipeline CI/CD fungsional | Review pipeline secara menyeluruh: apakah pipeline mencakup tahap yang relevan (minimal build dan lint)? Apakah pipeline berjalan otomatis tanpa intervensi manual? Apakah hasilnya dapat diobservasi oleh anggota tim lain? |
| Dokumentasi keputusan arsitektural untuk generasi berikutnya | Bisakah contributor baru memahami keputusan tanpa berbicara dengan author? |
| Mentee yang menunjukkan progress terukur | Ada evidence konkret progress mentee (naik level, deliverable yang lebih baik)? |
Track: UI/UX Design
Rubrik berikut mengukur keterampilan spesifik track UI/UX Design di setiap level.
Level Beginner - Sign-off Checklist
| Kriteria | Cara Memverifikasi |
|---|---|
| Hierarki visual yang membimbing perhatian | Tunjukkan desain ke orang yang tidak familiar: apakah mereka tahu apa yang harus dilihat/dilakukan pertama? |
| Temuan riset berbasis observasi nyata | Ada dokumentasi proses riset (catatan wawancara, hasil survei)? Minimal 3 responden? |
| Representasi desain yang cukup konkret untuk feedback | Apakah reviewer bisa memberikan feedback spesifik tanpa menebak-nebak intent designer? |
| Komponen dengan pola yang konsisten dan dapat diperluas | Apakah elemen serupa menggunakan pendekatan yang sama di seluruh desain? |
| Pertimbangan accessibility dasar | Apakah ada pertimbangan kontras warna, ukuran touch target, atau alternative text? |
Level Intermediate - Sign-off Checklist
| Kriteria | Cara Memverifikasi |
|---|---|
| Laporan usability testing dengan rekomendasi konkret | Apakah laporan bisa langsung digunakan untuk membuat keputusan desain tanpa klarifikasi? |
| Desain semua interaction states | Apakah ada desain untuk: normal, loading, error, empty state, edge case? |
| Handoff spec yang memungkinkan implementasi tanpa meeting | Minta developer implementasikan berdasarkan spec saja. Berhasil tanpa meeting = memenuhi |
| Design critique yang spesifik dan actionable | Lihat komentar review: apakah mengidentifikasi masalah dan memberikan arah perbaikan? |
| Arsitektur informasi yang memungkinkan navigasi intuitif | User test: apakah pengguna bisa menemukan apa yang dibutuhkan tanpa panduan? |
| Desain responsif untuk konteks berbeda | Test di minimal dua ukuran layar yang berbeda |
Level Advanced - Sign-off Checklist
| Kriteria | Cara Memverifikasi |
|---|---|
| Design system terdokumentasi untuk contributor baru | Bisakah contributor baru menggunakan design system secara konsisten tanpa penjelasan dari author? |
| Design sprint atau workshop yang menghasilkan alignment | Ada dokumentasi proses dan artefak yang dihasilkan dari sesi? |
| Komunikasi impact desain ke non-designer | Bisakah non-designer memahami mengapa keputusan desain ini diambil dari dokumen yang ada? |
| Mentee yang menunjukkan progress terukur | Ada evidence konkret progress mentee? |
Track: Product Management
Rubrik berikut mengukur keterampilan spesifik track Product Management di setiap level.
Level Beginner - Sign-off Checklist
| Kriteria | Cara Memverifikasi |
|---|---|
| Problem statement berbasis observasi, bukan asumsi | Apakah ada bukti riset? Apakah masalah bisa dibedakan dari solusi? |
| Problem statement yang membedakan masalah dari solusi | Tes sederhana: apakah problem statement bisa ada tanpa menyebut solusi spesifik? |
| Persona dan journey map berbasis riset | Apakah ada data di balik persona, atau hanya imajinasi? |
| Keputusan prioritas dengan framework yang konsisten | Apakah framework prioritasi bisa diaplikasikan ke item lain secara konsisten? |
| Acceptance criteria yang dapat diverifikasi | Dapatkah developer memulai implementasi berdasarkan acceptance criteria ini saja? |
| Sesi diskusi yang menghasilkan keputusan dan action items | Ada dokumentasi output sesi (bukan hanya agenda)? |
Level Intermediate - Sign-off Checklist
| Kriteria | Cara Memverifikasi |
|---|---|
| Roadmap yang dapat dipahami seluruh tim | Apakah ada orang di tim yang tidak mengerti roadmap setelah membacanya? |
| Decision log yang dapat dievaluasi setelah berbulan-bulan | Bisakah orang yang tidak hadir saat keputusan dibuat memahami reasoning-nya dari dokumen? |
| Metrik yang membedakan berhasil vs tidak berhasil | Apakah metrik bisa memberikan jawaban ya/tidak yang jelas setelah produk dirilis? |
| PRD yang menghasilkan output tepat sasaran dari mitra kerja | Apakah implementor bisa memulai tanpa klarifikasi tambahan? |
Level Advanced - Sign-off Checklist
| Kriteria | Cara Memverifikasi |
|---|---|
| Dokumen strategi produk dengan reasoning | Apakah dokumen menjelaskan mengapa arah ini dipilih di atas alternatif? |
| PRD review yang mengidentifikasi gap dan risiko | Apakah review konkret dan bisa langsung ditindaklanjuti? |
| Tim yang bergerak tanpa hierarki formal | Ada evidence bahwa kolaborasi terjadi tanpa perintah formal dari PM? |
| Mentee yang menunjukkan progress terukur | Ada evidence konkret progress mentee? |
5. Kompetensi Lintas Track - Cara Evaluasi
Enam Kompetensi Lintas Track tidak dievaluasi secara terpisah. Mereka dievaluasi sebagai bagian dari setiap project submission di semua level.
| Kompetensi Lintas Track | Kapan dan Bagaimana Dievaluasi |
|---|---|
| Komunikasi teknis tertulis | Setiap artefak - apakah bisa dipahami orang lain tanpa penjelasan lisan? |
| Problem decomposition | Sprint planning, task breakdown, atau artefak perencanaan serupa - apakah member bisa memecah masalah menjadi unit kerja yang executable? |
| Iterative delivery | Evidence iterasi yang diterima: commit history, version history Figma, changelog Notion, revision history dokumen, atau sistem versioning lain - apakah ada evidence proses bertahap, atau hanya satu submission besar? |
| Feedback literacy | Evidence yang diterima: Pull Request (PR) review, design critique, document review, atau feedback dalam meeting - apakah member memberikan dan merespons feedback secara spesifik dan actionable? |
| Knowledge documentation | Kualitas README, PRD, atau dokumen lain yang dihasilkan |
| Version control mindset | Evidence yang diterima: Git workflow, Figma versioning, Notion history, atau sistem versioning lain - apakah ada kesadaran menjaga history yang dapat ditelusuri? |
| Jika seorang member secara konsisten lemah di salah satu kompetensi lintas track, Mentor mencatatnya dalam feedback dan menjadikannya fokus di sesi coaching berikutnya. |
6. Prosedur Sign-off
Langkah 1: Self-assessment oleh Member
Sebelum mengajukan sign-off, member wajib mengisi self-assessment checklist:
# Self-Assessment Checklist - **[Track] Level [X]**
| Informasi | Isi |
|-----------|-----|
| **Nama Member** | |
| **Track** | |
| **Level** | |
| **Tanggal Pengajuan** | |
| **Link Artefak** | |
---
## Checklist Dimensi Universal
- [ ] Saya dapat menjelaskan setiap keputusan signifikan yang saya ambil dalam artefak ini. *(Dimensi 3: Kejujuran Proses)*
- [ ] Artefak ini dapat digunakan atau dipahami oleh orang lain tanpa penjelasan lisan dari saya. *(Dimensi 1: Kegunaan)*
- [ ] Seluruh **Exit Criteria** untuk level ini sudah saya periksa dan terpenuhi. *(Dimensi 2: Kelengkapan)*
- [ ] Tidak ada *fundamental error* yang saya ketahui dan belum saya perbaiki. *(Dimensi 4: Tidak Ada Fundamental Error)*
## Checklist Kompetensi Lintas Track
- [ ] Artefak saya mendemonstrasikan komunikasi teknis tertulis yang jelas.
- [ ] Saya dapat menjelaskan bagaimana saya memecah masalah menjadi unit kerja yang lebih kecil.
- [ ] Artefak menunjukkan proses iteratif, bukan hanya satu submission besar.
- [ ] Saya memberikan dan merespons feedback secara spesifik dan actionable.
- [ ] Dokumentasi yang saya hasilkan dapat digunakan oleh orang lain.
- [ ] Saya menjaga history yang dapat ditelusuri (commit, version, atau sejenisnya).
---
## Refleksi
### Hal yang masih bisa ditingkatkan
Tuliskan satu hal yang menurut Anda masih dapat diperbaiki.
**Jawaban:**
---
### Keputusan yang paling saya banggakan
Tuliskan satu keputusan yang menurut Anda memiliki reasoning paling kuat, beserta alasannya.
**Jawaban:**Langkah 2: Review Internal oleh Divisi SDM
Self-assessment dan artefak dikirimkan ke Divisi SDM terlebih dahulu. Divisi SDM melakukan review internal menggunakan checklist yang relevan di dokumen ini. Tujuannya:
- Memastikan artefak memenuhi standar sebelum diteruskan ke Mentor
- Mengidentifikasi gap atau masalah teknis yang perlu diperbaiki sebelum sign-off
- Menyampaikan rekomendasi awal kepada Mentor terkait
Langkah 3: Diteruskan ke Mentor
Jika artefak lolos review internal Divisi SDM, dokumen diteruskan ke Mentor terkait (atau Mentor lainnya yang tersedia). Mentor membaca review Divisi SDM dan mereview artefak secara asinkron. Mentor mempersiapkan clarifying questions seperlunya. Jika artefak belum memenuhi standar, Divisi SDM mengembalikan ke member dengan feedback untuk perbaikan - belum sampai ke Mentor.
Langkah 4: Sign-off Session (jika diperlukan)
Jika Mentor sudah yakin dari review asinkron, sign-off dapat dilakukan secara tertulis. Jika ada pertanyaan clarifying, dijadwalkan sesi singkat maksimal 30 menit.
Langkah 5: Keputusan
APPROVED: Semua empat dimensi universal terpenuhi dan semua Exit Criteria untuk level terpenuhi. Mentor memberikan sign-off tertulis di Notion/platform yang berlaku. NOT YET: Satu atau lebih dimensi atau Exit Criteria belum terpenuhi. Mentor memberikan written feedback menggunakan format SBIN.
7. Retry Mechanism
Jika member menerima keputusan NOT YET: Langkah 1: Feedback tertulis dari Mentor - Mentor memberikan SBIN feedback yang mengidentifikasi dimensi mana yang tidak terpenuhi, Exit Criteria mana yang belum terpenuhi, contoh konkret dari artefak, dan arah perbaikan yang spesifik (Next di SBIN). Feedback ini juga dikirimkan ke Divisi SDM untuk diarsipkan dan dipantau. Langkah 2: Masa iterasi member - Member diberikan waktu satu sprint (1 - 2 minggu) untuk melakukan perbaikan berdasarkan feedback. Member harus menunjukkan evidence baru yang mendemonstrasikan peningkatan kompetensi. Evidence tersebut dapat berupa revisi artefak sebelumnya apabila perubahan yang dilakukan cukup signifikan untuk menunjukkan peningkatan nyata, atau berupa pekerjaan baru yang dikerjakan setelah feedback. Langkah 3: Re-submission - Member mengajukan ulang dengan self-assessment yang diperbarui, termasuk penjelasan eksplisit tentang apa yang berubah dari submission sebelumnya. Re-submission melewati Divisi SDM terlebih dahulu sebelum diteruskan ke Mentor. Aturan retry:
- Tidak ada batasan jumlah retry
- Setiap retry membutuhkan new evidence of demonstrable change - bukan argumen bahwa artefak sebelumnya sebenarnya sudah cukup
- Jika setelah tiga retry berturut-turut tidak ada progress yang terukur, Divisi SDM dan Mentor melakukan evaluasi bersama untuk menentukan langkah selanjutnya
8. Appeal Mechanism
Jika member percaya keputusan Mentor tidak tepat:
- Member mendokumentasikan keberatan secara tertulis: keputusan apa yang diperdebatkan, alasan mengapa member percaya keputusan itu tidak tepat, dan evidence konkret yang mendukung posisi member
- Dokumen tersebut dikirim ke Divisi SDM
- Divisi SDM meninjau artefak dan feedback Mentor secara independen dan mengambil keputusan
- Jika member masih tidak setuju dengan keputusan Divisi SDM, eskalasi dapat dilakukan ke Founder sebagai final escalation - khusus untuk kasus yang melibatkan inkonsistensi standar atau gap rubrik yang sistemik
- Hasil appeal dicatat dan dapat digunakan untuk mengkalibrasi rubrik jika ditemukan gap dalam standar yang ada Catatan: Appeal bukan tentang mendebat preferensi - appeal adalah mekanisme untuk mendeteksi ketika rubrik tidak cukup jelas atau ketika ada inkonsistensi antar-Mentor.
9. Mentor Calibration
Untuk menjaga konsistensi keputusan lintas Mentor (inter-rater reliability): Calibration session: Dilakukan minimal sekali per batch, sebelum batch dimulai. Divisi SDM memfasilitasi review bersama terhadap 2 - 3 contoh artefak - satu yang jelas memenuhi, satu yang jelas tidak memenuhi, dan satu yang borderline. Semua Mentor membuat keputusan independen terlebih dahulu, kemudian mendiskusikan perbedaan. Calibration log: Setiap perbedaan signifikan dalam calibration session dicatat oleh Divisi SDM. Jika ada perbedaan yang berulang untuk dimensi yang sama, Divisi SDM mengusulkan pembaruan rubrik dan Founder menyetujui sebelum perubahan berlaku resmi. Cascade: Ketika rubrik diperbarui, semua Mentor aktif diberitahu dan diberikan contoh konkret dari perubahan.
10. Dokumen Terkait
| Dokumen | Relasi |
|---|---|
| Context induk | |
| 📚 Kurikulum Member YYZU | Source kompetensi dan evidence definition |
| 🧭 Prinsip Pembelajaran YYZU | Landasan Prinsip 2 dan 6 |
| 📈 Skema Mentoring | Konteks keterlibatan Mentor dalam sign-off |
Referensi Dokumen Tambahan
- Panduan Peran YYZU - Definisi Asesor Bypass dan Divisi SDM
- Knowledge Architecture YYZU - Diagnostic Questions per track
Metadata dokumen tercantum di bagian atas halaman ini.
| Versi | Tanggal | Ringkasan | Oleh |
|---|---|---|---|
| 1.2 | Juli 2026 | Integrasi Divisi SDM: alur sign-off dua lapisan, re-submission lewat Divisi SDM, calibration difasilitasi Divisi SDM; referensi Appendix yang tidak ada dihapus | Ghaniyyir Rahman Sudarsono |
| 1.1 | Juni 2026 | Remediation audit: Kompetensi Lintas Track dibuat track-agnostic; gating Dimensi 1 direvisi ke evaluasi penuh dengan auto-NOT YET; retry mechanism dilonggarkan untuk revisi signifikan; appeal mechanism diperjelas dengan tiered escalation; ownership update rubrik ditambahkan; rubrik Fundamental Error, CI/CD, dan commit history diperjelas | Ghaniyyir Rahman Sudarsono |
| Owner: Ghaniyyir Rahman Sudarsono (Founder YYZU) · Approved by: Ghaniyyir Rahman Sudarsono · Review: Tahunan · Status: v1.2 - Active |