Alur Kerja Tanpa Rasa Sakit Untuk Pelaporan dan Penyelesaian Masalah

(Ini adalah posting bersponsor.) Kesalahan, bug, dan masalah lainnya pasti akan muncul dalam pengembangan web. Bahkan jika itu bukan kesalahan langsung, klien sering memiliki umpan balik tentang bagaimana sesuatu dirancang, di mana ditempatkan atau bagaimana elemen tertentu bekerja. Itu hanya bagian dari pertunjukan.

Ini bisa menjadi bagian yang sangat menyakitkan dari pertunjukan juga.

Ambil skenario ini, misalnya:

Email #1 dari klien: “Saya tidak dapat melihat tombolnya lagi. Bisakah Anda mengembalikannya ke halaman rumah?”

Email #2 dari Anda: “Tombol mana yang Anda maksud? Bisakah Anda mengirimi saya tangkapan layar? ”

Anda mencoba menelepon klien, tetapi malah mendapatkan pesan suara mereka.

Email #3 dari klien: “Tombol untuk memesan demo.”

Anda melihat tangkapan layar terlampir dan melihat bahwa bagian Pesan Demo masih utuh, tetapi tombolnya tidak muncul. Anda membuka situs web di Chrome dan Safari dan melihatnya di kedua browser: tombol biru besar yang bertuliskan "Jadwalkan Demo". Anda menariknya di iPhone Anda dan melihatnya di sana juga.

Email #4 dari Anda: “Bisakah Anda memberi tahu saya di perangkat dan browser mana Anda mengalami masalah?”

Email #5 dari klien: “Ponsel saya.”

Anda tahu bagaimana rantai pesan ini akan berjalan dan itu hanya akan menyebabkan frustrasi di kedua ujungnya. Belum lagi biaya untuk bisnis Anda setiap kali Anda harus berhenti bekerja untuk mencoba menafsirkan laporan bug dan kemudian menyelesaikannya.

Kemudian, ada biaya bug untuk klien Anda yang harus Anda pikirkan. Ketika terjadi kesalahan setelah peluncuran dan klien Anda secara aktif mencoba mengirimkan lalu lintas ke situs web, bug dapat mengganggu penjualan mereka.

Ketika itu terjadi, menurut Anda siapa yang akan mereka kejar?

Alur Kerja Tanpa Rasa Sakit Untuk Pelaporan Masalah Dan Perbaikan

Tidak masalah apa ukuran bug atau masalahnya. Ketika terdeteksi dan dilaporkan, itu perlu ditangani. Ada beberapa alasan mengapa.

Sebagai permulaan, itu satu-satunya cara Anda akan membuat klien Anda menandatangani proyek sebagai selesai. Selain itu, penyelesaian bug yang cepat dan segera mengarah pada hubungan yang lebih baik dengan klien Anda yang melihat seberapa besar investasi Anda dalam membuat situs web yang mengesankan (dan bebas kesalahan) untuk bisnis mereka. Dan, tentu saja, semakin efisien Anda mengatasi kesalahan, semakin cepat Anda dapat kembali menyelesaikan pekerjaan ini dan beralih ke pekerjaan lain!

Jadi, inilah yang perlu Anda lakukan untuk mengatasi masalah ini dengan lebih efektif dan tanpa rasa sakit.

1. Tetapkan Seseorang Untuk Triase
2. Gunakan Alur Kerja Penyelesaian Masalah
3. Berikan Alat Pelaporan Bug kepada Pengguna Anda
4. Berikan Platform Pelacakan Manajer Triage Anda
5. Bekerja Di Platform Pengujian Lokal
6. Selalu Tutup Loop

1. Tetapkan Seseorang Untuk Triase

Hal pertama yang harus dilakukan adalah memutuskan siapa yang akan melakukan triase masalah.

Jika Anda bekerja sendiri, maka tanggung jawab itu adalah milik Anda. Jika Anda bekerja dalam tim, itu harus pergi ke manajer proyek atau pemimpin pengembang yang dapat mengelola masalah yang dilaporkan sama efektifnya dengan mereka akan mengelola beban kerja tim.

Orang ini kemudian akan bertanggung jawab atas:

• Pemantauan untuk masalah yang dilaporkan.
• Menambahkan bug ke antrian.
• Mengantar mereka melalui alur kerja resolusi.
• Menyelesaikan dan menutup laporan bug.
• Menganalisis tren dan merevisi proses Anda untuk mengurangi kemungkinan munculnya bug yang berulang.

Setelah Anda tahu siapa yang akan mengelola prosesnya, saatnya merancang alur kerja Anda dan membangun serangkaian alat di sekitarnya.

2. Gunakan Alur Kerja Penyelesaian Masalah

Manajer triase Anda tidak dapat melakukan ini sendirian. Mereka akan membutuhkan proses yang dapat mereka ikuti dengan cermat untuk mengambil setiap masalah dari Titik A (deteksi) ke Titik B (resolusi).

Untuk memastikan Anda telah membahas setiap langkah, gunakan alat visualisasi seperti Lucidchart untuk menyusun langkah-langkah atau tahapan alur kerja Anda.

Berikut adalah contoh tampilan diagram alur Anda:

Mari kita uraikan:

Anda akan mulai dengan mengidentifikasi di mana masalah itu terdeteksi dan melalui saluran mana masalah itu dilaporkan. Contoh ini tidak terlalu spesifik, tetapi katakanlah masalah baru yang terdeteksi adalah yang disebutkan sebelumnya: tombol Pesan Demo tidak ada di halaman beranda.

Hal berikutnya yang harus dilakukan adalah menjawab pertanyaan: “Siapa yang menemukannya?” Dalam kebanyakan kasus, ini akan menjadi umpan balik yang dikirimkan oleh klien Anda dari perangkat lunak pelacakan bug Anda (lebih lanjut tentang itu segera).

Selanjutnya, Anda akan masuk ke berbagai tahap yang akan dilalui oleh masalah Anda:

Ini adalah bagian dari proses di mana manajer triase akan menentukan seberapa parah masalah tombol Pesan Demo yang hilang (yang “parah” karena akan merugikan konversi klien). Mereka kemudian akan meneruskannya ke pengembang untuk memverifikasinya.

Bergantung pada berapa banyak pengembang atau pakar materi pelajaran yang tersedia untuk menyelesaikan masalah, Anda mungkin juga ingin memecah tahap ini berdasarkan jenis bug (mis. fungsionalitas yang rusak vs. pembaruan desain).

Terlepas dari itu, setelah bug diverifikasi, dan dalam konteks apa (seperti jika hanya di iPhone 7 atau lebih lama), tiket dipindahkan ke "Sedang Berlangsung".

Terakhir, bagan alur Anda harus menguraikan langkah-langkah selanjutnya untuk masalah yang dapat diselesaikan:

Anda dapat memberi nama langkah-langkah ini sesuka Anda. Dalam contoh di atas, setiap langkah dengan sangat spesifik menjelaskan apa yang perlu terjadi:

• Edisi Baru
• Sedang berlangsung
• Uji
• Memperbaiki
• Memeriksa
• Menyelesaikan
• Tutup Lingkaran.

Untuk menyederhanakan berbagai hal, Anda dapat menggunakan aliran resolusi seperti ini:

• Edisi Baru
• Melakukan
• Sedang mengerjakan
• Selesai
• Arsip.

Bagaimanapun Anda memilih untuk mengatur alur kerja tambalan Anda, pastikan bahwa tambalan bug diuji dan diverifikasi sebelum Anda menutup tiket.

3. Berikan Alat Pelaporan Bug kepada Pengguna Anda

Ketika datang untuk memilih alat pelaporan bug untuk situs web Anda, Anda menginginkan yang akan memudahkan tim dan klien Anda untuk meninggalkan umpan balik dan bahkan lebih mudah bagi Anda untuk memprosesnya.

Salah satu alat yang melakukan ini dengan baik disebut BugHerd.

Pada dasarnya, BugHerd adalah cara sederhana bagi orang non-teknis untuk melaporkan masalah kepada Anda secara visual dan kontekstual. Karena tidak perlu melatih pengguna tentang cara masuk ke alat pelaporan bug atau menggunakannya, Anda harus menghabiskan waktu lebih sedikit dalam proses ini.

Terlebih lagi, BugHerd menghindarkan Anda dari masalah karena harus berurusan dengan bolak-balik tanpa henti yang terjadi ketika umpan balik dikomunikasikan secara verbal dan di luar konteks.

Namun, dengan BugHerd, pengguna memberikan umpan balik ke situs web semudah mereka meninggalkan catatan tempel di meja Anda. Terlebih lagi, umpan balik disematkan di tempat yang tepat di mana bug itu ada.

Mari saya tunjukkan cara kerjanya:

Saat pertama kali menambahkan situs web klien Anda ke BugHerd (ini adalah langkah pertama), Anda akan diminta untuk menginstal ekstensi browser BugHerd. Inilah yang memungkinkan BugHerd untuk menyematkan bilah umpan balik ke situs web.

Ini terlihat seperti ini:

Bilah umpan balik yang disematkan ini memudahkan klien untuk meninggalkan umpan balik tanpa benar-benar mengubah situs web langsung.

Seperti inilah tampilan pelacak bug:

Seperti yang Anda lihat, ini adalah bentuk yang sangat sederhana. Dan, sungguh, yang perlu dilakukan klien Anda adalah memilih elemen pada halaman yang berisi bug, lalu memasukkan detailnya. Sisanya dapat diisi oleh manajer triase Anda.

Saat umpan balik baru ditambahkan, komentar disematkan ke halaman tempat mereka meninggalkannya. Sebagai contoh:

Anda juga akan melihat pada tangkapan layar di atas bahwa tugas yang telah ditetapkan tingkat keparahannya ditandai seperti itu. Mereka juga terdaftar dari atas ke bawah tentang seberapa kritisnya mereka.

Di sisi Anda, Anda memiliki pilihan di mana Anda melihat umpan balik Anda. Anda dapat membuka situs dan meninjau catatan yang disematkan ke setiap halaman. Atau Anda dapat masuk ke aplikasi BugHerd dan meninjau komentar dari papan Kanban Anda:

Secara default, semua bug masuk ke Backlog untuk memulai. Adalah tugas manajer triase Anda untuk mengisi setiap bug dengan detail yang hilang, menugaskan ke pengembang dan memindahkannya melalui langkah-langkah penyelesaian.

Konon, BugHerd melakukan banyak pekerjaan yang lebih membosankan untuk menangkap laporan bug untuk Anda. Misalnya, ketika Anda mengklik salah satu bug yang dilaporkan di papan kanban Anda, sidebar “Detail Tugas” ini akan muncul:

Panel ini memberikan detail tambahan tentang masalah tersebut, menunjukkan tangkapan layar di mana itu ada di situs, dan juga memberi tahu Anda siapa yang meninggalkan komentar.

Terlebih lagi, BugHerd menangkap “Info Tambahan”:

Dengan cara ini, Anda tidak perlu khawatir tentang klien yang tidak memberi Anda konteks masalah yang lengkap. Detail ini memberi tahu Anda perangkat dan browser apa yang mereka gunakan, seberapa besar layarnya, dan resolusi warna apa yang mereka gunakan untuk melihatnya.

Anda juga bisa melihat kode elemen buggy. Jika ada sesuatu yang benar-benar rusak atau tidak dikodekan dengan benar, Anda mungkin dapat menemukannya dari sini.

Secara keseluruhan, BugHerd adalah alat yang hebat untuk menyederhanakan berapa banyak yang harus dilakukan setiap orang dari semua sisi dan memastikan setiap permintaan ditangani tepat waktu.

4. Berikan Platform Pelacakan kepada Manajer Triage Anda

Jika Anda ingin membuat alur kerja ini sesederhana mungkin, Anda dapat menggunakan dasbor BugHerd untuk melacak dan mengelola permintaan Anda:

Manajer triase dan tim pengembang Anda mungkin ingin menggunakan sesuatu untuk melengkapi kemampuan pelaporan bug BugHerd. Tapi semoga berhasil meminta klien Anda untuk menggunakan platform seperti Jira untuk membantu Anda mengelola bug.

Dalam hal ini, saya akan merekomendasikan menambahkan alat lain ke alur kerja ini.

Beruntung bagi Anda, BugHerd terintegrasi dengan mulus dengan pelacakan masalah dan perangkat lunak helpdesk seperti Jira, Zendesk, dan Basecamp, jadi Anda tidak perlu khawatir menggunakan banyak alat untuk mengelola berbagai bagian dari proses yang sama. Setelah koneksi dibuat antara dua platform Anda, tugas apa pun yang dibuat di BugHerd akan secara otomatis disalin ke pusat penyelesaian masalah Anda.

Sekarang, jika ada alat yang sudah digunakan tim Anda, tetapi BugHerd tidak terintegrasi secara langsung, tidak apa-apa. Anda dapat menggunakan Zapier untuk membantu Anda terhubung dengan lebih banyak platform.

Misalnya, ini adalah betapa mudahnya membuat "zap" secara instan yang menyalin tugas BugHerd baru ke kartu Trello Anda. Dan itu semua terjadi dari dalam BugHerd!

Setelah koneksi dibuat, manajer triase Anda dapat mulai bekerja dari manajemen tugas atau platform pelacakan masalah yang dipilihnya. Dalam hal ini, inilah yang terjadi ketika Zapier menghubungkan BugHerd dan Trello:

Ini adalah tugas baru yang baru saja saya buat di BugHerd. Dalam beberapa detik, kartu tersebut ditempatkan ke dalam proyek dan daftar Trello yang tepat yang saya konfigurasikan untuk zap:

Ini akan membuat pekerjaan manajer triase Anda lebih mudah karena mereka tidak akan dibatasi oleh tahapan yang tersedia di BugHerd sementara juga masih memiliki semua informasi yang sama dengan mudah di ujung jari mereka.

5. Bekerja di Platform Pengujian Lokal

Saat bug dilaporkan, Anda tidak ingin menguji dan menerapkan perbaikan yang diasumsikan di situs web langsung. Itu terlalu berisiko.

Alih-alih, selesaikan masalah dari platform pengujian lokal. Artikel ini memiliki beberapa saran bagus tentang alat pengembangan lokal untuk WordPress yang dapat Anda gunakan untuk ini.

Alat-alat ini memungkinkan Anda untuk:

• Buat salinan situs web Anda dengan cepat.
• Reproduksi bug dengan kondisi server yang sama.
• Uji kemungkinan perbaikan sampai Anda menemukan satu yang berfungsi.

Baru setelah itu Anda harus bekerja untuk menambal bug di situs web.

6. Selalu Tutup Loop

Akhirnya, terserah kepada manajer triase Anda untuk menyelesaikan setiap masalah secara formal.

Pertama, mereka harus memberi tahu klien (atau pengunjung) yang awalnya melaporkan masalah bahwa masalah tersebut telah diselesaikan. Transparansi dan akuntabilitas semacam ini akan memberi agensi Anda tampilan yang lebih halus sambil membantu Anda membangun kepercayaan dengan klien yang mungkin terkesima dengan menemukan bug sejak awal.

Setelah semuanya ditutup di sisi klien, manajer triase kemudian dapat mengarsipkan laporan bug.

Seharusnya tidak berakhir di sana.

Seperti manajer proyek tradisional, manajer triase harus secara teratur melacak tren serta tingkat keparahan keseluruhan bug yang ditemukan di situs web mereka. Data mungkin mengungkapkan bahwa ada masalah yang lebih dalam. Dengan begitu, tim Anda dapat fokus untuk menyelesaikan masalah mendasar dan berhenti menghabiskan begitu banyak waktu untuk memperbaiki jenis bug dan masalah yang sama.

Membungkus

Pikirkan tentang semua cara di mana masalah dan bug dapat dilaporkan: melalui formulir kontak, melalui email, melalui telepon, melalui obrolan atau, lebih buruk lagi, di forum publik seperti media sosial.

Sekarang, pikirkan tentang semua orang berbeda yang mungkin melaporkan masalah ini kepada Anda: tim Anda, klien, pelanggan klien Anda, seseorang yang secara acak menemukannya saat melihat situs web dan seterusnya.

Ada terlalu banyak variabel dalam persamaan ini, yang membuatnya mudah untuk melupakan masalah terbuka. Lebih buruk lagi, ketika umpan balik datang melalui samar-samar, subjektif, atau tidak dapat dijelaskan tanpa konteks apa pun, menjadi terlalu sulit untuk menyelesaikan masalah secara lengkap atau tepat waktu.

Namun, dengan sistem pelaporan, pelacakan, dan pengorganisasian umpan balik yang tepat, Anda dapat menertibkan kekacauan ini dan secara lebih efektif menghapus bug yang ditemukan di situs web Anda.