Dashboard Panduan Alur Kerja ClickUp — SI PAI
ClickUp Workspace

Panduan Alur Kerja ClickUp

Proyek Pengembangan Sistem Informasi PAI (PAI-IPMS) — struktur workspace, pembagian peran, dan alur status kerja seluruh tim.

🏗

Struktur Workspace

Semua pekerjaan dikelola dalam satu Space bernama "SI PAI" di ClickUp.

Hierarki Workspace

🌐 Space
SI PAI
📁 Folder
Preparation · Live 1 (Sep 2026) · Live 2 (Oct 2026) · Post-Live
📋 List (per Folder)
1 List per Modul — 11 List total (Portal & CMS, Keanggotaan, Keuangan, LMS, UAT & Go-Live, dst.)
➕ List Tambahan
🐛 Bugs 🔄 Change Request 📄 Admin & Dokumentasi
✅ Task
Unit kerja individual — 1 baris pekerjaan dengan Assignee, tanggal, estimasi waktu, dan status.

🏷 Sistem Tagging

Setiap Task diberi Tag modul (misal: modul-1, modul-2) untuk filter lintas-fase, dan Tag milestone untuk titik keputusan penting (UAT Approval, Training & BAST).

👥

Tim & Peran

5 anggota tim dengan tanggung jawab masing-masing.

K
Kamal
Project Manager
Perencanaan, koordinasi timeline, evaluasi CR, approval BAST/kontrak
R
Pak Rhuly
Business Analyst
Requirement, user story, acceptance criteria, desain alur, User Manual, training materi
RT
Rio & Taufik
Developer
Implementasi backend & frontend, code review satu sama lain
S
Sindy
QA Engineer
Functional testing, pencatatan bug, koordinasi UAT dengan klien
J
Jesica
Project Admin
Update dokumentasi tiap task selesai, notulen meeting, arsip dokumen
⚙️

Alur Kerja Task Modul

Alur utama untuk hampir semua pekerjaan teknis, dari Preparation sampai Post-Live.

📋 6 Tahapan Utama

1

Requirement & Desain

Breakdown kebutuhan jadi task, lengkap acceptance criteria / wireframe.

👤 Pak Rhuly
2

Development

Coding fitur sesuai task yang di-assign. Push ke branch, buat pull request.

👤 Rio & Taufik
3

Code Review

Review kode satu sama lain sebelum merge. Cek kualitas dan standar.

🔄 Rio ↔ Taufik
4

Testing & QA

Test fungsional berdasarkan acceptance criteria. Kalau ada bug, buat task baru di List Bugs.

👤 Sindy
5

Update Dokumentasi

Update User Manual / catatan teknis terkait task yang baru selesai.

👤 Jesica
6

Selesai

Task ditutup. Siap direkap untuk laporan progres ke klien.

👤 Kamal

🔄 Alur Status ClickUp — List Modul Biasa

TO DO→ IN PROGRESS→ CODE REVIEW→ READY FOR QA→ IN QA→ REVISION↺ ulang ke IN QA→ DOCS UPDATE→ CLOSED
⚠️ Kalau QA menemukan masalah di status IN QA, task kembali ke REVISION — bukan mulai dari awal lagi.
TO DO
↓
IN PROGRESS
↓
CODE REVIEW
↓
READY FOR QA
↓
IN QA
↓
REVISION↺ ulang ke IN QA
↓
DOCS UPDATE
↓
CLOSED
⚠️ Kalau QA menemukan masalah, task kembali ke REVISION — bukan mulai dari awal.
🚀

Alur Khusus: UAT & Go-Live

Berlaku untuk List Modul 6 (UAT & Go-Live 1) dan Modul 10 (UAT & Go-Live 2).

🔄 Alur Status — UAT & Go-Live

TO DO→ IN PROGRESS→ CODE REVIEW→ READY FOR QA→ IN QA→ UAT (KLIEN) 👥→ REVISION→ DOCS UPDATE→ DEPLOYED ✅
🔑 Perbedaan kunci: Status UAT (KLIEN) = sistem sedang direview langsung oleh klien. Tim wajib menunggu approval eksplisit dari klien sebelum lanjut ke DEPLOYED.
TO DO
↓
IN PROGRESS
↓
CODE REVIEW
↓
READY FOR QA
↓
IN QA
↓
UAT (KLIEN) 👥
↓
REVISION
↓
DOCS UPDATE
↓
DEPLOYED ✅
🔑 UAT (KLIEN) = wajib menunggu approval klien sebelum DEPLOYED.
🐛

Alur Kerja: List "Bugs"

Dipakai kapan pun QA (atau siapa pun) menemukan defect di luar siklus testing terjadwal.

🔄 Alur Status Bug

OPEN→ CONFIRMED→ IN PROGRESS→ FIXED→ RE-TEST→ CLOSED
OPEN
↓
CONFIRMED
↓
IN PROGRESS
↓
FIXED
↓
RE-TEST
↓
CLOSED
OPEN

Bug baru dilaporkan, belum divalidasi.

CONFIRMED

Sindy sudah reproduksi dan memastikan bug valid.

IN PROGRESS

Rio/Taufik sedang memperbaiki.

FIXED

Perbaikan selesai, siap diuji ulang.

RE-TEST

Sindy menguji ulang untuk memastikan bug benar-benar hilang.

CLOSED

Bug tuntas.

🏷 Setiap task Bug diberi Tag modul (contoh: modul-3) supaya bisa ditelusuri terkait List modul mana.
🔄

Alur Kerja: List "Change Request"

CR ≠ Bug. CR adalah permintaan baru/di luar scope awal dari klien yang butuh evaluasi dan persetujuan formal.

⚠️ Perbedaan Bug vs Change Request

🐛 BUG

Kesalahan dari pekerjaan yang sudah disepakati. Wajib diperbaiki tanpa nego tambahan.

🔄 CHANGE REQUEST

Permintaan baru/di luar scope awal. Bisa berdampak jadwal & biaya — butuh evaluasi & persetujuan formal.

🔄 Alur Status Change Request

SUBMITTED→ REVIEW DAMPAK→ USULAN KE KLIEN→
APPROVED ✅ atau REJECTED ✗
→ (jika APPROVED) IN DEVELOPMENT→ CLOSED
SUBMITTED
↓
REVIEW DAMPAK
↓
USULAN KE KLIEN
↓
APPROVED ✅ atau REJECTED ✗
↓jika APPROVED
IN DEVELOPMENT
↓
CLOSED
SUBMITTED

Permintaan baru dari klien dicatat apa adanya oleh Kamal — jangan diringkas dulu.

REVIEW DAMPAK

Kamal & Pak Rhuly menghitung dampak: tambahan Man Days, potensi geser deadline, biaya tambahan.

USULAN KE KLIEN

Hasil evaluasi disampaikan ke klien untuk persetujuan formal — idealnya via Addendum SPK/kontrak.

IN DEVELOPMENT

Jika APPROVED, dibuatkan task teknis baru di List Modul terkait dengan Tag (misal cr-0001).

🚫 Aturan Penting Jangan pernah langsung mengerjakan CR di List Modul sebelum statusnya APPROVED di List Change Request.
📄

Alur Kerja: Admin & Dokumentasi

Untuk dokumen formal proyek yang bersifat administratif.

🔄 Alur Status Dokumen

DRAFT→ REVIEW INTERNAL→ REVIEW KLIEN→ APPROVED / SIGNED ✅
DRAFT
↓
REVIEW INTERNAL
↓
REVIEW KLIEN
↓
APPROVED / SIGNED ✅

📁 Dokumen yang Masuk List Ini

📜 Kontrak / SPK
📖 User Manual
📋 BAST tiap fase
🎓 Materi Training
📑 Dok. Garansi
📊

Ringkasan Cepat

Referensi cepat untuk semua List dan alurnya.

ListDipakai UntukStatus Akhir
9 List Modul Pekerjaan teknis harian per modul CLOSED
2 List UAT & Go-Live Modul yang butuh approval klien sebelum rilis DEPLOYED
Bugs Defect di luar siklus testing terjadwal CLOSED
Change Request Permintaan tambahan/di luar scope dari klien CLOSEDREJECTED
Admin & Dokumentasi Dokumen formal & deliverable non-teknis APPROVED/SIGNED
💬 Pertanyaan atau kendala soal alur ini? Hubungi Kamal (PM) sebagai penanggung jawab workspace ClickUp.