Dari Brief ke Peluncuran: Alur Proyek Website yang Sehat

Proyek website jarang gagal karena alasan teknis. Ia gagal karena keputusan yang tidak pernah dibuat, atau dibuat ulang pada tahap ketika mengubahnya sudah mahal. Gejalanya khas: revisi yang tidak berujung, tenggat yang mundur berulang kali, dan dua pihak yang sama-sama merasa sudah menjelaskan.

Artikel ini menyusun alur proyek website yang sehat dalam tujuh tahap: apa yang dihasilkan tiap tahap, siapa yang memutuskan apa, dan dokumen minimum yang mencegah pekerjaan berputar. Kerangkanya berlaku baik ketika Anda memakai vendor maupun ketika mengerjakannya dengan tim sendiri.

Prinsip yang mendasari semuanya

Satu prinsip menjelaskan sebagian besar aturan di bawah: biaya mengubah sesuatu naik tajam seiring tahapnya. Mengubah struktur halaman saat masih berupa kerangka memakan sepuluh menit. Mengubahnya setelah desain jadi memakan sehari. Mengubahnya setelah kode ditulis dan isi dimasukkan memakan seminggu, dan biasanya merusak hal lain.

Karena itu, seluruh alur ini dirancang untuk memindahkan keputusan sedini mungkin, dan untuk membuat keputusan yang sudah diambil sulit dibuka kembali tanpa disadari.

Tahap 1 — Penyelarasan tujuan

Tahap ini menjawab pertanyaan yang mengejutkan sering dilewati: apa yang harus berubah di bisnis setelah situs ini ada? Jawaban seperti "terlihat lebih profesional" belum cukup, karena tidak bisa diperiksa nanti.

Keluaran: satu halaman berisi tujuan bisnis, satu sampai tiga metrik yang akan dinilai, angka dasar hari ini, dan batasan yang sudah pasti — anggaran, tenggat, dan hal yang tidak boleh berubah.

Pemutus: pemilik bisnis. Ini satu-satunya tahap yang tidak boleh didelegasikan.

Tahap 2 — Pemetaan isi dan struktur

Sebelum ada desain, tentukan halaman apa saja yang akan ada, apa tugas masing-masing, dan bagaimana pengunjung berpindah di antaranya. Tahap ini murah dan mencegah sebagian besar pekerjaan ulang yang mahal.

Keluaran: daftar halaman lengkap dengan tugas tiap halaman, peta navigasi, dan daftar isi yang perlu disiapkan beserta siapa yang menyiapkannya. Kerangka menyusunnya ada di panduan struktur website.

Pemutus: pemilik bisnis, disiapkan bersama tim pengerjaan.

Tahap 3 — Kerangka tampilan

Kerangka adalah gambar sederhana tanpa warna dan tanpa gaya, yang menunjukkan susunan tiap halaman: apa di atas, apa di bawah, di mana tombolnya. Tujuannya memisahkan diskusi tentang susunan dari diskusi tentang selera.

Melewati tahap ini adalah kesalahan yang mahal, karena diskusi kemudian bercampur: ketika susunan halaman dibahas bersamaan dengan pilihan warna, keduanya jadi sulit diselesaikan.

Keluaran: kerangka untuk semua jenis halaman yang berbeda, disetujui tertulis.

Tahap 4 — Desain visual

Baru pada tahap ini warna, tipografi, dan gaya visual dibahas. Karena susunannya sudah disetujui, diskusi bisa fokus pada satu hal.

Aturan yang menghemat banyak waktu: sepakati jumlah putaran revisi di muka, dan sepakati bahwa umpan balik dikumpulkan dari semua pihak sekaligus, bukan menetes satu per satu. Umpan balik menetes adalah penyebab paling umum satu putaran revisi berubah menjadi lima.

Keluaran: desain untuk semua jenis halaman, di ukuran layar besar dan kecil, disetujui tertulis.

Tahap 5 — Pengerjaan

Selama pengerjaan, pekerjaan pemilik bisnis bukan menunggu, melainkan menyiapkan dua hal: isi yang belum lengkap, dan akses yang akan dibutuhkan saat peluncuran — domain, hosting, akun analytics, akun pihak ketiga.

Akses adalah penyebab keterlambatan peluncuran yang paling sering terjadi dan paling mudah dicegah. Kumpulkan semuanya pada tahap ini, bukan pada hari peluncuran.

Keluaran: situs berjalan di alamat uji, bisa diperiksa siapa pun yang berkepentingan.

Tahap 6 — Peninjauan dan pengujian

Tahap ini sering diperlakukan sebagai formalitas dan itu keliru. Sediakan daftar periksa, dan bagi tugas peninjauan supaya tidak semua orang memeriksa hal yang sama.

Yang diperiksa	Oleh siapa
Kebenaran isi, harga, dan klaim	Pemilik bisnis
Formulir benar-benar sampai ke tujuan	Tim penjualan
Tampilan di ponsel yang benar-benar dipakai	Beberapa orang berbeda
Kecepatan, tautan rusak, halaman 404	Tim pengerjaan
Pelacakan konversi berfungsi	Tim pengerjaan + pemilik
Pengalihan URL lama	Tim pengerjaan

Dua baris terakhir yang paling sering terlewat dan paling merugikan. Situs baru yang tidak mengalihkan URL lama kehilangan sebagian besar posisi pencarian yang sudah dibangun bertahun-tahun; rinciannya ada di panduan SEO teknis.

Tahap 7 — Peluncuran dan sesudahnya

Peluncuran bukan akhir proyek. Dua minggu setelahnya adalah periode ketika sebagian besar masalah nyata muncul, karena pengunjung sungguhan memakai situs dengan cara yang tidak terpikir saat pengujian.

Yang perlu disiapkan: siapa yang memantau, apa yang dipantau, dan bagaimana melaporkan masalah. Minimal, pantau tiga hal setiap hari selama dua minggu — apakah formulir masuk, apakah ada halaman yang error, dan apakah jumlah pengunjung wajar dibanding sebelumnya.

Keluaran: catatan serah terima berisi cara mengelola isi, tempat kredensial disimpan, dan siapa yang dihubungi bila ada masalah.

Dokumen minimum yang mencegah revisi tanpa ujung

Empat dokumen berikut sudah cukup untuk sebagian besar proyek, dan semuanya pendek.

1. Lembar tujuan dari tahap satu — satu halaman, jadi rujukan saat ada perdebatan lingkup.
2. Daftar halaman dan tugasnya — mencegah halaman bertambah diam-diam.
3. Catatan persetujuan tiap tahap — cukup satu baris bertanggal per tahap.
4. Daftar perubahan setelah persetujuan — mencatat apa yang berubah, kapan, dan atas permintaan siapa.

Dokumen keempat yang paling sering absen dan paling menyelamatkan. Tanpa itu, pertanyaan "kenapa proyeknya mundur" tidak punya jawaban yang bisa diperiksa, dan berubah menjadi saling menyalahkan.

Persetujuan yang tidak dicatat sama dengan tidak ada. Bukan karena orang tidak jujur, tetapi karena ingatan tentang siapa menyetujui apa memang tidak bisa diandalkan setelah dua bulan.

Menangani permintaan perubahan

Perubahan di tengah proyek bukan hal buruk; sebagian justru memperbaiki hasil. Yang merusak adalah perubahan yang masuk tanpa dinilai dampaknya.

Cara menanganinya sederhana: setiap permintaan perubahan dijawab dengan tiga hal sebelum dikerjakan — apa yang berubah, berapa tambahan waktunya, dan berapa tambahan biayanya kalau ada. Jawaban "bisa, tambah tiga hari" jauh lebih sehat daripada "bisa" yang kemudian diam-diam menggeser tenggat.

Beberapa perubahan tidak seharusnya diterima sama sekali di tahap akhir. Mengubah struktur navigasi setelah pengerjaan berjalan, misalnya, biasanya lebih baik ditunda ke tahap perbaikan setelah peluncuran daripada dipaksakan masuk.

Rapat yang perlu ada, dan yang tidak

Proyek yang berlebihan rapatnya sama merugikannya dengan proyek yang tidak pernah berkomunikasi. Yang pertama menghabiskan waktu tanpa keputusan; yang kedua menghasilkan keputusan yang tidak diketahui pihak lain.

Untuk proyek website berukuran menengah, empat pertemuan biasanya cukup, dan masing-masing punya tujuan yang berbeda.

• Rapat pembuka. Menyepakati tujuan, batasan, peran, dan cara berkomunikasi. Satu sampai dua jam, dan hasilnya ditulis.
• Peninjauan kerangka. Membahas susunan halaman sebelum ada desain. Biasanya yang paling banyak menghasilkan perubahan, dan itu memang tujuannya.
• Peninjauan desain. Satu pertemuan dengan umpan balik yang sudah dikumpulkan sebelumnya, bukan diskusi terbuka.
• Peninjauan sebelum peluncuran. Menelusuri daftar periksa bersama, bukan mengagumi hasilnya.

Di luar itu, kabar kemajuan cukup disampaikan tertulis sekali seminggu: apa yang selesai, apa yang sedang dikerjakan, apa yang ditunggu dari pihak klien. Kalimat terakhir yang paling penting dan paling sering hilang — sebagian besar keterlambatan terjadi karena tidak ada yang tahu bahwa sesuatu sedang ditunggu.

Cara menyampaikan umpan balik yang bisa dikerjakan

Umpan balik "kurang menarik" tidak bisa dikerjakan siapa pun. Yang bisa dikerjakan menyebutkan bagian, masalah, dan bila mungkin tujuannya: "judul di bagian atas tidak menyebutkan untuk siapa layanan ini, padahal itu pertanyaan pertama pelanggan kami." Meminta umpan balik dalam bentuk itu bukan kerewelan prosedural; ia memangkas jumlah putaran revisi secara langsung.

Peran yang harus jelas sejak awal

Sebagian besar kekacauan proyek berasal dari peran yang kabur, bukan dari orang yang tidak kompeten. Empat peran perlu ditetapkan dengan nama, bukan dengan tim.

• Pemutus tunggal di sisi klien. Boleh berkonsultasi ke siapa pun, tetapi hanya satu orang yang menyampaikan keputusan akhir.
• Penanggung jawab harian di sisi pengerjaan. Satu titik kontak, bukan tiga orang bergantian.
• Pemilik isi. Orang yang bertanggung jawab menyiapkan teks dan gambar tepat waktu.
• Pemilik akses. Orang yang bisa memberikan kredensial domain, hosting, dan akun pihak ketiga.

Peran pertama yang paling menentukan. Proyek dengan lima orang yang sama-sama boleh meminta perubahan hampir pasti akan mundur, berapa pun kemampuan tim pengerjaannya.

Menyiapkan isi: pekerjaan yang selalu diremehkan

Kalau ada satu bagian yang paling sering menghancurkan jadwal proyek website, itu adalah isi. Teks, foto, dan data produk hampir selalu diperkirakan lebih ringan daripada kenyataannya, karena secara intuitif menulis terasa seperti pekerjaan yang bisa diselipkan kapan saja.

Kenyataannya, menulis halaman layanan yang jelas membutuhkan keputusan bisnis: untuk siapa layanan ini, apa yang tidak termasuk, berapa kisaran harganya. Keputusan-keputusan itulah yang memakan waktu, bukan pengetikannya.

Tiga cara yang biasanya berhasil mempercepat tanpa mengorbankan kualitas. Pertama, mulai dari wawancara: rekam percakapan tiga puluh menit tentang satu layanan, lalu susun teksnya dari rekaman itu. Bicara jauh lebih mudah daripada menulis, dan hasilnya terdengar lebih jujur. Kedua, tetapkan tenggat per halaman, bukan tenggat gabungan untuk "semua isi" — tenggat gabungan selalu meleset di akhir. Ketiga, sepakati bahwa isi yang belum siap diluncurkan dalam bentuk sementara yang jujur, bukan menahan seluruh peluncuran.

Foto dan aset visual

Foto sering menjadi penghambat yang tidak terduga karena membutuhkan penjadwalan pihak ketiga. Putuskan sejak tahap dua: apakah akan memakai foto sendiri, foto pustaka, atau ilustrasi. Ketiganya sah, tetapi masing-masing punya konsekuensi waktu yang sangat berbeda, dan memutuskannya di tahap lima berarti menunda peluncuran.

Menghindari lingkup yang mengembang pelan-pelan

Lingkup jarang mengembang lewat satu permintaan besar. Ia mengembang lewat belasan permintaan kecil yang masing-masing terasa wajar: satu halaman tambahan, satu formulir lagi, satu integrasi kecil.

Cara paling efektif mengendalikannya bukan menolak, melainkan membuat dampaknya terlihat. Simpan satu daftar terbuka berisi semua permintaan tambahan beserta perkiraan waktunya, dan tinjau daftar itu bersama setiap dua minggu. Ketika total tambahan waktu terlihat sebagai satu angka, keputusan tentang mana yang dikerjakan sekarang dan mana yang ditunda menjadi jauh lebih mudah — dan diambil oleh pemilik proyek, bukan diam-diam oleh orang yang mengerjakan.

Perkiraan waktu yang realistis

Tenggat yang meleset biasanya bukan karena pengerjaannya lambat, melainkan karena waktu tunggu tidak dihitung. Waktu menunggu isi, waktu menunggu persetujuan, waktu menunggu akses — ketiganya sering lebih panjang daripada waktu mengerjakan.

Cara membuat perkiraan yang lebih jujur: hitung waktu pengerjaan, lalu tambahkan waktu tunggu secara eksplisit untuk tiap titik persetujuan. Kalau persetujuan desain biasanya butuh seminggu di organisasi klien, tulis seminggu — bukan dua hari yang optimistis.

Daftar periksa sebelum peluncuran

Daftar berikut pendek dengan sengaja. Ia memuat hal-hal yang, bila terlewat, menimbulkan kerugian yang sulit dipulihkan — bukan daftar lengkap semua yang perlu diperiksa.

1. Pengalihan URL lama sudah dipasang dan diuji satu per satu untuk halaman yang punya trafik.
2. Formulir diuji sampai ke tujuan akhir, bukan hanya sampai muncul pesan berhasil.
3. Pelacakan konversi berfungsi dan tidak menghitung ganda.
4. Situs bisa diindeks — penanda jangan-indeks dari masa pengembangan sudah dilepas.
5. Kredensial sudah berpindah ke pemilik bisnis, bukan tersimpan hanya di vendor.
6. Cadangan pertama sudah dibuat dan cara memulihkannya sudah diuji sekali.
7. Halaman legal tersedia — kebijakan privasi dan ketentuan layanan, terutama bila ada formulir.

Butir keempat adalah kesalahan klasik yang gejalanya baru terasa berminggu-minggu kemudian: situs baru terlihat sempurna, tetapi trafik pencarian tidak pernah datang karena penanda dari masa pengembangan tidak pernah dilepas.

Menyesuaikan alur untuk proyek kecil

Tujuh tahap terdengar berat untuk proyek satu halaman arahan atau perbaikan kecil. Alurnya memang bisa dipadatkan, tetapi bukan dengan menghapus tahap — melainkan dengan menggabungkannya.

Untuk proyek kecil, tahap satu dan dua bisa diselesaikan dalam satu percakapan tiga puluh menit yang menghasilkan setengah halaman catatan. Tahap tiga dan empat bisa digabung menjadi satu putaran desain, asalkan susunannya tetap disepakati lebih dulu di awal pertemuan. Tahap enam tetap tidak boleh dihapus, hanya dipersingkat menjadi satu daftar periksa pendek.

Yang tidak boleh hilang berapa pun kecilnya proyek: tujuan yang tertulis, satu pemutus, catatan persetujuan, dan pemeriksaan sebelum peluncuran. Empat hal itu memakan waktu total kurang dari dua jam, dan justru pada proyek kecil dampaknya paling terasa — karena proyek kecil tidak punya cadangan waktu untuk menyerap kesalahan.

Ringkasan

Tujuh tahap: selaraskan tujuan, petakan isi dan struktur, buat kerangka, desain, kerjakan, tinjau, luncurkan. Putuskan sedini mungkin karena biaya perubahan naik tajam. Tetapkan satu pemutus di tiap sisi. Catat persetujuan dan perubahan, sekalipun hanya satu baris. Dan hitung waktu tunggu, bukan hanya waktu mengerjakan — di situlah sebagian besar tenggat hilang.

Satu hal terakhir yang perlu disebut terang-terangan: semua ini tidak menuntut proses yang berat. Empat dokumen pendek, empat pertemuan, dan satu kabar tertulis mingguan sudah menutupi proyek berukuran menengah secara lengkap. Nilainya bukan pada berkasnya, melainkan pada kenyataan bahwa setiap keputusan punya tempat tinggal — sehingga tidak ada yang perlu menyusunnya ulang dari ingatan dua bulan kemudian.

Dan bila proyek Anda sudah berjalan dan mulai terasa berputar, tanda-tanda awalnya beserta koreksi yang masih mungkin diambil dibahas di artikel tentang tanda bahaya proyek digital.

Ingin proyek website Anda dijalankan dengan alur seperti ini? Bicarakan dengan tim kami.