Dalam artikel ini, saya akan membagikan pengalaman saya dalam memilih ide untuk mengembangkan fungsionalitas produk kami dan memberi tahu Anda cara mempertahankan vektor pengembangan utama.
Kami sedang mengembangkan sistem penagihan otomatis (ASR) - penagihan. Term
Kehidupan produk kami adalah 14 tahun. Selama waktu ini, sistem telah beralih dari versi pertama dari tarif industri ke kompleks modular yang terdiri dari 18 produk yang saling melengkapi. Salah satu aspek terpenting dari umur panjang untuk program adalah pengembangan berkelanjutan. Dan untuk pengembangan, dibutuhkan ide.
Gagasan
Sumber
Ada 5 sumber:
- Teman utama pengembang sistem informasi perusahaan adalah klien . Dan klien adalah citra kolektif para pembuat keputusan, sponsor proyek, pemilik dan eksekutif proses, spesialis TI rumahan, pengguna biasa, dan sejumlah besar individu yang berbeda minat. Penting bagi kami bahwa masing-masing perwakilan klien berpotensi menjadi pemasok ide. Dalam kasus terburuk, kami hanya mendapatkan umpan balik negatif tentang masalah dalam sistem. Paling-paling, di sisi klien ada seseorang yang selalu menjadi sumber ide untuk perbaikan, memberikan informasi terstruktur tentang kebutuhan klien.
- Penjual dan pengelola akun kami adalah sumber gagasan terpenting kedua untuk peningkatan. Mereka banyak berkomunikasi dengan perwakilan industri dan secara aktif, menerima permintaan langsung untuk fungsi penagihan dari pelanggan potensial. Penjual dan akun harus mengetahui semua perubahan signifikan dalam fungsi mereka dan pembaruan perangkat lunak terbaru dari pesaing, untuk dapat membenarkan pro dan kontra dari solusi yang berbeda. Karyawan inilah yang pertama kali merasakan jika beberapa kemampuan penagihan menjadi standar de facto, yang tanpanya perangkat lunak tidak dapat dianggap lengkap.
- Pemilik produk adalah salah satu manajer puncak kami atau manajer proyek yang sangat berpengalaman. Dia mengingat tujuan strategis perusahaan dan menyesuaikan rencana pengembangan produk sesuai dengan mereka.
- Seorang arsitek , seseorang yang memahami kemungkinan dan keterbatasan dari solusi teknologi yang dipilih / digunakan dan dampaknya terhadap pengembangan produk.
Pengembangan, pengujian tim. Orang yang terlibat langsung dalam pengembangan produk.
Klasifikasi banding
Dari sumber kami menerima data mentah - surat, tiket, permintaan verbal. Semua
banding diklasifikasikan:
- Konsultasi dengan makna "Bagaimana cara melakukannya?", "Bagaimana cara kerjanya?", "Mengapa tidak berhasil?", "Saya tidak mengerti ...". Jenis panggilan ini masuk ke Jalur Dukungan Level 1. Kemungkinan kualifikasi ulang konsultasi dalam jenis aplikasi lain.
- Insiden dengan arti "Tidak berfungsi" dan "Kesalahan". Ditangani oleh 2 dan 3 Garis Dukungan. Jika perlu, perbaikan cepat dan pelepasan tambalan dapat ditransfer dari dukungan segera ke pengembangan. Dimungkinkan untuk melatih kembali permintaan untuk perubahan dan mengirimkannya ke jaminan simpanan.
- Permintaan untuk perubahan dan pengembangan . Masuk ke tumpukan produk dengan melewati Garis Dukungan. Tetapi bagi mereka ada prosedur pemrosesan yang terpisah.
Ada statistik tentang banding seperti itu - segera setelah rilis, jumlah banding meningkat 10-15% untuk waktu yang singkat. Selain itu, ledakan panggilan terjadi ketika klien baru dengan sejumlah besar pengguna datang ke layanan cloud kami. Orang-orang belajar untuk menggunakan fitur-fitur baru dari perangkat lunak, mereka memerlukan saran. Bahkan klien kecil di awal pekerjaan dalam sistem dengan mudah membakar lebih dari 100 jam konsultasi per bulan. Karenanya, saat menghubungkan klien baru, kami selalu menyediakan waktu untuk konsultasi awal. Seringkali kita bahkan menyorot spesialis tertentu. Biaya sewa, tentu saja, tidak membayar kembali biaya tenaga kerja ini, tetapi seiring waktu situasinya diratakan. Periode adaptasi memakan waktu, dari biasanya, dari 1 hingga 3 bulan, maka kebutuhan untuk konseling berkurang secara signifikan.
Sebelumnya, kami menggunakan solusi yang ditulis sendiri untuk menyimpan panggilan. Namun secara bertahap beralih ke produk Atlassian. Pertama, kami mengembangkan pengembangan untuk membuatnya lebih mudah untuk bekerja pada Agile, kemudian mendukung. Sekarang semua proses penting hidup di Jira SD, ditambah lagi disediakan oleh berbagai plugin untuk Jira, plus Confluence. Solusi yang ditulis sendiri tetap hanya pada proses yang tidak penting untuk kegiatan perusahaan. Ternyata tugas kami sekarang lintas sektor, dapat ditransfer antara dukungan dan pengembangan tanpa berpindah dari satu sistem ke sistem lainnya.
Dari bundel ini kita dapat memperoleh data tentang semua tugas, biaya tenaga kerja terencana dan aktual, menggunakan berbagai opsi penetapan tarif untuk pelanggan dan menghasilkan dokumentasi untuk kebutuhan internal dan melaporkan kepada pelanggan.
Ubah Pemrosesan Permintaan
Biasanya, permintaan semacam itu datang dalam bentuk persyaratan fungsional. Analis kami mempelajari permintaan, menghasilkan spesifikasi dan ToR tingkat atas. Itu melewati spesifikasi dan pernyataan kerja kepada orang yang mengajukan permintaan persetujuan ini - kita harus yakin bahwa kita berbicara bahasa yang sama dengan pelanggan.
Setelah menerima konfirmasi dari pelanggan bahwa kami memahami satu sama lain dengan benar, analis menulis permintaan ke jaminan simpanan produk.
Manajemen Produk
Tumpukan menumpuk permintaan masuk untuk perubahan dan pengembangan. Setiap enam bulan sekali, sebuah dewan teknis diadakan, yang terdiri dari seorang direktur, pemeliharaan, pengembangan, penjualan, dan manajer arsitek sistem. Dalam format diskusi, dewan mem-parsing dan memprioritaskan aplikasi dari jaminan simpanan dan mengoordinasi 5 tugas pengembangan untuk implementasi dalam rilis berikutnya.
Bahkan, dewan teknis menanggapi persyaratan industri dan pasar, mengingat kebutuhan yang dicatat dalam aplikasi. Segala sesuatu yang memiliki sedikit relevansi tetap ada dalam tumpukan dan tidak mencapai pengembangan.
Klasifikasi Permintaan Perubahan dan Keuangan
Pembangunan itu mahal. Karenanya, kami akan segera memberi tahu Anda opsi apa yang dapat kami miliki jika permintaan perubahan datang dari klien, bukan karyawan.
Permintaan perubahan diklasifikasikan sebagai berikut: kebutuhan industri atau karakteristik individu dari perusahaan; sejumlah besar fungsi baru atau perbaikan kecil. Perbaikan kecil dan permintaan individu diproses tanpa embel-embel. Permintaan individu dihitung dan diimplementasikan untuk klien tertentu sebagai bagian dari pekerjaan proyek dengannya.
Jika ini bukan kebutuhan industri besar dan cakupan fungsi besar, maka keputusan dapat dibuat untuk mengembangkan modul terpisah baru, yang akan dijual di samping fungsi utama. Jika permintaan semacam itu diterima dari klien, kami dapat mengasumsikan biaya pengembangan modul, menyediakan klien dengan modul gratis atau dengan pembayaran parsial, dan menempatkan modul pada penjualan publik. Klien mengasumsikan bagian dari beban metodologis dalam situasi seperti itu dan pada dasarnya melakukan implementasi percontohan modul.
Jika ini adalah kebutuhan industri besar, maka keputusan dapat dibuat untuk memasukkan fungsionalitas baru dalam produk dasar. Biaya dalam kasus ini sepenuhnya ditanggung oleh kami, dan fungsionalitas baru muncul dalam versi program saat ini.
Pelanggan lama diberikan pembaruan.
Mungkin juga beberapa pelanggan memiliki kebutuhan yang serupa, tetapi tidak menarik produk massal. Dalam hal ini, kami dapat mengirimkan spesifikasi kepada pelanggan ini dan menawarkan untuk berbagi biaya pengembangan di antara mereka. Hasilnya, semua orang menang: pelanggan menerima implementasi fungsi dengan biaya rendah, kami memperkaya produk, setelah beberapa saat peserta pasar yang tersisa juga dapat menerima fungsionalitas untuk penggunaannya.
Devops
Pengembangan menyiapkan dua rilis utama per tahun. Dalam setiap rilis, waktu disediakan untuk implementasi 5 tugas yang diterima dari dewan teknis. Jadi, untuk cairan, kami tidak pernah lupa tentang pengembangan produk.
Setiap rilis melewati serangkaian pengujian dan dokumentasi yang sesuai. Selanjutnya, rilis ini dipasang di lingkungan pengujian pelanggan yang sesuai, yang, pada gilirannya, dengan cermat memeriksa semuanya dan hanya setelah itu rilis diterjemahkan ke dalam produksi.
Selain sistem rilis, ada format untuk perbaikan bug cepat sehingga klien tidak hidup dengan kesalahan selama enam bulan. Format sementara ini akan memungkinkan Anda untuk merespons insiden prioritas pertama dengan cepat dan memenuhi SLA yang dinyatakan.
Semua hal di atas berlaku terutama untuk sektor korporasi dan solusi di tempat. Untuk layanan cloud yang berfokus pada segmen SMB, tidak ada peluang luas bagi pelanggan untuk berpartisipasi dalam pengembangan produk. Format rental untuk SMB bahkan tidak menyarankan ini. Alih-alih permintaan perubahan dalam bentuk persyaratan yang jelas dari pihak perusahaan, inilah umpan balik dan keinginan biasa untuk layanan ini. Kami mencoba untuk mendengarkan, tetapi produk ini sangat besar dan keinginan satu klien untuk membawa sesuatu yang akrab dari sistem historisnya yang lama dapat bertentangan dengan strategi pengembangan sistem secara keseluruhan.