Beberapa waktu yang lalu saya membaca sebuah buku berjudul Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days yang ditulis oleh Jake Knapp, John Zeratsky, dan Braden Kowitz. Ketiganya adalah konsultan Google Venture, yang membantu banyak perusahaan untuk mengembangkan produk ataupun layanan mereka. Dalam buku ini membahas tentang 5 Days Design Sprint.
Salah satu penekanan penting dalam buku tentang 5 Days Design Sprint ini yaitu bagaimana mereka melakukan aktifitas yang berkaitan dengan pembuatan produk baru ataupun mempersiapkan sebuah fitur baru. Strategi yang digunakan adalah mengelola waktu seefisien mungkin dengan hanya melakukannya selama lima hari saja.
Sprint ini dilakukan untuk memastikan bahwa tim yang kita punya bisa menjawab pertanyaan besar pada saat meluncurkan produk atau fitur baru, yaitu Apakah pelanggan akan menggunakan produk/fitur baru yang diluncurkan?
Proses lima hari dilakukan mulai dari hari senin hingga hari jumat. Beberapa aktifitas yang dilakukan antara lain:
- Senin : Memetakan masalah dan memilih yang paling penting yang ingin Anda selesaikan pada akhir minggu
- Selasa : Membuat sketsa beberapa solusi di atas kertas
- Rabu : Membuat keputusan tentang solusi terbaik dan rubah menjadi hipotesis yang dapat diuji
- Kamis : Membangun prototipe
- Jumat : Pengujian melalui wawancara
Pertanyaan lebih lanjut adalah apakah hal ini masuk akal?
Kenapa hanya lima hari saja?
Bagaimana Jika?
Menggunakan periode waktu yang lebih lama: Seperti sprint selama dua minggu? Mungkin saja hal ini bisa berjalan dengan baik, tetapi itu tidak akan seefektif dengan rentang lima hari saja. Mengapa? Karena akhir pekan. Akhir pekan menyebabkan hilangnya kontinuitas. Anda lebih cenderung untuk memindahkan pekerjaan yang seharusnya dilakukan pada hari Jumat hingga Senin minggu depan.
Menggunakan periode waktu yang lebih singkat: mungkin tidak cukup untuk membuat dan menguji prototipe. Anda akan melelahkan untuk mencapai semuanya. Keajaiban nomor lima juga berlaku ketika Anda melakukan wawancara pada hari Jumat. Harus ada paling banyak lima orang saja. Mengapa? Sekali lagi, melakukan lima percakapan dengan pewawancara Anda cukup baik untuk menemukan pola masalah dengan produk Anda.
Sebuah penelitian tentang pengujian kegunaan yang telah dilakukan oleh Nielsen membuktikan bahwa, sebagian besar waktu, wawasan terungkap setelah meminta hanya 5 orang. Yang mengatakan, mengapa menghabiskan lebih banyak waktu dan usaha, sementara hasilnya sama saja?
Meskipun demikian, waktu lima hari ini masih terdengar tidak realistis. Saya juga punya pemikiran itu sejak awal. Namun, dalam buku itu, Jake (penulis) sebenarnya telah membuat argumen yang sangat jelas bahwa itu layak secara praktis, mengingat telah banyak tim yang telah menerapkan kerangka kerja ini dengan sukses. Ada puluhan tips dan saran yang tercantum dalam buku ini. Beberapa catatan yang saya dapatkan dari buku ini antara lain:
Tetapkan tenggat waktu
Tujuan penetapan tenggat waktu ini adalah untuk berkomitmen pada diri Anda dengan tujuan sprint. Saya tahu ini kedengarannya mudah dilakukan, tetapi dalam praktiknya, jarang ada orang yang bisa bertahan pada target mereka. Ini semua tentang psikologi, ini semua tentang Anda. Jika Anda dapat menipu pikiran Anda, hal-hal akan mudah dicapai. Beberapa pendekatan yang dapat Anda ikuti:
- Bagikan tenggat waktu dengan yang lain: terutama jika Anda berada di proyek individu, itu bekerja sebagian besar waktu. Karena itu memaksa Anda untuk menyelesaikan tujuan tepat waktu, sehingga Anda tidak merasa malu dengan siapa pun yang berbagi tenggat waktu dengan Anda.
- Tunjukkan hasilnya: sekali lagi, ini akan mengikat Anda dengan pekerjaan yang Anda komit sejak awal. Dalam pengembangan perangkat lunak, biasanya sesi demo pada akhir setiap sprint, di mana user dapat melihat fitur atau perubahan apa yang telah dilakukan selama periode tersebut.
Membuat keputusan
Akan ada banyak waktu selama 5 Days Design Sprint bahwa Anda akan terjebak di sekitar puluhan ide dan solusi dari brainstorming. Pilihannya bagus, tapi terlalu banyak dari mereka adalah beban. Selalu ada ketidaksepakatan dalam diskusi kelompok, yang mengarah pada pertemuan tanpa akhir dan email yang mungkin menguras otak Anda. Bagian tersulit adalah menentukan solusi mana yang harus dibuat prototipe dan tes oleh tim. Dengan batas lima hari, Anda harus menangani situasi ini dengan tepat:
Heat Map Vote – Berikan masing-masing anggota tim Anda stiker titik, dan biarkan mereka memberikan suara pada gagasan yang paling mereka sukai. Ya, demokrasi membuat orang merasa senang, karena itu memastikan mereka akan didengar. Setelah ini, papan tulis Anda akan terlihat seperti peta panas, tempat Anda dapat dengan mudah mengidentifikasi ide yang paling menarik.
Otoritas Pengambil Keputusan – Kadang-kadang demokrasi tidak berfungsi, saat itulah Penentu harus berpadu. Orang yang memiliki otoritas pengambilan keputusan akhir, biasanya CEO, Manajer Produk, Kepala Desain atau Pemimpin Tim. Biasanya, dia memiliki lebih banyak suara (yang disebut Supervote) daripada siapa pun di tim sprint, dan apa pun yang dia pilih adalah apa yang akan prototipe dan uji tim Anda
Meskipun demikian, melakukan semua ini tidak sepenuhnya memastikan bahwa idenya benar. Terkadang sang pengambil keputusan bisa saja salah, membuat Prototipe juga salah. Tapi itu tidak masalah. Melihat sisi baiknya, Anda hanya kehilangan satu minggu untuk mengetahui ide itu tidak berhasil, daripada menghabiskan bertahun-tahun kemudian untuk menentukan formula yang benar.
Fasilitator
Fasilitator adalah orang yang paling penting selama 5 Days Design Sprint. Seperti namanya, dia akan melakukan apa saja untuk memaksimalkan pertemuan. Saya menyadari peran ini memiliki banyak kesamaan dengan Scrum Master dalam tim Agile. Saya menduga mereka sama, hanya berbeda dalam penggunaan istilah. Dalam bukunya, Jake menguraikan kegiatan yang harus dilakukan seorang Fasilitator:
- Minta izin: Tidak ada yang mau dipesan atau dengarkan orang yang tidak mereka inginkan. Lebih dari biasanya, Anda perlu menyela ketika orang lain berbicara sehingga rapat dapat selesai tepat waktu. Yang mengatakan, Anda sebaiknya meminta izin mereka di muka, dengan hanya mengatakan sesuatu seperti ini: “Saya akan memfasilitasi pertemuan dan melacak waktu dan proses, jadi kalian tidak harus melakukannya. Kedengarannya oke? “. Mungkin tidak semua akan mengatakan ya, tetapi triknya adalah Anda sudah memberi mereka kesempatan untuk menolak (yang kemungkinan besar tidak akan mereka lakukan), sehingga mereka perlu menghormati aturan tersebut.
- Selalu tangkap kemudian lanjutkan: tim akan memberikan selusin ide sambil bertukar pikiran dan tugas Anda adalah mencatat ide-ide kunci di papan tulis. Mengajukan pertanyaan seperti, “Apakah pemahaman saya benar untuk menulis seperti ini”, atau “Bagaimana saya menangkapnya?”. Ketika percakapan tampaknya tidak menuju ke mana-mana, Anda perlu meringkasnya kembali dengan, misalnya, “Apakah ada cara untuk mencatatnya di sini dan melanjutkan?”
- Ajukan pertanyaan yang jelas: tidak ada pertanyaan yang bodoh, kecuali Anda tidak bertanya. Meskipun pertanyaan sudah memiliki jawaban yang diketahui oleh semua orang, menanyakannya memastikan tidak ada salah tafsir, dan terkadang wawasan utama muncul darinya.
- Sering-seringlah beristirahat: ini meningkatkan produktivitas. Istirahat 10 untuk setiap 60-90 menit akan ideal.
- Makan siang terlambat: Saya pikir itu tergantung pada area geografis atau budaya di tempat kerja Anda, di mana orang makan siang di tengah hari atau tidak memilikinya sama sekali. Meskipun demikian, makan siang pada jam satu siang akan menjadi sempurna karena membagi hari menjadi dua, di mana manusia dapat tetap fokus sepenuhnya ( jam sepuluh pagi sampai jam satu siang dan kemudian jam dua siang sampai jam lima sore)
- Makan ringan dan sering : hindari makan siang yang berat, atau Anda akan menguap dan mengganggu orang lain selama seluruh pertemuan.
Storyboard
Kadang-kadang ketika Anda membangun produk yang keren, maka Anda tiba-tiba menyadari bahwa produk ini kacau, karena tidak lagi sesuai dengan visi Anda, atau beberapa alasan sederhana seperti “Tombol ini di sini tidak akan berfungsi”, “Mengapa kita perlu tangkapan layar ini? “, atau” Apa yang harus terjadi setelah pengguna mengklik ini? “, dll.
Jawabannya adalah Storyboard. Jika Anda terbiasa dengan Agile, Anda harus tahu tentang Roadmap Produk. Saya percaya Storyboard dan Roadmap Produk berbagi beberapa kesamaan. Keduanya membantu Anda membayangkan prototipe Anda yang sudah jadi, dan memastikan Anda tidak akan terjebak di tengah jalan. Anda akan menggunakan storyboard untuk membayangkan prototipe Anda yang sudah jadi, sehingga Anda dapat menemukan masalah dan titik-titik kebingungan sebelum prototipe dibuat . Storyboarding adalah praktik umum dalam produksi film.
Beginilah tampilan storyboard ketika tim Blue Bottle Coffee membuat situs web pada awalnya. Ini adalah skenario yang menggambarkan bagaimana pengguna berinteraksi dengan aplikasi.
