Menggabungkan tidak kompatibel: tim pengembangan produk dan dukungan semua digulung menjadi satu

Banyak ahli di bidang pengembangan perangkat lunak percaya bahwa tidak mungkin untuk menggabungkan pengembangan dan dukungan pengguna dalam satu tim. Salah satu atau yang lainnya. Secara umum, dukungan harus diberikan kepada individu.

Hari ini saya ingin memberi tahu Anda tentang bagaimana kami di Odobrim.ru berhasil menggabungkan yang tidak kompatibel, atau lebih tepatnya, bagaimana tim pengembangan dapat mendukung produk. Itu akan menjadi 2-3 garis dukungan pada saat yang sama.

Odobrim.ru adalah layanan online gratis untuk memilih kartu kredit, pinjaman, dan pinjaman untuk perorangan, terlepas dari bank.

Tugas kami : untuk membantu klien mendapatkan dan memelihara produk pinjaman optimal yang menyelesaikan tugas-tugas klien.

Proses penanganan panggilan disusun sebagai berikut

gambar

1. "Layanan Layanan Pelanggan" melayani pelanggan kami - garis dukungan pertama. Ya, ya, di tempat yang baik itu ada :))

"Layanan Layanan Pelanggan" membantu pengguna dengan semua pertanyaan yang muncul saat bekerja dengan layanan ini. Perusahaan mana pun yang peduli dengan pelanggannya harus memiliki lini dukungan pertama, yang dapat Anda hubungi untuk bantuan sepanjang waktu.
Jika "Layanan Layanan Pelanggan" dapat membantu pelanggan, baris berikutnya tidak akan dimulai. Jika tidak, maka banding akan dimulai dan dikirim ke baris berikutnya. Sejauh ini tidak ada yang supranatural.

Dan setelah itu, biasanya ada dua garis dukungan lagi, tetapi kami memiliki satu: kami menggabungkan garis dukungan kedua dan ketiga. Ini terjadi setelah produk memasuki pasar, dan kami telah hidup selama sekitar dua tahun. Dan kita hidup dengan sempurna!

2. Pemantauan permintaan pengguna dilakukan secara teratur.
Insinyur yang bertugas dipanggil secara sukarela untuk panggilan tugas mingguan.
Papan rujukan mirip dengan papan Kanban.
Semuanya sangat mudah dikonfigurasi di dalamnya:

gambar

3. Klasifikasi awal banding dibuat oleh insinyur yang bertugas dan, berdasarkan hasilnya, dibuat secara terpisah Bug (bug dengan mengacu pada dokumentasi / persyaratan) atau Story (tugas). Mereka melekat pada sirkulasi. Kami memiliki tenggat waktu untuk memperbaiki kesalahan dan petugas berusaha keras untuk menangkapnya.

4. Pada tahap selanjutnya, Bug yang diperbaiki diperbaiki oleh pengembang (Blocker, Critical). Kemudian verifikasi dan konfirmasi koreksi dilakukan oleh insinyur tugas

5. Cerita (tugas) ditransfer ke PO (pemilik produk) untuk diprioritaskan.

Selama 2 tahun, tim pengembangan telah memproses lebih dari 270 panggilan prioritas berbeda dari unit bisnis kami dan pengguna dari antara mereka yang tidak dapat ditangani oleh garis dukungan pertama.

Kelebihan dari pendekatan ini


  • Banding dari pelanggan dan unit bisnis tidak hilang dan dikumpulkan di satu papan.
  • Tim melihat semua masalah utama dari produk dan tertarik untuk menyelesaikannya, yaitu semakin mendekati pengguna layanannya, yang secara positif mempengaruhi kualitas layanan dan produk secara keseluruhan.
  • Setiap pengembang, menyadari bahwa ia harus bertugas pada panggilan, mencoba untuk menulis kode lebih baik agar tidak menciptakan masalah tambahan untuk dirinya sendiri dan rekan-rekannya.
  • Selalu ada insinyur yang bertanggung jawab.
  • Keterlibatan tim dalam memecahkan masalah produk yang umum sedang tumbuh.
  • Pemantauan konstan tanpa peraturan tambahan.

Kontra dari pendekatan ini


Anggota tim dituntut memiliki tingkat profesionalisme, tanggung jawab, dan minat yang tinggi. Dan keberanian untuk dipanggil bertugas.

Jika Anda mengalami skema organisasi dukungan serupa, bagikan pengalaman Anda dalam komentar.

Source: https://habr.com/ru/post/id481798/


All Articles