Pada artikel ini, saya akan berbagi pengalaman saya dalam memilih ide untuk mengembangkan fungsionalitas produk kami dan memberi tahu Anda cara mempertahankan vektor utama pengembangan.
Kami sedang mengembangkan sistem penyelesaian otomatis (ACP) - penagihan. Ketentuan
Kehidupan produk kami adalah 14 tahun. Selama ini, sistem telah berkembang dari sistem tarif industri versi pertama menjadi kompleks modular yang terdiri dari 18 produk yang saling melengkapi. Salah satu aspek terpenting dari kelanggengan program adalah pengembangan yang berkelanjutan. Dan pembangunan membutuhkan ide.
Situs
sumber
Ada 5 sumber:
- Teman utama seorang pengembang sistem informasi perusahaan adalah pelanggan. Dan klien adalah gambaran kolektif dari pengambil keputusan, sponsor proyek, pemilik dan pelaksana proses, spesialis TI internal, pengguna biasa, dan sejumlah besar individu yang berkepentingan pada tingkat yang berbeda-beda. Penting bagi kami bahwa setiap perwakilan klien berpotensi menjadi pemasok ide. Dalam kasus terburuk, kami hanya menerima umpan balik negatif tentang masalah pada sistem. Dalam kasus terbaik, ada orang di pihak klien yang selalu menjadi sumber ide perbaikan, memberikan informasi terstruktur tentang kebutuhan klien.
- Kami tenaga penjualan dan manajer akun adalah sumber gagasan terpenting kedua untuk perbaikan. Mereka secara aktif dan ekstensif berkomunikasi dengan perwakilan industri dan menerima pertanyaan langsung tentang fungsi penagihan dari klien potensial. Penjual dan akun harus menyadari semua perubahan signifikan dalam fungsi mereka dan pembaruan terkini pada perangkat lunak pesaing, dan mampu menjelaskan pro dan kontra dari berbagai solusi. Inilah karyawan kami yang pertama kali merasakan jika beberapa kemampuan penagihan menjadi standar de facto, yang tanpanya perangkat lunak tidak dapat dianggap lengkap.
- Pemilik produk — salah satu manajer puncak kami atau manajer proyek yang sangat berpengalaman. Mengingat tujuan strategis perusahaan dan menyesuaikan rencana pengembangan produk agar sesuai dengan tujuan tersebut.
- Arsitek, orang yang memahami kemampuan dan keterbatasan solusi teknologi yang dipilih/digunakan serta dampaknya terhadap pengembangan produk.
Tim pengembangan dan pengujian. Orang yang terlibat langsung dalam pengembangan produk.
Klasifikasi permintaan
Kami menerima data mentah dari sumber - surat, tiket, permintaan lisan. Semua
banding diklasifikasikan:
- Konsultasi dengan arti “Bagaimana caranya?”, “Bagaimana cara kerjanya?”, “Mengapa tidak berhasil?”, “Saya tidak mengerti…”. Permintaan jenis ini dikirim ke Saluran Dukungan Level 1. Dimungkinkan untuk melatih kembali konsultasi ke dalam jenis permintaan lainnya.
- Insiden dengan arti “Tidak berfungsi” dan “Error”. Diproses oleh 2 dan 3 Jalur Dukungan. Jika koreksi cepat dan rilis patch diperlukan, patch tersebut dapat ditransfer dari dukungan langsung ke pengembangan. Dimungkinkan untuk mengklasifikasikannya ulang sebagai permintaan perubahan dan mengirimkannya ke backlog.
- Permintaan perubahan dan pengembangan. Mereka masuk ke dalam product backlog, melewati jalur dukungan. Namun ada prosedur pemrosesan terpisah untuk mereka.
Ada statistik permintaan: segera setelah rilis, jumlah permintaan meningkat 10-15% dalam waktu singkat. Ada juga lonjakan permintaan ketika klien baru dengan jumlah pengguna yang banyak datang ke layanan cloud kami. Orang-orang sedang belajar menggunakan kemampuan perangkat lunak baru, mereka memerlukan saran. Bahkan klien kecil, ketika mulai bekerja di sistem, dengan mudah menghabiskan lebih dari 100 jam konsultasi per bulan. Oleh karena itu, saat menghubungkan klien baru, kami selalu menyediakan waktu untuk konsultasi awal. Seringkali kita bahkan memilih spesialis tertentu. Harga sewa tentu saja tidak menutupi biaya tenaga kerja tersebut, namun lama kelamaan keadaan menjadi seimbang. Masa adaptasi biasanya memakan waktu 1 hingga 3 bulan, setelah itu kebutuhan akan konseling berkurang secara signifikan.
Sebelumnya, kami menggunakan solusi yang ditulis sendiri untuk menyimpan permintaan. Namun secara bertahap kami beralih ke produk Atlassian. Pertama, kami mentransfer pengembangan untuk memudahkan pekerjaan menurut Agile, lalu dukungan. Sekarang semua proses penting ada di Jira SD, ditambah lagi didukung oleh berbagai plugin untuk Jira, plus Confluence. Solusi yang ditulis sendiri hanya berlaku untuk proses yang tidak penting bagi aktivitas perusahaan. Ternyata tugas kami sekarang bersifat lintas sektoral dan dapat ditransfer antara dukungan dan pengembangan tanpa berpindah dari satu sistem ke sistem lainnya.
Dari tautan ini kami dapat memperoleh data tentang semua tugas, biaya tenaga kerja yang direncanakan dan aktual, menggunakan berbagai pilihan harga untuk klien dan menghasilkan dokumentasi untuk kebutuhan internal dan pelaporan kepada klien.
Memproses permintaan perubahan
Biasanya, permintaan tersebut datang dalam bentuk persyaratan fungsionalitas. Analis kami mempelajari permintaan tersebut, membuat spesifikasi dan spesifikasi teknis tingkat atas. Mentransfer spesifikasi dan spesifikasi teknis kepada orang yang mengajukan permintaan persetujuan ini - kita harus yakin bahwa kita berbicara dalam bahasa yang sama dengan pelanggan.
Setelah menerima konfirmasi dari pelanggan bahwa kami memahami satu sama lain dengan benar, analis memasukkan permintaan tersebut ke dalam product backlog.
Manajemen fungsionalitas produk
Backlog mengumpulkan permintaan perubahan dan pengembangan yang masuk. Dewan teknis, yang terdiri dari direktur, kepala dukungan, pengembangan, penjualan dan arsitek sistem, bertemu setiap enam bulan. Dalam format diskusi, dewan menganalisis dan memprioritaskan aplikasi dari backlog dan menyetujui 5 tugas pengembangan untuk implementasi pada rilis berikutnya.
Akibatnya, dewan teknis menanggapi permintaan industri dan pasar dengan meninjau kebutuhan yang dinyatakan dalam aplikasi. Segala sesuatu yang kurang relevan tetap tertinggal dan tidak mencapai pengembangan.
Klasifikasi Permintaan Perubahan dan Pembiayaan
Pembangunan itu mahal. Oleh karena itu, kami akan segera memberi tahu Anda opsi apa yang mungkin kami miliki jika permintaan perubahan datang dari klien dan bukan karyawan.
Kami mengklasifikasikan permintaan perubahan sebagai berikut: kebutuhan industri atau karakteristik individu dari perusahaan; sejumlah besar fungsi baru atau perbaikan kecil. Perbaikan kecil dan permintaan individual diproses tanpa embel-embel apa pun. Permintaan individu dihitung dan diimplementasikan untuk klien tertentu sebagai bagian dari pekerjaan proyek dengannya.
Jika ini bukan kebutuhan industri yang besar dan volume fungsinya besar, maka keputusan dapat diambil untuk mengembangkan modul baru yang terpisah yang akan dijual selain fungsi utama. Jika permintaan seperti itu diterima dari klien, kami dapat menanggung biaya pengembangan modul, menyediakan modul tersebut kepada klien secara gratis atau dengan pembayaran sebagian, dan menjual modul itu sendiri. Dalam situasi seperti ini, klien mengambil bagian dari beban metodologis dan pada dasarnya melakukan implementasi percontohan modul pada dirinya sendiri.
Jika ini merupakan kebutuhan industri yang sangat besar, maka keputusan dapat diambil untuk memasukkan fungsionalitas baru ke dalam produk dasar. Biaya dalam hal ini sepenuhnya ditanggung oleh kami, dan fungsi baru muncul di versi program saat ini.
Pelanggan lama diberikan pembaruan.
Mungkin juga beberapa pelanggan mempunyai kebutuhan serupa, namun tidak memenuhi syarat untuk produk massal. Dalam hal ini, kami dapat mengirimkan spesifikasi kepada pelanggan tersebut dan menawarkan untuk membagi biaya pengembangan di antara mereka. Pada akhirnya, semua orang menang: pelanggan menerima fungsionalitas dengan biaya rendah, kami memperkaya produk, dan setelah beberapa waktu, pelaku pasar lainnya juga bisa mendapatkan fungsionalitas tersebut untuk mereka gunakan.
DevOps
Pengembangan menyiapkan dua rilis besar dalam setahun. Dalam setiap rilis, waktu dicadangkan untuk pelaksanaan 5 tugas yang diterima dari dewan teknis. Oleh karena itu, di tengah rutinitas, kami tidak pernah melupakan pengembangan produk.
Setiap rilis menjalani serangkaian pengujian dan dokumentasi yang sesuai. Selanjutnya, rilis ini dipasang di lingkungan pengujian pelanggan terkait, yang, pada gilirannya, dengan cermat memeriksa semuanya dan hanya setelah itu rilis ditransfer ke produksi.
Selain sistem rilis, terdapat format untuk perbaikan bug cepat sehingga klien tidak mengalami kesalahan selama enam bulan. Format perantara ini akan memungkinkan Anda merespons insiden prioritas pertama dengan cepat dan memenuhi SLA yang dinyatakan.
Semua hal di atas berlaku terutama untuk sektor korporasi dan solusi on-premise. Untuk layanan cloud yang ditujukan pada segmen UKM, belum ada peluang seluas-luasnya bagi klien untuk berpartisipasi dalam pengembangan produk. Format persewaan UKM bahkan tidak mengasumsikan hal ini. Alih-alih adanya permintaan perubahan berupa persyaratan yang jelas dari pihak perusahaan, di sini hanya ada tanggapan dan keinginan biasa terhadap layanan tersebut. Kami mencoba mendengarkan, namun produknya sangat besar dan keinginan salah satu klien untuk menghadirkan sesuatu yang familier dari sistem historis lama mereka mungkin bertentangan dengan strategi pengembangan sistem secara keseluruhan.
Sumber: www.habr.com