Apakah Anda suka terganggu dengan menyelesaikan masalah mendesak dalam obrolan kerja sambil melakukan tugas saat ini? Kami pikir tidak!
Bayangkan sebuah situasi: Anda memulai tugas, tetapi Anda terganggu oleh notifikasi dalam obrolan, di mana Anda dengan segera diminta untuk membantu dengan pertanyaan dari pengguna. Dan sekarang Anda sudah berpartisipasi dalam diskusi aktif dan memahami apakah ini bug atau fitur.
Sekarang bayangkan selain Anda, ruang obrolan ini memiliki seluruh departemen pengembangan, yang terdiri dari 80+ orang, dan masing-masing peserta terlibat dalam diskusi ini.
Bersama kami di SuperJob, dukungan teknis dalam setiap situasi yang tidak dapat dipahami segera mengobrol di Slack dan dengan demikian mengalihkan semua peserta dari kegiatan saat ini. Karena itu, kami, departemen pengujian, mencoba mengubah proses bekerja dengan bug dari pengguna.
Sebelumnya, proses bekerja dengan bug dari pengguna adalah sebagai berikut:
- Umpan balik diterima dari pengguna dan dikirim ke spesialis dukungan teknis;
- seorang spesialis dukungan teknis menemukan rinciannya, tetapi tidak mereproduksi masalah, tetapi segera memulai tugas di Jira dalam proyek dukungan teknis;
- tugas dilemparkan ke ruang obrolan terpisah di Slack (dan ada 6 dari mereka, omong-omong, pada masalah pelamar, pengusaha, dan untuk setiap platform dalam aplikasi);
- dalam obrolan, penguji mengambil tugas ini dan mulai memahami, melokalisasi masalah dan mencari tahu bagaimana seharusnya bekerja;
- Selain tester, para pengembang juga mengambil bagian dalam obrolan dan mengambil bagian aktif dalam diskusi;
- setelah semua klarifikasi, penguji memindahkan tugas ke proyek pengembangan yang diinginkan, mengubah nama, dan memperbaiki deskripsi.
Pada akhirnya, ternyata banyak waktu dihabiskan untuk membahas dan mengecek satu masalah sekaligus oleh beberapa ahli. Juga, uraian tugas tidak selalu memungkinkan Anda untuk dengan cepat memahami esensi masalah, jadi Anda harus membuka korespondensi dukungan teknis dengan pengguna, dan kemudian menghabiskan lebih banyak waktu mengedit tugas ini.
Banyak masalah bukan bug dan umumnya tidak mencapai pengembang. Tetapi pada saat yang sama, pengembang sudah terlibat dalam proses diskusi, mengalihkan perhatian dari tugas mereka.
Kami memutuskan bahwa kami perlu mengubah proses ini dan membuat dukungan teknis lebih mandiri.
Hal pertama yang ingin kami ubah adalah
menyingkirkan pemeriksaan ganda bug oleh tester.Solusinya adalah ini: kami menggambarkan alur kerja yang dilakukan penguji, mengubahnya sedikit, dan menyerahkannya ke spesialis dukungan teknis. Sekarang mereka harus menjalaninya ketika bekerja dengan masalah dari pengguna.
Jelaskan secara singkat alur kerja ini, sekarang spesialis dukungan teknis secara independen memeriksa persyaratan sebelum meluncurkan bug, perlu mereproduksi kesalahan dan menempatkan tugas ke dalam proyek pengembangan.
Jika situasinya tidak mereproduksi, tugas dimulai dalam proyek dukungan teknis dan "ditangguhkan" sampai kontak pengguna berikutnya. Jika ada permintaan baru dari pengguna, pusat teknologi perlu mencoba lagi untuk mereproduksi masalah, dan jika itu mereproduksi, maka transfer tugas ke proyek pengembangan.
Jika keluhan yang diulang juga tidak direproduksi, maka tugas tersebut masih ditransfer ke proyek pengembangan dengan komentar wajib bahwa masalahnya tidak dapat direproduksi. Mungkin dalam situasi ini, para pengembang, untuk bagian mereka, akan dapat mencari tahu dan menyelesaikan masalah.
Jadi kami tidak menghabiskan banyak waktu untuk satu panggilan dan hanya dalam kasus panggilan berulang kami menghubungkan pengembang.
Pro: kami menghemat waktu spesialis pengujian, dan seringkali juga pengembang yang melihat pertanyaan dalam obrolan dan terhubung ke klarifikasi.
Masalah kedua kami adalah
desain bug itu sendiri , yang sudah
nama tidak informatif, kacau, dan kadang-kadang hanya deskripsi misterius.
Sebagai contoh:
Solusi: melalui contoh, kami memberi tahu dan menunjukkan cara kami menulis nama untuk bug menggunakan prinsip "Apa? Dimana? Kapan? ”
Misalnya, nama tugas "Masalah dari" Pekerjaan di situs Anda "setelah diproses menjadi lebih transparan:" Pekerjaan di blok "Pekerjaan di situs Anda" tidak ditampilkan ketika Anda pergi ke bagian siaran ". Apa "masalah" yang terjadi, menjadi jelas bagi semua orang hanya dari namanya.
Kami sepakat untuk menggunakan template untuk deskripsi. Kami memiliki mereka ditambahkan ke Jira. Saat membuat bug, Anda harus memilih template yang diinginkan tergantung pada platform dan mengisinya.
Semua informasi dicatat dalam instruksi dalam Confluence, yang selalu dapat diakses.
Pro: menjadi lebih mudah untuk mencari bug di Jira, dan dengan namanya Anda dapat langsung menentukan apa esensinya tanpa masuk ke tugas. Deskripsi tersebut menjadi terstruktur dan lebih mudah dipahami oleh pengembang.
Gangguan
ketiga dari semua adalah
kehadiran beberapa ruang obrolan dengan dukungan teknis.
Solusi: "Ruang Obrolan Lebih Banyak!"Kami memutuskan untuk hanya membuat satu # dukungan chat, dan menutup sisanya. Sekarang semua karyawan internal dilemparkan dari masalah yang ditemukan ke dalamnya, dan hanya orang-orang dukungan teknis yang menjawab. Mereka melakukan pengecekan ulang dan memulai tugas.
Pro: sekarang ada satu titik masuk di mana Anda dapat melaporkan masalah yang ditemukan.
Sebelumnya, pengembang bisa melihat semacam bug, tetapi tidak tahu harus melaporkannya ke mana. Pertama, Anda harus mencari tahu obrolan mana yang harus dibuang. Itu sulit ... Oleh karena itu, beberapa tidak repot-repot dan meninggalkan semuanya apa adanya (baik, atau yang sadar disingkirkan ke penguji).
Tetapi, tentu saja, ada beberapa kesulitan dalam menerapkan pendekatan ini. Misalnya, spesialis dukungan teknis tidak selalu dapat melokalisasi masalah dengan benar, menentukan apakah itu backend atau frontend. Dan karena ini, ada risiko mendapatkan bug di proyek yang salah atau di tim yang salah, dan kemudian lagi kehilangan waktu untuk mentransfer tugas dari satu bagian ke bagian lain.
Masih ada kesalahan dalam deskripsi dan nama bug. Oleh karena itu, sementara itu perlu untuk melihat melalui tugas-tugas untuk menghilangkan kekurangan ini, tetapi jumlahnya tidak begitu kritis.
Setelah semua inovasi, alur kerja kami terlihat seperti ini:
- spesialis dukungan teknis telah menjadi lebih mandiri, mereka tidak perlu menunggu penguji memeriksa ulang bug;
- bug dari pengguna dimulai di Jira lebih cepat dan dapat dikembangkan lebih awal;
- penguji dan pengembang tidak terganggu dengan tugas mereka;
- pengembang sekarang dapat
mengatur holivar untuk mengobrol di ruang obrolan tentang topik yang lebih menarik.
Dan bagaimana proses bekerja dengan bug dari pengguna diatur di perusahaan Anda? Bagikan contoh Anda :)