Proses yang Dapat Anda Pertanggungjawabkan ke Atasan Anda.
Kami tidak memulai pembangunan sebelum ruang lingkup dikunci. Kami tidak mengirim kode sebelum arsitektur divalidasi. Kami tidak menutup proyek sebelum sistem berjalan stabil di lingkungan produksi Anda.
Halaman ini menjelaskan secara konkret apa yang terjadi di setiap tahap — siapa yang mengerjakan apa, apa yang kami harapkan dari Anda, dan dokumen apa yang Anda terima di akhir setiap fase. Tidak ada klaim abstrak. Tidak ada janji tanpa parameter.
Ikhtisar Tahapan Proyek
Setiap proyek bersama Software Factory berjalan melalui empat tahap yang berurutan. Setiap tahap memiliki output konkret yang harus disetujui sebelum tahap berikutnya dimulai. Ini bukan preferensi gaya kerja — ini adalah mekanisme kontrol risiko yang melindungi anggaran dan jadwal Anda.
| No. | Nama Tahap | Fokus | Output Utama |
|---|---|---|---|
| 1 | Discovery Sprint (Berbayar) | Memahami masalah nyata sebelum menulis satu baris kode | Dokumen Definisi Masalah + Rancangan Ruang Lingkup |
| 2 | Arsitektur & Validasi | Merancang solusi teknis yang tepat sebelum eksekusi | Blueprint Teknis + RAB Final yang Terkunci |
| 3 | Implementasi Bertahap | Membangun sistem secara sprint dengan kontrol kualitas di setiap fase | Sistem Berfungsi per Sprint + Laporan UAT |
| 4 | Peluncuran & Managed Support | Go-live terkontrol dan dukungan pasca-peluncuran yang terstruktur | Sistem Live + SLA Tertulis + Akses Dukungan Prioritas |
Tahap 1: Discovery Sprint
Kami menggali masalah Anda sebelum menawarkan solusi.
Discovery Sprint adalah sesi kerja terstruktur — bukan presentasi produk, bukan demo — yang dirancang untuk satu tujuan: memahami masalah operasional Anda cukup dalam sehingga solusi yang kami rancang menjawab akar persoalan, bukan gejalanya. Proses ini menghasilkan dokumen yang dapat Anda gunakan, terlepas dari apakah proyek dilanjutkan atau tidak.
| Aktivitas Konkret | Peran Softwarefactory | Ekspektasi dari Klien | Output Klien |
|---|---|---|---|
| Sesi wawancara terstruktur dengan stakeholder teknis dan operasional klien (2–4 sesi). | Account Manager memimpin sesi. System Architect hadir sebagai pendengar aktif dan pencatat kebutuhan teknis. Semua hasil AI-assisted drafting divalidasi manual oleh tim senior sebelum diserahkan. | Menyiapkan stakeholder kunci yang berwenang menjawab pertanyaan operasional (minimal 1 orang dari sisi teknis, 1 dari sisi bisnis). Komitmen waktu: 2–4 jam total. | Notulensi terstruktur dari semua sesi, divalidasi dan disetujui klien. |
| Pemetaan proses existing: alur kerja saat ini, titik nyeri, dan batasan sistem yang sudah ada. | Tim Software Factory menyusun peta proses berdasarkan temuan wawancara. Tidak ada asumsi — setiap poin dikonfirmasi ke klien. | Menyediakan akses ke dokumentasi sistem existing (jika ada) atau menugaskan PIC yang bisa menjelaskan alur operasional secara langsung. | Dokumen Peta Proses Existing (as-is process map) dalam format yang dapat dibaca oleh pemangku kepentingan non-teknis. |
| Perumusan Problem Statement dan identifikasi success metrics. | Account Manager menyusun draf Problem Statement. System Architect memvalidasi keterjangkauan teknis dari sudut pandang arsitektur. Output final disetujui bersama. | Memberikan konfirmasi akhir bahwa Problem Statement mencerminkan prioritas internal klien secara akurat. | Dokumen Problem Statement yang telah disetujui — siap dibawa ke rapat internal klien. |
| Penyusunan Rancangan Ruang Lingkup awal (scope framework): fitur utama, batasan yang disepakati, dan asumsi yang terdokumentasi. | System Architect menyusun scope framework berbasis temuan Discovery. AI digunakan untuk membantu strukturisasi dokumen — semua keputusan konten tetap di tangan tim senior. | Me-review rancangan ruang lingkup dan memberikan sign-off atau catatan revisi dalam waktu yang disepakati. | Rancangan Scope Framework yang menjadi dasar Tahap 2 (Arsitektur & Validasi). |
Aktivitas Tahap
Account Manager memimpin sesi. System Architect hadir sebagai pendengar aktif dan pencatat kebutuhan teknis. Semua hasil AI-assisted drafting divalidasi manual oleh tim senior sebelum diserahkan.
Menyiapkan stakeholder kunci yang berwenang menjawab pertanyaan operasional (minimal 1 orang dari sisi teknis, 1 dari sisi bisnis). Komitmen waktu: 2–4 jam total.
Notulensi terstruktur dari semua sesi, divalidasi dan disetujui klien.
Tim Software Factory menyusun peta proses berdasarkan temuan wawancara. Tidak ada asumsi — setiap poin dikonfirmasi ke klien.
Menyediakan akses ke dokumentasi sistem existing (jika ada) atau menugaskan PIC yang bisa menjelaskan alur operasional secara langsung.
Dokumen Peta Proses Existing (as-is process map) dalam format yang dapat dibaca oleh pemangku kepentingan non-teknis.
Account Manager menyusun draf Problem Statement. System Architect memvalidasi keterjangkauan teknis dari sudut pandang arsitektur. Output final disetujui bersama.
Memberikan konfirmasi akhir bahwa Problem Statement mencerminkan prioritas internal klien secara akurat.
Dokumen Problem Statement yang telah disetujui — siap dibawa ke rapat internal klien.
System Architect menyusun scope framework berbasis temuan Discovery. AI digunakan untuk membantu strukturisasi dokumen — semua keputusan konten tetap di tangan tim senior.
Me-review rancangan ruang lingkup dan memberikan sign-off atau catatan revisi dalam waktu yang disepakati.
Rancangan Scope Framework yang menjadi dasar Tahap 2 (Arsitektur & Validasi).
Seluruh output Tahap 1 adalah dokumen fisik (digital) yang Anda miliki. Bahkan jika proyek tidak dilanjutkan ke Tahap 2, dokumen ini tetap menjadi milik Anda sepenuhnya.
Tahap 2: Arsitektur & Validasi
Solusi dirancang sepenuhnya sebelum dibangun. Anda dikonfirmasi, bukan dibebani.
Berdasarkan scope framework dari Tahap 1, tim teknis Software Factory merancang arsitektur sistem secara internal — meliputi desain database, alur integrasi, pemilihan stack teknologi, dan perkiraan effort yang akurat. Klien dikonfirmasi secara berkala di titik-titik keputusan kunci. Anda tidak perlu hadir setiap hari — Anda hanya perlu memberikan konfirmasi ketika arsitektur final siap untuk disetujui.
| Aktivitas Konkret | Peran Softwarefactory | Ekspektasi dari Klien | Output Klien |
|---|---|---|---|
| Desain arsitektur sistem: struktur database, API endpoints, integrasi dengan sistem existing klien, dan desain antarmuka pengguna (wireframe level). | System Architect memimpin proses desain secara internal. AI digunakan untuk mempercepat pembuatan draf dokumentasi teknis — semua keputusan arsitektur divalidasi secara manual oleh Direktur Teknis sebelum dokumen dianggap final. | Menyediakan jawaban atas pertanyaan teknis spesifik jika muncul selama proses desain (biasanya via email atau meeting singkat ≤ 60 menit). Tidak diperlukan keterlibatan harian. | Dokumen Arsitektur Teknis (wireframe, diagram sistem, spesifikasi integrasi) dalam format yang dapat dipresentasikan ke tim teknis internal klien. |
| Estimasi effort dan penyusunan RAB (Rincian Anggaran Biaya) final yang terkunci berdasarkan arsitektur yang telah dirancang. | Account Manager dan System Architect menyusun RAB bersama. Nominal spesifik tidak ditampilkan di halaman publik — RAB final hanya diserahkan kepada klien dalam konteks formal (dokumen terpisah). | Mengkonfirmasi apakah terdapat batasan anggaran atau regulasi pengadaan internal yang perlu diakomodasi dalam struktur kontrak. | RAB Final Terkunci: dokumen anggaran yang sudah disetujui dan menjadi acuan kontrak. Tidak ada perubahan biaya setelah tahap ini tanpa Change Request formal. |
| Sesi konfirmasi arsitektur bersama klien: presentasi desain dan validasi bahwa arsitektur menjawab problem statement dari Tahap 1. | Account Manager memfasilitasi sesi konfirmasi. System Architect hadir untuk menjawab pertanyaan teknis. Sesi ini biasanya berlangsung 60–90 menit. | Hadir dalam sesi konfirmasi dengan pemangku kepentingan yang berwenang memberikan sign-off teknis. Menyampaikan catatan atau revisi dalam waktu yang disepakati setelah sesi. | Dokumen Konfirmasi Arsitektur yang ditandatangani — ini adalah gate resmi sebelum Tahap 3 dimulai. |
Aktivitas Tahap
System Architect memimpin proses desain secara internal. AI digunakan untuk mempercepat pembuatan draf dokumentasi teknis — semua keputusan arsitektur divalidasi secara manual oleh Direktur Teknis sebelum dokumen dianggap final.
Menyediakan jawaban atas pertanyaan teknis spesifik jika muncul selama proses desain (biasanya via email atau meeting singkat ≤ 60 menit). Tidak diperlukan keterlibatan harian.
Dokumen Arsitektur Teknis (wireframe, diagram sistem, spesifikasi integrasi) dalam format yang dapat dipresentasikan ke tim teknis internal klien.
Account Manager dan System Architect menyusun RAB bersama. Nominal spesifik tidak ditampilkan di halaman publik — RAB final hanya diserahkan kepada klien dalam konteks formal (dokumen terpisah).
Mengkonfirmasi apakah terdapat batasan anggaran atau regulasi pengadaan internal yang perlu diakomodasi dalam struktur kontrak.
RAB Final Terkunci: dokumen anggaran yang sudah disetujui dan menjadi acuan kontrak. Tidak ada perubahan biaya setelah tahap ini tanpa Change Request formal.
Account Manager memfasilitasi sesi konfirmasi. System Architect hadir untuk menjawab pertanyaan teknis. Sesi ini biasanya berlangsung 60–90 menit.
Hadir dalam sesi konfirmasi dengan pemangku kepentingan yang berwenang memberikan sign-off teknis. Menyampaikan catatan atau revisi dalam waktu yang disepakati setelah sesi.
Dokumen Konfirmasi Arsitektur yang ditandatangani — ini adalah gate resmi sebelum Tahap 3 dimulai.
Gate resmi: Tahap 3 tidak dimulai sebelum Dokumen Konfirmasi Arsitektur dan RAB Final ditandatangani oleh perwakilan klien yang berwenang. Ini melindungi kedua pihak dari ambiguitas mid-project.
Tahap 3: Implementasi Bertahap
Dibangun per sprint. Dikontrol di setiap checkpoint. Tidak ada kejutan di akhir proyek.
Pembangunan sistem dilakukan secara bertahap dalam sprint-sprint yang terukur. Setiap sprint menghasilkan modul yang dapat diuji — bukan kode yang tersembunyi di server kami sampai proyek selesai. Tim teknis Software Factory menggunakan AI untuk mempercepat penulisan kode rutin, sementara setiap hasil kerja melewati peer code review manual oleh senior developer sebelum diserahkan ke tahap pengujian. Setiap perubahan di luar ruang lingkup yang sudah dikunci di Tahap 2 harus melalui mekanisme Change Request formal.
| Aktivitas Konkret | Peran Softwarefactory | Ekspektasi dari Klien | Output Klien |
|---|---|---|---|
| Eksekusi pengembangan sistem per sprint (biasanya 2 minggu per sprint). Setiap sprint memiliki backlog fitur yang telah disepakati di awal. | Developer tim satelit mengeksekusi task teknis. Lead System Architect melakukan peer code review manual untuk setiap deliverable sebelum masuk to staging environment. AI digunakan untuk code assistance dan deteksi kerentanan otomatis — semua output melewati human quality gate. | Menyediakan akses ke environment testing atau staging yang diperlukan. Menugaskan PIC teknis internal yang dapat merespons pertanyaan integrasi sistem dalam waktu 1 hari kerja. | Demo sprint yang dapat diakses dan diuji oleh klien di akhir setiap sprint. Laporan progres sprint (sprint summary report) yang didistribusikan secara rutin. |
| Pengujian internal (automated testing + manual exploratory testing) sebelum setiap deliverable diserahkan ke klien untuk UAT. | QA dilakukan berlapis: automated testing scripts dijalankan terlebih dahulu, kemudian dilanjutkan dengan manual exploratory testing oleh tim QA untuk menjamin pengalaman pengguna yang tidak hanya bebas bug tetapi juga intuitif. | Melakukan User Acceptance Testing (UAT) terhadap deliverable sprint dengan mengacu pada acceptance criteria yang telah disepakati. Memberikan sign-off UAT atau daftar bug dalam waktu yang disepakati. | Laporan UAT yang ditandatangani per sprint. Setiap modul yang lulus UAT dianggap accepted dan masuk ke inventory sistem yang sudah terverifikasi. |
| Manajemen Change Request: setiap perubahan di luar scope yang dikunci di Tahap 2 didokumentasikan, diestimasi dampak waktu dan biayanya, dan memerlukan persetujuan formal sebelum dikerjakan. | Account Manager mendokumentasikan Change Request dan mengoordinasikan estimasi dampak bersama System Architect. Tidak ada perubahan scope yang dikerjakan tanpa dokumen Change Request yang ditandatangani. | Mengajukan Change Request secara formal melalui saluran yang disepakati (bukan via WhatsApp atau verbal). Memberikan keputusan persetujuan atau penolakan dalam 3 hari kerja. | Dokumen Change Request yang terdokumentasi dan ditandatangani — melindungi klien dari pembengkakan scope yang tidak terdokumentasi. |
Aktivitas Tahap
Developer tim satelit mengeksekusi task teknis. Lead System Architect melakukan peer code review manual untuk setiap deliverable sebelum masuk to staging environment. AI digunakan untuk code assistance dan deteksi kerentanan otomatis — semua output melewati human quality gate.
Menyediakan akses ke environment testing atau staging yang diperlukan. Menugaskan PIC teknis internal yang dapat merespons pertanyaan integrasi sistem dalam waktu 1 hari kerja.
Demo sprint yang dapat diakses dan diuji oleh klien di akhir setiap sprint. Laporan progres sprint (sprint summary report) yang didistribusikan secara rutin.
QA dilakukan berlapis: automated testing scripts dijalankan terlebih dahulu, kemudian dilanjutkan dengan manual exploratory testing oleh tim QA untuk menjamin pengalaman pengguna yang tidak hanya bebas bug tetapi juga intuitif.
Melakukan User Acceptance Testing (UAT) terhadap deliverable sprint dengan mengacu pada acceptance criteria yang telah disepakati. Memberikan sign-off UAT atau daftar bug dalam waktu yang disepakati.
Laporan UAT yang ditandatangani per sprint. Setiap modul yang lulus UAT dianggap accepted dan masuk ke inventory sistem yang sudah terverifikasi.
Account Manager mendokumentasikan Change Request dan mengoordinasikan estimasi dampak bersama System Architect. Tidak ada perubahan scope yang dikerjakan tanpa dokumen Change Request yang ditandatangani.
Mengajukan Change Request secara formal melalui saluran yang disepakati (bukan via WhatsApp atau verbal). Memberikan keputusan persetujuan atau penolakan dalam 3 hari kerja.
Dokumen Change Request yang terdokumentasi dan ditandatangani — melindungi klien dari pembengkakan scope yang tidak terdokumentasi.
Prinsip yang tidak bisa dikompromikan di Tahap 3: Kami tidak menutup sprint tanpa sign-off UAT dari klien. Kami tidak mengerjakan perubahan scope tanpa Change Request tertulis. Dua aturan ini adalah yang paling sering dilanggar vendor lain — dan menjadi akar dari sebagian besar konflik proyek IT yang berujung di meja hukum.
Tahap 4: Peluncuran & Managed Support
Go-live bukan akhir proyek. Ini awal dari kemitraan operasional yang terstruktur.
Peluncuran sistem dilakukan secara terkontrol — bukan dengan menekan tombol lalu menyerahkan segalanya ke klien. Software Factory mendampingi proses go-live, memastikan migrasi data berjalan akurat, dan memverifikasi performa sistem di lingkungan produksi nyata sebelum dinyatakan live. Setelah go-live, dukungan purna jual dijalankan berdasarkan SLA tertulis yang disepakati — bukan janji verbal.
| Aktivitas Konkret | Peran Softwarefactory | Ekspektasi dari Klien | Output Klien |
|---|---|---|---|
| Pre-launch checklist dan verifikasi sistem di environment produksi klien: keamanan data, performa beban, dan konfigurasi backup. | System Architect melakukan final security audit dan performance testing di environment produksi. AI digunakan untuk menjalankan automated vulnerability scanning — hasil scan divalidasi manual sebelum sistem dinyatakan siap go-live. | Menyediakan akses ke environment produksi dan menugaskan admin IT internal yang dapat berkoordinasi selama proses deployment. | Laporan Pre-Launch Verification yang terdokumentasi — bukti tertulis bahwa sistem telah melewati standar keamanan dan performa sebelum go-live. |
| Pelaksanaan go-live terkontrol: deployment ke production, migrasi data (jika ada), dan monitoring intensif 72 jam pertama pasca-launch. | Account Manager mengkoordinasikan jadwal go-live dengan klien. Tim teknis standby selama 72 jam pertama untuk respons insiden cepat. Semua tindakan perbaikan didokumentasikan real-time. | Menginformasikan pengguna internal tentang jadwal go-live. Menyediakan PIC yang dapat dihubungi jika terjadi isu operasional di sisi klien selama 72 jam pertama. | Sistem live dan beroperasi di environment produksi. Berita acara serah terima sistem yang ditandatangani kedua pihak. |
| Managed Support pasca-go-live: penanganan bug kritis, pembaruan keamanan, dan dukungan operasional sesuai paket yang disepakati. | Tim support Software Factory merespons insiden berdasarkan tingkat prioritas yang didefinisikan dalam SLA. AI digunakan untuk kategorisasi tiket otomatis dan penyaringan FAQ — penanganan insiden kritis dan keputusan eskalasi tetap di tangan tim senior manusia. | Melaporkan insiden melalui saluran support yang disepakati (bukan nomor pribadi tim teknis). Memberikan informasi konteks yang cukup saat melaporkan isu untuk mempercepat waktu resolusi. | SLA Tertulis yang mencakup: response time per kategori insiden, availability commitment, dan eskalasi path yang terdefinisi. Laporan bulanan status sistem dan tiket yang diselesaikan. |
Aktivitas Tahap
System Architect melakukan final security audit dan performance testing di environment produksi. AI digunakan untuk menjalankan automated vulnerability scanning — hasil scan divalidasi manual sebelum sistem dinyatakan siap go-live.
Menyediakan akses ke environment produksi dan menugaskan admin IT internal yang dapat berkoordinasi selama proses deployment.
Laporan Pre-Launch Verification yang terdokumentasi — bukti tertulis bahwa sistem telah melewati standar keamanan dan performa sebelum go-live.
Account Manager mengkoordinasikan jadwal go-live dengan klien. Tim teknis standby selama 72 jam pertama untuk respons insiden cepat. Semua tindakan perbaikan didokumentasikan real-time.
Menginformasikan pengguna internal tentang jadwal go-live. Menyediakan PIC yang dapat dihubungi jika terjadi isu operasional di sisi klien selama 72 jam pertama.
Sistem live dan beroperasi di environment produksi. Berita acara serah terima sistem yang ditandatangani kedua pihak.
Tim support Software Factory merespons insiden berdasarkan tingkat prioritas yang didefinisikan dalam SLA. AI digunakan untuk kategorisasi tiket otomatis dan penyaringan FAQ — penanganan insiden kritis dan keputusan eskalasi tetap di tangan tim senior manusia.
Melaporkan insiden melalui saluran support yang disepakati (bukan nomor pribadi tim teknis). Memberikan informasi konteks yang cukup saat melaporkan isu untuk mempercepat waktu resolusi.
SLA Tertulis yang mencakup: response time per kategori insiden, availability commitment, dan eskalasi path yang terdefinisi. Laporan bulanan status sistem dan tiket yang diselesaikan.
Apa yang membedakan Managed Support Software Factory: SLA kami adalah dokumen kontraktual, bukan janji marketing. Response time, availability target, dan prosedur eskalasi tertulis dan mengikat. Anda tidak perlu menghubungi nomor pribadi siapapun untuk mendapat respons.
Kenapa Proses Ini? Pertanyaan yang Wajar — dan Jawaban yang Jujur.
Kami memahami bahwa buyer korporat — terutama di lingkungan BUMN — memiliki pertanyaan yang wajar tentang pendekatan ini. Berikut adalah jawaban langsung, tanpa klaim yang tidak bisa diverifikasi.
Anda sudah memahami prosesnya. Langkah berikutnya adalah satu.
Discovery Sprint adalah titik masuk satu-satunya untuk semua proyek Softwarefactory. Tidak ada jalan pintas, karena jalan pintas adalah yang menciptakan proyek bermasalah. Isi formulir pengajuan. Tim kami akan menghubungi Anda dalam 1 hari kerja untuk menjadwalkan sesi orientasi singkat (30 menit) sebelum Discovery Sprint dimulai.
Tidak ada komitmen di luar tahap yang sedang berjalan. Setiap tahap dimulai dengan persetujuan tertulis Anda.