---

Daftar Isi

1. Pendahuluan
2. Struktur Pelaksanaan & Peran Project
3. Pembentukan Kelompok
4. Divisi Product & Project Management (Detail)
5. Project Leader
6. Metodologi Kerja: Agile Scrumban
7. Alur Kerja Project (Project Workflow)
8. Standardisasi Tools Kolaborasi Ekosistem YYZU
9. Standardisasi Dokumentasi Proyek
10. Kategori & Karakteristik Project 9.1 Mini Project 9.2 Collaborative Project
    • Abstraksi Collaborative Project
    • Contoh: Platform Event YYZU
    • Peran dalam Tim 9.3 Internal Project 9.4 Real-World Project Development 9.5 Open-Source Contribution 9.6 Klasifikasi Aktivitas Ekosistem (Non-Project & Project)
11. KPI Framework
12. Batasan & Eskalasi
13. Kebijakan Kontribusi Aktif & Penanganan Anggota Pasif
14. Governance Dokumen

---

Pendahuluan

Kompetensi di YYZU divalidasi melalui proyek nyata, bukan kuis. Dokumen ini mengatur framework eksekusi proyek - dari pembentukan tim, metodologi Scrumban, alur kerja 5 fase, hingga KPI dan kebijakan kontribusi aktif - untuk seluruh kategori proyek di ekosistem YYZU.

[NOTE] Catatan untuk Calon Member Pemula: Seluruh alur kerja industri (seperti Git, Figma, Kanban) akan diajarkan dari dasar pada fase Learning Sprint. Anda tidak perlu khawatir jika belum pernah menggunakannya. Istilah Kunci:

• Batch: Periode keanggotaan aktif dalam ekosistem YYZU, di mana sekelompok anggota menjalani program mentoring dan project secara bersamaan. Satu batch mencakup satu siklus project dari Foundation hingga Release.
• BPH (Badan Pelaksana Harian): Kepengurusan harian ekosistem YYZU yang bertanggung jawab atas operasional sehari-hari, termasuk koordinasi dengan Mentor, Divisi PM, dan anggota.
• Project Leader (Person In Charge): Jabatan yang bertanggung jawab mengoordinasikan eksekusi harian project dalam satu kelompok. Bersifat project-scoped, melekat pada satu project tertentu.
• PIC (Person In Charge): Orang yang ditunjuk bertanggung jawab atas satu kegiatan atau aktivitas non-project (misal: study group, workshop, code review). Berbeda dengan Project Leader yang khusus untuk project management.
• Divisi SDM: Divisi yang bertanggung jawab atas sumber daya manusia, rekrutmen, evaluasi kinerja, dan penanganan kasus disiplin anggota.
• SP (Surat Peringatan): Surat peringatan resmi yang diterbitkan kepada anggota yang tidak memenuhi standar keaktifan (lihat Bagian 12).

---

1. Struktur Pelaksanaan & Peran Project

Level	Peran	Fungsi Utama
1	Founder YYZU	Mengawasi arah batch, menghadiri demo akhir, dan memberikan validasi strategis.
2	Mentor (Instructor + Client)	Memberikan brief, membimbing teknis, menguji kelayakan ide (Q&A Challenge), dan memberikan persetujuan (sign-off).
3	Divisi Product & Project Management	Menerjemahkan brief menjadi draf scope dan timeline, mengoordinasikan Project Leader, dan memantau linimasa batch.
4	Project Leader	Melakukan koordinasi harian, membagi task, memperbarui Kanban Board, dan memimpin pertahanan proposal kelompok.
5	Anggota Kelompok	Melaksanakan task, menyusun proposal produk (PRD/Figma), meyakinkan Mentor dalam presentasi, serta eksekusi teknis.

Detail Tanggung Jawab Peran:

• Founder YYZU (Pemimpin Ekosistem): Mengawasi jalannya seluruh project, menghadiri sesi presentasi akhir (Demo Day), serta memberikan arahan dan validasi strategis jangka panjang bagi hasil karya member.
• Mentor (Instructor & Client):
  • Peran Client (Stakeholder/Investor): Bertindak sebagai pemilik produk atau investor. Mentor akan menguji urgensi masalah dan solusi yang diajukan oleh tim, mengajukan pertanyaan kritis (Q&A Challenge), dan memberikan persetujuan ide awal (approval) setelah kelompok berhasil meyakinkan kelayakan ide tersebut secara rasional.
  • Peran Instructor: Memberikan bimbingan teknis, meninjau kualitas kode/desain (code/design review), serta mengevaluasi pertumbuhan kompetensi member.
• Divisi Product & Project Management (PM): Penjaga jalur komunikasi resmi antara Mentor dan Project Leader kelompok, memantau linimasa pengerjaan batch, menerjemahkan brief Mentor menjadi draf scope dan timeline, serta memfasilitasi kebutuhan resource tim.
• Project Leader (Project-scoped): Mengoordinasikan pembagian tugas harian anggota tim, memastikan Kanban Board selalu terupdate, memimpin tim dalam penyusunan proposal proyek, serta menjadi jalur komunikasi utama dengan Divisi PM.
• Anggota Kelompok (Members): Melakukan riset mandiri untuk memetakan masalah, menyusun draf proposal produk (PRD/Figma) bersama tim, mempertahankan ide di depan Mentor saat sesi pitching, serta mengeksekusi desain atau menulis kode setelah ide disetujui.

---

2. Pembentukan Kelompok

Terdapat dua opsi pembentukan kelompok: self-form, yaitu anggota memilih sendiri rekan kelompoknya, atau assigned, yaitu kelompok disusun langsung oleh Divisi Product & Project Management. Pendekatan yang direkomendasikan adalah hybrid: anggota melakukan self-form terlebih dahulu, kemudian Divisi Product & Project Management memvalidasi apakah komposisi setiap kelompok cukup proporsional terhadap kebutuhan project yang berjalan. Kriteria proporsionalitas ditentukan oleh Divisi Product & Project Management pada tahap planning, disesuaikan dengan jenis project yang dijalankan. Ukuran Kelompok: Default 4 orang per kelompok (sesuai parameter di Bagian 13), dapat disesuaikan 3-5 orang berdasarkan kompleksitas project. Divisi Product & Project Management berwenang menentukan ukuran optimal berdasarkan jenis project dan ketersediaan anggota. Kriteria Proporsionalitas:

• Keseimbangan kemampuan teknis (developer, designer, non-teknis)
• Pengalaman belajar yang beragam (tidak semua anggota baru atau semua senior)
• Preferensi role yang sesuai dengan kebutuhan project Apabila ditemukan kelompok dengan komposisi yang tidak seimbang, reshuffle dilakukan sebelum project dimulai, bukan pada saat proses eksekusi sedang berjalan.

---

3. Divisi Product & Project Management

Divisi Product & Project Management (Divisi PM) adalah divisi kepengurusan YYZU yang bertanggung jawab atas kelancaran operasional seluruh project di ekosistem YYZU pada level batch. Berbeda dengan Project Leader yang bekerja di level kelompok, Divisi PM bekerja di level lintas kelompok dan menjadi penghubung antara Mentor dengan seluruh tim yang berjalan.

Tujuan

Memastikan seluruh project dalam satu batch berjalan sesuai framework, timeline, dan standar kualitas yang telah ditetapkan, serta menjadi titik koordinasi resmi antara Mentor, Project Leader, dan BPH selama siklus project berlangsung.

Ruang Lingkup Tanggung Jawab

Sebelum Project Dimulai (Fase Foundation):

• Mentor bersama Divisi Product & Project Management menetapkan tema project, kemudian Divisi PM mengumumkan dan menyosialisasikan kepada seluruh anggota batch.
• Memfasilitasi proses pembentukan kelompok (self-form atau assigned) dan memvalidasi komposisi setiap kelompok.
• Menunjuk Project Leader untuk setiap kelompok atau memfasilitasi proses pemilihan Project Leader.
• Menerjemahkan brief dari Mentor menjadi draf scope, milestone, dan timeline batch yang dapat dipahami oleh Project Leader.
• Memastikan seluruh kelompok memiliki akses ke tools yang diperlukan sebelum project dimulai. Selama Project Berjalan (Fase Execution):
• Menerima laporan progres dari seluruh Project Leader secara berkala, minimal satu kali per sprint.
• Memantau status Kanban Board seluruh kelompok untuk mendeteksi bottleneck atau keterlambatan lebih awal.
• Menjadi jalur komunikasi resmi antara Project Leader dan Mentor. Project Leader tidak diperbolehkan menghubungi Mentor secara langsung terkait perubahan scope atau requirement tanpa melalui Divisi PM.
• Memfasilitasi negosiasi perubahan scope apabila ada kelompok yang membutuhkan penyesuaian, dengan membawa kasus tersebut ke Mentor.
• Mendeteksi gap antara rencana dan realita sebelum gap tersebut menjadi blocker yang terlambat ditangani.
• Menerbitkan SP1 dan SP2 sesuai prosedur Free Rider Policy (lihat Bagian 12). Menjelang Akhir Project (Fase Release & Closing):
• Memastikan seluruh kelompok siap untuk Demo Day, termasuk kesiapan presentasi dan dokumentasi.
• Mengumpulkan dan mengarsipkan seluruh dokumentasi project dari semua kelompok.
• Menyusun ringkasan batch kepada BPH dan Mentor setelah project selesai.

Wewenang

• Melakukan reshuffle komposisi kelompok sebelum project dimulai apabila ditemukan ketidakseimbangan yang signifikan.
• Menolak atau meminta revisi draf scope kelompok apabila dinilai tidak realistis terhadap timeline atau kapasitas tim.
• Membawa kasus perubahan scope ke Mentor atas nama kelompok, dan meneruskan keputusan Mentor kepada Project Leader.
• Menerbitkan SP1 dan SP2 terhadap anggota yang melanggar kebijakan kontribusi aktif.
• Mengeskalasi kasus ke Divisi SDM atau Founder apabila situasi di luar kapasitas Divisi PM untuk diselesaikan.

Batasan Peran

Divisi PM tidak bertanggung jawab atas:

• Mengerjakan task teknis milik kelompok. Divisi PM bukan backup developer atau desainer.
• Memimpin Daily Sync atau Sprint Ceremony kelompok; itu adalah tanggung jawab Project Leader.
• Memberikan penilaian teknis terhadap kualitas kode atau desain; penilaian teknis adalah domain Mentor selaku instructor.
• Memutuskan kelulusan atau transisi Level anggota; itu adalah kewenangan Mentor dan Divisi SDM.
• Mengubah framework atau kebijakan batch secara sepihak; perubahan harus mengikuti prosedur di Bagian 13.

Format Monitoring

Untuk menjalankan fungsi pemantauan secara efektif, Divisi PM menggunakan mekanisme berikut:

• Laporan progres mingguan dari setiap Project Leader, minimal berisi: task yang selesai di sprint berjalan, task yang sedang berjalan, dan blocker aktif yang ada.
• Akses baca ke Kanban Board semua kelompok untuk pemantauan mandiri.
• Sinkronisasi langsung dengan Mentor minimal satu kali per dua sprint untuk update status batch secara keseluruhan.

Profil Orang yang Sesuai

Posisi ini sesuai untuk individu yang mampu berpikir di level sistem (melihat keseluruhan batch, bukan hanya satu kelompok), terorganisir dalam mengelola banyak jalur komunikasi sekaligus, dan nyaman mengambil keputusan koordinatif di bawah tekanan waktu. Kemampuan teknis dasar dibutuhkan agar dapat membaca Kanban Board dan memahami laporan Project Leader secara substantif, bukan sekadar administratif.

Indikator Keberhasilan

• Tidak ada blocker lintas kelompok yang baru diketahui setelah terlambat ditangani.
• Seluruh kelompok dalam batch menyelesaikan project sesuai atau mendekati timeline yang disepakati.
• Komunikasi antara Mentor dan seluruh Project Leader berjalan lancar tanpa miskomunikasi yang berulang.
• Dokumentasi seluruh kelompok terkumpul lengkap pada akhir batch.
• Tidak ada kasus Free Rider yang mencapai Langkah 4 tanpa melalui prosedur eskalasi yang benar.

---

4. Project Leader

Peran ini bersifat project-scoped, berbeda dengan peran kepengurusan permanen di level divisi YYZU. Project Leader hanya aktif selama satu project berjalan dan melekat pada satu kelompok tertentu.

Tujuan

Project Leader bertanggung jawab dalam mengoordinasikan eksekusi harian kelompoknya, agar project berjalan sesuai scope, timeline, dan kualitas yang telah disepakati pada tahap planning, serta menjadi titik komunikasi utama antara kelompok dan Divisi Product & Project Management.

Ruang Lingkup Tanggung Jawab

• Membagi task kepada anggota kelompok sesuai hasil planning.
• Memantau progres harian maupun mingguan setiap anggota kelompok.
• Memastikan dokumentasi kelompok (progres, kendala, dan hasil kerja) tercatat dengan baik.
• Melaporkan progres dan kendala kepada Divisi Product & Project Management secara berkala.
• Memastikan kelompok siap menghadapi checkpoint bersama Mentor.
• Menjadi penengah pertama atas konflik kecil dalam kelompok, sebelum dilakukan eskalasi.

Wewenang

• Menentukan pembagian task harian dalam batas scope yang telah disepakati.
• Mengeskalasi kendala kepada Divisi Product & Project Management apabila tidak dapat diselesaikan secara internal.

Batasan Peran

Project Leader tidak bertanggung jawab atas:

• Mengubah scope atau requirement project secara sepihak; perubahan harus melalui Divisi Product & Project Management dan disetujui oleh Mentor.
• Melakukan komunikasi langsung dengan Mentor terkait brief atau requirement; komunikasi tersebut menjadi jalur Divisi Product & Project Management.
• Menentukan kelulusan atau transisi Level anggota kelompoknya; hal ini tetap menjadi kewenangan Mentor dan Divisi SDM.
• Menjabat secara permanen di luar durasi project; peran Project Leader berakhir saat project selesai.
• Suksesi: Jika Project Leader mengundurkan diri atau berhalangan di tengah project, Divisi Product & Project Management menunjuk pengganti sementara dari anggota kelompok yang ada, atau mengadakan pemilihan ulang dalam kelompok. Suksesi harus diselesaikan maksimal 3 hari kerja sebelum eksekusi terganggu.

Profil Orang yang Sesuai

Posisi ini sesuai untuk individu yang terorganisir, proaktif, dan nyaman berkoordinasi dengan banyak orang, serta tidak segan melakukan eskalasi ketika diperlukan. Individu pada posisi ini perlu memiliki kemampuan teknis dasar pada bidang project yang berjalan, agar mampu memahami progres anggotanya secara substantif, bukan hanya administratif.

Indikator Keberhasilan

• Kelompok menyelesaikan pekerjaan sesuai timeline yang disepakati pada tahap planning.
• Komunikasi progres kepada Divisi Product & Project Management berjalan lancar, tanpa kendala yang baru diketahui setelah terlambat.
• Anggota kelompok siap pada setiap checkpoint Mentor tanpa kebingungan terhadap scope. Untuk checklist harian, template ceremony, dan panduan lengkap Project Leader, lihat: Panduan Project Leader

---

5. Metodologi Kerja: Agile Scrumban

Seluruh project di ekosistem YYZU wajib menggunakan metodologi Scrumban - pendekatan hybrid yang menggabungkan struktur Scrum dengan fleksibilitas Kanban.

Mengapa Scrumban?

Scrum memberikan ritme kerja terstruktur melalui sprint dan ceremony berkala, sehingga tim memiliki cadence yang jelas dan terukur. Kanban memberikan visibilitas alur kerja secara real-time dan mencegah bottleneck melalui pembatasan pekerjaan yang sedang berjalan (WIP Limit). Kombinasi keduanya sesuai dengan kondisi tim YYZU yang berukuran kecil, memiliki kapasitas tidak selalu konsisten, dan perlu belajar workflow industri secara bertahap.

Komponen Scrumban yang Berlaku di YYZU

Komponen	Sumber	Fungsi
Sprint (1 - 2 minggu)	Scrum	Unit kerja utama dengan batas waktu tetap
Sprint Ceremonies	Scrum	Struktur sesi perencanaan, sinkronisasi, dan evaluasi
Backlog	Scrum	Daftar terprioritas semua pekerjaan yang akan datang
Kanban Board	Kanban	Visualisasi status seluruh task secara real-time
WIP Limit	Kanban	Batasan jumlah task yang boleh dikerjakan bersamaan
Pull System	Kanban	Anggota mengambil task berikutnya saat kapasitas tersedia

Kanban Board: Kolom Wajib

Seluruh task wajib dikelola di Kanban Board dengan kolom berikut: Backlog -> To Do -> In Progress -> In Review -> Done

• Backlog: Seluruh task yang sudah teridentifikasi namun belum dijadwalkan ke sprint berjalan.
• To Do: Task yang dikomitkan untuk dikerjakan pada sprint ini.
• In Progress: Task yang sedang aktif dikerjakan. WIP Limit maksimal 2 task per anggota pada waktu bersamaan.
• In Review: Task selesai dikerjakan, menunggu review dari rekan tim atau Project Leader.
• Done: Task telah diverifikasi sesuai Definition of Done (lihat Bagian 5.2).

5.1 Sprint Ceremonies (Sesi Wajib per Sprint)

Setiap sprint wajib menjalankan empat ceremony berikut. Seluruh sesi dipimpin oleh Project Leader dan dihadiri oleh seluruh anggota tim. 1. Sprint Planning

• Waktu: Hari pertama sprint, maksimal 60 menit.
• Peserta: Seluruh tim + Mentor (opsional, diundang jika ada keputusan scope besar).

Catatan Kehadiran Mentor: Mentor wajib hadir di Sprint Review (Bagian 5.1.3) untuk validasi hasil. Untuk Sprint Planning, kehadiran Mentor bersifat opsional kecuali ada keputusan perubahan scope signifikan. Untuk Sprint Retrospective, Mentor tidak wajib hadir.

• Agenda:
  1. Review backlog dan prioritas bersama.
  2. Tim memilih task dari backlog yang akan dikerjakan pada sprint ini.
  3. Setiap task dipecah menjadi subtask konkret dan diassign ke anggota.
  4. Estimasi durasi pengerjaan per task disepakati bersama.
• Output: Kanban Board terisi dengan task sprint yang siap dikerjakan. 2. Daily Sync (Standup)
• Waktu: Setiap hari kerja, maksimal 15 menit. Bisa dilakukan secara asinkron via pesan teks jika tim tidak bisa sinkron langsung.
• Peserta: Seluruh anggota tim.
• Format tiga pertanyaan:
  1. Apa yang sudah selesai sejak kemarin?
  2. Apa yang akan dikerjakan hari ini?
  3. Adakah blocker yang menghambat pekerjaan?
• Catatan: Daily Sync bukan sesi problem-solving. Blocker yang butuh diskusi panjang dijadwalkan terpisah setelah sesi selesai. 3. Sprint Review
• Waktu: Hari terakhir sprint, maksimal 45 menit.
• Peserta: Seluruh tim + Mentor (wajib hadir).
• Agenda:
  1. Tim mendemonstrasikan apa yang berhasil diselesaikan dalam sprint ini.
  2. Mentor memberikan feedback dan validasi terhadap deliverable.
  3. Task yang belum selesai dikaji: apakah dilanjutkan ke sprint berikutnya atau di-descope.
• Output: Daftar task Done yang divalidasi Mentor dan keputusan task carry-over. 4. Sprint Retrospective
• Waktu: Setelah Sprint Review, maksimal 30 menit.
• Peserta: Seluruh anggota tim. Mentor tidak wajib hadir.
• Format tiga kolom:
  1. What Went Well - apa yang berjalan baik dan harus dipertahankan.
  2. What Went Wrong / Bottlenecks - hambatan teknis atau komunikasi yang terjadi.
  3. Action Items - tindakan konkret yang akan diterapkan pada sprint berikutnya.
• Output: Catatan Retrospektif terisi dan disimpan di Notion sebagai bagian dari dokumentasi project.

5.2 Definition of Done (DoD)

Definition of Done adalah kriteria minimum yang harus terpenuhi agar sebuah task dianggap benar-benar selesai. Tanpa DoD yang jelas, "selesai" bisa berarti berbeda bagi setiap anggota tim. Sebuah task dinyatakan Done jika seluruh kondisi berikut terpenuhi:

1. Pekerjaan selesai sesuai kriteria yang disepakati saat Sprint Planning.
2. Sudah di-review oleh minimal satu anggota lain (untuk task teknis: melalui Pull Request).
3. Tidak ada bug kritis atau error yang belum diselesaikan.
4. Artefak hasil pekerjaan (kode, desain, dokumen) sudah tersimpan di repository atau platform resmi.
5. Status task di Kanban Board diperbarui ke kolom Done.
6. Jika task menghasilkan deliverable yang perlu diinformasikan ke Mentor, sudah dikomunikasikan kepada Project Leader. Sebuah project dinyatakan selesai jika:
7. Seluruh deliverable utama yang disepakati dalam Project Brief/PRD sudah diserahkan atau dijelaskan statusnya secara tertulis.
8. Application/produk sudah di-deploy dan dapat diakses (untuk project teknis).
9. Dokumentasi akhir (README, Closure Report, Retrospective) sudah lengkap.
10. Demo Day sudah dilaksanakan.
11. Mentor memberikan sign-off tertulis. Sebuah project dinyatakan gagal atau dibatalkan jika:
12. Project tidak mencapai minimal satu dari kriteria di atas setelah melewati batas waktu yang telah ditetapkan dalam PRD/Project Brief.
13. Seluruh anggota kelompok mengundurkan diri atau dinyatakan tidak aktif secara permanen.
14. Mentor dan Divisi Product & Project Management sepakat bahwa project tidak dapat dilanjutkan karena alasan teknis atau operasional yang fundamental. Prosedur Penutupan Project Gagal/Batal:
15. Project Leader atau Divisi Product & Project Management mengajukan dokumen penutupan (Closure Report) yang menjelaskan alasan kegagalan atau pembatalan.
16. Mentor memberikan evaluasi tertulis terhadap seluruh anggota kelompok.
17. Divisi Product & Project Management mencatat hasil evaluasi untuk keperluan penilaian Level anggota.
18. Kanban Board dan seluruh dokumentasi project diarsipkan.

---

6. Alur Kerja Project (Project Workflow)

Fase	Deskripsi Aktivitas Utama	Target Output & Milestone
Foundation (Persiapan)	Anggota kelompok mempelajari konsep dasar dan tools standar (Git flow, Figma, project setup) di bawah arahan Project Leader; Mentor memberikan pembekalan materi.	Kesiapan teknis seluruh anggota tim terverifikasi.
Problem Discovery (Observasi)	Tim menerima tema dari Mentor yang ditetapkan bersama Divisi Product & Project Management, lalu melakukan observasi lapangan untuk menemukan masalah nyata yang akan diselesaikan. Output wajib: Problem Discovery Document.	Problem Discovery Document selesai dan siap dijadikan dasar penyusunan PRD.
Planning & Pitching (Perencanaan)	Tim menyusun PRD dan Wireframe berdasarkan hasil observasi. Pitching dilakukan di depan Mentor sebagai simulasi komunikasi profesional ke client (Q&A Challenge).	Proposal disetujui Mentor, desain Figma handoff, repositori dibuat, dan Kanban Board siap.
Execution & QA (Pengerjaan)	Pengerjaan task secara fokus. Project Leader memimpin sinkronisasi berkala. Developer menulis kode dengan Pull Request & Code Review. Deployment berkala ke staging server untuk pengujian bersama.	Application berfungsi penuh di server staging dan bebas dari bug kritis.
Release & Closing (Rilis & Evaluasi)	User Acceptance Testing (UAT) oleh Mentor. Deployment aplikasi ke server produksi. Presentasi demo produk akhir (Demo Day). Penyelesaian dokumentasi dan evaluasi tim (Retrospective).	Application online (live), dokumentasi lengkap, presentasi demo selesai, dan catatan retrospektif terisi.

Detail Penjelasan Fase Kerja:

Catatan: Tabel di atas menampilkan 5 fase. Pada penjelasan detail di bawah, Problem Discovery digabung sebagai Sub-Fase 2A dalam Fase Planning & Pitching karena keduanya berjalan berurutan dan saling terkait.

1. Fase Foundation (Persiapan & Pembekalan):
   • Member mempelajari tools standar (Git flow, pengenalan Figma, dasar-dasar setup project).
   • Mentor memberikan materi/kuliah fundamental yang dibutuhkan untuk tema/bidang proyek yang berjalan.
   • Divisi PM melakukan pembentukan kelompok dan menunjuk Project Leader.
   • Output: Checkpoint kesiapan teknis seluruh anggota tim.
2. Fase Planning & Proposal Pitching (Perencanaan & Pembuktian Ide): Fase ini terdiri dari dua sub-fase yang wajib dijalankan secara berurutan: Problem Discovery terlebih dahulu, kemudian Proposal Pitching. Tim tidak diperbolehkan masuk ke tahap pitching sebelum menyelesaikan dan mendokumentasikan hasil observasi mereka. Sub-Fase 2A: Problem Discovery (Observasi & Penemuan Masalah) BPH atau Mentor menetapkan tema project di awal (contoh: Educational Technology, Health & Wellness, Local Business Digitalization). Tim tidak menentukan solusi terlebih dahulu - tim terlebih dahulu terjun ke lapangan untuk memahami masalah nyata yang ada di dalam tema tersebut. Proses yang wajib dijalankan:
   • Observasi lapangan atau riset pengguna: Tim mengamati kondisi nyata, mewawancarai minimal 3 - 5 orang yang relevan dengan tema, atau melakukan survei singkat untuk memahami pain point yang sesungguhnya.
   • Identifikasi masalah: Dari hasil observasi, tim merumuskan satu masalah utama yang paling signifikan, nyata, dan dapat diselesaikan dengan solusi teknologi dalam batasan scope project.
   • Validasi masalah: Tim memastikan masalah yang dipilih benar-benar dialami oleh pengguna nyata, bukan asumsi tim semata.
   • Output wajib: Problem Discovery Document (lihat Template E di Bagian 8). Sub-Fase 2B: Proposal Pitching (Penyusunan & Presentasi Ide) Setelah masalah ditemukan dan didokumentasikan, tim merancang solusi dan mempresentasikannya kepada Mentor.
   • Penyusunan Proposal (PRD Awal & Wireframe UI): Berdasarkan hasil Problem Discovery, tim menyusun draf PRD yang menjelaskan solusi yang diusulkan, fitur MVP, dan wireframe kasar antarmuka.
   • Pitching & Defense Session (Sesi Sidang Proposal): Kelompok mempresentasikan proposal di depan Mentor yang berperan sebagai Client. Tujuan sesi ini bukan sekadar mendapatkan persetujuan - melainkan melatih kemampuan komunikasi profesional: menyampaikan ide secara terstruktur, meyakinkan stakeholder dengan data, dan merespons pertanyaan kritis di bawah tekanan. Ini adalah simulasi nyata dari situasi kerja di industri.
   • Mentor Q&A Challenge: Mentor mengajukan pertanyaan tajam mengenai relevansi solusi terhadap masalah yang ditemukan, urgensi masalah bagi pengguna nyata, kesiapan tim, dan kelayakan MVP dalam timeline yang tersedia. Tim wajib menjawab dengan argumen berbasis data observasi, bukan opini atau asumsi.
   • Revisi & Finalisasi: Setelah mendapat persetujuan Mentor, desainer menuntaskan UI di Figma dan developer menyiapkan struktur database/API. Project Leader memecah fitur menjadi task di Kanban Board.
   • Output: Problem Discovery Document selesai, proposal disetujui Mentor, desain Figma handoff, repositori GitHub dibuat, dan Kanban Board siap.
3. Fase Execution & QA (Pengerjaan & Pengujian):
   • Developer fokus menulis kode sesuai tugas di Kanban Board. Setiap kode baru wajib melalui proses Pull Request (PR) di GitHub dan di-review oleh rekan tim/Tech Lead.
   • Project Leader melakukan sinkronisasi berkala (daily sync/standup) untuk melacak kendala.
   • Di pertengahan fase eksekusi akhir, aplikasi dideploy ke server uji coba (staging).
   • Tim melakukan pengujian aplikasi secara bersama-sama (QA Testing) dan memperbaiki bug yang ditemukan.
   • Output: Application berfungsi penuh di server staging dan bebas dari bug kritis.
4. Fase Release & Closing (Peluncuran & Evaluasi):
   • UAT (User Acceptance Testing): Mentor menguji aplikasi untuk memberikan persetujuan akhir (sign-off).
   • Deployment to Production: Merilis aplikasi ke server publik (misal: Vercel/Netlify).
   • Demo Day: Setiap tim melakukan presentasi demo karya di hadapan Founder, Mentor, dan seluruh anggota ekosistem YYZU.
   • Dokumentasi Akhir: Melengkapi dokumentasi repositori README dan mempublikasikan artikel portofolio.
   • Sprint Retrospective: Seluruh tim berkumpul untuk melakukan evaluasi kerja kelompok menggunakan template retro.
   • Output: Application online, dokumentasi lengkap, dan sesi retrospektif selesai.

---

7. Standardisasi Tools Kolaborasi Ekosistem YYZU

Untuk mendukung kolaborasi yang efisien dan menyimulasikan alur kerja industri nyata secara optimal, seluruh tim project YYZU wajib menggunakan perkakas (tools) digital standar berikut:

• GitHub: Repositori kode utama, review pull request (PR), dan pengelolaan codebase terintegrasi. Seluruh kontributor teknis wajib menggunakan workflow branch YYZU.
• Figma: Workspace desain antarmuka (UI/UX) kolaboratif, penerapan design system YYZU, prototyping interaktif, dan serah terima (handoff) aset desain ke tim developer.
• Discord / Slack: Saluran komunikasi utama ekosistem. Digunakan untuk sinkronisasi harian (asinkron), diskusi divisi, mentoring live, serta koordinasi insidental.
• Linear / Trello / Jira / ClickUp / Notion Board: Manajemen tugas berbasis Kanban Board untuk memantau status pengerjaan yang dikelola oleh Project Leader kelompok secara berkala. Kolom minimal yang harus ada:
  • Backlog: Ide fitur masa depan / di luar scope MVP.
  • To Do: Fitur MVP yang siap dikerjakan pada sprint berjalan.
  • In Progress: Fitur yang sedang dikerjakan developer.
  • In Review: Fitur yang telah selesai dikoding dan sedang dalam proses Pull Request/code review.
  • Done: Fitur yang telah lolos review dan diintegrasikan ke codebase utama.

---

8. Standardisasi Dokumentasi Proyek

Setiap tim wajib mematuhi standar dokumentasi berikut untuk menjaga kualitas portofolio publik dan keberlanjutan kode:

E. Template Problem Discovery Document - Diisi pada Sub-Fase 2A (Wajib untuk Mini Project & Collaborative Project)

Catatan: Template diberi label A-E berdasarkan urutan kronologis dalam siklus project, bukan urutan abjat. Template E (Problem Discovery) digunakan paling awal, diikuti A (PRD), B (README), C (Dokumentasi Publik), dan D (Retrospektif).

# [Nama Tim] - Problem Discovery Document

## 1. Tema Project yang Ditetapkan
Tuliskan tema yang diberikan oleh BPH/Mentor.
- Contoh: Educational Technology

## 2. Proses Observasi
Jelaskan metode yang digunakan tim untuk memahami masalah.
- Metode: [Wawancara / Survei / Observasi Langsung / Riset Literatur]
- Jumlah responden/sumber: [angka]
- Waktu pelaksanaan: [tanggal]

## 3. Temuan Utama
Ringkaskan apa yang tim temukan dari observasi. Gunakan data dan fakta, bukan opini.
- Temuan 1: ...
- Temuan 2: ...
- Temuan 3: ...

## 4. Masalah yang Dipilih
Rumuskan satu masalah utama yang akan diselesaikan. Gunakan format:
"[Kelompok pengguna] mengalami [masalah spesifik] ketika [konteks situasi], yang mengakibatkan [dampak nyata]."

## 5. Alasan Pemilihan Masalah
Jelaskan mengapa masalah ini diprioritaskan dibanding temuan lain.
- Seberapa sering masalah ini terjadi?
- Seberapa besar dampaknya bagi pengguna?
- Apakah teknologi dapat menjadi solusi yang realistis?

## 6. Solusi Awal yang Diusulkan (Hipotesis)
Tuliskan solusi awal tim sebelum PRD dibuat. Ini bersifat hipotesis dan masih bisa berubah.
- Solusi yang diusulkan: ...
- Asumsi utama yang perlu divalidasi: ...

---

A. Template PRD (Product Requirement Document) - Diisi di Notion pada Fase Planning

# [Nama Proyek] - PRD

## 0. Referensi Problem Discovery
- Link Problem Discovery Document: [Tautan ke Notion]
- Masalah yang diselesaikan: [salin rumusan masalah dari Problem Discovery Document]

## 1. Latar Belakang (The Why)
Jelaskan masalah nyata yang ditemukan dari observasi dan mengapa solusi teknologi dibutuhkan.

## 2. Solusi & MVP Scope (The What)
Tuliskan fitur-fitur minimal yang WAJIB ada di proyek ini agar aplikasi bisa berfungsi.
- [Contoh] Fitur Login & Registrasi.
- [Contoh] Fitur Dashboard Transaksi.

## 3. Batasan Proyek (Out of Scope)
Tulis fitur yang TIDAK dibuat pada fase ini demi menjaga timeline pengerjaan.
- [Contoh] Fitur pembayaran otomatis via e-wallet (dimasukkan ke backlog).

## 4. Tautan Penting
- Link Figma: [Tautan ke Figma]
- Link GitHub: [Tautan ke Repositori]

B. Template README Repositori - Wajib di GitHub pada Fase Release

Catatan: Template ini bersifat generik dan wajib disesuaikan dengan tech stack aktual yang digunakan tim. Contoh-contoh di bawah hanya ilustratif - tim bebas memilih tools, bahasa, framework, dan platform deployment yang paling sesuai dengan kebutuhan dan kompetensi mereka, sepanjang pilihan tersebut dapat dipertanggungjawabkan dalam review Mentor.

# [Nama Aplikasi]

Aplikasi ini dibuat dalam program kolaborasi proyek YYZU (Tema: [Nama Tema Proyek]).

## Tech Stack
- Frontend: [isi dengan framework/library yang digunakan, misal: React, Vue, Svelte, plain HTML/CSS]
- Backend: [isi dengan runtime/framework yang digunakan, misal: Express, FastAPI, Laravel, atau serverless function]
- Database: [isi dengan database yang digunakan, misal: PostgreSQL, MySQL, SQLite, MongoDB]
- Deployment: [isi dengan platform yang digunakan, misal: Railway, Render, Fly.io, VPS, dsb.]

## Cara Menjalankan Proyek Secara Lokal (Local Setup)
1. Clone repositori ini: `git clone [link-repo]`
2. Install dependensi: [sesuaikan dengan package manager yang digunakan]
3. Konfigurasi environment: salin file `.env.example` menjadi `.env` dan isi variabel yang dibutuhkan
4. Setup database: [sesuaikan dengan ORM atau migration tool yang digunakan]
5. Jalankan server lokal: [sesuaikan dengan perintah start project]

## Kontak & Kontributor
- [Nama Project Leader] (Role: Project Leader / [Track]) - [Username GitHub]
- [Nama Member] (Role: [Track]) - [Username GitHub]

C. Dokumentasi Publik ( LinkedIn / Notion Showcase ) - Fase Release

Setiap tim wajib membuat ringkasan proyek yang ramah dibaca masyarakat umum dengan format:

1. Screenshot / GIF Demo: Menampilkan cuplikan aplikasi yang berjalan.
2. Cerita Singkat Perjalanan Tim: Penjelasan tantangan tim selama pengerjaan dan bagaimana cara mereka mengatasinya bersama.
3. Link Demo Online: URL aplikasi aktif agar pembaca bisa mencoba langsung.

D. Catatan Retrospektif (Retrospective Notes) - Diisi Bersama pada Fase Release

Setiap tim wajib mendokumentasikan hasil evaluasi internal mereka dengan format:

# Catatan Retrospektif - Tim [Nama Tim]

## 1. What Went Well (Apa yang berjalan dengan sangat baik?)
Tuliskan keberhasilan tim yang harus dipertahankan.
- [Contoh] Komunikasi antar frontend dan backend sangat lancar menggunakan API contract.

## 2. What Went Wrong / Bottlenecks (Kendala apa saja yang dialami?)
Tuliskan hambatan teknis atau komunikasi yang mengganggu jalannya proyek.
- [Contoh] Estimasi pengerjaan fitur login terlalu singkat sehingga memakan waktu QA.

## 3. Action Items (Apa perbaikan konkret untuk proyek berikutnya?)
Tindakan nyata untuk mengatasi kekurangan di masa depan.
- [Contoh] Menyediakan waktu buffer 1 hari khusus untuk integrasi API di awal.

---

9. Kategori & Karakteristik Project

Di ekosistem YYZU, pengerjaan project dikelompokkan ke dalam lima kategori utama berdasarkan skala, durasi, dan tujuan belajarnya. Seluruh tim project wajib mengikuti karakteristik operasional berikut:

9.1 Mini Project

Mini Project adalah project pertama yang dijalankan member YYZU. Tim kecil (4 orang, bisa 1 track saja) bekerja selama 6 minggu untuk membangun solusi teknologi sederhana terhadap masalah nyata dalam tema yang ditetapkan Mentor. Alur singkat: Mentor menetapkan tema → tim riset masalah dalam tema tersebut → pitching ide ke Mentor → bangun solusi dalam 2 sprint → review dan dokumentasi. Yang membedakan dari Collaborative Project:

• Tim bisa 1 track saja (tidak wajib lintas track)
• Scope sederhana (CRUD, landing page, API sederhana)
• 6 minggu (bukan 8-12)
• Mentor sebagai reviewer (bukan Client aktif)
• Tidak ada Q&A Challenge
• Durasi Siklus: 6 Minggu
• Pembagian Fase & Linimasa: | Fase Pengerjaan | Durasi | Milestone Penting | Fokus Eksekusi | | --- | --- | --- | --- | | Learning / Foundation | 2 Minggu | Checkpoint Kesiapan Teknis | Anggota mempelajari tools/konsep dasar yang spesifik untuk project | | Problem Discovery | Bagian dari minggu ke-3 | Problem Discovery Document selesai | Tim menerima tema, observasi lapangan/riset pengguna, identifikasi masalah, dan menyusun Problem Discovery Document sebelum masuk ke planning | | Project Planning & Pitching | Sisa minggu ke-3 | Persetujuan Proposal oleh Mentor | Menyusun PRD berdasarkan hasil discovery, Wireframe awal, pitching ke Mentor, pembagian task, dan setup Kanban Board | | Project Execution | 2 Minggu | Checkpoint Progres Tengah Proyek | Eksekusi pengerjaan, koordinasi harian dipimpin Project Leader, integrasi komponen | | Review & Revision | 1 Minggu | Demo Presentasi & Final Delivery | Demo hasil project ke mentor, pencatatan feedback, perbaikan minor, dan penyusunan dokumentasi |
• Batasan & Contoh Scope: Project harus dirancang sesederhana mungkin agar realistis dapat diselesaikan penuh dalam 6 minggu. Contoh scope yang sesuai:
  • Landing page responsif sederhana.
  • Aplikasi CRUD sederhana (misalnya Todo App, Tracker Pengeluaran Sederhana).
  • Redesain UI 3-5 halaman aplikasi dengan Figma.
  • API endpoint sederhana dengan dokumentasi API (Postman/Swagger).
  • Purwarupa (prototype) mobile interaktif dasar.
  • Website dokumentasi statis sederhana. Mini Project bukan tempat untuk membangun sistem berskala enterprise, arsitektur microservices, atau produk dengan proses bisnis yang rumit.

Contoh Mini Project: "Tracker Pengeluaran Mahasiswa"

Tema dari Mentor: "Pendidikan" Tim: 4 orang, semua track Web Development

• Rizal (Project Leader)
• Sari
• Tono
• Ulya

Fase 1: Foundation (Minggu 1-2)

• Rizal ditunjuk sebagai Project Leader
• Tim belajar tools dasar: Git, Figma, Next.js
• Mentor memberikan pembekalan: "Mahasiswa sering kesulitan mengelola uang selama kuliah"
• Tim setup repo GitHub dan Kanban Board

Fase 2: Problem Discovery & Planning (Minggu 3)

Problem Discovery:

• Tim wawancara 5 mahasiswa di kampus
• Temuan: "Mahasiswa tidak tahu uangnya habis ke mana, tidak ada catatan rutin, dan baru sadar sudah habis di akhir bulan"
• Tim menulis Problem Discovery Document Planning & Pitching:
• Tim menyusun PRD sederhana:
  • Fitur 1: Catat pengeluaran harian
  • Fitur 2: Dashboard ringkasan per kategori
  • Fitur 3: Alert jika pengeluaran mendekati batas
• Tim membuat wireframe di Figma
• Tim pitching ke Mentor: "Kami mau bangun tracker karena..."
• Mentor: "Oke, scope-nya realistis. Lanjutkan."
• Rizal pecah task ke Kanban Board

Fase 3: Eksekusi (Minggu 4-5)

Sprint 1 (Minggu 4):

• Rizal: setup database + API
• Sari: buat halaman input pengeluaran
• Tono: buat dashboard ringkasan
• Ulya: desain UI di Figma
• Daily Sync setiap hari 15 menit
• Sprint Review: API jalan, input bisa disimpan Sprint 2 (Minggu 5):
• Integrasi semua komponen
• Tambah fitur alert
• Fix bug
• Sprint Review: aplikasi berfungsi penuh

Fase 4: Review & Closing (Minggu 6)

• Demo ke Mentor: "Ini hasilnya, bisa catat pengeluaran dan lihat ringkasan"
• Mentor feedback: "Bagus, tapi input-nya perlu validasi angka"
• Tim fix minor issue
• Deploy ke Vercel
• Tulis README
• Retrospective: "Komunikasi lancar, tapi estimasi API terlalu optimis" Output: Aplikasi live, 4 anggota punya portofolio pertama

9.2 Collaborative Project

Collaborative Project adalah simulasi kerja tim profesional di industri teknologi. Tim lintas track (Developer, UI/UX Designer, Product Manager) bekerja bersama selama 10 minggu untuk membangun produk digital yang menyelesaikan masalah nyata, menggunakan workflow standar industri (Scrumban, Git, Figma, Code Review). Alur singkat: Tim menerima tema → riset masalah di lapangan → pitching ide ke Mentor (sebagai Client) → bangun produk dalam sprint 2 mingguan → testing → Demo Day → dokumentasi portofolio. Yang membedakan dari Mini Project:

• Tim wajib lintas track (Dev + UI/UX + PM)
• Ada fase Problem Discovery sebelum coding
• Mentor berperan sebagai Client + Instructor (bukan hanya reviewer)
• Ada Q&A Challenge saat pitching
• Standar lebih ketat: PR wajib, code review wajib, testing wajib
• Tujuan Utama: Melatih kolaborasi lintas peran, penerapan workflow Git modern (pull request, review code), desain sistem UI terintegrasi, manajemen tugas dengan Kanban Board, pengujian perangkat lunak, serta penyusunan dokumentasi teknis yang profesional.
• Durasi Siklus: 10 Minggu
• Linimasa Fase Pengerjaan:
  • Fase 1: Preparation & Team Setup (1 Minggu): Pembentukan tim, pengenalan anggota, penyelarasan cara kerja, penyediaan repositori git, dan setup workspace desain/project management.
  • Fase 2: Problem Discovery & Planning (2 Minggu): Tim melakukan validasi masalah berdasarkan tema yang ditetapkan Mentor, kemudian menerjemahkan temuan tersebut menjadi User Stories, Product Requirement Document (PRD) sederhana, Wireframe UI, dan skema database. Proses pitching kepada Mentor tetap wajib dilakukan sebelum eksekusi dimulai.
  • Fase 3: Development Sprint (4 Minggu): Siklus pengerjaan fitur secara iteratif melalui sprints (2 mingguan), koordinasi dipimpin Project Leader, dan pengawasan kualitas oleh divisi Product & Project Management.
  • Fase 4: Testing & Review (1 Minggu): Pengujian sistem terintegrasi, perbaikan bug (bug fixing), validasi kegunaan (usability testing), dan peninjauan teknis/desain oleh mentor.
  • Fase 5: Final Demo & Documentation (2 Minggu): Rilis produk akhir, demo pleno di hadapan mentor/ekosistem, penyerahan dokumentasi teknis lengkap, dan retro kelompok.

9.3 Internal Project

Internal Project adalah project pengembangan platform, infrastruktur, atau aplikasi penunjang operasional internal YYZU Community yang dikerjakan secara berkelompok oleh member terpilih.

• Tujuan Utama: Membangun solusi nyata untuk kebutuhan riil YYZU (seperti dashboard keanggotaan, portal materi belajar, website profil utama) sambil memberikan member pengalaman membangun produk nyata yang digunakan pengguna asli.
• Durasi Siklus: 2 hingga 3 Bulan per Fase (Pengembangan bertahap)
• Estimasi Durasi per Fase: Fase 1-2: 4-6 minggu per fase. Fase 3-4: 6-8 minggu per fase. Fase 5: berkelanjutan (maintenance).
• Fase Pengembangan Bertahap (Iterative Roadmap):
  • Fase 1 (MVP awal): Pembuatan Landing Page Utama YYZU dan portal pendaftaran.
  • Fase 2 (Showcase): Penambahan galeri karya proyek member (Showcase Portal).
  • Fase 3 (Member Area): Integrasi sistem login dan Dashboard Anggota.
  • Fase 4 (Management): Sistem manajemen admin sederhana untuk BPH.
  • Fase 5 (Maintenance): Pengoptimalan kinerja, pemeliharaan sistem, dan pembaruan berkala.

9.4 Real-World Project Development

Real-World Project Development adalah project yang berasal dari kebutuhan nyata pihak luar (partner industri, UMKM, atau institusi mitra), bukan dari tema internal yang ditetapkan BPH/Mentor. Mentor pada tipe project ini berperan sebagai penghubung ke client asli, bukan sebagai client simulasi.

• Tujuan Utama: Memberikan member pengalaman bekerja dengan client sungguhan: requirement yang berubah berdasarkan kebutuhan bisnis nyata, ekspektasi profesional terhadap kualitas dan tenggat waktu, serta komunikasi langsung dengan stakeholder non-teknis.
• Durasi Siklus: Mengikuti kesepakatan dengan partner, umumnya 8 hingga 16 minggu tergantung skala kebutuhan.
• Perbedaan Kunci dari Collaborative Project:
  • Brief berasal dari partner eksternal, diterjemahkan oleh Divisi PM melalui sesi intake bersama partner sebelum masuk fase Foundation.
  • Perubahan scope mengikuti negosiasi nyata dengan partner (bukan simulasi Q&A Challenge), tetap melalui jalur Divisi PM sesuai Bagian 11.
  • Sign-off akhir membutuhkan persetujuan tertulis dari partner, selain dari Mentor.
• Linimasa Fase Pengerjaan: Mengikuti seluruh Alur Kerja Project di Bagian 6 (Foundation → Problem Discovery & Pitching → Execution & QA → Release & Closing) tanpa modifikasi struktural, dengan dua penyesuaian:
  • Fase Problem Discovery diganti dengan Sesi Intake Partner: Divisi PM dan Project Leader bertemu langsung dengan partner untuk menggali requirement asli, bukan observasi lapangan mandiri.
  • Fase Release & Closing menambahkan Handover ke Partner: dokumentasi akses, kredensial, dan panduan maintenance diserahkan resmi ke partner.
• Eligibilitas: Diprioritaskan untuk member yang sudah menyelesaikan minimal satu Collaborative Project, mengingat tingkat akuntabilitas terhadap pihak eksternal lebih tinggi.
• Project Leader: Project Leader, dengan Divisi PM sebagai jalur komunikasi resmi tunggal ke partner (anggota tim tidak diperkenankan berkomunikasi langsung dengan partner tanpa melalui Divisi PM atau Project Leader).

9.5 Open-Source Contribution

Open-source contribution memiliki karakteristik unik (timeline eksternal, tidak ada Mentor sebagai client, deliverable ditentukan oleh maintainer repo), sehingga aktivitas ini tidak sepenuhnya mengikuti alur Skema PM, namun tetap memerlukan struktur minimal yang terukur.

• Tujuan Utama: Melatih kemampuan membaca codebase orang lain, mengikuti contribution guidelines pihak eksternal, dan membangun portofolio kontribusi publik yang terverifikasi.
• Durasi Siklus: Tidak tetap, bergantung pada kompleksitas issue yang dipilih, direkomendasikan 2 hingga 6 minggu per kontribusi.
• Linimasa & Struktur Minimal: | Fase | Durasi Indikatif | Aktivitas | Output | | --- | --- | --- | --- | | Eligibilitas & Pendaftaran | Sebelum mulai | Member memastikan diri sudah menyelesaikan minimal satu Mini Project atau Collaborative Project, lalu mengajukan intent ke Divisi PM: repo target, issue yang dipilih, estimasi waktu. | Intent kontribusi disetujui Divisi PM | | Familiarisasi Repo | 2-4 hari di awal | Membaca contribution guidelines, code style, dan riwayat PR terkait issue yang dipilih. | Pemahaman dasar struktur repo | | Pengerjaan & Monitoring | Sisa durasi kontribusi | Member mengerjakan perubahan, melaporkan progres ke Divisi PM setiap dua minggu. | Progress report berkala | | Submisi & Review | Mengikuti timeline maintainer | PR diajukan ke repo asli, menunggu review dari maintainer eksternal (di luar kendali YYZU). | PR merged, ditolak, atau diminta revisi | | Penutupan & Refleksi | Setelah PR final diputuskan | Member menyusun ringkasan learning, terlepas dari hasil PR merged atau ditolak. | Link PR/commit + ringkasan learning |
• Project Leader: Project Leader (jika dilakukan sebagai tim kecil) atau member itu sendiri (jika mandiri), dengan Mentor sebagai advisor opsional.
• Catatan: Karena maintainer eksternal tidak terikat pada timeline YYZU, kontribusi yang belum di-review dalam waktu lama tetap dianggap berjalan (in progress) selama member terus melaporkan status, bukan otomatis dianggap gagal.

---

9.6 Klasifikasi Aktivitas Ekosistem (Non-Project & Project)

Bagian 9.1-9.5 di atas mendefinisikan karakteristik tiap jenis project (Mini Project, Collaborative Project, Internal Project, Real-World Project Development, Open-Source Contribution) sebagai salah satu jenis aktivitas dalam ekosistem YYZU. Namun tidak seluruh aktivitas YYZU berbentuk project. Bagian ini memetakan seluruh 16 tipe aktivitas ekosistem YYZU, baik yang non-project maupun project-based, ke dalam tiga klaster, sehingga jelas aktivitas mana yang wajib mengikuti Skema PM ini secara penuh dan mana yang tidak.

9.6.1 Tiga Klaster Aktivitas

Klaster	Sifat	Contoh Aktivitas
A: Learning & Sharing	Non-project, berbasis pengetahuan	Study group, mentoring session, workshop, technical discussion, product discussion, industry sharing, career preparation
B: Review & Simulation	Non-project, berbasis praktik terbatas	Code review, design review, portfolio review, workflow simulation
C: Project-Based	Berbasis deliverable dan eksekusi tim	Mini project, collaborative project, internal product development, real-world project development, open-source contribution

9.6.2 Klaster A: Learning & Sharing

Aktivitas di klaster ini bersifat non-project: tidak menghasilkan deliverable teknis, tidak membutuhkan Kanban Board atau sprint, dan tidak dijalankan dengan Skema Project Management ini. A1. Study Group

• Deskripsi: Sesi belajar bersama yang difasilitasi oleh anggota ekosistem, fokus pada topik tertentu sesuai track (Web Dev, UI/UX, PM, dll).
• Format: 60-120 menit, dipimpin satu fasilitator (bisa member), bisa sinkron atau asinkron.
• Output wajib: Catatan ringkasan sesi (summary notes) disimpan di Notion.
• PIC: Divisi yang relevan (misal: Divisi Web Dev menyelenggarakan study group React).
• Frekuensi: Sesuai kebutuhan batch atau inisiatif divisi. A2. Mentoring Session
• Deskripsi: Sesi bimbingan antara Mentor dengan member atau kelompok kecil, bersifat personal dan tematik.
• Format: 30-90 menit, bisa 1-on-1 atau kelompok kecil (≤5 orang).
• Output wajib: Action items yang disepakati, dicatat oleh member yang dibimbing.
• PIC: Divisi Divisi SDM (koordinasi jadwal Mentor).
• Catatan: Mentoring session dalam konteks project diatur oleh Skema Project Management ini. Mentoring Session bersifat opsional dan bisa dilaksanakan kapan saja sesuai kebutuhan, bukan event wajib batch. A3. Workshop
• Deskripsi: Sesi hands-on terstruktur dengan instruktur, fokus pada penguasaan tool atau konsep tertentu dalam satu waktu.
• Format: 2-4 jam, memiliki materi tertulis atau slide, disertai latihan praktis.
• Output wajib: Materi workshop diarsipkan di Notion. Peserta mengumpulkan hasil latihan.
• PIC: Divisi penyelenggara atau Mentor yang menjadi instruktur.
• Catatan: Workshop yang merupakan bagian dari Fase Foundation suatu project tetap diatur oleh Skema PM ini (lihat Bagian 6). A4. Technical Discussion
• Deskripsi: Diskusi teknis terfokus antara anggota ekosistem mengenai topik, teknologi, atau pendekatan tertentu. Bukan dalam konteks project yang sedang berjalan.
• Format: 30 - 60 menit, bisa sinkron (Discord/meet) atau asinkron (thread Discord).
• Output wajib: Ringkasan diskusi dan kesimpulan utama dicatat di Notion atau thread Discord yang dapat diakses ulang.
• PIC: Inisiator diskusi bertanggung jawab membuat ringkasan.
• Catatan: Technical Discussion berbeda dari Workshop (A3). Workshop bersifat hands-on dengan instruktur (hingga 2 jam lebih), sedangkan Technical Discussion bersifat diskusi dan eksplorasi ide (30 - 60 menit). Keduanya dipertahankan sebagai event terpisah karena:
  1. Fase berbeda: Technical Discussion cocok untuk Discovery phase (eksplorasi masalah), Workshop cocok untuk Execution phase (belajar tools)
  2. Durasi berbeda: Technical Discussion lebih pendek (30-60 menit), Workshop lebih panjang (hingga 2 jam lebih)
  3. Output berbeda: Technical Discussion menghasilkan ringkasan diskusi, Workshop menghasilkan materi + latihan
  4. Fleksibilitas: Technical Discussion bisa dipimpin oleh member, Workshop biasanya oleh expert Kapan menggunakan Technical Discussion vs Workshop: | Situasi | Gunakan | Alasan | | --- | --- | --- | | Eksplorasi ide, brainstorming | Technical Discussion | Format diskusi, durasi pendek | | Problem-solving teknis | Technical Discussion | Fokus pada solusi, bukan praktik | | Belajar tools baru | Workshop | Butuh hands-on dan instruktur | | Praktik langsung | Workshop | Butuh waktu lebih lama untuk latihan | A5. Product Discussion
• Deskripsi: Diskusi berfokus pada product thinking: validasi ide, analisis use case, product strategy, atau fitur suatu produk digital. Berbeda dari Technical Discussion karena perspektifnya adalah produk, bukan implementasi teknis.
• Format: 30-60 menit, bisa melibatkan lintas track (Dev, Design, PM).
• Output wajib: Ringkasan diskusi beserta keputusan atau insight utama.
• PIC: Inisiator atau Divisi Product & Project Management. A6. Industry Sharing
• Deskripsi: Sesi berbagi pengalaman dari praktisi industri (guest, Mentor, atau alumni), berupa cerita karier, insight dunia kerja, atau tren teknologi terkini.
• Format: 60-90 menit. Bisa berupa talk, panel diskusi, atau Q&A session.
• Output wajib: Ringkasan poin penting disimpan di Notion. Rekaman sesi (jika ada) diarsipkan.
• PIC: Divisi yang relevan atau BPH sebagai penyelenggara.
• Catatan: Pembicara eksternal harus dikoordinasikan dengan Founder/BPH terlebih dahulu. A7. Career Preparation
• Deskripsi: Aktivitas yang mempersiapkan member untuk memasuki dunia kerja: CV review, mock interview, portfolio critique, atau sesi career roadmap.
• Format: Bervariasi. Bisa 1-on-1 (CV/portfolio review: 20-30 menit) atau sesi kelompok (mock interview: 60-90 menit).
• Output wajib: Feedback tertulis yang diserahkan kepada member yang direview.
• PIC: Divisi Divisi SDM, berkoordinasi dengan Mentor jika diperlukan.

9.6.3 Klaster B: Review & Simulation

Aktivitas di klaster ini bersifat praktik terbatas: menggunakan artefak nyata (kode, desain, portofolio) sebagai bahan, tetapi tidak dalam konteks sprint atau project yang sedang berjalan secara penuh. B1. Code Review (Standalone)

• Deskripsi: Review kualitas kode yang dilakukan di luar konteks project aktif. Bisa menggunakan kode pribadi member, kode lama, atau kode latihan.
• Format: Async (via GitHub PR atau thread) atau sync (screen sharing, 30-60 menit).
• Output wajib: Catatan feedback reviewer, disimpan di thread atau Notion.
• PIC: Reviewer (Mentor atau senior member).
• Catatan: Code Review dalam konteks project aktif diatur oleh Skema PM ini (Fase Execution & QA, Bagian 6). B2. Design Review (Standalone)
• Deskripsi: Review terhadap desain UI/UX yang dilakukan di luar konteks project aktif.
• Format: Async (via komentar Figma) atau sync (screen sharing, 30-60 menit).
• Output wajib: Catatan feedback di Figma atau Notion.
• PIC: Reviewer (Mentor atau senior member dengan track UI/UX).
• Catatan: Design Review dalam konteks project aktif diatur oleh Skema PM ini. B3. Portfolio Review
• Deskripsi: Review menyeluruh terhadap portfolio member: website portfolio, GitHub profile, atau kumpulan project yang disiapkan untuk keperluan rekrutmen atau showcase.
• Format: 30-45 menit per member, bisa dilakukan secara batch (review bersama beberapa member sekaligus).
• Output wajib: Feedback tertulis yang memuat: apa yang sudah baik, apa yang perlu diperbaiki, dan prioritas perbaikan.
• PIC: Divisi Divisi SDM atau Mentor. B4. Workflow Simulation
• Deskripsi: Simulasi proses kerja industri dalam format yang terkontrol dan terbatas waktu. Contoh: simulasi sprint planning, simulasi code review process, simulasi pitching ke client.
• Format: 60-120 menit per sesi, dengan skenario yang disiapkan oleh fasilitator sebelumnya.
• Output wajib: Debrief session setelah simulasi: apa yang berjalan baik, apa yang perlu diperbaiki.
• PIC: Divisi Product & Project Management (untuk simulasi project workflow) atau Divisi yang relevan.
• Catatan: Workflow Simulation yang merupakan bagian dari Fase Foundation suatu project tetap diatur oleh Skema PM ini.

9.6.4 Klaster C: Project-Based

Aktivitas di klaster ini mengikuti Skema Project Management ini sebagai framework eksekusi utama. Seluruh lima tipe project sudah memiliki bagian operasional lengkap masing-masing di Bagian 9.1-9.5:

Tipe Project	Definisi Singkat	Referensi Detail
Mini Project	Project kecil 6 minggu untuk melatih fundamental dan basic collaboration	Bagian 9.1
Collaborative Project	Project menengah 10 minggu, lintas disiplin, standar workflow industri	Bagian 9.2
Internal Product Development	Pengembangan platform/infrastruktur internal YYZU, bertahap	Bagian 9.3
Real-World Project Development	Project dari kebutuhan pihak luar (partner/industri), mengikuti alur project penuh dengan dua penyesuaian fase	Bagian 9.4
Open-Source Contribution	Kontribusi ke proyek open-source publik, dikerjakan mandiri atau sebagai tim kecil	Bagian 9.5

9.6.5 Matriks Referensi Cepat

Aktivitas	Klaster	Butuh Skema PM Penuh?	PIC Default	Output Wajib
Study Group	A	Tidak	Divisi relevan	Summary notes di Notion
Mentoring Session	A	Tidak	Divisi SDM	Action items
Workshop	A	Tidak (Kecuali bagian Foundation)	Divisi/Mentor	Materi arsip + hasil latihan
Technical Discussion	A	Tidak	Inisiator	Ringkasan diskusi
Product Discussion	A	Tidak	Inisiator / Divisi PM	Ringkasan + keputusan
Industry Sharing	A	Tidak	BPH / Divisi	Ringkasan + arsip rekaman
Career Preparation	A	Tidak	Divisi SDM	Feedback tertulis
Code Review (standalone)	B	Tidak	Reviewer	Catatan feedback
Design Review (standalone)	B	Tidak	Reviewer	Catatan feedback Figma/Notion
Portfolio Review	B	Tidak	Divisi SDM / Mentor	Feedback tertulis
Workflow Simulation	B	Tidak (Kecuali bagian Foundation)	Divisi PM	Debrief notes
Mini Project	C	Iya	Project Leader	Sesuai Bagian 9.1
Collaborative Project	C	Iya	Project Leader	Sesuai Bagian 9.2
Internal Product Development	C	Iya	Project Leader	Sesuai Bagian 9.3
Real-World Project Development	C	Iya	Project Leader	Sesuai Bagian 9.4
Open-Source Contribution	C	Parsial	Project Leader + Mentor advisor	Sesuai Bagian 9.5

---

10. KPI Framework

KPI Umum

KPI berikut berlaku untuk seluruh project dan dinilai pada level kelompok. Skor KPI:

• Hijau: Sesuai target atau di atas standar
• Kuning: Perlu perhatian, masih dalam batas wajar
• Merah: Di bawah standar, perlu tindak lanjut | Kategori | Yang Diukur | Threshold | Penilai | | --- | --- | --- | --- | | Delivery | Ketepatan waktu dan kelengkapan scope sesuai timeline planning | Hijau: tepat waktu. Kuning: maks 2 hari terlambat. Merah: lebih dari 2 hari terlambat. | Project Leader melaporkan, Divisi PM memverifikasi | | Quality | Standar teknis atau desain sesuai best practice | Hijau: sesuai standar. Kuning: minor issues. Merah: major issues. | Mentor (peran instructor) | | Client Acceptance | Brief terpenuhi sesuai requirement awal | Hijau: diterima tanpa revisi. Kuning: revisi minor. Merah: revisi mayor/ditolak. | Mentor (peran client) | | Process | Partisipasi anggota, dokumentasi, dan demo | Hijau: seluruh proses terlaksana. Kuning: 1-2 item terlewat. Merah: lebih dari 2 item terlewat. | Project Leader dan Divisi PM | | Member Growth | Bukti pendukung transisi Level individu | Hijau: ada bukti kemajuan. Kuning: kemajuan minimal. Merah: tidak ada bukti kemajuan. | Mentor dan Divisi SDM |

Template KPI Spesifik

Elemen berikut ditentukan ulang pada setiap project, disepakati bersama oleh Mentor dan Divisi Product & Project Management pada tahap Planning, dan tidak memerlukan revisi terhadap dokumen framework ini.

Elemen	Sumber/Cara Menentukan
Output yang diharapkan	Diturunkan dari brief Mentor selaku client pada fase Planning
Kriteria Quality Check	Diturunkan dari standar teknis bidang project, disepakati bersama Mentor selaku instructor
Kriteria Client Acceptance	Disusun dalam bentuk pertanyaan dari sudut pandang pemilik produk, misalnya: "Apakah deliverable ini siap digunakan atau dilanjutkan?"

Dependency Antar Project

Apabila terdapat project lanjutan yang bergantung pada output project sebelumnya, perlu ditetapkan minimum deliverable dari project sebelumnya yang wajib selesai sebelum project lanjutan dapat dimulai, sehingga project lanjutan tidak perlu menunggu project sebelumnya selesai secara keseluruhan. Detail minimum deliverable ditentukan berdasarkan kasus masing-masing, bukan ditetapkan secara baku pada framework ini.

Evaluasi Level Peran

Peran	Dievaluasi Dari
Project Leader	Delivery dan process pada kelompoknya sendiri
Divisi Product & Project Management	Konsistensi koordinasi lintas kelompok, akurasi translasi brief Mentor, serta ketepatan dalam mendeteksi gap sebelum eksekusi berjalan

---

11. Batasan & Eskalasi

Isu	Diselesaikan pada Level	Eskalasi Apabila Tidak Selesai
Task harian dalam kelompok	Project Leader	Divisi Product & Project Management
Gap antara brief Mentor dan realita timeline/kapasitas	Divisi Product & Project Management berkoordinasi dengan Mentor, sebelum planning ditutup	Mentor dan Founder YYZU
Konflik internal kelompok	Project Leader	Divisi Product & Project Management, diteruskan ke Divisi SDM apabila bersifat serius
Perubahan scope di tengah eksekusi	Tidak diizinkan secara langsung pada level Project Leader maupun anggota	Harus melalui Divisi Product & Project Management untuk di-negosiasikan kepada Mentor

Jalur Eskalasi Resmi (Escalation Path)

Anggota Kelompok → Project Leader Kelompok → PM Core Division → Mentor & Founder

• Level 1: Anggota Kelompok → Project Leader (diskusi harian)
• Level 2: Project Leader → PM Core Division (kendala berat)
• Level 3: PM Core Division → Mentor & Founder (eskalasi akhir)

---

12. Kebijakan Kontribusi Aktif & Penanganan Anggota Pasif (Inaktivitas Operasional)

Keaktifan dan kontribusi nyata dalam pengerjaan proyek adalah prasyarat mutlak untuk mempertahankan status keanggotaan dan memperoleh sertifikat kelulusan batch. Sanksi administratif dan alur pembinaan anggota yang pasif diatur secara sah merujuk pada Anggaran Rumah Tangga (ART) YYZU.

Catatan Penting: Kebijakan ini mengatur inaktivitas operasional dalam project (batas waktu sebelum teguran diberikan kepada anggota yang tidak aktif dalam project). Untuk kebijakan inaktivitas keanggotaan formal (status keanggotaan secara keseluruhan), lihat ART Pasal 10 - Keanggotaan Tidak Aktif (30 hari).

Prosedur Pembinaan & Surat Peringatan (SP)

Catatan: Prosedur ini khusus untuk penanganan anggota pasif/kurang aktif di tingkat operasional project. Untuk pelanggaran disiplin (nilai, kode etik, dan sejenisnya), berlaku prosedur SP tersendiri sesuai ART YYZU Pasal 9 yang dikeluarkan oleh Divisi Divisi SDM. Untuk menjaga keadilan kontribusi dalam tim, alur penegakan sanksi kontribusi aktif di tingkat operasional project adalah sebagai berikut:

1. Teguran Internal (Lisan/Tertulis): Jika seorang anggota tidak aktif atau tidak mengerjakan tugas yang disepakati selama 2 hari berturut-turut tanpa alasan sah yang dikomunikasikan sebelumnya, Project Leader kelompok wajib memberikan teguran tertulis langsung di Discord/Slack.

Ketentuan Izin: Anggota dapat mengajukan izin tertulis (cuti/sakit/urusan mendesak) kepada Project Leader minimal 1 hari sebelumnya. Izin yang disetujui Project Leader menghentikan penghitungan hari inaktif selama durasi izin berjalan. Project Leader wajib mencatat izin di Kanban Board atau kanal Discord kelompok.

1. Surat Peringatan 1 (SP1): Jika dalam waktu 24 jam setelah teguran tertulis tidak ada respon atau perbaikan performa yang nyata, Project Leader kelompok melaporkan dan menyerahkan kasus kepada Divisi PM. Divisi PM akan meninjau bukti keaktifan dan menerbitkan SP1 yang berlaku selama 7 hari.
2. Surat Peringatan 2 (SP2): Jika dalam waktu 3 hari kerja setelah SP1 diterbitkan anggota tersebut tetap tidak menunjukkan kontribusi aktif, Divisi PM berhak menerbitkan SP2.
3. Eskalasi & Pemutusan Status Keanggotaan: Jika setelah SP2 anggota masih bersikap pasif, kasus akan dieskalasi kepada Pengurus Harian (BPH) dan Divisi SDM untuk dilakukan sidang khusus pemutusan status keanggotaan secara sepihak merujuk pada ART Pasal 9. Divisi PM adalah satu-satunya pihak yang berwenang memproses dan menerbitkan dokumen SP1 dan SP2 secara resmi. Project Leader kelompok tidak berwenang menerbitkan surat peringatan secara mandiri melainkan bertindak sebagai fasilitator pelaporan.

---

13. Governance Dokumen

Parameter Operasional yang Telah Ditetapkan

Berikut adalah parameter yang berlaku sebagai ketetapan standar untuk seluruh batch dan project di ekosistem YYZU:

Parameter	Nilai yang Ditetapkan	Keterangan
Komposisi tim per kelompok	4 orang (1 Project Leader + 3 Anggota)	Berlaku sebagai standar default
Durasi sprint	1 - 2 minggu per sprint	Disesuaikan dengan durasi total project
WIP Limit per anggota	Maksimal 2 task bersamaan	Berlaku di seluruh kategori project
Batas waktu SP1 setelah teguran Project Leader	24 jam	Lihat Bagian 12
Batas waktu SP2 setelah SP1	3 hari kerja	Lihat Bagian 12
Apabila kondisi project tertentu memerlukan penyimpangan dari parameter di atas, keputusan tersebut wajib disetujui oleh Divisi Product & Project Management dan Mentor sebelum project dimulai, serta dicatat dalam Project Brief project yang bersangkutan.

Prosedur Revisi Framework

Dokumen ini adalah dokumen hidup yang dapat berkembang seiring pertumbuhan ekosistem YYZU. Namun, setiap perubahan terhadap isi framework wajib mengikuti prosedur berikut:

1. Usulan perubahan diajukan secara tertulis oleh pengusul (BPH, Mentor aktif, atau Divisi PM).
2. Usulan dikaji bersama oleh minimal satu Mentor aktif dan Divisi Product & Project Management.
3. Perubahan disetujui oleh Founder YYZU sebelum diberlakukan.
4. Versi dokumen diperbarui dan riwayat perubahan dicatat pada tabel di atas.
5. Seluruh pengurus dan member aktif diberitahu mengenai perubahan yang berlaku.

Referensi Dokumen Terkait

• Anggaran Dasar (AD) YYZU - Landasan hukum dan struktur organisasi
• Anggaran Rumah Tangga (ART) YYZU - Ketentuan operasional dan keanggotaan
• Skema Mentoring - Mekanisme mentoring dan kontribusi mentor
• 38362601ca8c819d8ba4ed363897d2b5 - Mekanisme kemitraan eksternal
• Panduan Peran YYZU - Pembagian tanggung jawab peran
• Glosarium YYZU - Definisi seluruh istilah ekosistem
• Panduan Project Leader - Checklist harian, template ceremony, dan panduan lengkap PL