Dalam artikel ini, saya akan berkongsi pengalaman saya dalam memilih idea untuk pembangunan fungsi produk kami dan memberitahu anda cara mengekalkan vektor pembangunan utama.
Kami sedang membangunkan sistem penyelesaian automatik (ACS) - pengebilan. Penggal
Jangka hayat produk kami ialah 14 tahun. Pada masa ini, sistem telah beralih daripada versi pertama penilai industri kepada kompleks modular yang terdiri daripada 18 produk yang saling melengkapi. Salah satu aspek yang paling penting dalam jangka hayat untuk program ialah pembangunan berterusan. Dan idea diperlukan untuk pembangunan.
Idea
sumber
Terdapat 5 sumber:
- Rakan utama pembangun sistem maklumat korporat ialah pelanggan. Dan pelanggan ialah imej kolektif pembuat keputusan, penaja projek, pemilik dan pelaksana proses, pakar IT dalaman, pengguna biasa dan sebilangan besar orang yang berminat dalam pelbagai peringkat. Adalah penting bagi kami bahawa setiap wakil pelanggan berpotensi menjadi pembekal idea. Dalam kes yang paling teruk, kami hanya mendapat maklum balas negatif tentang masalah dalam sistem. Paling baik, terdapat seseorang di pihak pelanggan yang merupakan sumber idea yang berterusan untuk penambahbaikan, memberikan maklumat berstruktur tentang keperluan pelanggan.
- Kami penjual dan pengurus akaun merupakan sumber idea kedua terpenting untuk penambahbaikan. Mereka banyak berkomunikasi dan aktif dengan wakil industri, menerima permintaan tangan pertama untuk fungsi pengebilan daripada bakal pelanggan. Pedagang dan akaun perlu mengetahui semua perubahan ketara dalam fungsi mereka dan kemas kini perisian terkini pesaing, dapat mewajarkan kebaikan dan keburukan penyelesaian yang berbeza. Kakitangan kami inilah yang pertama merasakan jika beberapa ciri pengebilan menjadi standard de facto, tanpanya perisian itu tidak boleh dianggap lengkap.
- Pemilik Produk ialah salah seorang pengurus atasan kami atau pengurus projek yang sangat berpengalaman. Menyimpan matlamat strategik syarikat dalam fikiran dan menyesuaikan rancangan pembangunan produk mengikutnya.
- Arkitek, seseorang yang memahami kemungkinan dan batasan penyelesaian teknologi yang dipilih / digunakan dan kesannya terhadap pembangunan produk.
Pasukan pembangunan dan ujian. Orang yang terlibat secara langsung dalam pembangunan produk.
Klasifikasi hits
Kami menerima data mentah daripada sumber - surat, tiket, permintaan lisan. Semua
rayuan dikelaskan:
- Perundingan dengan maksud "Bagaimana untuk melakukannya?", "Bagaimana ia berfungsi?", "Mengapa ia tidak berfungsi?", "Saya tidak faham...". Panggilan jenis ini pergi ke Talian Sokongan Tahap 1. Adalah mungkin untuk melatih semula perundingan ke dalam jenis rayuan lain.
- Kejadian dengan maksud "Tidak berfungsi" dan "Ralat". Dikendalikan oleh 2 dan 3 talian sokongan. Jika perlu untuk membetulkan dan melepaskan tampalan dengan cepat, ia boleh dipindahkan daripada sokongan terus kepada pembangunan. Ia adalah mungkin untuk mengklasifikasikannya semula ke dalam permintaan perubahan dan menghantarnya ke tunggakan.
- Permintaan untuk perubahan dan pembangunan. Masuk ke dalam tunggakan produk, memintas Talian Sokongan. Tetapi bagi mereka terdapat prosedur pemprosesan yang berasingan.
Terdapat statistik sedemikian pada hits - sejurus selepas keluaran, bilangan hits meningkat sebanyak 10-15% untuk masa yang singkat. Terdapat juga letusan panggilan apabila pelanggan baharu dengan bilangan pengguna yang ramai datang ke perkhidmatan awan kami. Orang ramai sedang belajar menggunakan ciri perisian baharu, mereka memerlukan nasihat. Malah pelanggan kecil, apabila memulakan kerja dalam sistem, mudah membakar lebih daripada 100 jam perundingan setiap bulan. Oleh itu, apabila menyambungkan pelanggan baharu, kami sentiasa menyediakan masa untuk perundingan awal. Selalunya kami memilih pakar khusus. Kos sewa, sudah tentu, tidak membayar kos buruh ini, tetapi dari masa ke masa keadaan menjadi reda. Tempoh penyesuaian mengambil, sebagai peraturan, dari 1 hingga 3 bulan, selepas itu keperluan untuk kaunseling dikurangkan dengan ketara.
Sebelum ini, kami menggunakan penyelesaian bertulis sendiri untuk menyimpan panggilan. Tetapi secara beransur-ansur beralih kepada produk Atlassian. Pertama, pembangunan telah dipindahkan untuk memudahkan kerja pada Agile, kemudian sokongan. Kini semua proses kritikal hidup dalam Jira SD, ditambah pula dengan pelbagai pemalam untuk Jira, serta Confluence. Penyelesaian yang ditulis sendiri kekal hanya pada proses tidak kritikal untuk aktiviti syarikat. Ternyata tugas kami kini hujung ke hujung, mereka boleh dipindahkan antara sokongan dan pembangunan tanpa melompat dari satu sistem ke sistem yang lain.
Daripada himpunan ini, kami boleh mendapatkan data tentang semua tugas, kos buruh yang dirancang dan sebenar, menggunakan pelbagai pilihan pengebilan untuk pelanggan dan menjana dokumentasi untuk keperluan dalaman dan laporan kepada pelanggan.
Memproses Permintaan Perubahan
Biasanya, permintaan ini datang dalam bentuk keperluan ciri. Penganalisis kami mengkaji permintaan itu, menjana spesifikasi dan TOR peringkat teratas. Memindahkan spesifikasi dan TOR kepada orang yang menyerahkan permintaan kelulusan ini - kami mesti memastikan bahawa kami bercakap bahasa yang sama dengan pelanggan.
Setelah menerima pengesahan daripada pelanggan bahawa kami memahami satu sama lain dengan betul, penganalisis memasukkan permintaan ke dalam tunggakan produk.
Pengurusan ciri produk
Tunggakan terkumpul menerima permintaan untuk perubahan dan pembangunan. Setiap enam bulan sekali, majlis teknikal, yang terdiri daripada pengarah, ketua penyelenggaraan, pembangunan, jualan dan arkitek sistem, bertemu. Dalam format perbincangan, majlis menganalisis dan mengutamakan permohonan daripada tunggakan dan bersetuju dengan 5 tugas pembangunan untuk dilaksanakan dalam keluaran seterusnya.
Malah, majlis teknikal bertindak balas kepada keperluan industri dan pasaran, dengan mengambil kira keperluan yang direkodkan dalam aplikasi. Segala-galanya yang kurang relevan tetap tertunggak dan tidak mencapai pembangunan.
Klasifikasi Permintaan Perubahan dan Kewangan
Pembangunan adalah mahal. Oleh itu, kami akan segera memberitahu anda pilihan yang mungkin kami ada jika permintaan perubahan datang daripada pelanggan, dan bukan pekerja.
Permintaan perubahan dikelaskan seperti berikut: keperluan khusus industri atau ciri individu perusahaan; sejumlah besar fungsi baharu atau pembaikan kecil. Pembetulan kecil dan permintaan individu diproses tanpa sebarang tambahan. Permintaan individu dikira dan dilaksanakan untuk pelanggan tertentu sebagai sebahagian daripada kerja projek dengannya.
Jika ini bukan keperluan industri yang besar dan jumlah fungsinya besar, maka keputusan boleh dibuat untuk membangunkan modul berasingan baharu yang akan dijual sebagai tambahan kepada fungsi utama. Jika permintaan sedemikian diterima daripada pelanggan, kami boleh menampung kos membangunkan modul, memberikan pelanggan modul secara percuma atau dengan pembayaran separa dan meletakkan modul dalam domain awam untuk dijual. Dalam keadaan sedemikian, pelanggan mengambil sebahagian daripada beban metodologi dan, sebenarnya, menjalankan pelaksanaan perintis modul.
Jika ini adalah keperluan industri yang besar, maka keputusan boleh dibuat untuk memasukkan fungsi baharu dalam produk asas. Kos dalam kes ini ditanggung sepenuhnya oleh kami, dan fungsi baharu muncul dalam versi program semasa.
Pelanggan lama disediakan dengan kemas kini.
Mungkin juga beberapa pelanggan mempunyai keperluan yang sama, tetapi ia tidak menarik produk besar-besaran. Dalam kes ini, kami boleh menghantar spesifikasi kepada pelanggan ini dan menawarkan untuk berkongsi kos pembangunan antara mereka. Pada akhirnya, semua orang menang: pelanggan mendapat pelaksanaan fungsi pada kos yang rendah, kami memperkayakan produk, selepas beberapa ketika peserta pasaran lain juga boleh mendapatkan fungsi untuk kegunaan mereka.
DevOps
Pembangunan menyediakan dua keluaran utama setiap tahun. Dalam setiap keluaran, masa dikhaskan untuk pelaksanaan 5 tugasan yang diterima daripada majlis teknikal. Oleh itu, di sebalik perolehan, kami tidak pernah lupa tentang pembangunan produk.
Setiap keluaran melalui set ujian dan dokumentasi yang sesuai. Selanjutnya, keluaran ini dipasang dalam persekitaran ujian pelanggan yang sepadan, yang, seterusnya, menyemak segala-galanya dengan teliti, dan hanya selepas itu keluaran dipindahkan ke pengeluaran.
Selain sistem keluaran, terdapat format pembetulan pepijat pantas supaya pelanggan tidak hidup dengan ralat selama enam bulan. Format perantaraan ini akan membolehkan anda bertindak balas dengan cepat terhadap insiden keutamaan pertama dan memenuhi SLA yang dinyatakan.
Semua perkara di atas adalah benar terutamanya untuk sektor korporat dan penyelesaian di premis. Untuk perkhidmatan awan yang tertumpu pada segmen SMB, tidak ada peluang yang begitu luas untuk pelanggan mengambil bahagian dalam pembangunan produk. Format pajakan untuk SMB tidak mencadangkan ini. Daripada permintaan perubahan dalam bentuk keperluan yang jelas daripada pihak korporat, terdapat hanya maklum balas dan keinginan biasa untuk perkhidmatan tersebut. Kami cuba mendengar, tetapi produk itu sangat besar dan keinginan seorang pelanggan untuk membawa sesuatu yang biasa daripada sistem sejarah lamanya mungkin bercanggah dengan strategi pembangunan sistem secara keseluruhan.
Sumber: www.habr.com